تصور کنید تیم توسعه شما هر شب صدها خط کد را بدون بررسی انسانی به محصول اضافه کند؛ سرعت رشد خیرهکننده است، اما زیرساخت شما در حال تبدیل شدن به یک بمب ساعتی از بدهی فنی است. اگر امروز به عاملهای کدنویسی اعتماد میکنید، باید بدانید این سرعت لجامگسسته در حال تخریب کیفیت پایدار کدبیسهای تجاری است.
این بحران دقیقاً زمانی رخ میدهد که غولهایی چون Stripe، Ramp و WorkOS در حال مقیاسبندی کدنویسی عاملمحور (Agentic) هستند تا بخش بزرگی از کدهای خود را با هوش مصنوعی تولید کنند.叙روایت رایج در صنعت این است که مهندسی حفاظها (Harness Engineering) و حلقههای بازخوردی بیشتر میتواند جایگزین نظارت انسانی شود. اما طبق گزارش Faros AI، کیفیت تولید در محیطهای عملیاتی از ابتدای سال ۲۰۲۶ بهشدت سقوط کرده است. دادهها نشان میدهند تعداد حوادث به ازای هر درخواست ادغام (Pull Request) ۲۴۲.۷٪ و حوادث ماهانه ۵۷.۹٪ افزایش یافته است. همچنین تعداد باگها به ازای هر توسعهدهنده ۵۴٪ رشد کرده است.
همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، تکیه مطلق بر اتوماسیون بدون لایه نظارتی، ریسکهای سیستمی را بهشدت بالا میبرد. در مدل «کارخانههای بدون چراغ» (Lights-off Factories)، گلوگاه بررسی کد توسط انسان بهطور کامل حذف میشود. در این ساختار، سیستم تنها به ابزارهای بررسی خودکار (Linters)، تستهای رگرسیون مبتنی بر هوش مصنوعی و سیستمهای مانیتورینگ تکیه میکند. این چالشها در واقع بازتابی از ضعف چارچوبهای متنی در مدیریت مهندسی سطح تولید است که مانع از پایداری سیستمها در مقیاس بزرگ میشود.
دکس (Dex)، بنیانگذار HumanLayer، تجربه تلاش برای اجرای این مدل در ژوئیه ۲۰۲۵ را بازگو میکند؛ او میگوید سیستم در نهایت زیر فشار «اسپاگتی کدهای کلود» (Claude Spaghetti) فروپاشید. وقتی یک عامل (Agent) — شبیه به دستیاری که دستورات را سریع اما بدون درک عمیق از کل پروژه اجرا میکند — با یک باگ پیچیده مواجه میشود، نبود معماری خوانا برای انسان، اصلاح آن را تقریباً غیرممکن میکند. مدلها در حل تکمسائلی که سریع جواب میدهند موفقاند، اما در حفظ کیفیت کلی کدبیس شکست میخورند. این وضعیت تأکید میکند که باید به دستیارهای کدنویسی به چشم مهندسین جونیور نگاه کرد تا نقش آنها را در سطح تکمیلکننده کد قرار داد، نه معمار ارشد سیستم.
ریشه این مشکل در نحوه آموزش مدلهایی مانند Claude Code است. شرکت Anthropic از یادگیری تقویتی (RL) — روشی شبیه به آموزش سگ با پاداش برای انجام درست یک حرکت — برای آموزش مدلها در مواجهه با ابزارهای ارسالی استفاده کرده است. اگرچه این کار مدلها را در استفاده از ابزارهایی مثل grep یا نوشتن کد ماهر کرد، اما توابع پاداش (Reward Functions) اساساً ناقص هستند.
اکثر محکهای کدنویسی، مانند SWE-bench Multilingual، از پاداش دودویی استفاده میکنند: آیا وصله (Patch) باگ را بدون شکستن تستهای موجود برطرف کرد؟
در این سیستم هیچ جریمهای برای معماری بد وجود ندارد. اگر مدل یک تابع معیوب را در یک بلوک try-catch تنبل میپیچاند یا از تبدیل نوعی (Type-cast) استفاده میکند که سیستم تایپ را تضعیف میکند، باز هم امتیاز «۱» میگیرد چون تستها پاس شدهاند. هزینه این طراحی بد که هفتهها بازنویسی در آینده طلب میکند، برای «اوراکلِ» یادگیری تقویتی نامرئی است.
برای عبور ایمن از این وضعیت، دکس پیشنهاد میکند انسانها به چرخه بازگردند؛ اما نه به عنوان بازبینیکنندگان خطبهخط، بلکه به عنوان معماران. هدف این است که همراستاسازی (Alignment) در ابتدای مسیر انجام شود تا نیاز به بازنویسی کم شود. این فرآیند شامل چهار فاز است:
۱. بررسی محصول: ایجاد مستندات ساختاریافته و طرحهای اولیه (Mockups) برای توافق بر سر نیاز کاربر پیش از نوشتن حتی یک خط کد.
۲. معماری سیستم: تعریف نحوه تعامل سرویسها، نقاط انتهایی (Endpoints) و شمای دادهها با استفاده از نمودارهای توالی.
۳. طراحی برنامه: ورود به لایهی عمیقتر «شکل» کد، از جمله تعریف تایپها و امضاهای متدها پیش از پیادهسازی.
۴. برشهای عمودی (Vertical Slices): بهجای برنامههای افقی (مثلاً ابتدا ساخت کل دیتابیس و سپس کل رابط کاربری)، انسان باید مدل را هدایت کند تا «گلولههای ردیاب» بسازد؛ یعنی تکههای نازک و کامل از یک قابلیت که از ابتدا تا انتها کار میکند و در بازههای ۱۰۰ تا ۲۰۰ خطی قابل بررسی است.
تیمهای مهندسی باید تسکها را بر اساس پیچیدگی دستهبندی کنند. حدود ۴۰٪ تسکها میتوانند بهصورت تک-شات (One-shot) انجام شوند. تسکهای متوسط به سند طراحی محصول و سیستم نیاز دارند و قابلیتهای بزرگ و پرریسک باید از هر چهار فاز بگذرند.
در حالی که بررسی یک Pull Request باکیفیت لذتبخش است، کدهای تولید شده توسط هوش مصنوعی اغلب به ۵۰٪ بازنویسی نیاز دارند. با صرف ۳۰ دقیقه زمان برای برنامهریزی، توسعهدهندگان از ساعتها بررسی دردناک و نیاز به بازنویسی کامل سیستم در آینده نجات مییابند. این رویکرد یک واقعیت سخت را میپذیرد: ما هنوز اوراکل سریع و قابلاعتمادی برای سنجش «قابلیت نگهداری» کد نداریم و تنها داور قابلاعتماد، انسانی است که پیامدهای بلندمدت یک تصمیم طراحی را میفهمد.
گام بعدی شما
- تسکهای خود را به سه دسته (ساده، متوسط، پیچیده) تقسیم کنید و برای موارد پیچیده، مدل را مجبور به ارائه «طرح معماری» پیش از کدنویسی کنید.
- بهجای درخواستهای کلی، از متد «برش عمودی» استفاده کنید و هر بار فقط یک قابلیت کوچک را از لایه دیتابیس تا UI پیادهسازی و بررسی کنید.
- در پرامپتهای خود، جریمه برای «راهکارهای تنبل» (مانند try-catchهای کلی) تعریف کنید و مدل را به چالش بکشید تا دلیل انتخاب معماری خاص را توضیح دهد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو