SDLC ایآیمحور: ایجنت رو وصله نکن، جاش بده
خلاصهٔ کاملتر
تو این مقاله اومده که ایآیمحور کردن SDLC (یعنی همون چرخهٔ تولید نرمافزار از تیکت تا تست) یعنی ایجنت کدنویسی رو داخل فرایند فعلی جا بدی، نه اینکه از بیرون بهش وصله کنی. نویسنده میگه لازم نیست شکل خط لولهٔ PM به دولوپر به QA عوض بشه؛ کافیه هر مرحله ورودی ساختاریافته و قانون روشن داشته باشه تا ایجنت کار واقعی انجام بده، نه اینکه فقط یه اتوکامپلیت سریع باشه که یکی باید بالاسرش وایسه.
مشکل اصلی جاییه که تیمها ابزار رو میگیرن ولی هیچی از روش کارشون عوض نمیشه: PM همون سند رو مینویسه و دولوپر توضیح تیکت رو کپی میکنه تو ایجنت و میگه «اینو بساز». اینجا همون چیزیه که نویسنده بهش میگه productivity mirage، یعنی حس سرعتی که با اندازهگیری واقعی جور درنمیاد. به گفتهٔ نویسنده مطالعهها نشون دادن مهندسها حس میکنن تندترن، ولی وقتی وقت بازبینی و تصحیح خطاهای ایجنت رو حساب کنی عملاً کندتر شدن.
همین توضیح میده چرا آمار پذیرش و اعتماد اینقدر از هم فاصله دارن: بخش بزرگی از مهندسها یه جایی از کارشون از AI استفاده میکنن، ولی کمتر از نصفشون به خروجیش اعتماد دارن. نویسنده معتقده دلیلش اینه که کسی با ساختار درست به این ابزار فرصت نداده؛ خروجیِ بدون گاردریل ناهماهنگه و کسی که یه بار کد شلخته رو تمیز کرده، دیگه بهش اعتماد نمیکنه حتی اگه هنوز ازش استفاده کنه.
سراغ فریمورکهای آمادهٔ open source رفتن هم جواب نداده. نویسنده میگه اون سیستمهای سفتوسخت ازت میخوان کل فرایندت رو با فرضهای خودشون بازطراحی کنی و برای تیمی که سالها روی تیکتینگ و ریویو و QA خودش نشسته عملی نیست؛ خیلیها هم بعد از چند ماه ولش میکنن. پیشنهادش یه template سبکه: همون خط لولهٔ فعلی، بهعلاوهٔ قرارداد مشخص برای اینکه تو هر مرحله ایجنت دقیقاً چطور استفاده میشه.
قدم عملی اینه که ببینی ایجنت تو کدوم مرحله داره ورودی مبهم میگیره و همونجا قانون بذاری: قرارداد ساختار کدبیس، تعریف روشن از «تموم شد» برای یه تیکت، و اینکه چقدر از کار رو خودش پیاده کنه و کجا رو برای بازبینی آدم علامت بزنه. مرحلههای عقبتر هم جا دارن، مثل کمک به PM برای تبدیل یه epic خام به تیکتهای درستاسکوپشده. هدف واگذاری قضاوت به ایجنت نیست، حذف ابهامیه که خروجی بیکیفیت میسازه.
نکات کلیدی:
- ایآیمحور یعنی ایجنت داخل همون SDLC فعلی با ورودی ساختاریافته تو هر مرحله، نه یه فریمورک جدید
- productivity mirage: حس سرعت بیشتر ولی تحویل کندتر، بعد از کسر وقت رفع خطاهای ایجنت
- پذیرش بالا و اعتماد پایین: اکثر مهندسها از AI استفاده میکنن، کمتر از نصف به خروجیش اعتماد دارن
- فریمورکهای سفتوسخت open source معمولاً بعد از چند ماه رها میشن چون کل فرایند رو میخوان عوض کنن
- شکل خط لوله (PM، دولوپر، QA) ثابت میمونه؛ چیزی که عوض میشه سهم ایجنت و گاردریل دورشه




