Пять инженерных решений, которые нужно принять до генерации кода с AI

Инженер принимает решения то в коде, то до него. Если первый вопрос задать AI сразу, результат будет работающим, но его стоимость вырастет уже на втором релизе.

Вайбкодинг vs инженерная работа

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

Это не уровни — начинающий разработчик может работать вторым способом, опытный — первым. Значение имеет опыт, который превратился в понимание зависимостей. Когда ты уже откатывал релиз или разбирал конкурентную запись в базе, в новом задании сами собой появляются дополнительные вопросы — до кода и первого дефекта.

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

Пять решений до первой строки кода

1. Интеграции: определить границу внешнего контракта

На работающем продукте это часто три отдельных сервиса: A получает данные от провайдера, Б реализует бизнес-правило, В показывает результат. Если внешний формат проник во все три части, новый провайдер означает изменение A, Б и В одновременно. Если A преобразует данные во внутренний контракт, новый провайдер — это новый адаптер, Б и В не меняются.

Пример: каталог игр двух источников. Первый описывает игру как {id, name}, второй как {code, title}. Неправильный подход — потребители знают об обоих форматах и выбирают поле по типу источника. Каждый новый провайдер добавляет новую ветку в каждой функции, и через год никто не скажет, сколько мест нужно поменять. Правильный подход — адаптеры преобразуют в общий контракт {key, title}, потребители о провайдере не знают. Подключение нового источника не требует регрессии всей системы.

2. Мультибрендовая платформа: определить границы вариативности

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

3–5. Конкурентные операции, топология и гарантии доставки

Пополнение баланса при двух одновременных повторах — нужна однократность эффекта и транзакционные границы. Сообщение в чате после рестарта — нужны топология хранения и восстановления. Удаление старых данных при задержке задачи — нужны срок жизни и безопасное повторное выполнение. Готовый релиз требует сигналов бизнес-сценария и условий остановки.

Опыт становится не баллами в промпте, а конкретными вопросами в постановке. Длина промпта сама по себе ничего не даёт. Если задача локальна и обратима, постановка может быть короткой. Если касается общего контракта, баланса или прав, пара уточнений до реализации меняет модель данных, транзакцию и тестовый сценарий.