8 рівнів інженерії агентів

Автор: Bassim Eledath

Переклад: Бао Юй

Здатність штучного інтелекту до програмування поступово перевищує наші можливості керувати ним. Саме тому всі ті зусилля, що безперервно підвищують результати у SWE-bench, не узгоджуються з показниками продуктивності, якими дійсно цікавляться керівники інженерії. Команда Anthropic за 10 днів запустила Cowork, тоді як інша команда, використовуючи ту ж модель, не змогла навіть створити прототип (POC — концептуальний доказ) — різниця в тому, що одна команда вже подолала розрив між можливостями та практикою, а інша ще ні.

Цей розрив не зникне за одну ніч, а поступово зменшуватиметься за рівнями. Загалом їх 8. Більшість читачів цієї статті, ймовірно, вже пройшли перші кілька рівнів, і вам не терпиться досягти наступного — адже кожен підвищення рівня означає значний прорив у продуктивності, а кожне покращення можливостей моделі ще більше посилює ці переваги.

Ще одна причина, чому це важливо — ефект командної роботи. Ваша продуктивність значно залежить від рівня ваших колег. Уявіть, що ви — 7 рівень майстерності, і вночі штучний агент допомагає вам з кількома pull-запитами. Але якщо ваш репозиторій потребує схвалення колеги для злиття, і цей колега ще на 2 рівні, і досі вручну перевіряє PR, то ваша пропускна здатність буде обмежена. Тому підвищення рівня колег — вигідно і для вас.

Збираючи досвід роботи з багатьма командами та окремими користувачами, які застосовують AI для допомоги у програмуванні, я помітив таку послідовність розвитку рівнів (хоча вона не є строгою у всіх випадках):

Вісім рівнів інженерії штучного інтелекту

Рівні 1 і 2: автозаповнення та IDE з агентами

Ці рівні я швидко пройду, щоб зафіксувати їх цілісність. Можна пропустити або читати швидко.

Автозаповнення — це основа всього. GitHub Copilot започаткував цю хвилю — натискаєш Tab, і код автоматично доповнюється. Багато хто вже давно забув про цей етап, новачки, можливо, і зовсім його пропускають. Він підходить досвідченим розробникам, які спочатку створюють каркас коду, а потім довіряють AI заповнити деталі.

Спеціальні IDE для AI, такі як Cursor, змінили ситуацію: вони поєднують чат із кодовою базою, що робить редагування між файлами набагато простішим. Але межа — контекст. Модель може допомогти лише з тим, що вона бачить. Іноді вона не бачить правильний контекст або бачить забагато зайвого, що ускладнює роботу.

Більшість людей на цьому рівні також експериментують із режимами планування у вибраних інтелектуальних агентів: перетворюють ідею у структурований покроковий план для LLM, багаторазово його ітеративно покращують і запускають виконання. Це дає хороший результат і є цілком логічним способом зберігати контроль. Однак у наступних рівнях ми побачимо, що залежність від планування зменшуватиметься.

Рівень 3: контекстне інженерство

Тепер починається цікаве. Контекстне інженерство (Context Engineering) — це модна тема 2025 року. Воно стало концепцією, бо модель нарешті може надійно слідувати розумній кількості команд, у правильному контексті. Шумний або недостатній контекст — однаково погано, тому головне завдання — підвищити інформаційну щільність кожного токена. «Кожен токен має боротися за своє місце у підказці» — так тоді проголосила ця ідея.

Одна й та сама інформація — менше токенів, вища щільність інформації (джерело: humanlayer/12-factor-agents).

Практично, контекстне інженерство охоплює набагато більше, ніж здається. Це включає системні підказки та правила (.cursorrules, CLAUDE.md). Це — опис інструментів, оскільки модель читає ці описи, щоб вирішити, який інструмент викликати. Це — управління історією діалогу, щоб довгі сесії не губили напрямок після десятого раунду. І це — рішення, які інструменти відкривати кожного раунду, оскільки надто багато варіантів може заплутати модель — як і людину.

Зараз цей термін рідко чути. Тому що баланс змістився у бік моделей, здатних працювати з більш шумним контекстом і у хаотичних сценаріях зберігати логіку (більший вікно контексту допомагає). Але важливо пам’ятати: витрати на контекст все ще суттєві. Ось кілька сценаріїв, де це залишається вузьким місцем:

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

Велике споживання токенів. Протоколи Model Context Protocol (MCP) і зображення швидко з’їдають токени, змушуючи вас раніше входити у режим «стиснутої сесії» у Claude Code.

Агенти з десятками інструментів витрачають більше токенів на обробку описів інструментів, ніж на реальну роботу.

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

Рівень 4: комбінаційне інженерство

Контекстне інженерство покращує поточну сесію. Комбінаційне інженерство (Compounding Engineering, запропоноване Кієраном Клаассеном) — це покращення для всіх наступних сесій. Це стало для мене і багатьох інших переломним моментом — усвідомленням, що «програмування на інтуїції» — це не лише прототипування.

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

Цикл «планування, делегування, оцінки, закріплення» — кожен раз покращує наступний.

Магія у кроці «закріплення». LLM — безстанний. Якщо він учора знову додав залежність, яку ви чітко видалили, то й завтра він зробить те саме — хіба що ви скажете йому «не роби так». Найчастіше це вирішується оновленням файлу правил CLAUDE.md або подібного, закріплюючи досвід у кожній майбутній сесії. Але слід пам’ятати: спокуса додавати все до правил може бути шкідливою (надмірні інструкції — це майже відсутність інструкцій). Краще створити середовище, де LLM може самостійно знаходити корисний контекст — наприклад, підтримувати оновлювану папку docs/ (детальніше про це у рівні 7).

Практикуючі комбінаційне інженерство зазвичай дуже чутливі до контексту, який їм подають. Коли LLM робить помилки, їхній перша реакція — подумати, чи не бракує їм контексту, а не звинувачувати модель. Саме ця інтуїція робить можливим рівні 5–8.

Рівень 5: MCP і навички

Рівні 3 і 4 вирішують проблему контексту. Рівень 5 — проблему можливостей. MCP і власні навички дозволяють вашому LLM отримувати доступ до баз даних, API, CI-пайплайнів, систем дизайну, а також до таких інструментів, як Playwright для браузерного тестування або Slack для повідомлень. Модель більше не просто думає про ваш кодовий репозиторій — вона може безпосередньо з ним взаємодіяти.

Про MCP і навички вже багато хороших матеріалів, тому я не буду зупинятися на їх визначеннях. Наведу кілька прикладів із власного досвіду: у команді ми маємо спільний навик рев’ю PR, і всі разом його покращуємо (зараз ще вдосконалюємо). Він умовно активується залежно від характеру PR: один відповідає за безпеку інтеграції з базою даних, інший — за аналіз складності, щоб позначити зайву або надмірну архітектуру, третій — за здоров’я підказок, щоб вони відповідали стандартам команди. Також він запускає лінтери і Ruff.

Чому так багато уваги приділяємо навику рев’ю? Тому що, коли агент починає масово генерувати PR, ручний огляд стає вузьким місцем, а не гарантією якості. Latent Space переконливо доводить, що класичний код-рев’ю вже мертвий. На зміну йому приходить автоматизований, послідовний, навичковий огляд.

Щодо MCP, я використовую Braintrust MCP, щоб LLM міг запитувати журнали оцінки та безпосередньо вносити зміни. Також я застосовую DeepWiki MCP, щоб агент міг отримати доступ до документації будь-якого відкритого репозиторію без ручного додавання її у контекст.

Коли кілька членів команди починають писати свої власні схожі навички, їх варто об’єднати у спільний реєстр. Стаття Block (з привітаннями) чудово описує: вони створили внутрішній ринок навичок із понад 100 навичками та сформували пакети для конкретних ролей і команд. Навички та код отримують однаковий статус: pull-запити, рев’ю, історія версій.

Ще один тренд — LLM дедалі частіше використовують CLI-інструменти замість MCP (і, здається, кожна компанія вже випускає свої — Google Workspace CLI, скоро й Braintrust). Причина — ефективність токенів. MCP-сервер кожного раунду вставляє повний опис інструментів у контекст, незалежно від того, чи використовує їх агент. CLI ж навпаки: агент виконує цілеспрямовану команду, і лише релевантний вихід потрапляє у вікно контексту. Я активно використовую agent-browser замість Playwright MCP саме з цієї причини.

Перед тим, як продовжити, зроблю паузу. Рівні 3–5 — це фундамент всього подальшого. LLM у деяких сферах дивовижно сильний, у інших — надзвичайно слабкий. Вам потрібно розвинути інтуїцію щодо цих меж, щоб потім накладати автоматизацію. Якщо ваш контекст шумний, підказки недостатні або неточні, а опис інструментів нечіткий — рівні 6–8 лише посилять ці проблеми.

Рівень 6: Harness Engineering

Ракета справді починає злітати.

Контекстне інженерство зосереджене на тому, що бачить модель. Harness Engineering (інженерія «засобів») — це побудова цілого середовища — інструментів, інфраструктури та зворотного зв’язку — щоб агент міг працювати надійно без вашого втручання. Це не просто редактор, а повний цикл зворотного зв’язку.

Інструментарій OpenAI Codex — це цілісна система спостереження, яка дозволяє агенту запитувати, асоціювати та робити висновки з власних виходів (джерело: OpenAI).

Команда OpenAI інтегрувала Chrome DevTools, інструменти спостереження та навігацію браузера у середовище роботи агентів, щоб він міг робити скріншоти, керувати UI-процесами, запитувати журнали та перевіряти свої виправлення. За допомогою підказки агент може відтворити баг, записати відео, зробити виправлення. Потім він керує застосунком для перевірки, подає PR, відповідає на відгуки рев’ю і зливає — лише коли потрібно людське рішення. Агент не просто пише код, він бачить, що відбувається, і покращує його, — як людина.

Моя команда займається голосовими та чат-агентами для технічної діагностики збоїв, тому я створив CLI-інструмент converse, що дозволяє будь-якому LLM спілкуватися з нашим бекендом у режимі діалогу. Після редагування коду LLM тестує його у реальній системі через converse, і потім ітеративно покращує. Іноді цей цикл самовдосконалення триває кілька годин. Це особливо потужно, коли результати можна перевірити: діалог має слідувати цьому процесу або викликати відповідні інструменти (наприклад, передача на людське обслуговування).

Ключова ідея — механізм зворотного тиску (Backpressure) — автоматизований зворотній зв’язок (типові системи, тестування, лінтери, pre-commit hooks), що дозволяє агенту виявляти та виправляти помилки без людського втручання. Якщо ви прагнете автономності, цей механізм обов’язковий, інакше ви отримаєте «сміттєву машину». Це також важливо для безпеки: CTO Vercel зазначив, що агент, його згенерований код і ваші ключі мають бути у різних довірчих зонах, бо атака через ін’єкцію підказки у логах може змусити агент викрасти ваші облікові дані — якщо все спільне у одному контексті безпеки. Безпечна межа — механізм зворотного тиску: він обмежує, що агент може робити, коли виходить з-під контролю, а не лише що має робити.

Два принципи, що роблять цю ідею яснішою:

Проєктуйте для пропускної здатності, а не для досконалості. Якщо вимагаєте ідеальний результат у кожному запуску, агент буде зациклюватися на одних і тих самих багів, перекриваючи один одного. Краще дозволити дрібні некритичні помилки і зробити фінальну перевірку перед релізом. Так само працюємо і з колегами.

Обмеження — краще за інструкції. Постійне підказування («спочатку зроби A, потім B, потім C») вже застаріло. З мого досвіду, визначення меж ефективніше за списки — агент буде зациклюватися на них і ігнорувати все інше. Кращий підхід — сформулювати бажаний результат і наполягати, щоб агент виконував його, поки не пройде всі тести.

Інша половина Harness Engineering — це забезпечити, щоб агент міг без вашої участі вільно орієнтуватися у репозиторії. OpenAI пропонує: обмежити файл AGENTS.md приблизно до 100 рядків, зробити його індексом для інших структурованих документів і включити їхню актуальність у CI, щоб не покладатися на швидкоплинні тимчасові оновлення.

Коли все це налаштовано, виникає природне питання: якщо агент може сам перевірити свою роботу, орієнтуватися у репозиторії і виправляти помилки без вас — навіщо вам сидіти і контролювати?

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

Рівень 7: бекенд-агенти

Критика: планувальна модель поступово зникає.

Борис Черний, творець Claude Code, каже, що 80% його завдань починаються з планування. Але з кожним новим поколінням моделей ймовірність успіху після планування зростає. Я вважаю, що ми наближаємося до критичної точки: планування як окремий людський етап поступово зникне. Не тому, що планування не важливе, а тому, що модель вже досить розумна, щоб самостійно створювати плани. Але для цього потрібно, щоб ви зробили роботу рівнів 3–6. Якщо ваш контекст чистий, обмеження чіткі, опис інструментів повний, а зворотній зв’язок закритий — модель зможе надійно планувати без вашого контролю. Якщо ні — доведеться слідкувати за планами.

Щоб було зрозуміло: планування як універсальна практика не зникне, воно просто змінить форму. Для новачків воно залишиться правильним підходом (як рівні 1 і 2). Але для складних функцій рівня 7 «планування» вже більше схоже на дослідження: дослідження репозиторію, прототипування у робочому дереві, пошук рішень. І все частіше — це робота бекенд-агента, що виконує ці дослідження.

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

Рециклічний цикл Ralph — популярний спосіб почати: автономний агент повторює запуск CLI для програмування, поки всі пункти з ТЗ не будуть виконані, кожен раз створюючи новий екземпляр із новим контекстом. На моєму досвіді, щоб запустити Ralph правильно, потрібно багато уваги: будь-який недолік у ТЗ рано чи пізно дасть збої. Це — щось на кшталт «відпустив і забув».

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

Dispatch запускає одночасно 5 агентів у паралель через 3 моделі — ваші сесії легкі, агент працює

Останнім часом я активно використовую Dispatch — це мій створений навик для Claude Code, що перетворює вашу сесію у командний центр. Ви залишається у чистій сесії, а робочі агенти у ізольованих контекстах виконують важкі задачі. Планування, делегування і моніторинг — за допомогою диспетчера, а головне вікно залишається для оркестрації. Якщо агент застрягне, він видасть уточнююче питання, а не мовчки провалиться.

Dispatch працює локально, ідеально підходить для швидкої розробки, коли потрібно швидко отримати зворотний зв’язок, легко налагоджувати і без додаткових інфраструктурних витрат. Інструмент Ramp Inspect — це доповнення для довготривалих, автономних задач: кожен агент працює у хмарному ізольованому середовищі з повним набором інструментів. Менеджер продукту виявив UI-баг — позначив у Slack, і Inspect автоматично підхоплює і вирішує проблему, коли ви закриваєте ноутбук. Вартість — складність підтримки (інфраструктура, знімки, безпека), але ви отримуєте масштаб і відтворюваність, яких не дає локальний агент. Рекомендую використовувати обидва — локальні та хмарні.

На цьому рівні з’являється несподівано потужний режим: використання різних моделей для різних задач. Найкращі інженерні команди — не однорідні. У команді різні мислення, досвід, сильні сторони. Аналогічно й у LLM: моделі пройшли різне додаткове навчання і мають різний характер. Я часто делегую реалізацію Opus, дослідження — Gemini, рев’ю — Codex. Це дає колективний інтелект, застосований до коду.

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

Бекенд-агенти відкривають двері для інтеграції CI та AI. Якщо агент може працювати без людського контролю, його можна запускати з існуючої інфраструктури. Наприклад, автоматичний бот оновлює документацію після кожного злиття, створюючи PR для оновлення CLAUDE.md (ми вже так робимо, економлячи час). Інший — сканує PR на безпеку і виправляє вразливості. Третій — оновлює залежності і запускає тести. Хороший контекст, закріплені правила, потужні інструменти, автоматичний зворотній зв’язок — все це працює автономно.

Рівень 8: автономна команда агентів

Поки що ніхто не досяг цього рівня, хоча кілька людей вже рухаються до нього. Це — передова межа.

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

Експерименти з Agent Teams у Claude Code — ранні зразки: кілька інстансів працюють паралельно у спільному репозиторії, обмінюючись даними у своїх контекстах. Anthropic створила 16 агентів для побудови Linux-компілятора з нуля. Cursor запустила сотні агентів, що працювали тижнями, — вони з нуля створили браузер і перенесли код із Solid у React.

Але при цьому виникають проблеми. Без ієрархії агенти стають обережними, застрягають у місці. Anthropic додала CI-пайплайн, щоб запобігти регресії, і ситуація покращилася. Всі, хто експериментує з цим рівнем, кажуть одне: координація багатьох агентів — дуже складна задача, і досі не знайдено ідеального рішення.

Чесно кажучи, я не вірю, що моделі вже готові до такої автономії для більшості завдань. Навіть якщо вони досить розумні, для складних проектів — наприклад, побудови браузерів або компіляторів — вони все ще надто повільні, витрачають багато токенів і економічно нерентабельні (хоча й вражають). Для більшості наших щоденних задач рівень 7 — це справжній козир. Не здивуюся, якщо рівень 8 стане домінуючим у майбутньому, але зараз я зосереджений на рівні 7 — хіба що ви — Cursor, тоді це ваша справа.

Рівень ? (невідомий)

Незворотне питання «а що далі?»

Якщо ви навчилися ефективно керувати командою агентів без зайвих труднощів, інтерфейс взаємодії вже не обов’язково має бути лише текстовим. Голосові взаємодії — голос у голос (можливо, думка у думку?) — з програмними агентами — діалоговий Claude Code, а не просто голосовий перехід у текст — цілком природний наступний крок. Спостерігаючи за вашим застосунком, голосно описуйте послідовність змін і дивіться, як вони відбуваються у реальному часі.

Є група людей, які прагнуть ідеального одноразового генерування: скажіть, що потрібно, і AI ідеально виконає. Проблема у тому, що цей підхід базується на тому, що ми точно знаємо, чого хочемо. Але ми не знаємо. Ніколи не знали. Розробка — це ітеративний процес, і я вважаю, що вона завжди такою і залишиться. Просто вона стане набагато легшою, значно швидшою і позбавить від необхідності постійно переписувати текстові підказки.

Отже, на якому рівні ви зараз? Що ви робите, щоб перейти до наступного?