Когда агент выдаёт очередную глупость, сразу хочется сказать: модель тупая, поумнеет — пройдёт.
Ты просишь агента разобрать старый файл на пару тысяч строк на несколько отдельных модулей. Даёшь подробную инструкцию в чат и нажимаешь энтер. Через пару минут терминал рапортует об успехе. Агент аккуратно разнёс логику, сохранил импорты, заботливо обновил вызовы в соседних файлах.
Код выглядит чисто, тесты зеленеют, линтеры колосятся, всё собирается. Ты просматриваешь дифф в редакторе — всё на своих местах, старая логика не сломана. Можно сливать ветку и брать следующую задачу.
А потом, при следующем рефакторе кода, ты замечаешь мелкую, но болезненную деталь. Со всех перенесённых DTO-шек тихо сняли @freeze декоратор. Или формат какой-то служебной даты внезапно потерял UTC-0 и стал локальным. Или пропала проверка прав доступа, которую ты не упомянул в тексте задачи, потому что она казалась самоочевидной.
Эта грабля — сборная. Она склеена из повторяющегося класса ошибок, в котором от раза к разу меняется только наполнение. Исполнитель наткнулся на дыру в постановке задачи, не задал ни одного уточняющего вопроса и молча принял важное решение за тебя. Он додумал недостающий контекст, выбрал удобную ветку поведения и намертво забетонировал её в итоговом коде.
Модель тупая. И что дальше?
Первый рефлекс в такой момент — заклеймить исполнителя. “Ну тупыыыые”. Модель тупая, контекстное окно маловато, железо недотягивает. Вайбкодер в этой точке тяжело вздыхает и тянется за привычными рычагами. Он открывает настройки, выбирает класс модельки постарше, переводит effort на Ultra Max Extremely Unbelievable High и докидывает в промпт ещё с десяток полуслучайных файлов из проекта.
Мы искренне верим, что если навалить в контекст побольше токенов, то на этот раз машина всё поймёт правильно. Мы ждём, что со следующим мажорным релизом модельки этот тупняк рассосётся сам собой.
Может, и рассосётся. Но привычка списывать любой брак на дефект модели обрывает расследование ещё до его фактического начала. Диагноз «модель тупая» не ведёт ни к какому проверяемому действию. С ним нельзя работать: этот диагноз бесплоден. Это тупик, который оставляет тебе только смиренное ожидание следующей умной версии и ежедневное сжигание бюджета на компьют.
Повторение — мать учения
Здесь у нас отличное место, чтобы показать на практике как работает ключевой тезис прошлого поста — «Ты не ту ручку крутишь». Возможно, вы помните его: агент это не инструмент, а исполнитель.
Применяется оно здесь очень просто: представьте, что вы дали эту задачу человеку, и он облажался таким же образом, как облажалась в вашем случае модель.
Всегда можно заключить, что исполнитель просто туп, и заменить исполнителя на более умного. Но это рефлекс менеджера, который снимает с себя ответственность за управление рабочим процессом. Обычно потому что сам не понимает, как сделать задачу правильно. Но эта серия статей предназначена для опытных разработчиков, которые могли бы сделать эту работу сами, пусть, возможно, это заняло бы у них существенно больше времени.
Читайте дальнейший текст через призму работы тимлида / архитектора, который видит, что что-то сделано неправильно, знает, как должно быть сделано, но сам руками в код не лезет просто потому что так он потеряет ценную возможность преподать урок подчинённому и изменить процесс таким образом, чтобы избежать подобного класса ошибок в будущем, вне зависимости от навыков разработчиков.
А где это вообще пропустили?
Когда исполнитель выдаёт уверенно упакованный бред, самый продуктивный вопрос должен звучать совершенно иначе. Вместо «почему он такой тупой?», нужно спрашивать «как изменить процесс так, чтобы такое больше не повторилось?». Защита от дурака существует не потому, что все тупые, а потому что даже самые умные ошибаются.
Харнесс — это обвязка вокруг агента. Твои текстовые инструкции, набор баш-скриптов для верификации бизнес- и архитектурных правил, строгие линтеры, хуки перед коммитом, шаблоны код-ревью — всё это вместе образует харнесс. Это всё то, что направляет и проверяет работу агента в этом конкретном проекте. Направляет весь харнесс, но по-настоящему бьют по рукам только те его части, которые исполняются не по воле агента и способны остановить конкретный переход: например, не дать закоммитить секретные ключи или замёржить в мейн красный коммит.
У каждого элемента харнесса есть три координаты: какой сигнал он использует, в какой момент встречает агента и что способен сделать — подсказать, ограничить или заблокировать. Правило по маске файла (старые-добрые rules/) использует сам путь изменяемого файла и добавляет нужный контекст ещё до решения. Pre-tool-use hook смотрит на намерение вызвать инструмент и может остановить действие до мутации. Гейт работает позже: ищет в результате заранее определённый признак нарушения и не пропускает его дальше. Это не разные оформления одного правила: инструкция просит, маршрутизатор помогает найти нужное, интерфейс делает часть ошибок невозможной, а hook или gate блокирует переход. Это разные инструменты для имплементации правил.
Память — ещё один отдельный адрес. Кроме текущего диалога у некоторых агентов есть собственная долговременная память, куда они могут записывать довольно произвольные выводы. Она способна повлиять на следующие сессии, но не является каноном проекта: запись может устареть, конфликтовать с репозиторием или вообще не попасть в нужный контекст. Поэтому «агент это запомнил» и «процесс это гарантирует» — совершенно разные утверждения. Я бы вообще выключил нативную память, если ваш клиент позволяет это сделать. С другой стороны, есть и вариант её использования для дела, но это уже, что называется, задача со звёздочкой.
Если молчаливое, никем не согласованное решение без помех добралось до кода и никто не остановил процесс, это сильная улика в пользу дыры в харнессе. В твоём процессе может быть точка, где агент не наткнулся на важные правила, а верификационный гейт проспал. Может быть неохваченный путь, ложная зелёная проверка или сознательно пропущенный человеком барьер. Агент шёл по пути наименьшего сопротивления. Как шёл бы и человек-исполнитель 90% времени.
Провалы агента — это указатели на дыры в твоём харнессе.
Слово «адрес» в названии статьи не имеет ничего общего с поиском виноватого. Это не призыв махать плёткой за плохой код и не повод посыпать голову пеплом. Одиночный провал не объявляет весь твой процесс нерабочим. Он даже не гарантирует, что лёгкое исправление удастся сделать после первого же фейла.
Провал даёт лишь улики для расследования. Точные координаты точки приложения усилий ещё предстоит найти, но у тебя, как минимум, появляется отправная точка. Это повод проверить среду, в которой работает агент. И первым шагом в этом расследовании станет репродьюсер — проверяемый срез кода и всей харнесс обвязки, на которой ошибка случилась, и который позже поможет доказать, что дыра действительно закрыта.
Первый порыв, когда видишь провал агента, совершенно естественен. Ты открываешь редактор, руками дописываешь недостающую логику, прогоняешь локальные тесты и со спокойной душой закрываешь задачу. Когда сроки горят и продукт нужно срочно отдавать, быстро исправить конечный артефакт руками — это единственно верный вариант. Никто не запрещает тушить пожар таким образом.
Но предельно важно понимать: ручная правка готового кода — это борьба с последствиями, а не ремонт самого рабочего процесса. Если ты просто поправил файл и пошел дальше, изначальная брешь, допустившая этот фейл, никуда не делась. Завтра агент получит похожую задачу в другом модуле и с абсолютной уверенностью совершит структурно идентичную ошибку. Чтобы разорвать этот круг, нам нужно отложить готовый код в сторону и честно собрать репродьюсер в отдельном рабочем дереве.
Как зафиксировать ошибку в динамике
В классическом программировании мы привыкли, что репродьюсер — это минимальный входной набор данных, на котором программа предсказуемо падает. Для агента такой подход не работает. Репродьюсер провала агента состоит из тройки: твой дословный изначальный запрос, зафиксированное состояние проекта на тот момент (ты же делал коммиты, да?), и действовавший тогда харнесс. Отдельно нужно озаботиться тем, чтобы не протекала память агента.
Ты восстанавливаешь эту тройку и просишь агента сделать работу ещё раз. И здесь кроется главная механика расследования. Нам не нужен один случайный прогон. Нам нужны две серии экспериментов, чтобы увидеть реальную картину в цифрах.
Первая серия — это воспроизведение. Ты запускаешь задачу несколько раз подряд без изменений в проекте. Не нужно пытаться добиться стабильного, стопроцентного фейла. ЛЛМ вероятностны по своей природе. Если ошибка плавает и провал воспроизводится лишь в части случаев, это не значит, что агент кидает монетку вслепую, и это никак не доказывает неоднозначность твоей задачи. Плавающий исход — это базовая доля провалов, которую нам нужно честно замерить.
Вторая серия — это прогоны с направленным вмешательством. Тебе не обязательно менять только одну деталь за раз, ведь реальный ремонт часто бывает составным и затрагивает несколько слоёв. Важно, чтобы вмешательство было чётко описанным: новые проверочные скрипты, обновлённые базовые инструкции или изменённые права доступа к инструментам. После этого ты снова запускаешь серию попыток.
Теперь мы сравниваем доли успеха в двух сериях. Если во второй серии брак перестал пролезать наружу или стал явным, этот успех поддерживает твой диагноз. Он не доказывает его окончательно, но даёт направление куда двигаться дальше.
Ты что, издеваешься???
Я понимаю, что предложенная выше схема крайне сложна в реализации. Я и сам не делаю так каждый раз, когда агент косячит. К этому варианту я прибегаю только в тех случаях, когда работаю с ошибками, которые я ожидаю встретить ещё десятки раз, и от которых хочу избавиться раз и навсегда. Или же когда целенаправленно хочу “спустить” класс задач на более дешёвую модель без потери надёжности. Например, с terra на luna. Или когда слепые фиксы уже испробованы многократно и не помогли.
Я привёл здесь этот фрагмент для того, чтобы самым простым и наглядным образом продемонстрировать концептуальное сходство между верификацией кода и верификацией действий агента. Подходы, которые мы применяем к тестированию кода, переносятся и на тестирование поведения агента. Но здесь приходится учитывать стохастичность, состояние среды, смену моделей и протекание памяти: вместо одного бинарного прогона часто нужны серии экспериментов и сравнение долей, и нужен принципиально новый подход к созданию тестовых стендов. В отличие от юнит-тестирования, здесь каждый тестовый стенд имеет огромную цену. Ближе всего в этом плане подобные тесты к end-to-end тестированию в динамической среде.
Я хочу, чтобы вы хорошо подумали об этом. Ещё раз: подходы из тестирования кода переносятся на тестирование поведения агентов. Не в лоб, конечно, но принципиально переносятся. Переспите с этой мыслью.
Теперь, когда вы уловили ядро моей философии, представляю вам описание более жизненных практик, которые использую сам ежедневно.
Четыре вопроса для расследования
Чтобы приступить к ремонту харнесса, достаточно последовательно задать себе четыре простых вопроса:
- Почему исполнитель свернул не туда?
- Что именно мы будем менять в процессе?
- Где мы могли бы поймать поломку раньше всего, и где дешевле всего?
- Нам нужно мягко подсказать верный путь или жёстко остановить процесс?
Ответы на эти вопросы формируют конкретный план действий. Общего рецепта нет, но усреднённый рецепт примерно такой:
Подсказка или бетонная стена
Допустим, агент постоянно выбирает неправильный инструмент по умолчанию. Вместо подготовленного внутреннего парсера он пишет собственный код с нуля или дёргает внешнюю тяжёлую утилиту. Можно долго уговаривать его в промптах, но корень проблемы находится глубже.
Ремонт здесь — изменить маршрутизацию или ограничить доступность лишних и опасных инструментов. Если неверный путь закрыт на уровне доступа, это не гарантирует правильного выбора: исполнитель может запутаться и в оставшихся вариантах. Но отсечение ложного маршрута может не только предотвращать неправильные вызовы, но и направлять его к нужным инструментам. Как?
Ставим пре-тул хук на web fetch, через который агент кидает внешний вызов. В хуке проверяем: если адрес, куда агент обращается, соответствует адресу того самого тула, вызовы которого мы хотим предотвратить, то блокируем вызов, а в ответе самого скрипта пишем вежливое напоминание использовать уже готовый парсер с достаточно подробными инструкциями про то, как это сделать.
Это как если бы компания перешла с джиры на самописную штуку. И в течение первого месяца куча сотрудников по ошибке продолжала бы заходить в джиру и что-то там делать на уже фактически мёртвых досках. Вместо этого можно было бы на уровне файервола заблокировать старый адрес джиры, и вывесить там статический файл, который напоминал бы сотрудникам, что мы переехали.
Другой пример — работа с существующим контекстом. Исполнитель множит дубликаты сущностей, потому что в упор не видит уже написанные классы. Решение не в том, чтобы кричать на него через AGENTS.md или, не дай господи, в каждом пользовательском промпте.
Вместо этого можно добавить в харнесс удобный поисковый хелпер, понятный индекс файлов или однозначный стандарт именования. Индекс не обязан находить нужную строчку с первого запроса. Но он превращает слепой поиск через grep в проверяемый процесс, где старый код чаще находится вовремя.
Третий случай — сложный синтаксис. Агент ошибается при формировании объёмного вложенного YAML: забывает кавычки, путает уровни вложенности и ломает структуру. Очередная просьба «будь внимательнее с форматом» здесь мало помогает.
Ремонтом может стать типизированная обёртка: интерфейс принимает от агента плоские аргументы и сам собирает из них сложный YAML. Обёртка не убирает возможность ошибиться в данных, но элиминирует целый класс структурных ошибок, перенося риск из хрупкого синтаксиса в понятные переменные.
Четвёртый пример — опасные внешние операции. Агент может случайно отправить реальное письмо пользователям или повредить боевую базу. В таких случаях мы должны управлять рисками: изолированная песочница, безопасные настройки по умолчанию, идемпотентность действий, ask-user хинты, механизм отката — по отдельности или вместе, в зависимости от ставки. Эти инструменты не дают идеальной защиты, но сдерживают возможный ущерб.
Главный урок не в том, что текстовые инструкции бесполезны. Многие рабочие правила остаются текстовыми, особенно когда задача требует контекстного суждения или человеческого вкуса. Но если речь идёт о жёстких границах, ситуация меняется.
Правило, которое должно было останавливать действие, но осталось советом, — это не больше, чем лотерея.
Если нарушение должно останавливать работу, нужен реально исполняемый блокирующий носитель: линтер, тайп-чекер, хук или гейт в контуре проверки. Реальный барьер превращает пожелание в работающее ограничение. Помните: чем надёжнее защита от дурака, тем большего количества проблем вы избегаете.
Карта адресов: куда чинить
Харнесс складывается не из одного файла и не движется по простой лестнице от «слабого» к «сильному». В нём есть несколько разных адресов. Каждый действует в свой момент, использует свой сигнал и чинит свой класс проблем.
| Адрес | Когда действует | Как использовать и где его предел |
|---|---|---|
| Системные, проектные и локальные инструкции | На старте сессии, задачи или при входе в отдельную область проекта | Сюда входят системный промпт, постановка задачи, файлы вроде AGENTS.md и локальные ридмишки в папке. Они задают нормы, приоритеты и маршрут. Но текст сам по себе не гарантирует, что правило загружено, правильно понято и будет соблюдено. |
| Skills, чеклисты и шаблоны | При планировании или выполнении определённого класса работы | Превращают сложную деятельность в повторяемую процедуру: как провести миграцию, ревью или релиз. Хороши там, где важен порядок шагов. Могут быть вызваны не вовремя, пропущены или выполнены формально, если их запуск ничем не удерживается и не проверяется. Частая ошибка — класть сюда декларативные описания. Скилл должен быть глаголом, иначе это knowledge, а не skill. А knowledge лучше класть в другое место. Например, в индексы. |
| Маршрутизаторы, индексы и доставка контекста | Когда агент решает, что читать и где искать. В случае rules по маске файла. | Карты проекта, поисковые хелперы, RAG, MCP-ресурсы, rules по маске файла и подготовленные context packs помогают вовремя найти существующее правило или код. Наличие знания в репозитории ещё не означает, что оно попало в контекст принятия решения. Нужно обязательно указывать в каких ситуациях агент должен использовать каждую из этих штук в инструкциях и подталкивать к использованию в хинтах/хайлайтах. |
| Состояние и память | Между ходами, сессиями и возобновлениями работы | Контекст диалога, собственная память агента, checkpoints, handoff-файлы, план задачи и точный SHA помогают продолжить работу с прежнего места. Память агента может содержать произвольные и устаревшие выводы; устойчивое проектное решение лучше хранить в проверяемом носителе с происхождением и сроком жизни. Также полезно использовать Git history и diff как инструмент для навигации по текущей активности. |
| Инструменты и интерфейсы | В момент чтения, изменения или внешнего действия | Типизированные обёртки, узкие команды и безопасные API убирают хрупкий синтаксис и сокращают число допустимых действий. Они могут сделать неправильную форму невозможной, но не гарантируют правильность смыслового наполнения. |
| Права, sandbox и безопасные настройки | До и во время взаимодействия со средой | Ограничивают доступные возможности и максимальный ущерб: запрещают запись, отделяют production, требуют подтверждения от пользователя, поддерживают идемпотентность или откат. К ним можно также добавить хинты, которые скажут агенту что делать вместо опасного действия. |
| Хуки жизненного цикла агента | Автоматически при наступлении определённого момента: перед tool call, после изменения, перед завершением сессии или коммитом | Hook запускает проверку без отдельного решения агента. Например, pre-tool-use hook способен остановить опасный вызов ещё до мутации. Но он покрывает только те пути, через которые действительно проходит действие; названия и доступные моменты зависят от конкретного runtime. |
| Тесты, линтеры и локальные проверочные скрипты | После изменения артефакта | Проверяют известные бизнес-, архитектурные и технические предикаты. Их полезно превращать в репродьюсеры конкретных классов ошибок. Зелёный результат говорит только о записанных проверках и ничего не доказывает о реализации бизнес-требований. Часто удобно вешать на пре-коммит хук. |
| Гейты перед commit, CI, review и merge | Перед тем как результат станет общей или боевой версией | Делают определённую проверку условием выкатки во внешний мир. Локальный pre-commit hook обычно можно обойти; CI становится настоящим барьером только тогда, когда required checks и правила ветки не позволяют выполнить merge без него. Гейт относится к правилам внешнего мира, и не должен быть завязан на локальные правила. |
| Наблюдаемость, evals и репродьюсеры | Во время исполнения и после провала | Логи, traces, сохранённые входы, повторные прогоны и baseline/intervention серии показывают, что агент видел, какие инструменты вызывал и где изменилось поведение. Они поддерживают диагноз и измеряют долю провалов, но сами ничего не блокируют и не доказывают исчезновение ошибки навсегда. Немного в сторону от основной темы: в статье «Больше логов не докажет, что решал человек» я отдельно разбираю пределы наблюдаемости в процессах, где решение формально подтверждает человек. |
| Git-история и provenance | После ремонта и при его последующем пересмотре | Коммит связывает провал, репродьюсер, изменение правила и проверку. Это адрес, по которому через год можно понять, зачем ограничение появилось и можно ли его удалить. Заголовок коммита без соответствующего содержимого такой связи не доказывает. |
Названия вроде AGENTS.md, PreToolUse, SessionStart или skills зависят от конкретной среды. Здесь важны не имена API, а роли: доставка инструкции, восстановление состояния, ограничение действия, автоматический гейт и сохранение доказательства.
Выбирай не самый привычный носитель, а самый ранний адрес, где уже известны условия возникновения дефекта и механизм способен на них подействовать: дать агенту нужный контекст, сузить пространство допустимых действий или остановить опасный переход.
Чем раньше срабатывает ремонт, тем меньше работы приходится отбрасывать. Правило по маске файла может добавить нужную инструкцию ещё при входе в опасную область. Pre-tool-use hook может остановить опасное действие до вызова тула. Типизированная обёртка может вообще не дать агенту ошибиться в формате. Во всех этих случаях дефект ещё не виден в результате — он только возможен, но харнесс уже знает достаточно, чтобы не дать ему произойти.
Проверка после изменения решает другую задачу: не предотвращает ошибку, а подтверждает, что её сигнатура в коде отсутствует. Но такой гейт возможен лишь тогда, когда у дефекта есть выделенный признак — предикат, который можно проверить. Если признак не сформулирован, призыв «проверить отсутствие ошибок» остаётся таким же чертыханием, как «будь внимательнее».
У причины провала может быть одна координата, но законченный ремонт почти всегда проходит маршрут: наблюдение → доставка правила → проверка или ограничение → репродьюсер → исторический след.
А если не помогло?
Ты восстановил условия, провёл две серии экспериментов, посчитал доли, но во второй серии брак всё равно пролезает в итоговый код. Серии и частоты — рабочий инструмент, но они не дают математической гарантии. Если вмешательство не сработало, перед тобой три пути.
Первый — ты неверно нашёл место. Ты пытался чинить настройки тайп-чекера на финальной проверке, а агент спотыкается гораздо раньше, во время сбора контекста. Он не видел нужных файлов и не прочитал зависимости, поэтому проверки итогового кода его не спасут. Чинить нужно было доступ к информации, а не фильтр на выходе.
Второй — фикс не работает. Новая инструкция может не перекрывать реальный механизм ошибки. Или свежий проверочный скрипт оказался ложно-зелёным и послушно пропускает дефект. Заплатка существует, но на деле она дырявая.
Третий — возможный предел модели. Иногда задача требует объёма неявных знаний или такого контекстного суждения, которое технология пока не тянет. Но этот предел не устанавливается автоматически после одного неудачного ремонта. Это лишь одна из развилок, которую ещё предстоит отличить от ошибки в адресе. Теперь у тебя на руках есть репродьюсер, с которым можно играться на досуге.
Провал как капитал
Какой бы ни оказалась итоговая развилка, зафиксированный итог делает ошибку ценной. Обычно брак только съедает время на ревью. Но он становится капиталом, если превращается в конкретное изменение процесса. Когда ты закрываешь дыру в обвязке, ты делаешь реальный шаг вперёд.
Ошибка, правило, тест, коммит — четыре шага, и ни один не опирается только на память.
Если ты полагаешься на то, что агент учтёт твои гневные выкрики из диалога, ты просто переносишь головную боль на следующую неделю. Обвязка растёт, а вместе с ней растёт и твой кремниевый исполнитель, когда новое ограничение получает подходящий адрес из этой карты и харнесс действительно приводит агента именно сюда в нужный момент.
Здесь возникает соблазн сократить путь и скачать чужой настроенный харнесс. В этом есть логика. Сама форма процесса и та часть инженерного вкуса, которая уже отлита в правила, могут переноситься на новые проекты. Но, как и в случае с кодом, харнесс не может быть универсальным. Для каждой задачи нужна своя обвязка, свой набор правил и верификаций, свой запас прочности. Как и раньше, нет смысла тащить энтерпрайзные подходы в PoC. Однако, как и раньше, хотя бы на уровне представления владеть стоит всеми подходами, как минимум чтобы осведомлённо принимать решение когда какой применить.
Мастерство и личные предпочтения не передаются скачиванием файла. Личные стандарты чистоты кода, негласные правила команды и специфика конкретной архитектуры продолжат требовать настройки по месту. Чужой репродьюсер может подсказать подход, но ремонт собственной обвязки останется твоей ручной работой. Даже агент не сможет решить вместо тебя чего ты хочешь.
Что делать дальше
В следующий раз, когда на проекте случится беда, разбей работу на две части. Сначала восстанови итоговый результат, чтобы не блокировать текущую задачу. А потом переходи к ремонту процесса. Задай себе четыре вопроса, напиши заплатку, откатись, и попробуй снова.
Ощути SDLC своего проекта на кончиках пальцев. Куда агент должен был заглянуть во время исполнения задачи, чтобы избежать этой ошибки, и что он должен был там найти?
Harness Boilerplate: публичное исследование
В подтверждение тезиса этой статьи я опубликовал harness-boilerplate — живой пример того, как описанная здесь обвязка может выглядеть в репозитории. Там есть правила процесса, гейты, репродьюсеры, журнал хвостов, ретро, доставка контекста и несколько способов заставить ограничение встретить агента в нужный момент. Проект будет меняться вместе с моим пониманием того, как должен эволюционировать харнесс в долгоживущей разработке.
Но это не готовый инструмент, который я рекомендую устанавливать широкому кругу пользователей. Это открытая исследовательская работа и приглашение к разговору для специалистов, которым интересно проверять подобные механизмы, находить их границы и развивать их дальше.
Просто скопировать этот харнесс к себе в большинстве проектов будет избыточно. Он добавляет новые ритуалы, точки остановки и стоимость сопровождения. Если не пользоваться ими целенаправленно и регулярно, выигрыша не будет: лишняя обвязка начнёт создавать шум, тормозить работу и приучать обходить предупреждения. В таком режиме она способна сделать процесс хуже, а не лучше.
Поэтому смотреть на репозиторий стоит не как на универсальный starter kit, а как на открытый стенд: забирать из него отдельные идеи, проверять их на собственных провалах и оставлять только те ограничения, необходимость которых будет доказана на вашем процессе.
Нужна помощь с разработкой и внедрением агентских процессов? Forbidden Fundamentals.