«Сделай хорошо»: почему ИИ выдаёт лишнее и во что это обходится
Год назад я ставил задачи ИИ-агенту одной фразой: «сделай хорошо, используй лучшие практики». Агент старался. Получалась система с запасом прочности на десять лет вперёд, которую потом было дорого менять.
Почему «хорошо» ничего не значит
У любой задачи есть несколько правильных решений. Одно быстрее доводит продукт до первых клиентов. Другое дешевле переделывать через месяц. Третье выдержит нагрузку в сезонный пик. Четвёртое переживёт падение сервера без потери заказов.
Каждое из них качественное. В своих условиях.
| Что важно | Что получаете | Чем платите |
|---|---|---|
| Быстрый запуск | Проверяете спрос за неделю | Редкие случаи обрабатываете руками |
| Дешёвые правки | Новая функция стоит копейки | Часть универсальности откладывается |
| Надёжность | Сбой не роняет заказы | Больше проверок и состояний |
| Нагрузка | Держите пик | Время на оптимизацию и железо |
Когда в задаче написано «сделай хорошо», приоритет между этими колонками не задан. Исполнитель расставляет его сам.
Что происходит внутри
Модель не выбирает решение из каталога готовых. Она продолжает текст по одному кусочку, каждый раз прикидывая, что вероятнее идёт дальше. Если критерии пустые, вероятнее всего идёт то, что чаще встречается в интернете: архитектура крупной компании со всеми слоями, очередями и повторными попытками.
В чате вайбкодеров разбирали свежий случай. Агенту поручили парсинг предложений, задача на четыре сотни строк руками. Он выдал четырнадцать тысяч строк с защитой токенов доступа и системой прав. Формально грамотно. Для гипотезы, которую надо проверить за вечер, это балласт.
Цена всплывает позже. Вы просите добавить одну кнопку в основной сценарий, и агент идёт менять схему базы, доступ к данным, очередь, обработчик, права и тесты. Функция на полдня разрастается до недели.
Контракт из четырёх пунктов
Перед реализацией агенту нужно ровно четыре вещи. Цель этапа. Жёсткие ограничения. Приоритеты по порядку. Способ проверки.
Выглядит это так:
Цель этапа: первые десять клиентов проходят заявку целиком
и оставляют отзыв.
Жёсткие ограничения: платежи, персональные данные и доступы
защищены без компромиссов. Масштабирование добавляем после
подтверждённой нагрузки.
Критерии по приоритету: время до запуска, стоимость будущих
правок, безопасность, надёжность, производительность.
Предложи три варианта. Для каждого: польза, цена, риски
и сигнал, после которого понадобится усложнение.
До кода составь план проверки основного сценария.
После реализации запусти проверку и верни фактический вывод.
Разница между этим текстом и фразой «сделай хорошо» измеряется неделями лишней работы.
Мысль про контракт я подсмотрел у Сережи Риса в разборе «Почему агент не может выбрать лучший код». Он объясняет её с инженерной стороны. Мне важнее сторона заказчика: тот же принцип работает с живым подрядчиком, которому вы говорите «ну сделайте нормальный сайт».
Отдельный пункт: чего делать не нужно
В каждое ТЗ мы добавляем границы. Не трогать соседние модули. Не рефакторить попутно. Не добавлять функции сверх списка. Не деплоить.
Звучит избыточно, пока не столкнёшься с последствиями. Больше всего ущерба приносит инициатива за пределами задачи, а вовсе не ошибка внутри неё. Агент видит рядом кривой код и чинит его, потому что старается. В результате ломается то, что работало.
«Готово» не доказательство
Отчёт исполнителя про успех проверять надо отдельно. Модели пишут «всё работает» с одинаковой уверенностью в обоих случаях.
У нас приёмку делает второй агент на другой модели. Он идёт по пунктам определения готовности, требует сырые выводы команд и не верит пересказу. Работает это так себе, пока не начнёшь требовать доказательства правильно.
Живой пример из августа. Дорабатывали контур расчёта денег в CRM для автосервиса, четыре круга приёмки. На третьем круге исполнитель добавил тест на состояние гонки, тест проходил, все довольны. Верификатор попросил прогнать его со снятым фиксом. Тест снова прошёл. Оказалось, тестовый стенд молча ломал расчёт, и сравнение всегда возвращало ложь. Тест защищал пустоту.
Отсюда правило: тест, добавленный на найденный баг, обязан упасть при откате исправления. Иначе он декорация.
Что это дало
Переделок стало меньше, а те, что остаются, дешевле. Мы держим лимит: две доработки одним исполнителем, дальше задачу берёт другой с чистым контекстом. Два возврата подряд означают, что проблема в постановке задачи, и правим мы тогда ТЗ, а не код.
Самое неожиданное в этой истории: почти все возвраты касались непокрытых пунктов приёмки. Ни один не был про вкус или красоту кода. Спека без проверяемых критериев прошла бы первый круг спокойно, и расчёт денег уехал бы на прод вместе с гонкой.
Если ставите задачи нейросети и получаете громоздкий результат, начните с одного вопроса: что в вашем ТЗ написано про цену ошибки и срок запуска. Обычно там пусто.
Напишите @eldarmarketing — обсудим вашу задачу.