Оркестрація кодінг агентів, мульти-модельність, 1М контекст — це маркетинг для тих, хто не пробував

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Це агрегований досвід — мій персонально і публічних інженерів, моїх колег теперішніх та колишніх
Які щодня кодять в ентерпрайзі, створюють свої продукти, безліч різних прототипів: Viktor Tulskyi, The Prime Gen, Theo (t3.chat), Peter Steinberger, Gregory Orosz та безлічі інших прагматичних інженерів
Це не research paper з метриками. Це практичні висновки тих, хто перепробував безліч всього і повернувся до простого.
Хоча я все одно розумію, що мені прилетить СТО відсотків! Це ж dou!
Вибачте dou 😅

ШІ може бути захопливим та корисним, але будуть «але»

Я тішусь ШІ. Щодня використовую. Маю змогу швидше зробити те, в чому колись не розбирався — на рівні PoC, MVP, внутрішньої утіліти, що перетворює п’ятихвилинну дію на секунду, в принципі навіть в роботі.
Зробив екстеншени внутрішні для інфраструктури, консольна утіліта для транскрибування голосу в текст через буфер, macos утіліта для того ж, але зручніше і це буду продовжувати розвивати — це все для мене стало захопливим

Щодня слідкую за тим, що стається в світі ШІ. Щодня пробую щось новеньке.
— Апдейти тулів, сервіси типу Supabase, Vertex, Convex.
— Нові bullshit-бенчмарки від провадйерів
— Нові пейпери про підходи, комбінації промптів, контексти, моделі, токенізацію.

Скільки всього пізнавального — і водночас такого, що не виправдовує очікувань. Але корисного, все, за чим слідкую — ідеї, вже опрацьовані іншими інженерами, компаніями, дослідниками.

А ще — скільки рекламних, продажних, маркетингових відосів. Як хтось собі зробив мультиоркестрацію агентів, і вони йому вирішують задачі самостійно, практично без участі. Демо повної автономії. Красиве, вилизане, переконливе.

І це теж я пробував. Експериментував. Температури, системні промпти, фолбеки, плейграунди з різними модельками. Мультимодельність, мультиагентність, субагенти, RAG.

Все, буквально! Це переливання з пустого в порожнє. Все в деталях руйнується об реальність

Мій шлях у промптінгу виглядав так:

Етап 1: «Пофікси це, ось стектрейс»
Етап 2: Мультимодельність, мультиагентність, оркестрація, RAG, складні системні промпти, температури, фолбеки...
Етап 3: «Пофікси це, ось стектрейс, ось коли виникає, напевно проблемо в цьому»

Різниця між першим і третім етапом — я тепер точно знаю, що треба пофіксити.
Де пошукати, який контекст дати, як сформулювати.

Звуження контексту завжди краще працює аніж 1 МЛН вхідних токенів для написання коду.

Вся та фігня посередині — мультиагенти, оркестрація, RAG — це був маркетинг, який я ковтнув. І який ви теж можете спробувати. Спробуйте! Серйозно. Щоб на власній шкурі зрозуміли, те ЯК воно не працює. І коли воно потенційно може запрацювати.

Але не витрачайте багато часу на це, в довшій перспективі для MVP та на великих проєктах це в деталях робить слабо контрольовані зміни зі своїми унікальними витікающими

Точність

Один з ключових параметрів оцінки LLM для генерації коду — це accuracy. Точність.

Якщо точніше:
— Pass@k, чи пройшов хоча б 1 з k спроб тести
— Pass@1, чи виконав код задачу з першої проби

Не «майже працює», не «потребує доробки». Працює чи ні.

Не «наскільки красиво звучить». Не «наскільки впевнено написано». А наскільки повторювано і правильно.

Accuracy — не єдина метрика. Для брейншторму, аналізу, рев’ю — варіативність може бути корисною. Але для коду, який має компілюватись, проходити тести, працювати в проді — точність більш критичні.

Код або працює, або ні.

Інтерпретатор та компілятор це не творчі особистості які ведуть дискусію з автором, а «пʼятисотка» це не абстракціонізм продакшена

💡 Tip: Найкращий ROI — витратити 5 хв на генерацію промпту (APE/APRO), а не чатитись 30 хв поки модель втратить контекст. Детальніше про це нижче.

Агент/ЛЛМ не «думає».

Вибачте що повторюсь, але LLM це генератор імовірностей наступних токенів. І коли ти ставиш два генератори токенів спілкуватися між собою — ти не отримуєш «команду». Ти отримуєш накопичення галюцинацій з кожним кроком.

А що відбувається з «Accuracy», коли агент А передає результат агенту Б, той — агенту В? Вона падає. Експоненційно. Кожен крок додає варіативності. Кожен крок віддаляє від очікуваного результату.

Мультиагентність — це маркетинговий термін для «я написав кілька промптів і вони викликають один одного».

Мультагентність — це не архітектура. Це сподівання, що LLM магічно зрозуміє контекст, який ти сам не формалізував.

«Але ж Devin, Cursor, Windsurf background agents — вони працюють!»

Працюють. В окремих кейсах. На конкретних врокфловах. Але порівняйте: скільки часу ти витратиш на налаштування Cursor rules, кастомних агентів, власної RAG-системи vs. зрозуміти/розбирати архітектуру проекту, знати, де шукати проблему, і попросити ШІ забрейнштормити варіанти рішення?

Людина, яка розуміє систему + проста розмова з «моделлю» = (частіше отримує) швидше і точніше рішення, ніж жонглювання з мульти-агентними сетапами, який ти тиждень налаштовував.

Субагенти? Charade(бутафорія, декорація, цирк) — як доволі влучно назвав це Пітер Штейнбергер в своєму блог-пості про те як простіше можна працювати з «агентами».
Те, що інші роблять через субагенти — можна ж робити через окремі вікна терміналу.
Повний контроль. Повна видимість контексту. Менше експоненційної прогресії галюцинацій.
І головне — можливість перевірити результат на кожному кроці!

MCP? Маркетинговий спалювач токенів та розпалювач галюцинацій.

Більшість з них мали б бути просто CLI або API-клієнтом.

GitHub MCP з’їдає 23k токенів контексту зі старту. gh CLI робить те саме — «безкоштовно».
Або згенеруй простий скрипт, який дьоргає GitHub API для конкретної задачі — отримаєш передбачуваний результат без магії «а зараз агент сам розбереться завдяки MCP».

MCP дає структурованість? API теж. CLI з правильним форматом виводу — теж. Різниця в тому, що скрипт ти контролюєш повністю, а MCP — чорний ящик, не рідко обмежений, який може повернути що завгодно бо випадково не той тул дьорнув і з’їсти контекст просто тому що ти його ініціалізував в агенті.

MCP для Figma — окрема історія, для фронтенду це реально корисно. Більше маю на увазі MCP для браузера/БД — там профіт сумнівний з практики та більш небезпечний може бути. Думаю не мало хто з вас чув історії про МСР видалив базу, або виявилось що зливав все — тому думайте перед тим як підключати будь який опенсорс мсп, але це ж може стосуватись і будь-якої бібліотеки, так? 😏

RAG для коду?

В ентерпрайзі для пошуку документації, регуляторних вимог, внутрішніх вікі — RAG має сенс. Якщо у вас є ВИДІЛЕНА команда, яка це підтримує — напишіть в коментарях, в яких кейсах воно вам реально допомагає і шо ви з «багатої сімʼї»

Але якщо ти — розробник, який хоче налаштувати собі RAG для власної кодової бази, щоб «модель краще розуміла проєкт» — це оверкіл без велʼю. Сучасні моделі і так добре шукають по коду, якщо дати правильний контекст.
Твій час краще витратити на розбір архітектури/структури, ніж на налаштування векторних індексів.

Окрема ілюзія — контекстне вікно.

«У Gemini мільйон токенів! Можна закинути всю кодову базу!»

Є дослідження «lost in the middle» — модель губить інформацію в середині великого контексту. Так, дослідження старе, і нові моделі показують кращі результати в синтетичних тестах типу «needle in a haystack».
Але навіть Google Gemini 3.0 Pro декларує те саме, чим більше фактів шукаєш одночасно(тобто як в реальній роботі) — точність різько падатиме!

Але на практиці — моїй і колег в ентерпрайзі — великий контекст все одно працює гірше. Не тому, що модель «забуває». А тому що більше контексту = більше шуму = більша варіативність відповіді = нижче «Accuracy».

Порівняй:

• Закинути 500k токенів коду і сказати «знайди і пофікси проблему»
• Розуміти, де потенційно є проблема, і закласти це в контекст — приблизно назву файлу, папки, класу, патерн, репозиторій, репозиторії

Для простих речей — знайти функцію, оновити реалізацію, подивитись де використовується — агенти справляються непогано. Але для комплексніших речай чи комплексному рефакторингу не рідко отримував «шрапнель» зміни, зміни розкидані по проекту, генериться зайвий код, який потім треба прибирати. А особливо це яскраво проявляєстяь в проєкті з влеиким спадком та тех боргом.

Коли даєш більше підказок про структуру — працює стабільніше. Але для цього треба розуміти архітектуру і кодову базу. Мільйон токенів контексту цього не замінить.

Знову ж таки:
ЛЛМ Це машина генерації ймовірностей, не логічний процесор.
Чим більше шуму на вході — тим більше шуму на виході.

Автономність

Автономність агентів працює рівно до моменту, поки задача не виходить за межі демо-сценарію. Перший edge case — і вся «оркестрація» розсипається.

Чому про це не говорять ті, хто продає курси й тулзи? Бо «воно працює на 70% кейсів, а решту треба допилювати руками» — не продає. «Повна автономія» — продає.

Що реально працює?

Ітеративна робота!

Просто говори з моделлю, буквально. Перевір результат. Коригуй. Повторюй. Зупиняй, коли щось йде не так.
Питай: «давай придумаємо різні рішення», «які існують бест практіс для роботи з цими конкретними доменами проблем», «тепер давай зробимо промт для насутної ітерації» (APE/APRO)

Замість сліпого апрува на кожну дію

«Accuracy» росте не від більшого контексту чи кількості агентів. Вона росте від ітерацій під контролем людини, яка розуміє задачу.

Скорше за все:
— Не потрібні вам оверкіл фреймворки з купою абстракцій і конфігурацій. Не потрібні субагенти.
— Не потрібен MCP для кожного сервісу — напиши скрипт, який робить конкретну річ, або взагалі СДК або АПІ.
— Не потрібен мільйон токенів віхдного контексту — потрібен правильний контекст.

Потрібна твоя голова. Твоя технічна експертиза. Твоє розуміння задачі. І модель, з якою ти розмовляєш як з інженером — а не як з магічним оракулом, який все зрозуміє, знайде та вирішить за тебе.

Ні збільшений контекст, ні мультиагентність, ні MCP, ні RAG — нічого з цього не підвищує точність/стабільність саме по собі. Все це — інструменти, які підсилюють експерта. Не замінюють його.

Все інше — сільвер булінг для інвесторів і контент для LinkedIn, продажної презентації очєрєдної бутафорної автономії.

P.S. цей пост не написаний LLM, він транскрибований з монологів з моїм PoC Dictate to Buffer, лінки пруфи використав з загашніка закладок, певні часни з контрприкладами заресьорчені завдяки Claude

P.P.S. більшість моїх роздумів я дійшов сам на основі власних проб і помилок, а потім виявилось що вже це до мене спробували та зробили на більшому масштабі 😅