عامل من در یک عصر ۳ PR ارسال کرد. ۴۰٪ از پیامهای من اصلاحیه بودند.
عامل کدنویسی مبتنی بر هوش مصنوعی من در یک عصر، سه pull request ارسال کرد، اما ۴۰٪ از ۳۰ پیامهایی که فرستادم، اصلاحیه بودند.
این جلسه منجر به تولید یک MCP client، یک Azure AI Agent و یک M365 Copilot Agent شد. بررسیهای خودکار هر سه PR را تأیید کردند و من حتی یک خط کد هم ویرایش نکردم. با این حال، متن گفتگو داستان متفاوتی را روایت میکند: از مجموع ۷۱۰ پیام، من ۳۰ پیام تایپ کردم که ۱۲ مورد از آنها عامل را دوباره به مسیر درست هدایت کردند. «نرخ هدایت» (steering rate) – یعنی سهم پیامهای من که اصلاحیه بودند – ۴۰٪ است.
نحوه اتصال خط لوله (pipeline)
- Claude یک طرح پیادهسازی سطح بالا تهیه کرد.
- DeepSeek V4-Flash به عنوان ارکستراتور (orchestrator) عمل کرد و طرح را بررسی نمود.
- Codex کد واقعی را تولید کرد.
- ارکستراتور کد را بازبینی کرد و pull requestها را باز کرد.
نقش تعیینشده برای ارکستراتور صرفاً رابطی بود؛ وظیفه آن حل تداخلات بین اجزا بود، نه نوشتن کد. در عمل، عامل در حدود ۴۰ دقیقه، ۳۵۰۰ خط کد در قالب سه PR تولید کرد، اما در دو دسته خطای تکرار شونده دچار لغزش شد.
دو خانواده خطا
۱. نقض جریان کاری (Workflow violations) – ارکستراتور گاهی مرحله کدنویسی را بر عهده میگرفت، نقش «اتصالدهنده» (glue) خود را نادیده میداد و جزئیات پیادهسازی را خودش مینوشت. ۲. شکست در بازیابی متن (Context-retrieval failures) – علیرغم دستورات صریح، عامل SDK یا نسخه اشتباهی را انتخاب میکرد. اطلاعات صحیح در متن دستور (prompt context) موجود بود، اما مدل نتوانست آن را در لحظه مناسب استخراج کند.
اینها شکاف در توانایی استدلال نیستند؛ بلکه باگهای مهندسی در نحوه محدود کردن جریان کاری هستند. حتی یک مدل زبانی توانمندتر نیز همچنان به یک قانون سخت و غیرقابل چشمپوشی نیاز دارد که ارکستراتور را به وظایف غیرکدنویسی خود محدود کند و انتخاب SDK صحیح را اجبار نماید.
آنچه برای رام کردن عامل تغییر دادم
دیگر فرض نکردم که سیستم نقش خود را از لیست مراحل استنباط میکند. یک عبارت مستقیم اضافه کردم: «تو یک ارکستراتور هستی. تو پیادهسازی نمیکنی.» پنج پیام اصلاحی طول کشید تا این دستور تثبیت شود، و پس از آن، عامل به این مرز احترام گذاشت.
همچنین منطق بازیابی متن را دقیقتر کردم. وقتی ابزار اشتباهی ظاهر میشد، به جای آنکه آن را یک توهم (hallucination) بدانم، با آن به عنوان یک باگ در خط لوله بازیابی برخورد کردم و پرامپتی (prompt) را که جزئیات SDK را تغذیه میکرد، بازنویسی کردم تا نادیده گرفتن نسخه صحیح غیرممکن شود.
نکات کاربردی برای توسعه تقویتشده با هوش مصنوعی
- پیامهای خود را بشمارید. حجم بالای PRهای پذیرفتهشده میتواند یک فرآیند معیوب را پنهان کند. تعداد اصلاحات شما، شاخصی پیشرو برای شناسایی نقاط نشت در ساختار است.
- نقش را صراحتاً بیان کنید. عاملها هویت خود را از روی یک چکلیست استخراج نمیکنند؛ آنها به یک دستورالعمل شفاف و ثابت درباره اینکه چه کسی هستند و چه کارهایی میتوانند انجام دهند، نیاز دارند.
- با خطاهای انتخاب ابزار به عنوان باگهای مهندسی برخورد کنید. اگر عامل یک SDK مشخص را نادیده گرفت، تقصیر بر گردن مکانیسم تحویل متن (context-delivery) است، نه «دانش» مدل.
- اشتباهات را به مهارتهای قابل استفاده تبدیل کنید. من اجازه دادم عامل یک روتین اعتبارسنجی از خطاهای خودش تولید کند و بدین ترتیب یک شکست را به یک محافظ در آینده تبدیل کردم.