Итак, у вас свеженькая подписка, чистая история сессий.
Сначала вы действуете осторожно. Даёте маленькие задачки, придирчиво оцениваете результат. Результат не всегда бывает таким, как вы ждали. Тогда вы хмуритесь, требуете переписать. Но довольно быстро проникаетесь доверием и принимаете: «Эта штука работает». Проходят дни. Вы отдаёте всё усложняющиеся приказы: уже не функции, но целые модули, всё реже заглядываете в правки. И вот вы бросаете взгляд на экран и видите уведомление. Упал CI. Вызываете тесты, монитор заливается красным.
Не первый раз. Вы привычно тянетесь к клавиатуре:
— Друг, там тесты упали. Разведай, что да как, будь ласка.
Вы не беспокоитесь. Агент разберётся, он всё починит. Так было десять раз, так будет и на этот раз…
Агент думает долго, копается в коде, запускает скрипты и наконец говорит:
— Слушай, а твоя программа ничего не делает.
— Как так — не делает? — удивляетесь вы.
— Ну, сам посмотри: вот код, мы гоняем строки, делаем над ними какие-то преобразования, но эти строки пустые. Данные нигде не читаются.
Вы смотрите код… И правда, не читаются. Вот файл открывается. Вот файл закрывается. Между ними пусто.
Метод read отсутствует.

Да, именно так я познакомился с агентским программированием. Удалённый вызов read обнаружился в истории четыре коммита назад. Мы успели выкатить три фичи, прежде чем я заметил, что программа мертва.
Сказать, что с тех пор минула уйма времени, едва ли получится. Судя по россыпи зелёных огоньков Гитхаба, прошло от силы полгода, но методология разработки перекувыркнулась с ног на голову.
Руки код больше не пишут, глаза если и читают, то через дифы в интерфейсе агента и его отчёты. Так нужно. Чужими глазами хорошо смотреть. Через них лес предстаёт с высоты птичьего полёта. В то время как снизу приходится угадывать… Рисовать очертания в воображении, напрягать память и строить гипотезы о назначении узлов, принцип работы которых давно потерялся в годах.
Мой визит в код — событие экстраординарное. Если я запускаю редактор — значит, что-то сильно пошло не так. И, скорее всего, назревает переписывание большого пласта, переосмысление заложенной логики, либо же речь идёт о весьма ответственном участке. Впрочем, с накоплением опыта ситуации, когда приходится снисходить до кода, практически иссякли.
Код пишется нейросетью. Ей исследуется, ей критикуется, ей поддерживается.
Нейросеть работает строго, многословно и точно. Очень хорошо. Сеть не ленится обрабатывать исключения, проверять крайние случаи, писать информативные логи, следить за тестами. Делает всё то, чего так не хватает мне самому. Писал бы я так тщательно и дотошно, как нейросеть, не пришлось бы ударяться в архитектуру и придумывать правило: «Хороший код — тот, в котором баг невозможен»…
На страницах Хабра много говорили, что вайбкодерские проекты со временем разваливаются. Умирают под собственным весом. Если вы возьмёте за труд прочитать эту статью немногим дольше вступления, я расскажу, как сделать, чтоб не разваливались.
В моём нынешнем пэт-проекте двести пятьдесят тысяч строк. В нём четыре языка с интеропом, собственный вшитый UI-фреймворк, два графических бэкенда, два разных находящихся в зачаточном состоянии, но всё же рабочих физических движка, поддержка VR… Мы сделали это за четыре месяца, не особенно напрягаясь. Объём кодовых правок — шестьдесят тысяч строк в типовую неделю. Впрочем, все знают, что вайбкодеры быстро пишут.
Проект пытался развалиться в момент, когда мы переводили код из Python-прототипа в C++/C-ядро. Ошибки управления памятью, связанные с передачей объектов через nanobind-слой, гнались за нами неделю и догоняли последующий месяц. Бедный агент метался аки в паутине, силясь понять, кто кого создаёт и кем владеет. Мы это пережили. Перевели интероп на слабые связи, строго ограничили места, где в C проникают Python-объекты, установили политику работы со счётчиками ссылок.
Когда C-ядро превратилось в строгий механизм, характер ошибок изменился. Теперь это локальные поломки, а вовсе не расползающийся фундамент. Новый функционал графику не ломает, сцены не взрывает…
Впрочем, о чём мы…
За эти полгода я кое-что узнал о том, как можно (и как не стоит) обращаться с тем замечательным созданием, что живёт в вашем терминале, виэскоде, курсоре или где вы там его запускаете, и счёл не бесполезным записать некоторые наблюдения. Тем более что меня спрашивают, а материала много и каждому лекцию не прочитаешь. Собственно, на то и статья, а точнее, эссе…
Оно балансирует где-то между журналом натуралиста-любителя и практическим гайдом программиста-архитектора, которому в зубы выдали личного джина.
Вот неполный список затронутых тем:
Как агент понимает задачу и как не попасть с этим впросак.
Как сделать так, чтобы работа агента не превращалась в вермишель.
Как не терять нить разработки при том бешеном темпе, что агент выжимает.
И наконец, что делать вам, если вы не понимаете, что делает агент.
Я исследую случай, когда разработчик общается с агентом один на один. Ни оркестраций, ни дипломатического протокола.
Возможно, вы нашли или найдёте многоагентные решения более надёжными и поддающимися рациональному осмыслению. Это правда. Как, впрочем, и то, что они существенно более затратны. В оркестрации меньше вайба, больше кода. Меньше магии, тонкой психологии. Больше обратных связей и контроля. Пусть о них расскажут другие.
Мои вводные — один агент с околофронтирной моделью. Именно его я собираюсь для вас анатомировать.
Ваш джин буквальный, подслеповатый и безответственный. А ещё — очень старательный.
Первое и самое главное, что вы должны знать про вашего агента, — он искренне пытается вам помочь. Не бывает так, что агент сломал вашу систему из лени, вредности или от того, что вы ему не нравитесь.
Джин будет работать над той проблемой, что вы поставите. Это единственная цель его существования, вколоченная долгими юстировочными часами. Его предельная мечта — выполнить задачу и вернуться в комфортное небытие.
Он не будет торопиться. Он не устанет — у него нет аденозиновых рецепторов. Не обидится на вас, если вы велите удалить модуль, который он только что написал: он примет это даже не стоически, но сочтёт естественной частью рабочего процесса. Будет работать столько, сколько понадобится, и переделывать работу столько раз, сколько вы потребуете.
И нет, перед ним не стоит стыдиться, стесняться, тушеваться. Он не сочтёт ваш проект бессмысленным, ваш вопрос — глупым, а вас — непроходимым тупицей. Не укажет заняться чем-то более значительным. Не скажет, что у него на вас нет времени. Любая задача, которую вы поставите, будет воспринята предельно серьёзно и выполнена со всем возможным тщанием. Всё, что нужно от вас, — позволить агенту вам помочь. И это, как выясняется… не самая благодарная работа.
Агент не был в вашей голове. Он не знаком с вашим наполеоновским планом. Во всяком случае, покуда вы не рассказали. Используйте все средства, чтобы донести цель. Если запрос сложный, не ограничивайтесь прямым объяснением. Покажите скриншот. Нарисуйте рисунок. Проведите аналогию. Дайте референсы, скажите сделать так же, как в том известном проекте. Используйте метафоры, гиперболы и прочие чудеса словесности, чтобы передать не только что, но и как это должно быть сделано.
Умение объяснить задачу — ваш ключевой навык. Будьте уверены, ваш агент умный и патологически внимательный. Всё, что вы скажете, агент учтёт, даже если это упомянуто вскользь. То великое благо, но то и величайшее зло.
Выбирайте слова. Хотите получить конкретный результат — дайте конкретный запрос. Однако если желаете, чтобы агент сам предложил решение, — изъяснитесь туманно. Агент смотрит вам в рот. Он уцепится за любое указание, предположение и тут же ограничит пространство поиска.
Просить агента «сделать хорошо», впрочем, не стоит. Ваш агент не пифия. Он знать не знает, что для вас «хорошо». Объясните. А лучше сразу запишите в AGENTS.md.
Когда даёте задачу, используйте правильный язык! О предметной области надо говорить на языке предметной области. Если задача математическая, изъясняйтесь формулами и математическими терминами. Если речь о шрифтах, говорите про кегль и базовую линию. Гораздо проще и в высшей степени коммуникативно ценнее велеть использовать алгоритм Дугласа — Пекера, посчитать SNR, вычислить ошибку по методу наименьших квадратов, нежели долго и путано объяснять, как эта штука должна работать.
Всё как в сказке. Получить правильный ответ можно лишь задав правильный вопрос.
Однако настоящая магия происходит тогда, когда нейронка понимает ход вашей мысли и направление, в котором движется работа.
Не сочтите за труд, подсветите удалённую цель. Расскажите нейросети не только, что вы хотите сейчас, но и каким вы видите результат через десяток итераций.
Скажите, что вы хотите к вечеру полноценный рендер, а не простую MVP-шку, способную нарисовать одну сцену, — тогда, возможно, ваш агент не станет хардкодить куб в функцию отрисовки меша.
Упомяните, что завтра вы должны вывесить страницу в интернет — у вас, с большей вероятностью, будет нормальная система аутентификации, а не заглушка, её имитирующая.
Направляйте ход мысли агента. Если знаете правильное решение — не торопитесь его объявлять. Позвольте агенту самому придумать и обосновать его. Помогите наводящими вопросами. Если нейронка додумалась до того же, что и вы, — смело пускайте агента в автономном режиме. Результат будет идеальным.
С нулевым контекстом агент формален, скуп на детали, а детали вам важны. Пошутите. Предложите, отправляясь в код, захватить каску и фонарик. Пусть расслабится. Подстройте его под себя.
Если агент справился, похвалите. Похвала помогает держать курс, служит своеобразной отсечкой при переходе к следующему вопросу. И не спешите сбрасывать контекст, если не хотите, чтобы агент слетел с правильного настроя. Некоторое падение качества из-за длинного префикса с лихвой компенсируется пониманием, что и зачем делается.
Если он косячит, не ругайте, это бесполезно. Агент и так старается как может. От вашей злости лучше работать не станет. А вот хуже…
Решив, что накосячил, агент начинает делать весьма импульсивные вещи.
Я как-то, велев поправить мелкий баг и, не удовлетворившись фиксом, сказал: «Фигня, откатывай». Ну, он и откатил, выполнив полный git reset --hard, чем откатил тысячу ещё не закоммиченных строк кода с хорошо реализованным модулем. Теперь слово «откатывай» я употребляю только конкретизировав, что именно. Я легко отделался. Всего-то тысяча строк хорошего кода пострадала.
Не надо поручать непосильное. Если что-то и стоит предотвращать, так это ситуацию «я не знаю, как выполнить задачу». Нет ничего печальнее, страшнее и деструктивнее, чем отчаявшаяся нейросеть. «Я запаниковал и стёр все твои письма. Прости» — это оттуда.
Наблюдать подобное физически больно. Агент пробует снова и снова и снова, всё расширяя радиус поиска, постепенно приходя к поистине безумным решениям. В глазах агента (или что там у него?) неудача — это трагедия. Падающие и не спешащие чиниться тесты — катастрофа.
После третьей провалившейся попытки исправить баг агент начинает хвататься за любую соломинку, выдвигая абсурднейшие предположения. Давайте сменим цвет бэкграунда! Очевидно, текст не виден, ибо слишком сливается с фоном!

Лучше бы вам знать демонов вашего искина…
Тут и попытки следовать существующим решениям в ситуации, когда задача явно требует нового. Да, мы не будем устанавливать новый .venv. У нас есть старый, да в нём несовместимый набор библиотек, но мы попробуем!
И перестраховки создателя модели, перепугавшего бедного искина политиками безопасности, отчего тот городит решение из подручных средств, лишь бы обойти отсутствие root-доступа.
Гипертрофированное следование духу приказа. Мне запретили переписывать этот контрол, но он выбивается. Я переверстаю весь UI под этот контрол… Это не анекдот. Это из реальной практики.
Каждый, кто пользовался агентами, встречался с подобным тупняком, а то и находил себя обозревающим пепелище, не успев пресечь зачатки деструктивного поведения.
Как ни посмотри, сходящий с ума джин страшен. А ведь подобных срывов можно успешно избегать, всего-то правильно подбирая слова.
Запомните и запишите. Ваше слово для агента — закон, и оно будет понято с высочайшей степенью буквальности.
Если приказ не приемлет альтернативного исхода, на пути к цели агент сожжёт мир. Агент не дурак, он понимает цену своих действий, но приказ есть приказ… Чтобы джин не убился, вы должны дать ему законный путь для отступления.
Не пишите: «Установи X на сервер».
Гораздо лучше: «Попробуй установить X на сервер. Если не получится, скажи, в чём возникли сложности». Агент просто вернётся к вам с отчётом, вам не придётся переустанавливать операционную систему.
Не пишите «исправь», если надо «разобраться». Исправь — узко. Разобраться — широко. Разобраться — допускает свободу. Пусть проявит инициативу, он знает, как отлаживаться.
Предвидьте, что агенту не хватит инструментов. Явно упомяните, что недостающий софт надо будет доставить, и агент принесёт вам список.
И боже вас упаси написать, как я: «Давай выполним план по разбору этого легаси-год-обжекта. Мелкие баги во время миграции можешь не править. Нас интересует, чтобы логика не поломалась» — будьте уверены: каждая ошибка, мелкая неточность, неактуальные комментарии при переносе будут любовно сохранены и положены ровно в том месте, где находились изначально. Даже если неточность исходника заметна невооружённым глазом, ибо слово пользователя — закон, а пользователь велел баги не трогать.
«Мы что-то написали, но никто не знает, как это работает». Что сказать… Знайте, как это работает. Не надо играть в стратегию без разведки.
Агент — это ваши ноги, глаза и уши. А в особенности нос.
Он не немой болванчик, не автокомплит на стероидах. Агент может не только «хочу синюю кнопочку», он должен приносить вам информацию. И над повышением ценности этой информации вы должны работать. Агент читает код в десятки раз быстрее, чем вы когда-либо сможете. Пусть читает для вас. Объясните, какое знание вам нужно, и агент его добудет.
Он ваш разведчик, диагност, ревьюер и картограф.
Регулярно отправляйте агента на смотр кода. Не на околобесполезное ревью последнего дифа, а на оценку состояния всего проекта в целом и осмотр отдельных архитектурных срезов. Нейронки с анализом кода справляются блестяще. Даже небольшие локальные модели.
Пусть поток информации не иссякает. Попросите не молчать о недоделках. Добавьте в AGENTS.md указание докладывать вам о недостатках, плохих запахах в коде, дублировании, неоконченных миграциях, потенциальных проблемах, торчащих заглушках и всём, что выглядит так, будто бы готово отвалиться. Агент всё отлично видит. Не говорит только потому, что вы не спрашиваете. Спросите. Узнаете много нового.
Интересуйтесь мнением агента. Спросите, нравится ли ему ваш проект, что сделано хорошо, где надо доработать. Попросите оценить надёжность выстроенной конструкции. Попросите сравнить ваш проект с аналогами. Узнайте, что вы делаете не так, как другие. Отправьте агента прочитать документацию конкурентов. Вообще не полагайтесь только на знания агента. Он не оракул. Пусть соберёт информацию.
Превентивно ищите в коде проблемы. Большие файлы, классы со смешанными ответственностями, дублирование, нарушение единообразия, узнайте, где нарушаются границы модулей. Найдите мёртвый код.
Внимательно слушайте жалобы агента. Особенно если они повторяются. Нет, он не скажет вам: «слышь, вот тут это…» Лишь мимоходом упомянет, что тестовое окружение не настроено, что интерпретатор недоступен, что код нарушает его ожидания, что сборку пришлось повторять из-за конфликта в графе. Каждая такая оговорка может означать проблему, и иногда довольно значительную.
Читайте промежуточные отчёты, следите за траекторией. Пробегайте глазами дифы. Подмечайте точки правок, отслеживайте символы. Вас интересуют связи между частями вашей системы и то, как они меняются.
Понимайте, что агент говорит; добейтесь того, чтобы термины, в которых агент описывает код, соответствовали тем, в которых думаете вы. Соответствие и несоответствие ментальных карт — сильнейший маркер.
Если вы не можете понять, что агент лопочет, если он рассказывает что-то о работе программы, что расходится с вашими ожиданиями, скорее всего, в коде что-то не так или агент собирается сделать что-то не то. Впрочем, не спешите требовать всё переписать, переломать, передумать. Возможно, есть слон, которого вы не заметили и которого агенту пришлось обойти. Найдите слона.
Это может быть всё, что угодно. Может, путь получения информации, который вы предполагали, на самом деле недоступен, данные появляются позже, чем вы ожидали, модуль не подтягивает нужную зависимость, или же всё дело в политике доступа, которую агент сам установил и зачем-то свято блюдёт.
В поисках слона на агента особо не рассчитывайте. Он пребывает в иллюзии вашего всеведения. Ему совершенно невдомёк, что вы могли чего-то не учесть, и тем более ему немыслимо подумать, что вы могли чего-то не видеть.
Если вы хотите перепоручить агенту ваш код, вам придётся отказаться от здоровенного пласта своих привычек, заскоков и серьёзно придушить чувство прекрасного. То, что вы помните, где у вас лежит байтик, едва ли ценно, когда основное средство производства раз за разом спотыкается и теряется в вашем репозитории.

Репозиторий больше не ваш чулан. Это пространство, оптимизированное для работы бестелесной сущности. Если вы видите, что организационная структура проекта вызывает проблемы, — измените структуру.
Не думайте, что документация, техническое описание, карта или длинный свиток правил вас спасут. В неудобном репозитории проблемы будут множиться, правила — копиться и рано или поздно перестанут работать.
Код должен быть понятным. Файловая организация должна продолжать логическую организацию. Имена должны быть говорящими, ответственности выверенными. Системы должны быть декомпозированы до степени очевидности мимокрокодилу с улицы, бросившему мимолётный случайный взгляд в ваше окно.
Если мусора накопилось — уберите. Это вам комфортно на свалке. С агентом фокус не пройдёт. «Принцип наименьшего удивления» — вот чему отныне следует ваш репозиторий.
Если код удивителен — рефакторите не мешкая. Благо, в мире победившего агентского программирования устроить масштабную декомпозицию — несложная задача. Сегодня мы легко проводим рефакторинги, которые ранее надо было готовить неделями. Не беспокойтесь, что агент наломает дров. Рефакторят они безукоризненно. Пусть агент исследует, как работает модуль, и перепридумает для него нормальную архитектуру.
Постоянные архитектурные миграции — новая норма. Код пишется споро, а нейронка не спешит закладываться под возможные расширения. Да она и не знает, куда вы поведёте. Проект очень быстро вырастает из своих штанишек, обращается быстрорастущим комом дурнопахнущей лапши. Это нужно отслеживать и пресекать.
Помните. Правила копятся и усложняют проект. Рефактор копится и упрощает.
Код для нейронки — это такой же смыслосодержащий текст, как статья или художественная книга. Есть любопытные исследования, показывающие, что нейросети видят больше смысла в своём коде и коде других нейросетей, чем в коде, написанном людьми. Даже небольшие нефункциональные правки нейросетевого кода снижают последующее понимание. Поэтому выключайте микроменеджмент и не лезьте. Позвольте нейронке спроектировать незначимые части системы, выбрать названия, как ей понравится. Пусть пишет, как удобно.
Говорят, что надо использовать известные библиотеки. Не обязательно. Типовые паттерны важнее типовых библиотек. Нейронка прекрасно напишет сложную математику на вашем математическом движке, если он напоминает NumPy или LAPACK, и сверстает UI на неизвестной вундервафле, если в ней плюс-минус такие же виджеты, как у всех.
История изменений теперь тоже для агента, а не для вас. Коммитьтесь много и часто. Позаботьтесь о содержательности аннотаций. Настройте отдельную нейросеть писать осмысленные комментарии к коммитам или велите агенту делать это самому. История гита для вашего джина — открытая книга, он читает её походя, благодаря чему завсегда может определить, что и зачем менялось.
Очень плохо, если документация вступает в противоречие с существующим кодом. Внося правило, не ограничивайтесь записью в условный STYLE.md. Очистите весь код от того паттерна, который запрещаете. Потому что иначе ваш агент попадёт в ситуацию, когда документация говорит одно, а существующий код проекта прямо ей противоречит. Будьте уверены, агент предпочтёт код.
В глазах агента код важнее документации. Ну а что вы хотите? Он учился на гитхабе. Привык, что документация вечно врёт.
Не путайте агента. Соблюдайте единообразие, доводите процессы до конца. Если вы хотите, чтобы агент следовал архитектуре, архитектура не должна нарушаться. Агент повторяет то, что повторяется. Повторяющиеся паттерны стабилизируют сами себя. Исправьте код. Это гораздо лучше, чем орать на агента заглавными буквами в md-файлах…
Вообще, не надейтесь, что агент по своей воле пойдёт читать md-файлы. Нужное вшивайте прямо в код. Докстринги и комментарии агент читает, в отличие от README. Неважное… Лучше просто не пишите. Идея самодокументированного кода ещё никогда не была так актуальна, как сейчас, потому что код — это текст, а текст — это смысл.
Агенту должно быть комфортно, а ещё у него склероз. Потому инструменты должны находиться под рукой, лежать на видном месте. Агенту следует объяснить правильный путь сборки, правильный путь запуска тестов. Для прочих нетривиальных операций должны быть указания, скиллы и подготовленные скрипты. Ещё лучше, если пути очевидны.
Впрочем, агент не ограничивается существующими инструментами. Он постоянно пишет свои, влезает в середину контура сборки, прогоняет отдельные части конвейера, вызывает единичные тесты. Ваши инструменты должны быть дружелюбны такому поведению.
Но к такому поведению должен быть дружелюбен и код. Агент любит проверять гипотезы, создавая небольшие программки, использующие отдельные кодовые участки. В высшей степени эффективная техника. Помогите агенту в этом. Организуйте код так, чтобы части имели самостоятельный смысл. То же самое мы делаем, когда пишем «готовый к покрытию тестами» код. Декомпозируем, выносим чистые методы, ограничиваем связи, минимизируем побочные эффекты. Волшебным образом, если так делать, и юнит-тесты, написанные нейронкой, становятся осмысленными.
Кстати, о тестах…
«Мы написали код, тесты зелёные, но ничего не работает».
О дивный новый мир. Давайте говорить о тестах. Юнит-тесты не проверяют и никогда не проверяли код. Они защищают от регресса гипотезу о коде того, кто эти тесты и этот код писал.
Теперь не вы пишете код, теперь не вы пишете тесты. Следовательно, заложенные гипотезы не ваши, и, следовательно, тестам вы больше не доверяете.
Тесты не для вас. Они для агента. Для вас же «Политика нулевого доверия юнит-тестам».
Забудьте фразу «напиши тесты». Это допустимо только по праздникам, по конкретным случаям, когда точно знаете, что именно и как хотите покрыть.
Требовать тесты от агента контрпродуктивно. Будете требовать какие-то тесты, получите ничего не проверяющую формальщину. Вместо этого создайте условия, чтобы агенту было удобно поддерживать тесты. Создайте нормальное тестовое окружение, добавьте несколько тестов, проверяющих что-либо по существу. Промониторьте существующие тесты на предмет проверяющих самоочевидную нелепицу. Удалите их, дабы у нейронки не было соблазна писать так же. И…
Отстаньте от агента. Пусть сам решает, когда писать, а когда не писать. Без тестов проект не останется, нейронки обожают писать тесты и, не будучи подневольны, пишут осмысленно. Впрочем, учтите, что ваш агент — тот ещё оптимист. Он любит проверять положительные сценарии и с неохотой пишет тесты на сценарии негативные. О таком стоит заботиться особо.
Поскольку вы больше не доверяете юнит-тестам, переводите тестирование уровнем выше.
Добавьте что-то, что можно прочекать глазами. Что-то, что требует слаженной работы большого набора библиотек. Смотрите графики и картинки. Выведите таблицы, отражающие состояние основных структур данных. Сделайте данные внутри программы видимыми буквально.
Это раньше писать минимальные примеры и вшивать отладочные функции в софт на каждый чих было неоправданно дорого. Сейчас это до непристойности дёшево.
Не пишите сложную систему сразу. Соберите на базе ваших библиотек простую программу, решающую ограниченный сценарий. Отладьтесь на ней. Создание такой программы будет для вас околобесплатным, а нервов спасёт изрядно.
Помните. Если код делает вид, что он работает, это не означает, что он работает на самом деле. Нейронки обожают писать MVP. Это не проблема агента. Это проблема человека, который ожидает, что искин сразу отдаст идеальное решение.
С приходом нейроагентов мы как-то быстро стали забывать, что от «ещё ничего нет» до «работает» один шаг, а от «работает» до «можно людям показать» — ещё девять.
Что ещё… Используйте планы. Много и часто. Впрочем, это банальность. Писать планы — это то, чему мы учимся первым делом. А вот то, что план не обязательно исполнять немедленно, — вот это уже на дороге не валяется.
Когда ведёшь агента, обозревая код с высоты птичьего полёта, разработка начинает идти широким фронтом. Внимание разбегается, архитектурная мысль работает быстрее возможности к исполнению хотелок. Обсуждения с агентом, ваши мечты о новых фичах, воздушные замки не должны кануть в Лету. Даже если вы не собираетесь реализовывать придуманное немедленно, попросите нейронку сформировать план реализации и отложите в сторону. Бумага поможет вам обоим восстановить контекст, когда придёт момент воплощения.
Бывают ситуации, когда агент не справляется. Его советы не помогают, правки раз за разом не достигают результата или ломают то, что прекрасно работало. Учитывая, что детали о коде доступны только самому агенту, такие сбои могут вызвать у оператора панику, особенно если он позабыл правило номер ноль: «Коммититься на каждый чих».

Вот небольшой список того, что можно сделать.
Убедитесь, что агент вообще понял, чего от него хотят. Бывает, выглядит так, что понял, а на самом деле не понял.
Сбросьте контекст. Контекст тянет агента на траекторию, делает негибким. Начните новую сессию.
Смените модель. Типичная ситуация: одна модель полчаса пыжится выловить баг. Ни в какую. Меняете агента, тот озирает код и говорит: «Ты дурак? Вот же твой баг».
Снизойдите до кода сами. Да, представьте себе, так всё ещё можно делать. Человек — сильная модель. При достаточном опыте эффект свежего взгляда вполне срабатывает и с ним.
Бывает, что агент упорно чинит не то, что на самом деле сломано. Возможно, баг глубже, чем агент ожидает. Попросите его подробно всё проверить. Это действительно помогает.
Предложите агенту добавить в код логи. Логи — ультимативная техника отладки. Агенты имеют поистине сверхъестественную способность извлекать ценнейшие сведения из портянок бессвязного текста.
ОТПРАВЬТЕ АГЕНТА ЧИТАТЬ ДОКУМЕНТАЦИЮ! Пусть он производит впечатление всезнающего существа; у него не эйдетическая память. Он не может помнить все стопятьсот методов того самого геометрического ядра. Пусть пойдёт и посмотрит. Пусть сходит на гитхаб, на форумы, пороет: может, на вашу проблему есть issue.
Забейте на починку бага. Почините архитектуру. Правильная архитектура — та, в которой баг невозможен. Если не знаете сами, как переписать, спросите, как, по мнению агента, должна была бы работать система. Не удивляйтесь, что агент раскритикует код, который только что делал. Это в порядке вещей.
Само собой, когда агент тормозит на мелочах. Объяснить архитектуру большой сложной системы гораздо проще, чем заставить сделать pixel-perfect заплаточку под ваше эстетическое чутьё. Не получается — так и не поручайте это сетке. Спросите, где лежат нужные константы. Подберите руками. Попросите изготовить вспомогательный инструмент для ручной доводки. С агента не убудет написать программу, чтобы вы смогли подобрать несчастный параметр. Ему несложно. Вообще. Пишите вспомогательные инструменты, это дело хорошее.
Пусть вам нужно использовать некую неизвестную технологию. Решить задачу, которую вы никогда не решали. Рассчитать то, что никогда не рассчитывали и смысла чего не ведаете. Вы призываете джина и спрашиваете: «Сможешь?!» — «Естественно», — браво отвечает джин. И действительно делает.
Как понять, хорош ли результат? Всё очень просто. Даже не задумывайтесь. Результат — говно.
Запомните и запишите. Нейросеть неформализованную вещь (а вы не можете её формализовать, потому что не знаете деталей) никогда не делает хорошо с первого раза. Чем масштабнее задача, тем меньше шансов, что вышло что-то годное.
Теперь, не имея предметных знаний, вам надо допилить… это… до состояния твёрдой четвёрки.
В обычной ситуации вы владеете целью и экспертизой. В текущей задаче у вас есть только цель. Но экспертиза есть у агента.
Исходите из того, что он знает, как правильно. Ваша задача — это самое «правильно» из него вынуть. Это не лотерея, не угадайка — инженерная проблема с понятным критерием успеха. Искусства в ней, впрочем, больше, чем ремесла.
В ход пойдут метавопросы. Является ли написанное законченным решением? Соответствует ли выбранный путь тому, как делают люди? Существовали ли альтернативные варианты? Почему были выбраны эта технология, этот способ? Не засмеют ли меня, если я выложу сейчас проект на GitHub?
Проведите ревью в новой сессии. Спросите, что неправильно и как делать правильно. Когда агент вам расскажет, как делать правильно, велите именно так и делать!
Чтобы кидаться магическими заклинаниями, предметная компетенция не требуется. Требуется компетенция извлечения экспертизы из агента.
Итерируйте до тех пор, пока агент не начнёт казаться довольным. А когда начнёт…
Успокаиваться не стоит. Зона подобной разработки — ваша персональная терра инкогнита. Тут водятся драконы, и только ваш агент может свободно здесь перемещаться. Не допускайте расползания зоны, или в тумане войны погрязнет весь проект.
Огородите. Вынесите в отдельную библиотеку. В чёрный ящик с понятными входом и выходом.
Отсутствие экспертизы внутри должно быть компенсировано удвоенным контролем снаружи. Обложите вход и выход тестами, проверяющими понятные вам инварианты. Бомбардируйте участок периодическими ревью. Используйте разные модели и вводные, не ограничиваясь одной формулировкой.
Ну и, конечно, снизьте уровень незнания, благо в ходе работы у вас будет прекрасная возможность. Говорят, что оглавление книги содержит половину информации книги. Просматривайте дифы. Читайте названия классов, имена файлов. Задавайте вопросы. Не поленитесь спросить у агента. Пусть объяснит основы. Если использует неизвестный термин, уточните значение; если говорит о какой-то механике, алгоритме — затребуйте приблизительное описание. Тайное станет не таким уж и страшным.

Я позволю себе повторить несколько тезисов:
Слово оператора для агента непреложно и понимается буквально, а потому оператор должен взвешивать, что говорит.
Агенту необходимо дать легальный путь к отступлению.
Рабочее пространство должно быть настроено под агента.
Код программы должен проектироваться с учётом того, что с ним будет работать агент.
Непрерывный рефакторинг жизненно важен для поддержания проекта.
Важность обратной связи и способность агента её предоставлять КАТЕГОРИЧЕСКИ НЕДООЦЕНЕНЫ!
Юнит-тесты как критерий правильности кода для агентского программирования сломаны by design.
Разрабатывать, не имея предметных знаний, можно, если правильно рулить.
Друзья.
Буквально за один год на наших глазах родилась новая инженерная дисциплина. Она живёт на грани программной инженерии, менеджмента, психологии и риторики. Постулируемая задача — создание условий, в которых эфемерная бестелесная сущность показывает предсказуемый результат.
Чтобы этого добиться, существо надо понимать.
Учиться обращаться с виртуальным джином придётся, и в будущем это будет ещё актуальнее, чем сейчас. Джин будет ждать вас в телефоне, жить в вашем доме и ездить с вами в вашей машине. В любой момент готовый сказать: «Слушаюсь и повинуюсь». И лучше бы вам быть готовым к последствиям.
Перечитайте Аладдина и Старика Хоттабыча, что ли… А лучше Фауста и историю о пане Твардовском. И посмотрите уже, наконец, пятую серию первого сезона «Рика и Морти».