توسعه دهندگان به ابزارها متصل هستند زیرا ابزارها اعتماد را رمزگذاری می کنند

About six years ago, we ran a piece about IDEs که در آن اصل این بود که IDE ها آنقدر قدرتمند و توانا می شدند که جای تعجب بود که هر کسی از Vim یا Emacs مانند یک غارنشین استفاده می کرد. در حالی که بله، این یک مقاله تحریک آمیز بود، اما خیلی از توسعه دهندگان را عصبانی کرد. نظرات از هر دو طرف آمده است، هم از طرف افرادی که مقاله را سطل زباله می‌کنند زیرا نمی‌دانند توسعه‌دهندگان چگونه کار می‌کنند، و هم از طرف توسعه‌دهندگانی که در تمام روز اخبار خوب درباره Emacs را موعظه می‌کنند. اما بیشتر بحث بزرگی در مورد اینکه چرا این ابزارها واقعا مفید هستند وجود داشت.

برای یک مبتدی، Vim و Emacs می‌توانند مانند برنامه‌های ترمینال غیرواقعی به نظر برسند که برای استفاده از آنها نیاز به به خاطر سپردن کلیدهای مخفی دارند (و escape). اما برای کاربر باتجربه، می تواند به اندازه تفکر طبیعی احساس کند. یک نظر به The Pragmatic Programmer توسط دیوید توماس و اندرو هانت، که توضیح می دهد که توسعه دهندگان – صنعتگرانی که they are (or were)—نیاز به “ابزارهای تیز” دارند که مانند امتداد دستشان باشد. Vim و Emacs با قابلیت شخصی‌سازی بی‌پایان خود، می‌توانند دقیقاً متناسب با دست و گردش کار شما قالب‌گیری شوند. صرف زمان برای ایجاد مهارت و اعتماد به ابزارهای خود، و همچنین هک کردن آنها برای شما، سود زیادی را به همراه دارد.

در این دوره از مهندسی مبتنی بر عامل، ابزارهای جدید پایانه هایی هستند که شما با آنها به زبان طبیعی صحبت می کنید. یک عامل برنامه نویسی فاقد دقت و ویژگی برنامه نویسی است که به خوبی کد می نویسد، اما می تواند کل برنامه ها را در کسری از زمان اجرا کند. سوالی که امروزه همچنان مطرح است این است که آیا می توان به این نتایج اعتماد کرد؟ Our last Developer Survey متوجه شد که هر چه توسعه دهندگان بیشتر از هوش مصنوعی استفاده کنند، کمتر به آن اعتماد می کنند – میزان استفاده از 76٪ به 84٪ افزایش می یابد، اما اعتماد از 40٪ به 29٪ کاهش می یابد.

خود ابزارها جدید هستند و قابلیت های آنها در جریان است. اگر چاقوی آشپزخانه شما مدام در حال تغییر شکل، وزن و لبه است، باید هر بار آن را دوباره یاد بگیرید. این ابزار دشواری برای ایجاد اعتماد است. اما همچنین به یک نقص در نحوه استفاده از آن ابزار، فرآیند پیرامون آن و روشی که ابزار فرآیند را تقویت می کند، اشاره می کند. شما به چاقوی مورد علاقه خود، IDE، قلم مو یا هر چیز دیگری به دلیل اعتمادی که با آن و فرآیند اطراف آن ایجاد کرده اید اعتماد دارید.

در این مقاله، نحوه ایجاد فرآیندهای قابل اعتماد توسط ابزارها، روش‌هایی که تغییرات در ابزارها برجسته می‌شوند، اما نمی‌توانند فرآیندهای شکسته را برطرف کنند، و جایی که ابزارها و فرهنگ می‌توانند با یکدیگر برای ایجاد اعتماد جدید کار کنند، خواهیم دید.

ابزارهای توسعه‌دهنده با توسعه نرم‌افزار به‌عنوان یک کل، و همچنین با توسعه‌دهندگان فردی کار می‌کنند و تکامل می‌یابند. اگر شروع به کار و یادگیری در یک ترمینال کنید، شاید در همان روزگاری که IDE یا رابط کاربری گرافیکی وجود نداشت، پس روشی که ایجاد کد را درک می کنید شامل آن پایانه ها و ویرایشگرهای متن ترمینال می شود. افزودن یک IDE نه تنها به یادگیری یک ابزار جدید نیاز دارد، بلکه نیاز به طراحی مجدد فرآیند نوشتن کد شما دارد.

اگر جابجایی از ترمینال به یک IDE یک تغییر فرآیند دشوار است (یا به قول برخی غیر ضروری است)، تغییر از هر یک به یک ابزار کدگذاری مبتنی بر عامل دشوارتر است. “یکی از نگرانی های من در مورد پذیرش برخی از برنامه نویسی هوش مصنوعی این است که من با IDE خود سریع تر عمل می کنم زیرا می دانم چگونه کار می کند.” said Tricia Gee، مدافع بهره وری توسعه دهنده. “وقتی با افرادی که Vim و Emacs را به خوبی می‌شناسند، همین مورد را دیده‌ام. شما می‌توانید از ابزارهای refactoring در IntelliJ IDEA استفاده کنید. آنها مثل این هستند، بله، اما نیاز به یک منحنی یادگیری دارد. من زمان زیادی را صرف استفاده از هر ابزاری کرده‌ام. انگشتانم می‌دانند چه باید بکنم. درک یک ابزار بسیار خوب، مهم نیست که چه چیزی باشد، به یک مهارت تبدیل می‌شود.”

ایجاد آن حافظه عضلانی، آن دانش ضمنی از نحوه عملکرد نرم افزار در سطح کد، به توسعه دهندگان اجازه می دهد تا به ابزارهای خود برای کمک به ایجاد و بهبود کد خود اعتماد کنند. در همین حال، عوامل هوش مصنوعی سریع‌تر، غیرشفاف‌تر و کمتر قابل پیش‌بینی هستند. برای ایجاد نرم افزار به جای کد از زبان مبهم استفاده می کنید. “کد یک بیانیه راه حل دقیق است” said Bjarne Stoustrup، خالق C++. “انگلیسی یک زبان مزخرف برای بیان چیزهایی است که باید بدون ابهام باشد.” ابزار قابل اعتماد قابل پیش بینی، قابل اعتماد است. لازم نیست آن را به طور مکرر با Emacs یا Vim تکرار کنید.

با بیشتر ابزارهای توسعه‌دهنده، مانند IDE، ابزار کانتینری‌سازی یا تحلیلگر استاتیک، می‌دانید که مرزها کجا هستند. آنها نقش خود را دارند و فراتر از آن نمی روند. اما هوش مصنوعی راه خود را به تمام بخش‌های زنجیره ابزار SDLC باز کرده است. یعنی the reduced trust developers have in AI برای کل فرآیند اعمال می شود. ایجاد کد ممکن است سریع‌تر باشد، اما اعتبارسنجی آن، رساندن آن به نقطه‌ای که توسعه‌دهندگان بتوانند به آن اعتماد کنند، باعث ایجاد خطاهای پرهزینه تولید نمی‌شود و اغلب زمان بیشتری می‌برد.

ابزارهای کدنویسی مبتنی بر عامل در حال تغییر ماهیت فرآیند توسعه نرم افزار هستند. ابزارهایی که در حول و حوش فرآیند قبلی به وجود آمدند – لیترها، تست های واحد خودکار، CI/CD، و غیره – may not work in their current form با این روند تغییر یافته است.

این ابزارها فرآیند را رمزگذاری می‌کردند، اما خود فرآیند نبودند. یک ابزار عالی CI/CD به این معنی نیست که شما سریع‌تر ارسال می‌کنید. یک IDE عالی به این معنی نیست که کد بهتری نوشته اید. سیستم ردیابی مشکل با نکات تاریخی به این معنی نیست که شما به تلاش ها امتیاز خوبی داده اید. بخشی از این فرآیند به عنوان یک فرهنگ وجود داشت، به عنوان رفتار و هنجارهای افرادی که نرم افزار می سازند. ابزارهای جدید اغلب به معنای changing the organizational culture.

این داستان برای هر کسی که در سازمان های بزرگ مهندسی کار می کند آشنا خواهد بود. ابزارهای جدید، هر وعده ای که داشته باشند، زمانی که با فرهنگ ها و فرآیندهای موجود سازگار نباشند، ممکن است شکست بخورند. ابزارهای موفق نیاز به تغییر فرهنگ و فرآیند دارند به گونه ای که توسعه دهندگان آن را بپذیرند و درک کنند. همه شما عاشق خلق چیزها و حل مشکلات هستید، بنابراین ابزارهایی که به شما کمک نمی کنند بهتر است نادیده گرفته شوند.

کدگذاری عاملی به سرعت پذیرفته می شود زیرا به توسعه دهندگان اجازه می دهد مشکلات را سریعتر حل کنند. اما بسیاری از نقص‌ها را در فرآیندهای موجود که ایجاد کد تقریباً بی‌اهمیت می‌شد، آشکار کرد. همیشه مشکلی با unclear and shifting requirements اما اکنون حل یک مشکل نیاز به tightly defining “مشکل” و “راه حل” به چه معناست.

کد ممکن است (تقریبا) رایگان باشد، اما اعتبارسنجی اینطور نیست. گلوگاه جدید به بررسی کد تبدیل شده است. شوخی قدیمی این بود که اگر می خواهید یک PR سریع تایید شود، 100 خط را تغییر دهید. عوامل کد نویسی صدها خط کد را در یک لحظه تغییر می دهند و تفاوت های عظیم را برای بررسی (یا مهر) برای انسان ارسال می کنند. LLM-as-a-judge در اینجا به عنوان یک راه حل مقیاس پذیر در حال توسعه است، اما روش های مهندسی برای اعتماد به اینکه هوش مصنوعی می تواند کدهای نوشته شده توسط هوش مصنوعی را بررسی کند، کار می کند.

در همین راستا، کد اجرایی نیز رایگان نیست. شما هزینه زیرساخت را دارید که در عصر ابری عاملی در حجم محاسبات، حافظه و ترافیک مصرفی برنامه شما است. شما هزینه وابستگی ها و API های میزبانی شده خود را دارید. و شما هزینه شکست‌ها را دارید، سخت‌ترین چیز برای بودجه: خرابی، نقض امنیت و هزینه‌های فرصت. ابزارهایی که نرم افزار تولید می کنند که این هزینه ها را در نظر نمی گیرند (یا نمی توانند) ممکن است ارزشش را نداشته باشند. و آنها بر روندی که شما ساخته اید که برای تولید نرم افزار قابل اعتماد استفاده می شود فشار وارد می کنند.

برای بسیاری از افراد، SDLC به لطف کدنویسی عامل شروع به شکسته شدن کرده است. طبیعتاً، این افراد به دنبال ابزارهای جدیدی برای رفع این ترک‌ها هستند: AI SRE، بررسی خودکار کد، مدیریت حافظه و زمینه، بهبود سطح کنترل و مهار، و غیره. اما ابزارها به تنهایی مشکلات را حل نمی کنند، به خصوص اگر فرهنگ و روند یکسان باقی بماند. یک فرآیند شکسته با ابزارهای بهتر (که ممکن است مردم از آن استفاده نکنند) هنوز خراب است.

در SDLC قدیمی، مدیران محصول بر اساس تحقیقات خود، صحبت با مشتریان و درک رقبا، ویژگی ها و الزامات عملکرد را ارائه می کردند. معماران نرم افزار را بر اساس سال ها تجربه و درک خود از پشته فناوری موجود تعریف می کنند. مهندسان آن را می سازند و بر اساس دانش خود از منطق کد و پایگاه کد موجود، تعهدات را بررسی می کنند. QA بر اساس تجربه خود در مورد نحوه خراب شدن نرم افزار، نرم افزار را بررسی و تلاش خواهد کرد. پس از استقرار نرم افزار در تولید، DevOps و SRE عملکرد و منابع مورد استفاده را بر اساس تجربه قبلی خود نظارت و مدیریت خواهند کرد.

شما با کار کردن با مردم، درک نحوه تفکر آنها و محدود کردن راه هایی که هر فرد یا ابزاری می تواند سرکش باشد و سیستم را ویران کند، به این سیستم اعتماد ایجاد کردید. Building trust in an AI-enabled SDLC به همین چیزها نیاز دارد: کار با افراد و اطمینان از مسئولیت پذیری و مسئولیت پذیری آنها، به اشتراک گذاری گردش کار و تکرار آنها، و به حداقل رساندن فرصت برای اشتباهات.

اولین قدم این است که اطمینان حاصل کنیم که انسان‌ها را به عنوان طرف‌های مسئول در نظر می‌گیریم و توجه داشته باشیم که هوش مصنوعی در این امر مشارکت دارد. همه در مورد “مرد در حلقه” صحبت می کنند اما مانند Charity Majors, CTO of Honeycomb, pointed out، “Human-in-the-Loop شبیه یک دعوت رقت انگیز به نظر می رسد. من حلقه را ساختم، من مالک حلقه هستم، من تنها دلیل وجود این حلقه هستم. این حلقه لعنتی من است!” شخصی که commit را هل می دهد صاحب این کد است. افرادی که این روابط عمومی را تایید می کنند صاحب آن تایید هستند. اگر روز جمعه قبل از هوش مصنوعی شکست خوردید، IDE خود را سرزنش نکردید. اگر اکنون آن را بشکنید، مشکل عامل نیست. بین کیبورد و صندلی قرار دارد.

همکاری در عصر هوش مصنوعی می تواند یک چیز سخت تر و عجیب تر باشد. Agent ها به شما اجازه می دهند با انجام همه چیز از الزامات محصول گرفته تا DevOps در یک عامل برنامه نویسی، ایده توسعه fullstack چیست را گسترش دهید. توسعه دهندگان می توانند به راحتی به یک سیلو تبدیل شوند. “مثلاً لازم نیست با طراح خود در مورد طرح مشورت کنید زیرا فقط یک نماینده برای ایجاد طرح دارید.” said Jaime DeLanghe، مدیر ارشد محصول در Slack، “و شما مجبور نیستید با مهندس دیگری در یک دامنه خاص کار کنید تا پایه کد آنها را درک کنید زیرا فقط از نماینده سوال می‌پرسید. می‌توانید این مسیر را طی کنید و روابط عمومی بزرگی ایجاد کنید.”

برخی از افراد دعوت از نمایندگان را به یک اتاق مشترک پیشنهاد کردند تا همه بتوانند نظر بدهند و روند را تغییر دهند. برخی دیگر پیشنهاد می‌کنند که هر روابط عمومی شامل رونوشت‌هایی از فرآیند تحریک باشد. این نگاه به مکالمه با یک نماینده حتی ممکن است ایده بهتری درباره نحوه ایجاد این کد ارائه دهد. “خیلی جالب است که بتوانید یک روابط عمومی باز کنید و ببینید که توسعه دهنده چگونه فکر کرده و مشکلات را حل کرده است.” said Dane Knecht، مدیر ارشد فناوری در Cloudflare.

در جایی که فرآیند قدیمی از کنترل‌های دسترسی، مسیرهای حسابرسی و تفاوت‌ها، و بررسی‌های CI/CD برای محدود کردن شعاع انفجار هر باگ استفاده می‌کرد، فرآیند جدید باید شانس قبل از نوشتن کد را از بین ببرد. این به این معنی است که اطمینان حاصل کنید که هر کاری که می‌خواهید کد انجام دهد به صراحت در درخواست ذکر شده است. شما می توانید از فایل های spec.md برای این کار استفاده کنید، اما هر چیزی که مشخص نشده است اکنون می تواند ساخته شود. “اگر چیزی را به شانس بسپارید، آن را به شانس واگذار کنید” said Scott Hanselman، معاون جامعه توسعه دهندگان مایکروسافت. “من این برنامه کوچک حلقه لایت را برای ساخت دارم و روی x64 هستم. می‌خواستم آن را روی ARM اجرا کنم، بنابراین باید به آن می‌گفتم: “یک نسخه ARM برای من بساز.” اگر این کار را نمی کردم، این اتفاق نمی افتاد.»

البته، شما نمی توانید همه چیزهایی را که نیاز دارید در یک پیام هوشمند جمع کنید (و همچنین نباید). شما در نهایت خودتان را زیاد تکرار خواهید کرد و تقریباً مطمئناً چند چیز را که به عنوان دانش ضمنی شرکت وجود دارد از دست خواهید داد. افراد باهوش زیادی وجود دارند که به این فکر می کنند که چگونه زمینه بهتری را برای عوامل خود فراهم کنند و خاطرات بلندمدت و کوتاه مدت به آنها بدهند. ترفند این است که به عوامل خود زمینه مناسب کد مورد نیاز خود را بدهید. به طور معمول، این چاشنی است که توسعه دهندگان ارشد با گذشت زمان به آن دست پیدا می کنند. اما عوامل به شما نیاز دارند که این دانش را در جایی به دست آورید (مانند Stack Internal)، آن را بررسی کنید و در صورت نیاز بیت های صحیح را به عنوان متن ارائه دهید.

بنابراین شما بهترین درخواست را در جهان دارید. شما زمینه مناسبی را به نماینده خود دادید و آنها چیزی ساختند که بررسی همتایان را پشت سر گذاشت و به تولید سوق داد. بررسی بعدی سیستم شما این است که هرگز آن بخش از عملکرد را دوباره ایجاد نکنید. شما یک جزء نرم افزاری کاملاً خوب دارید. آن را هدر ندهید، دوباره از آن استفاده کنید. “اصل DRY (خودت را تکرار نکن) اصل اصلی ما است” Laly Bar-Ilan، دانشمند ارشد در بیت. “هوش مصنوعی امروز ذاتاً مرطوب است (همه چیز را دو بار بنویسید). این توسعه دهنده به آن می گوید، “بسیار خوب، یک دکمه ایجاد کنید” و با خوشحالی این کار را انجام می دهد، سپس توسعه دهنده دیگری در تیم دیگری آن را می پرسد، و سپس دکمه دیگری در پایگاه کد وجود دارد.”

با این حال، بزرگترین هک برای ایجاد اعتماد با عوامل هوش مصنوعی ممکن است دانستن زمان استفاده نکردن از آنها باشد. حتی با وجود تمام موارد حفاظتی بالا در فرآیند شما، هنوز هم به دلیل ماهیت هوش مصنوعی کمی تاس درگیر است. اگر راه حل غیر قطعی کاملاً خوبی دارید، چرا چرخ را دوباره اختراع کنید؟ Anil Dash گفت: «ما در تلاش هستیم تا سیستم‌های غیر قطعی را در بسیاری از سناریوهایی که نیاز به کد قطعی داشته باشید، اعمال کنیم. “LLM ها در این چیزها بد هستند، و چرا ما سعی می کنیم از آنها به عنوان چکشی برای همه این چیزهایی که میخ نیستند استفاده کنیم؟ یک فیلمنامه متواضع bash که شش سال است اجرا می شود خوب است.”

ما به خاطر افراد و ابزارهایی که با آنها کار می کردیم، اعتماد داخلی داشتیم. این اعتماد از پیش بینی پذیری ناشی می شود: شما می دانستید که آنها چه کاری می توانند انجام دهند، می دانستید نقاط قوت و ضعف آنها کجاست و آیا انتظار دارید تجربه شما با آنها در روز دوشنبه با تجربه شما در روز سه شنبه مطابقت داشته باشد. ماهیت احتمالی هوش مصنوعی و همچنین سرعتی که در آن پیشرفت‌ها و تغییرات رخ می‌دهند، همه اینها را از پنجره بیرون می‌اندازد. بهبود فرآیند می تواند به مهندسان کمک کند تا دوباره به توسعه اعتماد کنند.

در روزهای خوب گذشته، ما فرآیندهایی را پیرامون افراد ایجاد می‌کردیم و به آن فرآیندها اعتماد می‌کردیم، زیرا به افرادی که با آنها کار می‌کردیم اعتماد داشتیم. ما ابزارهایی را ایجاد کردیم که برای پیشبرد فرآیند به آنها اعتماد داشتیم، و آنها به عنوان توسعه دهنده ما و افرادی که با آنها کار کردیم عمل کردند.

با هوش مصنوعی می‌توانیم بسیاری از این فرآیندها را خودکار کنیم. خبر خوب این است که کار را سریعتر انجام می دهد. خبر بد این است که وقتی کار تمام شد به آن اعتماد نداریم. ابزارها جدید هستند، افراد به سمت نقش های سطح بالاتر حرکت می کنند و ما هنوز باید اعتماد ایجاد کنیم. با یک گردش کار آگاهانه تر و به خوبی تعریف شده که قضاوت انسان را حفظ می کند، می توانیم شروع به ایجاد اعتماد در سیستم های جدید کنیم.

تیم های موفق آنهایی نیستند که بیشترین کد را تولید کنند. آن‌ها حلقه‌های بازخورد، دانش استاندارد طلایی که بهترین زمینه را فراهم می‌کنند و ابزارهایی هستند که فرآیند شما را با جریان‌های کاری شما همسو می‌کنند، ایجاد می‌کنند.