تصور کنید برنامه‌نویسی هستید که هر روز با صدها خط کدِ تولیدشده توسط هوش مصنوعی مواجه می‌شوید که باید تایید کنید؛ در این وضعیت، شما دیگر یک توسعه‌دهنده نیستید، بلکه تبدیل به یک «گلوگاه» انسانی شده‌اید. اگر هنوز بر اساس مدل سنتی Pull Request (PR) کار می‌کنید، باید بدانید که سرعت تولید کد توسط عامل‌ها، سیستم نظارتی شما را در حال فروپاشی است.
به نقل از یک مهندس ارشد در شرکت Thoughtworks، مدل‌های سنتی بررسی کد در برابر هجوم کدهای تولیدشده توسط عامل‌های هوش مصنوعی (AI Agents) — ابزارهایی که مثل دستیاران هوشمند، می‌توانند به‌طور مستقل برنامه‌ریزی و کدنویسی کنند — به یک مانع بحرانی تبدیل شده‌اند. در ۲ سپتامبر ۲۰۲۶، بحث‌های شدیدی در این باره شکل گرفت که آیا صنعت نرم‌افزار صرفاً در حال اتوماتیک کردن یک «مراسم توخالی» است یا واقعاً در حال اصلاح فرآیند توسعه است.
این بحث‌ها از پنلی در Code Remix، به میزبانی Moderne، آغاز شد. در این گفتگو، مهندس Thoughtworks و برایان هوک از شرکت DX حضور داشتند. در حالی که هر دو بر سر اهداف نهایی کیفیت نرم‌افزار اتفاق نظر داشتند، اما در مورد مکانیسم دستیابی به آن اختلاف نظر داشتند. برایان هوک در مقاله خود با عنوان «بررسی کد اصلاً برای چیست؟» بر ضرورت فرآیند بررسی کد پافشاری کرد، اما مهندس Thoughtworks استدلال کرد که PR ابزار اشتباهی برای این هدف است. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اتکای بیش از حد به ابزارهای نظارتی پسینی، ریسک‌های سیستمی را کاهش نمی‌دهد، بلکه فقط آن‌ها را جابه‌جا می‌کند. این چالش زمانی پیچیده‌تر می‌شود که رانش خاموش مدل‌های AI باعث کاهش نرخ تشخیص باگ‌ها در مراحل نظارتی شود و اعتماد تیم‌ها به ابزارهای خودکار را متزلزل کند.
برای دهه‌ها، بررسی کد مثل یک «چاقوی سوئیسی» برای تیم‌های مهندسی بود؛ ابزاری برای امنیت، آموزش نیروهای تازه‌کار و همراستاسازی معماری. این سیستم زمانی جواب می‌داد که انسان‌ها با سرعتی خطی کد می‌نوشتند، اما حالا ریاضیات بازی تغییر کرده است. تصور کنید ویژگی‌ای که پیش از این نوشتن آن یک هفته زمان می‌برد، اکنون در عرض چند دقیقه ظاهر می‌شود. اگرچه این موضوع در ظاهر یک پیروزی در بهره‌وری به نظر می‌رسد، اما تعادلی خطرناک ایجاد می‌کند: ما اکنون می‌توانیم پیاده‌سازی‌ها را بسیار سریع‌تر از آنکه بتوانیم به‌درستی درک کنیم، تولید کنیم.
بحران مقیاس‌پذیری
طبق گزارش‌های منتشر شده در سایت مارتین فاولر، داده‌های شرکت Meta و DX ابعاد این بحران را نشان می‌دهد. میزان خطوط کد معنادار در هر تغییر (diff) که توسط انسان‌ها در Meta تایید شده، در یک سال ۱۰۶٪ افزایش یافته است. هم‌زمان، داده‌های DX نشان می‌دهد که اندازه میانهٔ Pull Requestها ۶۴٪ رشد کرده است.
اگر یک عامل هوش مصنوعی ۱۰ برابر بیشتر کد تولید کند، اما هر خط همچنان منتظر تایید یک مهندس ارشد باشد، سازمان مقیاس‌پذیر نشده است؛ بلکه فقط صف انتظار طولانی‌تر و گلوگاه شدیدتری ساخته است. نویسنده هشدار می‌دهد که استفاده از یک عامل هوش مصنوعی برای اینکه «تظاهر کند» یک بررسی‌کننده انسانی است، صرفاً اتوماتیک کردن یک مراسم است، نه پرسش در مورد اینکه چرا این مراسم از اساس وجود دارد.
انتقال قضاوت به مراحل ابتدایی
برای حل این مشکل، صنعت باید حلقه‌های بازخورد را به نقطه تصمیم‌گیری نزدیک کند. هدف این است که PR دیگر مرکز چرخه توسعه نباشد. نویسنده از تجربه شخصی خود می‌گوید: ساختن، تکمیل کردن و بسته‌بندی یک محصول و سپس پرتاب آن به پشت یک دیوار برای اینکه تازه در پایان کار، مهم‌ترین گفتگوها را درباره اینکه آیا رویکرد درستی داشتیم یا خیر انجام دهیم، یک اتلاف انرژی است. این تاخیر حتی منجر به درگیری‌های کد (merge conflicts) و کاهش شدید بهره‌وری می‌شود.
تیم‌ها می‌توانند با کوتاه‌تر کردن حلقه‌های بازخورد، قضاوت را به لحظه تصمیم منتقل کنند:
- انتقال دانش: به‌جای خواندن یک راهکار تکمیل‌شده، مهندسان باید از برنامه‌نویسی دونفره (Pair Programming) استفاده کنند. نشستن کنار یک همکار، به‌صورت فیزیکی یا مجازی، در حالی که او در حال استدلال روی یک مسئله است، بسیار آموزنده‌تر از بررسی یک diff است.
- منتورینگ تازه‌کارها: توسعه‌دهندگان جونیور باید در مرحله «تفکر» با مهندسان ارشد همکاری کنند. این کار به آن‌ها اجازه می‌دهد ببینند مهندسان باتجربه در لحظه چگونه فکر می‌کنند، نه اینکه فقط نتیجه نهایی را بخوانند.
- همراستاسازی معماری: تیم‌ها باید پیش از دستور دادن به عامل برای نوشتن حتی یک خط کد، جلسات طراحی جمعی با تخته‌سفید برگزار کنند. این کار تضمین می‌کند که پیش از شروع پیاده‌سازی، همراستایی کامل وجود داشته باشد.
- مالکیت جمعی: سازماندهی تیم‌ها برای ساخت و بهره‌برداری مشترک از نرم‌افزار از طریق برنامه‌نویسی گروهی (Mob Programming) یا جلسات طراحی تیمی، به‌جای تکیه بر PR برای اطلاع‌رسانی تغییرات به دیگران.
اتوماسیون موارد قطعی
قضاوت انسانی منبعی کمیاب است و نباید برای مسائل پیش‌پاافتاده هدر رود. در سال ۲۰۲۶، بحث بر سر فاصله‌گذاری‌ها (whitespace) یا فرمت کد، اتلاف ساعت‌های مهندسی است. تیم‌ها باید هر چیزی را که به‌صورت قطعی قابل تست است، اتوماتیک کنند:
- فرمت‌بندی و Linting: حذف بررسی‌های دستی برای استایل کد و فاصله‌ها.
- اسکن امنیتی: اتوماتیک کردن شناسایی مشکلات امنیتی شناخته‌شده.
- تحلیل استاتیک: استفاده از ابزارها برای تایید خودکار الگوهای کد.
- توابع برازش (Fitness Functions): تبدیل محدودیت‌های معماری مهم به تست‌های اجرایی تا عامل هوش مصنوعی بدون نظارت دستی، در چارچوب‌های تعیین‌شده باقی بماند.
برنامه‌نویسی دونفره، توسعه مبتنی بر تنه (Trunk-based development) و تست‌های اتوماتیک، همگی بازخوردها را سریع‌تر می‌کنند. عامل‌های هوش مصنوعی اکنون می‌توانند با به چالش کشیدن طراحی‌ها، تست کردن فرض‌ها و تایید مداوم بیلد (build)، در این حلقه‌ها شرکت کنند، اما تفکر محوری باید در اختیار انسان‌های باتجربه بماند.
بررسی بر اساس استثنا
این به معنای پایان کامل بررسی‌های انسانی نیست، بلکه حرکت به سمت مدل «بررسی بر اساس استثنا» است. نظارت انسانی فقط برای تغییرات پرریسک لازم است، جایی که قضاوت انسانی واقعاً ارزشمند است، مانند:
۱. چرخش‌های بنیادی معماری: بررسی کد به صورت تیمی برای اطمینان از اجرای درست پس از یک جلسه طراحی.
۲. مرزهای حساس امنیتی: تغییراتی که محیط‌های امنیتی حیاتی و محیط‌های حساس را قطع می‌کنند.
۳. تغییرات با اثر گسترده (High blast radius): به‌روزرسانی‌هایی که پتانسیل تاثیرگذاری بر بخش عظیمی از سیستم را دارند.
۴. ناشناخته‌های حیاتی: تغییر در بخش‌های ناآشنا از یک سیستم حیاتی یا مناطقی که تیم صراحتاً می‌گوید: «من درباره این مورد اطمینان ندارم».
در گذشته، تیم‌ها هر تغییر را بررسی می‌کردند چون این مراسمی بود که برای ایجاد اعتماد به کار می‌رفت. اما وقتی هوش مصنوعی می‌تواند با نرخ نمایی کد تولید کند، این روش دیگر عملی نیست.
ریسک بدهی قصد (Intent Debt)
یک خطر پنهان در این گذار وجود دارد: بدهی شناختی و بدهی قصد. برایان هوک این موضوع را به عنوان یک نگرانی اصلی برجسته می‌کند؛ این ریسک که نرم‌افزار رشد کند، اما انسان‌های مسئول آن، کمتر و کمتر بفهمند که چرا سیستم به این شکل کار می‌کند. در همین راستا، بررسی تاریخچه تقابل جلسات طراحی در برابر بررسی Diffها نشان می‌دهد که چگونه جایگزینی جلسات تعاملی با بررسی‌های متنی می‌تواند منجر به انحراف در قصد اولیه توسعه‌دهنده شود.
PRهای اجباری دفاع ضعیفی در برابر این بدهی بودند، اما حذف کامل آن‌ها می‌تواند مشکل را تشدید کند. برای مقابله با این موضوع، تیم‌ها باید آگاهانه‌تر در حفظ درک انسانی عمل کنند:
- طراحی مشارکتی: درگیر شدن در تفکر مشترک پیش از کدنویسی.
- دونفره و گروهی کار کردن: اطمینان از اینکه چندین نفر منطق پیاده‌سازی را به‌طور کامل می‌فهمند.
- مرزهای شفاف: حفظ جداسازی‌های معماری تمیز و دقیق.
- معماری اجرایی: استفاده از کد برای تحمیل و اجرای طراحی مورد نظر.
- مسئولیت عملیاتی مشترک: اطمینان از اینکه تیمی که نرم‌افزار را می‌سازد، مسئولیت اداره و بهره‌برداری از آن را نیز بر عهده دارد.
مهندسان باید تکامل یابند تا «سیستم‌ها» را بفهمند، نه فقط «تغییرات کد» (diffs) را. بحران فعلی نشان می‌دهد که ما مسئولیت‌های زیادی (دروازه کیفیت، بررسی امنیتی، بازبینی معماری، مکانیسم منتورینگ و مدل مالکیت) را روی دوش یک بررسی کد ساده گذاشته بودیم. حالا که محدودیت سرعت تایپ انسان از بین رفته، این مراسم باید بمیرد تا فرآیند مهندسی نجات یابد.
گام بعدی شما
- تست مدل Review by Exception: در پروژه بعدی خود، فقط تغییرات با ریسک بالا را برای بررسی انسانی بفرستید و بقیه را به تست‌های اتوماتیک بسپارید.
- جایگزینی PR با Pair Programming: برای ویژگی‌های پیچیده، به‌جای ارسال PR، یک جلسه ۳۰ دقیقه‌ای برنامه‌نویسی دونفره ترتیب دهید.
- پیاده‌سازی Fitness Functions: محدودیت‌های معماری خود را به تست‌های کد تبدیل کنید تا عامل‌های AI نتوانند ساختار سیستم را به هم بریزند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو