Что дописать в задачу для ИИ-кода

Разработчик под ником (имя не указано) на платформе «Хабр» опубликовал статью о том, как использование AI для генерации кода меняет подход к постановке задач. Автор описывает опыт мультибрендовой платформы и собственного автомобильного маркетплейса, где AI применялся на поздних этапах развития. По его словам, AI способен за вечер собрать интерфейс, backend и рабочий сценарий, но проблемы начинаются к пятому релизу, когда новое требование затрагивает несколько сервисов.

В статье вводится различие между «вайбкодингом» и инженерной работой с AI. В первом случае человек описывает желаемый результат и принимает работу по наблюдаемому поведению. Во втором — в задачу включаются ограничения существующей системы, допустимые изменения, условия отказа и способы проверки. Автор подчёркивает, что разница не в объёме сгенерированного кода, а в том, какие решения приняты осознанно.

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

Автор приводит учебный пример с каталогом игр двух провайдеров, где разные имена полей (id/name и code/title) приводят к условным операторам у потребителей. Это, по его мнению, ошибка проектирования, а не стиль. Со временем такие условия превращаются в карту исключений, и никто не может сказать, сколько мест нужно поменять для подключения следующего источника.

Опытный инженер, в отличие от новичка, формулирует в задаче для AI не только желаемый результат, но и условия, в которых решение должно продолжать работать. AI тоже может предложить риски и ограничения, но ответственность за выбор остаётся на человеке. Автор отмечает, что универсального списка вопросов нет, и сравнивать подходы стоит на второй, пятой и десятой итерации.

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