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