Після промпту: народження армії агентних циклів

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

Чат більше не виглядає як чат

Ще недавно взаємодія з AI виглядала просто.

Ти відкривав ChatGPT або Claude. Писав запит. Чекав. Копіював текст. Виправляв. Знову писав. Знову чекав. Знову копіював.

Це була епоха промпту.

У ній центральним героєм був користувач, який намагався знайти правильне формулювання. «Напиши як senior developer». «Дій як McKinsey consultant». «Постав мені 10 уточнювальних питань». «Не галюцинуй». «Будь точним». «Пиши без води». «Think step by step».

Це справді працювало. Певний час.

Але в травні 2026 року стало видно, що ця логіка вже застаріває. Не тому, що prompt engineering зник — він залишився як один із шарів. А тому, що він перестав бути центром системи.

Тепер головне питання вже не «як сформулювати запит?».

Воно інше:

Це вже не чат. Це **операційна система**.

OpenAI 5 травня викотив у ChatGPT memory sources — можливість бачити, які саме saved memories, минулі чати, custom instructions, файли або підключений Gmail вплинули на відповідь. Пам’ять перестає бути містичним чорним ящиком і стає видимим робочим шаром. ^[1]

За дев’ять днів OpenAI викотив Codex у мобільний ChatGPT. І тут важлива не сама «мобілка». Важливо інше: Codex тепер можна вести як живого віддаленого працівника. З телефону можна бачити активні threads, project context, screenshots, terminal output, diffs, test results, approvals, перемикати моделі або запускати нову задачу. Понад 4 мільйони людей уже використовують Codex щотижня. ^[2]

Це радикальна зміна UX.

AI більше не сидить у чаті й не чекає одного ідеального запиту. Він працює в середовищі. Бачить файли. Запускає тести. Пише diff. Чекає approve. Має hooks. Підключається по Remote SSH. Залишає сліди.

Промпт стає лише кнопкою запуску.

Робота відбувається в циклі.

Кінець магічного промпту

У старій епосі prompt engineering був схожий на шаманство.

Люди збирали «ідеальні промпти». Колекції команд. Ролі. Секретні формули. Markdown-шаблони. «Ultimate Claude Code prompt». «Best ChatGPT prompt for developers». «One prompt to build your SaaS».

Це було природно. Коли інструмент новий, люди намагаються керувати ним мовою.

Але з часом стало ясно: один великий prompt — це поганий спосіб управляти складною роботою.

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

І найгірше: він не масштабується.

Один prompt може допомогти написати текст, виправити функцію або пояснити помилку. Але він погано тримає довгий процес:

• дослідити тему;
• зібрати джерела;
• створити структуру;
• написати код;
• розгорнути на сервері;
• перевірити;
• отримати фідбек;
• внести правки;
• оновити пам’ять;
• зробити наступну версію.

У такому процесі prompt — лише один шар. Поруч із ним є контекст, пам’ять, tools, hooks, permissions, runtime, evals, logs, sandboxes, human approvals.

DataHub у квітні сформулював це прямо: prompt engineering оптимізує те, як ти формулюєш інструкцію, а context engineering управляє всім інформаційним середовищем, у якому працює модель. У їхньому дослідженні 82% IT і data-leaders сказали, що prompt engineering alone вже недостатній для AI at scale, а 95% вважають context engineering важливим для масштабування агентів. ^[3]

Різниця величезна.

У першому випадку людина шліфує формулювання. У другому — будує систему доставки правильного контексту в правильний момент.

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

Так само з AI. Модель може бути дуже розумною. Prompt може бути красивим. Але якщо контекст поганий, пам’ять шумна, tools невпорядковані, а approval logic не визначена — система буде ламатися.

Нова формула сили: не модель, а цикл

Стара AI-логіка мислила платформами.

GPT. Claude. Gemini. Llama. Grok. DeepSeek. (Який саме фронтір-моделі підбирати під яке завдання — окрема стаття, бо ландшафт швидко змінюється.)

Нова логіка мислить циклами.

намір
  → контекст
  → агент
  → інструменти
  → артефакт
  → перевірка
  → фідбек
  → пам'ять
  → наступна ітерація

У старій логіці ти питав: «Яка модель найкраща?»

У новій логіці треба питати:

• як агент отримує контекст?
• які tools він може викликати?
• де він має право писати?
• коли він має зупинитися?
• що він логуватиме?
• хто approve-ить ризикові дії?
• як результат перетворюється на наступний цикл?
• що з цього зберігається в пам’ять?
• які помилки стають eval tests?

Це вже не магія відповіді. Це інженерія повторення.

LangChain у звіті State of Agent Engineering пише, що 57.3% опитаних уже мають агентів у production, ще 30.4% активно розробляють агентів із планами deploy. Найбільший production-блокер — якість, її назвали 32% респондентів. Observability уже впровадили 89% організацій, тоді як evals мають лише 52.4%. ^[4]

Ці цифри показують одну річ: агенти вже не демо. Вони стали робочою інфраструктурою. І тепер головний біль — не «як змусити модель щось написати», а як зробити її роботу надійною.

## Codex у кишені: агент як віддалений працівник

OpenAI назвав травневий реліз просто: «Work with Codex from anywhere».

Формально це мобільний доступ до Codex у ChatGPT app. Але культурно це зовсім інше — це перший масовий образ AI coding agent як процесу, який не закінчується відповіддю в чаті.

Ти запускаєш задачу на ноутбуці, Mac mini або devbox. Агент працює у твоєму середовищі. Він бачить project context. Запускає команди. Виводить terminal output. Створює diff. Робить screenshots. Запускає tests. Питає дозволу.

Ти в цей момент можеш бути в таксі, на прогулянці, у спортзалі або між дзвінками — і з телефону дати йому рішення.

Це не «писати код на телефоні». Це керувати циклом виконання з телефону.

OpenAI прямо пише: маленький check-in може не дати роботі зупинитись, уникнути unnecessary rework або допомогти Codex рухатись із правильним контекстом. Звідси і набір дій: review outputs, approve commands, change models, start something new. ^[2]

Це дуже важливий момент для всіх, хто працює з AI.

Людина більше не сидить перед моделлю як оператор текстового поля. Людина стає диспетчером довгих задач.

людина:
  ставить намір
  дає обмеження
  ухвалює рішення
  перевіряє результат

агент:
  читає код
  викликає tools
  пробує варіанти
  створює артефакт
  повертає evidence

Це новий rhythm. Не «один запит — одна відповідь». А «одна задача — багато мікровтручань».

У цьому сенсі смартфон стає не пристроєм для споживання AI, а пультом управління агентом.

Claude Code і проблема довгих циклів

Anthropic теж рухається не просто в бік розумнішої моделі, а в бік довшого execution loop.

6 травня Anthropic подвоїв п’ятигодинні Claude Code rate limits для Pro, Max, Team і seat-based Enterprise планів, прибрав peak-hours limit reduction для Claude Code на Pro і Max, а також суттєво підняв API limits для Opus models. У тому ж релізі — partnership зі SpaceX, що дає доступ до понад 300 MW нової capacity і понад 220 000 NVIDIA GPUs протягом місяця. ^[5]

Ці цифри звучать як infrastructure news. Але насправді це новина про UX.

Чому AI coding tools так швидко впираються в ліміти?

Бо агентна розробка спалює не «повідомлення». Вона спалює цикли.

Агент читає репозиторій. Шукає файли. Пробує патч. Запускає тести. Отримує помилку. Читає лог. Переписує. Запускає знову. Робить diff. Дає summary. Чекає людини. Продовжує.

Це довга сесія. Може тривати хвилини або години.

LangChain описує це так: long-running agents потребують durable execution, memory, multi-tenancy, human-in-the-loop і observability. Агент може працювати хвилини або години, чекати human approval, переживати deploy або crash, і не втрачати прогрес. ^[6]

Тобто справжній bottleneck — не тільки intelligence.

Справжній bottleneck — тривалість і надійність циклу.

Якщо агент не може працювати довго, він залишається autocomplete.

Якщо може працювати довго, зберігати стан, питати дозволу, відновлюватися і залишати audit trail — він стає працівником системи.

Control plane: де насправді йде нова війна

VentureBeat 15 травня дуже точно назвав наступний фронт: не model war, а agent control plane.

Ідея проста: компанії вже не просто обирають, яка модель відповідає краще. Вони обирають, де житиме операційна машина AI: у Microsoft stack, OpenAI API layer, Anthropic managed runtime, open framework або hybrid mix.

За VB Pulse, у лютому 2026 Microsoft Copilot Studio і Azure AI Studio мали 38.6% primary-platform adoption серед enterprise agent orchestration respondents, OpenAI Assistants і Responses API — 25.7%, Anthropic tool use and workflows — 5.7% (вибірка маленька, тож VB прямо застерігає від перебільшення). ^[7]

Але навіть із цією обережністю сигнал сильний.

Модель можна змінити. Control plane змінити складніше. Бо саме там живуть:

• permissions;
• memory;
• tools;
• approvals;
• logs;
• auditability;
• sandboxing;
• integrations;
• cost controls;
• security policies;
• workflow state.

У старій AI-логіці vendor lock-in був на рівні моделі. У новій — він на рівні runtime. Це набагато глибше.

Якщо твоя команда зберігає workflows, permissions, memory, hooks і agent tasks в одному середовищі, ти вже не просто «користуєшся моделлю». Ти будуєш операційну тканину навколо неї.

Не «який LLM найрозумніший?». А «де живе моя робота?».

RAG більше не достатній

Ще один зсув: класичний RAG перестає бути універсальною відповіддю.

Кілька років тому було модно казати: «Підключимо документи до vector database, і агент усе знатиме».

Але agentic workflows швидко показали слабкість цього підходу.

Коли агент працює в довгому циклі, йому потрібен не просто пошук документів. Йому потрібна скомпільована структура знання: що є джерелом істини, як пов’язані сутності, які є permissions, які дані stale, який формат потрібен для наступного tool call, що можна викинути з context window.

VentureBeat 4 травня описав це як перехід від RAG pipeline до compilation-stage knowledge layer. У прикладі Pinecone Nexus один financial analysis task, який раніше споживав 2.8 млн токенів, був виконаний із 4 000 токенів — заявлене скорочення на 98% (це внутрішній benchmark Pinecone, ще не customer-validated). ^[8]

Навіть якщо ставитися до цифри обережно, напрям очевидний.

Майбутнє не в тому, щоб закидати модель більшим context window. Майбутнє в тому, щоб давати їй менший, чистіший, структурованіший контекст.

погано:
  усі документи
  вся історія
  всі інструкції
  весь шум

краще:
  релевантні факти
  поточний стан
  чіткі constraints
  потрібні tools
  коротка пам'ять
  evidence links

Великий контекст без дисципліни — це не сила. Це сміття з великим лімітом.

І якщо в цю пам'ять потрапляє шум, агент деградує **ще до того**, як у нього закінчаться токени.

GitHub показав, як не плодити агентів

Один із найкращих практичних прикладів тижня — GitHub accessibility agent.

15 травня GitHub описав експеримент із general-purpose accessibility agent. Його задача — відповідати на accessibility questions у Copilot CLI та VS Code integration, а також ловити й автоматично виправляти прості, об’єктивні accessibility issues до production. Агент уже переглянув 3 535 pull requests і має 68% resolution rate. ^[9]

Але найцікавіше не це. Найцікавіше — архітектура.

GitHub спершу мав monolithic agent, але він швидко вперся в межі. Команда перейшла до sub-agent architecture. Багато гідів радять робити цілий зоопарк агентів, але GitHub виявив, що це працює гірше. Вони залишили лише двох:

1. passive reviewer / researcher;
2. active implementer.

Вони sandboxed і не передають content напряму один одному. Натомість кожен створює structured, templatized output, який parent orchestrating agent споживає, перевіряє і маршрутизує.

orchestrator
  → reviewer
  → structured findings
  → orchestrator validates
  → implementer
  → changes or guidance
  → re-audit

Тут видно нову культуру AI workflow.

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

GitHub прямо пише, що без template schema агенти починали б довільно комунікувати, що створює higher token expenditure, hallucinations, unnecessary code changes і майже неможливий audit. ^[9]

Ще важливіше — GitHub ввів **complexity-based behavior**. Якщо код занадто складний, агент не має права генерувати зміни. Він переходить у guidance-only mode або ескалює людині. Також є high-risk patterns, де агенту **заборонено писати код**: drag and drop, toasts, rich text editors, tree views, data grids.

Це mature agent design. AI не повинен завжди діяти. Іноді найкраще, що може зробити агент, — зупинитися.

Межа автоматизації: 36% не піддається

У тому ж матеріалі GitHub дає ще одну сильну цифру.

Із 55 WCAG level A and AA Success Criteria лише 35 можуть бути виявлені deterministic automated code checkers. Тобто приблизно 36% критеріїв вимагають manual evaluation. ^[9]

Це не просто accessibility-факт. Це модель реальності для будь-яких AI workflows.

У кожній складній сфері є частина, яку можна автоматично перевірити. І є частина, де потрібен людський judgment.

автоматизується:
  синтаксис
  тести
  очевидні помилки
  формат
  повторювані патерни
  частина compliance

потребує judgment:
  UX
  репутаційний ризик
  етична неоднозначність
  контекст клієнта
  стратегічний компроміс
  смислова якість

Проблема багатьох AI-систем у тому, що вони поводяться так, ніби 100% реальності можна перетворити на tool call. Це неправда.

Сильна AI-архітектура не заперечує людський judgment. Вона ставить його в правильну точку циклу.

Human-in-the-loop — це не QA в кінці

Старе уявлення про human-in-the-loop виглядало так: AI щось робить, людина перевіряє, approve або редагує. Це слабка модель.

Сильніша модель: людина не просто перевіряє output. Людина формує траєкторію.

LangChain описує agent improvement loop як процес, у якому команда швидко створює першу версію агента, запускає її в production-like середовище, збирає дані, аналізує outputs і eval scores, а людський feedback впливає на context engineering та наступні ітерації. ^[10]

Тобто людина не редактор після моделі. Людина — тренер циклу.

Вона бачить, де агент плутається. Яких джерел не вистачає. Де треба стиснути контекст. Де додати приклад. Де заборонити дію. Де потрібен escalation gate. Де помилку треба перетворити на тест.

run
  → failure
  → human judgment
  → eval case
  → context patch
  → workflow patch
  → next run

Це ключ до зменшення wasted iterations. Не просити модель «бути кращою». А брати кожен збій і перетворювати його на новий елемент системи.

Hooks: правила переїжджають із промпту в runtime

OpenAI у Codex-релізі підкреслив: Hooks тепер generally available на всіх планах. Їх можна використовувати для secret scanning, validators, conversation logging, memory creation або repo-specific behavior customization. ^[2]

Claude Code теж рухається у цю саму логіку. У документації Claude Code за квітень-травень видно цілу хвилю runtime primitives: Routines, /usage, /ultrareview, effort levels, hooks, monitor tools, permission logic, sandbox rules. Routines запускають templated cloud agents за schedule, GitHub event або API call. /usage показує, що саме споживає ліміти. /ultrareview запускає parallel multi-agent analysis і adversarial critique pass для code review. ^[13]

Це означає, що правила дедалі більше переїжджають із prompt у runtime.

Не треба писати в prompt:

«Будь ласка, не видаляй важливі файли, не пуш секрети, не міняй production configs, не роби небезпечні Bash-команди, не генеруй код у high-risk zones».

Це треба кодувати в hooks, policies, deny-lists, validators і approval gates.

Це фундаментальна різниця.

GitHub 13 травня також викотив Agent tasks REST API для Copilot cloud agent у public preview. Copilot Business і Enterprise користувачі можуть програмно запускати cloud agent tasks. Агент працює у власному development environment, може робити й валідувати code changes, а потім відкривати pull request. GitHub наводить сценарії: fan out refactors across repositories, one-click repo setup з internal developer portal, weekly release preparation із release notes. ^[12]

Це ще один крок від чату до інфраструктури. Коли агент запускається через REST API, він стає не помічником у вікні, а частиною pipeline.

Sakana Conductor: маленький менеджер сильніший за великого генія

Найінтелектуальніший сигнал останніх тижнів — робота Sakana AI про Conductor.

Ідея майже елегантна: не тренувати ще одну модель, яка сама вирішує все. Навчити маленьку модель керувати іншими моделями.

Sakana описує 7B Conductor model, trained with reinforcement learning, який оркеструє пул frontier models — GPT-5, Gemini, Claude і open-source models. Він не пише код безпосередньо. Він вирішує: кого викликати, яке підзавдання дати, який контекст показати, як зібрати workflow. Для простих factual questions він може викликати одну модель. Для складних coding problems — створює planner-executor-verifier pipeline. ^[14]

Результати сильні: у paper Conductor показує 83.93 на LiveCodeBench, 93.3 на AIME25, 87.5 на GPQA-Diamond і середній 77.27, перевищуючи окремі worker models у цьому setup. ^[15]

Це дуже важлива метафора для всієї AI-епохи.

Майбутнє може належати не найбільшій моделі. А найкращому координатору.

велика модель:
  розв'язує задачу сама

conductor:
  розбиває задачу
  вибирає агентів
  обмежує контекст
  запускає перевірку
  збирає фінальний результат

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

AI починає навчатися не тільки відповідати. AI починає навчатися менеджменту.

Але не кожен workflow потребує агента

Тут важливо не впасти в протилежну дурість.

Якщо prompt engineering переоцінювали, то тепер є ризик переоцінити agents.

Martin Fowler 14 травня опублікував думку James Pritchard: багато «agent use cases» насправді є просто workflows — відомими послідовностями кроків, де один або два кроки включають LLM. Якщо workflow відомий, часто не потрібна автономія. Потрібен function call. ^[16]

Це болюче, але правильне. Не все треба перетворювати на агента.

Якщо процес стабільний — кодуй процес. Якщо кроки відомі — зроби pipeline. Якщо треба витягнути дані, класифікувати, переформатувати, перевірити шаблон — це часто функція з LLM-викликом всередині.

Агент потрібен там, де є: невизначеність, пошук, branching, tool use, довгий контекст, проміжні рішення, потреба в human approval, змінна траєкторія.

відомий шлях → workflow
невідомий шлях → agent
високий ризик → human gate
повторюваний патерн → automation

Проста матриця, але вона рятує від over-agenting.

Економіка агентів: підписки більше не бездонні

Ще один неприємний, але важливий сигнал — billing.

Zed 14 травня пояснив, що Anthropic із 15 червня розділяє Claude subscription billing на два пули: first-party Claude tools і third-party agent / SDK usage. Для third-party agent usage через ACP, claude -p та інші інструменти вводиться Agent SDK credit: $20 для Pro, $100 для Max 5x, $200 для Max 20x. Після вичерпання credit — usage за API rates або зупинка requests. ^[17]

Це не просто pricing drama. Це кінець all-you-can-eat ілюзії для heavy agent workflows.

Коли людина пише 30 повідомлень у чаті, це одна економіка. Коли агент запускає десятки tool calls, читає репозиторій, робить subagent analysis, тримає long context і повторює тести — це зовсім інша економіка.

Agentic work дорого коштує, бо це не «відповідь». Це compute-loop.

• Поганий контекст = більше токенів.
• Поганий prompt = більше retries.
• Погані tools = більше помилкових дій.
• Погані evals = більше людського review.
• Поганий runtime = більше обривів.
• Погана пам’ять = кожен запуск із нуля.

Усе це коштує. Не метафорично. Буквально.

Voice-to-artifact: наступна природна форма роботи

Найцікавіше, що ця логіка вже починає виглядати дуже природно в реальній роботі.

Людина говорить у мікрофон. Claude Code або Codex отримує задачу. Створює HTML, landing page, script, database migration, Telegram bot, research document. Завантажує на сервер. Людина дивиться результат. Голосом дає правки. AI змінює. Знову deploy. Знову feedback. Усе документується в .md файлах, project memory, agent instructions, changelog.

Це вже нормальний режим роботи для людей, які живуть у fast iteration.

voice
  → agent
  → artifact
  → deploy
  → inspect
  → correction
  → memory
  → next version

Мислення перестає бути відділеним від виробництва.

Раніше між ідеєю і артефактом було багато тертя: сісти, сформулювати, написати ТЗ, передати розробнику, чекати, отримати, пояснити правки, знову чекати.

Тепер voice interface стискає цей цикл. Ідея переходить у продукт майже напряму.

Але саме тому стає критичною структура. Якщо не формалізувати цей loop, він швидко перетвориться на хаос: різні сесії, різні агенти, втрачений контекст, дублікати, погано записані рішення, «а чому ми це зробили?», «де остання версія?», «який prompt працював?».

Тому новий стек має мати пам’ять. Не романтичну. Технічну:

/project.md      що це, ціль, користувачі, домен, деплой
/decisions.md    ключові рішення, чому, що не робити
/workflows.md    як запускати, деплоїти, перевіряти, відкочувати
/agents.md       ролі, constraints, tools, escalation rules
/evals.md        типові помилки, acceptance criteria, regressions

Це не бюрократія. Це спосіб не втрачати швидкість.

Чому wasted iterations — головний ворог

Уся ця тема зводиться до одного: зменшити кількість зайвих ітерацій.

Не просто «отримати кращу відповідь». А отримати менше циклів до правильного результату.

Поганий AI workflow виглядає так:

prompt
  → не те
  → пояснення
  → не те
  → уточнення
  → не те
  → роздратування
  → ручна правка

Добрий AI workflow виглядає так:

spec
  → context
  → agent run
  → artifact
  → validation
  → focused correction
  → memory update
  → reusable template

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

Саме тому artifact-first підхід такий сильний. Не просити AI «поясни, що ти зробив». Просити створити артефакт, який можна перевірити: diff, test result, deployed page, JSON, checklist, PR, changelog, screenshot, log, report.

## Найгірші антипатерни 2026 року

У новій AI-реальності найчастіше ламають роботу не моделі, а погані патерни.

1. Гігантський prompt замість системи. Коли всі правила, стиль, контекст, історія і constraints живуть в одному полотні тексту — система стає крихкою. Краще: короткий core prompt, контекст окремо, tools окремо, policies в hooks, пам’ять керована, evals явні.

2. Агент без меж. Якщо агент може все, він рано чи пізно зробить щось зайве. Краще: read-only by default, write only with scope, dangerous actions require approval, high-risk zones blocked.

3. Вільний текст між агентами. Без schema з’являються hallucinations, token bloat і audit hell. Краще: structured handoff, template schema, explicit fields, parent orchestrator validates.

4. Немає пам’яті рішень. Кожна нова сесія починає з нуля. Людина знову пояснює те саме. Краще: decisions.md, project.md, known constraints, what not to do.

5. Немає eval loop. Помилки виправляються вручну, але не стають тестами. Краще: failure → captured → classified → added to eval → prevents regression.

Нова професія: архітектор агентних циклів

Звідси народжується нова роль.

Не prompt engineer у старому сенсі. А agent workflow architect.

Людина, яка вміє:

• розбивати процеси на етапи;
• визначати, де потрібна модель, а де звичайний код;
• проектувати context flow;
• налаштовувати memory;
• прописувати agent roles;
• створювати structured handoffs;
• будувати approval gates;
• вводити evals;
• контролювати costs;
• робити workflows portable між vendors.

Це не одна професія в LinkedIn. Це навичка, яка проникне в роботу founder-а, CTO, product manager-а, operations lead-а, аналітика, редактора, розробника.

У 2024 році було цінно «вміти промптити». У 2026 році цінно вміти будувати цикли.

Bottom line

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

AI тепер пише код, запускає тести, редагує файли, працює в devbox, чекає approve, пам’ятає рішення, читає пошту, підключає tools, створює PR, запускається по API, отримує hooks і потрапляє в governance.

Це вже не «генератор тексту». Це нова машина виконання.

І в цій машині головне не те, хто напише найкрасивіший prompt.

Головне — хто швидше замикає цикл:

побачити
  → сформулювати
  → запустити
  → перевірити
  → виправити
  → запам'ятати
  → повторити

Так само як у Мадяровій війні перемагає не одна платформа, а швидкість сенсорного циклу — у сучасній AI-роботі перемагає не одна модель, а швидкість агентного циклу.

Промпт був командою.

Цикл стає армією.