GPT-5.6 или Claude Fable 5? Хватит выбирать — объединяйте

В новом ролике IndyDevDan формулирует тезис, который стоит запомнить каждому, кто работает с несколькими LLM одновременно: выбор между GPT-5.6 Sol и Claude Fable 5 — сам по себе ошибка. Мультиагентная разработка с ИИ строится не на «или», а на «и»: вместо того чтобы искать единственную лучшую модель, инженеры собирают команду агентов, которые думают параллельно и объединяют результаты. Идея не новая — раньше это называли architect/editor, prompt chaining, agent chaining, сегодня — model fusion. Суть паттерна не меняется, меняется только зрелость инструментов вокруг него.

Model Fusion: почему две модели лучше одной

Автор демонстрирует харнесс с тремя командами: /opinion запускает обе модели параллельно и получает независимые ответы, /fusion отдаёт оба результата третьему агенту-«архитектору», который сводит их в один — с явным указанием, где модели сошлись, где разошлись и что было отброшено, а /autovalidate заставляет одну модель писать валидационный скрипт заранее, до того как вторая начнёт код писать. На простом примере (топ-моделей scikit-learn) Sonnet 5 и GPT-5.6 Terra полностью совпали во мнениях — это не всегда так интересно, куда важнее случаи расхождения. На более сложном кейсе — вставка миллиона строк в SQLite — модели предложили разные стратегии ускорения (set-based CTE, WAL, тюнинг генерации), и agent harness собрал гибридное решение, которое ни одна из моделей не выдала бы в одиночку. Это ключевой аргумент: ценность не в количестве одинаковых агентов, а в разнообразии подходов, как у разных инженеров в одной команде.

Автовалидация вместо ревью: второй ограничитель agentic-разработки

Если первый бутылочное горлышко agentic-инженерии — планирование, то второй — ревью: кто-то должен проверить, что агент действительно сделал то, что нужно. Паттерн /autovalidate решает это иначе: валидационный скрипт с проверками и понятными fail-сообщениями пишется до того, как построена сама фича, и билдер-агент прогоняет его сам, итерируя до зелёного результата. По сути это TDD, перенесённый на уровень оркестрации нескольких моделей: одна модель — валидатор, другая — исполнитель, и обратная связь идёт напрямую между ними, без участия человека в цикле.

Кому пригодится этот agent harness на практике

Для стека, где публикация постов и работа с API уже полностью автоматизированы, идея особенно применима: критичные по стоимости ошибки решения (выбор модели, архитектура промпта, схема БД) можно прогонять через связку из двух моделей с разными сильными сторонами, а не полагаться на единственный вызов Claude API. Автор специально подчёркивает: ценность не в конкретном инструменте («pi coding agent»), а в том, что харнесс кастомизируемый и не привязан к готовому продукту — свой agent harness можно собрать поверх любого API, было бы желание описать промпты для opinion/fusion/autovalidate.

Вывод

Главный урок ролика — методологический, а не инструментальный: мультиагентная разработка с ИИ выигрывает не за счёт более мощной модели, а за счёт архитектуры, которая заставляет разные модели спорить, дополнять и проверять друг друга. Для проектов с автоматизированными пайплайнами это конкретный чек-лист: там, где решение дорого ошибиться, стоит гонять его через opinion и fusion, а не через одиночный запрос к одной модели — даже если эта модель называется Claude Fable 5.