Чат отвечает, агент делает
Разговор с моделью в чате устроен просто: вы пишете вопрос, она пишет ответ. Что делать с ответом дальше — ваша забота. Скопировать, вставить, поправить отступы, запустить, обнаружить, что не хватает импорта, вернуться и спросить ещё раз.
Агент для кода убирает из этой цепочки перенос. Он получает ту же задачу словами, но у него есть доступ к вашему проекту: он открывает файлы, ищет по ним, правит их, запускает команды и смотрит, что вышло. Вы получаете не текст про код, а изменённый код.
Разница выглядит мелкой — «ну, скопировал бы сам» — а на деле меняет всю работу. Когда перенос делаете вы, модель может не знать, как устроен ваш проект: она пишет пример, а не правку. Когда перенос делает агент, он обязан вписаться: найти нужный файл, попасть в существующий стиль, не сломать соседнее.
Вторая особенность: агент не отвечает один раз. Он ходит по кругу. Прочитал — изменил — запустил — посмотрел на результат — если не сошлось, зашёл ещё раз. Этот круг он проходит сам, не спрашивая вас после каждого шага.
Отсюда два следствия, о которых стоит знать заранее. Первое: агент может потратить десять минут и пятнадцать заходов на задачу, которую вы сделали бы за две минуты, — и вы об этом узнаете только в конце. Второе, более приятное: он может пройти двадцать кругов по задаче, на которую у вас не хватило бы терпения, — перебрать все места, где встречается устаревший вызов, и поправить каждое.
Третье, что важно понять сразу: агент не помнит вчерашний день. Каждая новая задача начинается с чистого листа. Всё, что он знает о вашем проекте, он либо прочитал в файлах прямо сейчас, либо получил от вас в поручении. Никакой накопленной картины «как у нас тут принято» у него нет — её приходится либо повторять каждый раз, либо один раз записать в проект. Как именно записать — тема отдельного урока.
И последнее, что задаёт тон всему курсу. Агент честно делает то, что вы попросили, — и ровно поэтому неточное поручение оборачивается не отказом, а работой не в ту сторону. Он не переспросит «а вы точно этого хотели?»; он решит, что вы хотели, и сделает. Умение формулировать становится главным рабочим навыком, а не вежливостью.
Стоит сразу принять и цену этой сделки. Вы экономите на наборе текста и на перекладывании из чата в редактор — и платите за это временем на чтение чужих правок. Сделка выгодная, но только если вторую часть действительно выполнять. Тот, кто принимает изменения не глядя, не экономит время, а откладывает его трату на тот день, когда что-нибудь сломается.
Что агент видит в проекте
Первый вопрос, который стоит задать про любого агента: что он видит. От ответа зависит всё остальное — и точность, и цена, и то, какие задачи ему вообще можно поручать.
Агент видит три вещи. Первая — ваше поручение: то, что вы написали словами. Вторая — файлы проекта, но не все сразу: он открывает их по мере надобности, как открывали бы вы. Третья — результат команд, которые он запускал: вывод тестов, ошибку сборки, содержимое папки.
Чего он не видит — список короче, но важнее. Не видит вашего экрана: если ошибка проявляется как «кнопка съезжает», словами это придётся описать. Не видит боевой базы и настоящих данных. Не видит истории обсуждений в мессенджере и решений, принятых голосом. Не видит того, что вы считаете очевидным.
Отдельно про размер. Всё, что агент прочитал, помещается в окно контекста — ограниченный объём текста, с которым модель работает одновременно. Оно большое, но конечное, и «прочитай весь проект» для сколько-нибудь настоящего проекта невыполнимо. Поэтому агент читает выборочно и сам решает, что открыть: сначала ищет, потом открывает найденное, потом смотрит соседнее.
Из этого следует практическое правило, которое экономит больше всего времени: указывайте место. «Поправь расчёт скидки» — агент пойдёт искать, где он лежит, и может найти не тот. «Поправь расчёт скидки в модуле заказов, функция итога» — начнёт с нужного файла и потратит на поиск ноль.
Ещё одна вещь, которую видит агент и часто недооценивают: то, что уже написано в проекте. Он подстраивается под соседний код — под принятые имена, под то, как оформлены ошибки, под то, как здесь принято писать тесты. Это работает и в хорошую сторону, и в плохую: аккуратный проект агент продолжает аккуратно, а в проекте с двумя несовместимыми стилями он выберет тот, что попался ему первым.
Есть и обратная сторона выборочного чтения, о которой редко предупреждают: агент останавливается, когда решил, что нашёл достаточно. Он может открыть три файла из семи, увидеть в них связную картину и уверенно на ней достроить остальное. Получится правдоподобно и неверно — не потому, что он поленился, а потому, что три файла действительно выглядели достаточными. Лекарство одно и простое: если вы знаете, что задача затрагивает четвёртое место, скажите об этом сами, не надеясь, что он дойдёт.
И последнее наблюдение, полезное на каждый день. Всё, что агент не увидел, для него не существует — но отсутствие он воспринимает не как «я не знаю», а как «этого нет». Не найдя тестов, он решит, что их не пишут, и не напишет. Не найдя правил оформления, он применит свои. Никакого «а где у вас?..» в этом месте не происходит: молчание проекта он читает как ответ.
Три места, где он запускается
Один и тот же агент встречается в нескольких видах, и на первых порах это путает. Разберём, чем они отличаются на самом деле.
В терминале. Ставится на вашу машину, запускается из папки проекта одной командой. Видит ровно то, что видите вы, работает с вашими файлами, запускает ваши команды. Это самый прямой вид: ничего никуда не копируется, изменения появляются в вашем рабочем каталоге.
cd ~/projects/shop
codexВ редакторе. Расширение к тому редактору, в котором вы и так работаете. По сути то же самое, что в терминале, но изменения видно подсветкой прямо в открытых файлах, а не отдельным списком. Удобнее, когда правок много и хочется смотреть их по ходу.
В облаке. Задача уходит на чужую машину: там поднимается контейнер, в него забирается копия вашего репозитория, и агент работает уже с ней. Ваш ноутбук при этом свободен, и таких задач можно запустить несколько сразу. Результат приходит не в файлы, а отдельным набором изменений, который вы просматриваете и по желанию превращаете в запрос на слияние.
Есть и четвёртый вид, о котором стоит знать: агент, подключённый к вашему хранилищу кода. Он не ждёт поручения, а сам смотрит присланные изменения и оставляет замечания — как делал бы коллега на ревью. Про него отдельно в конце курса.
Важное, что объединяет все виды: порядок работы один и тот же. Поручение — чтение — правка — проверка — показ. Различается только то, на чьей машине это происходит и как быстро вы увидите промежуточные шаги. Поэтому весь этот курс не про кнопки: научившись работать с агентом в терминале, вы будете работать с ним в облаке без переучивания.
Ещё одно общее свойство, которое пригодится дальше: во всех видах агент читает правила репозитория — обычный текстовый файл, лежащий в проекте. Он едет вместе с копией репозитория в облако, он же читается на вашей машине. Это и есть способ не повторять одно и то же в каждом поручении.
Стоит сказать и о том, чем виды не различаются, потому что на этом теряют время чаще всего. Они не различаются качеством ответа: это одна и та же модель, и задача, которую агент не решил в терминале, не решится сама собой в облаке. Перезапускать неудачную попытку в другом виде — распространённое суеверие; помогает не смена окна, а смена формулировки.
И правило, которое стоит взять сразу: начинайте с того вида, где вам виднее всего. Первые недели полезно смотреть, как агент ходит по проекту, — какие файлы открывает, что запускает, где ошибается. Это и есть способ понять, что ему можно доверить. Облако удобно, но прячет эти шаги, и доверие там приходится строить вслепую.
Что вы получаете на выходе
Теперь самое важное: что именно вы получаете, когда агент закончил. Здесь у новичков складывается неверное ожидание, и оно портит первые недели работы.
На выходе две вещи. Первая — сводка словами: что агент сделал и почему. Вторая — дифф, то есть точный список изменений: какие строки в каких файлах удалены, какие добавлены.
Шесть строк диффа говорят больше, чем абзац сводки: видно и что было, и что стало.
Неверное ожидание звучит так: «сводка — это отчёт, дифф — это подробности для въедливых». На самом деле наоборот. Сводка — это пересказ агента о собственной работе, и он бывает и неполным, и приукрашенным; дифф — это то, что произошло на самом деле. Расхождения между ними встречаются регулярно, и почти всегда не в вашу пользу: в сводке «поправил расчёт», в диффе — ещё и переименованное поле в трёх местах.
Дальше у вас три возможных действия, и полезно знать все три с первого дня.
Принять. Изменения остаются, вы их фиксируете — делаете коммит и идёте дальше.
Уточнить. Вы говорите, что не так, и агент дорабатывает: «ты поправил расчёт, но округление теперь идёт раньше умножения — переставь».
Откатить. Изменения снимаются, как будто их не было. Это самое недооценённое действие из трёх: откат почти всегда дешевле разбора. Если после трёх уточнений результат всё ещё не тот, вернуться к началу и переформулировать задачу выйдет быстрее, чем доводить неудачную попытку.
Перепиши загрузку отчёта так, чтобы она не держала весь файл в памяти
Готово: чтение переведено на поток, добавлен тест на большой файл. Заодно поправил опечатку в соседней функции и обновил версию библиотеки для чтения.
Обратите внимание на слово «заодно» в этом ответе. Оно встретится вам очень часто, и это главный повод читать дифф целиком, а не только те файлы, которые вы ожидали увидеть изменёнными. Обновлённая версия библиотеки — не мелочь: она может потянуть за собой поведение, о котором в задаче речи не было вовсе.
И последнее про принятие работы. Вопросов на самом деле не один, а четыре, и отвечают на них разные вещи: «что изменилось» — дифф, «почему так» — сводка, «не сломалось ли» — запуск и тесты, «туда ли вообще делали» — ваше исходное поручение. Последний вопрос забывают чаще остальных, и именно он отделяет «работает» от «сделано то, что было нужно».