От Vibe Coding к инженерии: как проектировать production-ready AI-агентов

Галлюцинации нейросетей — это не баг, а фича, которую необходимо обуздать с помощью жесткой «упряжи» из инвариантов и независимых верификаторов. Чтобы превратить ИИ из случайного прохожего в надежного Senior-коллегу, инженерам придется отказаться от хаотичного «vibe coding» в пользу строгой архитектуры с трехуровневой памятью и протоколами, заставляющими человека обосновывать каждый сгенерированный токен.

🛠️ Философия проектирования: от автоматизации к селективности 0:01

Философия селективности: почему «просто автоматизация» не работает 1:43

Большинство туториалов по созданию AI-агентов предлагают простую схему: взять разницу в коде (diff), добавить контекст через RAG и отправить запрос в LLM с просьбой найти ошибки . Однако Аюш Сингх (Ayush Singh) утверждает, что такой подход не пригоден для реального продакшена . Настоящая проблема заключается не в самой автоматизации проверки кода, а в селективности — способности системы определять, какие находки действительно заслуживают внимания Senior-разработчика, а какие являются шумом .

Проектирование системы должно начинаться не с выбора технологий, а с анализа работы опытного рецензента, у которого на очереди 20 пул-реквестов (PR) . Качество проверки первого и двадцатого PR будет неизбежно различаться из-за человеческого фактора: усталости, непоследовательности и потери концентрации . Идеальный AI-агент должен имитировать суждение старшего инженера, фокусируясь на критических аспектах и предоставляя доказательства для каждого замечания . Каждое утверждение агента обязано сопровождаться обоснованием (rationale) и уровнем уверенности (confidence), чтобы разработчик мог быстро оценить релевантность комментария . Ранее в разговоре авторы упоминали, что такая специализация требует разделения ответственности между разными типами агентов.

Пятишаговый цикл проектирования компонентов 2:10

Для создания надежной системы Аюш Сингх предлагает использовать итеративный цикл разработки, который применяется к каждому компоненту архитектуры — от триггеров до оркестратора . Этот процесс состоит из пяти последовательных этапов:

1. Изучение человеческой системы (Mapping the Mess): Необходимо задокументировать, как процесс выглядит сегодня без участия AI . Это включает фиксацию всех микро-решений, которые принимает человек, и ресурсов, к которым он обращается: документации, архитектурных записей (ADR) и контекста кода .
2. Определение контекста и триггеров: На этом этапе вычленяются механические действия и определяются точные условия запуска агента . Триггер должен быть максимально конкретным — например, не просто «поступление претензии», а «письмо на конкретный email с ключевым словом "claims"» . В случае с PR-агентом триггером служит вебхук GitHub .
3. Разделение ответственности (Reasoning across concerns): Рецензент смотрит на код под разными углами: безопасность, читаемость, наличие тестов и соответствие архитектуре . В системе эти направления разделяются между независимыми агентами, каждый из которых обладает своим «скептическим» менталитетом и ищет подтверждения своим выводам .
4. Техническое маппирование: Каждому шагу человеческого процесса назначается технический компонент. Чтение неструктурированных данных доверяется LLM, поиск по кодовой базе — RAG-системам, а критические узлы (финансы, безопасность) закрываются человеческими чекпоинтами .
5. Анализ отказов: Завершающий этап — ответ на вопрос «что может пойти не так?» для каждого модуля . Проектировщик должен заранее предусмотреть стратегии отката (rollbacks) и обходные пути на случай сбоев .

Классификация и предотвращение отказов AI-систем 3:41

Аюш Сингх разделяет потенциальные сбои на две большие категории: инженерные и специфичные для больших языковых моделей (LLM) . Инженерные риски включают технические ограничения инфраструктуры. Например, GitHub дает всего 10 секунд на подтверждение получения вебхука, в то время как работа агента может занимать 90 секунд и более . Для решения таких проблем применяются классические методы надежности: очереди, автоматические повторы (retries) и «предохранители» (circuit breakers), которые изолируют вышедший из строя сервис, не давая обрушить всю систему [18:47, 21:24].

Специфические для AI отказы требуют иных подходов:

• Галлюцинации: Модель может уверенно заявлять о несуществующих ошибках. Борьба с этим ведется через обязательное цитирование источников (citations) и внедрение слоев проверки фактов .
• Дрейф модели (Model Drift): Система, идеально работавшая на тестовых данных, может деградировать в реальности из-за изменения контекста или стратегий пользователей . Решением является мониторинг с алертами и периодическое обновление промптов .
• Отравление цикла обратной связи: Если агент учится на плохих комментариях неопытных разработчиков, качество его работы упадет . Необходимо фильтровать фидбек и постепенно «забывать» (decay) устаревшие данные .
• Человеческое «бутылочное горлышко»: Если система эскалирует на человека слишком много задач, это создает очередь. Здесь критически важно планирование пропускной способности (capacity planning) и приоритизация задач на основе бизнес-требований [23:55, 24:08].

Особую опасность представляет проблема «почти правильных» ответов (Almost right problem), когда агент корректен на 90%, но в критических 10% совершает неуловимую, но опасную ошибку . Для борьбы с этим Аюш Сингх рекомендует внедрять случайные аудиты и флаги для вывода с низкой уверенностью .

🤖 Уровни автономии и архитектура специализированных агентов 25:02

В проектировании ИИ-систем степень участия человека не является константой; она напрямую зависит от критичности задачи и зрелости самой технологии. Аюш Сингх (Ayush Singh) подчеркивает, что полная автоматизация допустима только для рутинных и обратимых задач с низкими ставками . Если же на кону стоит репутация компании, система должна генерировать лишь черновик, ожидая верификации человеком перед отправкой . Оптимальный сценарий для сложных систем — когда ИИ берет на себя простые случаи, а человек подключается только при возникновении аномалий или при низком уровне уверенности модели .

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

1. Цена ошибки: Если неверный комментарий о стиле кода — это просто досада , то пропущенная SQL-инъекция может стать катастрофой для безопасности всей системы .
2. Обратимость: Автоматический комментарий в PR можно легко удалить, но выполненную миграцию базы данных откатить гораздо сложнее .
3. Зрелость системы: Новые системы требуют жесткого контроля со стороны человека, и только по мере подтверждения своей надежности они «заслуживают» право на большую автономию .

Аюш Сингх предостерегает от чрезмерного доверия к агентам на ранних этапах, приводя в пример случай из практики Secondary Labs (SPL) . Их разговорный агент для LinkedIn самостоятельно договорился о встрече с крупным клиентом из Нидерландов, назначив ужин всего через 9 часов после начала диалога . Команда предполагала, что цикл планирования займет минимум 2–3 дня, что дало бы им время на проверку, но агент сработал слишком быстро . Этот инцидент показал, что система может выйти из-под контроля именно из-за неверных архитектурных предположений разработчиков о скорости и логике действий ИИ .

Первые принципы автоматизации код-ревью 34:26

Проектирование системы проверки кода должно начинаться не с выбора библиотек, а с понимания того, какую проблему она решает в реальности. Аюш Сингх предлагает использовать подход «первых принципов»: представить, что автоматизации не существует, и проанализировать, где именно возникают затыки в работе команды . В больших коллективах каждый Pull Request (PR) становится заложником дефицитного ресурса — внимания Senior-инженеров . Очереди могут растягиваться на дни, а качество проверки неизбежно падает из-за человеческого фактора .

Главный враг качественного ревью — усталость (fatigue) . Десятое ревью за день по определению будет менее глубоким и внимательным, чем первое . Это порождает непоследовательность: один и тот же баг может быть замечен утром и пропущен вечером. Следовательно, истинная цель создания ИИ-агента — не замена человека, а возврат (reclaiming) внимания Senior-разработчика за счет автоматизации механических и рутинных проверок .

Система должна работать по принципу селективности, а не максимального охвата . Ранее в обсуждении уже затрагивалась философия избирательности, и здесь она находит практическое применение: агент не должен заваливать автора PR десятками малозначимых замечаний. Его задача — подсвечивать только высокоценные находки (high-value findings), в которых он уверен, и эскалировать спорные моменты на человека .

Специализация агентов: четыре направления анализа 42:37

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

1. Агент по безопасности (Security): Ищет уязвимости, возможности для эксплойтов и утечки данных .
2. Агент по качеству кода (Quality): Проверяет логику на соответствие архитектурным паттернам и стандартам организации .
3. Агент по тестированию (Testing): Выявляет отсутствие граничных случаев в тестах, хрупкие ассерты и пробелы в покрытии .
4. Агент по документации (Docs): Следит за тем, чтобы код оставался читаемым, а документация соответствовала внесенным изменениям .

Такое разделение позволяет агентам оставаться скептичными и требовать доказательств для каждой находки . Вместо расплывчатых фраз вроде «это выглядит странно», агент должен приводить конкретную аргументацию: «в строке 40 переменная может принимать значение null, что приведет к ошибке» . Результаты работы этих четырех специалистов затем объединяются оркестратором в единый структурированный отчет .

Структура выходных данных (Findings) 48:34

Для того чтобы результаты ревью были полезны, они не могут быть просто «потоком текста». Каждая находка (finding) должна иметь строгую структуру данных . Входным триггером системы обычно служит вебхук от GitHub о создании PR , а выходным сигналом — структурированный ответ, привязанный к конкретным файлам и строкам кода .

Аюш Сингх выделяет обязательные компоненты каждой находки:

• Тип агента: Кто обнаружил проблему (безопасность, качество и т.д.) .
• Уровень критичности (Severity): От информационных сообщений до критических багов, требующих немедленной остановки слияния .
• Локация: Точный файл и номер строки .
• Рациональное обоснование (Rationale): Объяснение, почему это считается ошибкой .
• Уверенность (Confidence): Оценка моделью точности своего вывода, что необходимо для принятия решения об эскалации на человека .

Такой подход превращает ИИ из «черного ящика» в прозрачный инструмент, где каждое замечание обосновано и классифицировано, что минимизирует трения между разработчиком и автоматизированной системой .

🧠 Память агента и событийная шина: как превратить LLM в коллегу 50:06

Для того чтобы AI-агент стал полноценным участником процесса разработки, а не просто интерфейсом к LLM, он должен обладать контекстом, сопоставимым с багажом знаний опытного сотрудника. Аюш Сингх подчеркивает, что главная проблема простых реализаций — отсутствие «заземления» (grounding) в реалиях конкретного проекта . Если вы просто передадите дифф (разницу) кода в модель, она сможет найти синтаксические ошибки, но не поймет, нарушает ли этот код архитектурные соглашения вашей компании .

Три уровня памяти: от эмбеддингов до корпоративных правил 57:16

Аюш Сингх выделяет три критических типа памяти, которые необходимы агенту для качественного ревью :

1. Семантическая память (Semantic Memory): Это знание самой кодовой базы — функций, классов и архитектуры . Поскольку невозможно уместить весь репозиторий в контекстное окно модели (это приведет к огромным затратам и галлюцинациям), используется векторный поиск . Код разбивается на чанки, превращается в эмбеддинги и хранится в векторной базе данных (например, Qdrant), что позволяет извлекать только самые релевантные фрагменты для каждого конкретного PR .
2. Эпизодическая память (Episodic Memory): История прошлых взаимодействий . Агент должен «помнить», какие замечания были сделаны в предыдущих ревью, какие из них разработчики оспорили, а какие приняли . Это позволяет избежать повторения одних и тех же ошибок и делает поведение агента последовательным во времени .
3. Процедурная память (Procedural Memory): Это «культурный код» команды и специфические правила . Аюш приводит аналогию: если семантическая память знает, что такое «доса» (блюдо), то процедурная память знает, как именно этот конкретный человек предпочитает её есть . В контексте разработки это соглашения о стиле, специфические для компании паттерны и правила, которые нельзя извлечь простым поиском по коду .

Такая структура памяти превращает агента из «случайного встречного» в «коллегу», который понимает внутреннюю кухню проекта .

Событийная шина (Event Spine) и аудит системы 1:00:52

Доверие к AI-системе невозможно без полной прозрачности её действий. Аюш Сингх вводит понятие Event Spine (событийная шина) — единого хронологического потока всех событий, происходящих внутри системы агентов . Каждое решение, каждый вызов инструмента или обращение к LLM должно записываться как неизменяемое событие .

Это необходимо для решения трех ключевых задач:

• Трассировка и отладка: Возможность восстановить полную цепочку рассуждений (reasoning chain) для любого замечания агента . Если разработчик оспаривает находку, команда должна видеть, какой контекст был извлечен из памяти и какая версия промпта использовалась .
• Аудит и обоснование: Агент должен не просто выдавать результат, но и предоставлять «доказательство» (proof) . Это включает в себя рациональное обоснование (rationale) и уровень уверенности (confidence), что позволяет системе автоматически эскалировать сомнительные случаи на проверку человеку .
• Экономика и стоимость: Мониторинг затрат токенов в реальном времени . Событийная шина позволяет точно подсчитать, сколько стоило каждое конкретное ревью, и выявить аномалии в потреблении ресурсов .

Три измерения данных: память, истина и время 1:12:01

Для реализации описанной архитектуры Аюш Сингх предлагает разделить данные на три функциональные категории («формы данных»), каждая из которых требует своего технологического стека :

1. Memory (Память): Код репозитория и документация. Здесь доминируют векторные представления для семантического поиска .
2. Truth (Истина): Реляционные данные о результатах работы. Это записи о найденных багах, ID проверок в GitHub и финальные решения, принятые людьми (Human-in-the-loop) . Для этих целей идеально подходит классический PostgreSQL .
3. Time (Время): Данные наблюдаемости (observability). Сюда записываются все «спаны» (отрезки работы), задержки (latency) и вызовы API . Это временные ряды, которые позволяют анализировать производительность системы в динамике.

Ранее в разговоре авторы упоминали важность специализации агентов, и именно событийная шина позволяет связать работу нескольких узкопрофильных специалистов (безопасность, тесты, документация) в единый, поддающийся анализу процесс . Без этого «центрального нерва» система превратилась бы в черный ящик, ошибки которого невозможно было бы исправить системно .

🗄️ Единое хранилище на базе Postgres и архитектура обработки вебхуков 1:15:30

Унифицированная модель данных: почему Tiger Cloud заменяет «зоопарк» систем 1:15:30

Традиционный подход к созданию сложных AI-систем часто заставляет разработчиков использовать «зоопарк» из трех и более баз данных: векторную для памяти, реляционную для метаданных и специализированную для временных рядов . Аюш Сингх указывает, что такая архитектура ведет к избыточным расходам на обслуживание, сложностям с пулами соединений и создаёт множество векторов отказа . Если одна из баз данных (например, Qdrant или Postgres) выйдет из строя или произойдет повреждение строки, восстановить целостность системы будет крайне сложно .

Вместо этого предлагается объединить все три формы данных в одной системе. Аюш Сингх делает выбор в пользу Tiger Cloud — управляемой платформы на базе Postgres, которая поддерживает необходимые расширения для AI-агентов . Это позволяет сохранить привычную модель программирования Postgres, но при этом эффективно работать с семантическим поиском и временными рядами . Использование единого хранилища дает системе:

• единый механизм резервного копирования ;
• одну точку входа для запросов (Single Identity) ;
• возможность связывать «память» агента с историей его действий в рамках одного транзакционного контекста .

Масштабируемая память: PG Vector Scale и алгоритм DiskANN 1:18:04

Для реализации памяти агента, способного анализировать PR, необходимо хранить векторные представления (embeddings) кодовой базы . Система эмбеддирует основной репозиторий и сохраняет его в колонку code_chunks . Когда поступает новый PR, агент извлекает только те части кода, которые релевантны изменениям, используя классический RAG-подход . Однако при работе с миллионами строк кода стандартный поиск становится узким местом .

Чтобы решить проблему производительности, Аюш Сингх применяет расширение PG Vector Scale, которое он называет «быстрым библиотекарем» для Postgres . Оно добавляет продвинутые индексы, позволяющие находить ближайшие векторы на порядки быстрее стандартных методов . Одной из ключевых технологий здесь является алгоритм DiskANN . Когда объем эмбеддингов достигает миллионов, их невозможно бесконечно хранить в оперативной памяти; DiskANN позволяет строить структуру поиска прямо на SSD, обеспечивая мгновенный доступ к данным без потери точности . Это критически важно для корпоративных систем, где объем индексируемого кода огромен .

Аналитика и контроль экономики агентов через гипер-таблицы 1:21:19

Помимо кода, системе необходимо отслеживать работу самих агентов: когда был вызван LLM, какова была задержка (latency) и сколько стоил конкретный запрос . Для этого используются гипер-таблицы (hyper-tables), которые разбивают данные на временные чанки (например, по дням) автоматически . Это позволяет дашбордам не сканировать всю историю за несколько лет, а обращаться только к свежим срезам данных .

Чтобы еще больше оптимизировать систему, применяются непрерывные агрегаты (continuous aggregates) . Это суммарные таблицы, которые Tiger Cloud обновляет в фоновом режиме. Вместо того чтобы при каждом обновлении дашборда пересчитывать стоимость 10 миллионов вызовов LLM, система просто читает готовое значение из агрегата . Это имеет прямое влияние на «экономику агентов»:

1. Система мониторит метрики P95 latency и общий расход токенов .
2. Если дневной бюджет на использование LLM превышен, агент может быть заблокирован до вмешательства человека .
3. Аудит и отслеживание решений агента становятся прозрачными благодаря хранению истории рядом с метаданными .

Архитектура Stateless Ingress: борьба с тайм-аутами GitHub 1:28:32

Процесс код-ревью начинается с триггера — вебхука от GitHub при создании PR . Здесь возникает технический конфликт: GitHub ожидает подтверждения получения вебхука в течение 10–12 секунд . В то же время работа LLM-агента (анализ, рассуждение, формирование вывода) может занимать 30–40 секунд или больше . Если пытаться запустить агента синхронно, GitHub зафиксирует ошибку тайм-аута .

Аюш Сингх предлагает архитектурное решение в стиле «модульного монолита»: разделение на Stateless Ingress сервис (на базе FastAPI) и фоновых рабочих . Процесс обработки вебхука выглядит так:

• Верификация: Проверка подписи (signature) и ключа идемпотентности (idempotency key), чтобы убедиться, что запрос пришел именно от GitHub и не является повторным или вредоносным .
• Очередь: Сервис мгновенно помещает задачу в очередь Redis / ARQ .
• Подтверждение: Система отвечает GitHub статус-кодом 200 («принято») .
• Обработка: После этого отдельный пул воркеров (оркестратор) забирает задачу из Redis и начинает долгий процесс анализа кода .

Такое разделение на «рецепциониста», принимающего заказы, и «шеф-поваров» на кухне позволяет системе выдерживать нагрузку до 10 000 PR в минуту, избегая узких мест при масштабировании . В качестве движка для управления этими сложными рабочими процессами в дальнейшем будет использоваться LangGraph, который позволяет запускать специализированных агентов параллельно .

🏗️ Оркестрация и Genesis Kit: от MVP к надежному AI-инжинирингу 1:40:19

Выбор оркестратора: LangGraph против Temporal 1:40:32

При проектировании системы агентского ревью Аюш Сингх (Ayush Singh) ставит во главу угла вопрос масштабируемости и операционных затрат. На этапе разработки MVP выбор пал на LangGraph, так как этот инструмент обеспечивает легкость интеграции с Python-процессами и позволяет быстро запустить рабочие циклы . Однако Аюш Сингх подчеркивает, что Temporal остается отличным кандидатом для высоконагруженных систем . Temporal превосходно справляется с масштабированием, но требует управления собственными серверами и глубокого понимания форм воркфлоу .

Критически важным архитектурным решением в данном проекте является принцип независимости от фреймворка (framework agnosticism) . Автор настаивает на том, что код не должен быть жестко привязан к конкретной библиотеке оркестрации . Для этого создается абстрактный интерфейс — класс WorkflowEngine, который определяет три основных метода:

1. run — запуск воркфлоу .
2. resume — возобновление работы после остановки или ожидания .
3. get_state — получение текущего состояния конкретного процесса .

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

Фреймворк Genesis Kit для AI-инжиниринга 1:52:19

Для совместной разработки человека и AI-агента Аюш Сингх использует авторскую методологию — Genesis Kit . Это не просто набор скриптов, а полноценный фреймворк для управления контекстом и состоянием проекта. В его основе лежат концепции «инженерии циклов» (loop engineering) и структурного рассуждения, которые являются недостающими деталями в современном агентском ИИ .

Genesis Kit решает проблему так называемого «vibe coding» — интуитивного, но бессистемного написания кода с помощью LLM . Вместо того чтобы просто «кидаться промптами» в модель, фреймворк внедряет строгие петли обратной связи:

• Диагностические циклы: модель должна обосновывать свои решения перед выполнением .
• Петли отладки и исследования: автоматизированные процессы проверки гипотез .
• Гардрейлы (ограничители): механизмы, предотвращающие галлюцинации и отклонение от цели .

Одной из уникальных особенностей Genesis Kit является использование файла done.html . Этот файл служит «якорем» проекта: в нем четко зафиксировано, что именно считается выполненной задачей . Агентам строго запрещено редактировать этот файл — это прерогатива человека, что предотвращает дрейф целей, когда AI-агент начинает подстраивать описание задачи под тот результат, который ему легче выдать . Все промежуточные знания и память проекта хранятся в «хребте Genesis» (Genesis spine), что позволяет команде сотрудничать с агентом, не теряя контекста даже при перезапуске сессий .

Управление контекстом и экономика токенов 1:55:49

Работа с большими моделями вроде Claude Opus или Fable требует бережного отношения к бюджету токенов. Аюш Сингх формулирует жесткое правило: если модель сгенерировала хотя бы один токен, она должна оправдать его ценность для результата; в противном случае подход к промптингу нужно менять .

В рамках Genesis Kit реализована стратегия маршрутизации моделей (model routing):

• Для планирования и высокоуровневой оркестрации (роль Planner) используются мощные модели типа Opus .
• Для механической работы, написания тестов или простого кодинга Genesis Kit принудительно спавнит более дешевые и быстрые агенты на базе Haiku или Sonnet 3.5 .

Автор подчеркивает, что Genesis Kit обеспечивает «чистое» состояние проекта, предотвращая перегрузку контекстного окна лишними данными . Ранее в разговоре упоминалась важность наблюдаемости, и здесь она реализуется через интеграцию Genesis с OpenTelemetry, где каждый шаг агента фиксируется в гипер-таблицах событий . Это позволяет не только отлаживать логику, но и отслеживать стоимость каждого ревью в режиме реального времени . Если стоимость анализа PR превышает заданный лимит, система может автоматически остановить процесс . Таким образом, AI-инжиниринг превращается из «магии» в предсказуемый и контролируемый процесс сборки программного обеспечения .

🛠 Контроль качества через независимую верификацию этапов 2:05:29

Система «когнитивных шлюзов» и принудительная демонстрация 2:05:42

В процессе проектирования сложных систем на базе ИИ-агентов Аюш Сингх (Ayush Singh) выделяет важность «когнитивной работы», которую невозможно полностью шаблонизировать из-за обилия бизнес-решений . Чтобы гарантировать качество кода, который генерирует агент, автор вводит концепцию пяти «шлюзов» (gates), через которые должен пройти результат . Одной из самых ярких находок является система «упряжи» (harness), которая заставляет кодинг-агента не просто заявлять о готовности задачи, а доказывать её работоспособность через конкретные демонстрационные команды .

Для каждого этапа разработки (Milestones) прописывается своя демо-команда. Например:

• Для сервиса приема вебхуков — это выполнение curl с подписанными и неподписанными данными для проверки безопасности .
• Для этапа оркестрации — запуск четырех параллельных узлов, их принудительное завершение и последующее восстановление из контрольной точки (checkpoint) .
• Для RAG-системы — выполнение гибридного поискового запроса по чанкам кода .

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

Независимый агент-верификатор и работа с инвариантами 2:22:03

Ключевым механизмом контроля в архитектуре Аюша Сингха выступает независимый агент-верификатор. После завершения каждого этапа или фазы вызывается отдельный LLM-агент, задача которого — проверить работу основного агента на соответствие установленным инвариантам . Инварианты в данном контексте — это не подлежащие обсуждению правила системы, которые не могут быть нарушены ни при каких обстоятельствах .

В качестве примеров таких «жестких» правил Аюш приводит следующие:

1. Каждая нагрузка (payload) вебхука GitHub должна проходить проверку подписи .
2. Любая доставка события должна быть дедуплицирована с помощью ключа идемпотентности .
3. Каждый вывод специалиста (finding) обязан содержать уровень уверенности (confidence) и рациональное обоснование (rationale) .

Для того чтобы верификатор имел актуальный контекст, используется файл implementation_notes.md. Это «живое состояние» системы, которое обновляется в реальном времени и содержит информацию об активных циклах, текущих блокировках и пройденных фазах . Верификатор сопоставляет написанный код с этим документом и «графом контекста» (context graph), чтобы убедиться, что изменения в одной части системы не нарушили работу других компонентов и не потребовали написания новых тестов . Ранее в разговоре автор упоминал важность структуры выходных данных, и здесь верификатор следит за тем, чтобы эта структура строго соблюдалась.

Пять шлюзов качества и управление бюджетом токенов 2:26:53

Процесс верификации вплетен в жизненный цикл каждого этапа через пять специфических шлюзов, проверяющих состояние системы после выполнения процедуры G0 (первоначальной инициализации этапа) . Верификатор проверяет:

• Загружены ли правильные навыки (skills) для текущей задачи .
• Записаны ли все действия в контрольную точку (checkpoint) .
• Привело ли итеративное действие к измеримому прогрессу в достижении цели этапа .
• Не превышен ли установленный бюджет токенов для конкретной задачи .
• Соответствует ли итоговое качество требованиям независимого чек-листа, основанного на демо-команде .

Для управления стоимостью Аюш использует разные модели: дешевые (Haiku или Sonnet) для рутинных проверок и более дорогую Opus для сложных аналитических задач . У каждого этапа есть свой «бюджет токенов», за пределы которого агент не должен выходить, что предотвращает бесконечные циклы правок .

Если верификация провалена, система запускает цикл отладки (debug loop) . Если же все проверки пройдены, создается финальный артефакт этапа, такой как done.html — заблокированная спецификация (locked spec), которая фиксирует когнитивную задачу, уровень автономности и методы обработки отказов для данного компонента . Это создает надежный фундамент для перехода к следующему этапу разработки, исключая накопление ошибок в архитектуре.

🤖 Протокол 'Quiz Me': AI как ментор и экзаменатор 2:30:38

На этапе реализации сложных систем, таких как многоагентный ревьюер кода, Аюш Сингх (Ayush Singh) подчеркивает критическую проблему: разработчики часто принимают код от AI без глубокого понимания того, как он работает . Для решения этой проблемы в рамках фреймворка Genesis Kit был разработан протокол «Quiz Me» — интерактивный механизм проверки, который превращает процесс разработки в процесс обучения .

Интерактивная верификация через 'Quiz Me' 2:36:36

Протокол 'Quiz Me' — это не просто формальный опрос, а инструмент, гарантирующий, что инженер полностью контролирует архитектурные решения . Прежде чем пометить веху (Milestone) как завершенную, система инициирует сессию вопросов и ответов. Это происходит после того, как основной агент-строитель закончил свою работу, а независимый верификатор уровня L4 подтвердил корректность кода .

Аюш Сингх (Ayush Singh) отмечает несколько ключевых аспектов этой проверки:

• Изоляция контекста: Верификатор L4 — это отдельный агент, который получает только цели, критерии успеха и инварианты системы . Он не видит логов агента-строителя, что позволяет ему проводить непредвзятую оценку .
• Борьба с безответственностью: Главная цель протокола — лишить разработчика возможности заявить: «Это было решение AI, а не моё» .
• Обучающий момент: Вместо того чтобы просто прочитать код, инженер должен объяснить логику обработки пограничных случаев и выбора конкретных статус-кодов .

В случае обнаружения несоответствий между утверждениями строителя и выводами верификатора запускается цикл отладки (debug loop) . В этот момент система автоматически добавляет регрессионные тесты, чтобы гарантировать, что исправление одной ошибки не сломало другие части функционала .

Разбор кейса: Безопасность вебхуков и архитектурные компромиссы 2:40:13

В качестве примера Аюш Сингх (Ayush Singh) демонстрирует работу протокола на этапе настройки приемника вебхуков от GitHub . Система задает инженеру ряд вопросов, проверяя его понимание безопасности и семантики HTTP.

Первый вопрос касается последовательности действий: стоит ли проверять HMAC-подпись до начала любой обработки данных? . Правильный ответ, по мнению Аюша, заключается в том, что верификация должна идти первой, чтобы не тратить ресурсы сервера на обработку потенциально вредоносных запросов от неавторизованных источников . Это напрямую коррелирует с инвариантами системы о безопасности данных .

Второй важный аспект — выбор HTTP-статуса при получении поврежденного (malformed), но корректно подписанного JSON . Агент спрашивает: является ли статус 400 (Bad Request) правильным в этом случае? . Аюш Сингх (Ayush Singh) поясняет, что статус 400 корректно сообщает клиенту об ошибке в теле запроса, в то время как статус 500 ошибочно указывал бы на внутреннюю проблему сервера . Такое понимание помогает избежать ложных срабатываний систем мониторинга и упрощает отладку интеграций .

Третий вопрос затрагивает долговечность данных: допустимо ли для Milestone 1 использовать маршрутизатор задач (job router), работающий только в оперативной памяти? . Инженер должен подтвердить, что на текущем этапе (M1) целью является лишь установление контракта на вход (ingress contract) . Хотя в последующих вехах, таких как M4, этот компонент будет заменен на решение на базе Redis для обеспечения отказоустойчивости, для начального тестирования локальный механизм очередей приемлем .

Отладочные циклы и переход к новым этапам 2:46:33

После успешного прохождения опроса и подтверждения верификатора Milestone 1 получает статус M1 approved . На этом этапе срабатывает «выходной протокол»: обновляются файлы плана проекта (plan.md), логи прогресса и заметки по реализации . Аюш Сингх (Ayush Singh) показывает, что система фиксирует известные пробелы (known gaps), такие как необходимость замены заглушки очереди на полноценный Redis в будущем .

Переход к Milestone 2 (M2) начинается с настройки инфраструктуры. Аюш Сингх (Ayush Singh) демонстрирует использование CLI и MCP-инструментов для управления облачными сервисами в Tiger Cloud . Процесс включает:

1. Повторную аутентификацию: Использование специальных ссылок для входа и авторизации CLI .
2. Создание ресурсов: Запуск сервисов с выделенным CPU и поддержкой расширений для работы с временными рядами и векторными данными (например, PGVector) .
3. Применение миграций: Агент напрямую через MCP применяет схемы базы данных к живому сервису .

В ходе реализации M2 Аюш Сингх (Ayush Singh) подчеркивает важность неизменяемости данных: все события агентов должны только дописываться (append-only) и быть доступными для трассировки . Это позволяет системе сохранять прозрачность и воспроизводимость всех действий, совершенных AI-агентами в ходе разработки.

🛡️ Обеспечение целостности: инварианты базы данных и мощь гипер-таблиц 2:56:28

На финальных этапах проектирования системы Аюш Сингх (Ayush Singh) переходит к самому фундаменту — уровню хранения данных, где архитектурные принципы превращаются в жесткие правила. В контексте разработки многоагентных систем база данных перестает быть просто хранилищем и становится активным участником процесса верификации, обеспечивая соблюдение инвариантов на уровне движка . Это гарантирует, что даже при сбоях в логике отдельных агентов, целостность всей системы ревью кода останется непоколебимой.

Неизменяемость и жесткие инварианты данных 2:56:41

Одним из ключевых элементов дизайна Аюша является использование драйвера контекста ENV4, который обеспечивает соблюдение инвариантов непосредственно на уровне базы данных, а не просто в виде соглашений в коде . Это критически важно для создания «дымовых тестов» (smoke tests), которые проверяют работоспособность системы против живых сервисов . Когда агент записывает событие, система автоматически проверяет соответствие всем установленным правилам .

Центральный инвариант системы гласит: события агентов (agent events) никогда не могут быть удалены . Это превращает таблицу событий в бесконечный лог, где данные живут вечно, обеспечивая полную прозрачность и аудит всех действий AI-агентов. При запуске верификатора L4 система проверяет инфраструктуру данных Tiger Data, подтверждая работоспособность расширений для провижининга и корректную настройку механизмов . Аюш подчеркивает, что такая архитектура позволяет легко принимать решения на основе «переключателей» (decision switches) и успешно проходить все контрольные точки (gates) жизненного цикла разработки .

Гипер-таблицы TimescaleDB и проблема правил SQL 2:59:13

Для управления огромным потоком событий, генерируемых мультиагентной системой, Аюш использует специфические механизмы TimescaleDB — гипер-таблицы (hyper-tables) и непрерывные агрегаты (continuous aggregates) . В отличие от обычных реляционных таблиц, гипер-таблицы автоматически распределяют данные по множеству «чанков» (chunk tables) . Однако эта мощь накладывает определенные ограничения на использование стандартных инструментов PostgreSQL.

В процессе обучения через протокол верификации (ранее упоминавшийся в контексте обучения разработчика) Аюш разбирает важный технический нюанс: почему для защиты данных от изменений были выбраны триггеры, а не правила (rules) Postgres . Проблема заключается в том, что правила SQL реализуются на этапе перезаписи запроса (query rewrite stage), тогда как гипер-таблицы TimescaleDB, распределяя данные, не поддерживают перезапись правил . Попытка создать правило на гипер-таблице приведет к ошибке, поэтому триггеры остаются единственным надежным способом обеспечения неизменяемости событий .

Мониторинг, трассировка и обработка краевых случаев 3:00:13

Реализация этапа M3 (Milestone 3) фокусируется на записи каждой операции в базу данных для обеспечения сквозной наблюдаемости (observability) . Каждое действие, полученное через входящий вебхук, создает новую строку в agent_events . Это позволяет разработчику быстро извлекать полные трассировки (traces) работы агентов, что необходимо для отладки сложных цепочек рассуждений в мультиагентной среде .

Аюш также обращает внимание на опасные краевые случаи (edge cases), которые выявляются независимыми верификаторами:

• Команда TRUNCATE против DELETE: Если вызвать TRUNCATE вместо DELETE, стандартные триггеры уровня строки (row-level triggers) не сработают, так как это команда с отдельным путем исполнения в SQL . Для полной защиты данных необходимо вешать отдельные триггеры BEFORE TRUNCATE .
• Несоответствие размерности векторов: Если в файле окружения (.env) указана размерность эмбеддингов 256, а модель выдает 1536, расширение PG Vector выдаст ошибку . Система не будет автоматически обрезать или дополнять вектор нулями, что приведет к сбою при попытке вставки данных .

В завершение курса Аюш Сингх призывает сообщество использовать Genesis Kit для самостоятельной сборки агентов и подчеркивает, что настоящая ценность заключается в глубоком понимании каждого архитектурного решения — от событийной шины до тонкостей настройки базы данных . Участникам, успешно реализовавшим расширенную версию PR-ревьюера, обещаны призы, но главным вознаграждением станет навык проектирования надежных AI-систем .