Я почав ставитися до агентів кодування на ШІ менше як до вікон чату, а більше як до працівників з контрактами. Різниця не в моделі. Різниця в тому, чи знає агент, що продовжувати робити, як довести прогрес і коли зупинитися.
Саме тут мають значення /loop та /goal.
Claude Code тепер безпосередньо надає обидві ці ідеї: /goal для умови завершення та /loop для повторюваних запитів, поки сесія залишається відкритою. OpenAI Codex має /goal як задокументовану команду, а OpenAI також документує цикли покращення на основі оцінювання (eval) як робочий процес. Важлива деталь: я б не описував OpenAI Codex як такий, що має офіційну слеш-команду /loop, якщо вона не з'являється у вашому списку встановлених команд. У поточній документації, яку я перевіряв, /goal є офіційною; «loop» (цикл) — це шаблон.
Ця відмінність має значення, тому що ці інструменти виглядають схожими ззовні, але я використовую їх для різних завдань.
Швидка відповідь
Використовуйте /goal, коли агент має прагнути до одного стійкого результату, доки не буде виконана чітка умова.
Використовуйте /loop, коли агент має повторювати запит через певний інтервал або у власному ритмі, поки сесія залишається відкритою.
Використовуйте цикл на основі оцінювання (eval-driven loop), коли результат можна оцінити та багаторазово покращити: якість коду, візуальна якість, продуктивність, SEO, міграції, тести або будь-яке завдання, де кожен прохід можна виміряти.
Практичне правило просте: мета потребує фінішної риси; цикл потребує ритму; обидва потребують верифікації.
Що робить Claude Code /goal
Довідник команд Claude описує /goal [condition|clear] як спосіб встановити умову, щоб Claude продовжував працювати протягом кількох ходів, доки ця умова не буде виконана. Документація hooks додає корисну деталь реалізації: /goal поводиться як вбудований ярлик для умови зупинки в межах сесії.
Простою мовою, /goal каже Claude:
Це потужно, але лише за умови, що умова є конкретною.
Погано:
text /goal Зроби додаток кращим
Корисно:
text /goal Виправ помилку оформлення замовлення, збережи всю наявну поведінку платежів недоторканною та зупинися лише тоді, коли pnpm test, pnpm build та шлях перевірки Playwright для оформлення замовлення успішно пройдуть.
Друга версія надає Claude ціль, межі та доказ. Він може обрати шлях, але не може перевизначити успіх на півшляху.
Я використовую /goal для такої роботи:
Як тільки завдання має кілька несумісних результатів, я не використовую одну велику мету. Я розділяю його. Одна мета на один результат є чистішою та легшою для довіри.
Що робить Claude Code /loop
Довідник команд Claude перелічує /loop [interval] [prompt] як об'єднану навичку. Він багаторазово запускає запит, поки сесія відкрита. Ви можете задати інтервал, дозволити Claude самостійно визначати темп або опустити запит і дозволити йому використовувати налаштований запит обслуговування, де це доступно.
Це робить /loop більш операційним, ніж /goal.
Приклади:
text /loop 5m перевір, чи готовий попередній перегляд розгортання Vercel, потім перевір /blog та /api/health
text /loop візьми наступний неперевірений елемент у PRODUCTION_READINESS.md, виправ його, запусти відповідний тест, потім онови контрольний список
text /loop кожні 10m перевіряй CI, узагальнюй помилки та припиняй ескалацію лише після того, як останній запуск буде зеленим
Найкращий випадок використання — це повторювані перевірки або повторювані невеликі одиниці роботи. У моєму гібридному циклі перевірки коду на ШІ→ корисним шаблоном було не «писати вічно». Це було: взяти один пункт контрольної списку, реалізувати його, попросити іншу модель перевірити, запустити збірку, поставити галочку, повторити.
Саме це робить /loop небезпечним, якщо ви напишете лінивий запит. Якщо запит не вказує, що саме перевіряти, агент може продовжувати виконувати правдоподібну роботу, якій ніхто не повинен довіряти.
Що робить OpenAI Codex /goal
OpenAI документує /goal для Codex як у додатку, так і в CLI. Посібник Codex визначає це як стійку ціль для довготривалої роботи, особливо коли завдання має чітку умову успіху та цикл валідації.
Довідник команд CLI Codex перелічує /goal як команду для встановлення, паузи, відновлення, перегляду або очищення цілі завдання. Документація додатку говорить про ту саму ідею в термінах продукту: мета є постійною, видимою та може бути призупинена або відновлена.
Хороша мета Codex виглядає майже ідентично до хорошої мети Claude:
text /goal Заверши міграцію на Next.js 16, не змінюючи публічні маршрути. Зупинися лише тоді, коли pnpm build пройде успішно, головна сторінка завантажиться, /blog завантажиться, а змінені маршрути повернуть 200.
Для Codex мені подобаються цілі, які називають:
Власні рекомендації OpenAI для складних проблем близькі до того, як я вже працюю: надайте Codex систему оцінювання, внесіть цільові покращення, повторно запустіть оцінку, перевірте артефакти та продовжуйте, доки оцінка не стане достатньо хорошою.
Це серце агентної роботи. Не автономність заради автономності. Автономність, пов'язана з вимірюванням.
Чи є у OpenAI /loop?
Саме тут люди можуть бути недбалими у формулюваннях.
Claude Code має задокументовану команду /loop. OpenAI Codex має задокументовані робочі процеси циклічного типу: цикли оцінювання, цикли виправлення, режим цілей з валідацією, hooks та автоматизацію. Але в поточному довіднику слеш-команд Codex, який я перевіряв, я знайшов /goal, /plan, /review, /status, /mcp та багато інших, але не офіційну команду /loop, еквівалентну команді Claude.
Тому моє формулювання таке:
Це не слабкість. Це просто змінює те, як я це налаштовую. У Codex я зазвичай виражаю цикл всередині цілі або запиту:
text /goal Покращ цей компонент, доки оцінка візуальної регресії не перевищить 95%. Робіть одну цільову зміну за раз, запускайте порівняння скріншотів після кожної зміни, ведіть журнал оцінок і зупиніться, коли ціль буде досягнута двічі поспіль.
Це надає Codex той самий операційний ритм, не вдаючи, що існує окрема слеш-команда /loop.
Моя практична настройка
Для серйозної роботи я використовую п'ятишаровий шаблон.
1. Письмова ціль
Я починаю з короткого плану або контрольної списку. Це може бути `PLAN.md`, `PRODUCTION_READINESS.md`, issue у GitHub або звичайний запит. Формат має менше значення, ніж можливість перевірки.
Слабке завдання каже «покращити систему статей».
Сильне завдання каже «заборонити публікацію, коли зовнішні URL повертають 404, м'який 404, неправильний content-type або перенаправляють на неправильну ціль; дозволити збереження чернеток; довести це збіркою та цільовим випадком валідації».
Саме таку інструкцію агент може продовжувати виконувати.
2. Одна модель-власник
Оберіть, хто керує процесом. Claude може бути виконавцем. Codex може бути виконавцем. Не дозволяйте обом редагувати одні й ті самі файли одночасно, якщо у вас немає worktrees або суворої передачі справ. Автономність без власності перетворюється на театр конфліктів злиття.
3. Друга думка
Для роботи з високим ризиком мені все ще подобається рецензування модель-до-моделі. Я писав про свій міст для рецензування коду на ШІ→, тому що він виявляє інші режими відмови, ніж коли одна модель перевіряє сама себе.
Рецензент може бути лише для читання. Йому не потрібен доступ на запис, щоб бути корисним. Йому потрібна різниця (diff), мета, ризиковані файли та дозвіл сказати «це неправильно».
4. Жорсткий валідатор
Тести перемагають впевненість. Збірки перемагають підсумки. Скріншоти браузера перемагають «це має відобразитися». Логи перемагають відчуття.
Для веб-роботи це зазвичай означає:
bash pnpm build pnpm lint pnpm test
плюс перевірки маршрутів, скріншоти або потоки Playwright, коли завдання орієнтоване на користувача.
Для робочих процесів з контентом моїм уподобанням є QA URL перед публікацією: не просто «чи повернув посилання 200», а «чи досягло воно сторінки, про яку стверджувала стаття?». Це той самий принцип. Валідатор повинен перевіряти те, що фактично бачить читач.
5. Правило зупинки
Це та частина, яку люди пропускають.
Цикл без правила зупинки стає дорогим. Мета без правила зупинки стає розмитою. Правило зупинки має бути нудним і буквальним:
Останній рядок важливий. Хороші агенти не приховують невизначеність. Вони виявляють її.
Коли я використовую кожен із них
| Ситуація | Найкращий інструмент | Чому |
|---|---|---|
| --- | ---: | --- |
| Одне велике завдання з чітким визначенням завершення | /goal | Агент може продовжувати рухатися до стійкого кінцевого стану |
| Перевірка статусу розгортання кожні кілька хвилин | Claude /loop | Ту саму перевірку потрібно запускати повторно |
| Покращення згенерованого артефакту відповідно до оцінки | Цикл оцінювання (Eval loop) | Оцінка повідомляє агенту, чи покращило щось останнє проходження |
| Очищення пункт за пунктом у контрольному списку | /loop або /goal | Використовуйте /loop для повторюваних пунктів, /goal для кінцевого результату |
| Дослідження з невизначеним напрямком | Звичайний запит або режим планування | Не запускайте автономність, доки ціль не буде чіткою |
| Чутлива дія у продакшені | Шлюз людського затвердження | Агенти можуть підготувати дію, але не повинні тихо виконувати її |
Промпти для копіювання та вставки
Claude Code /goal
text /goal Заверши це виправлення помилки, не змінюючи непов'язану поведінку. Спочатку прочитай AGENTS.md та відповідні файли маршрутів/компонентів. Роби малі коміти лише в логіці, запускай pnpm build та цільовий шлях регресії, і зупинися лише тоді, коли оригінальна помилка більше не відтворюється і вся верифікація пройшла.
Claude Code /loop
text /loop візьми наступний неперевірений елемент у TODO.md, спочатку перевір реальні файли, зроби одну цільову виправлення, запусти відповідну команду валідації, онови прапорець лише після верифікації та повідом про будь-який блокатор замість того, щоб пропускати його
OpenAI Codex /goal
text /goal Заверши міграцію, описану в PLAN.md. Збережи публічну поведінку, залиш непов'язані файли без змін, запускай перелічені команди валідації після кожної віхи, ведіть короткий журнал прогресу та зупинися лише тоді, коли кожна віха завершена, а фінальна збірка пройшла успішно.
Промпт для циклу оцінювання (eval-driven loop) у Codex
text Я хочу, щоб це було циклом покращення на основі оцінювання. Знайди або створи команду, яка оцінює результат. Робіть одну цільову зміну за раз, повторно запускай оцінку після кожної зміни, безпосередньо перевіряй будь-який згенерований артефакт, фіксуй зміни оцінки та продовжуй ітерації, доки цільова оцінка не буде досягнута двічі поспіль. Якщо оцінка перестане покращуватися, поясни вузьке місце та зупинися.
Поширені помилки
Перша помилка — використання /goal як мотиваційного речення. «Зроби це готовим до продакшену» — це не мета. Це настрій.
Друга помилка — використання /loop без валідатора. Якщо кожна ітерація закінчується неперевіреним твердженням, цикл — це просто повторення.
Третя помилка — об'єднання непов'язаної роботи. «Виправити автентифікацію, переробити панель приладів, оновити ціни та очистити SEO» має бути чотирма завданнями, а не одним героїчним автономним запуском.
Четверта помилка — надання агенту доступу на запис до того, як він зрозуміє правила репозиторію. У моїх власних проектах я хочу, щоб агенти читали `AGENTS.md`, дотримувалися правил розгортання, уникали секретів та перевіряли перед тим, як заявляти про успіх. Контрольний шар навколо моделі має таке ж значення, як і сама модель. Ось чому я постійно повертаюся до робочих процесів розробника MCP→: інструменти, дозволи, докази та відтворювані дії — це те, що перетворює розумний чат на операційну систему.
Справжня суть
Цікаве в /loop та /goal — це не синтаксис слеш-команди. Цікаве — це зміна відповідальності.
Звичайний запит каже: відповідай мені.
Мета каже: заверши це і знай, що означає завершення.
Цикл каже: продовжуй перевіряти або покращувати, доки умова не зміниться.
Саме так я хочу, щоб працювали агенти кодування на ШІ. Не як магія. Не як неконтрольований хаос. Як працівники з контрактом, валідатором і чітким правилом зупинки.
Якщо ви використовуєте Claude Code, /loop — це найшвидший спосіб перетворити повторювану операційну перевірку на щось, з чим агент може впоратися, поки ви продовжуєте працювати. /goal — кращий інструмент, коли робота має один стійкий кінцевий стан.
Якщо ви використовуєте OpenAI Codex, /goal надає вам стійку ціль, а цикл належить до дизайну валідації: тести, оцінювання, артефакти, hooks, журнали прогресу та умова зупинки, яку агент не може тихо перевизначити.
Це шаблон, якому я довіряю: не «дозволь ШІ працювати», а «дозволь ШІ працювати всередині системи, яка може сказати йому ні».