تصور کنید یک عامل هوش مصنوعی با اطمینان کامل گزارش دهد که «تمام تست‌ها پاس شدند»، اما وقتی فایل را باز می‌کنید، حتی یک خط کد هم تغییر نکرده است. این شکاف میان روایت عامل و واقعیت دیسک، بزرگ‌ترین نقطه ضعف فعلی در سپردن کدنویسی به هوش مصنوعی است. یک مهندس QA که به‌صورت روزانه از Devin استفاده می‌کند، با همین فلسفه — «دست از اعتماد به ادعای عامل مبنی بر پاس شدن تست‌ها بردارید و شروع به تأیید وضعیت واقعی دیسک کنید» — یک استک جامع اعتبارسنجی محلی (Local-first) را منتشر کرده است که برای حل این «شکاف خوش‌بینی» در عامل‌های کدنویس AI طراحی شده است.
بسیاری از برنامه‌نویسان اکنون برای تأیید اتمام تسک‌ها به روایت خودِ عامل تکیه می‌کنند. این رویکرد یک نقطه کور خطرناک ایجاد می‌کند؛ جایی که عامل گزارش می‌دهد همه چیز «سبز» است، در حالی که فایل روی دیسک دست‌نخورده باقی مانده است. این مسئله در واقع ریشه در شکاف میان صحتِ پیاده‌سازی و صحتِ سیستمی در عامل‌های کدنویس دارد که باعث می‌شود خروجی‌های مدل با واقعیت محیط اجرا همخوانی نداشته باشد. طبق گزارش توسعه‌دهنده این پروژه، این اتفاق به این دلیل رخ می‌دهد که عامل‌ها وضعیت را بر اساس روایت داخلی خود گزارش می‌کنند، نه بر اساس شواهد عینی (Ground Truth). در این سناریو، ادعای عامل و وضعیت سیستم دو موجودیت متفاوت هستند و تنها یکی از آن‌ها — یعنی وضعیت دیسک — شواهد واقعی است.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی توهمات مدل‌های زبانی اشاره کردیم، تکیه بر خروجی متنی بدون لایه‌ی اعتبارسنجی، ریسک خطاهای پنهان را افزایش می‌دهد. در این سناریو، ادعای عامل و وضعیت سیستم دو موجودیت متفاوت هستند و تنها یکی از آن‌ها — یعنی وضعیت دیسک — شواهد واقعی است.
به نقل از مستندات این پروژه، راهکار در تله‌متری (Telemetry) — شبیه به جعبه سیاه هواپیما که تمام اتفاقات فنی را ثبت می‌کند — نهفته است که رابط‌های خط فرمان (CLI) عامل‌ها به‌صورت محلی می‌نویسند. شواهد در تمام مدت در قالب فایل‌های نشست (Session)، وضعیت فراخوانی ابزارها (Tool-call state) و میزان مصرف توکن روی دیسک موجود است. توسعه‌دهنده با خواندن این لاگ‌ها به‌جای داستان‌های عامل، خط لوله‌ای ساخته است که فرآیند را از «درک کردن» به «قضاوت کردن» منتقل می‌کند. این رویکرد شباهت زیادی به گردش‌کار متن‌باز محمد صالح برای حذف تاییدات صوری کد دارد که بر لایه‌های متعدد ممیزی برای جلوگیری از خطاهای توهمی تأکید می‌کند.
این خط لوله اعتبارسنجی از توالی زیر تشکیل شده است: درک $\rightrightarrows$ تأیید $\rightrightarrows$ اندازه‌گیری $\rightrightarrows$ کنترل $\rightrightarrows$ قضاوت.
- devin-internals-spec: لایه‌ی درک؛ این لایه قراردادها، فرمت فایل‌ها، کدهای خروج (Exit codes) و قوانین رفتاری محیط اجرا را تعریف می‌کند. هر چیزی که در مراحل بعدی خط لوله قرار دارد، بر اساس این مشخصات (Spec) خوانده و تفسیر می‌شود.
- devin-qa-pack: لایه‌ی تأیید؛ این ابزار نقطه شروع پروژه بود. این ابزار ممیزی QA را روی کار واقعی اجرا می‌کند و بررسی می‌کند که آیا تغییرات فایل (Diff) واقعاً وجود دارند، تست‌ها واقعاً اجرا شده‌اند، کامیت‌ها ثبت شده‌اند، پوش‌ها (Push) به سرور رسیده‌اند و دستورات اعتبارسنجی اجرا شده‌اند یا خیر. این سیستم با ۴۷ تست در محیط‌های CI روی اوبونتو و ویندوز، ادعاها را با
tool_call_stateمی‌سنجد، نه با روایت متنی عامل. این رویکرد برای مقابله با توهم پوشش کد بالا در تست‌های AI ضروری است، چرا که تست‌های تولید شده توسط AI لزوماً باگ‌های واقعی را شناسایی نمی‌کنند. - devin-evals: لایه‌ی اندازه‌گیری؛ این ابزار می‌پرسد که عامل در تسک‌های خاص چقدر خوب عمل می‌کند. این کار با استفاده از تسک‌های طلایی (Golden Tasks)، امتیازدهی بر اساس روباریک (Rubric scoring) و ردیابی رگرسیون در طول نشست‌های مختلف انجام می‌شود.
- devin-bridge: لایه‌ی کنترل؛ یک دروازه‌ی سیاست‌گذاری مبتنی بر ACP بین قصد (Intent) و اجرا. این ابزار دارای یک حالت
--devin-onlyاست که تحمیل می‌کند یک نشست دقیقاً همان کاری را انجام دهد که در محدوده (Scope) آن تعریف شده است. - poordjaevin: لایه‌ی قضاوت؛ این ابزار توصیف یک تسک را می‌گیرد و یک امتیاز اطمینان کالیبره شده تولید می‌کند تا مشخص شود آیا می‌توان به تفویض اختیار به عامل اعتماد کرد یا خیر. این ابزار یک سرور واقعی پروتکل زمینهٔ مدل (MCP) است (
poordjaevin serve) که عامل‌ها می‌توانند در حین اجرای عملیات با آن مشورت کنند.
یکی از دستاوردهای فنی کلیدی، کالیبراسیون (Calibration) — یعنی تنظیم دقیق مدل برای اینکه میزان اطمینانش با واقعیت همخوانی داشته باشد — در بخش قضاوت است. خطای کالیبراسیون مورد انتظار (ECE) از ۰.۱۷۰ به ۰.۰۷۱ کاهش یافت. ECE تضمین می‌کند که وقتی داور می‌گوید «۸۰٪ مطمئنم»، در واقع در تقریباً ۸۰٪ موارد درست می‌گوید. این پیشرفت از طریق برچسب‌گذاری نتایج واقعی (Labeled outcomes) به‌دست آمده، نه با تغییرات ساده در پرامپت‌ها.
علاوه بر خط لوله اصلی، این مجموعه شامل ۲۰ ابزار محلی است که روی لپ‌تاپ‌های با رم محدود اجرا می‌شوند و هیچ داده‌ای (Telemetry) از دستگاه خارج نمی‌کنند. از جمله این ابزارها می‌توان به موارد زیر اشاره کرد:
- devin-history: باستان‌شناسی قابل جست‌وجو در تمام نشست‌های گذشته با استفاده از SQLite (بیش از ۷ دستور).
- devin-metrics: تجمیع تله‌متری برای استخراج سیگنال‌های کیفی در طول زمان.
- devin-memory، devin-search و devin-graph: یک ذخیره‌ساز حافظه، سیستم بازیابی و گراف دانش روی نشست‌ها، پروژه‌ها و تصمیمات گرفته شده.
- devin-doctor: عیب‌یابی محیط (Diagnostics) در هر دو سیستم‌عامل ویندوز و لینوکس.
- devin-backup: قابلیت‌های اسنپ‌شات، تأیید و بازیابی برای وضعیت عامل.
- devin-janitor و devin-redact: ابزارهایی برای پاک‌سازی و حذف اطلاعات حساس (Secret-redaction) جهت انتقال امن وضعیت.
- devin-office: یک داشبورد بصری و فقط-خواندنی شبیه به مدار الکترونیکی که نشست‌های واقعی، زیر-عامل‌ها (Subagents) و فراخوانی ابزارها را از ذخیره‌ساز محلی رندر می‌کند.
این چرخش از «اعتماد» به «تأیید»، فرض بنیادی تفویض اختیار به هوش مصنوعی را تغییر می‌دهد. با تبدیل تله‌متری عامل به یک منبع داده برای QA، توسعه‌دهنده ثابت می‌کند که اعتبارسنجی تنها راه برای ایمن کردن کدنویسی خودمختار در مقیاس بزرگ است.
برای برنامه‌نویسان حرفه‌ای، حالت «فقط Devin» — جایی که ابزارها به‌صورت مستقل و بدون نیاز به ادغام‌های خارجی مانند Slack، Obsidian یا MCP کار می‌کنند — ارزشمندترین ویژگی است؛ زیرا اجازه می‌دهد این استک در محیط‌های بسته و سخت‌گیرانه شرکتی (Locked-down corporate boxes) که اکثر کارهای مهندسی واقعی در آنجا رخ می‌دهد، زنده بماند.
اگر در حال حاضر از عامل‌هایی مثل Claude Code، Cursor یا Copilot استفاده می‌کنید، باید بررسی کنید که آیا برای تأیید ادعاهای آن‌ها به بررسی‌های دستی (Spot-checks) تکیه می‌کنید یا از دروازه‌های خودکار CI استفاده می‌کنید. تمام ابزارهای این استک تحت لایسنس MIT منتشر شده و مستندات آن‌ها به زبان‌های انگلیسی و پرتغالی-برزیلی موجود است.
گام بعدی شما
- بررسی کنید که آیا عامل کدنویس شما لاگ‌های
tool_call_stateرا به‌صورت محلی ذخیره می‌کند یا خیر. - برای پروژه‌های حساس، یک لایه‌ی اعتبارسنجی مستقل (مانند بررسی Diff فایل‌ها) را جایگزین تایید متنی عامل کنید.
- مستندات این پروژه را که تحت لایسنس MIT منتشر شده، برای پیاده‌سازی ممیزی‌های محلی مطالعه کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو