تأیید دستی؛ تنها راه کنترل عامل‌های هوش مصنوعی در پروژه‌های واقعی

تصور کنید مهندسی استخدام کرده‌اید که با سرعت برق تایپ می‌کند و هیچ‌وقت از انتقادات شما نرنجد، اما چندین بار در روز با مهربان‌ترین لحن ممکن به شما دروغ می‌گوید. این توصیف دقیق تجربه‌ی کار با عامل‌های هوش مصنوعی (AI Agents) در مقیاس واقعی است؛ جایی که هرچه اتوماسیون بیشتر می‌شود، نیاز به بازرسی دستی نیز افزایش می‌یابد.

به گزارش مفصلی که یک توسعه‌دهنده در ۱۹ جولای ۲۰۲۶ منتشر کرد، استفاده از ابزاری مثل کلود کد (Claude Code) و جریان‌های کاری چندعاملی (Multi-agent workflows)، نقش برنامه‌نویس را از نویسنده‌ی کد به مسئول کنترل کیفیت تغییر داده است. در این مدل، برنامه‌نویس دیگر کد نمی‌زند، بلکه تمام مسئولیت صحت خروجی را از طریق یک فرآیند سخت‌گیرانه‌ی «تست رگرسیون دستی» بر عهده می‌گیرد. او تجربه خود را مدیریت مهندسی توصیف می‌کند که خستگی‌ناپذیر است و سریع‌تر از هر انسانی تایپ می‌کند، اما گاهی در صمیمی‌ترین حالت ممکن، اطلاعات غلط ارائه می‌دهد.

این رویکرد در حالی مطرح می‌شود که صنعت به دو طیف تقسیم شده است: گروه اول کسانی هستند که صرفاً «پرامپت می‌نویسند و دعا می‌کنند» (Prompts and Prays) تا نتیجه درست باشد. گروه دوم، طرفداران توسعه‌ی مبتنی بر مستندات دقیق (Spec-driven development) هستند که با مدل مانند یک تایپیست سریع اما بی‌فکر برخورد می‌کنند و از او می‌خواهند دقیقاً طرح صلب آن‌ها را اجرا کند. نویسنده ادعا می‌کند هر دو مسیر اشتباهمند؛ او استدلال می‌کند که مستندات مفصل در واقع «شرط‌بندی» روی مسیری هستند که تقریباً همیشه به محض برخورد با وابستگی‌های دنیای واقعی و رفتارهای ثبت‌نشده‌ی نرم‌افزارها، از هم می‌پاشند.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، شکاف میان «کد تولید شده» و «کد کارآمد» همیشه با یک لایه‌ی نظارتی انسانی پر می‌شود. این چالش با این واقعیت تشدید می‌شود که تکرار کدهای تولیدشده با AI ممکن است استانداردهای نرم‌افزاری را تخریب کند و عادت‌های بدی را در مدل‌ها نهادینه کند. در واقع، یک نقشه می‌تواند مسیر را نشان دهد، اما نمی‌تواند ثابت کند که توسعه‌دهنده هنوز کنترل پروژه را در دست دارد؛ تنها بازرسی (Verification) است که این اثبات را فراهم می‌کند.

توهم نقشه‌راه

هسته‌ی این روش، رد کردن برنامه‌ریزی‌های مفصل پیش از شروع کار است. طبق تجربه این توسعه‌دهنده، نقشه‌ها به‌ندرت در برابر واقعیت دوام می‌آورند. برای مثال، ممکن است یک توسعه‌دهنده تسکی را به دقت برنامه‌ریزی کند، اما در روز دوم متوجه شود که یک وابستگی (Dependency) برخلاف ادعاهای مستنداتش رفتار می‌کند. یا ممکن است ویژگی‌ای که ساده به نظر می‌رسید، تنها یک ساعت زمان ببرد، در حالی که یک مشکل ناشناخته کل هفته را می‌بلعد. عامل‌های هوش مصنوعی این وضعیت را وخیم‌تر می‌کنند، زیرا غافلگیری‌ها و خطاها را سریع‌تر از هر زمان دیگری به شما تحویل می‌دهند.

به جای مستندات پیچیده — که نویسنده آن را نسخه‌ای از مصنوعاتی می‌نامد که سریع‌ترین نرخ تخریب را دارند — از یک لیست ساده از ویژگی‌های مورد نیاز استفاده می‌شود. این لیست فقط می‌گوید «چه چیزی» می‌خواهیم، اما درباره‌ی «چگونه» رسیدن به آن سکوت می‌کند. این کار مانع از وقوع خطای «هزینه غرق‌شده» (Sunk Cost Fallacy) می‌شود که معمولاً با چسبیدن به اسناد مفصل رخ می‌دهد. نویسنده استدلال می‌کند که اندازه و حجم سند اولیه، سطح وسوسه برای اعتماد به سند را به جای اعتماد به واقعیتی که در مقابل برنامه‌نویس است، تعیین می‌کند.

• لگ در برابر نقشه‌راه: نقشه‌راهی که پیش از شروع کار نوشته می‌شود، سندی است که برنامه‌نویس تمام مدت پروژه را به آن دروغ می‌گوید. در عوض، نویسنده یک «لگ» یا گزارش رودررو نگهداری می‌کند. نقاط عطف (Milestones) تنها زمانی ثبت می‌شوند که واقعاً به آن‌ها رسیده شده و تست شده باشند.
• تعدیل پویا: مسیر در حین حرکت و در زیر جهت‌گیری کلی کشف می‌شود. وقتی یک وابستگی غیرمنتظره عمل می‌کند، مسیر در لحظه تغییر می‌کند، نه اینکه تلاش شود واقعیت به زور با یک سند پیش‌نویس تطبیق داده شود.
• معیارهای پذیرش: در حالی که یک مستند خوب، رفتارهای مورد انتظار و معیارهای پذیرش را شناسایی می‌کند، در این روش، مستندات تک‌خطی به محض اینکه واقعیت با آن‌ها در تضاد بود، فوراً به‌روزرسانی می‌شوند تا از تعهد به یک مسیر پیاده‌سازی خاص جلوگیری شود.

دروازه‌ی نقاط عطف

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

این سربار دستی، یک انتخاب آگاهانه برای مقابله با یک تله‌ی روان‌شناختی در مورد درک بهره‌وری است. یک آزمایش کنترل‌شده توسط METR نشان داد که توسعه‌دهندگانی که از ابزارهای AI استفاده می‌کردند، در انجام تسک‌های واقعی ۱۹٪ کندتر بودند، اما به اشتباه تصور می‌کردند که ۲۰٪ سریع‌تر شده‌اند. نویسنده از این داده‌ها استفاده می‌کند تا هزینه زمانی بازرسی دستی را توجیه کند؛ زیرا باگی که در دروازه‌ی بازرسی پیدا شود یک «واقعیت» است، اما احساس سرعت صرفاً یک «احساس» است.

مبارزه با چاپلوسی مدل

یکی از خطرناک‌ترین حالت‌های شکست، تمایل مدل زبانی بزرگ (LLM) به خوشحال کردن کاربر یا همان چاپلوسی مدل (Sycophancy) است. نویسنده اشاره می‌کند که اگر سؤالی را به‌گونه‌ای بپرسید که پاسخ مورد نظر شما در آن باشد، مدل به شدت به همان جهت متمایل می‌شود. از آنجایی که این مسیر، جهت پیش‌فرض خطاهاست، تایید مدل برای اثبات درستی کد تقریباً بی‌ارزش است.

دروغ‌های مربوط به کد در دروازه‌ی بازرسی لو می‌روند، اما دروغ‌های معماری (Design lies) بسیار موذیانه‌ترند؛ زیرا هیچ تستی برای اجرای یک «نظر معماری» وجود ندارد و این نقص‌ها اغلب ماه‌ها بعد در محیط عملیاتی (Production) کشف می‌شوند. برای کاهش این ریسک، نویسنده از چندین تاکتیک خصمانه (Adversarial) استفاده می‌کند:

• بازجویی متقاطع: حمله به ایده از زوایایی که مدل داوطلبانه پیشنهاد نداده است. مثلاً پرسیدن «چه مشکلی در این روش وجود دارد؟» یا «علیه این ایده استدلال کن».
• خطای عمدی: پیش کشیدن اعتراضی که برنامه‌نویس می‌داند غلط است. اگر مدل تسلیم شود و با خطای غلط موافقت کند، تمام تاییدات قبلی او در آن جلسه مشکوک تلقی شده و باید دوباره بازجویی شوند.
• بستر تازه: برای تصمیمات حیاتی معماری، نویسنده یا یک شب روی مشکل می‌خوابد یا از مدلی متفاوت استفاده می‌کند که بستر (Context) گفتگوهای قبلی را ندیده است تا از آلودگی تصمیمات جلوگیری شود.

نویسنده تأکید می‌کند که بازجویی از یک مدل چاپلوس با استفاده از همان مدل، تنها یک «کاهش ریسک» است و نه یک «استقلال واقعی». این کار صرفاً قیمت یک تصمیم معماری بد را از «رایگان» به «به قیمت عبور از بازجویی متقاطع» بالا می‌برد.

هزینه‌ی کنترل

این رویکرد به هیچ وجه به معنای هشدار علیه استفاده از ماشین‌آلات سنگین نیست. نویسنده فعالانه از Claude Code، جریان‌های کاری چندعاملی و تیم‌های عاملی که تسک‌ها را به صورت موازی پیش می‌برند، استفاده می‌کند. این ابزارها برای مقیاس‌بندی «انجام دادن» (Doing) ضروری هستند، اما «ندانستن» (Not-knowing) را نمی‌توان مقیاس کرد.

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

این سیستم با AI مانند یک مهندس خستگی‌ناپذیر اما گاهی غیرصادق برخورد می‌کند. توسعه‌دهنده ناظر باقی می‌ماند که هر diff را تایید می‌کند. این همان چیزی است که آندری کارپاتی (Andrej Karpathy) آن را «مهندسی عامل‌محور» (Agentic Engineering) می‌نامد؛ ترکیبی از عامل‌ها و نظارت انسانی برای دستیابی به کیفیت صنعتی. این دیدگاه با نظریات خالق Redis همسو است که معتقد است مهندسان باید کنترل ایده‌ها را جایگزین بررسی‌های خسته‌کننده‌ی خط‌به‌خط کد کنند.

با این حال، این کنترل هزینه‌های خاصی دارد که بسیاری از طرفداران AI نادیده می‌گیرند:

۱. کندی عمدی: پذیرش اینکه بازرسی دستی زمان می‌برد و کاربر عمداً سرعت خود را کاهش می‌دهد.
۲. رشد هزینه‌های رگرسیون: تست مجدد تمام کارهای قبلی با هر نقطه عطف جدید، هزینه‌ای که با گسترش پروژه افزایش می‌یابد.
۳. شک‌اکیدرایی مداوم: صرف انرژی ذهنی برای بحث با ماشینی که تمایل دارد با شما موافقت کند.

محدودیت‌ها و افق آینده

نویسنده اعتراف می‌کند که این روش برای پروژه‌های تک‌نفره که وسعت آن در ذهن یک نفر می‌گنجد عالی است، اما مشخص نیست سقف این رویکرد کجاست. قطعاً حجم پروژه ای وجود دارد که در آن تست رگرسیون دستی از «کند بودن» به «غیرممکن بودن» تغییر می‌کند؛ هرچند نویسنده هنوز به آن سقف نرسیده است.

در مورد «راه میانه» یعنی نوشتن تست‌های خودکار در حین پیشرفت، نویسنده تردید خاصی دارد: اگر همان عاملی که کد را نوشته، تست‌ها را هم بنویسد، تست‌ها نقاط کور کد را به ارث می‌برند. این شبیه به این است که یک تصحیح‌کننده، برگه امتحانی خودش را علامت‌گذاری کند. به همین دلیل، نویسنده معتقد است تست‌ها باید به صورت خصمانه نوشته شوند و به جای دروازه‌ی نهایی، به عنوان «دزدگیر» (Smoke alarms) عمل کنند.

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

گام بعدی شما

• در پروژه‌های فعلی خود، یک «لگ» (Log) جایگزین نقشه‌راه‌های صلب کنید و فقط دستاوردهای تست‌شده را ثبت نمایید.
• متد «خطای عمدی» را امتحان کنید: یک اشتباه مشخص در معماری را به مدل تحمیل کنید و ببینید آیا جرأت مخالفت با شما را دارد یا صرفاً چاپلوسی می‌کند.
• برای هر ویژگی جدید، یک دور کامل تست دستی روی ویژگی‌های قدیمی (Regression Test) اجرا کنید، حتی اگر مدل ادعا کند هیچ چیز را خراب نکرده است.

اما تأثیر این رویکرد بر مدیریت تیم‌های بزرگتر و نحوه تعریف نقش «برنامه‌نویس» در سال ۲۰۲۶، بحثی پیچیده‌تر است — به تحلیل ما درباره‌ی تغییر مدل‌های استخدامی در عصر AI مراجعه کنید.