تصور کنید یک برنامه‌نویس ارشد در تیمی است که همه از AI استفاده می‌کنند، اما کیفیت کدهای تولید شده بسته به اینکه چه کسی پشت کیبورد است، از «عالی» تا «فاجعه‌بار» تغییر می‌کند. این یعنی موفقیت پروژه نه به قدرت مدل، بلکه به حافظه لحظه‌ای کاربر برای پرسیدن «درست» وابسته است.
طبق گزارشی که در ۲۴ جولای ۲۰۲۶ منتشر شد، کیفیت کدهای تولیدشده توسط هوش مصنوعی بیش از آنکه به خود مدل وابسته باشد، به نحوه بیان درخواست (Prompt) بستگی دارد. وقتی یک درخواست را کمی متفاوت بیان می‌کنیم، نتایج بین یک کد متوسط و یک کد دقیق نوسان می‌کنند. این یعنی خروجی مدل، تابعی از مهارت فردی است، نه یک استاندارد ثابت.
در یک مورد واقعی، کاربر وظیفه‌ای را به یک عامل (Agent) — شبیه به دستیاری که می‌تواند ابزارهای مختلف را به جای شما اجرا کند — سپرد و نتیجه‌ای گرفت که «بد نبود اما خوب هم نبود». اما درست در همان بعدازظهر، با مدل و مخزن کد یکسان، تنها با تغییر نحوه بیان درخواست، عامل دقیقاً همان چیزی را تحویل داد که مورد نیاز بود. این چالش‌ها یادآور موردی است که در بررسی شکست لایه گزارش‌دهی در عامل‌های کدنویس به آن پرداختیم، جایی که متوجه شدیم موفقیت عامل‌ها تنها به پرامپت‌ها وابسته نیست و زیرساخت‌های خروجی نیز حیاتی هستند.
تفاوت در جزئیات کادربندی بود: در یک روز خوب، برنامه‌نویس به یاد داشت ابتدا لاگ‌های خطا را به مدل نشان دهد، از آن بخواهد ابتدا باگ را بازتولید کند و سپس الگوهای موجود در کد را یادآوری کند. اما در یک روز شلوغ و با تمرکزی پایین، فراموش کردن نیمی از این مراحل ساده، منجر به نصف شدن نتایج شد.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت و پایداری مدل‌های بازمتن اشاره کردیم، این نوسان (Variance) یک هزینه پنهان برای تیم‌های مهندسی ایجاد می‌کند. در حالی که کارهای فردی ممکن است خوب به نظر برسند، اما فقدان یک متدولوژی مشترک به این معناست که یک توسعه‌دهنده ممکن است از ترفندهای پیچیده برای رسیدن به نتایج پاک استفاده کند، در حالی که توسعه‌دهنده دیگری کدی را دستی می‌نویسد که یک مولد کد می‌توانست اسکلت آن را بسازد. این ناسازگاری باعث می‌شود خروجی‌ها در یک سازمان در حال رشد، غیرقابل پیش‌بینی شوند. در واقع، آنچه تیم‌ها را می‌کشد، «میانگین» کیفیت نیست، بلکه همین نوسانات شدید است.
برای حل این مشکل، سیستمی بر پایه «پلی‌بوک‌های متمرکز» توسعه یافته است. این‌ها برخلاف ویکی‌های ایستا که هیچ‌کس نمی‌خواند یا فایل‌های دستورالعمل غول‌آسا که به دلیل حجم زیاد نادیده گرفته می‌شوند، مهارت‌های کوچک و بازگشتی در قالب متن ساده هستند که عامل می‌تواند به‌طور خودکار آن‌ها را به کار بگیرد. این رویکرد در واقع تکامل یافته‌ی استراتژی‌های مدیریت بستر کد است که نشان داد ارتقای زمینه اطلاعاتی (Context) برای مدل، بسیار اثرگذارتر از صرفاً استفاده از مدل‌های هوشمندتر است.
این پلی‌بوک‌ها توصیف می‌کنند که انواع خاصی از وظایف چگونه باید پیش بروند، از جمله:
- شکار باگ‌های سخت: گام‌های مشخص برای ردیابی و شکار خطاهای پیچیده.
- توسعه تست-محور: نحوه ساخت قابلیت‌ها با استفاده از رویکرد «اول تست، بعد کد».
- ایجاد مشخصات (Spec): روش تبدیل یک ایده خام به یک سند فنی دقیق، پیش از آنکه حتی یک خط کد نوشته شود.
یک جزء حیاتی در این معماری، «روتر» (Router) است؛ یک درگاه واحد که کاربران قصد خود را در آن بیان می‌کنند و سیستم آن‌ها را به پلی‌بوک درست هدват می‌کند. این سازوکار نیاز توسعه‌دهندگان به حفظ کردن کاتالوگی از پرامپت‌ها را از بین می‌برد.
تمام پلی‌بوک‌ها اختیاری (Opt-in) هستند و به زبان متن ساده نوشته شده‌اند. این موضوع تضمین می‌کند که وقتی یک پلی‌بوک اشتباه است، اصلاح آن تنها شامل تغییر یک خط متن است، نه یک بحث طولانی و فرسایشی تیمی. به نقل از گزارش dev.to، یک یافته کلیدی این بود که مهارت‌هایی که هیچ‌کس به سراغ آن‌ها نمی‌رود، صرفاً «وزنه اضافی» (Dead weight) هستند؛ بنابراین روتر به اندازه خودِ مهارت‌ها اهمیت دارد.
این سیستم از نظریات اتوماسیون مهارت‌محور مت پاکوک (Matt Pocock) الهام گرفته است. اصل راهبردی اینجا این است: یک مهارت تنها زمانی ارزش دارد که عامل در لحظه درست به سراغ آن برود.
با تبدیل «مسیر درست» به «مسیر پیش‌فرض»، تیم تضمین می‌کند که رفع یک باگ، فارغ از اینکه چه کسی آن را شروع کرده، از یک حلقه منظم و منضبط پیروی کند. هدف اصلی از افزایش سرعت به «تضمین پیش‌بینی‌پذیری» تغییر یافت. جالب این است که پلی‌بوک‌هایی که جایگاه خود را در سیستم تثبیت کردند، تقریباً همیشه مربوط به کارهای خسته‌کننده و تکراری بودند، نه موارد خاص و هوشمندانه (Edge cases) که نویسنده در ابتدا انتظار داشت برای آن‌ها پلی‌بوک بسازد.
این چرخش به این معناست که اصلاح یک فرآیند معیوب، حالا به جای بحث‌های طولانی تیمی، تنها با تغییر یک خط متن ممکن است. این رویکرد، عامل AI را از ابزاری که نیاز به مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — دارد، به یک ابزار استاندارد تبدیل می‌کند که کف کیفیتی ثابت را برای کل سازمان حفظ می‌کند.
اگر شما تیمی را مدیریت می‌کنید که با هوش مصنوعی ادغام شده است، به جای تکیه بر اسناد سیاستی (Policy) که کسی نمی‌خواند و در عرض یک هفته قدیمی می‌شوند، پلی‌بوک‌های کم‌ریسک و قابل جایگزینی بسازید که «راه درستِ کار کردن» را به «راحت‌ترین راهِ کار کردن» تبدیل کنند. این یک معامله ارزان و کم‌ریسک است که کیفیت بخش بزرگی از کارهای تیم شما را تثبیت می‌کند. تماشا کنید که چگونه با بهبود پیش‌فرض‌ها، نوسانات کیفیت در تیم شما کاهش می‌یابد.
گام بعدی شما
- به جای نوشتن اسناد سیاستی (Policy) که کسی نمی‌خواند، «پلی‌بوک‌های» کوچک و قابل جایگزین برای تکراری‌ترین کارهای تیمتان بسازید.
- یک روتر ساده برای دسترسی به این دستورالعمل‌ها طراحی کنید تا مهندسی پرامپت از دوش تک‌تک افراد برداشته شود.
- بر روی کاهش نوسان کیفیت تمرکز کنید، نه لزوماً افزایش سرعت تولید کد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو