۵ باور غلط دربارهٔ عامل‌های هوش مصنوعی که بدهی فنی ایجاد می‌کنند

تصور کنید همین امشب تمام تب‌های چت شما پاک شود؛ آیا تاریخچهٔ گیت (git) شما هنوز می‌تواند هر تغییر فنی را توضیح دهد؟ در حالی که توسعه‌دهندگان به‌طور فزاینده‌ای از ترنسکریپت‌های چت به عنوان حافظهٔ پروژه استفاده می‌کنند، باید به یاد داشت که یک پاسخ روان از سوی هوش مصنوعی، یک رکورد امضا شده و رسمی نیست. این شکاف خطرناک بین «حس خوب» (vibes) و تصمیمات مهندسی قابل‌راستی، محوریت یک راهنمای فنی است که در ۶ سپتامبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد. اگر مستندات شما به جای کنترل نسخه، بر تاییدات یک عامل متکی است، شما تصمیم فنی نگرفته‌اید، بلکه فقط یک متن مودبانه دارید.

این تغییر رویکرد در زمانی می‌رسد که تیم‌ها عامل‌های خودمختار (autonomous agents) را عمیق‌تر در خط لوله‌های CI/CD خود ادغام می‌کنند. ابزارهایی مثل MonkeyCode برای پیش‌نویس‌های اولیه و محیط‌های آزمایشی (scratch pads) مفیدند و دسترسی رایگان به مدل‌ها و سرورهای رایگان را فراهم می‌کنند که برای تمرینات موقت عالی است، اما این ابزارها یک صف ادغام (merge queue)، آرشیو RFC یا ردیاب تیکت نیستند. صنعت اکنون در جداسازی گفتگوهای زنده از آرشیوهای دائمی پروژه دچار مشکل است. همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی مدل بدون لایهٔ اعتبارسنجی، نقطه‌ضعف سیستم است. خطر اصلی در «تلهٔ تاریخچه» است: این باور که تایید مودبانهٔ یک مدل، معادل یک بازبینی حرفه‌ای است.

سوابق در برابر ماشین‌ها

این بحث دربارهٔ سرعت پاسخ‌دهی (latency)، توضیح صورت‌حساب‌ها یا مقایسه «سرور رایگان در برابر لپ‌تاپ» نیست. این بحث دربارهٔ سوابق (records) است. هدف این است که محیط‌های چت و باکس‌های ریموت فقط به عنوان یک تخته‌سیاه موقت دیده شوند و تنها بیت‌های تاییدشده به گیت منتقل شوند. اگر چت از بین برود، مخزن کد (repo) باید همچنان بتواند داستان تغییرات را تعریف کند و با شما صحبت کند.

۵ باور غلط در توسعهٔ عامل‌محور

باور اول: تسلط زبانی به معنای اعتبار است.
برنامه‌نویسان اغلب تصور می‌کنند چون مدل یک الگوی پیچیده (مانند Event Sourcing) را با تسلط و روانی پیشنهاد می‌دهد، پس تصمیم نهایی گرفته شده است. جملاتی مثل «مدل از Event Sourcing خوشش آمد، پس ما هم همین راه را می‌رویم» در جلسات استندآپ رایج اما خطرناک هستند. در واقعیت، یک پاراگراف در چت، نه مالکی دارد، نه فیلد وضعیت (status) و نه برنامهٔ بازگشت (rollback). تسلط زبانی، اعتبار فنی نیست.

برای اصلاح این مورد، راهنما پیشنهاد می‌کند چت فقط پیش‌نویس بزند و انسان‌ها ثبت کنند. اگر شما بخش‌های ذخیره‌سازی (storage)، احراز هویت (auth) یا APIهای عمومی را تغییر می‌دهید، باید یک سند تصمیم معماری (ADR) بنویسید. یک فایل markdown کوتاه، بسیار ارزشمندتر از یک رشته‌چت است که هر لحظه ممکن است پاک شود. یک قالب پیشنهادی برای ADR باید شامل موارد زیر باشد:

• برچسب (Label): یک تمپلیت باشد، نه یک بازبینی تکمیل شده.
• سربرگ (Header): شامل کد ADR-XXXX، عنوان، وضعیت (مثلاً proposed)، تاریخ (YYYY-MM-DD) و تصمیم‌گیرندگان (نام افراد، نه «عامل هوش مصنوعی»).
• زمینه (Context): چه محدودیتی باعث شد این انتخاب صورت گیرد؟
• تصمیم (Decision): دقیقاً چه تغییری در مخزن کد اعمال خواهد شد.
• پیامدها (Consequences): بعد از اعمال این تصمیم، چه بخش‌هایی سخت‌تر یا پیچیده‌تر می‌شوند.
• گزینه‌های رد شده (Rejected options): ایده‌های دیگر مدل و دلیل رد شدن آن‌ها.

بدون یک فایل ADR، شما فقط یک «حس خوب» با نقطه‌گذاری‌های درست دارید. شما نمی‌توانید کسی را بر اساس یک «حس» در وضعیت اضطراری بیدار کنید.

باور دوم: پیشنهادهای Import، فایل‌های قفل هستند.
وقتی یک عامل می‌گوید «فقط این پکیج را اضافه کن»، این یک شایعه است، نه یک قرارداد. راهنما نسبت به حملات typosquatting و نسخه‌های پین‌نشده (unpinned) هشدار می‌دهد. این فایل‌ها تا زمانی که آن‌ها را diff نکنید، برای شما غریبه هستند. مخزن کد می‌تواند بدون چاپلوسی به شما پاسخ دهد، در حالی که مدل ممکن است برای خوشامد شما، ریسک‌ها را نادیده بگیرد.

برای تایید Importها، راهنما پیشنهاد می‌کند پیشنهادات را در یک لیست موقت ریخته و یک بررسی grep اجرا کنید. برای پروژه‌های Node-style، اسکریپتی می‌تواند فایل /tmp/suggested.txt را بخواند و با package-lock.json مقایسه کند تا پکیج‌های UNPINNED را بیابد. برای پایتون، بررسی مشابهی با استفاده از pathlib بین پیشنهادات و فایل requirements.txt منجمد شده (frozen) انجام می‌شود. اگر اسکریپت عبارت UNPINNED را چاپ کرد، یعنی چت شما زنجیره تامین (supply chain) شما نیست. متوقف شوید، نسخه را پین کنید و سپس Pull Request را باز کنید.

باور سوم: تایید LGTM در چت، معادل بازبینی است.
اینکه همان مدلی که کد را نوشته، diff آن را بازبینی کند، صرفاً نگاه کردن در آینه است، نه استفاده از یک مغز دوم. بازبینی واقعی نیاز به یک مغز دوم و یک Checkout دوم دارد. جلسات ریموت می‌توانند بدون خجالت از Local Hooks و فایل‌های CODEOWNERS عبور کنند. این تضاد بین تاییدات ماشینی و نیاز به بازبینی انسانی، یادآور شکاف عمیقی است که بین بنچمارک‌های مدل‌ها و ارزیابی‌های واقعی انسانی در محیط‌های عملیاتی وجود دارد و نشان می‌دهد چرا مدل‌ها نمی‌توانند جایگزین بازبین انسانی شوند.

مدل اصلاح شده: عامل‌ها پیش‌نویس می‌زنند، انسان‌ها تایید می‌کنند. به جای کپی کردن یک تعریف یا تعریف مثبت از مدل، SHA کامیت را در تیکت قرار دهید. یک چک‌لیست PR پیشنهادی باید شامل موارد زیر باشد:

• نام بازبین انسانی ذکر شده است.
• تاییدیه CODEOWNERS اخذ شده است.
• ترنسکریپت چت به صورت لینک است، نه به عنوان تاییدیه.
• لینک URL مربوط به CI قرار دارد، نه اسکرین‌شات از یک پرامپت.

آیا شما کدی را فقط چون در Slack گفته شد «lgtm» بدون دیدن diff ادغام می‌کنید؟ پس اجازه ندهید مدل هم همین کار را بکند.

باور چهارم: متن «تست‌ها پاس شدند» همان CI است.
متن سبز در پنجرهٔ چت یک ادعاست، نه یک مدرک. یک عامل که دستوری را روی یک سرور رایگان اجرا می‌کند، جزئیات ایمیج، فلگ‌های استفاده شده یا وجود فایل‌های باقی‌مانده از جلسه قبلی را به شما نمی‌گوید. یک CI معتبر ادعایی است که دارای URL، لاگ‌ها و یک SHA مشخص است.

برای جلوگیری از اینکه «سبز بودن چت» به سیگنال ادغام تبدیل شود، راهنما یک اسکریپت رد محلی (local refusal script) پیشنهاد می‌کند. این اسکریپت bash با استفاده از set -euo pipefail متغیر محیطی CI_JOB_URL را چک می‌کند. اگر این متغیر موجود نباشد، اسکریپت با خطا خارج شده و اعلام می‌کند که تنها یک URL پایپ‌لاین به همراه SHA فعلی می‌تواند تیکت را ببندد. اسکرین‌شات‌های پرامپت، هیچ‌کس را در ساعت ۳ صبح بیدار نمی‌کنند.

باور پنجم: جلسات عامل، حافظهٔ تیم هستند.
این ادعا که «ما دیشب در چت با عامل درباره این موضوع تصمیم گرفتیم»، یک مغالطه است. یک جلسه تا زمانی که منتشر نشود، خصوصی می‌ماند. اگر مهندس on-call در آن جلسه نبوده است، آن حافظه برای او وجود ندارد. حافظهٔ تیم باید در Issueها، ADRها و فایل‌های README زندگی کند. اگر نمی‌توانید چیزی را جست‌وجو کنید، پس آن اتفاق نیفتاده است.

از یک قانون ساده استفاده کنید: اگر نمی‌توانید آن را grep کنید، به آن اعتماد نکنید. راهنما پیشنهاد می‌کند برای یافتن تصمیمات ثبت شده از دستور git grep -n "ADR-" -- '*.md' یا جست‌وجوی عبارت "Deciders:" در پوشه مستندات استفاده کنید. اگر نتیجه‌ای یافت نشد، شما در حال بحث با یک روح هستید و روح‌ها مسئولیت on-call را نمی‌پذیرند.

پیاده‌سازی دروازهٔ سوابق (Record Gate)

نویسنده برای مبارزه با این باورها، اسکریپتی به نام record_gate.sh پیشنهاد می‌کند. این ابزار مانند یک ترمز سخت در شاخه‌های ویژگی (feature branches) عمل می‌کند و اگر سوابق مشخصی موجود نباشد، اجازه پیشروی نمی‌دهد (fail closed). این یک پیشنهاد برای اجرا روی شاخه ویژگی است، نه یک پلاگین تجاری.

جزئیات عملکرد دروازه

این اسکریپت چندین بررسی سخت‌گیرانه را به کار می‌گیرد:

• بررسی طراحی (Design Check): اگر git diff تغییراتی در schema، migrations یا infra نشان دهد، در صورتی که هیچ فایلی در docs/adr/*.md وجود نداشته باشد، اسکریپت خطا می‌دهد.
• بررسی وابستگی‌ها (Dependency Check): فایل /tmp/suggested.txt را می‌خواند و اگر هر پکیجی در package-lock.json گم شده باشد، متوقف می‌شود.
• بررسی انسانی (Human Check): اگر متغیر محیطی HUMAN_REVIEWER خالی باشد، خطا می‌دهد.
• بررسی CI: اگر CI_JOB_URL خالی باشد، صراحتاً اعلام می‌کند که «سبز بودن چت حساب نمی‌شود».

برای اجرای آن، ابتدا chmod +x record_gate.sh را بزنید، نام کاربری خود را به HUMAN_REVIEWER اکسپورت کنید و اسکریپت را اجرا کنید. اولین اجرا باید با شکست مواجه شود؛ زیرا شکست، درس اصلی است. زمانی که سوابق تکمیل شدند، اسکریپت باید با کد خروج صفر پایان یابد.

تمرین ۲۰ دقیقه‌ای

برای تیم‌هایی که می‌خواهند یک تجربه کم‌ریسک داشته باشند، راهنما یک تمرین ۲۰ دقیقه‌ای پیشنهاد می‌کند. این زمان برای حس کردن فقدان سوابق کافی است اما آنقدر کوتاه است که واقعاً قابل اجرا باشد. فرآیند به این صورت است:
۱. باز کردن یک دایرکتوری موقت و یک‌بار مصرف (بدون کانفیگ‌های تولید یا اسرار).
۲. درخواست یک تغییر طراحی از مدل و ذخیره پاسخ خام.
۳. ثبت یک پیش‌نویس ADR بر اساس تمپلیت.
۴. قرار دادن پکیج‌های پیشنهادی در /tmp/suggested.txt و اجرای grep روی lockfile.
۵. پین کردن یا رد کردن پکیج‌ها.
۶. اجرای یک دستور تست واقعی روی یک Checkout پاک.
۷. کپی کردن SHA و URL مربوط به CI در تیکت.
۸. اجرای record_gate.sh تا زمانی که خروجی صفر شود.

هزینهٔ مهندسی بر پایه «حس»

این رویکرد مدل ذهنی را از «عامل تایید کرد» به «سند کجاست؟» تغییر می‌دهد. برای اینکه این موضوع در یک PR محقق شود، نویسنده پیشنهاد می‌کند یک جدول پنج ردیفی جایگزین ادعاها شود:

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

محدودیت‌ها و دامنه

این گردش‌کار برای PRهای بسیار کوچک (مثل اصلاح غلط املایی) آزاردهنده است؛ نویسنده پیشنهاد می‌کند ADR را برای تغییرات صرفاً متنی حذف کنید. با این حال، هرگز نباید بررسی lockfile برای پکیج‌های جدید یا قرار دادن اسرار (secrets) در سرورهای رایگان مشترک را نادیده بگیرید. سرور مشترک یک گاوصندوق، محیط Staging یا آینه پکیج نیست.

این روش برای موارد زیر نیست:

• تیم‌هایی که تحت نظارت بردهای تغییر (change boards) هستند که استفاده از ریموت‌های موقت را ممنوع کرده‌اند.
• هر کسی که اعتبارنامه‌های محیط Production را در پرامپت کپی می‌کند.
• نگهدارندگانی که در حال حاضر مسیر RFC فعال دارند و صرفاً آن را نادیده می‌گیرند.
• کسانی که امیدوارند یک مدل رایگان جایگزین بازبین‌های انسانی شود.

اگر به یک ردپای حسابرسی (audit trail) امضا شده نیاز دارید، این FAQ کفِ استاندارد است، نه سقف آن. سطح ریسک خود را بالا ببرید.

مدل ذهنی قابل اقتباس

بعد از هر جلسه با عامل، چهار سوال بپرسید: ADR کجاست؟ پین کجاست؟ بازبین انسانی کیست؟ لینک CI کجاست؟ اگر نمی‌توانید پاسخ دهید، کار شما تمام نشده است. شما هنوز در حال چت کردن هستید. چت کردن مجاز است، اما بستن تیکت بدون این‌ها نیست. مدل رایگان می‌تواند پاراگراف را بنویسد و سرور رایگان می‌تواند پیش‌نویس را میزبانی کند، اما مخزن کد شما باید پس از مرگ چت، زنده بماند. آیا شما شبِ on-call خود را روی یک ترنسکریپت شرط‌بندی می‌کنید؟ جدول را بردارید، اسکریپت را اجرا کنید، ADR را ثبت کنید و سپس ادغام (merge) کنید.

گام بعدی شما

• اسکریپت record_gate.sh را در یک پروژه کوچک پیاده کنید تا نقاط کور مستنداتتان را بیابید.
• برای هر تصمیم فنی مهم، یک فایل ADR ساده در پوشه docs ایجاد کنید.
• عادت کنید به جای اسکرین‌شات از چت، لینک‌های CI و SHAهای کامیت را در تیکت‌ها ثبت کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.