تیم‌های مهندسی که در حال ارزیابی عامل‌های کدنویسی (coding agents) هستند، معمولاً با سوال اشتباهی شروع می‌کنند. آن‌ها می‌خواهند بدانند این عامل چقدر می‌تواند خودمختار باشد. چه بخشی از خط لوله (pipeline) را می‌تواند در اختیار بگیرد؟ آیا می‌تواند مشخصات (spec) را بنویسد، مخزن (repository) را ویرایش کند و بدون مزاحمت برای کسی، کد را به مرحله تولید (production) برساند؟ دموها این وسواس را تشدید می‌کنند. شما یک گردش کار روان را می‌بینید که در آن یک پرامپت (prompt) واحد، زنجیره‌ای از ویرایش‌ها و استقرارها (deployments) را آغاز می‌کند، و غریزه شما این است که در سازمان خود نیز به دنبال همان قابلیت باشید. اما جذابیت ظاهری، اصل طراحی بدی است. سوالات بهتر بسیار کم‌هیجان‌تر هستند: چه کسی به این موجود اختیار داده است، واقعاً به چه سیستم‌هایی دسترسی دارد، و وقتی ناگزیر اشتباه می‌کند، چه اتفاقی می‌افتد؟

تله‌ی خودمختاری

خودمختاری هیجان‌انگیز یک تله است. این موضوع ما را عادت می‌دهد که ربات‌هایی را تحسین کنیم که مشخصات را تولید می‌کنند، مخازن را تغییر می‌دهند و کد را مستقر می‌کنند، در حالی که با آرامش ادعا می‌کنند کار تمام شده است. این مهندسی نیست؛ این یک بازیِ اعتماد (trust fall) با دسترسی به شل (shell access) است. خودِ کارِ تولید، تقریباً بیش از حد آسان می‌شود. هر مدلی می‌تواند در عرض چند ثانیه کد، مستندات یا طرح‌های معماری تولید کند. اما هزینه واقعی در توسعه نرم‌افزار هرگز سرعت تایپ نبوده است. هزینه همیشه مربوط به اعتبارسنجی (validation)، بازبینی (review) و تصمیم دقیق برای گفتنِ «بله، این درست است و برای عرضه ایمن است» بوده است. کارِ تولیدشده ارزان است، اما تأیید (approval) گران است. شرکت‌هایی که راهی برای مدیریت تمیز و سازگارِ فرآیند تأیید پیدا کنند، همان‌هایی خواهند بود که واقعاً سیستم‌های قابل اطمینان را عرضه می‌کنند.

چرا خودبازبینی شکست می‌خورد

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

پرامپت‌ها سیستم‌های اجازه نیستند

شما نمی‌توانید یک عامل را با کلمات هوشمندانه ایمن کنید. گفتن اینکه «مراقب باش» یا «قبل از حذف چیزی اجازه بگیر» به یک مدل، مرزی ایجاد نمی‌کند. پرامپت‌ها سیستم‌های اجازه (permission systems) نیستند. قبل از اینکه اجازه دهید عاملی حتی به محیط تولید نزدیک شود، به یک فهرست صادقانه از قابلیت‌های آن نیاز دارید. آیا می‌تواند کل مخزن را بخواند؟ آیا می‌تواند دستورات شل را اجرا کند؟ آیا می‌تواند مرورگر را باز کند؟ آیا می‌تواند داده‌های مشتری را به پنجره کانتکست (context window) خود بکشد؟ اکثر تیم‌ها پاسخ کامل این‌ها را نمی‌دانند. آن‌ها تصور می‌کنند ابزار در یک محیط ایزوله (sandbox) محدود شده است، در حالی که در واقعیت دسترسی نوشتن به مسیرهای حیاتی را دارد. ابتدا سطح تماس (surface area) را شناسایی کنید، سپس دیوارها را بسازید.

یک سیستم کنترل چندسطحی بسازید

وقتی فهمیدید عامل چه کارهایی می‌تواند انجام دهد، سیستم کنترلی‌ای طراحی کنید که میزان ریسک را با میزان اصطکاک (friction) مطابقت دهد. اقدامات کم‌ریسک، مانند به‌روزرسانی مستندات داخلی یا قالب‌بندی یکدست کد، می‌توانند به‌صورت خودکار اجرا شوند. اقدامات میان‌ریسک، مانند بازنویسی (refactoring) یک ماژول یا افزودن یک وابستگی (dependency) جدید، باید به یک نقطه بازرسی برسند که در آن یک انسان یا یک مجموعه تست تأییدشده، آن حرکت را تأیید کند. اقدامات پرریسک، مانند استقرار در محیط تولید، تغییر زیرساخت یا دسترسی به داده‌های حساس، به یک تأییدکننده مجزا نیاز دارند که در فرآیند تولید درگیر نبوده است. هر اقدام باید یک ردپای حسابرسی (audit trail) به جا بگذارد. شما باید بتوانید دقیقاً بازسازی کنید که کدام فایل‌ها خوانده شدند، کدام ابزارها فراخوانی شدند و چه تصمیماتی گرفته شد. توسعه مبتنی بر عامل، مجوزی برای نادیده گرفتن بازبینی‌ها نیست. اصطکاکِ خسته‌کننده، یک ویژگی (feature) است. یک دروازه تأیید مناسب، مانند یک قطع‌کننده مدار (circuit breaker) عمل می‌کند، زمانی که اوضاع شروع به انحراف می‌کند.

مرزها را با ریسک مطابقت دهید

مرزهای خود را با خطر واقعی تنظیم کنید. تبدیل هر تغییر جزئی در قالب‌بندی Markdown به یک مراسم انطباق (compliance)، تیم شما را از حرکت باز می‌دارد. اما برخورد با اقدامات حساس به عنوان اموری بی‌خطر، صرفاً به این دلیل که عامل با اعتمادبه‌نفس به نظر می‌رسد، به همان اندازه احمقانه است. هدف، کنترل متناسب است، نه محدودیت نمایشی.

مصنوعات (Artifacts) را کوچک و قابل مشاهده نگه دارید

مفیدترین سیستم‌های ایجنت سعی نمی‌کنند شما را با اجراهای خودکارِ عظیم شگفت‌زده کنند. آن‌ها خروجی‌های (artifacts) کوچک و قابل بازبینی تولید می‌کنند. یک برنامه‌ی دقیق. یک تغییرات (diff) متمرکز. یک لاگ خوانا. اجراهای خودکارِ عظیم، کابوسی برای عیب‌یابی (debug) هستند. وقتی پس از یک نشستِ ایجنت با پنجاه فایل، چیزی خراب می‌شود، باید همزمان قصد، اجرا و اثرات جانبی را از هم باز کنید. شعاع تخریب را کوچک نگه دارید. بر دانستن اینکه ایجنت کدام فایل‌ها را خوانده و از کدام ابزارها استفاده کرده، پافشاری کنید. سیستم‌های قابل مشاهده (Observable)، سیستم‌های قابل نگهداری هستند. خودمختاریِ جعبه‌سیاه (Black-box autonomy) چیزی نیست جز بدهی فنی با بازاریابی بهتر.

شش پرسش پیش از اعطای دسترسی

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

  • سیستم واقعاً چه قابلیت‌هایی دارد؟
  • کدام اقدامات به‌صورت پیش‌فرض ممنوع هستند؛ یعنی در سطح زیرساخت مسدود شده‌اند، نه اینکه صرفاً با یک جمله‌ی مؤدبانه در پرامپت سیستم از انجام آن‌ها بازداشته شوند؟
  • کدام اقدامات نیازمند تأیید صریح هستند؟
  • کدام خروجی‌ها (artifacts) پیش از آنکه ایجنت آن‌ها را مصرف کند، منجمد (frozen) می‌شوند تا نتواند بی‌صدا ورودی‌های خود را دستکاری کند؟
  • کدام اعتبارسنج (validator)، که کاملاً از تولیدکننده (generator) جداست، خروجی نهایی را قضاوت می‌کند؟
  • کدام لاگ، بدون ابهام، ثابت می‌کند که واقعاً چه اتفاقی افتاده است؟

این یک بهداشت مهندسیِ پایه است. تولیدکننده را از اعتبارسنج جدا کنید. مرجعیت انسانی را در مرزها حفظ کنید.

آزمون واقعی

آنجا