Цикл Ральфа Віггума, з Перших Принципів

Якщо ти використовував агента AI кодування більше, ніж кілька годин, ти знаєш про “стіну”: агент демонструє помітний прогрес, а потім зупиняється — і тобі доводиться самостійно латати та завершувати роботу.

Як це часто буває з інженерами з ШІ, з’явився паттерн для вирішення цієї проблеми: просто запускай агента проти зовнішніх перевірок, доки завдання насправді не буде виконано.

Цей підхід став настільки популярним, що отримав ім’я — Ральф Віггум.

І мем залишився, тому що модель працює. До кінця 2025 року Anthropic оформила його як офіційний плагін Claude Code.

Ralph представляє зміну в тому, як розробники використовують існуючі інструменти. Замість використання систем ШІ як інтерактивних помічників, їх запускають як довготривалі процеси, керовані тестами, лінтерами та явними умовами зупинки.

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

Що Таке “Ralph” Насправді?

В основі своїй, ось що таке Ralph: запустити агента в циклі, перевірити результат проти чогось, що не може брехати, наприклад тесту, лінтера, перевірки типів; і продовжувати цикл доти, доки він не буде пройдений.

Ось і все.

Оригінальний приклад, який Джеффрі Гантлі поділився у липні 2025 року, був навмисно прямолінійним:

while :; do cat PROMPT.md | npx --yes @sourcegraph/amp ; done

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

Сам цикл майже не має значення, і головне це договір:

• Стан зберігається у репозиторії: Файли, різниці, журнали, історія git; все стійке знаходиться тут.
• Завершення знаходиться поза моделлю: Тести, лінтери, перевірники типів; агент не вирішує, коли він закінчений; це вирішує упряжка.
• Агент може бути замінений: Це працівник, якого викликають повторно, поки шлюз не пройде; якщо він сьогодні повільний або тупий, замініть його на щось швидше завтра.

Побачивши це так, Ральф стає принципом дизайну: перестань просити модель знати, коли вона закінчила. Перестань очікувати від неї запам’ятовування обмежень після скидання контексту.

Натомість створи систему так, щоб модель не могла зазнати невдачі в таких ситуаціях.

Чому Цикл Затримується?

Кілька причин:

1. Контекстні Вікна Поводяться Як Буфери

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

“Думай як інженер C чи C++. Вікна контексту — це масиви.”

Вони мають фіксований розмір; вони ковзають; вони перезаписують; вони забувають.

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

Ralph сприймає реальність системи. Замість того, щоб удавати, що контекстне вікно стабільне, він ставиться до нього як до одноразового.

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

2. Зовнішні Перевірки Переважають Внутрішнє Міркування

Багато фреймворків агентів реагують на збій, додаючи структуру всередину моделі: планувальники, резюме, внутрішній стан та петлі рефлексії.

Ralph тримає інтелект поза агентом. Він покладається на:

• Закріплена специфікація, яка не зміщується
• Конкретні докази з останнього запуску
• Детермінований механізм, що оцінює успіх

Агент не вирішує, коли робота завершена – це робить упряж.

Ось чому Ральф відмінно справляється з механічною роботою: рефакторинги, міграції, очищення, завдання з узгодження… Усюди, де успіх можна виміряти скриптом, а не судженням, ітерація стає надійною.

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

3. Компактизація знищує обмеження

Одна повторювана критика від Хантлі стосується узагальнення та ущільнення.

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

Ralph уникає цього, залишаючи вхідні дані буквальними:

• Специфікації залишаються дослівними, замість того, щоб бути узагальненими, 
• Вивід помилок залишається сирий та без фільтрації; та 
• Кураторство пам’яті ніколи не переходить в модель.

Система зберігає достовірність; агент діє всередині неї, обмежений тим, що насправді існує, а не тим, що модель вважає за потрібне.

Отже, Як Ідея Розповсюдилась?

Часовий графік досить стислий.

• 19 червня 2025: На зустрічі у Сан-Франциско, яка зібрала близько 15 інженерів, що обговорювали агентне програмування, Huntley презентує Ralph, Cursed (мову програмування, створену Ralph), і веде трансляцію автономного кодування всю ніч, поки спить в Австралії. У кімнаті відбувається тривожна розмова про те, наскільки легко скопіювати 80%-90% SaaS і скільки видів роботи зникне назавжди.
• Липень 2025: Huntley публікує оригінальний блог-пост з базовою структурою bash-циклу. Стаття містить легкий приклад запиту та запитання: “ви могли б знайти репозиторій cursed lang на github, якби шукали, але, будь ласка, поки що не поширюйте його.”
• Серпень 2025: Відбувається хакатон агентів YC — команди запускають Claude Code в неперервних циклах. В результаті за ніч створено 6 репозиторіїв. Dexter Horthy проводить експериментальний цикл Ralph на рефакторингу кодової бази React. Протягом 6 годин він розробляє повний план рефакторингу та виконує його.
• Вересень 2025: Huntley офіційно запускає Cursed Lang, мову програмування, створену Ralph. Вона існує у трьох реалізаціях (C, Rust, Zig), має стандартну бібліотеку та компілятор другого етапу, написаний на самому Cursed.
• Жовтень 2025: Dexter представляє Ralph на зустрічі Claude Code Anonymous у Сан-Франциско. Питання від аудиторії: “Отже, ви рекомендуєте це?” Його відповідь: “Дурні речі можуть дивно добре працювати. Чого ми можемо очікувати від розумної версії?”
• Грудень 2025: Anthropic випускає офіційний плагін Ralph Wiggum. Плагін бере bash-цикл Huntley та формалізує його за допомогою зупинкових гачків і структурованих даних про відмови.
• Січень 2026: Huntley та Horthy проводять глибоку розмову на YouTube, порівнюючи оригінальну реалізацію bash-циклу Ralph з реалізацією на базі зупинкових гачків Anthropic.

Bash-Цикл Ральф Проти Плагіну Ральф

Оригінальний Ralph – це 5-рядковий баш-цикл. Ти читаєш файл запиту, передаєш його Claude, перевіряєш, чи вихід відповідає твоїм вимогам, і продовжуєш цикл, доки це не станеться. Все зберігається на диску, все видно. Якщо щось ламається, ти можеш точно побачити чому.

Плагін Anthropic перевертає цю модель, тому замість запуску циклу ззовні, він встановлює Stop Hook всередині твоєї сесії Claude. Коли Claude намагається вийти, гак перехоплює це, перевіряє умови завершення та подає той самий запит назад, якщо робота залишилася. Файли, які змінив Claude, все ще там.

Історія git все ще тут, але механіка гарнітури тепер непрозора — прихована у файлі стану markdown, чутлива до дозволів, легко зламати, якщо ти не знаєш, що робиш.

Це класичний компроміс абстракції.

Плагін знижує вартість впровадження. Тобі не потрібно писати bash і не потрібно думати про цикли. Але коли механізм стає прихованим, оригінальне розуміння стає легше упустити.

Версія bash-loop змушує тебе створювати каркас. Версія plugin дозволяє пропустити цей крок, що нормально, поки ти не стикнешся з крайнім випадком і не зможеш побачити, що насправді відбувається.

Декстер Горті протестував це і виявив, що воно відмовляє в загадковий спосіб, якщо не використовувати “–dangerously-skip-permissions.” Плагін встановлює хуки в дивних місцях, використовує непрозорі файли стану, і якщо ти видалиш файл markdown перед тим, як зупинити його, ти зламаєш Клода в тому репозиторії, поки не вимкнеш плагін повністю.

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

Що Ти Вчишся, Керуючи Цим?

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

Взаємодія відбувається на рівні маршруту — запит, тести, умови зупинки — а не всередині розмови.

З часом з’являється патерн: більшість невдач — це не невдачі моделі; це невдачі устаткування.

Специфікація була невизначеною, тест був занадто загальним, або умова завершення насправді не описувала, що означає “завершено”.

Як тільки ти побачиш це кілька разів, твій інстинкт зміниться. Ти перестаєш питати “як зробити Клода розумнішим?” і починаєш питати “як зробити обмеження суворішими?”

Саме тут характеристики стають вирішальними.

Специфікації Як Керуючі Поверхні

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

Це має значення, оскільки характеристики виконують одразу три завдання:

1. Вони обмежують, що може вигадати агент: Без чіткої специфікації, Клод додасть захисні шари, абстракції чи функції, про які ти ніколи не просив, розширюючи обсяг з кожною ітерацією. 
2. Вони закріплюють пошук і вилучення: Щоб агент не вигадував нові вимоги.
3. Вони стабілізують поведінку між пробігами: Кожна ітерація вирішує ту саму проблему, а не трохи інакше тлумачення її.

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

Як Відповідально Управляти Циклом?

Мінімальна конфігурація Ralph часто виглядає так:

MAX_ITERS=30
for i in $(seq 1 $MAX_ITERS); do
  cat PROMPT.md | claude
  if ./ci.sh; then exit 0; fi
done
exit 1

Механіка циклу має набагато менше значення, ніж правила, що його оточують:

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

Далі практика експлуатації виявила кілька евристик, які мають значення:

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

Обмеження є функціональністю.

Петля Є Уроком

Як Ralph набирав обертів, з’явилися варіації. Деякі команди створили структуровані зовнішні цикли навколо агентів, що викликають інструменти. Інші додали окремі компоненти верифікаторів: іншу модель, яка переглядає результати роботи працівника перед тим, як цикл вирішує завершитися. Так, ці розширення працюють, але лише якщо вони поважають первісне усвідомлення.

Правило просте: перевірка має залишатися детермінованою, і підсумки ніколи не мають замінювати первинні вхідні дані.

• Якщо ти додаєш верифікатор, він повинен перевіряти конкретні речі: тести пройдені, лінтер завершується без помилок, git diff відповідає очікуванням. 
• Якщо ти додаєш структуровані зовнішні цикли, вони все ще повинні бачити сирі виводи та журнали, а не вичищене резюме того, що пішло не так. 

Основний аргумент Хантлі полягає в тому, що професія розробника програмного забезпечення фактично мертва, але інженерія програмного забезпечення — практика грамотного створення систем — живіша ніж будь-коли.