یک درخواست ادغام (Pull Request) که از نظر فنی بی‌نقص است، می‌تواند یک دروغ بزرگ باشد. اگر شما مدیر محصول یا توسعه‌دهنده‌ای هستید که اکنون از عامل‌های هوش مصنوعی برای کدنویسی استفاده می‌کنید، باید بدانید که سرعت خیره‌کنندهٔ این ابزارها در حال حذف کردن «اصطکاک‌های لازم» برای تفکر است.
به گزارش dev.to در ۳۰ سپتامبر ۲۰۲۶، پارادوکس عجیبی در توسعهٔ نرم‌افزار شکل گرفته است: عامل‌های هوش مصنوعی (AI Agents) — شبیه دستیارهای فوق‌سریع اما بدون‌تجربه‌ای که دستورات را کورکورانه اجرا می‌کنند — اکنون چنان در پیاده‌سازی تیکت‌ها کارآمد شده‌اند که مرحلهٔ انسانیِ تصمیم‌گیری دربارهٔ محصول را دور می‌زنند.
در گردش‌کار سنتی، یک تیکت مبهم باعث ایجاد اصطکاک می‌شد. توسعه‌دهنده با مدل داده‌ها به مشکل می‌خورد یا سؤالات شفاف‌کننده‌ای می‌پرسید و همین موضوع به مدیر محصول سیگنال می‌داد که یک تصمیم تجاری هنوز اتخاذ نشده است. اما هوش مصنوعی این وقفه را حذف می‌کند و یک پیشنهاد مبهم را در عرض چند ساعت به یک ویژگی کامل تبدیل می‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، حذف لایه‌های نظارتی انسانی همیشه با ریسک‌های پیش‌بینی‌نشده همراه است. این موضوع در واقع ادامهٔ همان چالشی است که در آن تولید سریع‌تر کد توسط عامل‌ها، گلوگاه‌های بازبینی را عمیق‌تر کرد و فشار را بر لایه‌های نظارتی افزایش داد.
تلهٔ «تفسیر طبیعی»
تصور کنید مدیر محصول پیشنهاد دهد کاربرانی که فرآیند ثبت‌نام (Onboarding) را رها کرده‌اند، باید از همان‌جایی که متوقف شده‌اند بازگردند. یک عامل هوش مصنوعی سریعاً این جمله را به یک تیکت فنی تبدیل می‌کند؛ شامل نقاط انتهایی API، مهاجرت‌های پایگاه‌داده و منطق فرانت‌اند. کد خروجی تمیز است، خوانایی بالایی دارد و تمام تست‌ها را پاس می‌کند.
اما عبارت «نمایش مرحله بعدی»، یک نیاز فنی نیست، بلکه یک تصمیم محصول است. هوش مصنوعی «طبیعی‌ترین تفسیر» متن را پیاده می‌کند، اما این تفسیر ممکن است برای کسب‌وکار غلط باشد. این پدیده نمونه‌ای از منطق‌های متقاعدکننده اما غلط است که باعث می‌شود کد در ظاهر درست به نظر برسد اما در عمل نیازهای تجاری را نادیده بگیرد. برای مثال:
- اگر قوانین ثبت‌نام در مدتی که کاربر غایب بود تغییر کرده باشد چه می‌شود؟
- آیا کاربر باید به دلیل مسائل قانونی (Compliance)، پس از دو هفته بازگشت، دوباره از ابتدا شروع کند؟
- آیا تغییر کشور کاربر، پیشرفت‌های قبلی او را باطل می‌کند؟
فرسایش سیگنال‌های هشدار
از آنجا که هوش مصنوعی کارهای مکانیکی — مثل جمع‌آوری زمینه، پیشنهاد ساختار و نوشتن تست‌ها — را بر عهده می‌گیرد، تیم‌ها «سیگنال‌های هشدار» مربوط به الزامات ناقص را از دست می‌دهند. وقتی یک PR در عرض چند ساعت آماده می‌شود، توهم پیشرفت ایجاد می‌کند. برای یک لید فنی دشوار است که ادغام کدی را که از نظر فنی بی‌نقص است، صرفاً بر اساس یک سؤال تئوریک درباره محصول متوقف کند.
معیارهای پذیرش (Acceptance Criteria) که توسط هوش مصنوعی تولید می‌شوند، این تله را تقویت می‌کنند. مدل یک تست می‌نویسد تا مطمئن شود کاربر در مرحله ۳، پس از بازگشت، مرحله ۴ را می‌بیند. این یک تست فنی معتبر است، اما نمی‌تواند تأیید کند که آیا کاربر «باید» مرحله ۴ را ببیند یا خیر. تست‌های فنی نمی‌توانند به سؤالات تجاری پاسخ دهند.
تغییر نقش توسعه‌دهنده
بر اساس تحلیل dev.to، سؤال اصلی برای توسعه‌دهندگان در حال تغییر است. دیگر بحث بر سر این نیست که «چگونه این را پیاده کنم؟»، بلکه سؤال این است: «در حال حاضر چه تصمیمی را به‌طور خاموش در کد جای‌گذاری می‌کنیم؟»
برای مقابله با این وضعیت، نویسنده پیشنهاد می‌کند که فرآیند توسعه باید «حق توقف» داشته باشد. به‌جای تکیه بر پرامپت‌هایی مثل «فرض نکن» — که اغلب در تاریخچه‌های طولانی گفتگو گم می‌شوند — تیم‌ها به ردیابی صریح تصمیمات نیاز دارند. این یعنی یک ویژگی باید تا زمان حل سؤال منطق تجاری توسط مالک محصول، در وضعیت «مسدود» (Blocked) باقی بماند، حتی اگر کد آن تمام شده باشد.
این نیاز به ردیابی صریح، محرک اصلی خلق ابزاری مثل Ordo است؛ ابزاری که طراحی شده تا سؤالات مهم محصول بین یک پرامپت و یک PR گم نشوند. با جداسازی وضعیت تصمیم از وضعیت پیاده‌سازی، تیم‌ها می‌توانند جلوی تصمیم‌گیری‌های تصادفی هوش مصنوعی درباره رفتار محصول را بگیرند.
برای توسعه‌دهنده مدرن، ریسک دیگر کد بد نیست، بلکه کد سریع است که در جهت اشتباه حرکت می‌کند. هدف این نیست که مدیر محصول را با هوش مصنوعی جایگزین کنیم، بلکه باید مطمئن شویم سرعت هوش مصنوعی، فقدان جهت‌گیری را نمی‌پوشاند.
گام بعدی شما
- در تیکت‌های خود، بخش «تصمیمات تجاری باز» را جدا از «نیازمندی‌های فنی» تعریف کنید.
- برای PRهای تولید شده توسط AI، یک مرحله بازبینی «منطق محصول» اضافه کنید که مستقل از بازبینی کد (Code Review) باشد.
- از ابزارهایی برای ردیابی وضعیت تصمیمات (Decision Tracking) استفاده کنید تا کد سریع، جایگزین تفکر استراتژیک نشود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو