تصور کنید در حالی که کاملاً تسلیم احساسات شدهاید و وجود کد را فراموش کردهاید، کدنویسی میکنید. به جای تایپ کردن، از Cursor و Sonnet بخواهید همه چیز را برای شما بسازند. وقتی با یک باگ مواجه میشوید، سعی نمیکنید آن را عیبیابی کنید — در عوض، خطا را دوباره به مدل زبانی بزرگ (LLM) برمیگردانید و اصلاحیه را کپی-پیست میکنید. کد فراتر از درک شما رشد میکند، اما همیشه در نهایت کار میکند. اینگونه است که آندری کارپاتی - یکی از اعضای بنیانگذار OpenAI - کدنویسی حسی را توصیف میکند.
در حالی که کارپاتی این را به عنوان یک رویکرد سرگرمکننده برای پروژههای آخر هفتهای گذرا ارائه میدهد، واقعیت این است که نسخهای از کدنویسی حسی — یا نوشتن کد به شدت با استفاده از LLM — در حال حاضر در مقیاس بزرگ اتفاق میافتد. گوگل گزارش میدهد که هوش مصنوعی ۲۵٪ از کد جدید آن را تولید میکند، و در بسیاری از بخشهای صنعت، این تعداد احتمالاً حتی بیشتر است. افراد متعددی گزارش دادهاند که مهندسان نرمافزار در شرکتها — از جمله HubSpot — دیگر مجاز به نوشتن نرمافزار نیستند و فقط میتوانند از LLM درخواست کنند. به نظر من، کدنویسی حسی آینده ساخت نرمافزار است.
اما چه اتفاقی میافتد وقتی کد تولید شده توسط هوش مصنوعی در محیط عملیاتی (production) با شکست مواجه میشود و باعث قطعی میشود؟ در این مقاله، من این سؤال را بررسی میکنم و چند ایده برای آمادهسازی سازمان مهندسی شما به اشتراک میگذارم.
کدنویسی حسی سرگرمکننده است تا زمانی که قطعی رخ دهد
داشتن مهندسان ماهری که کدهای مبنایی (codebase) را که در آن کار میکنند، درک کنند، ضروری است. سازمانهای مهندسی قوی حتی اطمینان حاصل میکنند که هیچ مهندسی با گسترش دانش در بین اعضای تیم، به یک نقطه واحد خرابی تبدیل نمیشود.
هنگامی که یک حادثه رخ میدهد، پاسخ معمول این است که مهندسی که بخش آسیبدیده را میشناسد، برای حل سریع آن وارد عمل شود. با این حال، از آنجایی که کد بیشتری توسط LLM تولید میشود، مهندسانی که کدهای مبنایی را عمیقاً درک میکنند، به طور فزایندهای نادر میشوند و تشخیص و حل قطعیها را دشوارتر میکنند.
شریه شانکار، دانشجوی دکترا در دانشگاه کالیفرنیا، برکلی، این موضوع را به طور کامل در توییتی که بیش از ۳۰۰ میلیون بازدید داشته است، بیان میکند: «چرا کسی در مورد اینکه چقدر حضور مهندسان در وضعیت آمادهباش (on-call) به دلیل ادغامهای کورکورانه کد تولید شده توسط هوش مصنوعی بدتر شده است، صحبت نمیکند؟ LLMها کدنویسهای خوبی هستند اما مهندسان وحشتناکی هستند.» و با قطعیهایی که اکنون ۱۴۰۰۰ دلار در دقیقه هزینه دارند، واضح است که تیمها نمیتوانند وقت خود را برای رمزگشایی کدی که توسط یک LLM نوشته شده است، تلف کنند.
تلاقی کدنویسی حسی با عیبیابی حسی
کد تولید شده توسط هوش مصنوعی از بین نخواهد رفت، با ۶۱٪ از تیمهای مهندسی که هوش مصنوعی مولد را پذیرفتهاند — فقط افزایش خواهد یافت. در اینجا نحوه آماده شدن برای آینده مدیریت حوادث آورده شده است.
ابتدا، از ابزارهای مدیریت حوادث مبتنی بر هوش مصنوعی مانند Rootly یا PagerDuty Advanced استفاده کنید. این ابزارها تدارکات حوادث را مدیریت میکنند — بهطور خودکار کانالهای ارتباطی را ایجاد میکنند، بهروزرسانیها را برای ذینفعان مختلف تهیه میکنند و گزارشهای پس از حادثه را مدیریت میکنند. این ابزارها همچنین شروع به استفاده از هوش مصنوعی برای مطابقت دادن حوادث فعلی با حوادث گذشته کردهاند و به شما کمک میکنند تا به سرعت موارد مشابه و افرادی که آنها را برطرف کردهاند، پیدا کنید و میانگین زمان حل مشکل را کاهش دهید.
سپس، نحوه رفع حوادث را ارتقا دهید. اگر بتوانید از ابزاری برای مشخص کردن علت اصلی و پیشنهاد یک راه حل استفاده کنید، چه؟ این دقیقاً همان کاری است که موج جدیدی از ابزارهای حل حوادث مبتنی بر LLM، که به عنوان دستیاران AI SRE برچسبگذاری شدهاند، مانند Sentry AI و Datadog Bits AI، انجام میدهند.
این ابزارها همان دادههایی را که یک SRE استفاده میکند — گزارشهای خطا، معیارها، ردیابیهای برنامه — پردازش میکنند، اما همچنین دادههای بدون ساختار تولید شده توسط انسان مانند بحثهای Slack، دستورالعملها و گزارشهای پس از حادثه را نیز دریافت میکنند. آنها میتوانند به سرعت تجزیه و تحلیل علت اصلی را خودکار کنند، کامیت (commit) را که باعث ایجاد مشکل شده است، برجسته کنند، نحوه تأثیر آن بر معیارهای سیستم را تجسم کنند و زنجیره خرابیهایی که منجر به قطعی شده است را ردیابی کنند. بنابراین، وقتی یک انسان فراخوانی میشود و پشت کامپیوتر مینشیند، یک تجزیه و تحلیل علت اصلی از قبل برای بررسی در دسترس است.
ابزارهای پیشرفتهتر فقط مسائل را تشخیص نمیدهند — بلکه راه حلهایی را نیز پیشنهاد میدهند. شما میتوانید قبل از استقرار آن، اصلاحیه را بررسی، بحث و تأیید کنید یا اجازه دهید ابزار همه چیز را به طور خودکار انجام دهد. قابل درک است که برخی از مهندسان عملیات (Ops) بدبین هستند. اگر LLM یک اصلاحیه توهمی (hallucinate) ارائه دهد که اوضاع را بدتر کند، چه؟ اگر هیچ بازگشتی (rollback) در دسترس نباشد، چه؟ استقرار تدریجی تغییرات میتواند به کاهش خطر کمک کند، اما این یکی از عوامل بسیاری است که باید در نظر گرفته شود. حل حوادث مبتنی بر هوش مصنوعی امیدوارکننده است، اما با مجموعه چالشهای خاص خود همراه است.
با این حال، ابزارهای خودترمیمی (self-healing) چیز جدیدی نیستند: آنها حداقل بیش از یک دهه است که وجود داشتهاند. فیسبوک در سال ۲۰۱۱ FBAR را برای خودکارسازی تعمیر و نگهداری رک (rack) معرفی کرد. دراپباکس در سال ۲۰۱۶ Naru را برای مدیریت خرابیهای سرور، هشدارها و اصلاحات ارائه کرد. با این حال، اینها سیستمهای قطعی با قوانین از پیش تعریف شده بودند که به طور چشمگیری شانس اشتباهات را کاهش میدادند.
در لینکدین، به عنوان یک SRE ارشد، من یک مکانیسم خودترمیمی برای زیرساخت توزیع شده طراحی کردم که از یادگیری ماشین برای تجزیه و تحلیل علت اصلی و اصلاح استفاده میکرد، اگرچه هرگز به طور کامل اجرا نشد. با ظهور LLM، این رویکرد در حال وقوع است و من بسیار هیجانزده هستم که آن را به واقعیت تبدیل کنم. شرکتها در این فضا در حال پیشرفت واقعی هستند. رقابت در حال گرم شدن است. حداقل ۲۰ بازیکن در بازار وجود دارد و بودجه VC در حال سرازیر شدن است. وارد عیبیابی حسی شوید! بله، من همین الان آن را ساختم.
اگر نمیتوانید با آنها بجنگید، به آنها بپیوندید
با فعال کردن هوش مصنوعی مولد برای توسعهدهندگان برای کار تا دو برابر سریعتر، این روند به هیچ وجه از بین نخواهد رفت. پس چرا عیبیابی حسی را نپذیریم؟ وقتی قطعی رخ میدهد، بنشینید، قهوه خود را بنوشید و اجازه دهید دستیار AI-SRE شما متوجه شود که چگونه کار همکاران کدنویسی حسی خود را اصلاح کند.