تصور کنید می‌خواهید به یک کارمند جدید وظیفه‌ای بسپارید، اما نه تیکتی در کار است، نه سند طراحی و نه مجموعه‌ای از تست‌ها. شما شاید با چند جلسه و تکیه بر شهود مشترک از پس این کار بربیایید، اما یک عامل (Agent) — شبیه دستیاری که دقیقاً طبق دستورالعمل پیش می‌رود و هیچ حدس و گمانی نمی‌زند — در این شرایط به‌سادگی شکست می‌خورد. میانبرهایی که انسان‌ها در طول توسعه پروژه می‌زنند، تجملاتی هستند که عامل‌های هوش مصنوعی نمی‌توانند تحمل کنند.
به نقل از یادداشتی که متیو برونل (Matthew Brunelle) در ۱۲ اوت ۲۰۲۶ منتشر کرد، هیجان فعلی پیرامون «مهندسی عامل‌محور» در واقع بازکشف انضباط‌های ساده‌ای است که مهندسان نرم‌افزار معمولاً تحت فشار زمانی حذف می‌کنند. برونل استدلال می‌کند که این روند ثابت می‌کند استانداردهای نرم‌افزاری — همان‌هایی که معمولاً قربانی عجله می‌شوند — برای عملکرد درست هوش مصنوعی اجباری هستند. او این روند را با نحوه بازکشف مفاهیم مالی مدرن توسط دنیای کریپتو از طریق اصول اولیه مقایسه می‌کند؛ یعنی رویکردهای «جدید» در مهندسی عامل‌محور، صرفاً همان شیوه‌هایی هستند که مهندسان نرم‌افزار از پیش باید در سیستم خود پیاده می‌کردند. این تغییر رویکرد در واقع بخشی از یک تحول گسترده‌تر است که در آن ماهیت توسعه نرم‌افزار از کدنویسی صرف به تفویض اختیار به عامل‌های AI تغییر می‌کند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، نبودِ ساختار در سیستم‌های پیچیده همیشه یک ریسک بوده است، اما حالا این ریسک به یک مانع سخت تبدیل شده است. این شکاف به دلیل فقدان چیزی است که جیمز سی. اسکات در کتاب دیدن مانند یک دولت (Seeing Like a State) آن را «متیس» (Mētis) می‌نامد.
متیس نوعی دانش تجربی است که فقط از طریق تکرار طولانی‌مدت کارهای مشابه اما نه کاملاً یکسان به دست می‌آید. این دانش نیازمند انطباق مداوم با شرایط متغیر است. در واقع، دانستن اینکه چگونه و چه زمانی باید «قواعد سرانگشتی» را در یک موقعیت عینی به کار برد، جوهر متیس است. در حالی که نحوِ کدنویسی یک ساختار انسانی تعریف‌شده و توصیف‌شده است، سایر اصول مهندسی به‌صورت آزاد و غیررسمی هستند و تبدیل آن‌ها به فرمتی که برای ماشین قابل خواندن (Legible) باشد، دشوارتر است.
طبق گزارش منتشر شده در blog.matthewbrunelle.com، پیش‌نیازهای موفقیت در مهندسی عامل‌محور دقیقاً با استانداردهای مهندسی دستی باکیفیت یکسان هستند:
- ردیاب‌های مسئله (Issue Trackers): استفاده از تیکت‌ها برای سازماندهی نیازمندی‌ها تا عامل‌ها بتوانند با پرسیدن سوالات در کامنت‌ها، نیازمندی‌ها را شفاف کنند و وضعیت کار در حین پیشرفت به‌روز کنند.
- مستندات: نوشتن رشته‌های مستنداتی (Docstrings) برای متدها و به‌روز نگه داشتن راهنماها. این کار تضمین می‌کند که عامل‌ها به اصول راهنمای پروژه پایبند بمانند.
- کیفیت کد: اجرای ابزارهای بررسی خودکار (Linting) برای حفظ یکپارچگی، نوشتن درخواست‌های ادغام (Pull Requests) توصیفی و طراحی تست‌های معنادار.
- برنامه‌ریزی: معماری دقیق سیستم و دریافت بازخورد روی طراحی‌ها پیش از آنکه پیاده‌سازی کد آغاز شود.
- ارتباطات: ثبت دقیق یادداشت‌های جلسات برای تأیید توافقات و انتقال گفتگوها از پیام‌های خصوصی (DM) به کانال‌های باز و قابل جست‌وجو.
برونل به تغییر خاصی در رفتار مهندسان اشاره می‌کند: حالا آن‌ها مستندات را نه برای همکاران انسانی، بلکه برای اینکه عامل‌های دیگر مهندسان را مجبور به رعایت اصول خاص کنند، به‌روز می‌کنند. یکی از همکاران او اشاره کرد که در گذشته، به‌روزرسانی مستندات اثر کمی داشت چون برای اطمینان از اینکه همه تغییرات را حفظ کرده‌اند، نیاز به برگزاری جلسات تیمی بود. اما اکنون با ساختار درست مستندات، تمام عامل‌ها قوانین را می‌خوانند و دقیقاً از آن‌ها پیروی می‌کنند.
با این حال، نویسنده هشدار می‌دهد که افزودن هوش مصنوعی به یک سیستم معیوب، فقط سرعت شکست را بیشتر می‌کند. او موردی را ذکر می‌کند که یک توسعه‌دهنده مجبور شد خروجی‌های گسترده یک عامل را دور بریزد، چون تیم در میانه یک اسپرینت، یکی از وابستگی‌های (Dependency) کد را بدون اطلاع دیگران تغییر داده بود. عامل فاقد آن شهود انسانی یا متیس برای تشخیص این تغییر نانوشته بود و در نتیجه کدی تولید کرد که کاملاً بی‌فایده بود. این چالش‌ها نشان می‌دهد که حتی با وجود ساختار، عامل‌های هوش مصنوعی همچنان در مواجهه با پیچیدگی‌های دنیای واقعی مانند احراز هویت کاربران با شکست مواجه می‌شوند.
این یعنی هر اصطکاکی که مهندسی انسانی را سخت می‌کند، مهندسی عامل‌محور را به‌صورت نمایی دشوارتر می‌سازد. عامل‌ها متیس لازم برای پیمایش در این موقعیت‌های مبهم را ندارند. اگر تیمی با ابزارهای هوش مصنوعی دست‌وپنج نرم می‌کند، مشکل احتمالاً از خودِ AI نیست، بلکه از فرهنگ مهندسی ناکارآمد در زیربنای آن است.
برونل به قاعده‌ای شناخته‌شده از سال ۱۹۷۵ اشاره می‌کند: افزودن نیروی انسانی به پروژه‌هایی که از زمان‌بندی عقب هستند، آن‌ها را باز هم عقب‌تر می‌کند. افزودن یک «شخص مصنوعی» از طریق هوش مصنوعی هم نتیجه‌ای متفاوت ندارد و صرفاً همان اشتباهات را تکرار می‌کند. برای بهبود نتایج، تیم‌ها باید به‌جای جست‌وجوی «ترفندهای AI»، بدهی‌های فنی (Technical Debt) خود را تسویه کنند. مسیر رسیدن به عامل‌های بهتر، صرفاً مهندسی بهتر است.
گام بعدی شما
- بررسی مجدد مستندات پروژه و تبدیل یادداشت‌های پراکنده به ساختارهای قابل خواندن برای ماشین.
- سخت‌گیرانه کردن فرآیند تست‌های خودکار پیش از سپردن وظایف به عامل‌های هوشمند.
- انتقال گفتگوهای تصمیم‌ساز از دایرکت‌ها به محیط‌های مستند و قابل جست‌وجو.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو