از وایبکدینگ تا مهندسی نرمافزار با Observability
هوش مصنوعیخلاصهٔ کاملتر
تو این مقاله از Dynatrace اومده که هوش مصنوعی دیگه بخشی از فرآیند ساخت نرمافزاره — از پیشنهادهای درونادیتوری گرفته تا ایجنتهایی که خودشون سرویس میسازن و پولریکوئست باز میکنن. نویسنده میگه سرعت تولید کد بالا رفته ولی گلوگاه جابهجا شده: حالا سختترین بخش اینه که بفهمی این کد تو یه سیستم واقعی چطور رفتار میکنه. به گزارشی از CodeRabbit هم اشاره میکنه که طبقش پولریکوئستهای نوشتهشده با AI نرخ بالاتری از بعضی نقصها داشتن.
مثال مقاله سادهست: از مدل میخوای تابعی بنویسه که سفارشهای یه دسته کاربر رو بگیره. کدی که برمیگرده سینتکس و منطق درستی داره و حتی داکیومنت شده، ولی نه error handling داره، نه rate limiting و نه هیچ ابزار مشاهدهپذیری. به گفتهٔ نویسنده مشکل اصلی همینه که مدل دهها تصمیم معماری — انتخاب کلاینت HTTP، استراتژی خطا، مدیریت کانکشن، تایماوت و ریترای — رو بیصدا گرفته و هیچوقت نگفته چی و چرا.
راهحل پیشنهادی چهار لایه گاردریله که روی هم اثر تجمعی دارن: prompt engineering (شفاف بودن، دادن context و مثال و قالب خروجی)، planning (وادار کردن مدل به فکر کردن قبل از کدزدن، حتی تو یه حالت plan جداگانه)، skills (دستورالعمل و دانش و اسکریپتی که استاندارد سازمان رو به مدل تزریق میکنه) و tools (دسترسی به سیستمهای بیرونی از راه MCP یا CLI). نویسنده میگه پرامپتنویسی بهتنهایی شکنندهست؛ ارزش واقعی وقتی درمیآد که لایهها روی هم سوار بشن.
به نظر نویسنده، observability یکی از بهترین حوزههاست که میشه به شکل skill درش آورد، چون دقیقاً همونجاییه که مدل بهصورت پیشفرض هیچی تولید نمیکنه: قرارداد لاگنویسی و سطح شدت، الگوهای OpenTelemetry، انتخاب بین auto-instrumentation و اسپن دستی، و لینککردن متریک و ترِیس و لاگ به هم. با planning و skill درست، همون درخواست «سفارشها رو بگیر» کدی میده که rate limit رو رعایت میکنه، دو لایه اسپن میسازه و لاگ ساختاریافته با ترِیس بیرون میده.
ولی مقاله میگه حتی این کد تمیز هم یه باگ پروداکشنی داره: سرویس مقصد خروجی رو تو دستههای ۵۰تایی صفحهبندی میکنه و تابع بیسروصدا فقط صفحهٔ اول رو برمیگردونه — باگی که نه تست گرفتش نه ریویو، چون فقط تو رفتار زمان اجرا وجود داره و بیرون از کدبیس و مستندات تیمه.
جواب مقاله همینجاست: یه حلقه که از Plan شروع میشه، از Code و Deploy و Test رد میشه، به Observe میرسه و مشاهدهها دوباره به برنامهٔ بعدی برمیگردن. برای هر مرحله یه ابزار کوچیک تعریف میشه؛ تو نمونهٔ Dynatrace، dtwiz برای راهانداختن سریع جریان تلهمتری و dtctl (یه CLI متنباز با الهام از kubectl) برای خوندن ترِیس و متریک و لاگ و رویداد. نکتهٔ مهم از نگاه نویسنده اینه که این حلقه باید به شکل hook اجباری اجرا بشه، نه یه مرحلهٔ اختیاری که راحت رد میشه.
نکات کلیدی:
- گلوگاه جدید تولید کد نیست، فهمیدن رفتار کد تو محیط واقعیه
- چهار لایهٔ گاردریل: prompt engineering، planning، skills و tools
- observability بهترین کاندید برای تبدیلشدن به skill، چون مدل پیشفرض هیچی تولید نمیکنه
- باگهایی مثل صفحهبندی نادیدهگرفتهشده فقط تو زمان اجرا دیده میشن، نه تو تست و ریویو
- حلقهٔ Plan تا Observe با ابزارهایی مثل dtwiz و dtctl بسته میشه
- اجرای این حلقه باید hook اجباری باشه تا وایبکدینگ به مهندسی تبدیل بشه
