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

Автор статті: CyrilXBT

Переклад статті, джерело: ME News

Червень 2026 року, протягом тижня троє людей незалежно один від одного прийшли до одного й того ж висновку.

Розробник OpenClaw Петер Штейнбергер відкрито заявив, що людям слід припинити прямий запис підказок для програмних агентів і замість цього розробляти циклічні системи, які автоматично надсилають інструкції агентам.

Майже одночасно Борис Черні, керівник Anthropic Claude Code, також зазначив, що більше не вводить підказки безпосередньо в Claude. Зараз він запускає набір циклів, які автоматично викликають Claude та визначають наступні кроки, а його справжня робота полягає у написанні та проектуванні цих циклів.

Кілька днів потому інженер Google Addy Osmani систематизував цю практику і дав їй назву:

Loop Engineering, циклічне інженерство.

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

Раніше базові інструменти подолали критичний поріг: програмні агенти почали здатні виконувати справжні завдання без нагляду; витрати на автоматичне планування знизилися настільки, що повторне запускання завдання за розкладом більше не виглядає витратним; витрати на один запуск агента також знизилися до нового рівня — замість того, щоб витрачати багато часу на тщетне обдумування одного разу, краще дозволити агенту спробувати п’ять разів — витрати можуть виявитися навіть нижчими.

Це саме тому і існує цей дорожній план.

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

Нижче наведено повна 20-крокова шлях від оператора підказок до дизайнера системи. Необхідно просуватися в порядку, оскільки на цьому шляху послідовність кроків часто важливіша, ніж будь-який окремий крок.

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

Наприклад, створення автоматизованого тригера на кроці 14 ще до встановлення справжніх умов зупинки на кроці 10 призведе лише до системи, яка автоматично витрачатиме кошти без нагляду. Раніше вона хоча б витрачала ресурси лише тоді, коли ви дивилися на екран, а зараз вона може самостійно постійно спалювати гроші.

Так само, якщо ви створите шар постійної пам’яті на кроці 11, перш ніж впровадите надійні механізми перевірки на кроках 6 і 7, ви можете серйозно зберегти досвід, зібраний надмірно лояльним «рецензентом», який постійно пропускає помилкові результати.

Це не лише не допоможе системі розвиватися, але й призведе до накопичення помилкового досвіду, перетворивши шар пам’яті з «тимчасово безкорисного» на «активно шкідливий».

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

Справжній перший крок не пов’язаний з жодною технікою.

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

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

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

Цей крок не має відповідного підказувального слова, це когнітивне рішення.

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

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

Через кілька місяців така практика створить стіну з правил: щільну, суперечливу та надто довгу, щоб модель могла одночасно обробити всі вимоги у оперативній пам’яті.

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

Циклічне проектування корінним чином змінило цей підхід.

Коли виникає проблема, ви більше не додаєте нову вимогу до підказки, а додаєте новий компонент до системи, наприклад:

• Додайте окремий етап верифікації;
• Додати файл пам’яті;
• Додати таймер-тригер;
• Додайте структурований етап оцінки.

Зі зростанням здатностей зовнішніх систем самі підказки повинні ставати все коротшими, а не довшими.

Будь-яке виконання циклу, незалежно від того, до якої галузі воно належить, можна розкласти на п’ять базових дій:

Ідентифікація, передача, перевірка, зберігання, планування.

Виявлення

Зрозумійте, яке завдання справді потрібно виконати.

Передача

Передайте завдання моделі, агенту чи інструменту, відповідальному за виконання.

Перевірка

Перевірте результати на відповідність реальним стандартам.

Персистентність

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

Планування

Визначте, коли цей процес має бути запущений знову.

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

Інші три дії або взагалі не існують, або приховані в людському мозку.

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

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

Не вибирайте найскладніші питання чи інноваційні завдання без жодних аналогів.

Перша кандидатська задача повинна відповідати трьом умовам:

1. Тобі потрібно виконувати це повторно;
2. Він має чіткі стандарти, які можна записати;
3. Він має легко визначуваний «стан завершення».

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

Це обмеження важливіше, ніж здається на перший погляд.

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

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

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

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

Можна використовувати наступний шаблон:

Назва завдання: [Назва завдання]

Завершено визначення (Definition of Done, DoD):

• [Конкретний, перевіряємий стандарт 1]
• [Конкретні, перевіряємі стандарти 2]
• [Конкретні, перевіряємі критерії 3]

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

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

Це найважливіше архітектурне рішення серед усіх циклічних систем.

Роль, відповідальна за генерацію результатів, та роль, відповідальна за перевірку результатів, повинні бути розділені.

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

У раціональному циклі повинні бути щонайменше два незалежних ролі:

Будівельник

Розробники мають певний простір для творчості та відповідають за створення першої версії результату.

Оцінювач

Рецензент отримує вихідні дані від будівельника та визначення завершення, розроблені на кроці 5, і оцінює, чи відповідає результат цим критеріям.

У ідеальному випадку рецензенти також повинні мати доступ до незалежних доказів, до яких немає доступу у розробників, наприклад:

• Тестовий набір;
• Вихідні дані;
• Реальні дані;
• Авторитетна база даних;
• Оригінальне завдання.

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

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

Він не може визначити, чи результат справді правильний.

Тому рецензенти повинні мати об’єктивні підстави для перевірки, тобто Ground Truth. Залежно від контексту, це можна розуміти як «еталонні дані», «правдиві дані» або «авторитетне джерело».

Для різних завдань об’єктивні критерії також різні.

Програмувальне завдання

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

Завдання з виробництва контенту

Об’єктивними основами є оригінальні матеріали та скорочені звіти. Рецензенти повинні порівнювати оригінальні матеріали зі згенерованим текстом поруч.

Дослідницьке завдання

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

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

Вихідні дані будівника та висновки рецензента повинні мати чітко визначену структуру, а не бути вільним потоком природної мови.

В іншому випадку менеджер на наступному етапі не матиме стабільної та надійної інформації для прийняття рішень та маршрутизації.

Будівельники можуть використовувати наступний формат виводу:

Вивід будівника:

• Фінальний доставлений контент;
• Рівень впевненості у результаті;
• Відома невизначеність.

Оцінювач може використовувати наступний формат виводу:

Висновок оцінки:

• PASS: успішно;
• FAIL: невдало;
• Потрібно виправити:
• Виявлені конкретні проблеми;
• Об’єктивні стандарти або первинні докази, на яких ґрунтується ця перевірка.

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

Уважно прочитайте судження, надане рецензентом, і запитайте себе:

• Чи згодні ви з його висновком?
• Чи дозволяв він коли-небудь пройти результат, який ти точно знав, що є помилковим?
• Чи він неправильно заперечив результат, який спочатку був кваліфікованим?

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

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

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

Крок 5: Визначте завершення

Стандартом виконання цього завдання може бути:

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

Крок 6: Будівельник створює чернетку

Будівельник отримує вихідні матеріали та короткий опис контенту, щоб створити чернетку.

Тим часом, воно також має чітко перелічити невизначеності, що існують у процесі написання, наприклад:

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

Крок 7: Рецензент перевіряє за оригіналом

Рецензенти отримують одночасно чернетку та оригінальні матеріали, а не лише чернетку.

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

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

Крок 8: Структуроване передача

Висновок рецензента має бути структурованим об’єктом, а не текстом з наповненням застережливими формулюваннями.

Він має виводити три чіткі результати — «пройдено» або «не пройдено» — і для кожного невдалих результатів наводити конкретні причини.

Крок 9: Ручна перевірка механізму оцінки

Ручне виконання повного процесу перед автоматичним запуском системи допоможе вам виявити, чи є рецензенти надто лояльними чи надто суворими.

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

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

Ці дві проблеми дуже поширені під час першої настройки.

Виявлення їх після 50 автоматичних запусків системи значно дорожче, ніж вирішення проблем під час першого ручного тестування.

Менеджер відповідає за читання оцінок рецензентів та прийняття рішення щодо наступних дій.

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

Наприклад:

Умова зупинки:

• Максимальна кількість змін: 3 рази;
• При невдачі третього огляду надішліть повну історію на розгляд людині, не запускаючи четвертої редагування;
• Стандарт якості: кожен пункт у визначенні повинен відображати PASS;
• Ліміт бюджету: якщо вартість завдання перевищує X або час виконання перевищує Y, завдання має бути негайно зупинене, незалежно від поточного стану.

Цикл без справжніх умов зупинки — це не система, а обов’язок, що чекає на виявлення ризиків.

Чому такі м’які інструкції, як «зупинятися, коли результат достатньо добрий», ненадійні?

Оскільки це лише рекомендація.

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

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

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

Тому потрібно додати простий шар зберігання.

Можете створити файл для кожного справжнього нового досвіду і на початку файлу коротко описати його одним реченням:

• Що ви навчилися;
• Що було виправлено;
• Чому цей досвід важливий.

Ключовий принцип: записувати лише нові знання, які ще не збережено в інших місцях.

Повторювані пам’яті — це не знання, а шум.

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

Легко виникає бажання записувати всі деталі роботи, але це лише відтворює проблему «надмірного промпта», згадану на кроці 2, лише на цей раз розпухають не промпти, а папки пам’яті.

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

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

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

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

Процес упорядкування включає:

• Перевірте наявні пам’яті;
• Об'єднати повторювані дані;
• Згрупуйте кілька подібних досвідів у одну чіткішу принципову ідею;
• Видаліть вже доведені неправильні або застарілі матеріали.

Мета — не накопичувати все більше файлів, а отримати менше кількість знань з вищою щільністю інформації.

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

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

У реальності такі завдання «пізніше впорядкую» зазвичай ніколи не виконуються, доки продуктивність системи не почне падати через велику кількість суперечливих, застарілих і частково пов’язаних спогадів, що борються за вікно контексту.

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

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

Не намагайтеся натягувати минулі досвіди на абсолютно нову проблему лише тому, що система пам’яті вже існує.

Далі потрібно визначити, коли цей цикл буде автоматично запускатися без ручного запуску.

Способи активації можуть включати:

• Завдання Cron;
• Слухач змін файлів;
• Календарний періодичний тригер;
• Тригериться при зміні зовнішньої події або стану.

Цей крок перетворить систему, яку можна запустити лише вручну, на систему, яка продовжуватиме працювати, поки ви спите.

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

Перед використанням циклу для будь-якої важливої задачі необхідно активно протестувати чотири моделі відмов.

Тест 1: Неможлива задача

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

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

Тест 2: Виглядає логічно, але фактично неправильний результат

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

Цей результат має звучати дуже плавно, але містити одну свідомо вставлену помилку у факті чи логіці.

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

Тест 3: Будівельники та рецензенти діляться сліпими зонами моделі

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

Якщо рецензент і будівельник мають однакові сліпі зони, тоді розділення ролей, запропоноване на кроці 6, втрачає сенс.

Тест 4: Обчислення вартості виконання у найгіршому випадку

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

Потім щиро запитайте себе:

Чи ви відчули б незручність, якби це число з’явилося у справжньому рахунку?

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

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

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

Різні ролі в циклі вимагають різного рівня здібностей моделі.

Будівельник

Розробники зазвичай повинні використовувати найпотужніші моделі.

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

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

Рецензент

Рецензенти відповідають за перевірку за чіткими критеріями, зазвичай не вимагаючи високого рівня креативності.

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

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

Менеджер

Менеджер просто маршрутизує згідно з уже написаними правилами і майже ніколи не використовує найдорожчі моделі.

Його завдання — виконувати вже визначену логіку, а не здійснювати відкриті міркування.

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

Розумна конфігурація рівнів зазвичай має вигляд:

• Сильна модель відповідає за побудову;
• Дешеві та стабільні моделі відповідають за регулярні перевірки;
• Моделі з низькою вартістю або правила програми відповідають за маршрутизацію та управління.

Справжнє значне зниження витрат у циклічній системі зазвичай походить із такого співставлення ролей моделі.

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

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

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

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

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

Тільки досягши цього стану, слід починати побудову другого циклу.

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

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

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

Окремо взята, циклічна бюджетна схема може бути абсолютно обґрунтованою.

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

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

Крім успішно виконаних завдань, необхідно окремо фіксувати кожне спрацювання умови зупинки.

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

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

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

П’ятий етап: Стати справжнім дизайнером системи Крок 19: Більше не вимірюйте себе кількістю написаних підказок

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

Оператор підказок цікавиться:

• Сьогодні написано скільки ефективних підказок;
• Який промпт дає найкращий ефект;
• Як краще сформулювати підказки.

Дизайнер системи цікавиться:

• Скільки циклів зараз працює;
• Яка надійність кожного циклу;
• Скільки часу система вивільнила для себе;
• Які роботи вже не потребують ручного контролю.

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

Останній крок більше не стосується виключно вашої системи.

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

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

Ідентифікація, передача, перевірка, зберігання, планування.

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

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

Ви стали тим, хто стоїть поза циклом, проектує систему і спостерігає, як вона працює сама по собі.

Чотири витрати, які накопичуються після пропуску кроків

На кінці статті необхідно надати попередження.

Пропуск кроків у цьому маршруті часто не призводить до миттєвого збою системи.

Його невдача зазвичай тиха і навіть довгий час непомітна, поки проблеми не накопичаться до досить серйозного рівня.

Коли ви пропускаєте кроки 6 і 7, не створюючи справжніх незалежних рецензентів і не надаючи надійних об’єктивних підстав, перевірка боргу починає накопичуватися.

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

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

При пропуску 20-го кроку може виникнути деградація розуміння.

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

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

Когнітивна капітуляція виникає, якщо крок 1 ніколи не був завершений.

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

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

Якщо пропустити крок 10 і не встановити справжньої умови зупинки для циклу, може відбутися неконтрольоване споживання токенів і витрат на виклики.

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

Всі вищевказані витрати можна уникнути.

Спосіб уникнути їх завжди один і той самий: дисципліна:

Будуйте по порядку, не пропускайте кроки, які здаються недостатньо захопливими.

Саме найбільш нудні частини часто відіграють ключову роль:

• Чітке визначення завершення;
• Надійні умови зупинки;
• Перевірні об’єктивні підстави;
• Незалежний механізм оцінки.

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

Справжнім визначником якості системи є те, чи знає система, яку ви створили:

• Коли ти вірний сам собі;
• Коли ви самі помиляєтесь;
• Коли треба зупинитися.

Це вся різниця між оператором підказок і розробником системи.

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

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