‏هوش مصنوعی همه چیز رو تقویت می‌کنه — راهنمای تیم‌لیدها

یه اصل مهم توی این مقاله وجود داره که بقیه‌ی همه چیز ازش نشأت می‌گیره: هوش مصنوعی، عادت‌ها و فرایندهای موجود تیم رو تقویت می‌کنه، نه اصلاح. اگه تیمت منظم و با استانداردهاست، AI سرعت و کیفیتت رو چند برابر می‌کنه. ولی اگه بدون review process، بدون مستندات، و بدون تست‌های درست سراغش بری، فقط دیس‌فانکشن‌ات رو با سرعت بیشتری تولید می‌کنی.

یه مثال واقعی توی مقاله هست: یه تیم بدون هیچ review process ای ابزار Copilot رو راه انداخت. سه ماه بعد، چهار الگوی مختلف برای دسترسی به پایگاه داده توی یه سرویس داشتن که هیچ‌کدوم از وجود بقیه خبر نداشتن. رفاکتور کردن این بهم‌ریختگی، شش هفته از سرعتی که فکر می‌کردن به دست آوردن رو خورد. در مقابل، یه تیم هم‌اندازه که قبل از معرفی AI کنوانسیون‌ها و فرایندهاش رو مستقر کرده بود، ۴۰ درصد افزایش سرعت در سه ماه اول داشت و نرخ رگرسیون بعد از یک سال حتی کاهش پیدا کرد.

این مقاله یه طیف برای تصمیم‌گیری معرفی می‌کنه که کجا AI بنویسه و کجا نه. سمت امن طیف شامل کدهای boilerplate، فایل‌های configuration، کلاس‌های data، و CRUD endpointهایی‌ه که روی الگوی موجود پیاده می‌شن. اینا مشکلات حل‌شده‌ان با ریسک پایین. ولی سمت خطرناک طیف — منطق اصلی کسب‌وکار، لایه امنیت، pipeline مهاجرت داده، موتور محاسبات مالی — باید توسط خود توسعه‌دهنده نوشته بشه. AI می‌تونه کمک فکری بکنه یا edge caseها رو پیشنهاد بده، ولی نویسنده‌ی اصلی باید کسی باشه که مسئله رو درک می‌کنه.

یه دام رایج که توی مقاله بهش «تله‌ی کپی-پیست» گفته می‌شه اینه که AI کدی تولید می‌کنه که توی تست‌های ساده کار می‌کنه، ولی همه چیزهایی که کد رو production-ready می‌کنه نداره: retry logic، connection pooling، circuit breaker، graceful degradation، و observability. اینا چیزایی‌ان که از تجربه پیجر خوردن ساعت ۳ صبح میان، نه از پرامپت.

برای اینکه تصمیم‌گیری راحت‌تر بشه، مقاله یه decision tree پیشنهاد می‌ده: ۱. آیا می‌تونی output رو کامل verify کنی؟ نه → خودت بنویس. ۲. آیا این مشکل حل‌شده‌ایه با الگوی موجود؟ بله → AI بنویسه، تو review کن. ۳. آیا به security، داده مالی، PII، یا auth مربوطه؟ بله → خودت بنویس، AI review کنه. ۴. منطق کسب‌وکاره یا boilerplate؟ منطق کسب‌وکار → خودت بنویس؛ boilerplate → AI بنویسه.

درباره‌ی سنجش واقعی نتایج هم مقاله تأکید می‌کنه که فقط «داستان‌های بیشتر در sprint» معیار کافی نیست. متریک‌های مهم‌تر شامل Mean Time to Correct (MTTC)، نرخ recidivism باگ، نرخ رگرسیون، زمان onboarding اعضای جدید، و درصد PRهای AI-generated که نیاز به rework اساسی دارن هستن. اگه نرخ رد شدن PRهای AI بالای ۳۰٪ باشه، یعنی یا پرامپت‌ها یا خود requirementها مشکل دارن.

نتیجه‌گیری کلی اینه: قبل از اینکه AI رو به workflow تیمت اضافه کنی، اول workflow رو درست کن. review process رو اصلاح کن. کنوانسیون‌ها رو مستند کن. زیرساخت تست رو بساز. بعد AI اضافه کن تا همه این‌ها رو تقویت کنه — نه اینکه بی‌نظمی‌ات رو اتوماتیک کنه.

نکات کلیدی:

• AI هر چیزی که در تیم وجود داره رو تقویت می‌کنه — چه نقاط قوت، چه ضعف‌ها
• قبل از معرفی AI، فرایند review، مستندات، و تست‌ها باید سر جاشون باشن
• boilerplate و کدهای تکراری گزینه‌ی ایده‌آل برای AI هستن؛ منطق کسب‌وکار و امنیت نه
• کدهای تولیدشده توسط AI اغلب فاقد retry logic، connection pooling، circuit breaker و observability هستن
• سرعت delivery تنها معیار نیست؛ MTTC، نرخ رگرسیون، و زمان onboarding رو هم باید رصد کنی
• نرخ رد PRهای AI بالای ۳۰٪ نشانه‌ی مشکل در پرامپت‌ها یا requirementهاست