ИИ-инструменты для кода: где они реально ускоряют работу, а где создают иллюзию прогресса

Когда продукт, собранный на коленке с помощью ИИ, продаётся за 80 миллионов долларов через полгода после запуска — хочется поверить, что ИИ-кодинг это однозначное благо. Но реальность интереснее и сложнее. Эти инструменты ускоряют одни задачи и замедляют другие. Команды, которые понимают эту разницу, действительно двигаются быстрее — но без накопления скрытого долга.

Проблема ощущений

Исследование METR поставило опытных разработчиков перед реальными задачами в их собственных крупных кодовых базах. До начала работы участники оценили, что ИИ ускорит их примерно на 24%. После завершения — примерно на 20%. Замеры показали другое: с ИИ они работали на 19% медленнее.

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

Где ускорение реально работает

Исследования сходятся в одном: настоящий выигрыш — в новом коде на незнакомой территории. Контролируемое исследование GitHub показало, что разработчики создавали веб-сервер с нуля на 55% быстрее с Copilot. Эксперименты в реальных компаниях зафиксировали на 26% больше выполненных задач. Младшие разработчики давали на 27–39% больше результата на задачах с коротким сроком выполнения. Лабораторные замеры McKinsey показали, что документация и код на зелёном поле появляются примерно вдвое быстрее.

Это профиль MVP. Чистый проект, стек, который изучаешь, шаблоны — или фича, которую можно описать коротким промптом. На такой работе инструменты делают именно то, что обещает реклама. Ключевое слово — "именно это".

Где начинается торможение

Замедление в исследовании METR случилось именно там, где и ожидалось: опытные разработчики поддерживали кодовые базы, которые писали сами years. Модель выдавала правдоподобный код для системы, которую не понимала. Разработчик тратил время на оценку корректности. И эта оценка стоила больше, чем просто написать функцию с нуля.

В масштабе это именно то, где команды попадают в неприятности. Стартап активно использует ИИ для MVP, находит product-market fit, начинает расти — и через три месяца обнаруживает, что "работающий код" содержит проверки безопасности на уровне строк, которые закомментированы; админку, доступную любому аутентифицированному пользователю; API-ключи, оказавшиеся в клиентском бандле. ИИ писал быстро. ИИ создал проблемы с безопасностью, которые никто не планировал проверять.

Исследование Faros AI, охватившее более 10 000 разработчиков в реальных командах, показало: ИИ-помощь замедляла команды в 20–40% сценариев. Особенно в кодовых базах свыше 100 000 строк, где контекстное окно не вмещает всю картину. Это проблема brownfield-работы. Именно здесь живёт большинство устоявшихся команд большую часть времени.

Счёт за безопасность, который никто не озвучивает

Каждую неделю появляется история: код от ИИ раскрыл пользовательские данные; деплой с ИИ-помощью оставил порт базы данных открытым; prompt injection попал в продакшен. Это не экзотические исключения. Это предсказуемый результат направления инструмента, оптимизированного на правдоподобный код, в безопасностно-чувствительную работу — без проверки экспертом по безопасности.

Паттерн предсказуем. ИИ-кодинг-инструменты обучаются на публично доступном коде. А этот код содержит множество известных уязвимостей, некорректных настроек прав доступа, захардкоженных секретов. Когда просишь такой инструмент создать систему аутентификации или платёжную интеграцию — часто получаешь правдоподобную версию. Которая может быть безопасной, а может и не быть.

Для быстро двигающихся стартапов это критический риск. Вы строите не просто MVP. Вы строите репутацию и surfaces для compliance. Утечка данных в первый год — не техническая проблема. Это проблема, которая может закончить компанию.

Практическая рамка

Исследования указывают на чёткую операционную модель:

Используйте ИИ агрессивно для зелёного поля. Новые проекты, прототипы, шаблоны, незнакомые стеки, хорошо очерченные фичи — там ускорение реально и значительно. Это большая часть того, что запускает MVP. Это где инструменты отрабатывают подписку.

Используйте ИИ выборочно для brownfield. В кодовой базе, которую знаете хорошо, или на чём угодно, касающемся аутентификации, платежей, пользовательских данных — относитесь к результату ИИ как к черновику, требующему проверки безопасности. Время на эту проверку — реальная стоимость инструмента на этой работе. Не давайте ощущению "работаю быстрее" уговорить вас пропустить её.

Отгружайте маленькими порциями, с тестами. Нестабильность в выводе ИИ проявляется сильнее всего в крупных сложных изменениях. Маленькие инкрементальные изменения с реальным тестовым покрытием ловят тонкие ошибки, которые проходят ревью и вызывают инциденты в продакшене. Это хорошая практика в целом. Но она становится критической, когда ИИ в процессе.

Укрепляйте защиту до контакта с пользователями. Включайте проверки безопасности на уровне строк. Убирайте секреты из клиентского кода. Не направляйте ИИ-агента на продакшен-базу. Это не экзотические меры безопасности. Это базовый уровень для любой системы с реальными пользовательскими данными. ИИ-кодинг не меняет этот базовый уровень. Он просто делает его легче пропустить.

Итог

ИИ-инструменты для кода действительно полезны. Но они также создают затраты — реальные, предсказуемые, почти никогда не упоминаемые в маркетинговых материалах. Команды, которые двигаются быстрее всех, — не те, что используют ИИ для всего. Это те, кто использует его стратегически: там, где ускорение реально, защищая при этом части системы, где корректность важнее скорости.

Собираете MVP на Vibe Hosting? Используйте ИИ-инструменты для быстрого движения по частям, которые могут измениться. Используйте аккуратно там, где всё должно быть правильно с первого раза. И если не уверены, где проходит граница — это, вероятно, ваш следующий вопрос.