ИИ для написания кода

ИИ для написания кода перестал быть экспериментом энтузиастов. В 2026 году его используют студии, внутренние IT-отделы и соло-разработчики. Вопрос не «пользоваться или нет», а «где черновик уместен, а где цена ошибки выше экономии часов». Компании, которые внедряют модель без правил, получают ускорение багов. Компании, которые запрещают всё из страха, теряют скорость на рутине.

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

Где ИИ действительно экономит время

Хорошо получается черновик типового кода: CRUD, маппинг DTO, тесты на очевидные ветки, миграции по описанной схеме, документация API по уже существующим хендлерам, переписывание однообразных кусков. Хорошо получается объяснение чужого фрагмента и поиск по репозиторию, если агенту дали доступ к контексту.

Плохо получается «придумать предметную область». Модель не была на вашей планёрке и не знает, что «отгрузка» у вас означает три разных статуса. Плохо получается безопасность «по умолчанию»: она может предложить хранить токен в незащищённом месте, потому что так короче пример. Плохо получается оценка нагрузки и деградации при обрыве сети в полевом приложении.

Задачи, которые обычно отдают первыми

• Бойлерплейт клиентов API по OpenAPI.
• Генерация черновика unit-тестов с последующей вычиткой.
• Рефакторинг имён и навигации в небольшом модуле.
• Черновик changelog и комментариев к сложным веткам.
• Поиск мест, где копипаста разъехалась между платформами.

Риски: качество, лицензии, данные, ответственность

Качество. Сгенерированный код часто «почти работает». Почти — это дефект в проде. Без тестов и ревью вы копите долг быстрее, чем писали руками. Лицензии. Фрагменты могут напоминать публичные репозитории; для коммерческого продукта нужна политика: не вставлять код с неясной лицензией, фиксировать зависимости.

Данные. В промпт легко отправить ключ, персональные данные клиента, закрытую бизнес-логику. Это инцидент, даже если «просто проверяли идею». Ответственность. Акт приёмки подписывает заказчик и подрядчик, не модель. В договоре полезно указать, что генеративные инструменты допустимы, но гарантия качества остаётся на исполнителе.

Для мобильных клиентов риск выше: сторы, платежи, биометрия. Для внутренних систем управления — права доступа и журналы. Связка с процессом продукта — процесс разработки приложений и проектирование и разработка ПО.

Как внедрить ИИ в команду, не развалив поставку

Начните с политики на одной странице: какие инструменты разрешены, какие проекты под запретом (платежи, медицина, гостайна — по вашему контуру), как хранить секреты, кто ревьюит дифф. Затем пилот: один сервис, измеримые метрики (время на типовой задачу, плотность дефектов после релиза), срок 2–4 недели.

1. Запретите вставлять секреты и выгрузки клиентов в чат.
2. Требуйте описание изменения человеческим языком в задаче, не только «ИИ так сделал».
3. Критичный путь — тесты до мержа, не «потом».
4. Агентам ограничивайте права: не давать слепой доступ к продовой инфраструктуре.
5. Раз в спринт разбирайте промахи: галлюцинации API, лишние зависимости, сломанные контракты.

Заказчику на созвоне полезно спросить подрядчика, пользуются ли они ИИ и как контролируют качество. Отказ обсуждать процесс — такой же сигнал, как отказ показать репозиторий. Выбор команды — как выбрать подрядчика.

Постановка задач для модели

Чем точнее контекст, тем меньше «уверенного бреда». Давайте ограничения: стек, стиль, файлы, которые нельзя трогать, примеры вход/выход, что считать ошибкой. Не просите «сделай как Uber». Просите «добавь идемпотентность создания заказа по ключу X, покрой тестом повторного запроса».

Для агентов отдельно фиксируйте stop-условия: не рефакторить соседние модули, не обновлять мажор зависимостей, не менять схему БД без миграции и ревью. Иначе за ночь получите «улучшения», которые ломают отчёты бухгалтерии.

ИИ и заказчик: что меняется в ТЗ и приёмке

ТЗ не становится короче. Сценарии, роли, интеграции остаются. Меняется скорость прототипа: черновик экранов и API можно увидеть раньше. Приёмка должна опираться на чек-лист сценариев, а не на «код похож на современный». Если подрядчик сдаёт модуль «написанный нейросетью» без тестов — это не инновация, это перенос риска на вас.

Как фиксировать требования — как составить ТЗ. Как не расползтись в scope — ошибки заказчика.

Когда ИИ для кода не нужен или вреден

Вреден как замена понимания домена. Вреден в контуре, где нельзя отправлять фрагменты во внешнее облако, а локальной модели нет. Вреден, если в команде нет человека, способного отвергнуть плохой дифф. Не нужен как маркетинговая галочка в КП без изменения процесса качества.

Не путайте «ИИ пишет код» с «ИИ-функция в продукте для клиентов». Второе — отдельная спецификация: данные, метрика, отказ модели, человек в контуре. Это ближе к продуктовой задаче, чем к автодополнению в IDE.

Следующий шаг

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

Если разрабатываете ПО или приложение и хотите прозрачный процесс с ревью — Grevin, grevin.info@mail.ru, контакты. Услуги: разработка ПО, разработка приложений.

Примеры промптов, которые снижают брак

Плохой запрос: «напиши сервис заказов». Рабочий запрос: «добавь endpoint создания заказа, идемпотентный ключ в заголовке, при повторе возвращай существующий id, покрой двумя тестами: новый и повтор, не трогай модуль отчётов». Вторая формулировка экономит часы ревью, потому что модель меньше додумывает соседние слои.

Для фронтенда указывайте, какие компоненты уже есть в дизайн-системе и какие состояния обязательны: загрузка, пусто, ошибка, нет прав. Иначе получите третью кнопку «отправить» с другим текстом и без обработки 401. Для мобильного клиента отдельно запрещайте хранить секреты в коде и логировать персональные данные — модели любят удобный console.log.

Храните удачные промпты в вики команды как часть инженерной культуры, не как личные чаты. Тогда пилот ИИ переживает отпуск того, кто «умеет спрашивать».

Метрики, по которым пилот ИИ можно оставить или закрыть

Считайте время от постановки до ревью, долю возвратов с ревью, дефекты после релиза на 100 изменений, инциденты, связанные с принятым сгенерированным диффом. Если строки кода выросли, а дефекты тоже — вы ускорили производство брака. Если ревьюеры тонут в тысячестрочных PR — сузьте автономию агента.

Отдельно мерите онбординг: новичок с ИИ быстрее находит место правки или быстрее плодит костыли в неправильном слое? Второе лечится картой архитектуры и запретом трогать ядро без плана, не покупкой более «умной» модели.

Юридическая и закупочная рамка

В договоре с подрядчиком полезно зафиксировать: генеративные инструменты допустимы; ответственность за дефекты и лицензионную чистоту на исполнителе; запрет скармливать ваши данные в сервисы с обучением на клиентских промптах без согласия. Для внутренней разработки — приказ или политика ИБ с тем же смыслом.

Закупка лицензий ИИ должна идти рядом с закупкой IDE и облака, а не «с карточки сотрудника». Иначе через год вы не знаете, кто имеет доступ к репозиторию через личный аккаунт. Это уже не про код, а про контур компании. Связка с безопасностью — безопасная разработка ПО, с услугой работ — разработка ПО как услуга.

ИИ в тестировании и документации

Черновик тест-кейсов по сценариям ТЗ — сильная сторона. Генерация «тестов, которые всегда зелёные» — слабая: модель любит проверять саму себя. Человек обязан задать негативные случаи: повтор оплаты, пустой файл, отозванный токен. Документацию API лучше генерировать из живого контракта, а не из прозы в чате, иначе она разъедется с кодом за спринт.

Для заказчика это значит: в приёмке по-прежнему чек-лист сценариев. «Нейросеть покрыла тестами» не заменяет прогон «менеджер видит заказ за минуту». Продуктовая ясность важнее любой модели: ТЗ, процесс приложений.

Онбординг разработчика в мире ИИ

Новому человеку выдайте не только доступ к репозиторию, но и карту «куда не пускать агента», примеры хороших PR и список модулей с повышенной ценой ошибки. Иначе он ускорит хаос в платежном контуре в первую неделю. Парное ревью первых сгенерированных диффов — обязательная инвестиция. Через две недели правило можно ослабить на типовых задачах.

Документируйте антипаттерны: агент добавил зависимость без нужды, сериализовал лишние поля, обошёл линтер, написал тест на реализацию вместо поведения. Это учебник команды ценнее любого внешнего курса «промпт-инжиниринг». Для заказчика наличие такого онбординга — зелёный флаг подрядчика рядом с чек-листом выбора.

ИИ и оценка сметы: не путать часы печати с часами ответственности

Подрядчик может честно сказать, что черновик пишется быстрее. Он не должен вычитать из сметы ревью, тесты, постановку и сопровождение. Если КП стало втрое дешевле «из-за нейросети» при том же scope платежей и 1С, вы либо смотрите урезанное качество, либо маркетинг. Просите ту же разбивку блоков, что и без ИИ: аналитика, реализация, тесты, публикация, передача.

Внутренней команде ИИ не отменяет бэклог и владельца продукта. Он отменяет часть скучной печати. Продуктовая неопределённость как стоила дорого, так и стоит. Её лечат сценарии и ТЗ, не модель: как составить ТЗ, проектирование ПО.

ИИ не отменяет код-ревью и не ускоряет неопределённость

Самый частый самообман 2026 года: «раз модель пишет быстро, можно не описывать процесс». Неопределённый процесс в быстрых диффах размножается быстрее. Ревьюер, который не понимает домен, начнёт пропускать «похоже на правду». Держите ревьюера, который может сказать нет. Держите сценарии приёмки. ИИ — печать, не стратегия. Стратегия по-прежнему в границах v1, в правах, в интеграциях и в том, кто отвечает за прод ночью. Для продукта это те же услуги и та же ответственность: разработка ПО, приложения, контакты.

Практика репозитория: ветки, линтеры, запретные каталоги

Заведите файл правил для агента рядом с линтером: какие каталоги не трогать, какой стиль импортов, запрет новых зависимостей без задачи. Человек всё равно ревьюит, но агент реже предлагает третий фреймворк «для красоты». Ветки агента именуйте явно, чтобы откат был понятен. Этого абзаца достаточно, чтобы пилот не расползся по ядру в первый день. Дальше дисциплина важнее выбора модели.

Частые вопросы