همچنین یک مقاله راهنما درباره این که چرا باید انتظارات خود را بازنگری کنیم و مهندسی نرمافزار واقعا چیست.
سال نو مبارک! همانطور که ما به نوآوری هایی که ممکن است در سال ۲۰۲۵ به ارمغان بیاورد نگاه می کنیم، مطمئناً GenAI به تغییر نحوه عملیات مهندسی نرم افزار ادامه خواهد داد.
باورش سخت است که کمی بیش از دو سال پیش در نوامبر ۲۰۲۲ بود که اولین نسخه ChatGPT ارایه شد. این نقطه زمانی بود که مدل های زبان بزرگ (LLM) شروع به رونماییهای گسترده کردند. اگرچه LLM ها به روشی ساده و شگفت آور ساخته می شوند ، اما نتایج چشمگیری در زمینههای مختلف ایجاد می کنند. شاید کدنویسی یکی از قویترین نقاط عملکرد آنها باشد. با توجه به اینکه چگونه:
- برنامهنویسی دارای دستور زبانی بسیار سادهتر از هر زبان انسانی است
- به لطف نرم افزارهای منبع باز و خزشهای GitHub و سایر مخازن کد با دسترسی آزاد، حجم عظیمی از دادههای آموزشی با کیفیت بالا برای این LLM ها وجود دارد که می توانند از آنها به شکل کد منبع فعال استفاده کنند (این نوع خزیدن و آموزش در حال حاضر به شکل گستردهای در حال انجام است، صرف نظر از اینکه کاری اخلاقی است یا نه)
سال گذشته، طبق نظرسنجی بررسی واقعیت ابزارسازی هوش مصنوعی ، شاهد بودیم که حدود ۷۵ درصد از توسعهدهندگان از نوعی ابزار هوش مصنوعی برای کارهای مرتبط با مهندسی نرمافزار استفاده میکنند . و با این حال، به نظر می رسد که ما هنوز در اوایل چرخه نوآوری ابزارسازی هستیم و رویکردهای پیچیده تری مانند عوامل مهندسی نرم افزار هوش مصنوعی احتمالاً در مرکز نوآوری در سال ۲۰۲۵ خواهند بود.
رسانه های جریان اصلی تصویری چشمگیر از صنعت مهندسی نرم افزار ترسیم کرده اند. در ماه مارس، Business Insider در مورد اینکه چگونه مهندسان نرمافزار در حال نزدیکتر شدن به کشف اینکه آیا هوش مصنوعی واقعاً میتواند آنها را بیکار کند، نوشت و در ماه سپتامبر، فوربس پرسید : «آیا مهندسان نرمافزار منسوخ میشوند؟» در حالی که چنین مقالاتی دسترسی گسترده ای پیدا می کنند، از افرادی می آیند که خودشان مهندس نرم افزار نیستند، از این ابزارهای هوش مصنوعی استفاده نمی کنند و از کارایی (و محدودیت ها!) این ابزارهای کدنویسی جدید GenAI بی اطلاع هستند.
اما به طور واقع بینانه چه انتظاری می توانیم از ابزار GenAI برای شکل دادن به مهندسی نرم افزار داشته باشیم؟ GenAI بخشهایی از مهندسی نرمافزار را تغییر خواهد داد، اما بعید به نظر میرسد که این کار را به شکل چشمگیری که برخی از سرفصلهای قبلی نشان میدهند، انجام دهد. و با دو سال استفاده از این ابزارها و با استفاده از اکثر تیم های مهندسی به مدت ۱۲ ماه یا بیشتر، می توانیم نظر بهتری در مورد آنها شکل دهیم.
آدی عثمانی یک مهندس نرم افزار و رهبر مهندسی است که در موقعیت خوبی برای مشاهده اینکه چگونه ابزارهای GenAI واقعاً مهندسی نرم افزار را شکل می دهند، است. او ۱۲ سال است که در گوگل کار می کند و در حال حاضر رئیس تجربه توسعه دهندگان کروم است. گوگل شرکتی است که در خط مقدم نوآوری GenAI قرار دارد. این شرکت مقاله تحقیقاتی در مورد معماری ترانسفورماتورها را در سال ۲۰۱۷ نوشت که به عنوان پایه ای برای LLM عمل می کند. امروزه گوگل یکی از پیشرفته ترین مدل های پایه را با Gemini 2.0 ساخته است و یکی از بزرگترین رقبای OpenAI است.
آدی مشاهدات و پیشبینیهای خود را در مقاله مشکل ۷۰ درصد: حقایق سخت در مورد کدگذاری به کمک هوش مصنوعی خلاصه کرد . این یک برداشت مبتنی بر نقاط قوت و ضعف ابزارهای هوش مصنوعی است که محدودیتهای اساسی این ابزارها را برجسته میکند، و همچنین نکات مثبتی را که نمیتوان آنها را به عنوان یک مهندس قبول کرد بسیار خوب است. همچنین توصیه های عملی را برای مهندسان نرم افزار از خردسال تا ارشد در مورد چگونگی استفاده حداکثری از این ابزارها ارائه می دهد. با اجازه ادی، این یک نسخه ویرایش شده از مقاله او است که مجدداً منتشر شده است و نظرات من در پایان اضافه شده است. این موضوع شامل موارد زیر است:
- چگونه توسعه دهندگان واقعاً از هوش مصنوعی استفاده می کنند. کاربردهای بسیار متفاوت «bootstrappers» در مقابل «iterators». شاید دلیلی باشد که چرا یک ابزار بعید است برای هر دو گروه به یک اندازه خوب کار کند؟
- مشکل ۷۰ درصد: پارادوکس منحنی یادگیری هوش مصنوعی. چالشهای کمتر مورد بحث هوش مصنوعی: «پارادوکس دو قدم به عقب»، هزینه پنهان «سرعت هوش مصنوعی» و «پارادوکس دانش».
- آنچه در واقع کار می کند: الگوهای عملی. AI-اول پیش نویس، مکالمه مداوم و الگوهای “اعتماد اما تایید”.
- این برای توسعه دهندگان چه معنایی دارد؟ کوچک شروع کنید، مدولار بمانید و به تجربه خود اعتماد کنید.
- ظهور مهندسی نرم افزار عاملی. تغییر به همکاری با هوش مصنوعی، قابلیتهای چندوجهی، رویکردهای مستقل اما هدایتشده، و محیط توسعه «اول انگلیسی».
- بازگشت نرم افزار به عنوان یک صنعت؟ هنر گمشده لهستانی برای بازگشت، و رنسانس نرم افزار شخصی.
- افکار اضافی زمان خوبی برای تازه کردن آنچه که مهندسی نرم افزار واقعاً چیست و چگونه از دهه ۱۹۶۰ رویای عدم نیاز به توسعه دهنده بوده است. و با این حال، تقاضا برای مهندسان با تجربه می تواند در آینده به جای کاهش، افزایش یابد.
پس از گذراندن چند سال گذشته در توسعه با کمک هوش مصنوعی، متوجه الگوی جذابی شدم. در حالی که مهندسان گزارش می دهند که به طور چشمگیری با هوش مصنوعی کارآمدتر هستند، نرم افزار واقعی که ما روزانه استفاده می کنیم به نظر نمی رسد که به طور قابل توجهی بهتر شود. اینجا چه خبر است؟
فکر میکنم میدانم چرا، و پاسخ برخی از حقایق اساسی را در مورد توسعه نرمافزار نشان میدهد که باید آنها را در نظر بگیریم. بگذارید آنچه را که یاد گرفته ام به اشتراک بگذارم.
من دو الگوی متمایز را در نحوه استفاده تیم ها از هوش مصنوعی برای توسعه مشاهده کرده ام. بیایید آنها را «بوت استرپر» و «تکرارکننده» بنامیم. هر دو به مهندسان (و حتی کاربران غیر فنی) کمک می کنند تا فاصله ایده تا اجرا (یا MVP) را کاهش دهند.
۱. توسعه دهندگان واقعاً چگونه از هوش مصنوعی استفاده می کنند
The Bootstrappers: Zero to MVP
ابزارهایی مانند Bolt، v0 و هوش مصنوعی اسکرین شات به کد، انقلابی در نحوه بوت استرپ پروژه های جدید ایجاد می کنند. این تیم ها معمولا:
- با یک طرح یا مفهوم خشن شروع کنید
- از هوش مصنوعی برای ایجاد یک پایگاه کد اولیه کامل استفاده کنید
- نمونه اولیه کار را به جای چند هفته در چند ساعت یا چند روز دریافت کنید
- روی اعتبارسنجی و تکرار سریع تمرکز کنید
نتایج می تواند چشمگیر باشد. اخیراً یک توسعهدهنده انفرادی را تماشا کردم که از Bolt برای تبدیل طرح Figma به یک برنامه کاربردی وب در مدت زمان کوتاهی استفاده میکرد. آماده تولید نبود، اما به اندازه کافی خوب بود که بازخورد اولیه کاربران را دریافت کند.
Iterators: توسعه روزانه
کمپ دوم از ابزارهایی مانند Cursor، Cline، Copilot و WindSurf برای گردش کار توسعه روزانه خود استفاده می کند. این کمتر زرق و برق دار است اما به طور بالقوه دگرگون کننده تر است. این توسعه دهندگان عبارتند از:
- استفاده از هوش مصنوعی برای تکمیل کد و پیشنهادات
- استفاده از هوش مصنوعی برای وظایف پیچیده بازسازی
- تولید آزمون ها و مستندات
- استفاده از هوش مصنوعی به عنوان “برنامه نویس زوج” برای حل مسئله
اما نکته اینجاست: در حالی که هر دو رویکرد می توانند به طور چشمگیری توسعه را تسریع کنند، هزینه های پنهانی دارند که بلافاصله آشکار نمی شوند.
۲. مشکل ۷۰ درصد: پارادوکس منحنی یادگیری هوش مصنوعی
توییتی که اخیراً توجه من را به خود جلب کرد ، کاملاً آنچه را که در این زمینه مشاهده کردهام به تصویر میکشد: غیرمهندسهایی که از هوش مصنوعی برای کدنویسی استفاده میکنند، متوجه میشوند که به دیواری خستهکننده برخورد میکنند. آنها میتوانند بهطور شگفتآوری به سرعت ۷۰ درصد از مسیر را به آنجا برسانند، اما این ۳۰ درصد نهایی به تمرینی برای کاهش بازده تبدیل میشود.
این «مشکل ۷۰ درصدی» چیز مهمی را در مورد وضعیت فعلی توسعه با کمک هوش مصنوعی نشان می دهد. پیشرفت اولیه جادویی به نظر می رسد: می توانید آنچه را که می خواهید توصیف کنید و ابزارهای هوش مصنوعی مانند v0 یا Bolt یک نمونه اولیه کارآمد ایجاد می کنند که چشمگیر به نظر می رسد. اما سپس واقعیت به وجود می آید.
الگوی دو گام به عقب
آنچه معمولاً بعد اتفاق می افتد از یک الگوی قابل پیش بینی پیروی می کند:
- شما سعی می کنید یک اشکال کوچک را برطرف کنید
- هوش مصنوعی تغییری را پیشنهاد می کند که منطقی به نظر می رسد
- این اصلاح چیز دیگری را می شکند
- شما از هوش مصنوعی می خواهید که مشکل جدید را برطرف کند
- این دو مشکل دیگر ایجاد می کند
- بشویید و تکرار کنید
این چرخه مخصوصاً برای غیرمهندسها دردناک است، زیرا آنها فاقد مدلهای ذهنی برای درک اینکه واقعاً چه چیزی اشتباه پیش میرود، نیستند. وقتی یک توسعهدهنده با تجربه با یک باگ مواجه میشود، میتواند بر اساس سالها تشخیص الگو، دلایل و راهحلهای احتمالی را استدلال کند. بدون این پس زمینه، شما اساساً با کدهایی که کاملاً درک نمی کنید بازی می کنید.
هزینه پنهان “سرعت هوش مصنوعی”
وقتی کار یک مهندس ارشد را با ابزارهای هوش مصنوعی مانند مکاننما یا Copilot تماشا میکنید، به نظر جادو میرسد. آنها میتوانند تمام ویژگیها را در عرض چند دقیقه، با آزمایشها و مستندات تکمیل کنند. اما با دقت تماشا کنید، متوجه یک چیز مهم خواهید شد: آنها فقط آنچه را که هوش مصنوعی پیشنهاد می کند نمی پذیرند. آنها دائماً:
- تبدیل مجدد کد تولید شده به ماژول های کوچکتر و متمرکز
- اضافه کردن لبه مورد رسیدگی به هوش مصنوعی از دست رفته
- تقویت تعاریف نوع و رابط
- زیر سوال بردن تصمیمات معماری
- افزودن مدیریت جامع خطا
به عبارت دیگر، آنها از سال ها خرد مهندسی که به سختی به دست آمده اند برای شکل دادن و محدود کردن خروجی هوش مصنوعی استفاده می کنند. هوش مصنوعی به پیاده سازی سرعت می بخشد، اما تخصص آنها چیزی است که کد را قابل نگهداری نگه می دارد.
مهندسان جوان اغلب این مراحل مهم را از دست می دهند. آنها خروجی هوش مصنوعی را راحتتر میپذیرند، و منجر به چیزی میشود که من آن را «کد خانه کارتها» مینامم – کامل به نظر میرسد اما تحت فشار دنیای واقعی فرو میریزد.
شکاف دانش
موفق ترین غیرمهندس هایی که از ابزارهای کدنویسی هوش مصنوعی استفاده می کنند، رویکرد ترکیبی دارند:
- از هوش مصنوعی برای نمونه سازی سریع استفاده کنید
- برای درک نحوه عملکرد کد تولید شده زمان بگذارید
- مفاهیم اولیه برنامه نویسی را در کنار استفاده از هوش مصنوعی بیاموزید
- به تدریج پایه ای از دانش بسازید
- از هوش مصنوعی به عنوان یک ابزار یادگیری استفاده کنید، نه فقط یک تولید کننده کد
اما این نیاز به صبر و فداکاری دارد، که دقیقاً برعکس چیزی است که بسیاری از افراد در وهله اول امیدوارند با استفاده از ابزارهای هوش مصنوعی به آن دست یابند.
پارادوکس دانش
در اینجا غیرقابل تصورترین چیزی است که من کشف کرده ام: ابزارهای هوش مصنوعی بیشتر از مبتدیان به توسعه دهندگان با تجربه کمک می کنند. این عقب مانده به نظر می رسد. آیا هوش مصنوعی نباید کدنویسی را دموکراتیک کند؟
واقعیت این است که هوش مصنوعی مانند داشتن یک توسعه دهنده جوان بسیار مشتاق در تیم شماست. آنها می توانند به سرعت کد بنویسند، اما نیاز به نظارت و اصلاح مداوم دارند. هرچه بیشتر بدانید، بهتر می توانید آنها را راهنمایی کنید.
این چیزی را ایجاد می کند که من آن را “پارادوکس دانش” می نامم:
- سالمندان از هوش مصنوعی برای سرعت بخشیدن به کارهایی که قبلاً می دانند چگونه انجام دهند استفاده می کنند
- نوجوانان سعی می کنند از هوش مصنوعی استفاده کنند تا یاد بگیرند چه کاری انجام دهند
- نتایج به طور چشمگیری متفاوت است
من مهندسان ارشد را مشاهده کردهام که از هوش مصنوعی برای موارد زیر استفاده میکنند:
- ایدههایی را که قبلاً درک کردهاند، به سرعت نمونهسازی میکنند
- پیاده سازی های اساسی را ایجاد کنید و سپس آنها را اصلاح کنید
- رویکردهای جایگزین برای مشکلات شناخته شده را بررسی کنید
- کارهای برنامه نویسی روتین را به صورت خودکار انجام دهید
در همین حال، نوجوانان اغلب:
- راه حل های نادرست یا قدیمی را بپذیرید
- ملاحظات مهم امنیتی و عملکرد را فراموش نکنید
- تلاش برای رفع اشکال کدهای تولید شده توسط هوش مصنوعی
- سیستم های شکننده ای بسازید که به طور کامل درک نمی کنند
یک مسئله عمیقتر در اینجا وجود دارد: همان چیزی که ابزارهای کدنویسی هوش مصنوعی را برای غیر مهندسان قابل دسترسی میکند، توانایی آنها در رسیدگی به پیچیدگیها از طرف شما، در واقع میتواند مانع یادگیری شود. زمانی که کد فقط بدون اینکه اصول اساسی را درک کنید، ظاهر می شود:
- شما مهارت های اشکال زدایی را توسعه نمی دهید
- یاد گرفتن الگوهای اساسی را از دست می دهید
- شما نمی توانید در مورد تصمیمات معماری استدلال کنید
- شما برای حفظ و تکامل کد تلاش می کنید
این یک وابستگی ایجاد میکند که در آن باید به جای توسعه تخصص برای رسیدگی به مشکلات، به هوش مصنوعی برای رفع مشکلات ادامه دهید.
پیامدهایی برای آینده
این “مشکل ۷۰٪” نشان می دهد که ابزارهای کدگذاری AI فعلی به بهترین وجه به صورت زیر مشاهده می شوند:
- نمونه سازی شتاب دهنده برای توسعه دهندگان با تجربه
- کمک های آموزشی برای کسانی که متعهد به درک توسعه هستند
- مولدهای MVP برای اعتبارسنجی سریع ایده ها
اما آنها هنوز راه حلی برای دموکراتیزاسیون کدنویسی نیستند که خیلی ها به آن امیدوار بودند. ۳۰ درصد نهایی، بخشی که تولید نرم افزار را آماده، قابل نگهداری و قوی می کند، همچنان به دانش مهندسی واقعی نیاز دارد.
خبر خوب؟ این شکاف احتمالاً با بهبود ابزارها کاهش خواهد یافت. اما در حال حاضر، عملی ترین رویکرد استفاده از هوش مصنوعی برای تسریع یادگیری است، نه جایگزینی کامل آن.
۳. آنچه در واقع کار می کند: الگوهای عملی
پس از مشاهده دهها تیم، در اینجا چیزی است که من به طور مداوم کار کردهام:
الگوی “هوش مصنوعی اولین پیش نویس”.
اجازه دهید هوش مصنوعی یک پیاده سازی اساسی ایجاد کند
- بررسی دستی و اصلاح کننده برای مدولار بودن
- مدیریت جامع خطا را اضافه کنید
- تست های کامل بنویسید
- تصمیمات کلیدی را مستند کنید
الگوی “مکالمه مداوم”.
برای هر کار مشخص، چت های هوش مصنوعی جدید را شروع کنید
- زمینه را متمرکز و حداقل نگه دارید
- تغییرات را مرتباً مرور و انجام دهید
- حلقه های بازخورد محکم را حفظ کنید
الگوی «اعتماد کن اما تأیید کن».
- برای تولید کد اولیه از هوش مصنوعی استفاده کنید
- تمام مسیرهای حیاتی را به صورت دستی مرور کنید
- آزمایش خودکار لبهها را انجام دهید
- ممیزی های امنیتی منظم را اجرا کنید
۴. این برای توسعه دهندگان چه معنایی دارد؟
با وجود این چالش ها، من به نقش هوش مصنوعی در توسعه نرم افزار خوشبین هستم. نکته کلیدی درک این موضوع است که واقعاً برای چه چیزی مفید است:
- شتاب دادن به معلوم. هوش مصنوعی در کمک به ما در پیادهسازی الگوهایی که قبلاً درک کردهایم عالی است. این مانند داشتن یک برنامه نویس جفت صبور بی نهایت است که می تواند خیلی سریع تایپ کند.
- کاوش در امر ممکن هوش مصنوعی برای نمونه سازی سریع ایده ها و کاوش در رویکردهای مختلف عالی است. مانند داشتن یک جعبه شنی است که می توانیم به سرعت مفاهیم را آزمایش کنیم.
- خودکار کردن روال هوش مصنوعی زمان صرف شده در دیگ بخار و کارهای کدگذاری معمول را به طور چشمگیری کاهش می دهد و به ما امکان می دهد روی مشکلات جالب تمرکز کنیم.
اگر به تازگی توسعه با کمک هوش مصنوعی را شروع کرده اید، توصیه من در اینجا است:
از کوچک شروع کنید
- از هوش مصنوعی برای کارهای جدا شده و به خوبی تعریف شده استفاده کنید
- هر خط کد تولید شده را مرور کنید
- به تدریج ویژگی های بزرگتر را ایجاد کنید
مدولار بمانید
- همه چیز را به فایل های کوچک و متمرکز تقسیم کنید
- رابط های واضح بین اجزا را حفظ کنید
- مرزهای ماژول خود را مستند کنید
به تجربه خود اعتماد کنید
- از هوش مصنوعی برای تسریع و نه جایگزین کردن قضاوت خود استفاده کنید
- کد ایجاد سوال که اشتباه است
- استانداردهای مهندسی خود را حفظ کنید
۵. ظهور مهندسی نرم افزار عامل
چشم انداز توسعه به کمک هوش مصنوعی با رفتن به سال ۲۰۲۵ به طرز چشمگیری در حال تغییر است. در حالی که ابزارهای فعلی قبلاً نحوه نمونه سازی و تکرار ما را تغییر داده اند، من معتقدم که ما در آستانه یک تحول مهم تر هستیم: ظهور مهندسی نرم افزار عاملی. .
منظور من از “عامل” چیست؟ این سیستمها میتوانند بهجای پاسخگویی به درخواستها، راهحلها را با افزایش استقلال برنامهریزی، اجرا و تکرار کنند.
اگر علاقه مند به یادگیری بیشتر در مورد عوامل، از جمله برداشت من از Cursor/Cline/v0/Bolt هستید، ممکن است به صحبت اخیر من در JSNation در بالا علاقه مند باشید .
ما در حال حاضر نشانه های اولیه این تکامل را می بینیم:
از پاسخ دهندگان گرفته تا همکاران
ابزارهای فعلی بیشتر منتظر دستورات ما هستند. اما به ویژگیهای جدیدتر مانند استفاده از رایانه Anthropic در کلود، یا توانایی Cline برای راهاندازی خودکار مرورگرها و اجرای آزمایشها نگاه کنید. اینها فقط تکمیل خودکار تجلیل شده نیستند. آنها در واقع وظایف را درک می کنند و برای حل مشکلات پیشقدم می شوند.
به اشکالزدایی فکر کنید: به جای اینکه فقط راهحلهایی را پیشنهاد کنند، این عوامل میتوانند:
- به طور فعال مشکلات احتمالی را شناسایی کنید
- مجموعه های آزمایشی را راه اندازی و اجرا کنید
- عناصر UI را بررسی کنید و از صفحه نمایش عکس بگیرید
- پیشنهاد و اجرای اصلاحات
- کار راه حل ها را تأیید کنید (این می تواند یک مشکل بزرگ باشد)
آینده چندوجهی
نسل بعدی ابزارها ممکن است بیشتر از کار با کد انجام دهند. آنها می توانند به طور یکپارچه ادغام کنند:
- درک بصری (تصاویر UI، مدلها، نمودارها)
- مکالمات زبان کلامی
- تعامل محیطی (مرورگرها، پایانهها، APIها)
این قابلیت چندوجهی به این معنی است که آنها می توانند نرم افزار را به روشی که انسان ها انجام می دهند درک کرده و با آن کار کنند: به طور کلی، نه فقط در سطح کد.
خودمختار اما هدایت شده
بینش کلیدی که من از کار با این ابزارها به دست آوردهام این است که آینده این نیست که هوش مصنوعی جایگزین توسعهدهندگان شود. این در مورد این است که هوش مصنوعی تبدیل به یک همکار با توانایی فزاینده می شود که می تواند در عین احترام به راهنمایی ها و تخصص انسانی، ابتکار عمل را در دست بگیرد.
موثرترین تیم ها در سال ۲۰۲۵ ممکن است آنهایی باشند که یاد بگیرند:
- مرزها و دستورالعمل های واضحی را برای عوامل هوش مصنوعی آنها تعیین کنید
- الگوهای معماری قوی ایجاد کنید که عوامل بتوانند در آن کار کنند
- حلقه های بازخورد موثری بین توانایی های انسان و هوش مصنوعی ایجاد کنید
- نظارت انسانی را حفظ کنید و از استقلال هوش مصنوعی استفاده کنید
اولین محیط توسعه انگلیسی
همانطور که آندری کارپاتی خاطرنشان کرد :
داغ ترین زبان برنامه نویسی جدید انگلیسی است.
این یک تغییر اساسی در نحوه تعامل ما با ابزارهای توسعه است. توانایی تفکر واضح و برقراری ارتباط دقیق به زبان طبیعی به اندازه مهارت های کدگذاری سنتی اهمیت پیدا می کند.
این تغییر به سمت توسعه عاملی مستلزم آن است که مهارت های خود را توسعه دهیم:
- طراحی سیستم و تفکر معماری قوی تر
- مشخصات و ارتباطات بهتر مورد نیاز
- تمرکز بیشتر بر تضمین کیفیت و اعتبارسنجی
- افزایش همکاری بین انسان و قابلیتهای هوش مصنوعی
۶. بازگشت نرم افزار به عنوان کاردستی؟
در حالی که هوش مصنوعی ساخت سریع نرمافزار را آسانتر از همیشه کرده است، ما در خطر از دست دادن چیزی مهم هستیم: هنر ایجاد تجربیات واقعاً صیقلی و با کیفیت مصرفکننده.
تله کیفیت آزمایشی
این در حال تبدیل شدن به یک الگو است: تیم ها از هوش مصنوعی برای ساخت سریع دموهای چشمگیر استفاده می کنند. مسیر شاد به زیبایی کار می کند. سرمایه گذاران و شبکه های اجتماعی شگفت زده شده اند. اما چه زمانی کاربران واقعی شروع به کلیک کردن در اطراف می کنند؟ آن وقت است که همه چیز به هم می ریزد.
من این را از نزدیک دیدم:
- پیام های خطایی که برای کاربران عادی بی معنی است
- موارد لبه ای که برنامه را خراب می کند
- حالت های گیج کننده UI که هرگز پاک نمی شوند
- دسترسی کاملاً نادیده گرفته شد
- مشکلات عملکرد در دستگاه های کندتر
اینها فقط باگ های P2 نیستند. آنها تفاوت بین نرم افزاری است که مردم تحمل می کنند و نرم افزاری که مردم دوست دارند.
هنر گمشده لهستانی
ایجاد نرمافزار واقعی خود خدمت، نوعی که کاربران هرگز نیازی به تماس با پشتیبانی ندارند، به طرز فکر متفاوتی نیاز دارد:
- وسواس در مورد پیام های خطا
- تست روی اتصالات کند
- با ظرافت با هر لبه برخورد کنید
- قابل کشف کردن ویژگی ها
- آزمایش با کاربران واقعی، اغلب غیر فنی
این نوع توجه به جزئیات (شاید) نمی تواند توسط هوش مصنوعی ایجاد شود. این ناشی از همدلی، تجربه و مراقبت عمیق در مورد هنر است.
رنسانس نرم افزارهای شخصی
من معتقدم که ما شاهد رنسانس توسعه نرم افزار شخصی خواهیم بود. از آنجایی که بازار مملو از MVP های تولید شده توسط هوش مصنوعی می شود، محصولاتی که برجسته می شوند محصولاتی هستند که توسط توسعه دهندگان ساخته شده اند که:
- به هنر آنها افتخار کنید
- به جزئیات کوچک اهمیت دهید
- روی تجربه کامل کاربر تمرکز کنید
- برای لبه ها بسازید
- تجارب واقعی خود را ایجاد کنید
کنایه؟ ابزارهای هوش مصنوعی ممکن است در واقع این رنسانس را فعال کنند. آنها با انجام وظایف برنامهنویسی روتین، توسعهدهندگان را آزاد میکنند تا روی مهمترین چیز تمرکز کنند: ایجاد نرمافزاری که واقعاً به کاربران خدمت میکند و آنها را خوشحال میکند.
خط پایین
هوش مصنوعی نرمافزار ما را بهطور چشمگیری بهتر نمیکند، زیرا کیفیت نرمافزار (شاید) هرگز با سرعت کدنویسی محدود نشده است. بخشهای سخت توسعه نرمافزار – درک الزامات، طراحی سیستمهای قابل نگهداری، رسیدگی به موارد لبه، تضمین امنیت و عملکرد – هنوز نیاز به قضاوت انسانی دارد.
کاری که هوش مصنوعی انجام می دهد این است که به ما اجازه می دهد سریعتر تکرار و آزمایش کنیم، که به طور بالقوه منجر به راه حل های بهتر از طریق اکتشاف سریع تر می شود. اما این تنها در صورتی اتفاق می افتد که ما رشته مهندسی خود را حفظ کنیم و از هوش مصنوعی به عنوان یک ابزار استفاده کنیم، نه به عنوان جایگزینی برای شیوه های نرم افزاری خوب. به یاد داشته باشید: هدف نوشتن کدهای بیشتر سریعتر نیست. این برای ساختن نرم افزار بهتر است. با استفاده عاقلانه، هوش مصنوعی می تواند به ما در انجام این کار کمک کند. اما هنوز به ما بستگی دارد که بدانیم «بهتر» به چه معناست و چگونه آن را بدست آوریم.
افکار اضافی
باز هم گرگی از شما متشکریم، ادی، برای این خلاصه عملگرایانه در مورد چگونگی تجدید نظر در انتظارات خود در زمینه هوش مصنوعی و مهندسی نرم افزار. اگر از این قطعه از ادی لذت بردید، مقالات دیگر و آخرین کتاب او را بررسی کنید : تیمهای مهندسی مؤثر پیشرو .
در اینجا نظرات اضافی من در مورد هوش مصنوعی و مهندسی نرم افزار وجود دارد.
زمان خوبی برای تازه کردن آنچه واقعاً مهندسی نرم افزار است
بیشتر افشای ابزارهای هوش مصنوعی برای مهندسی نرمافزار بر قابلیتهای تولید کد متمرکز است و به درستی هم همینطور است. ابزارهای هوش مصنوعی در تولید کدهای کاری از طریق اعلان ها یا پیشنهاد کدهای درون خطی هنگام ساختن نرم افزار، چشمگیر هستند. اما چه مقدار از فرآیند ساخت نرم افزار مربوط به خود کدنویسی است؟ حدود ۵۰ سال پیش، فرد بروکس فکر می کرد که حدود ۱۵ تا ۲۰ درصد از کل زمان صرف شده است. در اینجا افکار بروکس از ماه مرد اسطوره ای آمده است :
“برای چند سال، من با موفقیت از قانون سرانگشتی زیر برای برنامه ریزی یک کار نرم افزاری استفاده می کنم:
⅓ برنامه ریزی
⅙ کد نویسی
¼ تست جزء و تست اولیه سیستم
¼ تست سیستم، همه اجزا در دست.
برداشت من این است که امروزه مهندسان نرم افزار احتمالاً وقت خود را اینگونه می گذرانند:
- ۲۰ درصد برنامه ریزی
- ۴۰% کدگذاری (کد + تست)
- بررسی کد ۲۰% (کد دیگران)
- ۲۰% آمادگی تولید + عرضه + اصلاحات کوچک در این مدت + نظارت + هشدار
در عین حال، ساختن نرمافزار برجسته دارای بخشهای زیادی است:
- چه : بفهمید چه چیزی بسازید. این می تواند شامل طوفان فکری، طراحی، آزمایش کاربر، کار با مدیران محصول و سهامداران تجاری و غیره باشد. برای استارتآپها، این مرحله زمان بسیار کمی میبرد («فقط آن را بسازید و ببینید که آیا کار میکند یا نه!»). برای شرکتهای مستقر، ممکن است زمان بیشتری نسبت به ساختن زمان ببرد (“ما باید مطمئن شویم آنچه میسازیم مشتریان فعلی ما را گیج نمیکند!”).
- چگونه: طرحی در مورد نحوه ساخت محصول/ویژگی/خدمت تهیه کنید. به مفاهیم معماری، وابستگی ها، نحوه آزمایش محصول و غیره فکر کنید. باز هم، استارت آپ ها ممکن است بتوانند از این مرحله بگذرند و تیم می تواند مستقیماً به سمت برنامه ریزی بپرد. اما برای شرکتهای بزرگتر با خدمات و وابستگیهای بیشتر، کنار گذاشتن برنامهریزی به تیم بازمیگردد. بنابراین اکثر تیم ها نوعی برنامه ریزی را با استفاده از اسناد طراحی، RFC یا ADR انجام می دهند.
- ساخت: ویژگی یا محصول را پیاده سازی کنید: کد را بنویسید و مطمئن شوید که کار می کند.
- تأیید کنید : قبل از ارسال به تولید، دوباره بررسی کنید که مطابق انتظار کار می کند. این امر به ویژه در مواردی که حمل و نقل با ریسک بالایی همراه است مهم است: به عنوان مثال، ارسال یک رگرسیون به یک برنامه بانکی می تواند پیامدهای مالی برای مشتریان و کسب و کار داشته باشد! ما به جزئیات مربوط به QA در QA در صنعت فناوری پرداختیم .
- ارسال آن : تغییر را ادغام کنید و برای مشتریان ارسال کنید. استراتژی های زیادی برای انتقال تغییرات به تولید وجود دارد. ما چندین مورد از این موارد را در حمل و نقل تا تولید پوشش دادیم.
- مانیتورینگ و حضوری: تشخیص دهید که مشکلی در محصول وجود دارد. اگر قطعی وجود دارد، آن را در اسرع وقت برطرف کنید، و سپس مطمئن شوید که قطعی مشابه دیگر تکرار نخواهد شد. ما این رویکردهای متداول را در شیوههای حضوری سالم و در بررسی رویداد و بهترین شیوههای پس از مرگ بررسی کردیم .
- نگهداری: به شکایات و بازخوردهای مشتریان گوش دهید و تصمیم بگیرید که کدام باگ ها رفع آنها را تضمین می کند و کدامیک از درخواست های ویژگی برای اولویت بندی هستند. و بفهمید که چه بازخوردی را نادیده بگیرید.
- مهاجرت : اگر محصول تحت تغییرات بزرگ قرار گیرد، یا اگر پشته فناوری تغییرات عمده ای را ببیند – مانند یک چارچوب جدید – ممکن است نیاز به مهاجرت داشته باشد. ما موارد بیشتری را در مهاجرت به خوبی پوشش دادیم .
ابزارهای هوش مصنوعی امروزه می توانند به بخش «Build» کمک زیادی کنند. اما اینجا یک سوال خوب وجود دارد: آنها چقدر برای ۷ مورد دیگر که بخشی از مهندسی نرم افزار هستند مفید هستند؟
بدون نیاز به توسعه دهنده: رویایی از دهه ۱۹۶۰
افراد غیر فنی ایجاد نرم افزار کار بدون نیاز به تکیه بر توسعه دهندگان نرم افزار رویای از دهه ۱۹۶۰ بوده است. برنامه نویسی در مورد ترجمه از آنچه مردم می خواهند (مشتریان، سهامداران کسب و کار، مدیر محصول و غیره) به آنچه رایانه می فهمد است. LLM ها سطح بالاتری از انتزاع را به ما ارائه می دهند که می توانیم انگلیسی را به کد تبدیل کنیم. با این حال، این انتزاع جدید ماهیت نحوه ایجاد نرم افزار را تغییر نمی دهد – و نرم افزار چیست – که این است:
ابزارهای GenAI روند را تغییر نمی دهند، اما برخی از بخش های کدنویسی را کارآمدتر می کنند:
در طول تاریخ فناوری، نوآوریهای جدید این توانایی را برای افراد تجاری نوید میداد که بخش «تکنولوژی» را کنار بزنند یا از کنار آن عبور کنند و مستقیماً از درخواستهای سطح بالای خود به نرمافزارهای کارآمد برسند. این آرمان بود:
- دهه ۱۹۶۰: زبان برنامه نویسی سطح بالا COBOL . COBOL مخفف “زبان مشترک و کسب و کار محور” است. هدف اعلام شده این زبان این بود که به افراد تجاری بدون پیشینه برنامه نویسی اجازه استفاده از آن را بدهد.
- دهه ۱۹۹۰: ویژوال بیسیک . یک زبان برنامه نویسی برای داشتن منحنی یادگیری بسیار کم، به علاوه یک محیط بصری که در آن فرم ها را می توان با کشیدن و رها کردن ایجاد کرد.
- اواخر دهه ۲۰۱۰: جنبش بدون کد . از طریق قالب ها و ویرایش بصری، راه حل های بدون کد مانند Bubble راهی برای ساخت برنامه های نرم افزاری ارائه می دهند.
جای تعجب نیست که چندین استارت آپ برنامه نویسی GenAI در آرزوی یک هدف هستند: اجازه دادن به هر کسی برای ایجاد نرم افزار با استفاده از زبان انگلیسی. در گذشته، ما شاهد موفقیت برای موارد استفاده ساده تر بوده ایم. به عنوان مثال، این روزها برای ایجاد یک وب سایت نیازی به دانش کدنویسی نیست: افراد غیر فنی می توانند از ویرایشگرها و سرویس های بصری مانند Wix.com، Webflow، Ghost یا WordPress استفاده کنند.
هر چه انتزاع سطح بالاتری داشته باشد، تعیین اینکه نرم افزار دقیقاً چگونه باید کار کند دشوارتر است . راهحلهای بدون کد قبلاً با این محدودیت مواجه بودند. همانطور که CTO مشاور الکس هادسون در مقاله خود توهم بدون کد می نویسد :
«توسعه این نحوها عموماً با مشکل بیان مواجه شده است: هنگامی که به اندازه کافی ساده باشند تا سریعاً قابل برداشت باشند، دیگر برای استفاده در بسیاری از سناریوها به اندازه کافی رسا نیستند. و بالعکس: برخی از زبان ها توانایی تعریف یک زبان سفارشی را در درون خود دارند که به آن زبان های دامنه خاص (DSL) می گویند. تعداد کمی از این زبانها تا به حال در میان جامعه توسعهدهنده به طور کلی موفق بودهاند، عمدتاً به این دلیل که دوباره کار را بسیار پیچیده میکنند.»
برای نرمافزارهای پیچیدهتر، سخت است که نیازی به مهندسان نرمافزار در برنامهریزی، ساخت و نگهداری نرمافزار نداشته باشیم. و هرچه GenAI موانع افراد غیر فنی را برای ایجاد نرم افزار کاهش دهد، نرم افزار بیشتری برای نگهداری وجود خواهد داشت.
عوامل هوش مصنوعی: یک وعده بزرگ، اما همچنین یک “ناشناخته” بزرگ برای سال ۲۰۲۵
دو سال پس از راهاندازی LLM، بسیاری از ما در مورد چگونگی استفاده از آنها برای تقویت برنامهنویسی و کار مهندسی نرمافزار خود به خوبی دست پیدا کردهایم. آنها برای نمونه سازی، جابجایی به زبان های کمتر آشنا و کارهایی که می توانید صحت آنها را تأیید کنید و توهم یا خروجی نادرست را فراخوانی کنید عالی هستند.
از سوی دیگر، عوامل هوش مصنوعی در مراحل ابتدایی خود هستند. بسیاری از ما به طور گسترده از آنها استفاده نکرده ایم. تنها یک نماینده به طور کلی در دسترس است، Devin ، با ۵۰۰ دلار در ماه، و پاسخ های اولیه متفاوت است .
سرمایه گذاری خطرپذیر زیادی به این حوزه سرازیر خواهد شد. ما شاهد راه اندازی ابزارهای عامل کدنویسی هوش مصنوعی بیشتری خواهیم بود و در نتیجه مطمئناً قیمت نیز کاهش خواهد یافت. احتمالاً GitHub Copilot چیزی مانند Copilot Workspace (رویکردی نمایندگی) را به طور کلی در سال ۲۰۲۵ در دسترس خواهد داشت. و احتمالاً محصولاتی از استارتاپهایی مانند آنچه که مدیر ارشد فناوری سابق Stripe، دیوید سینگلتون تأسیس کرد ( /dev/agents ) خواهیم دید .
عوامل هوش مصنوعی تأخیر و هزینه (زمان بسیار طولانی تری را که صرف نتایج محاسباتی و اجرای چندین بار دستورات می شود، که توسط این استارتاپ ها به عنوان “تفکر” تعبیر می شود) را با دقت (نتایج بهتر، بر اساس درخواست ها) عوض می کنند. چند سؤال خوب در مورد اینکه چقدر دقت با این تأخیر + هزینه معاوضه بهبود مییابد، و اینکه چه موارد استفاده مهندسی در نتیجه افزایش بهرهوری قابل توجهی را شاهد خواهند بود، وجود دارد.
تقاضا برای مهندسان نرم افزار با تجربه می تواند افزایش یابد
مهندسان نرم افزار با تجربه می توانند در آینده نسبت به امروز تقاضای بیشتری داشته باشند. موضوع رایجی که با ابزارهای هوش مصنوعی می بینیم این است که چگونه مهندسان ارشد و بالاتر می توانند از این ابزارها به طور موثرتر استفاده کنند، زیرا می توانند بهتر با آنها “هدف گیری” کنند. هنگامی که میدانید «خروجی عالی» چگونه به نظر میرسد، میتوانید بهتر درخواست دهید، تولید کد را در زمانی که مشکل پیش میآید متوقف کنید، و میتوانید بدانید چه زمانی درخواست را متوقف کنید و مستقیماً به سراغ کد منبع بروید تا خود کد را اصلاح کنید.
ما شاهد تولید کدهای بسیار بیشتری با کمک این ابزارهای هوش مصنوعی خواهیم بود و افراد و مشاغل بیشتری شروع به ساخت راه حل های خود می کنند. از آنجایی که این راهحلها به سطحی از پیچیدگی میرسند، این یک شرط مطمئن است که بسیاری از آنها در تلاش برای کاهش پیچیدگی، باید افراد حرفهای را وارد کنند: پیچیدگیای که نیاز به مهندسان با تجربه برای مقابله با آن دارد. شرکت های فناوری موجود تقریباً به طور قطع کد بیشتری را با ابزارهای هوش مصنوعی تولید خواهند کرد: و برای مقابله با افزایش پیچیدگی که لزوماً به دنبال دارد، به مهندسان با تجربه متکی خواهند بود.
بهعنوان یک مهندس نرمافزار، تسلط بر توسعه به کمک هوش مصنوعی، شما را بهرهورتر و همچنین ارزشمندتر میکند. این زمان هیجان انگیزی برای کار در این زمینه است: ما در دوران نوآوری ابزارسازی شتابان زندگی می کنیم. فهمیدن اینکه چگونه ابزارهای فعلی را به گونهای «رام کنید» زمان میبرد که بیشترین بهرهوری را داشته باشید: پس با آنها آزمایش کنید!
امیدوارم رویکردهای عملی Addy برای شما مفید بوده باشد. برای نکات بیشتر، به موضوع AI Tooling for Software Engineers in 2024: Reality Check مراجعه کنید .
