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

چرا «روی حلقه» اهمیت دارد

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

بازگرداندن اصول مهندسی: CI/CD برای عامل‌ها

اصول پذیرفته‌شده در DevOps و Continuous Delivery باید برای کار با عامل‌ها نیز اعمال شود. خطوط لولهٔ تحویل پیوسته (CI/CD) باید طوری طراحی شوند که هر بار تولید توسط عامل‌ها از مجموعهٔ همان تست‌ها، کنترل‌ها و بررسی‌ها عبور کند؛ در صورت مشاهدهٔ باگ، اصلاح باید در «منبع» انجام شود تا جلوی تکرار خطا گرفته شود.

سخنرانی کیف موریس در PlatformCon لندن درباره مهندسی هارنس

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

تعریف «خوب» باید ملموس و قابل اندازه‌گیری باشد

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

بدهی‌ها؛ سه سطلِ هزینهٔ پنهان

موریس با اتکا به کارهای مارگارت-آن استوری و چارچوب SPACE اشاره می‌کند هوش مصنوعی می‌تواند سه نوع بدهی پنهان ایجاد کند که در بلندمدت هزینه‌ساز خواهند بود:

بدهی فنی

مشکلات و پیچیدگی‌های موجود در خودِ کد که نگهداری، توسعه و رفع اشکال را سخت می‌کند. مثال: تکه‌کدهای تولیدی که استانداردهای ساختاری و تست را رعایت نمی‌کنند.

بدهی شناختی

افزایش بار ذهنی و سردرگمی اعضای تیم که فهمِ سیستم را دشوار می‌کند؛ برای مثال، کدی که بدون مستندسازی یا نام‌گذاری مناسب تولید شده و درک منطق آن برای توسعه‌دهندهٔ بعدی طولانی یا پرخطا است.

بدهی نیت

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

عملیاتی‌سازی: گام‌های فوری برای تیم‌ها

  • تعریف معیارهای قابل سنجش برای «کد خوب» مطابق نیازهای کاربران و اهداف تجاری؛ این معیارها باید در پذیرش تغییرات وارد خط لوله شوند.
  • گسترش تست‌های واحد، یکپارچه و امنیتی داخل خط لولهٔ CI/CD تا عامل‌ها تنها در صورت عبور از آن‌ها امکان استقرار پیدا کنند.
  • اتومات‌سازی کنترل‌های بازگشتی (guardrails) و الزامِ امضای تغییرات در مبنای کد تا اصلاحات در منبع ثبت و قابل پیگیری باشد.
  • مستندسازی صریح تصمیمات طراحی و قواعد نیت برای کاهش بدهی نیت؛ شامل توضیح اهداف، محدودیت‌ها و موارد استثنایی.
  • پایش تولیدی و مانیتورینگ که بازخورد سریع به منبع و تیم توسعه برگرداند؛ معیارهای عملکرد، خطا و رفتار عامل‌ها مستمراً رصد شوند.

چشم‌انداز

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