Первая неделя решает, останется ли инструмент в работе. Проваливают её обычно одинаково: берут самую больную задачу, получают невнятный результат и делают вывод, что всё это не работает.
Правильный выбор — задачи, где результат проверяется машиной, а ошибка ничего не стоит. Таких у меня три.
Задача первая: воспроизвести баг тестом
Есть баг. Есть примерное понимание, где он живёт. Задача — не чинить, а написать тест, который падает по этой причине.
Пользователь с неподтверждённой почтой может открыть форму загрузки.
Напиши функциональный тест, который это воспроизводит: падает сейчас,
пройдёт после исправления. Код приложения не меняй.Почему это хорошая первая задача.
Критерий готовности машинный и однозначный: тест либо падает по нужной причине, либо нет. Не надо оценивать качество, надо посмотреть на вывод.
Цена ошибки нулевая: неудачный тест выбрасывается за секунду, в коде приложения ничего не менялось.
Результат остаётся полезным независимо от впечатлений: тест нужен в любом случае, вы его собирались писать.
И побочная польза, ради которой я советую именно это: вы сразу видите, насколько агент понимает ваш проект. Тест, написанный не в том стиле, не с теми фикстурами и не в том каталоге, — это точный список того, чего не хватает в описании проекта.
Задача вторая: покрыть один класс
Берёте класс, который давно хотели покрыть, и заказываете тесты на него. Не на модуль, не на подсистему — на один класс.
Покрой тестами класс подсчёта времени по задаче.
Смотри на соседние тесты и повторяй их стиль, фикстуры и именование.
Не меняй код класса. Если для теста нужна правка кода — остановись и скажи.Последняя строка обязательна. Без неё код класса начинает подстраиваться под тесты, и вы получаете два изменения вместо одного.
Что здесь проверяется: умеет ли агент читать существующие конвенции. Тесты — самая конвенциональная часть проекта, отклонение видно мгновенно.
Что делать с результатом: половину обычно можно принять, треть переписать, остальное выбросить. Это нормальная пропорция для первой недели, и она улучшается ровно по мере того, как вы записываете конвенции в файл контекста.
Задача третья: разобрать незнакомый кусок
Берёте часть проекта, которую не понимаете, и заказываете не описание, а ответы на вопросы со ссылками на строки.
Ответь на вопросы со ссылками file:line. Если ответа в коде нет —
напиши «не найдено», не предполагай.
1. Где начинается обработка входящего вебхука?
2. Что происходит при повторной доставке того же события?
3. Где проверяется подпись запроса?
4. Что пишется в базу и в какой момент?
5. Что произойдёт при падении обработчика на середине?Проверять такие ответы дёшево: открыл файл на строке, увидел или не увидел.
Это задача с нулевым риском вообще: ничего не меняется, всё, что вы получаете, — знание. И она же даёт вам первый черновик файла контекста: из проверенных ответов вырастает раздел «как устроено».
Подробно про такую постановку я писал в цикле про промпты. Для первой недели важно, что она безопасна и сразу показывает, где инструмент врёт.
Чего не трогать в первую неделю
Список из четырёх пунктов, каждый из которых я нарушал.
Рефакторинг. Соблазн огромный: вот же класс на восемьсот строк. Проблема в том, что у рефакторинга нет машинного критерия правильности, кроме тестов, а тестов на такой класс обычно нет. Без них вы получите дифф, про который невозможно сказать, изменилось поведение или нет.
Изменения схемы данных. Миграции нельзя дёшево откатить, а ошибка обнаруживается на проде. Это задача для того момента, когда вы уже понимаете, чего ожидать.
Обновление зависимостей. Задача выглядит механической и таковой не является: часть изменений меняет поведение, и заметить это можно только зная проект.
Всё срочное. Срочная задача не оставляет времени на проверку, а первая неделя — это как раз про проверку.
Как понять, что неделя прошла успешно
Не по количеству сделанного. По трём признакам.
У вас появился файл контекста хотя бы на двадцать строк — не выдуманный, а собранный из тех мест, где агент промахнулся.
Вы знаете, на каких задачах результат хороший, а на каких приходится переделывать. Это личное знание, оно не переносится из чужих статей.
Вы перестали удивляться. Первые дни каждое несовпадение ожиданий выглядит как открытие, к концу недели становится понятно, где системная слабость, а где ваша плохая формулировка.
Если ничего из трёх не появилось — скорее всего, задачи были слишком большими.
Отклонения
Проект без тестов. Первые две задачи отпадают в исходном виде. Замена: попросить написать первый тест на самый простой путь, вместе с настройкой окружения для тестов. Это дольше и полезнее — вы получаете инфраструктуру, без которой дальше всё равно не двинетесь.
Проект без локального запуска. Бывает, что поднять проект на машине нельзя: внешние зависимости, доступы, данные. Тогда остаётся третья задача, разбор кода вопросами, и она же становится основной на первое время. Правки без возможности проверить я в такой ситуации не советую.
Легаси, где страшно трогать всё. Начните с чтения и карты, а первым изменением сделайте характеризующий тест: тест, который фиксирует текущее поведение как есть, даже если оно кажется неправильным. Это единственный способ получить опору в коде, который нельзя менять вслепую.
Проект на незнакомом вам стеке. Порядок меняется: сначала третья задача, потом первая, вторую отложите. Вы не сможете оценить качество тестов на языке, конвенций которого не знаете, а вот проверить ответ со ссылкой на строку сможете.
