تصور کنید برنامه‌نویسی هستید که باید یک ویژگی ساده را به سیستمی اضافه کند که چهار سال است توسط ده نفر مختلف نوشته شده و هیچ مستنداتی ندارد. در این محیط، حتی پیشرفته‌ترین مدل‌های هوش مصنوعی هم به جای حل مشکل، با حدس زدن معنای متغیرها، بدهی فنی (Technical Debt) جدیدی به پروژه تحمیل می‌کنند. اینجاست که ما با «گورستان بهره‌وری هوش مصنوعی» روبرو می‌شویم: کدبیس‌های قدیمی (Legacy Codebase).
به نقل از راهنمای فنی منتشر شده در وب‌سایت coldtake.dev در ۲۹ اوت ۲۰۲۶، مدل‌های زبانی بزرگ در پروژه‌های جدید (Greenfield) که از صفر شروع شده‌اند عالی عمل می‌کنند، اما در مواجهه با سیستم‌های قدیمی (Brownfield) که با بدهی‌های فنی انباشته شده و قراردادهای نام‌گذاری متناقض رنج می‌برند، به‌شدت شکست می‌خورند.
کالبدشکافی شکست هوش مصنوعی
در یک پروژه جدید (Greenfield)، درخواست برای ایجاد فیلد «وضعیت پیشنهاد شغلی» (job offer status) به‌سادگی و با دقت اجرا می‌شود. اما در سیستمی که چهار سال است در حال عرضه و تغییر است، مدل احتمالاً چهارمین مدل نوشتاری از مفهومی را ابداع می‌کند که پیش از این سه بار با نام‌های متفاوت در جای‌های مختلف تعریف شده است. این اتفاق به این دلیل رخ می‌دهد که خودِ کدبیس هرگز تصمیم نگرفته است کدام نسخه از این مفهوم «واقعی» و مرجع است.
در این حالت، مدل شروع به حدس زدن می‌کند. ممکن است در جایی که یک فراخوانی مستقیم کافی بود، یک لایه سازگارساز یا آداپتور (Adapter) — شبیه به تبدیل‌های برق که اجازه می‌دهد دو دستگاه با پریزهای متفاوت به هم وصل شوند — اضافه کند، یا برعکس، در جایی که هدف کل معماری استفاده از یک آداپتور بوده است، مستقیماً کد را فراخوانی کند. این‌ها نقص در هوش مدل نیستند، بلکه پاسخ به سؤالاتی هستند که خودِ سیستم در هیچ جای کد یا مستنداتش به آن‌ها پاسخ نداده است.
پروژه‌های قدیمی لایه‌ای از عمق فنی دارند، اما زیر آن لایه، لایه‌ای از سردرگمی، معانی گم‌شده و فقدان یک زبان مشترک برای حل این تضادها قرار دارد. این همان لایه‌ای است که مدل در آن سقوط می‌کند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، نبودِ ساختار، بزرگ‌ترین دشمنِ دقت است. در اینجا مدل نیاز به ارتقا ندارد، بلکه کد آماده‌ی پذیرش هوش مصنوعی نیست. آمادگی (Readiness) چیزی است که باید به‌صورت تدریجی و قطعه به قطعه ساخته شود.
اقتصاد بدهی فنی
در ابتدای مهندسی نرم‌افزار، بدهی فنی به عنوان یک پیامد طبیعی از تحویل سریع محصول و پذیرش مصالحه‌های تجاری در برابر تصمیمات آینده معرفی شد. به‌طور سنتی، پاسخ به این مشکل این بود که ۱۰ تا ۲۰ درصد از بودجه فناوری برای پاک‌سازی‌ها (Cleanups) اختصاص یابد.
اما هزینه این کار به دو بخش تقسیم می‌شود: تصمیم‌گیری درباره آنچه باید تغییر کند و تایپ کردن آن. در حالی که هزینه تصمیم‌گیری (بخش ذهنی و استراتژیک) همچنان بالاست، هزینه تایپ کردن (بخش مکانیکی) به‌شدت کاهش یافته است. یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — اکنون می‌تواند بخش مکانیکی پاک‌سازی، مانند استخراج یک ماژول، بازسازی کد (Refactoring) در دو پکیج مختلف یا افزایش پوشش تست‌ها را با هزینه‌ای انجام دهد که دیگر با اقتصاد سال ۲۰۲۰ قابل مقایسه نیست. برای بهینه‌سازی این هزینه‌ها در محیط‌های عملیاتی، استفاده از مدل‌های زبانی کوچک‌تر به دلیل کاهش هزینه‌های استنتاج، به یک روند غالب تبدیل شده است.
برای بهره‌برداری از این توان، نویسنده پیشنهاد می‌کند از برنامه‌نویسی تاکتیکی (که هدفش فقط «کارさせる» و راه انداختن سریع کد است) به برنامه‌نویسی استراتژیک (سرمایه‌گذاری روی طراحی) تغییر مسیر دهیم. کار استراتژیک شامل خواندن سیستم و تحلیل این است که چه چیزی باید تغییر کند و چرا. کار تاکتیکی یعنی انتقال آن تصمیمات به داخل فایل‌ها. اولی نیازماد داشتن مدل سیستم در ذهن انسان است؛ دومی اکنون ارزان شده است.
گردش‌کار عامل‌محور
سیستم پیشنهادی، نویسندگی کد را به دو مسیر مجزا تقسیم می‌کند:
- مسیر استراتژیک: انسان به‌طور کامل درگیر است. او کدبیس را به‌صورت کلی تحلیل می‌کند، تغییرات را برای همراستایی با ویژگی‌های محصول ارزیابی می‌کند و در هر مخزن (Repository) مربوطه، ایشوهای گیت‌هاب (GitHub Issues) را ایجاد می‌کند.
- مسیر تاکتیکی: انسان دیگر اجراکننده نیست، بلکه نقش بازبین (Reviewer) را دارد. یک سامانه عامل‌محور (Agentic) با ترکیبی از «مهارت‌ها» و «زیر-عامل‌ها» به ایشوهای ایجاد شده پاسخ می‌دهد. این رویکرد در واقع تکاملی از تبدیل چت‌بات‌های صلب به دستیارهای پویا و عامل‌محور است که اجازه می‌دهد هوش مصنوعی از پاسخ‌های ساده به سمت اجرای وظایف پیچیده حرکت کند.
جزئیات سامانه هوش مصنوعی
مهارت‌ها (Skills): این‌ها رویه‌های مکتوبی هستند که در فایل‌های markdown ذخیره شده‌اند. مدل زمانی که یک تسک با این مهارت‌ها مطابقت داشته باشد، دستورالعمل‌ها را بارگذاری می‌کند. این کار تضمین می‌کند عملیاتی مثل «رفع یک ایشو» یا «بازسازی نقشه زمینه» (Context Map) هر بار دقیقاً یکسان اجرا شوند، فارغ از اینکه کاربر در آن صبح درخواست را با چه لحنی بیان کرده است.
زیر-عامل‌ها (Sub-agents): این‌ها جلسات مجزای مدل با زمینه‌های (Context) تازه و وظایف محدود هستند. برای مثال، یک زیر-عامل برای پیاده‌سازی یک ویژگی، یکی برای بررسی امنیتی و دیگری برای بازبینی بر اساس مشخصات فنی (Spec) عمل می‌کند. آن‌ها به جای ریختن تمام متن گفتگوها در جلسه اصلی، فقط نتیجه نهایی را به کاربر گزارش می‌دهند.
فرآیند بازبینی: پس از پیاده‌سازی، درخواست‌های ادغام (PR) آماده بازبینی می‌شوند. انسان در این مرحله پوشش تست‌ها را بررسی می‌کند و شناسایی می‌کند که کدام بخش‌های دیگر سیستم از کامپوننت‌های تغییریافته استفاده می‌کنند تا مطمئن شود تغییرات باعث فروپاشی سیستم نمی‌شوند.
پیاده‌سازی طراحی دامنه-محور (DDD)
برای جلوگیری از توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — نویسنده از طراحی دامنه-محور (Domain-Driven Design) استفاده می‌کند. برای مقابله با این چالش، استفاده از اعتبارسنجی‌های سخت‌گیرانه در لایه‌های بازیابی داده یکی از موثرترین روش‌ها برای حذف توهمات پارامتری در مدل‌های زبانی است. بر اساس رویکرد اریک ایوانز، DDD از «زبان مشترک» (Ubiquitous Language) و «بسترهای محدود» (Bounded Contexts) برای کاهش شکاف ارتباطی بین بخش‌های تجاری و فنی استفاده می‌کند.
در محیطی که عامل‌های هوش مصنوعی در چرخه هستند، این پیوند حیاتی است. DDD تعریف می‌کند که نیازها چگونه به مدل بیان شوند و استدلال‌های مدل چگونه بازخوانی شوند. در این ساختار، هر مخزن کد یک فایل مانیفست .workflow.json در ریشه دارد. این مانیفست به ابزارها می‌گوید که این مخزن چیست، شامل چه زبان‌هایی است، کدام دایرکتوری‌ها را عامل باید اول بخواند و چه بررسی‌هایی برای انتشار (Shipping) الزامی است.
ساختار مانیفست
بلاک دامنه (Domain Block) در فایل .workflow.json تنها ثبت مورد نیاز برای هر مخزن است تا از ایجاد یک رجیستری دوم که احتمالاً با زمان مرور از هم فاصله می‌گیرند، جلوگیری شود. این بلاک موارد زیر را تعریف می‌کند:
- نام پروژه.
- بسترهای محدود (Bounded Contexts).
- محل قرارگیری واژه‌نامه (Glossary) هر بستر.
- نوع زیردامنه (Subdomain type).
- هرگونه لبه یا ارتباط (Edge) با بسترهای همسایه.
به‌عنوان مثال در پروژه job-offer-box (یک سیستم ردیابی درخواست‌های شغلی شامل بک‌اند Rust به نام hyperion و یک فرانت‌اند وب)، مانیفست فرانت‌اند شامل یک لبه خاص است:
{ "domain": { "project": "job-offer-box", "contexts": [ { "name": "job-box-web", "docs": "CONTEXT.md", "subdomain": "supporting", "edges": [ { "to": "hyperion/job-offer-backend", "direction": "outbound", "pattern": "unclassified", "owner": "supplier", "shape": "codegen from the backend's document (scripts/generate-api.ts:12) ... conformist on write (src/lib/api/jobs.ts:37), ACL on read (src/lib/api/adapters/offer.ts:50)", "note": "conformist on write and an anticorruption layer on read; two patterns hold at once, so neither name alone is true" } ] } ] } }
در این مثال، to آدرس بستر دیگر است. direction خروجی (outbound) است چون فرانت‌اند بک‌اند را فراخوانی می‌کند. owner تأمین‌کننده (supplier) یعنی بک‌اند است، به این معنی که در صورت اختلاف در نام‌گذاری، مدل بک‌اند پیروز است. pattern به دلیل استفاده همزمان از الگوی «مطابق» (Conformist) در نوشتن و «لایه ضد-فساد» (ACL) در خواندن، به عنوان «طبقه‌بندی نشده» (unclassified) علامت‌گذاری شده است.
واژه‌نامه زنده و نقشه بستر
در کنار مانیفست، هر بستر یک فایل CONTEXT.md دارد. این یک واژه‌نامه زنده است که معنای دقیق هر اصطلاح و لیستی از مترادف‌هایی که به‌طور عمدی رد شده‌اند را نگه می‌دارد.
برای حفظ یک دید کلی، یک اسکریپت تولیدکننده تمام مخازن روی دیسک را بررسی می‌کند، بلاک‌های دامنه را با هم ترکیب (Union) کرده و یک فایل CONTEXT-MAP.md صادر می‌کند. این نقشه یک فایل مصرفی است که هر زمان نیاز باشد دوباره تولید می‌شود.
در مثال job-offer-box:
- hyperion/job-offer-backend مالک زبان محصول است و اصطلاحاتی مثل «پیشنهاد شغلی» (Job Offer)، «پروفایل»، «نسخه پروفایل»، «رزومه» و «نامه پوششی» را مدیریت می‌کند. اگر دو بستر یک اصطلاح را تعریف کنند، آن بستری که وضعیت پایدار (Durable State) را نگه می‌دارد، مالک آن است.
- job-offer-box/job-box-web فقط مالک واژگان مربوط به صفحه نمایش (مانند View Model، Filter State، Facet Stats) است. هر چیز دیگری با برچسب
[published]علامت‌گذاری شده و به صورت TypeScript تولید شده از سند OpenAPI بک‌اند وارد می‌شود.
این دقت به عامل می‌فهماند که تغییر نام «Job Offer» در مخزن وب، در واقع یک تسک مربوط به بک‌اند است و وجود آداپتورها در مسیر خواندن، عمدی و هدفمند است.
حل مکانیکی تضادها
هر لبه (Edge) دو بار تعریف می‌شود؛ یک بار از هر طرف. این تکرار اجازه می‌دهد تولیدکننده نقشه، جفت‌ها را با استفاده از یک جدول جفت‌سازی (Pairing Table) بررسی متقاطع کند. تأمین‌کننده موضع خود را (زبان منتشر شده) نام می‌برد و مصرف‌کننده موضع خود را (مطابق یا لایه ضد-فساد).
این بررسی به عنوان یک «مهارت» در سه لحظه خاص اجرا می‌شود:
۱. زمانی که یک مانیفست تغییر کرده باشد.
۲. هنگام اضافه کردن یک مخزن جدید به سیستم.
۳. پیش از تغییر در هر بخشی که بسترهای دیگر به آن وابسته هستند.
هر تضاد به عنوان یک «مشکل DDD» در مخزنی که طرف اشتباه را تعریف کرده، ثبت می‌شود. این ایشو دارای یک اثر انگشت (نوع یافته به علاوه دو آدرس) است، بنابراین اجراهای مجدد به جای باز کردن ایشوهای تکراری، همان‌های قبلی را به‌روز می‌کنند. اگر یک تضاد برطرف شود، ایشو بسته می‌شود. این فرآیند از همان خط لوله پیروی می‌کند: ایشو $ \rightarrow $ عامل $ \rightarrow $ PR $ \rightarrow $ بازبینی انسانی.
مسیر پیش رو
این لایه استراتژیک، شکل نقشه را تثبیت می‌کند؛ اینکه بسترهای محدود کجا تمام می‌شوند و چگونه با هم ارتباط برقرار می‌کنند. گام بعدی، تمرکز بر داخل هر بستر است. با انتقال کدهای معمولی به مدل‌های دامنه واقعی که از primitivesهای DDD (مانند Value Objects، Aggregates و Domain Services) ساخته شده‌اند، کدبیس شروع به پاسخ دادن به سؤالاتی می‌کند که مدل قبلاً در مورد آن‌ها حدس می‌زد.
این تغییر، فرض بنیادی کدنویسی با هوش مصنوعی را تغییر می‌دهد: مدل آن چیزی نیست که نیاز به ارتقا دارد، بلکه «آمادگی کد» است که باید ارتقا یابد. با ساخت یک نقشه ساختاری از دامنه، توسعه‌دهندگان محیطی ایجاد می‌کنند که در آن عامل‌ها می‌توانند با دقت جراحی عمل کنند، نه با حدس‌های احتمالی.
توسعه‌دهندگانی که قصد پیاده‌سازی این روش را دارند، باید با شناسایی ناسازگارترین ماژول‌های خود و نوشتن یک واژه‌نامه پایه در CONTEXT.md شروع کنند تا ببینند آیا این کار نرخ خطاهای نام‌گذاری تولید شده توسط AI را کاهش می‌دهد یا خیر.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو