Чем лучше AI-агент умеет программировать, тем опаснее слишком расплывчатая постановка. Модель не любит пустоты: если ей не хватает информации, она пытается восстановить ее по контексту и общим практикам. Для учебного примера это удобно. Для живого проекта такой энтузиазм может привести к тому, что агент уверенно исправит проблему, которой на самом деле не было.
Не описывать причину бага, если мы ее не знаем
Одна из самых полезных привычек - отделять наблюдение от гипотезы. Если кнопка уезжает на мобильном экране, это факт. Если мы пишем агенту, что проблема точно вызвана неправильным flex-контейнером, не увидев код, мы уже навязали диагноз.
Хорошая постановка говорит: "сейчас происходит вот это", а техническую причину предлагает определить по проекту. Конкретную архитектуру стоит указывать только тогда, когда она действительно известна из файлов или документации.
Сначала описать текущее и желаемое поведение
Агенту нужен контраст. Что пользователь видит сейчас? Как должно быть после изменения? На каких состояниях это проявляется? Такая пара часто полезнее длинного технического эссе.
Например: сейчас стрелка в раскрытой панели показывает вниз, а должна показывать вверх, потому что действие пользователя в этом состоянии - свернуть. Это достаточно конкретно, но не диктует способ реализации.
Отдельно зафиксировать то, что нельзя сломать
Локальная правка почти всегда существует внутри уже принятой системы. Если агенту не сказать, что остальное поведение считается корректным, он может начать рефакторинг соседних частей в попытке сделать решение "чище".
Поэтому в задачах мы прямо указываем границы: не менять размер машины при загрузке, не трогать существующий скролл, сохранить текущие состояния карточек, не перестраивать структуру данных без необходимости. Это не микроменеджмент, а описание области изменений.
Критерий приемки должен быть видимым
Фраза "исправить адаптив" слишком широка. Лучше сформулировать то, что можно проверить: на мобильной ширине элементы не выходят за экран, порядок блоков сохраняется, кнопка остается доступной, горизонтального скролла нет.
Так агент получает конкретную цель, а человек после выполнения понимает, что именно проверять.
Документация проекта важнее универсальных best practices
Модель обучена на огромном количестве типовых решений и закономерно пытается использовать их. Но наш проект может сознательно принимать другое решение. Например, иметь собственную систему токенов, конкретный формат Epic или особую архитектуру Builder.
Поэтому чем важнее проектное правило, тем меньше оно должно зависеть от того, догадается ли агент о нем. Такие вещи нужно выносить в устойчивую документацию и давать вместе с задачей.
AI лучше работает в роли исполнителя понятного решения
Это не означает, что агенту нельзя поручать исследование или проектирование. Можно. Но тогда именно исследование должно быть задачей: изучить варианты, показать последствия и предложить решение. Нельзя незаметно смешивать это с задачей "починить конкретный баг".
Когда тип работы назван явно, легче контролировать, где модель должна следовать правилам, а где от нее действительно ждут самостоятельного поиска.
Мы постепенно перестали писать постановки как инструкции предполагаемому программисту и начали писать их как проверяемое описание изменения. Парадоксально, но чем меньше мы выдумываем за агента технических деталей, тем точнее он обычно работает с реальным проектом.