Чтобы Codex и Claude не ломали систему я сделал рельсы [revisited]

По совету старожилов я переписал статью с целью улучшения ее "читабельности". Надеюсь в этом варианте она будет читаться легче.

Я начал продуктивно использовать ИИ в разработке ПО еще в начале 2023 года. Ранний chatGPT позволил мне закрыть дыру в моих знаниях конкретной технологии и создать новую подсистему в существующей распределенной платформе меньше чем за неделю. С тех пор я довольно плотно использую genAI/ИИ-агенты для разработки: Codex, Claude, Cursor, многоагентные процессы, отдельные рабочие деревья Git, передачи контекста между агентами, агенты-проверяющие и т.п.

Быстро стало очевидно, что ИИ очень скор на генерацию нового кода. Когда я использовал именно chatGPT и просил помочь с конкретной функцией, проверкой моего дизайна и другими очень четко очерченными задачами, потом переносил код вручную, я имел полный контроль над процессом и стостоянием разрабатываемого ПО.

Но когда я начал переходить на агентную разработку тут же вскрылись проблемы: ИИ-агент легко делает изменения, которые локально выглядят разумными, но глобально ломают систему.

ИИ агент может за несколько минут сделать такой объём изменений, который раньше занял бы у человека часы. И если он не понимает границы системы (а ИИ НЕ понимает что он делает в человеческом смысле этого слова!), то он очень быстро делает не просто "больше кода", а больше хаоса.

Вот неполный перечень проблем с которыми мне очень быстро пришлось иметь дело:

• Ломает бизнес-инвариант;
• Пересекает архитектурную границу;
• Меняет поведение отката;
• Задевает лишние модули;
• Меняет семантику повторных попыток (retry logic);
• Ломает идемпотентность;
• Ухудшает читаемость кода;
• Смешивает несколько несвязанных изменений в один коммит.

TL;DR

Главное что я пытаюсь донести этой статьей и что сделать с помощью контрольных инструкйций для агентов, я сформулировал так:
Your team does not need AI coding agents to write more code. It needs them to stop writing the wrong code!

Я много лет работаю архитектором и разработчиком, наверное поэтому я постоянно думаю про границы системы, инварианты, ответственность модулей, откаты изменений, диагностику и последствия изменений. И я начал собирать небольшой open-source проект:

https://github.com/vadimche/ai-agent-rails-pack

Это набор файлов, шаблонов и правил для репозитория, которые заставляют ИИ-агентов работать не в режиме "сейчас накидаю кода с лопаты", а по более безопасному циклу:

намерение → границы изменения → инварианты → тесты → сравнение изменений с намерением → риск → откат

Это набор инженерных рельсов, который я кладу в каждый новый проект и использую с Codex, Claude, Cursor и похожими инструментами.

А вот у нас был еще такой случай...

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

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

Из-за ограничений контекста, я еще в доисторическую эру, до реальных агентов, использовал несколько чатов в chatGPT, чтобы разделить задачи по уровням от архитектуры до дизайна и написания конкретной функции и тестов к ней. С приходом агентов я начал разделять роли: один агент планирует, другой занимается архитекрутой, третий пишет код, четвертый проверяет написанное, пятый проверяет сборку и тесты. Еще я начал разделять агентов-программистов по языкам программирования.

Это уже дало ощутимые преимущества и повысило производительность. Но выявилась другая проблема. Если рецензенту дать слишком общий запрос, он часто делает поверхностный обзор, как уставший человек на ревью в пятницу вечером. Рецензент становится полезным, когда ему дают не общий вопрос "проверь код", а конкретные вопросы: совпадает ли изменение с заявленным намерением, сохранились ли инварианты, не изменилось ли поведение повторных попыток, не появилась ли новая архитектурная зависимость, есть ли план отката.

У меня есть проект с ботами для торговли на спортивной бирже. Трейдер поставил инвариант для одного из алгоритмов: если матч уже начался и у нас есть открытая позиция, то должна быть выставлена обратная позиция. Агенты, причем от всех ведущих производителей, регулярно ломают это поведение. Новый код выглядит адекватно, тесты проходят, агенты объясняют свои действия вполне убедительно. Но глобально бот становится бесполезным и даже вредным: главное бизнес условие его существования перестает срабатывать.

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

Другая повторяющаяся история: агент решает задачу, а заодно делает небольшую "полезную" уборку рядом. Например, чуть поменял структуру условий, убрал "лишнюю" проверку, объединил две ветки логики, изменил место логирования, поправил соседний класс, потому что так говорит Uncle Bob.

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

Observability/SRE - это наше всё. Неожиданно, но ИИ-агенты хорошо помогают писать диагностику. И конечно плохо понимают, какая диагностика действительно нужна системе, если им это явно не объяснить. Поэтому в проекте я хочу закреплять не только правила изменения кода, но и вопросы для отладки: какой лог докажет правильное поведение, какая метрика покажет регрессию.

Эволюция идеи

В итоге я начал собирать проект:

https://github.com/vadimche/ai-agent-rails-pack

Сейчас это набор файлов, которые можно положить в репозиторий:

• Инструкции для ИИ-агентов;
• Шаблон намерения изменения;
• Реестр инвариантов;
• Шаблон проверки изменений против намерения;
• Шаблон отката;
• Классификация риска;
• Правила тестирования;
• Правила безопасности;
• Шаблон передачи задачи между агентами;
• Шаблон для описания архитектурных границ;
• Пример для критичных сценариев.

Главная идея простая:
перед тем как менять код, агент должен явно зафиксировать:

• Что он собирается решить;
• Что он не собирается менять;
• Какие файлы можно трогать;
• Какие файлы нельзя трогать;
• Какие инварианты нельзя сломать;
• Какие проверки должны пройти;
• Как откатиться назад.

После изменения он должен сравнить фактическую разницу в коде с исходным намерением.

Не "я вроде всё сделал", а:

• Сделал ли я именно то, что обещал;
• Не тронул ли лишнее;
• Не сломал ли инвариант;
• Не изменил ли опасное поведение;
• Есть ли доказательство через тесты или логи;
• Понятен ли пусть отката.

Промежуточные выводы

Первое: ИИ-разработка сильно повышает ценность архитектурной дисциплины.

Раньше можно было сказать: "Не будем душнить, нормальный разработчик и так разберётся". С агентами это не работает. Агент не живёт в системе годами. Он не помнит историю компромиссов. Он не знает, какой некрасивый кусок кода держит редкий, но важный сценарий.

Второе: плохой код менее опасен, чем почти хороший код.

Плохой код видно быстро. Почти правильный код проходит дальше по цепочке проверок.

Третье: рецензирование должно быть не общим, а направленным.

Не абстракное "проверь качество", а проверь инварианты, границы, идемпотентность, расползание изменения, не появился ли новый риск.

Четвёртое: человек всё равно должен оставаться в контуре (human in the loop), как мне было известно еще с середины 90х, когда я только начинал заниматься интеллектуальными системами.

Главное, чтобы человек вытянул когнитивную нагрузку, ему надо помочь и указать правильные точки для принятия решений.

Ожидания от vas3k

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

Интересны любые кейсы:

• где ИИ-агент реально что-то сломал;
• где он сделал локально правильное, но системно опасное изменение;
• где он полез не туда;
• где он поменял поведение, которое не должен был менять;
• где он “почистил” важный старый код;
• где рецензент-агент помог;
• где рецензент-агент оказался бесполезен;
• какие правила вы уже пишете в репозитории;
• как вы контролируете изменения;
• как вы ограничиваете область работы агента;
• как вы боретесь с раздуванием контекста;
• как вы решаете, когда нужен человек.

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

Возможно ли это?

Ссылки

Проект:

https://github.com/vadimche/ai-agent-rails-pack

Первый пост в LinkedIn:

https://www.linkedin.com/posts/chepegin_ai-codex-claude-activity-7462400424663384064-CkHE

Буду рад любому фидбеку: техническому, архитектурному, продуктовому или просто историям "у нас ИИ сделал вот такую дичь".