چرا فاصله میان «بریف» و «سِپک» باعث شکست عامل‌های کدنویس می‌شود؟

اگر مدیر محصول یا توسعه‌دهنده‌ای هستید که از عامل‌های هوش مصنوعی استفاده می‌کنید، احتمالاً متوجه شده‌اید که کدها اکنون سریع‌تر از توان تیم شما برای توافق بر سر «چه چیزی باید ساخته شود» منتشر می‌شوند. طبق گزارشی که در ۱۶ ژوئن ۲۰۲۶ در وب‌سایت dev.to منتشر شد، یک شکست بحرانی رخ داده است: عامل‌های هوش مصنوعی در مواجهه با دستورات مبهم، متوقف نمی‌شوند؛ آن‌ها صرفاً حدس می‌زنند و کد را ادغام می‌کنند و به این ترتیب نقاط بازرسی انسانی را دور می‌زنند.

در دنیای سنتی نرم‌افزار، پیاده‌سازی آن‌قدر کند بود که مهندسان فرصت می‌کردند سوال بپرسند یا با بن‌بست مواجه شوند و ابهامات دستورالعمل محصول (Brief) به‌طور طبیعی برملا می‌شد. در آن زمان، حضور انسان در چرخه به‌اندازه‌ای کند بود که فرصت اصلاح خطاها پیش از ثبت نهایی کد وجود داشت. اما امروز، این تأخیر انسانی کاملاً ناپدید شده است.

تصور کنید یک مهندس دوشنبه صبح روی یک تسک کار می‌کند. دوشنبه عصر کد نوشته شده و سه‌شنبه بازبینی و ادغام می‌شود. چهارشنبه مدیر محصول در جلسه می‌پرسد واقعاً چه چیزی منتشر شده است، چون توصیف کد با هدف اولیه همخوانی ندارد. ویژگی به‌درستی کار می‌کند و تست‌ها پاس می‌شوند، اما این آن چیزی نیست که طراح مشخص کرده بود یا مدیر محصول مد نظر داشت.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن دیدیم، سرعت بالای مدل‌ها بدون نظارت دقیق می‌تواند منجر به نتایج غیرمنتظره شود. وقتی زمان پیاده‌سازی به چند ساعت کاهش می‌یابد، بازبینی‌های سنتی یا به گلوگاهی تبدیل می‌شوند که سرعت هوش مصنوعی را می‌کشد، یا به کالبدشکافی تبدیل می‌شوند که پس از انتشار کد رخ می‌دهد. اگر نقاط بازرسی بگذارید، سرعت را به سطح انسانی برمی‌گردانید و سود هوش مصنوعی را از دست می‌دهید؛ اگر آن‌ها را حذف کنید، سریع پیش می‌روید اما بدون توافق بر سر خروجی.

برای حل این مشکل، تیم‌ها در حال پذیرش «توسعهٔ مشخصه‌محور» (Spec-driven development) هستند. در این رویکرد، تفاوت میان «دستورالعمل» و «مشخصه» تعریف می‌شود:

• دستورالعمل (Brief): بیانی از هدف (چه چیزی و چرا) که برای مخاطب محصولی نوشته شده است. این سند معمولاً در جزئیات پیاده‌سازی، شرایط مرزی و موارد استثنایی که به عامل هوش مصنوعی می‌گوید کجا متوقف شود، دچار نقص است.
• مشخصه (Spec): هدف اجرایی. سندی concrete که دقیقاً تعریف می‌کند «پایان کار» چه شکلی است، سیستم چه کارهایی را نباید انجام دهد و مرزهای ویژگی چیست. مشخصه در واقع ترجمهٔ دستورالعمل به چیزی است که تنها یک تفسیر منطقی دارد.

به نقل از تحلیل dev.to، راهکار این است که گفتگوهای هم‌سویی را به مرحلهٔ «پیش از ساخت» منتقل کنیم. شکست در هماهنگی زمانی رخ می‌دهد که مدیر محصول فکر می‌کند چون دستورالعمل داده شده، گفتگو تمام شده است و مهندس فکر می‌کند چون دستورالعمل واضح به نظر می‌رسید، نیازی به پرسش نیست. در این میان، هوش مصنوعی با اعتمادبه‌نفس کامل، بر اساس هر چه به او داده شده می‌سازد.

برای پل زدن بر این شکاف، مشخصه باید یک دستاورد تیمی باشد — نه پرامپتی که یک نفر می‌نویسد یا سندی که در یک ویرایشگر شخصی می‌ماند. این باید سندی مشترک باشد که هر کسی در نتیجهٔ کار سهم دارد، پیش از ایجاد هر خط کد، آن را بخواند و تأیید کند.

این تغییر، نقش‌های بنیادی در یک تیم فنی را عوض می‌کند:

• مدیران محصول: به‌جای نوشتن دستورالعمل و انتظار برای بازبینی کد، فعالانه در تدوین مشخصه شرکت می‌کنند و شرایط را تعیین می‌کنند.
• طراحان: به‌جای بازبینی خروجی پس از اتمام کار، نتایج مورد انتظار را از ابتدا شکل می‌دهند.
• مهندسان ارشد: محدودیت‌های معماری دیگر در مرحله بازبینی کشف نمی‌شوند؛ بلکه پیش از شروع ساخت، به‌عنوان مرزها در مشخصه نوشته می‌شوند.

تنها پس از این تأیید جمعی — جایی که طراح نتایج را می‌نویسد، مدیر محصول شرایط را تعیین می‌کند و مهندس ارشد مرزها را می‌کشد — مشخصه به‌عنوان ورودی اصلی به عامل هوش مصنوعی داده می‌شود.

این متدولوژی هستهٔ اصلی Penling است؛ فضای کاری مشترکی که برای تسهیل این هم‌سویی پیش از ساخت طراحی شده است. Penling به تیم‌ها اجازه می‌دهد مشخصه را با هم بنویسند و مستقیماً از طریق پروتکل زمینه مدل (Model Context Protocol یا MCP) به عامل‌های کدنویس منتقل کنند تا مطمئن شوند کد نهایی بازتابی از یک اجماع قبلی است. در نهایت، این مشخصه همراه با کد در مخزن (Repository) ثبت می‌شود.

برای شما این بدان معناست که «سرعت» هوش مصنوعی دیگر به این نیست که عامل با چه سرعتی تایپ می‌کند، بلکه به این بستگی دارد که تیم با چه سرعتی هم‌سو می‌شود. با سرمایه‌گذاری روی یک مشخصه صلب، تیم‌ها در واقع سرعت خود را افزایش می‌دهند چون دیگر روزها وقت خود را صرف باز کردن گره‌های فرضیاتی نمی‌کنند که یک هوش مصنوعی مطمئن اما اشتباه، ایجاد کرده است.

گام بعدی شما

• بررسی کنید آیا در تیم شما «دستورالعمل» (Brief) با «مشخصه اجرایی» (Spec) اشتباه گرفته می‌شود یا خیر.
• برای تسک‌های پیچیده، یک جلسه «تأیید مرزها» قبل از دادن دستور به AI برگزار کنید.
• با پروتکل MCP آشنا شوید تا بتوانید مستندات تیم را به‌طور ساختاریافته به مدل‌ها تزریق کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.