Содержание
- Тезис, который все цитируют
- Что ИИ реально делает хорошо
- Где ломается: чего LLM не умеет
- «90% кода» ≠ «90% работы»
- Что меняется в бюджетах и сроках
- Что меняется в найме и аутстаффе
- Как мы используем ИИ в заказной разработке
- Чек-лист: о чём спросить подрядчика
- FAQ
Тезис, который все цитируют
Полтора года назад глава Anthropic заявил: «через шесть месяцев ИИ будет писать 90% кода». Шесть месяцев прошли, потом ещё, и фраза превратилась в мем — её цитируют и евангелисты, и скептики. В профессиональных сообществах спор не утихает: одни показывают, как агент за вечер собирает работающий прототип, другие — как тот же агент уверенно генерирует код, который не проходит ревью и падает в проде.
Истина, как обычно, не в лагере, а в деталях. ИИ действительно изменил процесс разработки — но «90% кода» и «90% работы по созданию продукта» это очень разные числа. Ниже — трезвый разбор без хайпа: где LLM реально ускоряют заказную разработку, а где по-прежнему нужен инженер с опытом.
Что ИИ реально делает хорошо
За последний год LLM и агенты перестали быть игрушкой и стали рабочим инструментом для конкретных задач:
- Boilerplate и обвязка. CRUD-эндпоинты, DTO, мапперы, конфиги, тесты-заготовки — то, что инженер писал руками по шаблону, теперь генерируется за секунды.
- Объяснение чужого кода. Разобраться в legacy-модуле, который писали пять лет назад уволившиеся разработчики, — ИИ читает и пересказывает быстрее человека.
- Перевод между технологиями. Накидать эквивалент функции с одного языка на другой, переписать SQL-запрос под другой диалект, сгенерировать клиент по OpenAPI-спеке.
- Рутинный рефакторинг. Переименования, извлечение методов, приведение к единому стилю — под контролем линтеров и тестов.
Ключевое наблюдение из практики: слабая модель в хорошо инструментованном контуре работает как сильная. Когда вокруг ИИ настроены компилятор, линтеры, типы и автотесты, которые возвращают ему ошибки, он итеративно дописывает до рабочего состояния. Без этой обвязки — генерирует правдоподобный, но хрупкий код.
Где ломается
А вот список того, где «напиши мне сервис» заканчивается дорогими сюрпризами:
- Архитектурные решения. ИИ предложит реализацию, но не возьмёт на себя ответственность за выбор между монолитом и микросервисами, за модель консистентности данных, за то, как система переживёт рост в 50 раз. Это решения с последствиями на годы.
- Неявные требования. Бизнес-логика, которую заказчик «забыл сказать, потому что это очевидно», граничные случаи, регуляторика (152-ФЗ, отраслевые нормы) — ИИ не угадывает контекст, которого нет в промпте.
- Отладка распределённых сбоев. Гонки, дедлоки, утечки под нагрузкой, «иногда падает раз в сутки» — здесь нужен инженер, который умеет читать трейсы и метрики, а не догадки по логам.
- Безопасность. Сгенерированный код регулярно содержит уязвимости и тянет случайные зависимости — а в репозиториях пакетов (PyPI, npm) и без того растёт число вредоносных пакетов. Без аудита это прямой риск.
«90% кода» ≠ «90% работы»
Даже если принять, что ИИ генерирует львиную долю строк, создание продукта — это не только написание кода. Разложим типичный проект заказной разработки по этапам и прикинем, где ИИ реально снимает нагрузку:
| Этап | Доля усилий | Помощь ИИ |
|---|---|---|
| Аналитика, требования, ТЗ | высокая | низкая — нужен диалог с бизнесом |
| Архитектура и проектирование | высокая | средняя — как ассистент, не как решающий |
| Написание кода | средняя | высокая |
| Ревью, отладка, интеграции | высокая | средняя |
| Тестирование, нагрузка, безопасность | высокая | средняя |
| Деплой, мониторинг, поддержка | средняя | низкая |
Получается, что «написание кода» — лишь один из шести этапов, и именно там ИИ силён. Остальные пять — про понимание задачи, ответственность за решения и эксплуатацию. Поэтому даже при «90% кода от ИИ» совокупная экономия на проекте — не 90%, а скорее 20–40% на этапе реализации.
Что меняется в бюджетах и сроках
Реальный эффект, который мы видим на проектах:
- MVP собирается быстрее. То, что занимало 6 недель, делается за 4 — за счёт ускорения рутины. Это уже отражается в наших оценках.
- Смещается структура затрат. Меньше времени на «набивание» кода, больше — на проектирование, ревью и тестирование. Доля senior-времени в проекте растёт, а не падает.
- Дешёвый старт, та же стоимость владения. ИИ удешевляет первую версию, но сопровождение, развитие и устранение техдолга зависят от качества архитектуры — а его задаёт человек.
Вывод для заказчика: ИИ — это рычаг скорости на этапе реализации, но он не отменяет аналитику и не заменяет ответственность за результат.
Что меняется в найме и аутстаффе
На рынке труда — парадокс. С одной стороны, рынок жалуется: качественных специалистов «разобрали», работодатели «бросаются деньгами», а в потоке всё больше слабых. С другой — ИИ поднимает планку: рутину теперь делает модель, и ценность инженера смещается к тому, что ИИ не умеет — архитектура, отладка, ответственность.
Практический итог: нужно меньше джунов на рутину и столько же (или больше) сильных инженеров на решения. Поэтому модель аутстаффинга Java/Kotlin-разработчиков становится выгоднее найма: вы берёте готового senior-инженера под задачу, а не растите команду под рутину, которую и так закрывает ИИ.
Как мы используем ИИ
Мы не прячем, что используем ИИ в разработке ПО на заказ — но используем его как инструмент в руках инженера, а не как замену инженеру:
- Генерация под ревью. Весь сгенерированный код проходит code review и автотесты — как и написанный руками. Без исключений.
- Контур безопасности. Сгенерированные зависимости проверяем, секреты и ПД не уходят в облачные модели (см. подход локальные LLM против облака).
- Человек принимает решения. Архитектуру, выбор стека, модель данных, стратегию отказоустойчивости задаёт senior, а не промпт.
- Ускорение, а не срезание углов. ИИ экономит время на рутине — это время уходит в качество: больше тестов, лучше документация, тщательнее ревью.
Чек-лист
О чём стоит спросить подрядчика, который «делает всё с ИИ»:
- Проходит ли сгенерированный код ревью и автотесты? Если «ИИ же написал, значит работает» — это красный флаг.
- Кто принимает архитектурные решения — инженер или модель?
- Что с безопасностью зависимостей и куда уходят ваши данные при работе с LLM?
- Передаётся ли исходный код и документация — или вы получаете «чёрный ящик», который никто не понимает?
- Как считается оценка — учитывает ли ускорение рутины ИИ, или вам продают старые часы по старой цене?
Если нужна команда, которая использует ИИ как ускоритель, но отвечает за результат по-инженерному — это наша заказная разработка ПО на Java/Kotlin под ключ и разработка ИИ-решений.
FAQ
ИИ действительно пишет 90% кода?
В отдельных задачах (boilerplate, тесты-заготовки, рутинный рефакторинг) — близко к тому. Но «написание кода» — лишь один из этапов проекта. С учётом аналитики, архитектуры, отладки, тестирования и эксплуатации совокупная экономия на реальном проекте — порядка 20–40% на этапе реализации, а не 90%.
Можно ли заказать разработку «полностью на ИИ» и сэкономить?
Можно получить дешёвый прототип. Но без архитектуры, ревью и тестирования он превращается в техдолг, который дороже переписать, чем сделать сразу правильно. ИИ удешевляет первую версию, а не стоимость владения.
ИИ заменит разработчиков?
Он заменяет рутину, а не инженерное мышление. Ценность смещается к тому, что ИИ не умеет: архитектура, отладка распределённых сбоев, ответственность за решения, понимание бизнес-контекста. Сильных инженеров нужно столько же или больше.
Безопасно ли отдавать код и данные в ИИ?
Зависит от контура. Публичные данные — можно облачным моделям. Персональные данные и коммерческую тайну — только через закрытый контур или со слоем обезличивания. Мы не отправляем чувствительные данные в облачные LLM напрямую.
Это ускорит мой проект?
Да, на этапе реализации — обычно на 20–40%, особенно на MVP. Но аналитику и проектирование ИИ не ускоряет, поэтому общий срок сокращается умеренно, а не в разы.