‏وایبینگ، هارنس و حلقه OODA

یه بار یه بنیان‌گذار استارتاپ به تیمش گفت: «من آخر هفته با یه آبجو این فیچر رو ساختم، شما چرا دو هفته وقت می‌خواید؟» این جمله آشناست، نه؟ نویسنده این مقاله معتقده که هوش مصنوعی و وایبینگ دقیقاً همین دینامیک قدیمی رو احیا کردن؛ ابزاری که جهل رو جذاب‌تر نشون می‌ده.

وایبینگ به خودی خود بد نیست. وقتی هدفمون ثابت کردن یه ایده یا ساختن یه PoC ساده‌ست، سرعت می‌تونه یه مزیت واقعی باشه. قدرت جهل اینجاست که گیر جزئیات نمی‌شیم و سریع به نتیجه می‌رسیم. اما اگه عاشق این نتیجه بشیم و فکر کنیم کارمون تمومه، مشکل شروع می‌شه.

برای توضیح بهتر، نویسنده از حلقه OODA استفاده می‌کنه؛ مدلی که نظامی‌ها برای تصمیم‌گیری سریع در شرایط بحرانی طراحی کردن. این حلقه چهار مرحله داره: Observe (مشاهده خام واقعیت)، Orient (تحلیل بر اساس دانش و تجربه)، Decide (تصمیم‌گیری)، Act (اجرا). در دنیای نرم‌افزار، هرکی بتونه این چرخه رو سریع‌تر و دقیق‌تر بزنه، برنده‌ست.

مشکل وایبینگ اینه که مراحل Observe و Orient رو دور می‌زنه و مستقیم می‌ره سراغ Decide و Act. بنیان‌گذار استارتاپ همین کار رو کرد؛ یه UI صاف و تمیز دید، فرض کرد که همه چیز درسته، و رفت سراغ مرحله بعدی. اما «نگاه کردن» با «مشاهده واقعی» فرق داره.

مشاهده واقعی نیاز به هارنس داره؛ یعنی تست‌های اتوماتیک، مانیتورینگ، تریس‌های دقیق و ابزارهای CI/CD. بدون اینا فقط داریم به سیستم نگاه می‌کنیم، نه اینکه واقعاً بفهمیمش. همون‌طور که کلیک کردن توی پنل AWS بدون مستندسازی، یه محیط غیرقابل بازتولید می‌سازه، وایبینگ بدون هارنس هم همینه.

نویسنده تجربه خودش رو مثال می‌زنه: داشت Observability و OpenTelemetry رو به پروژه Emmett اضافه می‌کرد. برای تست روی نمونه واقعی، از استک Grafana با Docker Compose استفاده کرد و عمداً config رو با LLM وایب کرد. نتیجه؟ یه‌بار با یه سری دستور Linux جادویی کار کرد، ولی قابل تکرار نبود. بعد تصمیم گرفت کل فرآیند رو با ابزارهای واقعی اتوماتیک کنه: از execa برای اجرای shell script، از fetch بومی Node.js برای بررسی endpoint‌ها، و از ابزار تست بومی Node.js برای اعتبارسنجی استفاده کرد.

نکته مهم اینه که تیم‌ها «دو هفته» وقت می‌خوان نه به خاطر کندی، بلکه به خاطر اینکه دارن زیرساختی می‌سازن که بتونه حلقه OODA رو پایدار نگه داره. این کار شامل مشاهده درست، تحلیل دقیق، اتوماسیون تکرارپذیر و چرخش چندباره توی حلقه‌ست. البته تمرکز بیش از حد روی Orient و Decide هم می‌تونه به overengineering منجر بشه؛ تعادل اینه که با فروتنی شروع کنیم، ساده‌ترین راه رو امتحان کنیم، ولی از اول به هارنس فکر کنیم.

نکات کلیدی:

• وایبینگ با LLM همون «من آخر هفته ساختمش» قدیمیه، فقط سریع‌تر
• حلقه OODA می‌گه سرعت Act باید با سرعت Observe متناسب باشه وگرنه چرخه می‌شکنه
• بدون هارنس (تست، مانیتورینگ، اتوماسیون) فقط داری به سیستم نگاه می‌کنی، نه مشاهده‌اش می‌کنی
• LLM توی Decide و Act عالیه، ولی Orientation رو نمی‌تونه جای تجربه و دانش واقعی بگیره
• اولین راه‌حل کار می‌کنه؟ عالی، حالا وقت اتوماتیک کردنشه تا قابل تکرار بشه
• تیم‌ها کند نیستن؛ دارن زیرساخت پایدار می‌سازن