💡 نمونه‌هایی از بازنویسی با AI و نیاز به بازنگری در SDLC

طی چند ماه اخیر، چند نمونه از بازنویسی محصولات بزرگ با کمک AI منتشر شد که ارزش توقف و مرور عمیق‌تر و بین‌سطور این اخبار رو داره!

مثلا کلادفلر نسخه اولیه EmDash رو منتشر کرد؛ بازنویسی وردپرس با TypeScript، با معماری AI-native که هم امن‌تره هم سبک‌تر. همین کلادفلر کمی قبل‌ترش، vinext رو هم به عنوان نسخه بهینه‌تر از Next.js طی مدت کوتاهی توسعه داد. LakeSail نشون داد که می‌شه یه SQL parser رو با Rust در یک هفته نوشت که از نمونه‌های مشابه (PySpark) عملکرد بهتری داشته باشه. و نمونه مفهومی‌تر، پروژه cpp-to-rust-skill بود که البته برای کدبیس‌های واقعی و بزرگ به تنهایی کافی نیست.

نکته مشترک همه این مثال‌ها: این تیم‌ها از AI برای تسریع چیزی استفاده کردن که خودشون بهش تسلط داشتن. دانش domain، تجربه معماری، و درک عمیق از مشکلی که می‌خواستن حل کنن؛ اینا پیش‌نیاز بود، نه خروجی AI. ابزار سرعت داد، نه جهت.
البته نمونه‌های زیادی هم هست که اولش خیلی سریع با AI تولید شده، بعدن توی دیباگ و نگهداری و… عاجز موندن.

این تمایز، یه سوال جدی‌تر رو باز می‌کنه و من به عنوان بهانه برای مطالب بعدی می‌خوام ازش استفاده کنم (در صورت استقبال)
وقتی یکی از مراحل SDLC؛ یعنی توسعه؛ سریع‌تر و ارزون‌تر می‌شه، بقیه بلاک‌های چرخه نمی‌تونن بدون تغییر بمونن. Requirements & Analysis باید دقیق‌تر بشه، نه سطحی‌تر. Testing باید پوشش بیشتری بده، چون خروجی بیشتره و حالت‌ها غیرقابل پیش‌بینی، بیشتر. Maintenance باید پذیرای کدی باشه که شاید کمتر «دست‌ساز» احساس بشه. حتی ownershipها باید بازنگری شن. مسئولیت‌های tech lead هم دیگه مثل قبل نیست.

اگه علاقه‌مند باشید، یه مطلب مفصل‌تر درباره تغییرات لایه‌به‌لایه SDLC در دوره AI می‌نویسم.

💬 به نظرتون در سازمان شما، کدوم بلاک SDLC بیشترین lag رو داره؟ لیدرشیپ سازمان و تیمتون خودش رو با دوره AI هم‌آهنگ کرده؟!

6