درس 13. از پرامپت‌نویسی دستی تا حلقه‌های خودمختار

Code examples: code/ Practice project: Project 07. Build Your First Automated Loop

هر آنچه در دوازده درس نخست آموختید بر یک فرض استوار است: شما پشت صفحه‌کلید نشسته‌اید و دستورالعمل‌ها را یکی پس از دیگری تایپ می‌کنید.

شما فایل AGENTS.md را نوشتید (درس‌های 1 تا 4)، مدیریت وضعیت را ساختید (درس‌های 5 و 6)، دامنه را با فهرست ویژگی‌ها محدود کردید (درس‌های 7 و 8)، در پایان هر نشست تحویل تمیز بر جای گذاشتید (درس‌های 9 و 12)، و زمان اجرا را مشاهده‌پذیر ساختید (درس‌های 10 و 11). اما محرک تمام این فرایندها همواره شما بودید. ایجنت هرگز خودش تصمیم نگرفت چه زمانی کار را آغاز کند — چون هیچ‌کس دکمهٔ «شروع» را نفشرده بود.

این درس دربارهٔ سپردن دکمهٔ شروع به سیستم است. نه واگذاری کنترل — بلکه ارتقای آن به لایهٔ بعدی.

دستور /goal: ساده‌ترین حلقهٔ ممکن#

بهترین دروازهٔ ورود به مهندسی حلقه (loop engineering) یک نمودار معماری پیچیده نیست — بلکه یک فرمان واحد است.

در اوایل سال 2026، Claude Code و OpenAI Codex به‌طور مستقل قابلیت یکسانی را عرضه کردند: /goal. شما در ترمینال تایپ می‌کنید:

/goal "All tests pass, zero lint warnings, merge to main"

سپس لپ‌تاپ خود را می‌بندید و به خواب می‌روید. هشت ساعت بعد، ایجنت به‌تنهایی تحلیل کرده، کد نوشته، آزموده، باگ‌ها را رفع نموده، و با شاخهٔ اصلی ادغام کرده است. در هنگام شکست دوباره تلاش می‌کند، هنگام بن‌بست رویکردش را تغییر می‌دهد، و در زمان اتمام کار متوقف می‌شود — بدون اینکه شما بالای سرش بایستید و بگویید «دوباره امتحان کن».

تنها تفاوت میان /goal و یک پرامپت سنتی یک چیز است. اما همان یک چیز همه‌چیز را دگرگون می‌سازد:

دستور /goal در اصل یک حلقه است. دقیقاً از سه بخش تشکیل شده است: یک هدف، یک روش راستی‌آزمایی، و یک شرط توقف. تنها همین سه مورد شما را از درون حلقه به بیرون آن منتقل می‌کنند.

دستور /goal چگونه به‌طور طبیعی رشد کرد#

دستور /goal یک‌شبه از صفر به یک نرسید. به‌تدریج از دل جریان‌های کاری روزمره تکامل یافت، و تقریباً چهار مرحله را پشت سر گذاشت:

مرحلهٔ 1: پرامپت‌نویسی دستی گام‌به‌گام. نخستین شیوهٔ کار تایجنت رفت‌وبرگشتی بود: «یک تابع بنویس»، «یک آزمون اضافه کن»، «این منطق را درست کن». ایجنت بعد از هر گام متوقف می‌شد و منتظر می‌ماند تا شما بگویید بعد از این چه کند. شما زمان‌بند (scheduler) کل پایپ‌لاین بودید.

مرحلهٔ 2: پرامپت‌های طولانی با چند گام. سپس افراد شروع به نوشتن پرامپت‌های طولانی‌تری کردند که گام‌ها را پشت سر هم می‌چید: «ابتدا کد را تحلیل کن، سپس پیاده‌سازی را بنویس، سپس آزمون‌ها را اجرا کن، و اگر شکست خوردند، اصلاحشان کن». ایجنت می‌توانست چند گام را در یک اجرا پیش ببرد، اما شما همچنان باید نظارت می‌کردید — زیرا ممکن بود در میانهٔ راه منحرف شود، یا گامی را تمام کند و نداند بعد از آن چه کند.

مرحلهٔ 3: خودتأملی و خودهدایتی ایجنت. پس از آن، ایجنت‌ها توانایی «درون‌نگری» پیدا کردند — پس از هر گام به نتیجه نگاه می‌کردند و تصمیم می‌گرفتند بعد از آن چه کنند. شما هدفی می‌دادید، و آن‌ها خودشان آن را خرد کرده و مستقلاً تلاش مجدد می‌کردند. اما مشکلی پدیدار شد: چه زمانی متوقف شوند؟ آیا گزارهٔ «کارم تمام شد» از زبان خود ایجنت سندیت دارد؟ تجربه مداوم پاسخ داد — خیر. ایجنت‌ها بسیار بیش از حد زود اعلام پیروزی می‌کنند.

مرحلهٔ 4: قضاوت مستقل دربارهٔ توقف — دستور /goal. گام پایانی خارج کردن «قضاوت دربارهٔ اتمام کار» از دست ایجنتی بود که کار را انجام می‌دهد، و سپردن آن به یک داور مستقل. این داور می‌توانست مدلی دیگر، یک اسکریپت، یا یک دستور آزمون باشد — اما قاعده یکسان بود: فردی که کد را می‌نویسد نمی‌تواند به تکالیف خودش نمره دهد. در این نقطه، /goal واقعاً کار کرد: شما هدف را می‌دهید، سیستم حلقه می‌زند، یک داور مستقل تصمیم به توقف می‌گیرد، و شما می‌توانید محل کار را ترک کنید.

این چهار مرحله نقشه‌راهی نبود که توسط یک شرکت طراحی شده باشد. مسیری بود که هرکس با ایجنت‌ها کدنویسی می‌کرد، تحت فشار همان نقاط درد مشترک، مستقلاً به آن دست یافت. عرضهٔ هم‌زمان /goal در اوایل سال 2026 توسط Claude Code و Codex تصادفی نبود — زمان آن فرا رسیده بود.

انواع مختلف حلقه‌ها#

دستور /goal ساده‌ترین حلقه برای فهمیدن است، اما تنها نوع آن نیست. حلقه‌ها بر اساس نحوهٔ راه‌اندازی و نحوهٔ توقف به چند دسته تقسیم می‌شوند:

این‌ها با هم رقابت نمی‌کنند — ابزارهای متفاوتی برای کارهای متفاوت هستند. نوبتی برای کارهای کوچک مناسب است. وقتی خط پایان مشخصی دارید از /goal استفاده کنید. وقتی نیاز به مراقبت مداوم دارید از /loop استفاده کنید. و وقتی با سیستم‌های خارجی یکپارچه می‌شوید از رویدادمحور بهره ببرید.

دستور /goal و /loop را اشتباه نگیرید#

هر دو واژهٔ «loop» را در نام خود دارند، اما دو مسئلهٔ کاملاً متفاوت را حل می‌کنند:

یک اشتباه رایج: جا دادن چیزی که باید /goal باشد درون یک /loop. مانند نوشتن /loop 10m "keep implementing the payment system" — این اشتباه است. دستور /loop همان دستورالعمل را هر بار به‌طور مستقل اجرا می‌کند، و به یاد نمی‌آورد دفعهٔ قبل کار کجا متوقف شده است. صرفاً همان نقطهٔ شروع را بارها و بارها تکرار خواهید کرد.

آزمون یک‌جمله‌ای برای انتخاب: آیا این کار پایانی دارد؟ - پایان دارد → /goal - پایان ندارد، فقط باید مداوم نظارت کنید → /loop

مهندسی حلقه، که موضوع این درس است، دربارهٔ یک دستور خاص نیست. دربارهٔ توانایی طراحی سیستم‌هایی است که همهٔ این انواع را در بر می‌گیرند — تا ایجنت شما بتواند حتی زمانی که آنجا نیستید به کار خود ادامه دهد.

نیازی نیست هر بار /goal را تایپ کنید. اما فهمیدن اینکه از کجا آمده و چرا این ساختار را دارد — همان درک هستهٔ مهندسی حلقه است. حلقه‌های پیچیده‌تر صرفاً بخش‌هایی مانند زمان‌بندی، موازی‌سازی، انزوا، و حافظه را بر روی همان سه اصل بنیادین می‌افزایند: هدف، راستی‌آزمایی، و شرط توقف.

تاریخ‌های متفاوت، جهتی یکسان#

یک ایده در زمان‌های مختلف و مکان‌های مختلف پدیدار شد.

پیتر اشتاینبرگر (سازندهٔ OpenClaw، در یک پست): «دیگر نباید به ایجنت‌های کدنویسی پرامپت بدهید. باید حلقه‌هایی طراحی کنید که به ایجنت‌های شما پرامپت می‌دهند.»

بوریس چرنی (مدیر پروژهٔ Claude Code در Anthropic، در پادکست Acquired): «من دیگر به کلود پرامپت نمی‌دهم. من حلقه‌هایی در حال اجرا دارم که به کلود پرامپت می‌دهند و می‌فهمند چه باید کرد. کار من نوشتن حلقه‌هاست.»

ادی عثمانی (مدیر مهندسی در گوگل کروم) این مفهوم را در 7 ژوئن 2026 نام‌گذاری کرد و تعریفی یک‌خطی از آن ارائه داد:

مهندسی حلقه یعنی جایگزین کردن خودتان به‌عنوان فردی که به ایجنت پرامپت می‌دهد. شما به‌جای آن سیستمی را طراحی می‌کنید که این کار را انجام دهد.

چرنی در گزارش شخصی 2025-12-27 خود نوشت که طی 30 روز 259 پول‌ریکوئست (PR) ادغام کرده است — 497 کامیت، 40,000 خط اضافه و 38,000 خط حذف — و تمام خطوط توسط Claude Code + Opus 4.5 نوشته شده بودند.

این نقل‌قول‌ها از تاریخ‌ها، قالب‌ها، و تیم‌های متفاوتی می‌آیند. جهت مشترک آن‌ها خارج کردن زمان‌بندی، راستی‌آزمایی، و تصمیم توقف از پرامپت‌های لحظه‌ای و سپردن آن‌ها به یک سیستم است. تا اواسط سال 2026، ایجنت‌ها توانستند وظایف غیربدیهی را بدون نظارت تمام کنند، عناصر بنیادین زمان‌بندی تعبیه شدند، و یک اجرا به اندازهٔ کافی ارزان شد که با تایمر تکرار گردد. وقتی قطعات آماده باشند، بیش از یک نفر آن‌ها را کنار هم می‌چیند.

منبع: Addy Osmani: Loop Engineering

درون حلقه در برابر بیرون حلقه#

بیایید دو سناریوی ملموس را مقایسه کنیم.

سناریوی الف: شما درون حلقه هستید (درس‌های 1 تا 12).

flowchart TD
    You["You"] -->|"Manually type instruction"| Agent["AI Agent"]
    Agent -->|"Produces output"| Result["Code / tests / docs"]
    Result -->|"You inspect"| You
    You -->|"Unsatisfied, modify instruction"| Agent
    You -->|"Satisfied, move to next task"| You

شما یک هارنس کامل دارید: فایل AGENTS.md قواعد پروژه را به ایجنت می‌گوید، feature_list.json دامنه را محدود می‌کند، init.sh محیطی پایدار را تضمین می‌نماید، و claude-progress.md پیشرفت را ثبت می‌کند. اما هر گام همچنان نیازمند شروع دستی توسط شماست. یک ویژگی را تمام کنید، فایل پیشرفت را بخوانید، دربارهٔ گام بعدی فکر کنید، و دستورالعمل را تایپ نمایید. شما موتور محرکهٔ کل جریان کاری هستید.

سناریوی ب: شما بیرون حلقه هستید (مهندسی حلقه).

flowchart TD
    subgraph Loop["The loop system you designed"]
        Trigger["Auto trigger<br/>Schedule / Event / Previous task complete"] --> Discover["Discover work<br/>Read progress file / issue tracker"]
        Discover --> Dispatch["Dispatch<br/>Spawn sub-agent"]
        Dispatch --> Verify["Verify<br/>Tests / lint / Independent reviewer agent"]
        Verify --> Persist["Persist state<br/>Update progress / Commit / Open PR"]
        Persist -->|"Work remains"| Discover
        Persist -->|"Done or blocked"| Inbox["Push to your review inbox"]
    end
    Inbox -->|"You only need to make decisions"| You["You"]

شما دیگر دستورالعمل تایپ نمی‌کنید. سیستمی که طراحی کرده‌اید کار را کشف می‌کند، تخصیص می‌دهد، نتایج را راستی‌آزمایی می‌کند، وضعیت را ثبت می‌نماید، و دربارهٔ گام بعدی تصمیم می‌گیرد. وظیفهٔ شما به سه چیز خلاصه می‌شود: تعریف هدف و شرط توقف پیش از شروع، بازبینی خروجی پس از پایان، و تنظیم قواعد زمانی که سیستم از مسیر منحرف می‌شود. اهرم از «نوشتن پرامپت درست» به «طراحی حلقهٔ درست» جابجا می‌شود.

عثمانی: «یک سال پیش اگر حلقه‌ای می‌خواستید باید خرواری از کدهای بش می‌نوشتید و تا ابد از آن نگهداری می‌کردید و فقط مال شما بود. اکنون این قطعات مستقیماً درون محصولات عرضه می‌شوند.» نیازی نیست همه‌چیز را از صفر بسازید. باید بفهمید این قطعات چگونه کنار هم قرار می‌گیرند.

مفاهیم اصلی#

• مهندسی حلقه (Loop Engineering): طراحی سیستمی که به‌طور خودکار به ایجنت شما پرامپت می‌دهد، و جایگزین ورودی گام‌به‌گام و دستی انسان می‌شود. انسان از درون حلقه به بیرون آن منتقل می‌شود، و اهرم از «نوشتن پرامپت درست» به «طراحی حلقهٔ درست» تغییر می‌یابد.
• حالت /goal: ساده‌ترین حلقهٔ ممکن — هدفی ارائه دهید، روش راستی‌آزمایی و شرط توقف را تعیین کنید؛ ایجنت تا برآورده شدن آن‌ها حلقه می‌زند. پلی میان پرامپت‌نویسی دستی و حلقه‌های خودمختار.
• تفکیک تولیدکننده از ارزیاب (Generator/Evaluator Separation): ایجنتی که کد را می‌نویسد و ایجنتی که آن را بررسی می‌کند باید تفکیک شوند. نمره‌دهی مدلی به کار خودش غیرقابل‌اعتماد است؛ یک راستی‌آزمای مستقل — که گاهی از مدلی کاملاً متفاوت استفاده می‌کند — ضامن حداقلی قابلیت اطمینان هر حلقه است.
• انزوای ورک‌تری (Worktree Isolation): هر ایجنت موازی در یک ورک‌تری گیت مستقل کار می‌کند، که به‌طور فیزیکی مانع از تداخل فایل‌ها می‌شود. پیش‌نیاز زیرساختی برای اجرای موازی چند ایجنت.
• وضعیت خارجی (External State): حافظه‌ای که بیرون از یک گفتگوی واحد زندگی می‌کند — فایل‌های مارک‌داون، ردیاب‌های ایشو، و بردهای کانبان. مدل‌ها همه‌چیز را میان اجراها فراموش می‌کنند؛ حافظه باید روی دیسک بماند.
• چهار هزینهٔ خاموش: چهار هزینهٔ پنهان که با طولانی‌تر شدن کار حلقه عمیق‌تر می‌شوند — بدهی راستی‌آزمایی، فرسودگی درک، تسلیم شناختی، و انفجار توکن‌ها. حلقه‌ها نه‌تنها خروجی، بلکه ریسک را نیز شتاب می‌بخشند.

شش عنصر بنیادین یک حلقه#

عثمانی یک حلقه را به پنج بلوک سازندهٔ اصلی خرد کرد، به‌علاوهٔ یک لایهٔ حافظه که از میان همهٔ آن‌ها عبور می‌کند — در مجموع شش مورد، اما لایهٔ حافظه جایگاهی ویژه دارد: مؤلفه‌ای هم‌سطح بقیه نیست، بلکه ستون فقراتی است که همه‌چیز به آن وابسته است.

نمودار زیر هر شش مورد را به‌صورت یک حلقه رسم می‌کند تا تصویر کامل را در یک نگاه ببینید. اما به خاطر داشته باشید: وضعیت خارجی صرفاً ایستگاهی دیگر در حلقه نیست — شالوده‌ای است که کل حلقه بر آن استوار است.

flowchart LR
    A["Automations<br/>Scheduled triggers"] --> W["Worktrees<br/>Parallel isolation"]
    W --> S["Skills<br/>Codified project knowledge"]
    S --> C["Connectors<br/>External tool access"]
    C --> SA["Sub-agents<br/>Maker / checker split"]
    SA --> ES["External State<br/>Cross-iteration memory"]
    ES --> A

1. خودکارسازی‌ها — ضربان قلب#

بدون خودکارسازی، یک حلقه اصلاً حلقه نیست — صرفاً یک اجرای یک‌باره است که دستی انجام داده‌اید.

هم Claude Code و هم Codex دارای سیستم‌های زمان‌بندی کامل هستند، اما از نام‌ها و لایه‌های متفاوتی استفاده می‌کنند. از سبک‌ترین به سنگین‌ترین:

تب خودکارسازی‌های Codex نقطهٔ ورود زمان‌بندی است. پروژه، پرامپت، ضرب‌آهنگ (cadence)، و اینکه آیا روی مخزن محلی اجرا شود یا ورک‌تری پس‌زمینه را انتخاب کنید. اجراهایی که چیزی بیابند وارد صندوق ورودی (inbox) تریاژ (triage) می‌شوند؛ اجراهایی که نتیجه‌ای نیابند به‌طور خودکار آرشیو می‌گردند. OpenAI در داخل برای دسته‌بندی روزانهٔ ایشوها، خلاصه‌سازی خطاهای CI، گزارش‌های کامیت‌ها، و شکار باگ‌های هفتهٔ پیش از آن‌ها استفاده می‌کند.

خودکارسازی‌های Codex در دو قالب عرضه می‌شوند: - Thread automation — تماس‌های بیدارباش مکرر به سبک ضربان قلب که به یک گفتگو متصل هستند و زمینه را حفظ می‌کنند. مناسب برای پیگیری مداوم یک مورد واحد، مانند پایش یک دستور طولانی یا بررسی وضعیت PR. معادل آن در Claude Code همان /loop است. - Standalone automation — هر اجرا از نو آغاز می‌شود، نتایج به Triage می‌روند. مناسب برای کارهای مستقل روزانه/هفتگی مانند گزارش‌ها یا اسکن وابستگی‌ها. معادل آن در Claude Code همان Desktop scheduled tasks است.

سیستم Claude Code در لایه‌های دقیق‌تری چیده شده است:

• /loop — تکرار زمان‌بندی‌شده و سبک درون‌نشست. تا زمانی که ترمینال شما باز است کار می‌کند، با بسته شدن نشست می‌میرد، و پس از 7 روز منقضی می‌شود. مناسب برای پایش موقت در حین جلسهٔ کاری کنونی شما.
• Desktop scheduled tasks — تا زمانی که سیستم شما روشن است اجرا می‌شود، پس از راه‌اندازی مجدد نشست زنده می‌ماند، در فواصل دقیقه‌ای. مناسب برای کارهای تکرارشونده که نیاز به دسترسی به فایل‌های محلی دارند.
• Cloud Routines — روی زیرساخت ابری Anthropic اجرا می‌شود، با خاموش بودن سیستم شما به حیات ادامه می‌دهد، با حداقل بازهٔ 1 ساعت. از سه نوع محرک پشتیبانی می‌کند: زمان‌بندی، فراخوانی API، و وب‌هوک گیت‌هاب. مناسب برای وظایف روزانه‌ای که به محیط محلی شما نیاز ندارند.
• GitHub Actions / کرون‌جاب خودمیزبان — کاملاً تحت کنترل شما، به هر شکلی که بخواهید اجرا می‌شود. مناسب برای سناریوهایی با نیازمندی‌های خاص محیطی یا امنیتی.

# Claude Code: run tests every 30 min, fix failures (within current session)
/loop 30m Run the test suite and fix any failing tests

# Claude Code: check deploy status every 15 minutes
/loop 15m Check if the production deploy succeeded and report status

خودکارسازی‌ها ضربان قلب هستند. بدون آن‌ها، حلقه طرحی روی کاغذ است که هرگز بیدار نمی‌شود.

2. ورک‌تری‌ها — انزوا در مقیاس بالا#

به محض اینکه بیش از یک ایجنت را اجرا می‌کنید، تداخل فایل‌ها به حالت شکست اجتناب‌ناپذیر بدل می‌شود. نوشتن دو ایجنت در یک فایل واحد دقیقاً همان دردسر کامیت زدن هم‌زمان دو مهندس روی خطوط یکسان بدون هماهنگی با یکدیگر است.

دستور git worktree این مشکل را حل می‌کند: هر ایجنت روی شاخهٔ اختصاصی خود در دایرکتوری مجزای خود کار می‌کند. آن‌ها از نظر فیزیکی نمی‌توانند به فایل‌های یکدیگر دست بزنند.

هم Claude Code و هم Codex از ورک‌تری پشتیبانی می‌کنند. هنگامی که از --worktree یا isolation: worktree برای یک زیر-ایجنت (sub-agent) استفاده می‌کنید، هر کمکی یک محیط مستقل و پاک دریافت می‌کند که پس از پایان کار پاک‌سازی می‌شود. ورک‌تری‌ها مشکل برخورد مکانیکی را حل می‌کنند — اما به یاد داشته باشید: پهنای باند بازبینی شما همچنان سقف ماجراست. اینکه بر چند ایجنت موازی می‌توانید نظارت کنید، تعیین می‌کند که واقعاً چند ورک‌تری می‌توانید راه بیندازید.

3. مهارت‌ها — توقف توضیح مجدد پروژه#

مهارت (skill) روشی است که با آن از توضیح دوباره و دوبارهٔ زمینهٔ پروژه در هر نشست خلاص می‌شوید. مهارتی پوشه‌ای است حاوی یک فایل SKILL.md شامل دستورالعمل‌ها و فراداده‌ها، به‌همراه اسکریپت‌ها، مراجع، و دارایی‌های اختیاری.

Codex و Claude Code هر دو از همین قالب پشتیبانی می‌کنند. مهارت‌ها مستقیماً با /skill-name (Codex از $skill-name نیز پشتیبانی می‌کند) فراخوانی می‌شوند، یا زمانی که وظیفه با شرح مهارت تطابق دارد به‌طور ضمنی فعال می‌گردند.

مهارت‌ها اساساً دربارهٔ پرداخت بدهی نیت شما هستند. یک ایجنت هر نشست را بدون سابقه آغاز می‌کند — هر خلأ در نیت شما را با یک حدس بااعتمادبه‌نفس پر می‌نماید. یک مهارت همان نیتی است که در بیرون نوشته شده است: قراردادها، گام‌های بیلد، آن جملاتی که «ما این کار را نمی‌کنیم چون فلان بار فاجعه شد» — یک‌بار نوشته می‌شود، در هر اجرا خوانده می‌شود.

4. رابط‌ها (Connectors) — پیوند حلقه با ابزارهای واقعی#

حلقه‌ای که تنها فایل‌سیستم را ببیند، حلقه‌ای کوچک است. رابط‌ها (ساخته‌شده بر پروتکل MCP) به ایجنت اجازه می‌دهند ردیاب ایشوها را بخواند، پایگاه داده را پرس‌وجو کند، به یک API استیجینگ متصل شود، یا پیامی در اسلک بگذارد.

هم Codex و هم Claude Code به زبان MCP صحبت می‌کنند، بنابراین رابطی که برای یکی نوشته‌اید معمولاً در دیگری نیز کار می‌کند. رابط‌ها همان تفاوت میان «این هم راه‌حل اصلاحی» و حلقه‌ای هستند که خودش PR باز می‌کند، به تیکت Linear پیوند می‌دهد، و پس از سبز شدن CI در کانال اطلاع‌رسانی می‌کند — به‌صورت خودکار، درون محیط واقعی شما، نه صرفاً در یک ترمینال.

5. زیر-ایجنت‌ها — جداسازی سازنده از بازرس#

ارزشمندترین تصمیم طراحی ساختاری در یک حلقه، جداسازی کسی است که می‌نویسد از کسی که بررسی می‌کند. مدلی که کد را نوشته است بسیار بیش از حد نسبت به نمره‌دهی به کار خود دست‌ودلباز است. ایجنت دومی، با دستورالعمل‌های متفاوت و گاهی با مدلی متفاوت، چیزهایی را می‌گیرد که ایجنت اول خودش را قانع به نادیده گرفتنشان کرده بود.

تفکیک کلاسیک سه نقشی:

flowchart LR
    Explorer["Explorer Agent<br/>Read codebase, locate issues"] --> Implementer["Implementer Agent<br/>Write fix, write tests"]
    Implementer --> Verifier["Verifier Agent<br/>Independent review, run verification"]
    Verifier -->|"Fails"| Implementer
    Verifier -->|"Passes"| Output["Output"]

دستور /goal در Claude Code در پشت صحنه از همین الگو استفاده می‌کند — یک نشست مستقل و تازه قضاوت می‌کند که آیا حلقه باید متوقف شود یا خیر، نه همان نشستی که کار را انجام داده است. این الگو تفکیک تولیدکننده از ارزیاب نام دارد، و مهم‌ترین ضامن قابلیت اطمینان در طراحی حلقه است.

6. وضعیت خارجی — حافظهٔ حلقه#

مدل‌ها همه‌چیز را میان اجراها فراموش می‌کنند. حافظه باید روی دیسک زندگی کند، نه در پنجرهٔ زمینه.

این شاید بیش از حد ساده به‌نظر برسد، اما همان ترفندی است که هر ایجنت بلندمدتی به آن وابسته است. یک فایل مارک‌داون، یک برد Linear — هر چیزی که بیرون از یک گفتگوی منفرد باشد و آنچه انجام شده، آنچه در جریان است، و آنچه در پیش است را نگه دارد. ایجنت فراموش می‌کند. مخزن فراموش نمی‌کند.

این شش عنصر بنیادین جعبه‌ابزار طراحی حلقهٔ شما هستند. نیازی نیست در هر حلقه از همهٔ آن‌ها استفاده کنید. اما باید بدانید چه زمانی به سراغ کدام‌یک بروید.

کالبدشکافی یک حلقهٔ کامل#

هر شش عنصر را به هم متصل کنید؛ این همان چیزی است که یک حلقهٔ تریاژ صبحگاهی واقعی به‌نظر می‌رسد:

flowchart TD
    Trigger["Every morning at 9:00 AM<br/>Automation fires"] --> Read["Read external state<br/>Yesterday's claude-progress.md<br/>Open GitHub issues"]
    Read --> Triage["Triage Skill kicks in<br/>Classify and prioritize findings"]
    Triage --> Fork["For each actionable item<br/>Fork an isolated Worktree"]
    Fork --> Implement["Implementer Sub-agent<br/>Write fix + tests"]
    Implement --> Verify["Verifier Sub-agent<br/>Independently run tests + lint + review"]
    Verify -->|"Fails"| Retry["Retry queue<br/>Try different approach"]
    Retry --> Implement
    Verify -->|"Passes"| PR["Connector: Open PR<br/>Link issue, update progress file"]
    PR --> Memory["Write to External State<br/>Update claude-progress.md<br/>Record this round's results"]
    Memory -->|"Work remains"| Fork
    Memory -->|"All done or blocked"| Inbox["Results land in Triage inbox<br/>Waiting for your review"]

این دیگر اجرای یک ایجنت منفرد نیست. سیستمی است که مداوم کار می‌کند، هر صبح بیدار می‌شود، خودش زمین را جارو می‌زند، و مواردی را که نیاز به توجه شما دارند جلوی چشمانتان می‌گذارد. نقش شما این می‌شود: بازبینی محتویات صندوق ورودی، تصمیم‌گیری، و هنگامی که الگویی فراتر از توان سیستم دیدید، بازنویسی مهارت‌ها و قواعد.

گزارش 30 روزهٔ چرنی داده‌ای روشن برای این الگوست: 259 پول‌ریکوئست، با کدهایی که توسط Claude Code + Opus 4.5 نوشته شده بودند. گزارش مهندسی هارنس OpenAI نمونه‌ای دیگر است: تیمی کوچک که به‌مدت پنج ماه از Codex در یک مخزن جدید استفاده کرد و حدود یک میلیون خط کد و تقریباً 1,500 پول‌ریکوئست گزارش نمود.

تفکیک تولیدکننده از ارزیاب: چرا نباید بگذارید مدل به کار خودش نمره دهد#

این سخت‌ترین درس در مهندسی حلقه است.

باهوش‌ترین ایجنت شما قطعه‌کد زیبایی می‌نویسد. منطق شفاف است، کامنت‌ها کامل‌اند، و هر تابع دارای آزمون است. شما راضی هستید.

اما پرسش اینجاست: اگر به ایجنتی که آن کد را نوشته است اجازه دهید قضاوت کند که آیا کارش را خوب انجام داده است یا خیر، چه خواهد گفت؟

پاسخ با تجربه بارها و بارها تأیید شده است: نمرهٔ بالایی به خود خواهد داد. نه به این دلیل که فریبکار است، بلکه چون خودش نویسنده بوده است — در طول تولید کد، خود را متقاعد کرده که این مسیر درست است. وقتی به عقب نگاه می‌کند، خطاها را نمی‌بیند؛ فرایند استدلال خودش را می‌بیند.

این مشکل کلود نیست. مشکل GPT نیست. ویژگی تمام مدل‌های زبانی مولد است. یک مدل بهترین وکیل مدافع برای خروجی‌های خودش است.

راه‌حل: هرگز نگذارید همان موجودیت (همان مدل، همان پرامپت) هم کار را انجام دهد و هم بازبینی کند.

• دستور /goal در Claude Code از یک نشست نظارتی مستقل برای قضاوت دربارهٔ رسیدن به هدف استفاده می‌کند — نه همان نشستی که برای آن تلاش کرده است.
• سیستم زیر-ایجنت Codex به شما امکان می‌دهد یک ایجنت راستی‌آزما با مدلی متفاوت و با سطح استدلال متفاوت تعریف کنید.
• شیوهٔ تجربی جامعه در «راستی‌آزمایی تقابلی» به‌ازای هر یافته N منتقد مستقل ایجاد می‌کند که هرکدام مأمور به رد کردن آن هستند — رد شدن توسط اکثریت، یافته را باطل می‌کند.

یک جمله را به خاطر بسپارید: یکی از اعضای گروه شما نباید حرف‌های شما را باور کند.

پروژهٔ autoresearch کارپاتی: نمونهٔ اعلای حلقه#

اگر می‌خواهید ببینید یک حلقهٔ خوش‌ساخت و واقعاً در حال کار چگونه است، autoresearch کارپاتی نمونه‌ای درسی است.

در مارس 2026، کارپاتی autoresearch را منتشر کرد. مخزن عمداً کوچک است: فایل prepare.py زیرساخت ثابت است، train.py فایلی است که ایجنت ویرایش می‌کند (حدود 630 خط)، و program.md روش‌شناسی پژوهش است که انسان ویرایش می‌کند. یک پردازندهٔ گرافیکی (GPU) و یک جهت پژوهشی به آن بدهید، و تمام شب به کار ادامه می‌دهد — هر آزمایش یک بودجهٔ زمانی ثابت 5 دقیقه‌ای برای آموزش دریافت می‌کند (به‌جز راه‌اندازی و کامپایل)، و تنها تغییراتی که سنجهٔ val_bpb را بهبود بخشند نگه داشته می‌شوند.

سه فایل، سه نقش#

کل سیستم تنها سه فایل اصلی دارد، اما تقسیم کار بسیار دقیق و شفاف است:

این تفکیک سه‌گانه روح طراحی است: انسان‌ها به کد دست نمی‌زنند، به جهت دست می‌زنند؛ ایجنت‌ها به جهت دست نمی‌زنند، به کد دست می‌زنند. کار شما از نوشتن کد پایتون به «نوشتن فرهنگ سازمانی پژوهش» تغییر می‌یابد.

ورودی: فایل program.md چگونه است#

فایل program.md مغز متفکر حلقه است. کد نیست — یک راهنمای پژوهشی است که در قالب مارک‌داون نوشته شده است. به‌طور کلی شامل این موارد است:

• هدف: بهینه‌سازی val_bpb (بیت بر بایت اعتبارسنجی، مقدار کمتر بهتر است)
• محدودیت‌ها: دست نزدن به prepare.py، ماندن درون بودجهٔ VRAM، آموزش ثابت 5 دقیقه‌ای
• جهت‌های کاوش: آزمودن معماری‌های مختلف، بهینه‌سازها، و زمان‌بندی‌های نرخ یادگیری
• قواعد ارزیابی: چه چیزی بهبود محسوب می‌شود، چگونه نتایج ثبت گردند، و هنگام شکست چه باید کرد
• قاعدهٔ آهنین: هرگز متوقف نشو. وقتی حلقه شروع شد، تا ابد ادامه بده

پرامپت آغازین شما به ایجنت می‌تواند به کوتاهی یک جمله باشد:

Have a look at program.md and let's kick off a new experiment!

باقی کار بر عهدهٔ ایجنت است که سند را بخواند و تصمیمات خودش را بگیرد.

حلقهٔ چرخ‌دنده‌ای نه‌مرحله‌ای#

در قلب autoresearch یک چرخ‌دندهٔ جغجغه‌ای (ratchet) قرار دارد — فقط به جلو حرکت می‌کند، هرگز به عقب برنمی‌گردد. هر تکرار اکیداً از نه گام پیروی می‌کند:

flowchart TD
    1["1. Read direction<br/>Load program.md"] --> 2["2. Survey current state<br/>Read train.py + past results"]
    2 --> 3["3. Propose hypothesis<br/>Think of a change to try"]
    3 --> 4["4. Modify code<br/>Edit train.py"]
    4 --> 5["5. Snapshot<br/>git commit"]
    5 --> 6["6. Run training<br/>Fixed 5-min wall clock"]
    6 --> 7{"7. Evaluate<br/>Did val_bpb improve?"}
    7 -->|Yes| 8a["8a. Keep<br/>Commit stays<br/>Write to results.tsv"]
    7 -->|No| 8b["8b. Revert<br/>git reset HEAD~1<br/>Log the failure"]
    8a --> 9["9. Next round<br/>Go back to step 1"]
    8b --> 9

فایل README تخمین می‌زند که حدود 12 آزمایش در هر ساعت انجام می‌شود، یا تقریباً 100 آزمایش در یک اجرای شبانهٔ 8 ساعته. بودجهٔ 5 دقیقه‌ای فرایند آموزش را پوشش می‌دهد، نه راه‌اندازی و کامپایل را؛ باقی‌ماندهٔ هر دور صرف ویرایش، راه‌اندازی، و ارزیابی می‌شود. کارپاتی گزارش داد که نسخهٔ خصوصی autoresearch را به‌مدت حدود دو روز به‌صورت خودکار برای دور nanochat که در زیر تشریح شده اجرا کرده است.

بودجهٔ زمانی ثابت 5 دقیقه‌ای آموزش یک تصمیم طراحی کلیدی است — صرف‌نظر از اینکه ایجنت چه چیزی را تغییر می‌دهد، اجرای آموزش همان بودجهٔ زمانی مشخص را دریافت می‌کند. این بدان معناست که تمام نتایج تحت یک بودجهٔ آموزشی یکسان مستقیماً قابل‌مقایسه‌اند.

خروجی: صبح که بیدار می‌شوید چه می‌بینید#

پس از یک شب چرخش حلقه، صبح که پشت سیستم می‌نشینید سه چیز را می‌یابید:

1. تاریخچهٔ گیت (چرخ‌دنده‌ای که رو به جلو رفته است)

تنها کامیت‌هایی که واقعاً بهبودی ایجاد کرده‌اند روی شاخهٔ اصلی باقی می‌مانند. هر چیزی که شکست خورد بازگردانده (revert) شد. دستور git log یک گزارش پژوهشی راستی‌آزمایی‌شده است.

2. فایل results.tsv (سابقهٔ کامل آزمایش‌ها)

تک‌تک آزمایش‌ها — موفق یا ناموفق — ثبت شده‌اند:

timestamp    commit_hash    val_bpb    vram_mb    description
--------- ------------- ---------- ---------- ----------------------------
08:01:12  a1b2c3d       1.234     22100    baseline
08:06:15  d4e5f6g       1.228     22400    increased learning rate by 10%
08:11:20  (reverted)     1.241     21800    switched to GELU activation
08:16:08  h7i8j9k       1.219     23000    added weight decay 0.01
...

3. یک گزارش پژوهشی (خلاصهٔ خود ایجنت)

ایجنت پیام‌های کامیت شفافی دربارهٔ آنچه امتحان کرد، آنچه جواب داد، آنچه جواب نداد، و آنچه قصد دارد در ادامه بیازماید می‌نویسد. شما این گزارش‌ها را می‌خوانید — نیازی نیست خط‌به‌خط تغییرات کد (diffs) را بررسی کنید.

آنچه در عمل کشف شد#

نتایج حاصل از دور اول autoresearch زمان آموزش در سطح GPT-2 پروژهٔ nanochat را روی 8×H100 از 2.02 ساعت به 1.80 ساعت کاهش داد، که بهبودی معادل حدود 10.9% در زمان آموزش است.

بیشتر تغییرات بهینه‌سازی‌های کوچکی بودند که روی هم انباشته شدند. بخش کارآمد همان حلقه است: بودجهٔ ثابت، سابقهٔ کامل آزمایش‌ها، و قاعده‌ای که تنها به تغییرات راستی‌آزمایی‌شده اجازهٔ ماندن می‌دهد.

گویاترین جزئیات: حلقه به انگلیسی نوشته شده است، نه به کد#

فایل program.md یک سند مارک‌داون است، نه یک اسکریپت پایتون. روش‌شناسی پژوهش را تشریح می‌کند — چه چیزی تغییر کند، چه چیزی دست‌نخورده بماند، چگونه ارزیابی شود، موارد شکست چگونه مدیریت شوند، و یک قاعدهٔ آهنین: هرگز از انسان کمک نخواه، فقط به جلو برو. یک ایجنت کدنویسی این سند را می‌خواند و آن را تا بی‌نهایت اجرا می‌کند.

این همان الگوی مهندسی حلقه است: به ایجنت وظیفه ندهید. به آن روش‌شناسی بدهید. بگذارید روش‌شناسی همان حلقه باشد. یک فایل program.md، حدود 630 خط کد چسباننده، و همه‌چیز دیگر ایجنتی است که خودش را اجرا می‌کند.

چهار هزینهٔ خاموش#

وقتی حلقه‌ای شروع به کار می‌کند، مشکلات را بلافاصله نخواهید دید. چهار هزینهٔ زیر به‌صورت خاموش انباشته می‌شوند، و تا زمانی که متوجه شوید، ممکن است بهای سنگینی پرداخته باشید.

1. بدهی راستی‌آزمایی#

حلقه‌های سریع شما را وسوسه می‌کنند از راستی‌آزمایی صرف‌نظر کنید. «مناسب به‌نظر می‌رسد» همان «درستی‌اش تأیید شد» نیست. هر چه یک حلقه کدهای بیشتری را بدون نظارت تولید کند، بدهی راستی‌آزمایی با سرعت بیشتری انباشته می‌شود. راه‌حل: شرایط توقف باید توسط ماشین قابل‌بررسی باشند، هرگز نباید در حد «تقریباً درست حس می‌شود» بمانند.

2. فرسودگی درک#

هر چه یک حلقه با سرعت بیشتری کد تحویل دهد، درک شما از پایگاه کد خودتان بیشتر از واقعیت فاصله می‌گیرد. یک حلقه صدها PR را ادغام می‌کند؛ تیم آن PRها را می‌خواند، تغییرات مهم را مرور می‌کند، و مدام از کد استفاده می‌نماید تا مدل ذهنی‌اش به‌روز بماند. حلقه‌های سریع نیازمند خواندن سریع هستند.

3. تسلیم شناختی#

هنگامی که حلقه به‌خوبی کار می‌کند، راحت‌ترین وضعیت این است که دیگر نظری نداشته باشید. هر چه خروجی داد بپذیرید، و دربارهٔ آن فکر نکنید. اما این دقیقاً همان جایی است که خطر آغاز می‌شود — شما از حلقه برای فرار از اندیشیدن استفاده می‌کنید، نه برای تقویت اندیشه. هشدار عثمانی: «دو نفر می‌توانند دقیقاً همان حلقه را بسازند و نتایجی کاملاً متضاد بگیرند. یکی از آن برای سریع‌تر رفتن در کاری که درکش می‌کند استفاده می‌کند؛ دیگری برای فرار از فهمیدن کار به کارش می‌گیرد. حلقه تفاوت را نمی‌داند. شما می‌دانید.»

4. انفجار توکن‌ها#

هر تکرار یک حلقه زمینهٔ بیشتری را انباشته می‌کند: کدهای نوشته‌شده، خطاهای رخ‌داده، و تصمیمات اتخاذشده. هنگامی که هر دور تقریباً مقدار ثابتی از محتوای جدید را اضافه می‌کند، طول تاریخچه‌ای که توسط یک دور منفرد دیده می‌شود به‌طور خطی با تعداد دورها رشد می‌نماید. اگر سیستم در هر دور کل تاریخچه را دوباره پردازش کند، ورودی تجمعی در طول N دور به‌صورت درجه دو (مربعی) رشد خواهد کرد. سیستم Codex با فشرده‌سازی خودکار زمینه به این موضوع می‌پردازد — یک API اختصاصی نوبت‌های قدیمی گفتگو را در خلاصه‌های رمزنگاری‌شده فشرده می‌سازد، و دانش ضروری را حفظ کرده و جزئیات تکراری را دور می‌ریزد. این یک دغدغهٔ مهندسی است که باید از نخستین حلقه به آن بپردازید، نه چیزی که بعداً اضافه شود.

ساخت نخستین حلقهٔ شما#

نیازی نیست با پایپ‌لاینی با توان عملیاتی بالا شروع کنید. با کوچک‌ترین چیزی که کار می‌کند آغاز نمایید.

گام 1: انتخاب یک کار تکرارشونده#

کاری را پیدا کنید که دست‌کم دوبار در هفته به‌صورت دستی انجام می‌دهید. نمونه‌ها: - باز کردن گیت‌هاب در صبح، بررسی ایشوهای جدید، اولویت‌بندی و پاسخ‌گویی - اجرای لینت و آزمون‌ها پیش از هر بازبینی PR - به‌روزرسانی اسناد پیشرفت در پایان هر روز

گام 2: نوشتن هدف و شرط توقف#

کار را به چیزی تبدیل کنید که یک /goal بتواند بفهمد:

Goal: Check the 10 most recent issues in the repo.
For each issue:
  - If it already has clear labels and an assignee, skip
  - If untagged, add appropriate labels based on content
  - If fixable in under 10 minutes, create a branch and attempt a fix
Stop when: All qualifying issues have been processed, or an issue requires human decision.

گام 3: تفکیک سازنده از بازرس#

نگذارید همان ایجنت هم کد را بنویسد و هم به آن نمره دهد. حلقهٔ خود را به دو نقش تقسیم کنید: - پیاده‌ساز: ایشو را می‌خواند، اصلاحیه را می‌نویسد، آزمون‌ها را می‌نویسد - راستی‌آزما: آزمون‌ها را مستقلاً اجرا می‌کند، تفاوت‌های کد را بررسی می‌نماید، و قضاوت می‌کند آیا اصلاحیه واقعاً مشکل را حل کرده است یا خیر

گام 4: افزودن حافظه#

از یک فایل مارک‌داون برای ثبت آنچه در هر اجرای حلقه رخ داد استفاده کنید. اجرای بعدی با خواندن این فایل آغاز می‌شود — می‌داند چه چیزی انجام شد، چه چیزی معلق است، و چه مواردی مسدود شدند. این بر هر پایگاه دادهٔ پیچیده‌ای برتری دارد.

گام 5: تنظیم یک تایمر#

از دستور /loop یا کرون‌جاب سیستم‌ایجنت خود استفاده کنید تا حلقه بدون شما آغاز به کار کند. با روزی یک‌بار شروع نمایید. به مدت یک هفته آن را مشاهده کنید.

نردبان بلوغ#

نیازی نیست با یک جهش به بالاترین پله برسید. به‌کارگیری حلقه یک نردبان تدریجی است:

1. سطح 1: اجراکنندهٔ هدف (Goal Runner) — می‌توانید با /goal وظیفه‌ای همراه با شرط توقف بدهید؛ ایجنت تا برآورده شدن آن حلقه می‌زند.
2. سطح 2: تک‌وظیفهٔ زمان‌بندی‌شده — یک خودکارسازی یک وظیفه را روی تایمر اجرا می‌کند (مانند بررسی صبحگاهی CI).
3. سطح 3: حلقهٔ چندایجنتی — تفکیک سازنده و بازرس؛ هر یافته یک ورک‌تری مجزا ایجاد می‌کند.
4. سطح 4: حلقهٔ خودتغذیه‌گر — حلقه کار بعدی خود را به‌طور خودکار از وضعیت خارجی کشف می‌کند؛ خودش تصمیم می‌گیرد در ادامه چه کند.
5. سطح 5: هماهنگ‌سازی ناوگان — چندین حلقه به‌طور موازی اجرا می‌شوند، مستقل اما با لایهٔ حافظهٔ مشترک.

بیشتر تیم‌ها در حال حاضر میان سطح 2 و 3 قرار دارند. سطح 1 سریع‌ترین مسیر برای مشاهدهٔ بازگشت سرمایه است.

نکات کلیدی#

• مهندسی حلقه جایگزین مهندسی هارنس نمی‌شود — بلکه یک طبقه بالاتر از آن ساخته می‌شود. هارنس اجراهای منفرد را قابل‌اعتماد می‌سازد. حلقه اجراهای مداوم را خودمختار می‌کند.
• دستور /goal ساده‌ترین حلقهٔ ممکن است: هدف + راستی‌آزمایی + شرط توقف. این سه مورد شما را از درون حلقه به بیرون آن منتقل می‌کنند.
• شش عنصر بنیادین (خودکارسازی‌ها / ورک‌تری‌ها / مهارت‌ها / رابط‌ها / زیر-ایجنت‌ها / وضعیت خارجی) بلوک‌های سازندهٔ حلقه هستند. نیازی نیست همیشه از همه استفاده شود، اما باید بدانید چه زمانی به سراغ کدام بروید.
• سازنده و بازرس باید تفکیک شوند. نمره‌دهی مدلی به کار خودش غیرقابل‌اعتماد است. یک راستی‌آزمای مستقل — گاه مدلی کاملاً متفاوت — ضامن حداقلی قابلیت اطمینان هر حلقه است.
• حلقه‌ها تولید را تقریباً رایگان می‌کنند و قضاوت را به منبعی کمیاب بدل می‌سازند. زمانی که ذخیره می‌کنید برای استراحت نیست. برای قضاوت‌های بیشتر است.
• چهار هزینهٔ خاموش با طولانی‌تر شدن کار حلقه‌ها عمیق‌تر می‌شوند: بدهی راستی‌آزمایی، فرسودگی درک، تسلیم شناختی، و انفجار توکن‌ها. حلقه‌ها خروجی را شتاب می‌بخشند — و ریسک را نیز.
• کوچک شروع کنید. یک /goal، یک کرون‌جاب، یک فایل حافظهٔ مارک‌داون. بازگشت سرمایه را ببینید، سپس طبقات بالاتر را بسازید.

منابع بیشتر#

• Addy Osmani: Loop Engineering
• Addy Osmani: Agent Harness Engineering
• Simon Willison: Designing Agentic Loops (Sep 2025)
• Karpathy: autoresearch
• Claude Code: Dynamic Workflows and Orchestration
• Loop Library (Forward Future) — مجموعهٔ عمومی از 50 حلقهٔ واقعی
• The Neuron: Claude Code Creators on Agent Loops
• درس 12: بر جای گذاشتن یک تحویل تمیز در پایان هر نشست — پیش‌نیاز حلقه‌ها: هر نشست وضعیتی تمیز بر جای می‌گذارد تا دور بعدی بتواند خودکار شروع شود
• درس 5: زنده نگه‌داشتن زمینه در طول نشست‌ها — دانش پیش‌نیاز برای وضعیت خارجی و حافظه
• درس 11: مشاهده‌پذیر ساختن زمان اجرای ایجنت — هر چه حلقه سریع‌تر بچرخد، برای مهار مشکلات به مشاهده‌پذیری بیشتری نیاز دارید
• درس 8: استفاده از فهرست ویژگی‌ها برای محدود کردن کارهای ایجنت — فهرست‌های ویژگی‌ها منبع دادهٔ طبیعی برای یک حلقهٔ خودتغذیه‌گر برای کشف کار بعدی هستند

تمرین‌ها#

1. تبدیل یک کار تکرارشونده به یک /goal: کاری را که دست‌کم دوبار در هفته دستی انجام می‌دهید پیدا کنید. هدف، روش راستی‌آزمایی، و شرط توقف آن را مکتوب نمایید. آن را یک‌بار با /goal اجرا کنید و زمان و کیفیت را با انجام دستی مقایسه نمایید. این نخستین گام شما از هارنس به حلقه است.

2. تفکیک سازنده و بازرس: وظیفه‌ای را که قبلاً به یک ایجنت سپرده‌اید بردارید. این‌بار دو پرامپت متفاوت بنویسید: یکی برای ایجنت پیاده‌ساز و دیگری برای ایجنت راستی‌آزما (از مدل‌های متفاوتی استفاده کنید — مثلاً Claude برای پیاده‌سازی و GPT برای راستی‌آزمایی، یا برعکس). راستی‌آزما باید مشکلات مشخص را همراه با شواهد مستند بیان کند. تعداد و نوع مشکلات کشف‌شده را در هر حالت ثبت کنید.

3. ایجاد حافظه برای حلقه: یک فایل وضعیت مارک‌داون برای حلقهٔ خود ایجاد کنید. در هر تکرار بنویسید: در این دور چه شد، نتایج راستی‌آزمایی، وضعیت (قبول/رد/مسدود)، و اینکه در ادامه چه باید کرد. سه دور اجرا کنید و تفاوت رفتاری میان داشتن و نداشتن فایل حافظه را مشاهده نمایید.

4. ارزیابی هزینه‌های خاموش حلقه: پس از اینکه حلقهٔ شما یک ساعت کار کرد، این چهار سنجه را بررسی کنید: - چه مقدار از راستی‌آزمایی‌ها در حد «درست حس می‌شود» بودند تا «تأییدشده توسط ماشین»؟ (بدهی راستی‌آزمایی) - چقدر خوب می‌توانید کدی را که حلقه در آخرین مرحله تولید کرد توضیح دهید؟ (فرسودگی درک) - چند بار با خود گفتید «بعداً نگاه می‌کنم» و هرگز نگاه نکردید؟ (تسلیم شناختی) - روند اندازهٔ زمینهٔ حلقه چگونه است؟ آیا اطلاعات تکراری را بازگو می‌کند؟ (انفجار توکن‌ها)