Go Casts 🚀

از قشنگ‌ترین دیدگاه‌هایی که این چند ماهه درباره‌ی «نقش هوش مصنوعی در مهندسی نرم‌افزار» دیدم٬ ارائه‌ی Adam Bender هست. نقطه قوتش این نیست که چیز جدیدی درباره‌ی مدل‌ها بگه، بلکه اینه که می‌گه نمی‌شه فقط به سرعت تولید کد نگاه کرد و قضاوت کرد که هوش مصنوعی چقدر داره کمک می‌کنه. باید کل محیط توسعه‌ی نرم‌افزارتون رو به‌عنوان یه سیستم پیچیده ببینید، با همون اصطلاحی که خودش ساخته، "بوم‌شناسی نرم‌افزار" یا software ecology - یعنی مطالعه‌ی کامل مجموعه‌ی انسانی و تکنیکی شرکت که در کنار هم نرم‌افزار رو تولید می‌کنه. این نکته که فرهنگ یه تیم و معماری سیستم‌ش از هم جدا نیستن، دقیقاً همون چیزیه که خیلی از ما هم باهاش دست‌وپنجه نرم می‌کنیم - یه تیم اگه فرهنگ خرابی داشته باشه و بعد هوش مصنوعی رو هم بهش اضافه کنه، نتیجه نه‌فقط بهتر نمی‌شه، بلکه همون ناکارآمدی رو با سرعت بیشتر تکرار می‌کنه. این دقیقاً همون چیزیه که گزارش DORA هم چند بار تو دو سال اخیر گفته: هوش مصنوعی فقط یه تقویت‌کننده‌ست (amplifier)، نه یه راه‌حل. اصول خوب رو تقویت می‌کنه، اصول بد رو هم همینطور. نکته‌ای که برام جالب بود، بحث «لحظه‌ی 10x شدن»ـشه. می‌گه فرق بین سریع‌تر کد تولید کردن و سریع‌تر مهندسی کردن (engineering) از زمین تا آسمونه. بعد یکی‌یکی بخش‌های سیستم رو بررسی می‌کنه: زمان بیلد، بازبینی کد، تست، کنترل نسخه، انتشار نسخه، برگشت به نسخه‌ی قبل - و می‌گه همه‌ی این‌ها برای سرعت انسانی طراحی شدن، و اگه بخوای ده برابر سریع‌تر کد تولید کنی ولی این بخش‌ها رو متناسب باهاش جلو نبری، کل سیستم می‌شکنه. این خیلی شبیه چیزیه که تو هر زیرساخت بزرگی می‌بینیم - یه جای سیستم رو سریع می‌کنی، ولی فشار میره رو جای دیگه‌ای که اصلاً برای اون حجم طراحی نشده بوده و خودش تبدیل به نقطه‌ی شکست می‌شه. اون بحث «کنترل ذهنی روی سیستم» یا همون intellectual control هم خیلی به دلم نشست. می‌گه تقریبا پانزده ساله که ما مهندسین نرم‌افزار این جنگ رو داریم می‌بازیم - سیستم‌ها اونقدر بزرگ شدن که هیچ‌کس نمی‌تونه کامل تو ذهنش معماری‌شون رو نگه داره (یه آزمایش جالب پیشنهاد می‌ده: از تیمت بخواه نقشه‌ی معماری سیستم رو بکشن، ببین چقدر فرق دارن). ولی برخلاف خیلی‌ها که ممکنه فقط منفی نگاه کنن، می‌گه شاید هوش مصنوعی بتونه برعکس عمل کنه و کمک کنه این کنترل رو پس بگیریم - مثلاً یه مدل تعاملی از معماری سیستم که بشه ازش پرسید «اگه ظرفیت (capacity) رو از اینجا به اونجا منتقل کنیم چی می‌شه؟». این برام جالب‌تر از صرف تولید کد بود، چون داره می‌گه ارزش واقعی هوش مصنوعی نه‌فقط نوشتن کد، بلکه فهمیدن سیستم‌های بزرگه. نتیجه‌ای که می‌گیره هم به نظرم درسته: رویه‌ها(practices) تغییر می‌کنن، اصول(principles) می‌مونن. اگه نفهمی چرا تیمت یه جور خاص تست می‌نویسه یا منتشر می‌کنه، نمی‌تونی اون رو درست تغییر بدی. این مسئولیت رو هم می‌اندازه گردن مهندس‌های ارشد، نه فقط مدیریت بالادست - می‌گه شما باید برای کیفیت و طراحی درست حرفتون رو بزنید، چون احتمالاً مدیرتون این کار رو نمی‌کنه. واکنش‌هایی هم که دیدم متفاوت بود - بعضی‌ها همین نگاه رو دقیقاً چیزی می‌دونن که صنعت لازم داشت، بعضی‌ها هم می‌گن خیلی کلی‌گوییست. به نظر من خود ایده ارزشمنده، ولی باید عملیاتیش کرد - یعنی واقعاً بنشینی ببینی تو سیستم خودت کدوم بخش اول می‌شکنه. تجربه شخصی خودم هم در تلاش‌های مختلف برای agentic کردن محیط توسعه همین بوده که در نهایت به این نتیجه رسیدم واقعا اگه یه محیط agentic توسعه بخواد موثر باشه باید حتما جنبه های socio-technology ecosystem رو با هم در نظر بگیری. تعامل اجتماعی-فنی در کنار هم داره باعث توسعه نرم‌افزار میشه و این دو عامل در طی زمان co-evolve میشن و تغییر یکی‌شون دیگری رو هم تحت تاثیر قرار میده. https://www.youtube.com/watch?v=2n41YjR5QfU @gocasts