Почему агент не может выбрать лучший код
Как настроить агента, чтобы он всегда писал код без ошибок? Этот вопрос постоянно возвращается в разных формулировках. Иногда ищут правильный промпт, иногда CLAUDE.md, иногда скилл с лучшими практиками.
Ответ один: это невозможно.
У любой задачи есть много допустимых реализаций. Один вариант быстрее запустить. Другой легче поддерживать. Третий выдержит больше нагрузки. Четвёртый лучше переживёт сбой, но потребует больше времени на каждое следующее изменение. Все они могут соответствовать хорошим практикам.
Слово «лучший» ничего не выбирает. Проект должен сообщить, что для него важно сейчас.
Надёжная система без единого пользователя
Представим продукт, которым пока никто не пользуется. Человек просит агента сразу сделать всё максимально надёжно. Агент добавляет роли и права, очередь задач, повторные попытки, журнал событий, отдельные состояния и обработку каждого возможного сбоя.
Каждое решение выглядит разумно. Для каждого найдётся статья с лучшими практиками.
На следующий день в продукт надо добавить одну кнопку. На уровне пользователя это маленькая функция. Агенту приходится изменить состояние, права доступа, событие, очередь, восстановление после ошибки и тесты. Вместо одного изменения появляется десять связанных правок.
Код всё равно пишет агент. Цена приходит через процесс вайбкодинга. Агент трогает больше файлов, дольше держит контекст, чаще задевает соседние части. Простая функция занимает отдельную сессию, несколько проверок и новые попытки починить созданную им же сложность.
При этом продукт ещё никто не открывал.
У двух подходов есть понятная цена:
| Подход | Что даёт | Чем платим |
|---|---|---|
| Максимальная надёжность заранее | Повторные попытки, восстановление, подробный контроль сбоев | Долгий запуск, больше состояний, дорогие изменения |
| Простое решение для текущей цели | Быстрый запуск, дешёвые изменения, ранняя обратная связь | Часть редких сбоев придётся разбирать вручную |
Простота не отменяет базовую безопасность, сохранность оплат и защиту ценных данных. Уровень остальных гарантий зависит от реальной цены ошибки.
Почему «надёжнее» не выбирает за нас
Когда критериев нет, самый надёжный вариант кажется естественным. Он звучит безопасно и профессионально.
Проблема в том, что надёжность тоже состоит из компромиссов. Очередь повторит неудачное действие и добавит новые состояния. Резервирование переживёт отказ одного компонента и усложнит всю систему. Строгие ограничения снизят один риск и замедлят каждую новую функцию.
В AWS Well-Architected Framework предлагают сначала определить факторы оценки: стоимость, надёжность, безопасность и производительность. Затем сравнить последствия решения экспериментом или прототипом.
Лучшие практики работают как набор условий. Если сбой стоит денег, нужны дополнительные гарантии. Если главная опасность проекта состоит в том, что он никому не нужен, ценнее скорость проверки идеи.
Уровень выше кода
Вопрос о коде появляется слишком рано. Сначала нужна цепочка:
цель продукта → поведение пользователя → проверяемый результат → техническое решение
Для проекта без пользователей цель может звучать так: «пять человек открыли продукт, прошли главный сценарий и захотели вернуться». Теперь у агента появляется основание для выбора. Скорость запуска помогает проверить цель. Масштабирование на миллион пользователей пока ничего не проверяет.
Я уже формулировал это короче: тесты от пользователей важнее идеального стека. Реальные вопросы становятся видны после запуска. До него мы оптимизируем предположения.
Поэтому я поднимаюсь на уровень цели и только потом возвращаюсь к реализации. Что должно произойти с человеком? Как мы это увидим? Какая ошибка помешает проверить гипотезу? Какие ограничения обязательны уже сегодня?
Ответы превращаются в критерии для агента.
Что даёт скилл с лучшими практиками
Такой скилл всё равно полезен. Я делаю скиллы из документации и накопленного опыта, чтобы агент не исследовал одну тему заново в каждом проекте.
Скилл может:
- собрать известные варианты;
- показать плюсы, минусы и условия применения;
- напомнить про риски;
- предложить проверки;
- сохранить удачное решение для похожих задач.
Ему не хватает одного: цели конкретного продукта. Без неё агент выберет допустимый вариант и убедительно защитит его. Инструкция «спорь со мной» добавит уверенности в ответе. Критерий правильности от этого не появится.
Магического промпта, который заставит LLM всегда выбирать верно, не существует. Правила направляют модель. Результат подтверждает только обратная связь.
Как поставить такую задачу агенту
Перед работой я задаю пять опор:
- Цель продукта на текущем этапе.
- Поведение пользователя, которое подтвердит цель.
- Ошибки с действительно высокой ценой.
- Ограничения по времени и ресурсам.
- Способ проверки результата.
После этого агент сравнивает решения. Если критерии конфликтуют, он показывает конфликт до реализации. Решение остаётся за мной.
Объяснение агента ничего не доказывает
Даже сильная аргументация остаётся текстом. Модульный тест проверяет отдельное правило. Браузерный сценарий проходит путь пользователя целиком. Первые пользователи показывают, решает ли продукт их задачу.
Anthropic тоже рекомендует сначала определить конкретные и измеримые критерии успеха. Эвалы проверяют заранее сформулированные ожидания.
Свой простой контур я описал в статье про эвалы для вайбкодера.
В работе с агентами постановка цели и проверка результата остаются на человеке. Это самая сложная часть вайбкодинга. Агент пишет код, ищет практики, сравнивает варианты и запускает проверки. Человек определяет, куда должен прийти продукт.
Весь процесс укладывается в одну последовательность:
цель → критерии → варианты → выбор → проверка
Скилл с лучшими практиками делает варианты сильнее. Цель продукта определяет, какой из них подходит сейчас. Когда появятся пользователи, нагрузка и реальные сбои, критерии изменятся. Агент пересоберёт решение под новую реальность.
Подписаться на обновления — @sereja_tech