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

پیاده‌سازی لوپ‌ها روی کاغذ جذابه اما تو واقعیت به شدت پرهزینه است. یک لوپ ساده برای یک تسک برنامه‌نویسی می‌تونه به راحتی بین ۵۰ تا ۲۰۰ هزار توکن مصرف کنه. اگه محدودیت نذارید و از مدل‌های گرون‌قیمت استفاده کنید، تو چند روز کل بودجه API شما نابود میشه. دلیل اینکه این روزها پیاده‌سازی لوپ منطقی شده، ظهور مدل‌های ارزون‌قیمت با کانتکست بالا (مثل سری DeepSeek V4) هست که اجازه میدن ایجنت‌ها بدون نگرانی از هزینه، بارها خطا کنن و خودشون رو دیباگ کنن.

معماری یک لوپ مهندسی‌شده و پایدار از ۶ بخش اصلی تشکیل میشه که باید دقیق کنار هم چیده بشن:
بخش Automations: یک سیستم زمان‌بندی (کرون جاب یا هوک) که لوپ رو بیدار می‌کنه. به جای اجرای دستی، سیستم هر روز صبح ایشوها رو چک می‌کنه.
مفهوم Worktrees: وقتی چند ایجنت موازی کار می‌کنن، نباید فایل‌های هم رو خراب کنن. استفاده از قابلیت worktree تو گیت باعث میشه هر ایجنت تو دایرکتوری ایزوله خودش کار کنه.
فایل‌های Skills: ایجنت‌ها حافظه ندارن. باید فایل‌هایی مثل VISION.md یا SKILL.md تعریف بشه تا کانونشن‌های پروژه رو یک‌بار بخونن و هر بار از صفر شروع نکنن.
پروتکل Connectors: استفاده از MCP برای اتصال ایجنت به دنیای واقعی. ایجنت باید بتونه تیکت جیرا رو آپدیت کنه یا تو اسلک پیام بده، نه اینکه فقط روی فایل سیستم بچرخه.
معماری Sub-agents: مدلی که کد رو می‌نویسه، نباید خودش رو ارزیابی کنه. همیشه باید یک ایجنت برای تولید (Maker) و یک ایجنت ایزوله با دستورالعمل‌های سخت‌گیرانه‌تر برای تایید (Checker) داشته باشید.
مدیریت State: یک فایل ساده STATE.md که لاگ کارهای انجام شده و ارورها رو نگه می‌داره تا لوپ در اجرای بعدی بدونه کجا متوقف شده و دوباره از صفر اختراع نکنه.

بزرگترین اشتباه در ساخت لوپ، نبودن یک گیت اعتبارسنجی سفت و سخته. اگر معیار پایان کار، نظر خود ایجنت باشه، لوپ شما توهم می‌زنه و کار رو نصفه رها می‌کنه. یک لوپ واقعی به محض توقف، باید به صورت خودکار تست‌ها یا Linter رو اجرا کنه (مثلا با اجرای دستورات تست در پس‌زمینه). اگر خروجی خطا داشت، لاگ ارور به صورت خودکار به کانتکست برمی‌گرده و ایجنت مجبور به رفع اون میشه. برای جلوگیری از گیر کردن در لوپ بی‌نهایت، حتما باید یک Hard limit (مثلا حداکثر ۵ بار تلاش) براش تعریف بشه تا اگر نتونست حلش کنه، تسک رو به انسان بسپاره.

بدهی درک کد (Comprehension debt) خطرناک‌ترین عارضه این سیستمه. وقتی لوپ‌ها با سرعت بالا کد می‌زنن و مرج می‌کنن، فاصله بین چیزی که تو ریپو هست و چیزی که شما از معماری می‌فهمید به شدت زیاد میشه. این سیستم قرار نیست شما رو از چرخه مهندسی حذف کنه. اگر لوپ روی کدهای حساسی مثل منطق Auth یا سیستم پرداخت رها بشه، فاجعه امنیتی و منطقی به بار میاد. بهترین نقطه شروع، اتوماتیک کردن رسیدگی به خطاهای CI، آپدیت Dependencyها و رفع باگ‌های مشخص و تکراریه.

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

🛠 Join @LLMEngineers Community