Трек: программист

Что меняется в роли

Агент (agent) не заменяет программиста, а меняет распределение времени. Раньше значительная часть дня уходила на механическую работу: найти нужное место в коде, написать шаблонный обработчик, воспроизвести баг по логам, обновить тесты после правки. Теперь эту работу можно делегировать, а себе оставить то, что агент делает плохо: постановку задачи, архитектурные решения и проверку результата.

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

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

Основные сценарии

1. Навигация по незнакомой кодовой базе

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

Как поставить агенту:

Разберись, как в этом проекте обрабатывается оплата заказа:
с какого HTTP-эндпоинта начинается путь, через какие сервисы
проходит запрос, где вызывается платёжный шлюз и где результат
пишется в базу. Дай список файлов с путями и краткую схему
потока данных. Код не меняй.

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

2. Реализация фичи по постановке

Задача. Есть описание фичи, нужен работающий код с тестами.

Как поставить агенту. Не просите «сделай фичу» одним сообщением. Разбейте на план → код → тесты, как описано в рабочем цикле:

Нужно добавить ограничение частоты запросов к /api/export:
не больше 5 запросов в минуту на пользователя, при превышении отдавай 429.
Сначала предложи план: какие файлы затронем, где хранить счётчики,
как впишемся в существующий middleware. Код пока не пиши.

После согласования плана: «План принят, реализуй шаг 1». Так вы ловите неверное направление до того, как агент написал 500 строк не туда.

Как проверить. Прогнать тесты обязательно, но недостаточно: агент мог написать тесты под своё же неверное понимание задачи. Прочитайте дифф как чужой пул-реквест и запустите фичу руками на паре сценариев, включая граничный: шестой запрос за минуту действительно получает 429?

3. Отладка по стек-трейсу и логам

Задача. В проде ошибка, есть стек-трейс и фрагмент логов.

Как поставить агенту:

Вот стек-трейс и логи за минуту до ошибки (ниже). Пройди по коду
от точки падения вверх по стеку и проверь, при каких входных
данных null мог оказаться в user.subscription. Сформулируй
гипотезу о причине, предложи минимальный фикс и тест,
воспроизводящий баг.

[стек-трейс]
[логи]

Как проверить. Требуйте воспроизводящий тест: он должен падать до фикса и проходить после. Если агент не может воспроизвести баг тестом, его версия о причине остаётся только версией, даже если звучит убедительно.

4. Рефакторинг с тестовой страховкой

Задача. Переструктурировать код, не меняя поведение.

Как поставить агенту:

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

Как проверить. Порядок важен: сначала тесты зафиксированы на старом коде, потом рефакторинг, и те же тесты проходят на новом. Если агент правит тесты одновременно с кодом, страховка не работает: откатывайте и начинайте заново.

5. Код-ревью агентом как вторая пара глаз

Задача. Получить свежий взгляд на свой код до того, как его увидят коллеги.

Как поставить агенту:

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

Как проверить. Замечания агента остаются гипотезами, а не вердиктами. Часть окажется ложными срабатываниями: проверьте каждое по коду, прежде чем править. И помните: агент дополняет ревью коллег, а не заменяет его, ведь человек знает контекст продукта, которого нет в репозитории.

6. Генерация тестов

Задача. Покрыть тестами существующий модуль.

Как поставить агенту:

Напиши юнит-тесты для validateCoupon в src/coupons/validate.ts.
Обязательно покрой: просроченный купон, купон на нулевую сумму,
повторное применение, купон в другой валюте. Используй принятый
в проекте стиль (посмотри соседние *.test.ts). Каждый тест должен
проверять поведение, а не детали текущей реализации.

Как проверить. Худший тест тот, что проходит всегда. Выборочно сломайте код (поменяйте > на >=, закомментируйте проверку) и убедитесь, что тесты это ловят. Если после поломки всё зелёное, значит, тесты декоративные.

Чего остерегаться

Правдоподобный неверный код. Агент пишет код, который выглядит профессионально: осмысленные имена, аккуратная структура, комментарии. Это никак не гарантирует корректность. Красивый код проверяют так же строго, как уродливый.
Выдуманные API. Галлюцинация (hallucination) в коде выглядит как метод библиотеки, которого не существует, или параметр, который называется иначе. Компилируемые языки ловят часть таких ошибок, а динамические их пропускают. Сомневаетесь? Сверяйтесь с документацией, а не с уверенным тоном агента.
Деградация собственного понимания. Если месяцами принимать код не читая, вы перестанете понимать собственную систему и однажды не сможете ни проверить агента, ни починить прод без него. Читайте диффы. Иногда пишите руками. Понимание кодовой базы остаётся вашим главным профессиональным активом.

Маршрут по сайту для программиста

Что такое агент и Харнес: как устроен инструмент, с которым вы работаете.
Токены и контекстное окно: почему агент «забывает» середину длинной сессии.
Промптинг и Контекст-инжиниринг: как ставить задачи, чтобы получать нужное с первого-второго раза.
Рабочий цикл и Проверка результатов: ядро ежедневной практики.
Память и Скилы: как научить агента соглашениям вашего проекта.
Обзор харнесов: выбор конкретного инструмента.

С чего начать на этой неделе

Установите один харнес (начните с обзора) и дайте ему первую задачу не на код, а на навигацию: «объясни, как устроен модуль X». Это безопасно и сразу показывает уровень инструмента.
Заведите в рабочем проекте файл памяти (CLAUDE.md или AGENTS.md) с тремя пунктами: как запускать тесты, ключевые соглашения кода, чего не трогать. Инструкция есть в разделе Память.
Отдайте агенту одну настоящую задачу из бэклога по схеме «план → код → тесты» и проведите полное ревью результата. Запишите, что пришлось править: это материал для улучшения ваших постановок.

Что дальше

Рабочий цикл: как строится сессия с агентом от постановки до приёмки.
Типичные ошибки: грабли, на которые наступают почти все новички.

Автор учебника: Шахматов Алексей