کدنویسی با هوش مصنوعی؛ چرا گیت‌های ادغام سخت‌گیرانه‌تر شده‌اند؟

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

این تغییر در حاکمیت کدنویسی زمانی رخ می‌دهد که تیم‌ها از کدنویسی دستی به جریان‌های کاری تقویت‌شده با هوش مصنوعی کوچ می‌کنند. در حالی که ما پیش‌تر بررسی کردیم که چگونه IssueFlow توسعه‌ی عامل-به-عامل (agent-to-agent) را آزمایش کرد، واقعیت عملی برای اکثر سازمان‌ها یک مدل ترکیبی است که در آن انسان‌ها بر دستیاران هوش مصنوعی نظارت دارند. این نیاز به نظارت دقیق‌تر با یافته‌های اخیر همسو است که نشان می‌دهد کدهای تولیدشده توسط عامل‌های هوش مصنوعی ۱.۷ برابر بیشتر خطا دارند و لزوم حضور تسترهای انسانی را دوچندان می‌کند. خطر اصلی اینجاست که کدهای تولیدشده توسط هوش مصنوعی، تمام‌شده به نظر می‌رسند و از استایل‌های داخلی شرکت پیروی می‌کنند؛ همین موضوع باعث می‌شود بازبین‌های انسانی کدها را سریع رد کنند و شکست‌های ظریف اما حیاتی را نبینند. سرعت رشد عالی به نظر می‌رسد و درخواست‌های ادغام سریع‌تر از هر زمان دیگری ثبت می‌شوند، اما وقتی سیستمی می‌پاشد، عبارت «هوش مصنوعی آن را نوشت» در گزارش‌های حوادث (incident notes) دیده می‌شود.

ماهیت نقص‌های هوش مصنوعی

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

• خطاهایی که به‌طور بی‌صدا در بلوک‌های catch بلعیده می‌شوند.
• بررسی‌های دسترسی (Permission checks) که در نقاط لیست (list endpoints) وجود دارند اما در نقاط جزئیات (detail endpoints) فراموش شده‌اند.
• حلقه‌های تکرار (Retry loops) که فاقد حد حداکثری هستند.
• استفاده از نام بسته‌هایی که درست به نظر می‌رسند اما وجود ندارند یا قدیمی شده‌اند.

حجم بالای کدها این مشکل را تشدید می‌کند. وقتی یک بازبین با یک تغییر ۹۰۰ خطی (diff) روبروست، اغلب بر اساس اعتماد تایید می‌کند. علاوه بر این، تست‌هایی که در همان جلسه با کد تولید می‌شوند، معمولاً بررسی می‌کنند که کد «چه می‌کند»، نه اینکه «باید چه کند». این تست‌ها پاس می‌شوند، اما هیچ حقیقت مفیدی را نشان نمی‌دهند.

هزینه بلندمدت نادیده گرفتن گیت‌ها

هزینه این شکست‌ها به‌ندرت در همان اسپرینتی که کد ادغام شده ظاهر می‌شود. در عوض، ماه‌ها بعد به شکل‌های زیر نمایان می‌گردد:

• بدهی نگهداری: شما با کدبیسی مواجه می‌شوید که هیچ‌کس به‌طور کامل آن را نمی‌فهمد و هر تغییر بعدی زمان بیشتری نسبت به آنچه باید، می‌برد. این تغییر در نقش مهندس نرم‌افزار باعث شده تا ارزش برنامه‌نویسان از نوشتن کد به معماری سیستم و عیب‌یابی منتقل شود، چرا که درک کلان سیستم اکنون حیاتی‌تر از تولید سریع کد است.
• شکاف‌های امنیتی: حفره‌هایی که یک ممیزی ساده می‌توانست بگیرد، در عوض ابتدا توسط یک مشتری یا یک متخصص تست نفوذ کشف می‌شوند.
• ریسک‌های انطباق: وابستگی‌هایی را به ارث می‌برید که یا رها شده‌اند یا تحت لایسنس‌هایی هستند که خریداران سازمانی در زمان بررسی‌های قانونی (Due Diligence) آن‌ها را زیر سوال می‌برند.
• ریسک تحویل: اگر از تیم‌های برون‌سپاری استفاده می‌کنید، ممکن است مالک کدی باشید که فقط پرامپت‌های پیمانکار می‌توانند آن را توضیح دهند؛ این موضوع روزی که شریک خود را عوض می‌کنید یا یک مدیر داخلی استخدام می‌کنید، منجر به بحران می‌شود.

استثنا برای نمونه‌های اولیه

هر پروژه‌ای به گیت‌های سخت نیاز ندارد. بنیان‌گذاران فنی تک‌نفره که برای تست تقاضا در حال ساخت نمونه اولیه (Prototype) هستند — در حالی که هیچ داده‌ای از مشتری و هیچ سیستم پرداختی ندارند — می‌توانند برای حفظ سرعت از این محدودیت‌ها بگذرد. آن‌ها فقط باید یک لیست کوتاه از قوانین را رعایت کنند: هیچ رمز عبوری (secret) در مخزن نباشد، یک فایل lockfile ثبت شده باشد و هر تغییر قبل از ادغام به‌طور کامل خوانده شود. اما به محض ورود اولین کاربر واقعی یا داده‌های واقعی، تمام مجموعه گیت‌های سخت‌گیرانه باید اضافه شوند.

قوانین اجباری برای Pull Request

برای مقابله با این ریسک‌ها، گزارش dev.to گیت‌های ادغام مشخصی را پیشنهاد می‌کند. اول، تغییرات (diffs) باید کوچک بمانند؛ حد نرم حدود ۴۰۰ خط تغییر است، بدون احتساب فایل‌های تولیدشده و lockfileها. هر چیزی بزرگ‌تر از این مقدار به بازبین دوم نیاز دارد، زیرا تمرکز انسان بعد از این آستانه به‌شدت افت می‌کند.

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

حفاظت از شاخه و دسترسی

تیم‌ها باید از GitHub یا GitLab استفاده کنند تا حداقل یک تاییدیه از کسی به‌جز نویسنده بگیرند و پوش‌های مستقیم به شاخه main را مسدود کنند. استفاده از CODEOWNERS تضمین می‌کند تغییرات در بخش‌های احراز هویت، پرداخت و دسترسی به داده‌ها حتماً به دست شخص مسئول برسد. یک قانون تصمیم‌گیری سخت‌گیرانه باید اجرا شود: اگر تغییری به احراز هویت، پرداخت‌ها، مجوزها یا داده‌های شخصی دست می‌زند، فارغ از اندازه کد، به دو بازبین انسانی نیاز دارد.

تست رفتاری در برابر پوشش تست

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

الزامات تست

• پوشش تغییرات (Diff Coverage): ابزارهایی مثل Codecov یا SonarQube باید پوشش را به‌طور خاص روی فایل‌های تغییریافته اجبار کنند، که این روش عادلانه‌تر از یک هدف کلی روی یک کدبیس قدیمی است.
• نام‌گذاری موارد خاص (Edge Cases): نویسندگان باید لیست کنند که تست‌ها کدام موارد خاص را پوشش می‌دهند، مانند ورودی خالی، تایم‌اوت، درخواست‌های تکراری یا کاربرانی از یک tenant دیگر.
• تست‌های یکپارچگی (Integration Tests): مسیرهای حیاتی به جای تست‌های واحد (Unit Tests) شبیه‌سازی‌شده، به تست‌های یکپارچگی نیاز دارند. دستیاران هوش مصنوعی اغلب دقیقاً همان نقاط شکست تولیدی را شبیه‌سازی (Mock) می‌کنند که در واقعیت اهمیت دارند.
• پذیرش تدریجی: تیم‌هایی که تست ندارند نباید یک‌شبه به دنبال عدد پوشش باشند، اما باید برای هر تغییر جدید و هر رفع باگ، تست اجباری باشد.

گیت‌های وابستگی و امنیت

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

برای جلوگیری از این اتفاق، بررسی‌های CI زیر توصیه می‌شود:

• فایل‌های Lock: ثبت lockfileها و نصب از طریق هش‌ها (مثلاً npm ci یا pip install با هش‌ها).
• اسکن آسیب‌پذیری: اجرای اسکن روی هر PR با ابزارهایی مثل Snyk، Dependabot، npm audit یا pip-audit با سطح شدت مشخصی که ادغام را مسدود کند.
• توجیه: الزام به ارائه یک خط توجیه برای هر وابستگی مستقیم جدید: چرا این بسته، چه کسی آن را نگهداری می‌کند و آخرین انتشارش کی بود.
• بررسی لایسنس: شناسایی لایسنس‌های copyleft یا ناشناخته قبل از ورود کد به محصول تجاری.
• اسکن رمزها: پیاده‌سازی Gitleaks یا سیستم حفاظت از پوش گیت‌هاب برای شناسایی کلیدهای نمونه‌ای که هوش مصنوعی در فایل‌های تنظیمات می‌چسباند.

استقرار مالکیت مطلق

مالکیت باید دوتایی (binary) باشد: کسی که کد را ادغام می‌کند، مالک آن است. این موضوع باید در دفترچه راهنمای مهندسی و قراردادهای پیمانکاران نوشته شود. عبارت «هوش مصنوعی آن را نوشت» هرگز دلیل قابل قبولی برای ریشه‌یابی حوادث (Postmortem) نیست.

برای تیم‌های برون‌سپاری، قراردادها باید صراحتاً ذکر کنند که مشتری ۱۰۰٪ مالک کد و IP است، مخزن در حساب سازمان مشتری قرار دارد و پیمانکار هر زمان خواسته شد، مهندسان را برای توضیح هر ماژول به جلسه می‌آورد.

یک قانون نهایی برای هر مهندس: هیچ‌کس کدی را ادغام نکند که نتواند ساعت ۲ صبح آن را دیباگ کند. اگر ماژولی برای مالک انسانی بیش از حد پیچیده است تا توضیح دهد، باید ساده شود یا قبل از رسیدن به شاخه اصلی، یک جلسه walkthrough داشته باشد.

نقشه راه پیاده‌سازی

این انتقال باید به‌صورت تدریجی اجرا شود تا اصطکاک تیمی ایجاد نشود:

۱. فوری (یک بعدازظهر): فعال کردن حفاظت از شاخه، بررسی‌های اجباری و اسکن رمزها.
۲. کوتاه‌مدت (دو هفته): افزودن اسکن وابستگی و آسیب‌پذیری به CI. ابتدا دو هفته در حالت هشدار و سپس در حالت مسدودکننده.
۳. میان‌مدت: پذیرش قالب PR با افشای استفاده از هوش مصنوعی و قانون مالکیت.
۴. بلندمدت: اجبار به پوشش تغییرات در فایل‌های تغییریافته و افزودن تست‌های یکپارچگی برای سه مسیر اصلی کاربر.

اگر تیم برون‌سپاری است، پیمانکار باید اجرای این گیت‌ها را در خط لوله (Pipeline) خود نشان دهد، نه در یک فایل اسلاید. برای کسانی که شک دارند کدبیسشان دچار انحراف شده است، یک ممیزی کامل کد AI قبل از اجرای این گیت‌ها توصیه می‌شود تا شکاف‌های امنیتی موجود و وابستگی‌های رهاشده شناسایی شوند.

گام بعدی شما

• در قالب Pull Request خود یک چک‌باکس «تولید شده توسط AI» اضافه کنید تا بازبین‌ها را متوجه نیاز به دقت بیشتر کنید.
• برای هر وابستگی (Dependency) جدید، یک خط توجیه درباره تاریخچه و نگهداری آن بسته بنویسید.
• تست‌های خود را به جای پوشش خطوط، بر اساس «اثبات رفتار» بازنویسی کنید تا حذف خطوط کلیدی حتماً منجر به شکست تست شود.

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