مهندسی حلقه (Loop engineering) در صدر توجهات قرار گرفته است. کافی است در هر انجمن فنی جستجو کنید تا با صداهایی مواجه شوید که استدلال میکنند ما باید از برخورد با عاملهای هوش مصنوعی (AI agents) مانند چتباتهایی که با پرامپتهای هوشمندانه آموزش میبینند، دست برداریم. در عوض، آنها میگویند که باید حلقهها را طراحی کنیم: چرخههای خودگردانی که به یک عامل اجازه میدهند برنامهریزی کند، اجرا کند، کار خود را بررسی کند و در حالی که ما خواب هستیم، تکرار و اصلاح (iterate) انجام دهد. این پیشنهاد وسوسهانگیز است. اگر حلقه به خوبی ساخته شده باشد، عامل بدون نظارت مداوم انسان در مسیر درست میماند و قصد و نیت اولیه را طی یک شب به خروجی نهایی تبدیل میکند.
این وعده در تئوری بسیار زیبا عمل میکند. در عمل، اکثر عاملها از قبل دارای حلقه هستند. آنها کد تولید میکنند، خطاهای کامپایلر یا شکستهای تست را بررسی میکنند، کد را اصلاح میکنند و دوباره مجموعه تست را اجرا میکنند. این چرخه بازخوردِ پایه، چیز جدیدی نیست. آنچه حامیان این حوزه اکنون خواستار آن هستند، چیزی جاهطلبانه تر است: یک «حلقه بیرونی» (outer loop) که بر کل وظیفه نظارت کند، نه فقط بر خطاهای سینتکسی. ساختن این حلقه بیرونی جایی است که کار دشوار میشود، زیرا مهندسی نرمافزار به ندرت یک سیستم بسته با قوانین ثابت است.
مسئله طراحی حلقه
اهداف محصول معمولاً مبهم و پیچیده هستند. شما به ندرت با یک تعریفِ دقیق از «انجامشده» (definition of done) کار را شروع میکنید. اغلب، زمانی که در میانه فرآیند ساخت هستید، هدف واقعی را کشف میکنید. الزامی که روی تخته سفید ساده به نظر میرسید، ممکن است در عمل دارای موارد خاصی (edge cases) باشد که شکل راهکار را کاملاً تغییر دهد. وقتی یک عامل را درون یک حلقه صلب و انعطافناپذیر قرار میدهید، این صلبیت به یک نقطه ضعف تبدیل میشود. حلقه مدام به هدفی ضربه میزند که ممکن است هدف اشتباهی باشد. بدتر از آن، یک حلقه منعطف گاهی اوقات با تغییر بیصدای هدف برای مطابقت با هر خروجی که توانسته تولید کند، بنبست را حل میکند. هیچکدام از این دو نتیجه مفید نیست؛ یکی منابع محاسباتی را هدر میدهد و دیگری با اطمینان کامل، زباله تحویل میدهد.
مسئله عمیقتر، هزینه تعیین مشخصات (specification cost) است. اگر میخواهید یک حلقه بدون نظارت اجرا شود، باید مشخصاتی بنویسید که تقریباً همه چیز را پیشبینی کند. عامل دقیقاً باید چه چیزی را تغییر دهد؟ کدام رفتار موجود مقدس است و باید حفظ شود؟ تحت چه شرایط دقیقی عامل باید تکرار را متوقف کند؟ کدام ریسکها قابل قبول هستند و کدام اثرات جانبی باید باعث توقف فوری شوند؟ نوشتن آن سند میتواند بیشتر از نشستن در کنار عامل و هدایت لحظهای آن در طول انجام وظیفه زمان ببرد. شما در حال پرداخت یک مالیات سنگین اولیه هستید تا در ازای اتوماسیونی، بهرهمند شوید که تنها در صورتی سودآور است که هزینه راستیآزمایی (verification) به طور چشمگیری کمتر از هزینه انجام کار باشد.
حلقهها در کجا واقعاً ارزش خود را ثابت میکنند
این بدان معنا نیست که مهندسی حلقه بیفایده است. بلکه به این معناست که این یک ابزار تخصصی است، نه یک استراتژی همهجانبه. حلقهها زمانی میدرخشند که هزینههای راستیآزمایی به صورت ترکیبی افزایش مییابد و معیارهای موفقیت بدون ابهام هستند. سه حوزه وجود دارد که این موضوع در آنها صادق است.
کارهای مکانیکی روتین. به کارهایی فکر کنید که باعث میشود مهندسان ارشد بخواهند بازنشسته شوند: اجرای برنامهها با یک توالی خاص، کلیک کردن در رابط کاربری استقرار (deployment UI) برای تأیید هر مرحله، جستجوی لاگها (grep) برای رشتههای خطای شناخته شده پس از انتشار، یا تأیید اینکه یک فایل پیکربندی در تمام گرههای درست نوشته شده است. این مراحل برای انسانها خستهکننده اما برای راستیآزمایی ساده هستند. یک حلقه میتواند بر فرآیند نظارت کند، نقاط پایانی سلامت (health endpoints) را پس از هر بار راهاندازی مجدد بررسی کند و در اولین نشانه بروز مشکل، عملیات را به حالت قبل برگرداند (rollback). انسان همچنان طرح استقرار را تعریف میکند؛ حلقه صرفاً آن را با صبر و حوصلهی یک ماشین در ساعت دو صبح اجرا میکند.
اهداف بهینهسازی قابل اندازهگیری. وقتی موفقیت با یک عدد سنجیده میشود، حلقهها به شکلی خیرهکننده موثر هستند. کاهش تأخیر p99 به زیر ۱۵۰ میلیثانیه. کاهش ۲۰ درصدی ردپای حافظه (memory footprint). مهاجرت یک مسیر پرکاربرد (hot path) از Python به Rust و اطمینان از اینکه تمام تستهای واحد موجود همچنان پاس میشوند. حلقه میتواند یک تغییر ایجاد کند، آن را بنچمارک کند، نسخهای را که تغییر ملموسی ایجاد کرده نگه دارد و بقیه را دور بریزد. از آنجایی که راستیآزمایی خودکار است و فضای جستجو بزرگ است، هزینه ترکیبی بررسی دستی، انجام این کار را بدون یک حلقه غیرعملی میکند. هدف ثابت است، اما مسیر ناشناخته است؛ این دقیقاً نقطه طلایی است.
دستورالعملهای عملیاتی (Operational playbooks). پاسخ به حوادث و تیکتهای پشتیبانی اغلب از الگوهایی پیروی میکنند که انسانها قبلاً کشف کردهاند. یک کلاس خاص از خطاهای تولید همیشه مستلزم چرخش یک اعتبارنامه (credential) و پاک کردن حافظه پنهان (cache) است. یک دسته از درخواستهای پشتیبانی میتواند با بازپرداخت وجه، در صورت برآورده شدن سه شرط خاص، حل شود. یک حلقه میتواند مراقب آن محرکها باشد و دستورالعمل را اجرا کند و تنها زمانی که الگو شکسته شد، موضوع را به سطوح بالاتر ارجاع دهد. حلقه تصمیم نمیگیرد که دستورالعمل درست است یا خیر؛ بلکه صرفاً سازگاری را با مقیاس و سرعتی اعمال میکند که مهندسانِ آنکال (on-call) نمیتوانند با آن برابری کنند.
تنظیمکننده، نه تعیینکننده مرجع
یک تمایز حیاتی در بسیاری از گفتگوهای فعلی نادیده گرفته شده است. حلقهها تنظیمکننده هستند. آنها سیستم را با یک هدف از پیش تعیینشده همسو نگه میدارند، درست همانطور که یک ترموستات دمای اتاق را روی هفتاد و دو درجه نگه میدارد. اما ترموستات عدد هفتاد و دو را انتخاب نمیکند؛ بلکه ابتدا باید کسی تصمیم میگرفت که این دمای مناسب است.
در حوزه نرمافزار، این بدان معناست که یک عامل (agent) در داخل یک حلقه میتواند تمام روز را صرف رفع باگها، بازنویسی (refactor) توابع یا تنظیم پارامترها کند. با این حال، نمیتواند تصمیم بگیرد که کدام ویژگی واقعاً به مشتری کمک میکند یا آیا یک باگ ارزش دارد که قبل از انتشار بعدی اصلاح شود یا خیر. این انتخابها نیازمند قضاوت درباره بافت کسبوکار، نیازهای کاربران و اولویتهای استراتژیک است. عاملها اجرا میکنند، انسانها تصمیم میگیرند. اشتباه گرفتن این دو باعث میشود تیمها در نهایت با سیستمهایی بسیار بهینه روبرو شوند که در حال حل کردن مشکل اشتباهی هستند.
مهندسی حلقه (Loop engineering) مفید است، اما محدود است. این کار به شما کمک میکند ماشین را با نظم و سرعت اجرا کنید، اما تصمیم نمیگیرد که چه ماشینی ساخته شود، برای چه کسی است، یا موفقیت از دیدگاه انسانی چگونه تعریف میشود. قضاوت درباره اینکه کدام ویژگی اهمیت دارد، کدام ریسک قابل قبول است و چه زمانی خودِ هدف باید تغییر کند، با شماست. حلقهها را برای کارهایی بسازید که به اندازه کافی آنها را میشناسید تا بتوانید بهطور خودکار تأییدشان کنید. مسئولیت هر چیز دیگری را خودتان بر عهده داشته باشید.
این مقاله بر پایه ایدههایی است که در اصل توسط Isaac Hagoel در “Loop Engineering Minus The Hype.” مطرح شده است. برای بحثهای مهندسی بیشتر، به انجمن یادگیری ما در Telegram بپیوندید.