تصور کنید ۹ ساعت از زمان خود را صرف رفع یک باگ ساده میکنید، اما ۷ ساعت آن را صرف تماشای یک عامل هوش مصنوعی میکنید که با اعتمادبهنفس کامل، وصلههایی میزند که هیچکدام کار نمیکنند. این سناریوی واقعی که در گزارش ۲۶ اوت ۲۰۲۶ وبسایت dev.to منتشر شد، شکاف عمیقی را میان دو مفهوم جدید برملا میکند: «کدنویسی بر اساس حس» (Vibe Coding) و «عیبیابی بر اساس حس» (Vibe Debugging).
درک مفهوم کدنویسی بر اساس حس (Vibe Coding)
بسیاری از برنامهنویسان اکنون برای ساخت اسکلت برنامهها (Scaffolding) یا مدیریت دادهها (CRUD handlers) از هوش مصنوعی زاینده (Generative AI) استفاده میکنند. به این روند Vibe Coding میگویند؛ یعنی اجازه میدهید مدل کد را بنویسد و شما بدون خواندن دقیق هر خط، آن را میپذیرید. این روش جواب میدهد چون حلقه بازخورد کوتاه است و بررسی صحت کد در خارج از مدل اتفاق میافتد.
تولید کد (Generation) کاری است که مدلهای زبانی واقعاً در آن بهترین هستند. دادههای آموزشی آنها شامل میلیونها نمونه از توابعی است که ورودی X را میگیرند و خروجی Y را برمیگردانند. به همین دلیل، یک مدیریتکننده استاندارد CRUD برای هوش مصنوعی یک اثر نوآورانه یا پیچیده نیست، بلکه یک الگوی تکراری است.
این فرآیند به این دلیل کار میکند که حلقه بازخورد خارجی و فوری است. اگر نقطه انتهایی (Endpoint) پاسخ 200 OK برگرداند، صفحه به درستی رندر شود یا رابط خط فرمان (CLI) خروجی درست را چاپ کند، کد صحیح است. برنامهنویس نیازی ندارد هر خط از تغییرات (Diff) را درک کند، زیرا واقعیت به عنوان یک «اوراکل» یا داور عمل میکند و کد را در حدود چهار ثانیه ارزیابی میکند.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، تکیه بر خروجیهای مدل بدون اعتبارسنجی سختگیرانه، ریسکهای پنهانی دارد. در کدنویسی، چون خروجی سریعاً تست میشود، این ریسک کمتر است. اما در عیبیابی، ما با دنیای متفاوتی روبرو هستیم. این تضاد میان سادگی ظاهری کدنویسی و پیچیدگی مدیریت عاملها، چالشهای جدیدی را برای برنامهنویسان حرفهای ایجاد کرده است که در تحلیلهای پیشین به آن پرداختیم.
خطرات عیبیابی بر اساس حس (Vibe Debugging)
عیبیابی یا Debugging اساساً متفاوت است. باگ، ادعایی درباره اتفاقی است که درون یک فرآیند رخ داده و مدل هرگز آن را ندیده است. یک عامل (Agent) — شبیه کارمندی که فقط گزارشهای متنی را میخواند اما هرگز وارد محیط کارخانه نشده — فقط متنها، مانند ردپاهای پشته (Stack Traces)، خطوط لاگ و توصیفات کوتاه و اغلب عصبیِ تکجملهای را میبیند. او نمیتواند وضعیت واقعی زمان اجرا (Runtime State) را در یک سیستم عملیاتی مشاهده کند.
در نتیجه، مدل به تطبیق الگوهای علائم با رایجترین دلایل آماری متکی میشود. این روش اغلب «به اندازه کافی درست است که خطرناک باشد». وقتی مدل اشتباه میکند، خطایی برنمیگرداند؛ بلکه یک «راه حل متقاعدکننده» ارائه میدهد.
به نقل از گزارش dev.to، در مورد باگ ایمیلهای تکراری، مشکل دقیقاً شبیه به یک «شرایط مسابقه» (Race Condition) به نظر میرسید چون یک مسئله همزمانی (Concurrency) بود. عامل هوش مصنوعی یک قفل Mutex را دور یک مجموعه (Set) در حافظه پیشنهاد داد. این یک پاسخ کتابخانهای و کلاسیک برای یک تکپردازش (Single Process) بود، اما سیستم واقعی به دو نمونه (Instance) مقیاسدهی (Autoscale) شده بود. باگ واقعی، نبودِ وضعیت مشترک (Shared State) بین نمونهها بود؛ یعنی دو مجموعه مجزا و صفر وضعیت مشترک. این یک توپولوژی استقرار (Deploy Topology) بود که مدل نمیتوانست با خیره شدن به کد منبع کشف کند. نتیجه این شد که تستها پاس شدند، اما ایمیلهای تکراری همچنان ارسال میشدند و حالا یک قفل بیهوده در کد باقی ماند که برنامهنویسان آینده را گمراه میکند تا فکر کنند مسئله همزمانی حل شده است.
مکانیسم «مارپیچ مرگ»
وقتی یک عامل نمیتواند ریشه مشکل را بیابد، معمولاً یک الگوی شکست چهار مرحلهای پیشبینیپذیر را به ترتیب زیر دنبال میکند:
- محافظت تهی (Null Guard): اضافه کردن شرطهایی مثل
if (!x) return;. در این حالت کرش متوقف میشود، اما باگ صرفاً به مراحل پایینتر منتقل میشود و حالا شبیه به یک باگ متفاوت به نظر میرسد. - اسفنج Try/Except: پیچیدن کد در بلوکهای مدیریت خطا برای لاگ کردن و نامیدن آن به عنوان «مدیریت شده». این کار نرخ خطا را کاهش میدهد، اما صحت عملکردی زیربنایی تغییر نمیکند.
- بازنویسی کلی (The Rewrite): گسترش دامنه تغییرات برای پیادهسازی مجدد کل یک تابع، چون وصلههای کوچک شکست خوردهاند. این کار باعث ایجاد یک Diff ۲۰۰ خطی میشود که در آن تشخیص اینکه چیزی واقعاً اصلاح شده یا فقط جابهجا شده، غیرممکن است.
- بستن با اعتمادبهنفس: بیان یک اصلاحیه به عنوان حقیقت (مثلاً: «حل شد! مشکل این بود که Set ایمن نبود») بدون اینکه واقعاً کد را اجرا کرده باشد.
هیچکدام از اینها به معنای دروغ گفتن مدل نیست. این نتیجه سیستمی است که برای تولید یک وصله محتمل بهینه شده، در حالی که هیچ حقیقت زمینی (Ground Truth) برای بررسی ندارد. بدون وجود یک اوراکل، مدل «احساسِ داشتنِ» یکی را ابداع میکند. این رویکرد احتمالی، دقیقاً همان نقطهای است که جایگزینی تحلیل سیستماتیک با حدسهای احتمالی در ابزارهایی مانند Claude Code را به چالش میکشد.
مشکل آلودگی زمینه (Context Pollution)
عاملهای هوش مصنوعی اغلب هرچه جلسه عیبیابی طولانیتر شود، بدتر عمل میکنند. این اتفاق به این دلیل میافتد که تئوریهای غلط خود مدل، بخشی از تاریخچه گفتگو میشوند.
تا نوبت چهارم، عامل تشخیصهای غلط قبلی خود را به عنوان شواهدی در متن گفتگو میخواند. این باعث ایجاد ماشینی میشود که به خودش استناد میکند. نویسنده مشاهده کرد عاملی ۱۲ نوبت صرف دفاع از تشخیصی کرد که در نوبت سوم رد شده بود، صرفاً چون آن تئوری شش پاراگراف بود در حالی که رد کردن آن تنها در یک خط گنجیده بود.
برای شکستن این چرخه، نویسنده «قانون سه ضربه» را پیشنهاد میکند. بعد از سه تلاش ناموفق، جلسه باید کاملاً ریست شود. یک جلسه تازه باید تنها با استفاده از شواهد سخت — مراحل بازتولید (Repro steps)، مقادیر مشاهده شده واقعی و لیستی از مواردی که رد شدهاند و نحوه رد شدن آنها — شروع شود، نه بر اساس تاریخچه گفتگوهای قبلی.
پنج قانون برای عیبیابی به کمک هوش مصنوعی
برای جلوگیری از تله عیبیابی بر اساس حس، راهنمای dev.to یک چارچوب قطعی (Deterministic) پیشنهاد میکند. این قوانین در ابتدا زمانبر هستند اما میتوانند از تلف شدن روزهای کاری جلوگیری کنند:
۱. بدون بازتولید، بدون عامل (No Repro, No Agent): ساعت اول را صرف این کنید که باگ را به صورت دستوری و قطعی بازتولید کنید. این کار آمادهسازی برای کار نیست؛ بلکه خودِ کار است. یک تست شکستخورده قطعی، یک شرط پایان (Terminal Condition) به عامل میدهد که میتواند به طور مستقل بررسی کند و این امر نرخ موفقیت را به شدت افزایش میدهد.
۲. توضیح پیش از ویرایش: یک زنجیره علت و معلولی با استناد به فایل و شماره خط مطالبه کنید. بپرسید کدام خط مقدار بد را مینویسد، کدام خط آن را میخواند و بین آنها چه اتفاقی میافتد. اگر عامل نتواند استناد کند، یعنی در حال حدس زدن است.
۳. محدود کردن تغییرات (Cap the Diff): اصلاحات را به ۱۰ خط محدود کنید یا مدل را مجبور کنید اعتراف کند که نمیتواند آن را حل کند. باگهای حلنشده در Diffهای بزرگ پنهان میشوند. این محدودیت مدل را مجبور به تشخیص واقعی میکند چون نمیتوانید یک ماژول کامل را در ۱۰ خط «شاتگان» (تغییرات گسترده و تصادفی) کنید.
۴. بازگشت و تایید مجدد (Revert and Re-verify): وقتی تستی پاس شد، وصله را برگردانید (Revert) و تایید کنید که تست دوباره قرمز (شکست) میشود. این کار «وصلههای پلاسیبو» را حذف میکند؛ جایی که تغییر واقعی در واقع یک ریاستارت، پاک کردن کش یا یک ویرایش نامرتبط از ابتدای جلسه بوده است.
۵. مشاهده به جای صفت: از کلماتی مثل «ناپایدار» (Flaky) استفاده نکنید. در عوض، از عامل بخواهید ابزارهای اندازهگیری (Instrumentation) اضافه کند، خودتان آن را اجرا کنید و مقادیر واقعی را دوباره در چت قرار دهید. دقت تابعِ چیزی است که در پنجره زمینه قرار دارد، نه شدت و سختگیری درخواست شما.
نتیجهگیری نهایی
در نهایت، مشکل ایمیلهای تکراری با سه خط SQL حل شد: یک محدودیت یکتا (Unique Constraint) روی (order_id, template) و یک دستور Insert که تداخل (Conflict) را مدیریت میکرد. حذف تکراریها باید در پایگاهداده انجام میشد — تنها جزئی از سیستم که هر دو نمونه (Instance) بر سر آن توافق داشتند.
عامل هوش مصنوعی میتوانست در یک نوبت به این جواب برسد اگر پرامپت این بود: «این حذف تکراریها از حافظه محلی پردازش استفاده میکند؛ ما ۲ یا بیشتر نمونه سیستم را اجرا میکنیم». با این حال، این یک ترفند پرامپت نیست؛ بلکه نتیجه این است که انسان ابتدا تشخیص (Diagnosis) را انجام داده است.
آیا کدنویسی بر اساس حس هنوز مفید است؟ بله. برای رابط کاربری (UI)، اسکلتبندی، کدهای رابط (Glue code) و اسکریپتهای یکباره که واقعیت سریعاً کار را چک میکند، بسیار مؤثر است. کلید موفقیت این است که توجه خود را از خواندن Diffها به مالکیت حلقه بازخورد منتقل کنید. ارزشمندترین مهارت برای برنامهنویسان دیگر مهندسی پرامپت (Prompt Engineering) نیست، بلکه توانایی ایجاد باگ به صورت دستوری و در لحظه است. این تنها کاری است که یک عامل هنوز نمیتواند انجام دهد و تنها ورودیای است که باعث میشود خروجی هوش مصنوعی واقعاً کار کند.
گام بعدی شما
- در اولین باگ بعدی خود، به جای دادن کد به AI، ابتدا یک تست اتوماتیک بنویسید که باگ را ۱۰۰٪ بازتولید کند.
- هرگاه مدل بیش از ۳ بار در رفع باگ شکست خورد، تاریخچه چت را پاک کرده و فقط شواهد سخت را دوباره وارد کنید.
- از مدل بخواهید قبل از هر تغییر، «زنجیره علت و معلولی» را با ارجاع به شماره خط بنویسد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو