عاملهای کدنویسی هوش مصنوعی در monorepoها خفه میشوند و سازمانها کدبیسهای خود را بازطراحی میکنند
طبق نظرسنجیهای صنعتی اخیر، تقریباً نه از هر ده پروژه آزمایشی عامل کدنویسی هوش مصنوعی هرگز به تولید نمیرسند — و توضیح بدیهی که مدلها هنوز به اندازه کافی خوب نیستند، تا حد زیادی نادرست است. مانع واقعی معماری است: کدبیسهایی که از این عاملها خواسته میشود در آنها کار کنند، برای انسانها و سیستمهای ساخت طراحی شدهاند، نه ابزارهایی با پنجره زمینه ثابت، و monorepoها جایی است که این عدم تطابق بیشترین وضوح را دارد.
چرا monorepoها بهطور خاص برای عاملها خصمانه هستند
یک monorepo با ۵۰ بسته و ۳۰۰,۰۰۰ خط کد یک تنظیم مهندسی کاملاً عادی است — بسیاری از سازمانهای بزرگ فناوری، دهها سرویس و کتابخانه را در یک مخزن واحد ادغام میکنند تا تغییرات بینپروژهای و مدیریت وابستگی برای مهندسان انسانی سادهتر شود. این ادغام دقیقاً همان چیزی است که هدف است: یک تاریخچه commit، یک خط لوله CI، یک مکان برای اعمال استانداردها.
برای یک عامل هوش مصنوعی، همین ساختار به یک بدهی تبدیل میشود. عاملی که سعی میکند «کدبیس» را برای زمینه بارگذاری کند، یا ردیابی آنچه واقعاً به وظیفه مربوط است را از دست میدهد، یا کل بودجه زمینهاش را روی فایلهایی میسوزاند که هرگز لمس نخواهد کرد. یک مورد گزارششده شامل تلاش برای وارد کردن یک monorepo با ۴۵۰,۰۰۰ فایل به زمینه کاری یک عامل بود که به دلیل محدودیتهای مرورگر و ابزارها کاملاً شکست خورد — نه به این دلیل که وظیفه از نظر مفهومی سخت بود، بلکه به این دلیل که تعداد خالص فایلها از آنچه ابزارها اصلاً میتوانستند مدیریت کنند فراتر رفت.
این یک حالت شکست کاملاً متفاوت از «مدل اشتباه کرد» است. نزدیکتر به این است که به کسی یک کابینت بایگانی با ۳۰۰,۰۰۰ پوشه بدهید و از او بخواهید سه پوشه مهم را پیدا کند، با این تفاوت که آن شخص باید ابتدا برچسب هر پوشه را مرور کند و پس از پوشه ۴۰,۰۰۰ همهچیز را فراموش میکند.
مشکل یکپارچهسازی از مشکل زمینه بزرگتر است
دادههای نظرسنجی تأیید میکند که این واقعاً یک شکاف هوشمندی نیست. حدود ۴۶ درصد از تیمهایی که ابزارهای کدنویسی عاملمحور را بهکار میگیرند، یکپارچهسازی با سیستمهای موجود را مانع اصلی خود عنوان میکنند — نه تولید کد نادرست، نه توهم، بلکه مکانیزم اتصال ایمن و قابلاعتماد یک عامل به مخازن واقعی، سیستمهای CI واقعی و خطوط لوله استقرار واقعی. پیشبینی خود Gartner صریح است: انتظار دارد بیش از ۴۰ درصد پروژههای هوش مصنوعی عاملمحور تا پایان ۲۰۲۷ لغو شوند، به دلیل هزینههای رو به افزایش، ارزش تجاری نامشخص و کنترلهای ریسک ناکافی — نه به دلیل شکست عاملها در خود وظیفه کدنویسی.
با این حال، پذیرش متوقف نشده است. حدود ۵۷ درصد از سازمانهای مورد بررسی هماکنون عاملهای کدنویسی را در جایی از تولید دارند، با سازمانهای بزرگ — دقیقاً همانهایی که به احتمال زیاد monorepoهای بزرگ را اجرا میکنند — در صدر پذیرش. این ترکیب استفاده بالا در تولید و اصطکاک بالای monorepo دلیلی است که راهحلهای موقت همین حالا اهمیت دارند، نه بهصورت فرضی.
تیمها واقعاً چه کاری انجام میدهند
سه الگو در نحوه تطبیق سازمانهای مهندسی با monorepoها برای استفاده عاملها در حال ظهور است، بهجای انتظار برای هوشمندتر شدن عاملها.
نمایهسازی گزینشی بهجای زمینه کل مخزن. بهجای دادن کل monorepo به یک عامل، تیمها لایههای بازیابی میسازند که فقط زیرمجموعهای از فایلهای مرتبط با وظیفه را به عامل میدهند — گرافهای وابستگی، مرزهای مالکیت و تاریخچه تغییرات اخیر برای ساخت یک مجموعه کاری بسیار کوچکتر برای هر وظیفه استفاده میشوند.
تراش مجازی زیرمخزنها. برخی سازمانها «نماهایی» رو به عامل از یک monorepo ارائه میدهند که مانند مخازن مستقل محدود به یک سرویس یا بسته واحد به نظر میرسند و رفتار میکنند، در حالی که منبع حقیقت زیربنایی همچنان یک مخزن واحد یکپارچه برای انسانها و CI باقی میماند.
حاکمیت و زیرساخت ایزولاسیون قبل از قابلیت بیشتر عامل. تیمهایی که به تولید میرسند، در حال اولویتبندی sandbox، محدودسازی مجوز و مسیرهای حسابرسی برای آنچه یک عامل میتواند لمس کند هستند — با این نگاه که زیرساخت استقرار مانع واقعی است، نه هوشمندی عامل.
نتیجه برای رهبران مهندسی
اگر سازمان شما با یک عامل کدنویسی در مرحله آزمایشی گیر کرده، راهحل احتمالاً یک مدل بهتر یا یک prompt بهتر نیست — بازاندیشی در مورد اینکه عامل واقعاً چقدر از کدبیس شما باید برای یک وظیفه معین ببیند، و ساخت لایه بازیابی یا محدودسازی است که این را ممکن میسازد. تصمیمات معماری monorepo که صرفاً برای تیمهای مهندسی انسانی منطقی بودند، اکنون چه کسی برنامهریزی کرده باشد چه نه، تصمیماتی درباره قابلاستفاده بودن کدبیس شما برای ابزارهای عاملمحور نیز هستند.