Роль разработчика
Агент закрывает всё больше механической работы, и центр тяжести смещается. Меньше времени уходит на набор кода, больше на три вещи: точно поставить задачу, выбрать подходящий инструмент и проверить результат.
Отсюда требование, которого раньше не было: нужно знать, что вообще существует. Какие подходы бывают, какие навыки и MCP-серверы решают твою задачу, где у агента слабые места. Иначе выбирать не из чего, и остаётся только соглашаться с тем, что он предложил.
Дело не в недоверии: агент одинаково уверенно выдаёт и верный результат, и ошибочный. Отличить одно от другого можно только проверкой.
Что делаешь ты
Заголовок раздела «Что делаешь ты»| Этап | Твоя часть |
|---|---|
| До начала | Рамки задачи: что делаем, чего не делаем, какие ограничения |
| Постановка | Способ проверки: тест, сборка, метрика, эталон |
| По ходу | Ранняя правка курса, пока контекст не забит неудачными попытками |
| На выходе | Проверка по задаче, а не по диффу: решено ли то, что просили |
Интервью до кода
Заголовок раздела «Интервью до кода»На задаче крупнее одного файла первый шаг это не запрос «сделай», а разговор. Пусть агент задаёт вопросы, пока не исчезнут развилки.
Хочу [кратко]. Расспроси меня инструментом AskUser: реализация, интерфейс,крайние случаи, компромиссы. Очевидное пропускай, разбирай сложные места.Когда всё обсудим, запиши спецификацию в SPEC.md.Хорошее интервью отличается от плохого содержанием вопросов. Если агент спрашивает про то, что и так видно в коде, интервью пустое. Ценные вопросы это те, ответа на которые у тебя ещё нет: что делать при повторном запросе, кто владелец данных, что важнее в конфликте требований.
На выходе нужна спецификация, которая называет файлы и интерфейсы, явно перечисляет, что вне объёма, и заканчивается шагом проверки. Выполнять её лучше в новой сессии с чистым контекстом.
Готовые наборы навыков автоматизируют этот цикл, см. Подборку расширений.
Общий язык проекта
Заголовок раздела «Общий язык проекта»Второй источник расхождений это термины. Если у сущности в голове, в задаче и в коде три разных имени, агент будет каждый раз переспрашивать или додумывать.
Зафиксируй словарь предметной области там, где агент его прочитает: в WAIBEE.md или отдельном файле, подключённом через @путь. Выигрыш двойной: объяснения становятся короче, а значит дешевле по контексту, и именование в коде перестаёт разъезжаться. Принятые решения с обоснованием держи рядом, чтобы агент не переизобретал их заново.
Что смотреть в результате
Заголовок раздела «Что смотреть в результате»| Что проверяешь | Типичная ошибка агента |
|---|---|
| Та ли задача решена | Сделана соседняя, спецификация прочитана по диагонали |
| Крайние случаи | Пустой ввод, таймаут, повтор, одновременный доступ |
| Границы доверия | Нет проверки входных данных, права проверяются не на том слое |
| Причина, а не симптом | Исключение проглочено, поверх бага навешан повтор |
| Повторное использование | Написан свой хелпер там, где рядом лежит готовый |
| Тесты | Тест подогнан под реализацию: проверяет вызовы вместо поведения |
| Объём | Заодно переписаны соседние файлы, о которых не просили |
| Лишние абстракции | Интерфейс с одной реализацией, конфиг для константы |
| Доказательства | Сказано «готово» без вывода тестов и команд |
Последний пункт самый дешёвый в применении. Проси не отчёт, а вывод: что запускал и что вернулось. Читать вывод быстрее, чем перепроверять самому.
Проверка чужими глазами
Заголовок раздела «Проверка чужими глазами»Тот же агент, который писал код, плохой проверяющий: он защищает собственное решение. Отдай проверку субагенту или второй сессии, где в контексте только дифф и критерии.
Свежим субагентом проверь дифф этой ветки против SPEC.md: все ли пунктыреализованы, покрыты ли перечисленные крайние случаи тестами, не затронутоли лишнее. Отмечай расхождения, а не вкусовые придирки к стилю.Оговорка: проверяющий, которого попросили найти проблемы, найдёт их всегда, даже в исправной работе. Если гнаться за каждым замечанием, получится обратное: лишние слои, защитный код и тесты на невозможные случаи. Прямо укажи, что считать находкой, остальное отмечай как необязательное.
Что не поймает автоматика
Заголовок раздела «Что не поймает автоматика»Тесты и метрики проверяют то, что в них описано. Мимо них проходит:
- Задача решена аккуратно, но это не та задача.
- Решение верное, но не вписывается в то, куда движется проект.
- Метрика улучшилась за счёт того, чего в метрике нет, см. Autoresearch.
- Цена поддержки: код работает, но через полгода в нём никто не разберётся.
Эти четыре темы остаются за тобой, и именно на них стоит тратить внимание, сэкономленное на наборе кода.