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

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

Агент (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) с тремя пунктами: как запускать тесты, ключевые соглашения кода, чего не трогать. Инструкция есть в разделе Память.
Отдайте агенту одну настоящую задачу из бэклога по схеме «план → код → тесты» и проведите полное ревью результата. Запишите, что пришлось править: это материал для улучшения ваших постановок.

Что дальше

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

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