تصور کنید در لحظهٔ پیادهسازی یک ویژگی جدید هستید؛ همینجاست که تفاوت واقعی میان یک عامل خودکار و یک دستیار ساده روشن میشود، نه در ابزاری که استفاده میکنید. اگر این مرز را نشناسید، احتمالاً برای وظایف مهندسی فعلی خود، گردش کار اشتباهی را انتخاب میکنید.
در حالی که صنعت از «چگونه پرامپت بنویسیم» به «چگونه تفویض کنیم» حرکت میکند، راهنمایی عملی که در ۶ اوت ۲۰۲۶ منتشر شد، یک ماتریس تصمیمگیری را معرفی میکند. این ماتریس مشخص میکند چه زمانی باید از هوش مصنوعی بهمثابه دستیار (AI-as-a-Helper)، توسعهٔ محدودبستر (AB-CD) یا هوش مصنوعی عاملمحور (Agentic AI) استفاده کنیم. توسعهٔ محدودبستر (AB-CD) بهطور خاص به عنوان گردش کاری تعریف شده است که در آن برنامهنویس راهکار مورد انتظار را تعیین و مرز اطلاعاتی هر گام از پیادهسازی را کنترل میکند، اما اجرای سطح پایین و زمانبر را به یک مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — میسپارد.
همانطور که در تحلیل قبلی ما دربارهی ماژولهای آموزشی Visualpath برای AI عاملمحور و MLOps اشاره کردیم، تفویض درست نیازمند شناخت دقیق معماری است. برای درک این موضوع، نویسنده مورد واقعی افزودن یک فیلتر به استک فنی یک استارتاپ آموزشی را بررسی میکند. این پروژه از یک استک جامع شامل ASP.NET Web API، C#، OpenAPI، Angular، TypeScript، RxJS و ng-open-api استفاده میکند.
کد مربوطه در ماژولی قرار دارد که بر خلاصههای کاربر-محور (User-created summaries) تمرکز دارد. این سیستم یک فرم ساده محلی برای تغییرات نیست؛ بلکه یک جریان دادهای پیچیده را به کار میگیرد که در آن پنل چپ شامل کنترلهای فیلترینگ است و ناحیه راست شامل چیپهای فیلتر منتخب (Selected-filter chips) و خلاصههای فیلتر شده است. در این ساختار، تغییرات فیلتر از طریق هابهای رویداد مشترک (Shared event hubs) پخش شده و توسط چندین بخش مستقل رابط کاربری مصرف میشوند.
طبق مستندات این پروژه، جریان داده end-to-end از این خط لوله (Pipeline) خاص میگذرد:
- کنترل فیلتر
- وضعیت مشترک فیلتر
- همگامسازی چیپها
- قرارداد درخواست API
- خط لوله فیلترینگ در بکاند
بر اساس گزارش نویسنده، پیش از انتخاب گردش کار، برنامهنویس باید یک غربالگری اولیه انجام دهد—که در این مورد خاص به دلیل آشنایی برنامهنویس با کدبیس، تنها ۵ تا ۱۰ دقیقه زمان برد. آنها باید به چهار پرسش کلیدی پاسخ دهند:
۱. آیا راهکار مورد انتظار از پیش شناخته شده است؟
۲. آیا مسیر پیادهسازی پایدار است؟
۳. آیا مرز اطلاعاتی را میتوان با اطمینان تعریف کرد؟
۴. آیا رویه تکرارپذیری از قبل وجود دارد؟
برای مثال، در کامپوننت SumsFilterComponent در انگولار، یک فیلتر جدید باید هم حالت خارجی را بازیابی کند و هم تغییرات را منتشر نماید. این کامپوننت از متد _reactOnInputTechDataChanged استفاده میکند تا با کد .react().subscribe((selectedDataInput) => { this._updateForm(selectedDataInput); }) در _sumsFilterBhub مشترک شود. همزمان، یک متد به نام _reactOnFormValueChange خروجیها را از طریق this._sumsFilterBhub.selectedDataOutputChanged.trigger(formValue as SumsFilterSelectedData) فعال میکند.
یک فیلتر جدید باید در هر دو جهت مشارکت کند. اگر فقط کنترل را به قالب (Template) اضافه کنید، جریان وضعیت ناقص میماند. علاوه بر این، خط لوله بکاند Predicateهایی مانند این را اعمال میکند: if (fpsParams.FilterStarred.HasValue) { query = query.Where( summary => fpsParams.FilterStarred.Value ? summary.IsStarred : !summary.IsStarred ); }.
در اینجا نکته حیاتی این است که قراردادهای API تولید شده در فرانتاند نباید بهصورت دستی ویرایش شوند. اینکه فیلتر جدید مستقیماً در یک متد موجود در بکاند قرار گیرد، به یک سرویس کوئری اختصاصی نیاز داشته باشد یا نیازمند تغییر در دیتابیس باشد، کاملاً به معناشناسی (Semantics) آن بستگی دارد. اگرچه درخواست «افزودن یک فیلتر» ساده و تکگانه به نظر میرسد، اما در واقع بسته به معماری موجود، نمایانگر سه وظیفه مهندسی fundamentally متفاوت است.
در حالت اول، اگر الزام این باشد که یک فیلتر Boolean اضافه شود که مشابه یکی از فیلترهای موجود باشد (مثلاً پیروی از فیلتر ستارهدار موجود)، وظیفه در درجه اول «تکمیل الگو» یا همان Pattern Replication است. چون رفتار مورد انتظار، لایههای متأثر (Affected layers)، شکل وضعیت، چرخه حیات چیپها، نگاشت API، Predicateهای بکاند و احتمالاً ساختار تستها از پیش شناخته شدهاند، برنامهنویس میتواند مسیر زیر را دنبال کند:
- برنامهنویس ابتدا از AB-CD استفاده میکند تا رویه ضمنی را به صریح تبدیل کرده و آن را با یک تغییر واقعی اعتبارسنجی کند.
- هنگامی که رویه پایدار شد و نوشته شد، آن را به عنوان راهنمای تکرارپذیر کدگذاری میکند.
- تکرارهای قابل پیشبینی سپس به هوش مصنوعی عاملمحور (Agentic AI) تفویض میشوند.
در واقع: رویه در ذهن برنامهنویس $
ightarrow$ بیان آن از طریق AB-CD $
ightarrow$ اعتبارسنجی روی یک وظیفه واقعی $
ightarrow$ کدگذاری راهنمای تکرارپذیر $
ightarrow$ تفویض تکرارهای بعدی به Agentic AI.
نویسنده اشاره میکند که تکرارپذیری به تنهایی یک وظیفه را «عاملمحور» نمیکند؛ رویه باید صریح، پایدار و قابل تأیید باشد. استفاده از «هوش مصنوعی بهمثابه دستیار» در اینجا کنترل را حفظ میکند، اما یک تغییر پیشبینیپذیر end-to-end را به قطعات پراکنده و تکهتکه تبدیل میکند.
در حالت دوم، اگر فیلتر مشابه نباشد، ممکن است به موارد زیر نیاز داشته باشد:
- یک کنترل یا UX جدید
- معناشناسی وضعیت ناشناخته (مانند بازه/Range، سلسلهمراتب/Hierarchy یا شکلهای چند-مقداری)
- یک قرارداد API متفاوت
- یک فیلد یا رابطه جدید در دیتابیس
- یک کوئری اختصاصی در بکاند
در اینجا معماری شناخته شده است اما رفتار درست در این معماری نامشخص است. در این سناریو، AB-CD پیشران اصلی است. استفاده از دستیار ساده، تفویض بسیار کمی ایجاد میکند زیرا مسیر یکپارچهسازی درک شده است، در حالی که Agentic AI بیش از حد تفویض میکند چون تصمیمات مهندسی هنوز نمیتوانند به عنوان یک رویه پایدار کدگذاری شوند.
یک چرخه پیادهسازی عینی در این حالت به این صورت است:
- گام ۱: برنامهنویس تصمیم میگیرد فیلتر یک بازه تاریخ nullable باشد.
- گام ۲: برنامهنویس فرم، چیپها، API و معناشناسی بکاند را تعریف میکند.
- گام ۳: یک «قرارداد زمینه» (Context Contract) برای مرحله وضعیت فرانتاند ایجاد میشود.
- گام ۴: مدل LLM کد را در داخل آن مرز پیاده میکند.
- گام ۵: برنامهنویس نتیجه را بازبینی کرده و رفتار مقادیر خالی (Empty-value behavior) را شفاف میکند.
- گام ۶: مرز اطلاعاتی برای مرحله بکاند تغییر میکند.
- گام ۷: مدل LLM مربوط به Predicate و تستها را پیاده میکند.
- گام ۸: کلاینت API مجدداً تولید شده و جریان نهایی بازبینی میشود.
اما در حالت سوم، وقتی هیچ زیرساخت فیلترینگی وجود ندارد، ما با یک «خلاء معماری» (Architectural Vacuum) روبرو هستیم. در این وضعیت، مسئله دیگر افزودن یک فیلتر نیست، بلکه یک مسئله طراحی است: «طراحی و پیادهسازی خط لولهای برای فیلترینگ که بتواند از اشکال مختلف فیلتر پشتیبانی کند بدون اینکه غیرقابل نگهداری شود».
در این سناریوی با عدمقطعیت بالا، برنامهنویس باید پرسشهای حیاتی معماری را حل کند:
- وضعیت فیلترینگ کجا باید قرار گیرد؟
- کنترلها چگونه با بقیه رابط کاربری ارتباط برقرار کنند؟
- فیلترها چگونه سریالایز شوند؟
- Predicateها چگونه ترکیب شوند؟
- صفحهبندی (Pagination) و مرتبسازی چگونه با فیلترینگ تعامل کنند؟
- فیلترهای آینده چگونه طراحی را گسترش دهند؟
در اینجا، هوش مصنوعی بهمثابه دستیار تنها انتخاب امن است. مهمترین کار، تعیین راهکار درست است، نه پیادهسازی. نقش مدل در اینجا تحقیق درباره جایگزینها، رصد وابستگیها و تولید کدهای اکتشافی یا اثبات-مفهومهای (PoC) یکبارمصرف است. استفاده از Agentic AI در اینجا ریسکی است، زیرا پیادهسازی خودکار میتواند یک حدس معماری محتمل را به یک تعهد دائمی و تصادفی تبدیل کند. AB-CD نیز زودرس است زیرا راهکار درکشدهای برای استخراج مرزهای پایدار وجود ندارد. خروجیهای عامل باید به عنوان شواهدی برای تصمیمگیری باشند، نه جایگزینی برای آن.
به نقل از تحلیلهای وبسایت dev.to، انتخاب گردش کار باید بر اساس ماتریس زیر از معیارهای ارزیابی باشد:
- عدمقطعیت راهکار:
- دستیار: بالا (راهکار نیاز به اکتشاف دارد)
- AB-CD: متوسط (راهکار تا حد زیادی درک شده است)
- Agentic AI: پایین (نتیجه و مسیر تا حد زیادی شناخته شده است)
- پایداری رویه:
- دستیار: پایین (مسیر اثبات شدهای وجود ندارد)
- AB-CD: جزئی (مسیر گامبهگام تعریف شده است)
- Agentic AI: بالا (رویه تکرارپذیر است)
- اعتبارسنجی:
- دستیار: قضاوت انسانی اولویت دارد
- AB-CD: بازبینی انسانی، پیادهسازی را با راهکار مورد انتظار مقایسه میکند
- Agentic AI: اعتبارسنجی خودکار قوی یا پیشبینیپذیر مورد نیاز است
- تکرارپذیری:
- دستیار: پایین
- AB-CD: پایین تا متوسط
- Agentic AI: بالا
- ارزش یادگیری برای برنامهنویس:
- دستیار: بالا
- AB-CD: متوسط
- Agentic AI: پایین
این ماتریس یک سیستم امتیازدهی نیست. یک وظیفه تکراری بدون اعتبارسنجی واضح ممکن است همچنان برای یک عامل ناامن باشد. برعکس، یک تغییر پرهزینه ممکن است از Agentic AI استفاده کند اگر در یک محیط sandbox با اعتبارسنجی قوی اجرا شود. یک وظیفه یکباره که به خوبی درک شده، ممکن است حتی اگر هیچ رویه تکرارپذیری فرمولبندی نشود، از AB-CD استفاده کند.
مالکیت گردش کار میتواند در طول یک درخواست ویژگی تغییر کند. برنامهنویس ممکن است این مراحل را طی کند:
دستیار (برای تعیین معماری/حل عدمقطعیت) $
ightarrow$ AB-CD (برای پیادهسازی راهکار درکشده) $
ightarrow$ Agentic AI (برای تکرار رویههای پایدار و اعتبارسنجی شده).
این رویکرد هدف را از «حداکثر خودکارسازی AI» به «حداکثر ارزش برای برنامهنویس» تغییر میدهد. نقش برنامهنویس از نوشتن کد به مدیریت مرزها و بازبینی مجموعهای از پیادهسازیهای مجزا و کنترلشده تغییر مییابد.
در نهایت، معادله انسانی نیز مؤثر است؛ هویت برنامهنویس اهمیت دارد. یک معمار پروژه کدبیس را به طور کامل میشناسد و مسیرها و انتزاعهای تعمدی را که نباید دستخورده شوند تشخیص میدهد؛ او میتواند سریعتر به سمت Agentic AI حرکت کند. اما برای کسانی که آشنایی کمتری با سیستم دارند، نویسنده پیشنهاد میکند مالکیت کمتری از پیادهسازی تفویض شود تا از انباشت بدهی فنی جلوگیری گردد.
توانایی استفاده از AB-CD به این بستگی دارد که برنامهنویس بتواند:
- تصمیمات مهندسی مهم را شناسایی کند
- راهکار مورد انتظار را تعریف کند
- مرز اطلاعاتی مرتبط را شناسایی کند
- پیادهسازی را تجزیه (Decompose) کند
- نتایج را به صورت انتقادی بازبینی نماید
ارزش یادگیری نیز نسبی است. یک وظیفه فیلترینگ ممکن است برای معمار روتین باشد اما برای یک برنامهنویس جونیور، تمرین طراحی ارزشمندی باشد. بنابراین، زمانی باید بیشتر تفویض کرد که مسیر پیادهسازی درک شده باشد، نتیجه به طور قابل اعتمادی قابل تأیید باشد و ارزش یادگیری برای برنامهنویس پایین باشد. وظایف روتینتر و نیاز کمتر به رشد برنامهنویس باید منجر به تلاش کمتر برنامهنویس شود.
گام بعدی شما
- برای وظایف تکراری، ابتدا یک بار از متد AB-CD استفاده کنید تا رویه را مستند کنید و سپس آن را به یک عامل بسپارید.
- در مواجهه با عدمقطعیت معماری، از مدلها فقط برای «اکتشاف» استفاده کنید و هرگز اجازه ندهید تصمیمات ساختاری را خودکار اتخاذ کنند.
- یک ماتریس ساده (عدمقطعیت در برابر پایداری) را برای تیم کدنویسی خود تعریف کنید تا استانداردهای تفویض یکسان شود.
اما مدیریت این مرزها در مقیاس سازمانها چالشهای متفاوتی دارد؛ برای بررسی اثر این رویکرد بر بهرهوری تیمهای بزرگ، تحلیل ما درباره مدیریت چرخههای توسعه AI را بخوانید.
گفتگو