«ناپایداری ساختاری»؛ چالش کدهای تولیدشده توسط هوش مصنوعی در سیستم‌های پیچیده

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

بر اساس مستندات چارچوبی با عنوان Tedium Is Stability (تدیم است پایداری) که در ۱۱ ژوئیه ۲۰۲۶ منتشر شد، این شکاف به‌دلیل تفاوت بنیادین میان «کد کارآمد» و «ویژگی کامل» ایجاد می‌شود. مدل‌های هوش مصنوعی در منطق‌های بصری — مثل نقاط انتهایی API (API endpoints) و لایه‌های سرویس — عالی هستند، اما قوانین نانوشته‌ی یک سیستم بالغ را نادیده می‌گیرند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تفاوت یک برنامه‌نویس جونیور و یک مهندس باسابقه در همین جزئیات پنهان است؛ جایی که یک جونیور ممکن است صرفاً دستورات یک تیکت را دنبال کند، اما مهندس خبره با تکیه بر شهود خود، امنیت، حسابرسی و هم‌زمانی (Concurrency) را مدیریت می‌کند. این رویکرد با این دیدگاه همسو است که مدل‌های زبانی فعلی را باید بیشتر به عنوان تکمیل‌کننده‌های کد دید تا معماران سیستم، چرا که هنوز توانایی درک جامع معماری‌های پیچیده را ندارند. در سیستم‌های پیچیده، همین تعهدات نامرئی هستند که منبع اصلی شکست‌ها در محیط عملیاتی (Production) می‌شوند. نویسنده اشاره می‌کند که هرچه ویژگی ساده‌تر باشد، این ناآرامی کمرنگ‌تر است؛ اما هرچه سیستم بالغ‌تر باشد، این شکاف مرگبارتر می‌شود.

برای درک بهتر این موضوع، مجموعه‌ی dev.to یک ویژگی کارآمد را مانند نوک کوه یخی می‌بیند که بالای خط آب است. اگر از یک عامل (Agent) — ابزاری هوشمند که می‌تواند به‌طور مستقل کارهای پیچیده را پیش ببرد — بخواهید «API خاصی برای خروجی گزارشات سفارشات بسازد»، مدل بخش مرئی را می‌سازد: یک نقطه انتهایی، منطق سرویس و تست‌های موفق. این خروجی تمیز و اطمینان‌بخش است، اما تمام رشته‌های طولانی از الزامات زیر سطح آب که هیچ‌کس به‌طور صریح به آن‌ها اشاره نکرده، نادیده گرفته می‌شوند.

به گزارش dev.to، خطر اصلی در یک «نامتقارن بودن بی‌رحمانه» (Cruel Asymmetry) نهفته است. هوش مصنوعی بخش مرئی وظیفه را به‌طور دقیق انجام می‌دهد، به این معنی که در دموی اولیه هیچ خطایی رخ نمی‌دهد. از آنجایی که هوش مصنوعی «کود نادان» نیست، بلکه صرفاً به او گفته نشده است که «این موارد را هم چک کن»، ویژگی منتشر شده و آرام به نظر می‌رسد. اما صورت‌حساب واقعی سه ماه بعد می‌رسد؛ زمانی که یک نشت داده یا نبودِ لاگ‌های حسابرسی در محیط عملیاتی کشف می‌شود — مشکلاتی که هرگز هنگام اجرای یک نمونه واحد روی لپ‌تاپ برنامه‌نویس ظاهر نمی‌شوند.

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

• حسابرسی (Auditability): ثبت اینکه چه کسی، چه چیزی و در چه زمانی استخراج کرده است تا مسئولیت‌پذیری در آینده تضمین شود.
• سطوح دسترسی (Authorization): بررسی اینکه آیا کاربر اجازه اجرای عملیات را دارد و آیا طرح (Plan) خاص مشتری، هزینه این ویژگی را پرداخت کرده است یا خیر.
• گردش‌های تأیید (Approval Workflows): تعیین اینکه آیا عملیات پیش از اجرا به سطح خاصی از تأییدیه نیاز دارد.
• امنیت: ماسک کردن فیلدهای حساس، مانند شماره ملی، برای جلوگیری از نشت داده‌ها.
• هم‌ترازی یا یکتایی (Idempotency): اطمینان از اینکه وقتی دو سرور در محیط عملیاتی اجرا می‌شوند، یک عملیات (مانند ارسال اعلان) دوبار اجرا نمی‌شود.
• مشاهده‌پذیری (Observability): اطمینان از اینکه تماس‌های خارجی، مانند ایمیل‌های اعلان، یک رکورد قابل ردیابی بر جای می‌گذارند.
• تست رگرسیون (Regression Testing): تایید اینکه تغییر دادن کد، به‌طور مخفیانه بخش دیگری از سیستم را خراب نکرده است.

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

برای حل این مشکل، چارچوب مذکور بر پایه تز POG بنا شده است؛ رویکردی که معتقد است با پرامپت‌ها و وظایف باید مانند کد برخورد کرد. طبق این دیدگاه، به جای اینکه یک پرامپت صیقل‌خورده یا منطق شکستن یک وظیفه توسط هوش مصنوعی بعد از بستن چت گم شود، توسعه‌دهندگان باید آن‌ها را در Git ثبت کنند و سوابق اجرا را نگه دارند تا تجربه جمعی سازمان انباشته شود.

در حالی که POG به سؤال «هوش مصنوعی چه کرد؟» پاسخ می‌دهد، رویکوب Tedium Is Stability لایه‌ای را اضافه می‌کند تا به این سؤال پاسخ دهد: «آیا هوش مصنوعی همه چیز را انجام داد؟»

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

برای تیم‌هایی که از عامل‌های هوش مصنوعی استفاده می‌کنند، مستندسازی «خسته‌کننده» هر مورد خاص (edge case) دیگر یک کار اضافی و دشوار نیست، بلکه تنها راه قابل اطمینان برای دستیابی به پایداری است. این چرخش، شهودهای معماری نامرئی را به دارایی‌های قابل ردیابی و بازبینی تبدیل می‌کند و به‌طور موثری کل کوه یخ را به سطح آب می‌آورد.

گام بعدی شما

• برای هر تسکی که به هوش مصنوعی می‌سپارید، یک «چک‌لیست الزامات ضمنی» (Implicit Requirements Checklist) بسازید و آن را به عنوان بخشی از پرامپت سیستمی ارسال کنید.
• خروجی‌های مدل را نه با تست‌های واحد (Unit Tests)، بلکه با سناریوهای «شکست در مقیاس» ارزیابی کنید.
• سوابق تصمیم‌گیری مدل‌ها را در مخازن Git ثبت کنید تا دانش سازمانی جایگزین حافظه کوتاه‌مدت مدل شود.

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