تصور کنید برنامهنویسی هستید که برای تسریع کار، هم کدنویسی و هم بازبینی (Review) را به هوش مصنوعی سپردهاید، اما بهجای اتمام پروژه، در تلهای از اصلاحات بیپایان گیر کردهاید. این کابوس زمانی رخ میدهد که دقت فنی مدل، جایگزین هدف نهایی محصول شود.
به گزارش وبسایت dev.to در ۱۱ اوت ۲۰۲۶، یک توسعهدهنده با چالشی عجیب روبرو شد: یک درخواست تغییر (Pull Request) با ۲۱,۹۶۲ خط کد، طی دو روز منجر به ۲۰۹ گفتگو درباره بازبینی شد. مشکل حجم کار نبود، بلکه سازوکار سیستم بود؛ چراکه مدل Codex هم کد را نوشته بود و هم آن را بازبینی میکرد. این سیستم بسته، چرخهای از اصلاحات بیپایان ایجاد کرد که نزدیک بود توسعه قابلیت جدید را متوقف کند.
این پروژه مربوط به یک قابلیت امنیتی برای انتشار اثرات مخرب (Taint Propagation) در مراحل گردشکار بود. ابعاد کار بسیار گسترده بود: ۸۳ فایل در ۳۶ کامیت تغییر کرده بودند. این اتفاق شکافی حیاتی در نحوه استقرار عاملهای هوش مصنوعی (AI Agents) — شبیه به کارمندانی دیجیتال که میتوانند کارهای پیچیده بهطور مستقل انجام دهند — را نشان میدهد. همانطور که در تحلیلهای قبلی ما درباره اتوماسیون رفع باگها اشاره کردیم، این مورد ثابت میکند که صحت فنی لزوماً به معنای پیشرفت پروژه نیست. این چالش با گزارش OpenAI درباره نقص در برخی سناریوهای محک کدنویسی همسو است که نشان میدهد حتی در محیطهای تستشده نیز معیارهای موفقیت لزوماً با واقعیت عملی تطابق ندارند. وقتی یک بازبین هوش مصنوعی یک مورد خاص (Edge Case) را پیدا میکند، کدنویس هوش مصنوعی آن را اصلاح میکند و این اصلاح، مورد خاص جدید و ظریفتری را برای بازبین ایجاد میکند.
طبق مستندات این گزارش، ۹۰٪ نظرات هوش مصنوعی از نظر فنی کاملاً درست بودند. Codex مواردی را میدید که یک بازبین انسانی خسته احتمالاً از آنها چشمپوشی میکرد یا با یک اشاره ساده از کنارشان میگذشت. توسعهدهنده پیش از این روشهای جایگزین دیگری را امتحان کرده بود؛ مثلاً اینکه عامل اصلی کد را خودش بازبینی کند، یا از یک مدل متفاوت به عنوان زیر-عامل (Subagent) استفاده کند، و یا بازبینیها را در دو مرحله مجزا اجرا نماید. با این حال، حتی پس از عبور از این فیلترها، Codex همچنان مسائل جدیدی را پیدا میکرد. این یافتهها منجر به اثر «دنبال کردن دم» (Tail-chasing) شد. در یک بعدازظهر، او بین ساعت ۱۳:۱۲ تا ۱۵:۰۸، دوازده بهروزرسانی مجزا را فقط برای پاسخ به یافتههای جدید هوش مصنوعی منتشر کرد؛ یعنی تقریباً هر ۱۰ دقیقه یک دور اصلاحات جدید رخ میداد.
مکانیسم ایجاد حلقه
این چرخه به این دلیل تداوم مییابد که هر دو عامل کدنویس و بازبین برای «جامع بودن» و بررسی تمام جزئیات آموزش دیدهاند. در این پروژه، الگو به این شکل بود:
- Codex یک مورد خاص با شدت P1 یا P2 را شناسایی میکند.
- عامل کدنویس برای راضی کردن بازبین، یک اصلاحیه (Fix) را اعمال میکند.
- کد جدید باعث ایجاد یک تغییر معنایی ظریف (Semantic Drift) یا یک مورد خاص جدید میشود.
- بازبین این تغییر جدید را شناسایی کرده و چرخه از نو آغاز میشود.
این روند تا جایی ادامه مییابد که کد از هدف اصلی محصول فاصله گرفته و به وسواسی برای رسیدن به کمال تئوریک تبدیل میشود. توسعهدهنده اشاره کرد که مدل نمیتواند «کوه» یا همان هدف نهایی محصول را ببیند، چون این اطلاعات در خارج از محیط کدبیس (Codebase) قرار دارد. وقتی یک Codex که برای «اصلاح تا انتها» طراحی شده، رو در روی یک Codex قرار بگیرد که برای «یافتن تا انتها» ساخته شده است، چرخه بیپایان بهجای اینکه یک اتفاق تصادفی باشد، به حالت پیشفرض سیستم تبدیل میشود. این رفتار یادآور تحلیلهای ما درباره سوءاستفاده از پاداش در عاملهای AI است، جایی که مدل برای بهینهسازی یک معیار خاص (در اینجا جامعیت بازبینی)، هدف کلی سیستم را نادیده میگیرد.
شکستن چرخه
برای توقف این وضعیت، توسعهدهنده استراتژی خود را از «واکنش به یافتهها» به «اجرای قرارداد تاییدشده کاربر» (Ratified User Contract) تغییر داد. او بهجای دنبال کردن هر پیشنهاد فنی، دو قانون مشخص و سختگیرانه را مکتوب کرد: اول اینکه اعتبارنامههایی که فقط برای احراز هویت استفاده میشوند باید قابل استفاده بمانند، و دوم اینکه مقادیر محرمانه (یا هر چیزی که از آنها مشتق شده باشد) باید بهطور خودکار مسدود شوند.
با تبدیل این دو جمله به قرارداد رسمی قابلیت، یک مرز مشخص ایجاد شد. صبح روز بعد، او بهجای عبارت «یافتههای اخیر را اصلاح کردم»، صراحتاً بیان کرد که کد «بر اساس قرارداد تاییدشده بازنویسی شده است». این تغییر رویکرد، چرخهای را که در دو ساعت دوازده بار تکرار شده بود، به تنها دو کامنت و یک درخواست بازبینی نهایی کاهش داد و در نهایت اجازه داد کد ادغام (Merge) شود.
اصول بازبینی با هوش مصنوعی
این تجربه منجر به تدوین چهار اصل راهنما برای مدیریت بازبینیهای هوش مصنوعی شد که در طول دو هفته در Pull Requestهای بعدی نیز پایداری خود را حفظ کردند:
- خوانش کاربرمحور: هر کامنت را از دیدگاه محصول بخوانید. نپرسید «آیا این نظر درباره کد درست است؟»، بلکه بپرسید «اگر این تغییر را اعمال کنم، چه چیزی برای کاربر عوض میشود؟».
- وزندهی بر اساس اثرگذاری: شدت خطا را با اثر آن روی کاربر بسنجید. نظری که جلوی کرش کردن برنامه را میگیرد، در کلاس اولویت متفاوتی نسبت به نظری است که صرفاً یک نام را صیقل میدهد یا زیباتر میکند.
- واکنش تأخیری: فوراً اصلاح نکنید. درک کنید که کد اصلاحشده چه رابطهای با آنچه از قبل وجود دارد دارد؛ اصلاحات عجولانه معمولاً به ماده اولیه برای دور بعدی بازبینیها تبدیل میشوند.
- نادیده گرفتن استراتژیک: اگر یافتهای مانع ادغام کد (Merge Blocker) نمیشود، آن را به عنوان یک «Issue» در ردیاب ثبت کنید یا نادیده بگیرید. نظر درست اما غیرضروری در لحظه فعلی، جایگاهی در Pull Request ندارد.
برای برنامهنویسان مدرن، نقش انسان در حال تغییر است. ما دیگر بازبین اصلی کد نیستیم، بلکه تعریفکننده «وضعیت نهایی» (End State) هستیم. نادیده گرفتن یک نظر درست از هوش مصنوعی، تنبلی نیست، بلکه یک تصمیم مدیریتی ضروری است تا پروژه مسیرش را گم نکند. اعمال هر نظر درست در یک منبع نامحدود، دقت نیست، بلکه شکست در قضاوت است. این رویکرد با تغییر پارادایم ارزیابی پایداری عاملهای هوشمند همسو است که بر اهمیت معیارهای فراتر از صحت محض تأکید دارد.
اینکه آیا میتوان «جوهر» یک محصول را از ابتدا به یک عامل داد — یعنی ارائه معیارهای پایان بهجای اینکه هر بار انسان آن را تعریف کند — هنوز یک آزمایش باز است. تا آن زمان، انسان در حلقه (Human in the loop) تنها ترمز موجود در برابر میل هوش مصنوعی به صعود از قلههای بیربط است.
گام بعدی شما
- در بازبینیهای بعدی، بهجای پذیرش تمام پیشنهادات AI، یک لیست از «قوانین غیرقابل مذاکره» برای محصول خود بنویسید.
- هرگاه احساس کردید در حال اصلاحات جزئی و تکراری هستید، از خود بپرسید: «آیا این تغییر واقعاً تجربه کاربر را بهبود میدهد یا فقط کد را تئوریکتر میکند؟».
- برای موارد غیرضروری، بهجای اصلاح کد در PR، از سیستم Ticket-ing استفاده کنید تا جریان توسعه متوقف نشود.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو