تصور کنید جمعه ساعت ۱۶:۴۰ است و یک سرویس پرداخت پایتون نیاز به اصلاح فوری دارد. در این لحظه، پنجرهٔ چت با یک دستیار هوش مصنوعی خطرناک‌ترین جای ممکن برای تأیید نتیجه است؛ جایی که مدل با اطمینان می‌گوید «همه چیز درست شد» و یک تغییر ۴۰ خطی را ارائه می‌دهد، اما هیچ دستور تست یا لاگی در کار نیست.
این شکاف میان «اعتمادبه‌نفس مدل» و «رفتار واقعی کد در زمان اجرا»، ریشهٔ اصلی اتلاف ساعت‌ها وقت تیم‌های توسعه در جلسات به‌اصطلاح Vibe-based یا حس‌محور است. طبق گزارش‌های فنی، بسیاری از تیم‌ها تسلط زبانی مدل در رابط کاربری چت را با امنیت مخزن کد (Repository) اشتباه می‌گیرند. در واقع، وقتی ادعای مدل به جای لاگِ سیستم، به عنوان گیتِ ورود به کد تبدیل شود، احتمال بروز باگ‌های بحرانی به‌شدت افزایش می‌یابد. این چالش با تجرباتی مشابه در سیستم‌های خودکار همسو است؛ برای مثال، ثبت دقیق رسید تصمیمات هوش مصنوعی پیش‌تر نشان داد که چگونه نبودِ لاگ‌های شفاف می‌تواند خطاهای منطقی پیچیده را در خط لوله‌های عملیاتی پنهان کند.
برای حل این مشکل، چارچوبی معرفی شده است که از یک درخت تصمیم چهاربرگی استفاده می‌کند تا هیچ جلسه‌ای را با «لحنِ متقاعدکننده» به پایان نرساند. هدف این است که تصمیم برای ادغام (Merge) از احساس انسان دربارهٔ متن چت، به یک فایل لاگ قطعی منتقل شود. در این رویکرد، هوش مصنوعی تنها ابزاری برای پیش‌نویس تست‌هاست، نه شاهدی بر موفقیت خودش.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اتکای مطلق به خروجی مدل بدون لایه‌ی اعتبارسنجی خارجی، ریسک‌های سیستمی ایجاد می‌کند. این چارچوب دقیقاً همین لایه را با تعریف یک واژه‌نامه سخت‌گیرانه ایجاد می‌کند:
- ادعای اتمام (Claim of Done): ادعای زبانی مدل که هیچ ارزش اثباتی ندارد و صرفاً اشاره‌ای به فایل‌هاست.
- تغییر رفتاری (Behavioral Diff): هر تغییری که خروجی، وضعیت ذخیره‌شده یا کدهای خروج را تغییر دهد. اصلاح کامنت‌ها در این دسته نیستند.
- بازتولیدکننده (Reproducer): دستوری که هر شخصی بدون نیاز به متن چت بتواند اجرا کند و نتیجه را ببیند.
- جفت قرمز/سبز (Red/Green Pair): اجرای یک تست که ابتدا در نسخه قبلی شکست بخورد (قرمز) و سپس در نسخه جدید پاس شود (سبز).
- گیت محلی (Local Gate): تستی که روی لپ‌تاپ توسعه‌دهنده با نتایج قطعی اجرا شود.
- گیت خارج از لپ‌تاپ (Off-Laptop Gate): تستی که به دلیل حجم داده یا نیاز به سخت‌افزار، روی سرور اجرا شود.
- گزارش جلسه (Session Report): یک سند JSON کوچک که شامل نوع برگ، دستور اجرا و مسیر لاگ است.
درخت تصمیم چهاربرگی
توسعه‌دهندگان باید هر جلسه را بر اساس سوالات متوالی در یکی از این چهار دسته قرار دهند:
برگ A: بدون تغییر رفتاری
زمانی رخ می‌دهد که مدل فقط مستندات یا کامنت‌ها را اصلاح کرده باشد. در اینجا ادغام تنها پس از بررسی انسانیِ تمام تغییرات مجاز است. چارچوب هشدار می‌دهد که نباید برای تأیید یک کامنت، از سرورهای گران‌قیمت یا مقالات تولیدشده توسط مدل استفاده کرد.
برگ B: تغییر رفتاری بدون جفت قرمز/سبز
این رایج‌ترین حالت شکست در کدنویسی حس‌محور است. مدل منطق کد را تغییر می‌دهد (مثلاً گرد کردن اعداد در محاسبات مالی) و می‌گوید «تمام شد»، اما هیچ تست یا دستوری ارائه نمی‌دهد. در این حالت، ادغام کد به‌طور مطلق ممنوع است.
برگ C: جفت قرمز/سبز محلی
در اینجا بازتولیدکننده روی نسخه قبلی شکست می‌خورد و روی نسخه جدید پاس می‌شود. ادغام تنها زمانی مجاز است که لاگ اجرا (مثلاً خروجی pytest) ذخیره و به Pull Request پیوست شود. متن چت در اینجا اختیاری است، اما لاگ اجباری است.
برگ D: جفت قرمز/سبز خارج از لپ‌تاپ
زمانی کاربرد دارد که ریسک مربوط به داده‌های حجیم باشد (مثلاً پردازش ۵۰ هزار ردیف داده). توسعه‌دهنده دستور را می‌نویسد اما روی سرور اجرا می‌کند. ادغام تنها زمانی رخ می‌دهد که لاگ سرور با مشخصات دستور مطابقت داشته باشد.
پیاده‌سازی فنی
برای اتوماسیون این فرآیند، اسکریپتی به نام done_gate.py ارائه شده است. این ابزار گزارش JSON جلسه را می‌خواند و بر اساس فیلدهای موجود، وضعیت ادغام را اعلام می‌کند. این ابزار تست‌ها را اجرا نمی‌کند، بلکه صرفاً اجازه نمی‌دهد فیلدهای خالی به عنوان «اتمام کار» پذیرفته شوند.
برای تیم‌هایی که نیاز به زیرساختی برای انتقال از برگ B به D دارند، MonkeyCode یک دستیار کدنویسی متن‌باز با دسترسی رایگان به مدل‌ها و سرور فراهم کرده است. این ابزارها به عنوان سطحی برای پیش‌نویس تست‌ها و اجرای دستورات سنگین طراحی شده‌اند، نه جایگزینی برای واژه‌نامه اعتبارسنجی.
تحلیل: جابه‌جایی بار اثبات
این چارچوب بار اثبات را از دوش بازبین انسانی به دوش مصنوعات خروجی هوش مصنوعی منتقل می‌کند. با الزام به اجرای «قرمز» روی نسخه قبلی، احتمال «شکست خاموش» حذف می‌شود؛ یعنی حالتی که مدل تستی می‌نویسد که چه باگ رفع شده باشد و چه نشده باشد، همیشه پاس می‌شود.
برای یک توسعه‌دهنده عملیاتی، گردش کار به این ترتیب است:
۱. تثبیت نسخه قبلی با git rev-parse HEAD.
۲. پذیرش وصله‌ها (Patches) فقط به صورت فایل.
۳. تکمیل session_report.json پیش از تأیید نهایی.
۴. اجرای done_gate.py برای تعیین نوع برگ.
۵. اگر نتیجه برگ B بود: پرامپت بعدی را صرف ساخت بازتولیدکننده کنید، نه پیاده‌سازی مجدد.
۶. اگر نتیجه برگ C بود: لاگ محلی را در پوشه artifacts/ ذخیره کنید.
۷. اگر نتیجه برگ D بود: دستور را به سرور بفرستید و تا تطبیق لاگ، ادغام را رد کنید.
۸. پیوست کردن نوع برگ، دستور و مسیر لاگ به PR.
این متد جایگزین خط لوله‌های CI/CD یا مرزهای امنیتی نیست، بلکه روشی برای مدیریت جلسات فردی است. اگر تغییرات حساس یا غیرقابل بازگشت هستند، باید از خط لوله‌های رسمی استفاده شود. اما برای تیم‌هایی که بر بررسی دستی PRهای تولیدشده توسط AI متکی هستند، این یک گیت مکانیکی در برابر خطاهای ناشی از تسلط زبانی مدل است.
گام بعدی شما
- در جلسه بعدی کدنویسی با AI، به جای پذیرفتن عبارت «Done»، از مدل بخواهید یک بازتولیدکننده (Reproducer) بنویسد که روی کد فعلی شما شکست بخورد.
- یک فایل
session_report.jsonساده برای تغییرات خود بسازید تا متوجه شوید چند درصد از جلسات شما در «برگ B» (بدون تست) متوقف می‌شوند. - اسکریپت
done_gate.pyرا در محیط توسعه خود تست کنید تا عادت کنید خروجی مدل را با لاگ‌های سیستم تطبیق دهید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو