Роль-разделение это ключ. Когда архитектор только планирует а инженер только исполняет у них нет почвы для спора. Цикл на 3-й итерации у меня появлялся именно когда оба агента имели одинаковые полномочия и начинали переспрашивать решения друг друга. С явными ролями этого нет. Единственное что добавил бы: четкий формат хэндофа между ними — JSON с задачей, критериями готовности и что нельзя менять. Без этого инженер-агент иногда переосмыслял архитектурные решения в процессе.

Точно, роли в оркестраторе как границы в tsx, с явным главенством архитектора над инженером. В моем кустарном над обоими агентами висел мой жесткий блок промптов с постоянной/переменной частями, путаницы/смешения не возникало и на 15-20 итерации. Только начал автоматизацию через Agents SDK с множеством агентов, там целый фреймворк взрослого вайбкодинга)

15-20 итераций без путаницы это хорошая проверка. Промпт с постоянной частью (правила агента, что нельзя менять) и переменной (текущая задача) по сути System Prompt и User Message в явном виде. Agents SDK даёт нормальную структуру под это. Пробовал похожее: жёсткий блок «no architecture changes» в системном промпте инженера снял 80% нежелательных рефакторингов. Как обрабатываешь ситуацию когда инженер-агент находит что архитектурное решение нереализуемо?

У меня нереализуемых решений не возникало, потому что архитектор не генерирует абстрактные схемы, а опирается на обратную связь от инженера, после каждой итерации получает лёгкий архив проекта и пишет док по текущему состоянию. Промпт для инженера содержит конкретные файлы и методы, до 1000 строк. Если мой Codex инженер упирается в техническое ограничение, возвращает мне диагностику с указанием причины. Я или добиваю вместе с ним или кидаю архитектору, тот корректирует план. Agents SDK пока не использовал, только изучаю документацию. В текущей кустарной схеме жёсткое разделение ролей и явный хендоф через JSON с критериями готовности глушит проблему в зародыше

Обратная связь с архивом после каждой итерации это сильно. Когда архитектор видит реальное состояние кода а не только свой предыдущий план он перестаёт уходить в абстракцию. У меня этого не было и архитектор иногда предлагал решения которые инженер просто не мог реализовать в рамках текущей структуры. 1000 строк в промпте инженера с конкретными файлами и методами это интересный выбор. Я ограничивался 8-10k токенами и убирал конкретные пути чтобы не захламлять контекст. Как ты решаешь проблему устаревания когда файлы меняются быстро и промпт перестаёт отражать реальность?

Делал кустарно-кастомный оркестратор под конкретную цель: для некоторого IT кластера - 1) создать проект, как визуальное демо кластера, 2) написать связную документацию кластера, отражающую строительство проекта от нуля до деплоя. Архитектор только в чате, не видит проект, поэтому после каждой итерации получает легкий архив (через скрипт). Инженер лучше Codex, видит проект истину и все остальное (_donors, _sources,...), но не трогая истину, сам делает его копию (гит-версия) и работает в ней. Можно и в саму истину пустить, но я предпочитал строить истину по копии руками, копипастами после добро от архитектора. Мой уникальный объемный промпт писал только раз вначале архитектору. ~1000 строчные prompt-incoming.md (арх - инж) и prompt-outcoming.md (инж - арх) они пишут сами другу другу прямо в проекте, вполне читаемые, но я в них даже не заглядывал. Переменная часть их же промптов отражает текущую фазу, устаревания нет. Каждая итерация 10-15 моих простых действий на маке по шаблону, результат - новый слой в проекте и документации. Без выгорания, глюков, расхождений у агентов, да и у меня)

prompt-incoming.md и prompt-outcoming.md как живой контракт между агентами. Интереснее всего что ты говоришь что не заглядывал в них: значит структура достаточно стабильная. Я сталкивался с тем что агенты переусложняют формат хэндофа если дать им полную свободу: одна итерация JSON, следующая YAML, потом в свободном тексте. Как ты задаёшь начальный формат промптов или они сами выработали структуру?

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

Про свободу агентов соглашусь частично. У меня галлюцинации падали не от свободы, а от обратной связи: когда агент видит реальный результат прошлого шага, он перестаёт фантазировать. Но полную свободу в проде не дал бы. Один раз агент сам переписал слой авторизации, потому что ему так показалось чище. С тех пор держу жёсткий список того что трогать нельзя.

Все так, мой общий принцип - макс эффективности любых динамических систем при соотношении порядка и карт бланш 3/1. Свобода лишь в тех дозволенных агенту 25%. Пускать агента во все 100% тяжкие - приговор задаче)

3/1 хорошая метафора, у меня на практике примерно так же вышло. Те 25% свободы это где агент сам выбирает как реализовать, но не что. Заметил: чем чётче 75% порядка прописаны в начале, тем шире можно дать свободу без риска. Когда границы размыты даже 10% уводят агента не туда. Спасибо за разбор, редко встретишь кого-то кто реально гоняет это в системе, а не на хайпе.

75/25 вообще-то фундаментальный принцип, который впервые увидел в лингвистике много лет назад, как соотношение между предсказуемостью и неожиданностью в осмысленной речи. В природе между порядком и энтропией в живых системах. 100% порядка бессмысленный шаблонный шум, 0% хаос. Интересно, что 75/25 всплывает везде, где система должна быть и стабильной и адаптивной. Спасибо, что тоже поймали этот параллельный слой)

Да, 75/25 похоже на золотое сечение для систем. В коде вижу то же: полностью зарегламентированная архитектура мертвеет и её обходят, полный хаос не масштабируется. Рабочая система всегда где-то между. Было ценно сверить оптику, спасибо за диалог.