تصور کنید برنامه‌نویسی هستید که هر روز ده‌ها تغییر در کد یک سیستم پیچیده اعمال می‌کند و حالا یک دستیار هوشمند، نیمی از این مسیر را برای شما می‌رود. باید بدانید یک «تخفیف نامرئی» در حال شکل‌گیری است که تیم‌های مهندسی را به خطر می‌اندازد. در تیم‌های نرم‌افزاری سنتی، کدی که توسط دو انسان نوشته شده معمولاً بازبینی ساده‌تری می‌پذیرد؛ چرا که بررسی هم‌تا (Peer-review) در لحظه خلق کد و به‌صورت آنی رخ داده است. این یک سیاست مکتوب نیست؛ هیچ‌کس برای آن رای نداده و در هیچ سند سیاستی ثبت نشده است. با این حال، وقتی یک درخواست ادغام (PR) از دو نفری می‌رسد که با هم کد زده و آن را تست کرده‌اند، بازبین‌ها به آن کد اعتماد بیشتری می‌کنند. در نتیجه، مشکلات کمتری در مرحله بازبینی یافت می‌شود و باگ‌های کمتری به مراحل بعدی سرایت می‌کنند. این وضعیت یک چرخه ایجاد می‌کند که در آن، بازبینی‌های سبک‌تر، تصمیمی درست به نظر می‌رسد و به تدریج تثبیت می‌شود. اکنون، همین تخفیف اعتماد به‌طور اشتباه به عامل‌های هوش مصنوعی (AI Agents) — ابزارهایی شبیه به دستیاران هوشمند که می‌توانند به‌طور مستقل کد بزنند — تعمیم داده شده است.
همان‌طور که در تحلیل قبلی ما درباره‌ی شکاف بازبینی در ابزارهای کدنویسی AI اشاره کردیم، این پدیده یک ریسک خاموش ایجاد می‌کند. در حالی که همکاری با یک انسان، تخفیف اعتماد می‌آورد، همکاری با یک عامل AI چنین اعتباری ندارد. مشکل اصلی این است که تیم‌ها ترکیب «برنامه‌نویس + عامل» را مانند یک «جفت‌برنامه‌نویسی» (Pair Programming) می‌بینند و اجازه می‌دهند دسته‌ای از کارها، قاعده‌ای را جذب کنند که هرگز لیاقت کسب آن را نداشته‌اند.
زمینه و تاریخچه تخفیف جفت-برنامه‌نویسی
جفت‌برنامه‌نویسی انسانی سابقه مستندی در ارتقای کیفیت دارد. این تخفیف اعتماد از طریق تاریخچه‌ای ثابت از نتایج مثبت به دست آمده است. پژوهشگران مدت‌هاست که این شیوه را مطالعه کرده‌اند و یافته‌اند که هرچول نتایج آن کمتر از ادعاهای بازاریابی «معجزه‌آسا» است، اما کاملاً قابل‌اتکا است.
نکته کلیدی این است که این تخفیف هرگز یک معامله یکسانی برای همه نبود. در اینجا یک سلسله‌مراتب اعتماد وجود دارد: برای مثال، دو برنامه‌نویس تازه‌کار (Junior) اگر با هم جفت‌برنامه‌نویسی کنند، معمولاً کدی بهتر از آنچه هر کدام به تنهایی می‌نوشتند تولید می‌کنند، اما کیفیت کار آن‌ها هنوز به سطح کدی نمی‌رسد که در آن یک برنامه‌نویس ارشد (Senior) بخشی از جفت باشد. بنابراین، این میان‌بر هیچ‌گاه یک قانون تختِ «جفت‌برنامه‌نویسی یعنی بازبینی سبک‌تر» نبود، بلکه بیشتر شبیه به این بود: «این جفت خاص، هنگام کار بر روی این تسک خاص، تخفیف بازبینی را به دست آورده است».
جزئیات پژوهش‌ها و تضاد با AI
به نقل از مطالعه‌ای که در سال ۲۰۰۰ توسط کاک‌برن و ویلیامز (Cockburn and Williams) انجام شد، جفت‌برنامه‌نویسی یک موازنه مشخص میان منابع و کیفیت ایجاد می‌کند:
- زمان توسعه: جفت‌برنامه‌نویسی تقریباً ۱۵٪ زمان بیشتری هزینه می‌کند.
- کاهش نقص: در مقابل، این روش باعث کاهش تقریبی ۱۵ درصدی نقص‌ها (Defects) می‌شود.
- بهبودهای سیستماتیک: بهبودهای آماری معناداری در کیفیت طراحی، مهارت‌های فنی و ارتباطات تیمی مشاهده شده است.
- تاب‌آوری: دانش دیگر در ذهن یک نفر محبوس نمی‌شود و با پخش شدن آن در تیم، تاب‌آوری سازمان در برابر خروج کارکنان افزایش می‌یابد.
علاوه بر این، شواهد حاصل از یک متاآنالیز در سال ۲۰۰۹ توسط هانی، دیب، آریشولم و شوبِرگ (Hannay, Dybå, Arisholm, and Sjøberg) دیدگاه دقیق‌تری ارائه می‌دهد:
- مدت زمان: یک اثر مثبت متوسط مشاهده شد، به این معنی که جفت‌ها اغلب کارهای خود را سریع‌تر (از نظر ساعت دیواری) به پایان می‌رسانند.
- تلاش: یک اثر منفی متوسط دیده شد، زیرا مجموع نفر-ساعت‌های مصرف‌شده بیشتر است.
- پیچیدگی: اثر این روش بسته به دشواری کار تغییر می‌کند؛ جفت‌ها زمانی که کار ساده است سریع‌تر هستند و زمانی که کار سخت است، کیفیت بالاتری تولید می‌کنند.
- کیفیت: در مجموع، یک اثر مثبت کوچک بر کیفیت کلی کد مشاهده شد.
باید به چند نکته احتیاطی توجه کرد. هیچ‌کدام از این دو مطالعه به‌طور مشخص «بازبینی کد» را اندازه‌گیری نکردند؛ استنتاج ما مبنی بر اینکه بازبینی‌ها کوتاه‌تر می‌شوند، بر اساس این واقعیت است که نقص‌های کمتری در مرحله نهایی ظاهر می‌شوند. همچنین، نویسندگان متاآنالیز به نشانه‌هایی از «سوگیری انتشار» (Publication Bias) در ادبیات پژوهشی اشاره کردند، به این معنی که این اعداد را نباید کاملاً قطعی و تثبیت‌شده دانست.
در مقابل، کدهای تولیدشده توسط AI فاقد این رکورد سیستماتیک اعتماد هستند. عامل‌های AI به‌کرات حفره‌های امنیتی و باگ‌های فانکشنال ایجاد می‌کنند. بحرانی‌تر آنکه، یک عامل نمی‌تواند به برنامه‌نویس کمک کند تا مدل ذهنی (Mental Model) از سیستم را حفظ کند. مدل ذهنی همان نقشه‌ای است که برنامه‌نویس از کل ساختار در ذهن دارد. با افزایش حجم کد تولیدی توسط AI، برنامه‌نویس‌ها ممکن است درک خود را از همان سیستمی که وظیفه تعمیرش را دارند، از دست بدهند و این امر تعمیر سیستم‌ها را در طول زمان دشوارتر می‌کند.
هزینه ارزیابی با هزینه تولید کاهش نیافته است. تولید کد ارزان شد، اما ارزیابی آن ارزان نشد. در حال حاضر هیچ عاملی وجود ندارد که سرعت خواندن کد را بالا ببرد، نگه داشتن مدل سیستم در ذهن را آسان کند یا تشخیص یک فرض غلط را سریع‌تر نماید — فارغ از اینکه آن عامل با چه اطمینانی صحبت کند. این وضعیت یک «اثر قیچی» (Scissors Effect) ایجاد کرده است: حجم کد در حال افزایش است، اما میزان دقت و بررسی در هر خط، به‌دلیل دسته‌بندی اشتباه در گروه «کدهای جفت‌برنامه‌نویسی»، در حال کاهش است.
این یک تصمیم مدیریتی در جلسات هیئت‌مدیره نیست، بلکه یک «لغزش فرهنگی» (Cultural Drift) است. این اتفاق زمانی رخ می‌دهد که دسته‌ای که از قبل داشتید (جفت‌برنامه‌نویسی)، به‌آرامی نوع جدیدی از کار (همکاری با AI) را می‌بلعد و قوانینی که به آن دسته چسبیده بود، همراه آن منتقل می‌شود.
اکثر تیم‌ها میان‌برهای بازبینی خود را به ارث برده‌اند. چه میان‌بر «این فقط یک تغییر در کانفیگ است» باشد یا میان‌بر «PRهای این شخص همیشه تمیز هستند»، این قوانین نانوشته اغلب از تیم‌هایی منتقل شده‌اند که برنامه‌نویس دیگر حتی عضو آن‌ها نیست. وقتی یک عامل AI در همان دسته جفت‌برنامه‌نویسی انسانی قرار می‌گیرد، تخفیف اعتماد بدون اینکه کسی صریحاً تصمیم بگیرد، منتقل می‌شود. هزینه این خطا بر دوش برنامه‌نویس نیست، بلکه دیرتر بر دوش کسب‌وکار، مشتریان و کاربران نهایی می‌افتد.
برای جلوگیری از این وضعیت، تیم‌ها باید میان‌برهای نانوشته بازبینی خود را حسابرسی (Audit) کنند. شما باید شناسایی کنید کدام دسته‌های تغییرات در حال حاضر «پاس» می‌گیرند و بپرسید آیا آن چیزی که باعث کسب این تخفیف شده بود، هنوز برای کدی که امروز ادغام می‌کنید صادق است یا خیر. اگر عامل AI در واقع بررسی‌های سیستماتیک یک هم‌تای انسانی را فراهم نکرد، این تخفیف باید لغو شود. در واقع، برای مدیریت درست این حجم از کد، شاید لازم باشد نگاه خود را از بازبینی خط‌به‌خط به سمت مدل‌های جدید مسئولیت‌پذیری تغییر دهیم تا از خستگی ذهنی برنامه‌نویسان کاسته شود.
گام بعدی شما
- بازبینی‌های اخیر خود را بررسی کنید و ببینید آیا برای کدهای AI، همان استانداردی را به کار برده‌اید که برای کدهای انسانی به کار می‌برید؟
- فهرست «میان‌برهای بازبینی» (Review Shortcuts) تیم خود را شناسایی و به‌روزرسانی کنید تا مشخص شود کدام دسته‌ها دیگر تخفیف اعتماد ندارند.
- اطمینان حاصل کنید که برنامه‌نویسان، کد تولیدشده توسط AI را خط‌به‌خط بازخوانی می‌کنند تا مدل ذهنی آن‌ها از سیستم تخریب نشود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو