Поручение целиком: агент в редакторе

Что меняется, когда место выбирает агент

Третья скорость: вы называете задачу, а место выбирает агент. Это единственное отличие от второй скорости, и из него следует всё остальное.

Пока вы ждёте, агент ходит по кругу: посмотрел — решил — сделал — проверил. Не сошлось — заново. Круг может повториться десять раз, и это нормально: именно этим агент отличается от одного ответа на один вопрос.

У круга нет своего признака готовности. Агент останавливается, когда решит, что сделал, — а не когда сделал. Это важнейшее свойство третьей скорости, и из него растут все её слабости.

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

Отсюда правило, которое звучит занудно и стоит всей главы: размер поручения определяет, сможете ли вы его принять. Задача на три файла читается за десять минут. Задача на пятнадцать файлов не читается — просматривается, а просмотренное поручение это непринятое поручение.

И третье свойство, приятное: агент в редакторе видит результат своих действий. Он может запустить код, прочитать ошибку, поправить и запустить снова — и часто именно это делает третью скорость полезной. Задача «почини вот эту падающую проверку» решается за один заход, потому что у агента есть обратная связь.

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

Поручение из четырёх строк

Теперь как ставить задачу. Поручение — четыре строки, и каждая закрывает свою беду.

Что должно получиться. Не действие, а состояние: не «почини отчёт», а «в отчёте появилась колонка процента выполнения плана». Разница в том, что второе можно проверить, а первое — нет.

Где искать, если знаете. «Начни с services/report.js» экономит половину его работы и заодно убирает главный риск третьей скорости: он не найдёт нужное место и сделает в похожем.

Чего не делать. «Формат существующих колонок не меняй», «зависимостей не добавляй», «ничего за пределами отчёта не трогай». Три строки, каждая из которых снимает класс сюрпризов.

Как проверить. «Должно совпасть с итогом внизу», «старые отчёты пересчитываться не должны». Это и ваш признак готовности, и его — он может проверить сам.

Теперь про две противоположные ошибки в размере задания.

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

Слишком крупно. «Сделай раздел отчётов» — это не задача, а направление. Агент возьмётся, сделает что-то на пятнадцать файлов, и принять это будет невозможно.

И приём, который стоит сделать привычкой на третьей скорости: сначала план, потом работа.

«Не правь пока ничего — скажи, какие файлы тронешь и что в каждом изменишь» стоит полминуты и даёт то, чего иначе не будет вовсе: возможность возразить до того, как что-то сделано. В половине случаев из плана сразу видно, что он не нашёл нужное место или собирается тронуть лишнее.

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

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

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

Пока он работает

Агент работает. Вопрос, который встаёт сразу: смотреть или уйти?

Ответ зависит от того, сколько шагов он сделает, и делится довольно чётко.

Смысл смотреть — не в контроле, а в одном моменте: когда видно, что он пошёл не туда. Он открыл не тот файл, начал править тест вместо кода, полез в соседний модуль. В этот момент остановка стоит секунду, а через три минуты — уже придётся откатывать сделанное.

Теперь про то, чего делать не стоит, пока он работает, и это неочевидно.

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

Не давать второе поручение в те же места. Два агента в одном файле — отдельная тема одиннадцатого урока, и там же сказано, почему это не работает без разделения.

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

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

Приёмка поручения

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

1. Список файлов. Те ли тронуты? Лишний файл — вопрос раньше, чем открыт первый дифф. Часто этого шага достаточно, чтобы отказаться: агент не нашёл нужное место и сделал в похожем, и видно это по списку, а не по коду.

2. Размер. Столько ли, сколько вы ждали? Сорок строк на задачу о трёх — сигнал, а не мелочь: значит, он сделал больше, чем просили, и надо понять, что именно.

3. Смысл по каждому файлу. Только теперь — чтение. И читают дифф, а не итоговый код: причёсанное по дороге видно только в изменениях.

4. Запуск. Не «выглядит верно», а «работает». Тот самый признак готовности, который вы назвали в поручении, — им и проверяют.

Колонка добавлена — это то, о чём просили. А соседняя переименована, потому что «так короче и таблица лучше влезает»: решение разумное, никем не заказанное и ломающее всех, кто разбирает выгрузку по именам колонок. В итоговом коде таблица выглядит опрятнее прежней.

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

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

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

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

И совсем последнее — про то, что делать с удачным поручением. Запишите его. Не фразу целиком, а то, что в ней сработало: какие границы вы назвали, какой файл указали, каким признаком готовности воспользовались.

Через неделю похожая задача придёт снова, и восстанавливать это по памяти дороже, чем прочитать три строки. А через месяц накопленный список удачных поручений сам покажет, чего проекту не хватает: если в каждом втором вы пишете «обработку ошибок делай как в такой-то файл», значит это место правилам проекта, а не поручению. Так шестой урок и вырастает из этого.