Часть 3. В прод попадает не лучшая модель. В прод попадает та, что переживёт деплой

Самый честный способ описать реальное разделение труда в ИИ-разработке Формула «Python обучает + Java разворачивает» — это не идеология, а экономика. Python доминирует там, где нужно быстро перебрать архитектуры, поэкспериментировать с гиперпараметрами, запустить ноутбук с визуализацией. Java выигрывает там, где модель должна работать 24/7 под нагрузкой, с гарантиями по latency, с интеграцией в существующую систему мониторинга и безопасности. Это типичный корпоративный сценарий, а не универсальный закон: обучение идёт и на C++ с CUDA, и на JAX, а inference-сервисы строят и на Go, и на Rust.

Экономика — ключевой аргумент. Microsoft Java-команда сформулировала его в терминах стоимости: JVM эффективнее Python и Node.js по соотношению производительности и потребления ресурсов — особенно в серверных нагрузках с длительным жизненным циклом процесса. Холодный старт JVM может проигрывать, и именно поэтому появились GraalVM Native Image и Project Leyden. Но когда предприятие разворачивает сотни или тысячи ИИ-агентов, каждая сэкономленная единица вычислительных ресурсов превращается в дополнительный бюджет на токены и API-вызовы. Если один агент экономит 200 МБ памяти, тысяча агентов — это уже 200 ГБ, которые можно потратить на более мощную модель.

Есть и менее очевидный аргумент. Когда ИИ-ассистенты пишут всё больше кода, критерий выбора языка смещается с «кто короче» на «кто понятнее для ревью». Java с её явным, структурированным синтаксисом даёт человеку больше шансов понять и проверить то, что сгенерировала модель. По опыту команд, Copilot, Claude Code и Cursor стабильнее генерируют код для фреймворков с устоявшимися конвенциями — таких как Spring Boot и Hibernate. Публичных сравнительных измерений пока мало, но наблюдение устойчивое. Строгая типизация здесь работает как страховка: если ИИ-ассистент ошибётся с типом, компилятор поймает это до код-ревью. В динамических языках та же ошибка всплывёт только в рантайме — возможно, в продакшене.

Отдельная тема — зависимости и сборка. Maven и Gradle с их версионированием и плагинами дают предсказуемый reproducible build. В Python-мире с его виртуальными окружениями и конфликтами версий пакетов воспроизводимость сборки до сих пор остаётся головной болью. Для enterprise, где аудит требует точного знания, какой код и с какими зависимостями развёрнут, это не мелочь. А эксплуатация — это 90% жизни любой модели в продакшене. Демо живёт один день, модель в банке — годы. И всё это время кто-то должен её обслуживать, мониторить, обновлять и объяснять регулятору, почему она работает именно так. Java делает эту работу скучной — а скучная работа в enterprise и есть синоним надёжности.

И вот здесь стоит сказать про понедельники. Понедельник — это не день недели. Это день, когда проверяется, переживёт ли ваш деплой выходные. В пятницу модель отвечала на 98% запросов корректно. В понедельник после обновления данных она начала отклонять заявки без объяснения. Java-команда видит в логах, какой именно шаг планировщика изменил маршрут. Python-команда видит, что промпт вернул другой результат — и не всегда может сказать почему.

Разница не в наличии логов — они есть везде. Разница в зрелости платформенной наблюдаемости: JMX, Micrometer, Actuator, APM-агенты в Java против более фрагментированного набора инструментов в Python. Зрелые Python-команды тоже используют structured logging, OpenTelemetry, Sentry и tracинг — но собрать это в единую картину сложнее. В Java-мире наблюдаемость встроена в платформу: метрики, трейсы, дашборды — бесплатно, просто добавьте зависимость.

Справедливости ради: Python остаётся лучшим выбором для research, обучения моделей и экспериментов с архитектурами. LangGraph, Prefect и Dagster дают хорошую оркестрацию и наблюдаемость. Java выигрывает не потому, что Python плохой, а потому что задачи разные. Одно дело — найти архитектуру, другое — держать в проде годами.

Понедельник покажет, кто построил систему, а кто — демо.