تصور کنید یک برنامه‌نویس ارشد تمام شب را صرف خواندن لاگ‌ها می‌کند تا بفهمد کدام‌یک از ۹ خطای سیستم واقعاً حیاتی است؛ این دقیقاً همان جایی است که هوش مصنوعی فعلاً شکست می‌خورد. تولید یک بلوک کد متقاعدکننده تنها چند ثانیه زمان می‌برد، اما اثبات اینکه این کد باعث سقوط سیستم در محیط عملیاتی (Production) نمی‌شود، ممکن است ساعت‌ها طول بکشد. گوتام کورلام، مهندس ارشد در شرکت Sonar، استدلال می‌کند که این عدم تقارن (Asymmetry) بین سرعت تولید و سرعت تأیید، گلوگاه اصلی در توسعه نرم‌افزارهای مدرن است.
مهندسی نرم‌افزار در حال تغییر جهت است؛ تمرکز از «تولید» به «تأیید» منتقل شده است. با هجوم عامل‌های هوش مصنوعی (AI Agents) — شبیه دستیارهای دیجیتالی که می‌توانند به‌طور مستقل وظایفی را انجام دهند — به مخازن کد و ارسال انبوه درخواست‌های ادغام (Pull Requests)، فشار از دوش نویسنده برداشته شده و به ماشینری منتقل شده است که باید تصمیم بگیرد آیا یک تغییر برای ادغام (Merge) ایمن است یا خیر. این رویکرد عامل‌محور با دیدگاه‌های گسترده‌تری در مورد توسعه عامل‌های لبه‌ای برای کاهش وابستگی به ابرهای متمرکز همسو است که به دنبال توزیع هوشمندی در لایه‌های مختلف زیرساخت است. این تنش به‌ویژه در محیط‌های مقیاس‌بزرگ که سرویس‌های مختلف به‌گونه‌ای پیش‌بینی‌ناپذیر با هم تعامل دارند، مشهود است و مهندسان را در وضعیتی قرار می‌دهد که باید منتظر بمانند تا بفهمند آیا تغییری که اعمال کرده‌اند ایمن است یا خیر.
این تقابل، عصر فعلی کدنویسی به کمک هوش مصنوعی را تعریف می‌کند. توسعه‌دهندگان به‌طور فزاینده‌ای از ابزارها برای نوشتن کد استفاده می‌کنند، اما متوجه شده‌اند که «مایل آخر» — یعنی اعتبارسنجی (Validation) — همچنان به‌طور لجبازانه دستی، کند و دشوار باقی مانده است.
گلوگاه اعتبارسنجی
دیدگاه گوتام کورلام حاصل سال‌ها تجربه گسترده در زیرساخت‌های توسعه است. او پیش از پیوستن به Sonar، نزدیک به یک دهه در Uber فعالیت کرد و مسیر شغلی خود را از یک مهندس مؤسس در تیم پلتفرم موبایل تا رسیدن به جایگاه مهندس ارشد (Principal Engineer) طی کرد. در اوبر، او روی سیستم‌های حیاتی که تصمیم می‌گیرند کد ارسال شود یا خیر، کار کرد: از Monorepo و سیستم Build گرفته تا صف‌های CI و مجموعه‌های تست (Test Suite).
در طول دوران فعالیتش، او ابتکارات بزرگی را در زمینه Monorepo و سیستم‌های Build رهبری کرد و محیط‌های توسعه از راه دور (Remote Developer Environments) و ابزارهای CI/CD را توسعه داد. او همچنین مدل‌های زبانی بزرگ متن‌باز، از جمله StarCoder، OctoCoder و Code Llama را آزمایش کرد تا کدنویسی به کمک AI را در پایگاه کد عظیم اوبر بهبود بخشد. او مشاهده کرد که اگرچه یک مدل می‌تواند به‌سرعت یک پیاده‌سازی کاربردی ارائه دهد، اما اطمینان از اینکه این کد از قراردادهای تیمی پیروی می‌کند و باعث خرابی در سرویسی که دو مرحله دورتر است نمی‌شود، یک بار انسانی عظیم است.
این بینش منجر به خلق Gitar شد؛ پلتفرمی بومیِ هوش مصنوعی (AI-native) که برای خودکارسازی بررسی کد، تشخیص علت شکست‌های یکپارچه‌سازی مداوم (CI)، شناسایی ریشه‌ای مشکلات و تولید اصلاحات طراحی شده است. شرکت Sonar در می ۲۰۲۶ Gitar را تصاحب کرد تا این قابلیت‌های عامل‌محور (Agentic) را در پلتفرم گسترده‌تر تأیید کد خود ادغام کند. Sonar که به بیش از ۲۲,۰۰۰ مشتری و ۷ میلیون توسعه‌دهنده خدمات می‌دهد، روزانه بیش از ۷۵۰ میلیارد خط کد را با استفاده از پلتفرم پرچم‌دار خود، SonarQube، تحلیل می‌کند.
زمینه: هزینه خروجی‌های هوش مصنوعی
به نقل از نظرسنجی «وضعیت کد ۲۰۲۶» (State of Code Developer Survey) که کورلام به آن استناد می‌کند، اثرات کد تولیدشده توسط AI در گردش کار تیم‌ها ملموس است:
- تیم‌ها گزارش می‌دهند که تقریباً ۲۵٪ از هفته کاری خود را صرف بررسی و اصلاح خروجی‌های AI می‌کنند.
- تنها ۴۸٪ توسعه‌دهندگان همیشه کد تولیدشده توسط AI را پیش از Commit کردن بررسی می‌کنند.
- ۹۶٪ توسعه‌دهندگان به‌طور کامل اعتماد ندارند که کد تولیدشده توسط AI از نظر عملکردی درست باشد.
این داده‌ها نشان می‌دهد که اگرچه AI حجم کد تولیدی را افزایش می‌دهد، اما به‌طور همزمان بار تریژ (Triage) یا اولویت‌بندی خطاها را برای مهندسان ارشد زیاد می‌کند. کورلام اشاره می‌کند وقتی یک مهندس ارشد تمام شب را صرف خواندن لاگ‌ها می‌کند تا بفهمد کدام‌یک از ۹ شکست سیستم واقعاً اهمیت دارد، او در حال انجام یک کار مکانیکی و تریژ است، نه به‌کارگیری قضاوت حرفه‌ای. این کار مکانیکی و ناخوشایند، هدف اصلی برای خودکارسازی است.
زمینه: تکامل چرخه توسعه
کورلام مشاهده می‌کند که تیم‌ها در حال پذیرش یک چرخه خودکار از «تولید، بررسی و تعمیر» با یک ترتیب خاص و ثابت هستند. آن‌ها مستقیماً به سراغ ادغام خودکار نمی‌روند، بلکه از این مراحل عبور می‌کنند:
۱. تشخیص (Detection): شناسایی مشکل در وهله اول.
۲. اصلاح (Remediation): اعمال یک راهکار برای رفع مشکل شناسایی شده.
۳. تأیید (Approval): تعیین شرایط خاصی که تحت آن یک تغییر پذیرفته می‌شود.
۴. ادغام (Merge): یکپارچه‌سازی نهایی در پایگاه کد.
این پیشروی بر اساس شواهدی از پایگاه کد خود تیم است، نه بنچ‌مارک‌های خارجی. با افزایش نرخ Commitها به دلیل استفاده از AI، مرحله ادغام به بحرانی‌ترین نقطه اصطکاک تبدیل می‌شود، زیرا فرکانس تداخلات (Conflicts) همگام با حجم تغییرات افزایش می‌یابد.
تحلیل قطعی در برابر احتمالی
کورلام تأکید می‌کند که AI باید مکمل تحلیل‌های قطعی (Deterministic) باشد، نه جایگزین آن‌ها. او اعتبارسنجی کد را بر اساس ماهیت مسئله به دو لایه متمایز تقسیم می‌کند.
تحلیل‌های مبتنی بر قانون (Rule-based) تنها ابزار مناسب برای ویژگی‌های «تصمیم‌پذیر» (Decidable) هستند؛ یعنی مواردی که جای مذاکره ندارند. این موارد شامل شناسایی موارد زیر است:
- ورودی‌های آلوده (Tainted input) که به یک Sink می‌رسند.
- ارجاعات تهی (Null dereferences) در مسیری که توسعه‌دهنده نادیده گرفته است.
- اعتبارنامه‌های سخت‌افزاری (Hardcoded credentials).
- وابستگی‌هایی که دارای یک CVE شناخته‌شده هستند.
- Importهایی که از لایه‌ای عبور می‌کنند که نباید کنند.
این بررسی‌ها تکرارپذیرند، در هر بار اجرا پاسخ یکسانی می‌دهند و به سیستم اجازه می‌دهند دقیقاً به دلیل اجرای یک قانون اشاره کند. به دلیل این قابلیت اطمینان، اجرای سخت‌گیرانه باید در این لایه باشد.
در مقابل، AI برای درک «قصد» (Intent) و بستر متن (Context) به کار می‌رود، جایی که نتایج احتمالی (Probabilistic) هستند. یک پارسر (Parser) نمی‌تواند تشخیص دهد که آیا یک رشته متنی برای یک مترجم مبهم است یا خیر، یا اینکه آیا یک تغییر ادعا می‌کند تیکتی را می‌بندد در حالی که تنها نیمی از نیازمندی‌ها را پیاده کرده است. یک مدل زبانی بزرگ (LLM) می‌تواند Diff، تیکت مرتبط و کل بستر کد را بخواند تا این موارد را به عنوان یافته (Finding) مطرح کند. این‌ها باید به عنوان «پیشنهاد» برای بررسی توسط انسان برسند، نه به عنوان حکم نهایی.
پیاده‌سازی حفاظ‌ها
برای جلوگیری از اینکه AI باعث ایجاد پس‌رفت (Regression) شود، Sonar مرزی سخت بین پیشنهادات احتمالی و تصمیمات قطعی ایجاد کرده است. AI یک یافته را پیشنهاد می‌کند، اما حکم نهایی بررسی در کد و بر اساس وضعیت آن یافته‌ها محاسبه می‌شود. این تضمین می‌کند که اگر کد مربوط به یک یافته از Diff حذف شود، یک بررسی قطعی آن را حل‌شده تلقی کند؛ مدل اجازه ندارد چیزی را که Diff قبلاً اصلاح کرده است، دوباره «حل‌نشده» اعلام کند.
کورلام چندین حفاظ (Guardrails) خاص را در پیاده‌سازی Gitar برجسته می‌کند تا اطمینان حاصل شود که اصلاحات خودکار، صرفاً برای رسیدن به یک Build موفق بهینه‌سازی نمی‌شوند:
- محدودیت دامنه (Scope Limitation): سیستم CI شکست‌خورده را اصلاح می‌کند، اما ابتدا بررسی می‌کند که Commit قبل از Push خودش سبز بوده باشد. سیستم پس از دو Commit تکمیلی متوقف می‌شود و اجازه نمی‌دهد مدل به‌طور بی‌پایان روی یک Build قرمز تلاش کند.
- ضد-بهینه‌سازی (Anti-Optimization): سیستم از پذیرش «Build سبز» به عنوان تنها معیار پذیرش خودداری می‌کند. یک Build موفق فقط ثابت می‌کند تست‌های موجود شکست نخورده‌اند، اما کیفیت را تضمین نمی‌کند. اگر شکست ناشی از یک تست ناپایدار (Flaky test) یا اختلال زیرساختی باشد، سیستم مسیر «تلاش مجدد» (Retry) را دنبال می‌کند نه مسیر «اصلاح»، زیرا «متوقف کردن شکست تست» خطرناک‌ترین هدفی است که یک عامل AI می‌تواند دنبال کند.
- تأیید مستقل (Independent Verification): هر اصلاحیه تولیدشده توسط AI باید از همان گیت‌های کیفیتی (SonarQube Quality Gates) عبور کند که کدهای انسانی عبور می‌کنند. ادغام به این گیت‌ها وابسته است و تیم مالک این سیاست است.
- استخراج نیازمندی (Requirement Extraction): سیستم استخراج نیازمندی‌ها را از قضاوت درباره تکمیل آن‌ها جدا نگه می‌دارد. این کار مانع از آن می‌شود که نیازمندی‌ای که به‌طور پنهانی از تیکت حذف شده، به عنوان «پیاده‌شده» علامت‌گذاری شود.
جزئیات: اعتبارسنجی چندلایه
یک فرآیند اعتبارسنجی مؤثر باید از غرق کردن توسعه‌دهندگان در «دیواری از یافته‌ها» جلوگیری کند؛ کورلام اشاره می‌کند که یافته‌های بیش از حد، تقریباً با همان نرخی نادیده گرفته می‌شوند که انگار هیچ یافته‌ای وجود ندارد. برای جلوگیری از این اتفاق، Sonar چندین مکانیزم فیلترینگ را اجرا می‌کند:
- حذف تکرار (Deduplication): یافته‌ها پیش از رسیدن به نویسنده، در بین بررسی‌کنندگان مختلف حذف تکرار می‌شوند.
- تأیید (Verification): سیستم کاندیداهایی را که نمی‌تواند تأیید کند حذف کرده و منحصراً روی یافته‌های با سیگنال بالا تمرکز می‌کند.
- فیلتر پیش‌شرط (Predicate Filtering): در بخش قوانین، یک پیش‌شرط تصمیم می‌گیرد که آیا یک قانون بر روی Diff فعلی اعمال می‌شود یا خیر، پیش از آنکه هر مدلی اجرا شود. این باعث می‌شود اکثر قوانین برای اکثر تغییرات هیچ هزینه‌ای نداشته باشند.
- یکپارچگی (Integration): تمام یافته‌ها مستقیماً روی همان Pull Request که توسعه‌دهنده باز کرده است ظاهر می‌شوند، نه در یک ابزار مجزا.
جزئیات: مکانیسم‌های بررسی AI
برای اطمینان از اینکه بررسی‌های AI کاربردی و قابل اعتماد باشند، سیستم از یک منطق عملیاتی خاص پیروی می‌کند:
- ورودی احتمالی: AI برای کارهایی استفاده می‌شود که اشتباه در آن‌ها قابل جبران است، مانند پیشنهاد یک خطای منطقی یا عدم تطابق رفتاری.
- وضعیت قطعی: ماشین وضعیت (State Machine) حاکم بر بررسی، قطعی باقی می‌ماند تا ثبات و یکپارچگی حفظ شود.
- مسئولیت انسانی: تصمیم نهایی و مسئولیت‌پذیری همیشه بر عهده تیم انسانی باقی می‌ماند.
- اعتماد مبتنی بر شواهد: اعتماد از طریق شواهدی به دست می‌آید که انسان بتواند بازرسی و کنترل کند و در هر بار اجرا رفتار یکسانی داشته باشد.
زمینه و هوشمندی مخزن
یک بررسی مؤثر AI به چیزی بیش از خواندن یک Diff نیاز دارد؛ این کار مستلزم توانایی استدلال مانند یک بررسی‌کننده با تجربه است. برای دستیابی به این هدف، AI به موارد زیر نیاز دارد:
- هدف تغییر و جزئیات تیکت‌های مرتبط.
- مسیرهای کد مرتبط و اطلاعات نوع (Type information).
- وابستگی‌ها و رفتار تست‌ها.
- قراردادهای مخزن و مرزهای معماری.
کورلام استدلال می‌کند که این بستر متن (Context) باید همراه با کد زندگی کند. سازمان‌ها باید قوانین و راهنمای بررسی را در مخزن نسخه‌بندی کنند و با تکامل سرویس‌ها، آن‌ها را به‌روزرسانی نمایند. بدون این کار، AI ممکن است پیشنهادی ارائه دهد که به‌طور انفرادی منطقی به نظر برسد اما با معماری کلی سیستم در تضاد باشد.
در محیط‌های تحت نظارت یا حساس به امنیت، این موضوع از طریق یک ردپای حسابرسی (Audit trail) سخت‌گیرانه مدیریت می‌شود. این ردپا باید تغییر بررسی‌شده، یافته AI، تصمیم اتخاذ شده و شواهد مستقلی که برای تأیید نتیجه استفاده شده است را نشان دهد. این کار باعث می‌شود اجرا و تأیید در لنگر مسئولیت‌پذیری انسانی باقی بماند.
سنجش موفقیت
رهبران مهندسی باید از اندازه‌گیری موفقیت AI بر اساس تعداد کامنت‌های تولیدشده اجتناب کنند. در عوض، کورلام پیشنهاد می‌کند بر معیارهای مبتنی بر نتیجه تمرکز کنند:
- سرعت (Velocity): زمان سپری شده از ایجاد Pull Request تا ادغام نهایی.
- کارایی (Efficiency): زمان صرف‌شده برای تشخیص شکست‌های CI و نرخی که اصلاحات در اولین تلاش اعتبارسنجی پاس می‌شوند.
- قابلیت اطمینان (Reliability): هر چند وقت یک‌بار مشکلات به محیط عملیاتی یا مراحل بعدی نشت می‌کنند.
- سیگنال‌های کیفیت: نرخ مثبت کاذب، نرخ رد کردن یافته‌ها، تیکت‌های بازشده مجدد و پس‌رفت‌های مرتبط با ادغام‌های اخیر.
آینده مهندس نرم‌افزار
با خودکار شدن چرخه تولید، بررسی و تعمیر، نقش مهندس انسان در حال تغییر است. کورلام پیشنهاد می‌کند که ارزشمندترین مهارت‌ها اکنون «در اطراف» این چرخه شکل می‌گیرند، نه «درون» آن.
دقت در توصیف مسئله حیاتی‌تر شده است زیرا عامل‌های AI توصیفات را به‌طور تحت‌اللفظی اجرا می‌کنند. مهندسان اکنون باید «عادت‌های» کیفی درونی خود را به سیاست‌های مکتوب و صریحی تبدیل کنند که یک سیستم خودکار بتواند آن‌ها را اعمال کند. این امر تمرکز مهندس را از «پیاده‌سازی» به «سیاست‌گذاری» منتقل می‌کند.
در نهایت، شغل مهندس به سمت طراحی سیستم‌ها حرکت می‌کند. این شامل موارد زیر است:
- تعیین مرزهایی برای اینکه کارهای خودکار به چه بخش‌هایی دسترسی داشته باشند.
- پیاده‌سازی بررسی‌های مستقلی که عامل AI کنترلی روی آن‌ها ندارد.
- تضمین اینکه تمام تغییرات در صورت بروز خطا، قابل ردیابی و انتساب به شخص باشند.
- تصمیم‌گیری درباره اینکه چه چیزی «اثبات کافی» است که یک تغییر واقعاً درست کار می‌کند.
این تغییر به معنای زمان کمتر برای تولید پیاده‌سازی و زمان بیشتر برای تمرکز بر مرزهای معماری، قصد (Intent) و مسئولیت‌پذیری است.
گام بعدی شما
- بررسی کنید که آیا در تیم خود «گیت‌های کیفیتی» (Quality Gates) مکتوب و مستقل از AI دارید یا خیر.
- تمرین کنید تا نیازمندی‌های فنی را به‌جای توصیفات کلی، به صورت سیاست‌های صریح و قابل اندازه‌گیری بنویسید.
- ابزارهایی را امتحان کنید که تحلیل‌های قطعی (Static Analysis) را با پیشنهادات AI ترکیب می‌کنند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو