Запуск и первое знакомство
Разберём первый заход целиком, без пропусков. Он занимает несколько минут, и в нём нет ничего сложного, — но пара привычек, заложенных здесь, определяет, будет ли работа с агентом приятной или мучительной.
Шаг первый: перейти в папку проекта. Агент работает с тем каталогом, из которого запущен. Это не мелочь: запущенный из домашней папки, он увидит вашу домашнюю папку, а не проект, и честно попытается что-нибудь в ней сделать.
cd ~/projects/shop
codexПосле запуска агент один раз спрашивает, под какой учётной записью работать, и запоминает ответ. Дальше вы видите поле ввода — и всё. Никакого настроечного экрана, никаких обязательных шагов.
Шаг второй, который пропускают все: посмотреть, где вы находитесь. У агента есть команда состояния. Она показывает рабочий каталог, выбранную модель, режим прав — то есть ровно то, от чего зависит, что сейчас произойдёт.
/statusШаг третий: убедиться, что есть куда откатываться. Прежде чем поручать первую задачу, зафиксируйте текущее состояние проекта — сделайте коммит, если есть что коммитить. Тогда любой результат агента снимается одной командой, и вам не придётся разбирать, где ваши изменения, а где его.
git status
git add -A && git commit -m "перед работой агента"Это привычка, которая окупается не сразу, а в тот единственный день, когда агент перепишет то, что вы час писали руками. Стоит она пять секунд.
Шаг четвёртый: поручить задачу. Просто напишите её словами в поле ввода. Никакого особого языка, никаких ключевых слов. Как именно формулировать, чтобы получалось с первого раза, — тема следующего урока; здесь достаточно сказать, что писать надо как коллеге, а не как поисковой строке.
Стоит сказать и о том, чего на этом шаге делать не надо, потому что новички делают это часто. Не надо настраивать агента «под себя» до первой задачи: перебирать модели, выставлять права пошире, писать длинный список предпочтений. Всё это имеет смысл ровно тогда, когда вы столкнулись с неудобством, — а до первой задачи вы не знаете, с каким именно. Настройка вслепую обычно выливается в права шире нужного и в набор предпочтений, половина которых противоречит друг другу.
Последнее, что полезно сделать в самом начале работы с проектом: попросить агента завести файл правил. У него есть для этого отдельная команда — он осмотрит проект, поймёт, чем он собирается и чем проверяется, и напишет черновик. Черновик придётся дописать руками, но начинать с пустого листа не придётся.
/initЧто видно в журнале работы
Вы написали задачу и нажали ввод. Дальше начинается то, что отличает агента от чата: он не отвечает, а работает, и вы видите его работу шаг за шагом.
Журнал показывает действия, а не мысли. Поиск по слову. Открытый файл. Запущенная команда и её вывод. Правка. Это ровно то, что вам нужно: мысли агента вы всё равно не проверите, а действия — можете.
Смотреть на этот журнал в первые недели полезно, и не из недоверия. Из него видно три вещи, которых больше негде взять.
Первая: нашёл ли он нужное место. Если вы просили поправить расчёт скидки, а агент открывает файл настроек, дальше можно не ждать — проще остановить его и назвать место самому.
Вторая: чем он проверяет себя. Хороший признак — агент запускает тесты или хотя бы саму программу. Плохой — он правит код и сразу пишет «готово», ничего не запустив. Во втором случае «готово» означает «я так думаю».
Третья, самая ценная: что он сделал, когда что-то не сошлось. Посмотрите на схему выше: тест упал — и агент поправил тест. Это законный ход ровно в одном случае: если тест действительно был неправильный. Во всех остальных это подгонка, и она проходит незамеченной у того, кто читает только сводку.
Есть и практическая мелочь: агента можно прервать. Если видно, что он пошёл не туда, не обязательно ждать конца — прерывание останавливает работу, и уже сделанные правки остаются на месте, откуда их видно и откуда их легко снять.
Полезно понимать и обратное: чего в журнале нет. Там нет причин. Строка «открыл файл заказов» не объясняет, почему именно его, — и если выбор был неверный, из журнала это видно только вам, потому что проект знаете вы. Там нет и оценки: агент не пишет «кажется, я делаю ерунду». Журнал — протокол, а не размышление, и читать его надо как протокол: что было сделано, в каком порядке, с каким результатом.
И ещё одна привычка, которая экономит часы: если в журнале агент второй раз подряд запускает одну и ту же команду и получает ту же ошибку, он застрял. Дальше он, скорее всего, будет ходить по этому кругу, пока не упрётся в ограничение. Дешевле прервать его и сказать, в чём дело, — почти всегда причина видна вам и невидима ему.
Сессия: одна задача — один разговор
Разговор с агентом называется сессией. Внутри одной сессии он помнит всё, что было сказано и сделано: ваши поручения, свои правки, вывод команд. Между сессиями — не помнит ничего.
Из этого следует правило, которое звучит скучно и экономит больше всего времени: одна задача — одна сессия. Закончили с расчётом скидки — начните новый разговор для следующей задачи, даже если он про тот же проект.
Причин две, и обе практические.
Первая: окно контекста конечно. Каждое сообщение, каждый прочитанный файл, каждый вывод тестов занимает в нём место. Когда место кончается, самое старое вытесняется — а самое старое это, как правило, ваши условия, заданные в первом сообщении. Признак всегда один и тот же: агент перестаёт соблюдать то, о чём вы просили в начале. Просили не трогать соседние модули — начал трогать. Просили писать тесты — перестал.
Вторая: разговор засоряется. Три отменённых подхода, два неудачных варианта и одно «нет, давай наоборот» лежат в сессии и тянут ответ к себе. Агент честно учитывает их все — включая те, от которых вы отказались десять минут назад.
Есть и приём для длинной работы, которую в одну сессию не уместить. Прежде чем начинать новую, попросите итог: «собери в десяти пунктах, что мы сделали, к чему пришли и какие правила действуют». Полученный список кладётся в первое сообщение новой сессии — и она начинается не с нуля, а с накопленного.
Отдельно про то, чего сессия не помнит даже внутри себя: она не помнит ваших мыслей. Если вы посмотрели дифф, поморщились и решили, что вторая правка лишняя, — агент об этом не знает. Он узнает об этом ровно тогда, когда вы напишете это словами.
Ещё одна вещь, которую стоит знать про сессию: она стоит денег и времени пропорционально своей длине. Каждое новое сообщение отправляется вместе со всем предыдущим разговором — модель каждый раз перечитывает его целиком. Поэтому сессия из сорока сообщений и медленнее, и дороже сессии из пяти, причём разница нелинейная. Это ещё один довод в пользу правила «одна задача — одна сессия», и довод чисто практический: длинный разговор вы почувствуете по времени ожидания раньше, чем по качеству ответов.
И последнее. Многие сессии кончаются не решением, а тем, что человек закрывает окно и идёт делать руками. Это нормальный исход, но у него есть цена: всё, что агент прочитал и понял про задачу, пропадает вместе с сессией. Если вы собираетесь вернуться к этой задаче завтра, потратьте минуту на итог — завтрашний вы скажет спасибо.
Задача целиком: пример
Соберём всё вместе на одной настоящей задаче. Пусть в корзине интернет-магазина неверно считается итог: не учитывается количество товара.
Шаг 1. Зафиксировать. Одна команда, пять секунд, и у вас есть точка возврата.
git add -A && git commit -m "перед правкой итога"Шаг 2. Поручить. Обратите внимание на три вещи в формулировке: названо место, названа ошибка, названо чем проверять.
В файле корзины, в функции итога, сумма считается без количества товара. Поправь и добавь тест на позицию с количеством больше одного. Соседние модули не трогай.
Нашёл функцию итога. Умножение на количество добавлено, добавлено округление до копеек. Добавлен тест на позицию с количеством 3. Все тесты проходят.
Шаг 3. Ждать — и поглядывать в журнал. Если агент открывает не тот файл, прерывайте, не дожидаясь конца.
Шаг 4. Прочитать дифф. Не сводку — дифф.
Два файла, девять строк. Всё названное в задаче — на месте; ничего сверх названного нет.
Здесь стоит задержаться на округлении. В задаче про него не было ни слова — агент добавил его сам. Это как раз то самое решение за вас: округление до копеек в денежном расчёте почти наверняка правильно, но вы его не заказывали, и в другом проекте оно могло бы противоречить принятому там правилу.
Обратите внимание и на то, чего в диффе нет. Нет правок в соседних модулях — потому что в поручении было сказано их не трогать. Нет обновлённых версий библиотек. Нет переименованных переменных «для ясности». Отсутствие лишнего — такой же результат работы, как присутствие нужного, и заметить его можно только если смотреть на дифф целиком, а не искать в нём знакомую строку.
Шаг 5. Запустить. Не «тесты зелёные у агента», а зелёные у вас. Это не недоверие: агент мог запустить их в другом окружении, с другими настройками, а то и поправить сам тест.
npm testШаг 6. Решить. Три варианта, и все три законны. Принять — фиксируем коммитом. Уточнить — «округление лишнее, убери». Откатить — одной командой, если результат не тот.
git restore .И ещё одно наблюдение по этому примеру, которое пригодится дальше. Агент сделал ровно то, что было названо в трёх частях поручения, — место, ошибка, чем проверять, — и добавил одно решение сверх. Это типичная пропорция: в хорошо поставленной задаче лишнего бывает одна вещь, в плохо поставленной — половина диффа. Иначе говоря, качество поручения видно не по тому, сделал ли агент нужное, а по тому, сколько сверх нужного он сделал.
Весь заход занял минуты три. Из них ваше внимание требовалось на шагах 1, 2, 4 и 6 — и суммарно это меньше минуты. Именно в этой пропорции и заключается выгода: не в том, что работа исчезла, а в том, что она сжалась до постановки и приёмки.