سرعت خروجی در برابر کیفیت تحلیل؛ تضاد ابزارهای هوش مصنوعی در مهندسی

اگر امروز کدهای شما سریع‌تر از هر زمان دیگری تأیید و منتشر می‌شوند، ممکن است دقیقاً در حال تخریب یکی از حیاتی‌ترین دارایی‌های تیم خود باشید: قضاوت فنی.

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

طبق گزارشی که در ۱ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، یک تیم مهندسی با عملکرد بالا متوجه شد که ابزارهای کدنویسی با هوش مصنوعی، نوعی «توهم صلاحیت» ایجاد می‌کنند. در ابتدا، داشبوردها تصویر خوش‌بینانه‌ای می‌دادند. تیم به‌سرعت کدنویسی با کمک هوش مصنوعی را پذیرفت و متریک‌ها دقیقاً همان چیزی را نشان می‌دادند که صنعت وعده داده بود: تعداد درخواست‌های ادغام (PR) در حال حرکت بود، اندازه تیم ثابت ماند و میزان تأخیرها (Drag) به‌طور قابل‌توجهی کاهش یافت. اما این موفقیت ظاهری، آسیب‌پذیری رو به رشدی را در بدنه کد و مهارت‌های تیم پنهان کرده بود. این تغییر در اولویت‌ها از سرعت خالص به سمت پایداری، یادآور تحولی است که در گزارش توسعه ما درباره جایگزینی حاکمیت داده‌ها با سرعت کدنویسی به آن پرداختیم.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بیش از حد به خروجی‌های خودکار بدون درک عمیق سازوکار، ریسک‌های پنهانی را به همراه دارد. در این مورد، مشکل از یک شکست باشکوه شروع نشد، بلکه یک زوال آرام بود. تیم تغییراتی را اعمال کرد که تمام تست‌ها را پاس کرد، بازبینی‌ها را رد کرد و به‌طور پاکیزه‌ای منتشر شد؛ اما دو هفته بعد مشخص شد که این تغییرات، مسیرهای تکرار (Retry Path) را در شرایط فشار شدید سیستم — که در محیط‌های تست آن‌ها شبیه‌سازی نشده بود — تخریب کرده است.

وقتی از مهندس مربوطه سؤال شد تا روند تغییرات را شرح دهد، او توانست توضیح دهد هر بخش از کد چه کاری انجام می‌دهد. اما وقتی پرسیده شد «اگر سرویس پایین‌دست به جای قطع شدن، صرفاً کند شود چه اتفاقی می‌افتد؟»، مکث کرد و سکوت کرد. هوش مصنوعی زاینده (Generative AI) — مثل دستیاری که سریع‌ترین پاسخ‌ها را می‌دهد اما دلیل انتخاب آن‌ها را نمی‌داند — کد مدیریت خطا و تست‌های آن را نوشته بود و چون تست‌ها پاس شده بودند، مهندس هرگز نیاز پیدا نکرد تا پیش از انتشار، یک سؤال معماری حیاتی بپرسد.

این اتفاق به این دلیل رخ می‌دهد که AI «اصطکاک» یا همان چالش‌های سازنده را حذف می‌کند. در مهندسی نرم‌افزار سنتی، برنامه‌نویسان شهود خود را با ساعت‌ها عیب‌یابی (Debugging) در ساعت ۱۱ شب و تعقیب سه باره‌ی تئوری‌های اشتباه می‌سازند. این فرآیند است که غریزه سیستمی لازم برای تشخیص کدهای «به ظاهر فعال اما در فشار، ناامن» را ایجاد می‌کند.

بر اساس مستندات این گزارش، زمانی که پیش‌نویس اول کد رایگان می‌شود و AI جایگزین مراحل اولیه یادگیری می‌گردد، سه شکاف فنی مشخص ایجاد می‌شود:

• شکاف بازبینی (Review Gap): اکنون یک مهندس می‌تواند حجم PRهایی را تولید کند که قبلاً نیاز به چندین نفر داشت. این موضوع بازبین‌ها را بیش از حد تحت فشار می‌گذارد و باعث می‌شود آن‌ها کدها را سریع‌تر بخوانند. اگر تست‌ها پاس شوند، کد تأیید می‌شود، حتی اگر تست‌ها کاملاً از حالت‌های واقعی شکست جدا باشند. این وضعیت ظاهری از سخت‌گیری ایجاد می‌کند، بدون اینکه سخت‌گیری واقعی وجود داشته باشد.
• شکاف عیب‌یابی (Debugging Gap): وقتی هر خطایی را می‌توان در یک پنجره چت قرار داد و در ۳۰ ثانیه به یک اصلاح plausible (پذیرفتنی) تبدیل کرد، مهندسان دیگر نمی‌پرسند «چرا» این اتفاق افتاد. علامت بیماری وصله می‌شود، اما درس یاد گرفته نمی‌شود. در نتیجه، وقتی شکست مشابهی با شکلی متفاوت ظاهر می‌شود، تیم زمان بیشتری برای حل آن نیاز دارد چون از مورد اول درس نگرفته‌اند.
• شکاف حادثه (Incident Gap): مهندسان ممکن است ماه‌ها PRهای سالمی را با تحویل سریع منتشر کنند، اما در اولین بحران واقعی در محیط عملیاتی (Production) درمانده شوند. بدون صرف زمان کافی در یک سیستم شکسته، آن‌ها فاقد «تکرارهای» (reps) لازم برای محدود کردن دایره احتمالات هستند، به‌ویژه زمانی که پاسخ بدیهی نباشد.

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

آنچه واقعاً اثر کرد، تغییر هدف بنیادین بازبینی کد بود. آن‌ها بازبینی را از یک «دروازه کنترل کیفیت» ساده به مکانی تبدیل کردند که در آن افراد باید «تفکر» خود را نشان دهند. اکنون توسعه‌دهندگان به جای توصیف صرفِ کاری که کد انجام می‌دهد، باید جزئیات زیر را شرح دهند:

• چه فرض‌هایی درباره سیستم داشته‌اند.
• کدام بخش احتمالاً زودتر از همه شکست می‌خورد.
• آگاهانه تصمیم گرفته‌اند چه مواردی را مدیریت نکنند.

علاوه بر این، برای بخش‌های با تأثیر بالا (High-impact)، مهندسان اکنون موظف‌اند یک پاراگراف کوتاه در توضیحات PR اضافه کنند که مشخصاً به این سؤال پاسخ دهد: «چه چیزی ممکن است در اینجا اشتباه پیش رود؟»

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

• مانورهای عیب‌یابی (Debugging drills): تمرینات متمرکز برای مهارت در جداسازی خطاها.
• کالبدشکافی حوادث (Postmortem walkthroughs): بررسی‌های عمیق در مورد نحوه شکست سیستم‌ها.
• سایه زنی حادثه (Incident shadowing): وارد کردن مهندسان جونیور به حوادث زنده، زودتر از زمانی که معمولاً راحت به نظر می‌رسد.

این مداخلات دستی تلاش می‌کنند شهودی را بازسازی کنند که ابزارهای AI به‌طور ناخواسته پاک می‌کنند تا سرعت تیم دوباره قابل اعتماد شود.

این وضعیت یک پارادوکس را در عصر هوش مصنوعی نشان می‌دهد: هرچه هزینه تولید پیش‌نویس اول (First Draft) به صفر نزدیک‌تر شود، ارزش قضاوت خبره افزایش می‌یابد. AI می‌تواند مفید باشد — مثلاً با کاهش شرم از ندانستن و اجازه دادن به افراد برای تلاش در کارهایی که قبلاً جرئت نمی‌کردند — اما نمی‌تواند جایگزین درکی شود که فقط هنگام تحلیل لاگ‌های مبهم و در لحظاتی که سیستم در حال فروپاشی است، به دست می‌آید.

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

باید ارزیابی کنید که آیا سرعت (Velocity) تیم شما ناشی از افزایش توانمندی است یا صرفاً خروجی سریع‌تر. اگر توسعه‌دهندگان شما می‌توانند توضیح دهند AI «چه» نوشته اما نمی‌توانند پیش‌بینی کنند «چگونه» شکست می‌خورد، شما در حال انباشت یک نوع بدهی فنی روشنفکری (Intellectual Technical Debt) هستید.

به دنبال متریک‌های نوظهوری باشید که به جای سرعت PR، «درک عمیق» را اندازه‌گیری می‌کنند؛ زیرا صنعت در حال کلنجار رفتن با quantifying (کمی‌سازی) فقدان مهارت‌های مهندسی شهودی است.

گام بعدی شما

• بازبینی‌های کد (Code Review) را از حالت تأیید/رد به حالت «توضیح استدلال» تغییر دهید.
• برای PRهای حساس، بخش اجباری «سناریوهای شکست» را اضافه کنید.
• جلسات ماهانه کالبدشکافی حوادث (Postmortem) را برای مهندسان جونیور به یک کارگاه آموزشی تبدیل کنید.

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