Перейти к содержимому

Роль разработчика

Агент закрывает всё больше механической работы, и центр тяжести смещается. Меньше времени уходит на набор кода, больше на три вещи: точно поставить задачу, выбрать подходящий инструмент и проверить результат.

Отсюда требование, которого раньше не было: нужно знать, что вообще существует. Какие подходы бывают, какие навыки и MCP-серверы решают твою задачу, где у агента слабые места. Иначе выбирать не из чего, и остаётся только соглашаться с тем, что он предложил.

Дело не в недоверии: агент одинаково уверенно выдаёт и верный результат, и ошибочный. Отличить одно от другого можно только проверкой.

Этап Твоя часть
До начала Рамки задачи: что делаем, чего не делаем, какие ограничения
Постановка Способ проверки: тест, сборка, метрика, эталон
По ходу Ранняя правка курса, пока контекст не забит неудачными попытками
На выходе Проверка по задаче, а не по диффу: решено ли то, что просили

На задаче крупнее одного файла первый шаг это не запрос «сделай», а разговор. Пусть агент задаёт вопросы, пока не исчезнут развилки.

Хочу [кратко]. Расспроси меня инструментом AskUser: реализация, интерфейс,
крайние случаи, компромиссы. Очевидное пропускай, разбирай сложные места.
Когда всё обсудим, запиши спецификацию в SPEC.md.

Хорошее интервью отличается от плохого содержанием вопросов. Если агент спрашивает про то, что и так видно в коде, интервью пустое. Ценные вопросы это те, ответа на которые у тебя ещё нет: что делать при повторном запросе, кто владелец данных, что важнее в конфликте требований.

На выходе нужна спецификация, которая называет файлы и интерфейсы, явно перечисляет, что вне объёма, и заканчивается шагом проверки. Выполнять её лучше в новой сессии с чистым контекстом.

Готовые наборы навыков автоматизируют этот цикл, см. Подборку расширений.

Второй источник расхождений это термины. Если у сущности в голове, в задаче и в коде три разных имени, агент будет каждый раз переспрашивать или додумывать.

Зафиксируй словарь предметной области там, где агент его прочитает: в WAIBEE.md или отдельном файле, подключённом через @путь. Выигрыш двойной: объяснения становятся короче, а значит дешевле по контексту, и именование в коде перестаёт разъезжаться. Принятые решения с обоснованием держи рядом, чтобы агент не переизобретал их заново.

Что проверяешь Типичная ошибка агента
Та ли задача решена Сделана соседняя, спецификация прочитана по диагонали
Крайние случаи Пустой ввод, таймаут, повтор, одновременный доступ
Границы доверия Нет проверки входных данных, права проверяются не на том слое
Причина, а не симптом Исключение проглочено, поверх бага навешан повтор
Повторное использование Написан свой хелпер там, где рядом лежит готовый
Тесты Тест подогнан под реализацию: проверяет вызовы вместо поведения
Объём Заодно переписаны соседние файлы, о которых не просили
Лишние абстракции Интерфейс с одной реализацией, конфиг для константы
Доказательства Сказано «готово» без вывода тестов и команд

Последний пункт самый дешёвый в применении. Проси не отчёт, а вывод: что запускал и что вернулось. Читать вывод быстрее, чем перепроверять самому.

Тот же агент, который писал код, плохой проверяющий: он защищает собственное решение. Отдай проверку субагенту или второй сессии, где в контексте только дифф и критерии.

Свежим субагентом проверь дифф этой ветки против SPEC.md: все ли пункты
реализованы, покрыты ли перечисленные крайние случаи тестами, не затронуто
ли лишнее. Отмечай расхождения, а не вкусовые придирки к стилю.

Оговорка: проверяющий, которого попросили найти проблемы, найдёт их всегда, даже в исправной работе. Если гнаться за каждым замечанием, получится обратное: лишние слои, защитный код и тесты на невозможные случаи. Прямо укажи, что считать находкой, остальное отмечай как необязательное.

Тесты и метрики проверяют то, что в них описано. Мимо них проходит:

  • Задача решена аккуратно, но это не та задача.
  • Решение верное, но не вписывается в то, куда движется проект.
  • Метрика улучшилась за счёт того, чего в метрике нет, см. Autoresearch.
  • Цена поддержки: код работает, но через полгода в нём никто не разберётся.

Эти четыре темы остаются за тобой, и именно на них стоит тратить внимание, сэкономленное на наборе кода.