وقتی وایب کدینگ گیر می‌کنه: دیباگ، ریست و برگشت به نسخه سالم

وقتی وایب کدینگ گیر می‌کنه: دیباگ، ریست و برگشت به نسخه سالم

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

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

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

---

چرا هوش مصنوعی گیر می‌کنه؟

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

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

دومیش شلوغ شدن گفت‌وگوئه. هر پیامی که می‌فرستی، هر جوابی که می‌گیری و هر کدی که خونده میشه، تو حافظه کوتاه‌مدت مدل جمع میشه. راهنمای رسمی Claude Code صریحاً می‌گه وقتی این حافظه پر میشه، مدل دستورهای قبلی رو «فراموش» می‌کنه و اشتباهاتش بیشتر میشه (Claude Code Docs). ده تا تلاش ناموفق یعنی ده تا راه‌حل غلط که حالا جلوی چشم مدله و گاهی دوباره سراغشون می‌ره.

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

و چهارمیش مخصوص کارهاییه که یه کتابخونه جدید لازم دارن، مثل همین خروجی اکسل. هوش مصنوعی گاهی اسم پکیجی رو پیشنهاد می‌ده که وجود نداره، یا نسخه قدیمیش رو با روش استفاده نسخه جدیدش قاطی می‌کنه. کد کاملاً منطقی به نظر میاد، ولی هیچ‌وقت کار نمی‌کنه.

---

اول بفهم چه نوع گیری داری

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

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

---

پیدا کردن خطای واقعی، حتی اگه برنامه‌نویس نیستی

صفحه سفید معمولاً بی‌دلیل نیست. مرورگر دقیقاً می‌دونه چی خراب شده و تو یه جایی به اسم کنسول نوشته. فقط باید بلد باشی کجا رو نگاه کنی.

تو Chrome یا Edge، روی صفحه اپ کلید F12 رو بزن، یا کلیک راست کن و Inspect رو انتخاب کن. یه پنل باز میشه. بالاش چند تا تب هست. روی Console کلیک کن. هر خطایی که اپ داشته، اینجا با رنگ قرمز نوشته شده.

لازم نیست معنی خطا رو بفهمی. فقط کل متن قرمز رو کپی کن، از خط اول تا آخرین خطی که اسم یه فایل توش هست. همون یه خط اول معمولاً کلید ماجراست. تو اپ ما، اولین خط قرمز این بود:

Uncaught SyntaxError: The requested module '/node_modules/xlsx-export-lite/index.js' does not provide an export named 'exportToExcel'

حتی بدون دونستن برنامه‌نویسی، دو تا چیز از این خط معلومه. مشکل از یه پکیج به اسم xlsx-export-lite هست، و کد داره دنبال چیزی تو این پکیج می‌گرده که اونجا نیست. این خیلی بیشتر از «صفحه سفید شده» به هوش مصنوعی اطلاعات می‌ده.

اگه مشکل درباره ذخیره یا دریافت اطلاعاته، مثلاً دکمه‌ای که چیزی رو می‌فرسته و اتفاقی نمی‌افته، کنار Console یه تب دیگه به اسم Network هست. اونجا هر درخواستی که اپ فرستاده لیست شده و اونایی که شکست خوردن قرمزن. روی ردیف قرمز کلیک کن و هرچی تو بخش Response نوشته شده رو هم کپی کن.

یه نکته هم درباره دکمه‌های آماده. Lovable و ابزارهای مشابه وقتی خطا می‌بینن، یه دکمه مثل «Try to fix» نشون می‌دن که خطا رو خودکار برای هوش مصنوعی می‌فرسته. تو Lovable ده بار استفاده رایگان ازش داری که هرکدوم ۲۴ ساعت بعد از استفاده دوباره آزاد میشه، و بعدش مثل یه پیام معمولی اعتبار مصرف می‌کنه (مستندات Lovable). برای خطاهای ساده عالیه. ولی اگه یه بار زدی و درست نشد، دوباره و دوباره زدنش همون حلقه خطاست با یه دکمه قشنگ‌تر.

---

دیباگ با پرامپت: پنج تکنیک که واقعاً جواب می‌دن

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

گزارش بازتولید، به جای «درستش کن»

هر وقت چیزی خراب شد، سه چیز رو بگو: چی کار کردی، انتظار داشتی چی بشه و چی شد. اگه خطا داری، متن کاملش رو هم بذار.

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

مراحل: صفحه رو باز می‌کنم، هنوز روی هیچ دکمه‌ای نزدم، صفحه سفیده.

خطای کامل کنسول: Uncaught SyntaxError: The requested module '/node_modules/xlsx-export-lite/index.js' does not provide an export named 'exportToExcel'

علت اصلی رو پیدا کن. فقط جلوی نمایش خطا رو نگیر.

جمله آخر مهمه. بدون اون، هوش مصنوعی ممکنه فقط یه شرط بذاره که خطا دیده نشه و دکمه اکسل بی‌صدا کار نکنه.

اول فرضیه، بعد دست زدن به کد

وقتی یه مشکل بیش از یه بار تکرار شده، نذار مدل مستقیم بره سراغ تغییر کد. اول ازش بخواه فکرش رو بگه.

قبل از اینکه چیزی رو تغییر بدی، توضیح بده فکر می‌کنی دلیل این خطا چیه، از کجا مطمئنی، و دقیقاً می‌خوای کدوم فایل‌ها رو عوض کنی. منتظر تأیید من بمون.

تو Lovable برای این کار یه حالت جدا هست به اسم Plan mode که مدل توش کد رو بررسی می‌کنه و برنامه می‌ده ولی به چیزی دست نمی‌زنه. خود مستندات Lovable پیشنهاد می‌کنه برای دیباگ امن از همین حالت استفاده کنی (مستندات Lovable). تو Claude Code هم حالت plan mode دقیقاً همین کار رو می‌کنه.

تو اپ ما، همین پرامپت مشکل رو باز کرد. مدل توضیح داد که پکیج xlsx-export-lite رو پیشنهاد داده، ولی حالا که نگاه می‌کنه، این پکیج تابعی به اسم exportToExcel نداره و احتمالاً اسمش رو با یه پکیج دیگه اشتباه گرفته. یعنی دلیل چهارم از بخش اول. سه تلاش قبلی همه داشتن صفحه سفید رو با دور زدن همین پکیج «درست» می‌کردن و هرکدوم یه جای دیگه رو خراب کرده بودن.

لاگ موقت برای اشتباه‌هایی که خطا ندارن

بدترین باگ‌ها اونایی‌ان که هیچ خطایی نمی‌دن، فقط نتیجه اشتباهه. مثلاً جمع کل یه عدد عجیبه. اینجا می‌تونی از هوش مصنوعی بخوای ردپا بذاره.

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

بعد کنسول رو باز می‌کنی و می‌بینی، مثلاً، یکی از مبلغ‌ها به جای عدد ۲۴۵۰۰۰ به شکل متن «۲۴۵٬۰۰۰» ذخیره شده و جمع رو به هم ریخته. حالا یه گزارش دقیق داری که می‌تونی بدی. یادت باشه آخر کار بگی لاگ‌های موقت رو پاک کنه.

جدا کردن مشکل

وقتی نمی‌دونی خرابی از کدوم تغییره، موقتاً فیچر جدید رو خاموش کن و ببین مشکل می‌مونه یا نه.

دکمه خروجی اکسل و هر کدی که برای اون اضافه شده رو موقتاً غیرفعال کن، بدون اینکه پاکش کنی. می‌خوام ببینم نمودار بدون اون درست کار می‌کنه یا نه.

اگه نمودار برگشت، می‌دونی مقصر کیه. اگه نه، مشکل یه جای دیگه‌ست و الکی داری با دکمه اکسل کلنجار می‌ری.

پیدا کردن نسخه‌ای که خرابی ازش شروع شد

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

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

---

نردبان ریست: از کم‌هزینه به پرهزینه

دیباگ همیشه جواب نمی‌ده و گاهی برگشتن سریع‌تر از درست کردنه. ولی برگشتن هم درجه داره. این پنج پله رو به ترتیب برو و تا وقتی پله پایینی جواب می‌ده، سراغ بالایی نرو.

پله اول، برگرداندن آخرین تغییره. اگه همین الان یه درخواست دادی و اوضاع رو بدتر کرد، فقط همون رو برگردون. تو Lovable روی آخرین جواب یه گزینه به اسم Undo latest edit هست که با یه کلیک این کار رو می‌کنه.

پله دوم، برگشت به آخرین نسخه سالمه. اگه چند تا تغییر پشت هم خراب کردن، برگرد به آخرین جایی که می‌دونی سالم بوده. تو Lovable روی هر جواب قدیمی‌تر گزینه Revert to this version هست و کل پروژه رو به همون لحظه برمی‌گردونه. یه قانون ساده هم اینجا به کارت میاد. اگه دو بار پشت هم تلاش کردی و درست نشد، دیگه اصرار نکن و همین پله رو برو. بعد از برگشتن، همون درخواست رو دوباره بفرست، ولی این بار با چیزی که از تلاش‌های ناموفق یاد گرفتی. تو اپ ما پیام جدید این شد: «برای خروجی اکسل از کتابخونه SheetJS (پکیج xlsx) استفاده کن که معروف و معتبره. قبل از نصب بگو دقیقاً کدوم پکیج و کدوم نسخه.»

پله سوم، گفت‌وگوی تازه‌ست. وقتی گفت‌وگو خیلی طولانی شده و حس می‌کنی مدل داره دور خودش می‌چرخه، حتی برگشتن به نسخه سالم هم کافی نیست، چون تلاش‌های غلط هنوز تو حافظه گفت‌وگو هستن. راهنمای Claude Code هم همینو می‌گه: اگه بیشتر از دو بار سر یه مشکل اصلاحش کردی، context رو پاک کن و با یه پرامپت بهتر از نو شروع کن، چون یه گفت‌وگوی تازه با پرامپت بهتر تقریباً همیشه بهتر از یه گفت‌وگوی طولانی پر از اصلاحیه جواب می‌ده (Claude Code Docs). برای اینکه چیزی از دست نره، قبلش از همین گفت‌وگو یه خلاصه بگیر:

یه خلاصه کوتاه بنویس که بتونم تو یه گفت‌وگوی تازه بدم: اپ چیه و چی کار می‌کنه، از چه تکنولوژی‌ها و پکیج‌هایی استفاده می‌کنه، الان دقیقاً چه مشکلی داریم، چه راه‌حل‌هایی امتحان شد و چرا جواب نداد. راه‌حل جدید پیشنهاد نده.

پله چهارم، ساختن دوباره فقط همون فیچره. اگه یه فیچر خاص بارها مشکل ساخته، از نسخه‌ای که هنوز اون فیچر رو نداشت شروع کن، یعنی به نسخه قبل از اولین تلاش برگرد، و این بار با یه پرامپت کامل‌تر از اول درخواستش کن. اگه ابزارت امکان کپی گرفتن از پروژه رو داره، قبلش یه کپی بگیر که اگه این بار هم نشد، نسخه اصلی دست‌نخورده بمونه.

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

---

ابزار برگشت تو هر محیط

ابزارهای مرورگری مثل Lovable، Bolt و v0

همه‌شون تاریخچه نسخه‌ها رو نگه می‌دارن. تو Lovable علاوه بر گزینه‌هایی که بالا گفتیم، یه بخش History هم هست که همه نسخه‌ها رو یه جا نشون می‌ده. یه امکان کمتر شناخته‌شده‌ش Bookmark in history هست که یه نسخه خاص رو نشونه‌گذاری می‌کنه تا بعداً راحت پیداش کنی (مستندات Lovable). عادت کن هر وقت به یه نسخه سالم و مهم رسیدی، نشونه‌ش بذاری. وقتی دو هفته بعد تو تاریخچه دنبال «آخرین نسخه سالم» می‌گردی، بین صد تا تغییر گم نمیشی.

ایجنت‌هایی مثل Claude Code

Claude Code قبل از هر تغییری که خودش تو فایل‌ها می‌ده، یه نقطه بازگشت (checkpoint) می‌سازه. با دو بار زدن Esc یا دستور /rewind منوی برگشت باز میشه و می‌تونی انتخاب کنی فقط گفت‌وگو برگرده، فقط کد، یا هر دو (Claude Code Docs).

یه هشدار مهم هم تو همین مستندات هست. این نقطه‌های بازگشت فقط تغییرهایی رو برمی‌گردونن که با ابزار ویرایش فایل خود Claude Code انجام شده. اگه ایجنت با یه دستور ترمینال چیزی نصب کرده، فایلی رو پاک کرده یا دیتابیس رو تغییر داده، rewind اون رو برنمی‌گردونه. برای همین خود Anthropic هم می‌گه این امکان جای Git رو نمی‌گیره.

Git، تور ایمنی آخر

Git یه دفتر تاریخچه برای کل پروژه‌ست که مستقل از هر ابزاری کار می‌کنه. هر بار که به یه نسخه سالم رسیدی، یه commit می‌سازی، یعنی یه عکس از کل پروژه با یه توضیح کوتاه. اگه همه‌چیز خراب شد، حتی اگه ابزارت از دسترس خارج شد یا اعتبارت تموم شد، می‌تونی به هر کدوم از این عکس‌ها برگردی.

لازم نیست دستورهای Git رو حفظ باشی. اگه با Claude Code کار می‌کنی، بعد از هر قدم سالم بگو «یه commit با یه توضیح مناسب بساز». اگه با Lovable کار می‌کنی، پروژه رو به GitHub وصل کن تا هر تغییری خودکار اونجا ثبت بشه.

---

جلوگیری بهتر از درمانه

بیشتر گیر کردن‌ها رو میشه از قبل کم کرد.

قبل از هر تغییر بزرگ یه نقطه امن بساز. «بزرگ» یعنی هر چیزی که پکیج جدید لازم داره، چند تا صفحه رو درگیر می‌کنه، یا به ذخیره اطلاعات دست می‌زنه. یه نشونه تو تاریخچه یا یه commit، دو ثانیه وقت می‌گیره و می‌تونه یه شب رو نجات بده.

یه یادداشت ثابت برای پروژه داشته باش. خیلی از ابزارها جایی دارن که دستورالعمل‌های ثابت پروژه رو می‌نویسی و مدل تو همه درخواست‌ها رعایتشون می‌کنه. تو Lovable اسمش Knowledge هست (مستندات Lovable) و تو Claude Code فایل CLAUDE.md. چیزهایی مثل «اپ فارسی و راست‌چینه»، «اعداد با رقم فارسی نمایش داده میشن» یا «بدون اجازه من پکیج جدید نصب نکن» رو اونجا بنویس. خیلی از خرابی‌ها از جایی میاد که مدل یه تصمیم قدیمی رو یادش رفته.

از پرامپت‌های بی‌سروته دوری کن. «بهترش کن»، «حرفه‌ای‌ترش کن» یا «یه نگاه کلی بنداز و مشکلاتش رو درست کن» دعوت‌نامه‌ای برای تغییر دادن ده تا فایل با هم‌ان. هر چی دامنه درخواستت مشخص‌تر باشه، خرابی‌های جانبی کمتره.

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

---

کِی دیگه کار هوش مصنوعی نیست؟

گاهی همه این کارها رو می‌کنی و باز گیر می‌کنی. چند تا نشونه هست که میگه مشکل از روش تو نیست.

اگه همه‌چیز یهو با هم خراب شده، حتی پروژه‌هایی که بهشون دست نزدی، احتمالاً مشکل از خود ابزار یا سرویسشه. صفحه وضعیت سرویس رو چک کن، یه ساعت صبر کن و تو این فاصله پیام نفرست.

اگه یه فیچر خاص بعد از پله چهارم نردبان هم درست نشد، شاید از توان اون ابزار برای این پروژه بیرونه. پرداخت آنلاین، سیستم‌های چندکاربره با سطح دسترسی و یکپارچه شدن با سرویس‌های پیچیده معمولاً اولین جاهایی‌ان که ابزارهای مرورگری به سقف می‌رسن. اینجا رفتن به یه ادیتور یا ایجنت مثل Claude Code که کنترل بیشتری بهت می‌ده، یا کمک گرفتن از یه برنامه‌نویس برای همون بخش، معمولاً راه درسته.

و اگه حس می‌کنی هر بار بیشتر از قبل گیر می‌کنی چون نمی‌فهمی اون زیر چه خبره، این خودش یه نشونه خوبه. یعنی پروژه‌هات اون‌قدر جدی شدن که فهمیدن کد ارزشش رو داره. تو بوت‌کمپ مهندسی نرم‌افزار با ایجنت‌های هوش مصنوعی استارکوچ دقیقاً همین مسیر رو می‌ریم، از کار با ایجنت‌ها تا تست و دیباگ و دیپلوی، روی چهار پروژه واقعی و با یه منتور اختصاصی که وقتی گیر کردی کنارته. اگه هم می‌خوای این مهارت‌ها رو زیر فشار یه رقابت تیمی محک بزنی، هکاتون وایب کدینگ استارکوچ رو دنبال کن.

---

سوالات پرتکرار

خطای کنسول انگلیسیه و هیچی ازش نمی‌فهمم، چی کار کنم؟

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

به نسخه قبل برگشتم، اطلاعاتی که تو اپ ثبت کرده بودم پاک شد؟

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

هوش مصنوعی میگه مشکل حل شد ولی هنوز هست. چرا؟

چون اکثر وقت‌ها خودش نتیجه رو امتحان نکرده و فقط کدی نوشته که به نظرش مشکل رو حل می‌کنه. ازش بخواه مدرک بیاره: «بعد از اصلاح، دقیقاً بگو چطور امتحانش کردی و نتیجه چی شد.» تو ایجنت‌هایی مثل Claude Code که می‌تونن خودشون تست اجرا کنن، بخواه تست بنویسه و خروجیش رو نشون بده.

تو پیش‌نمایش همه‌چیز درسته، ولی بعد از انتشار خراب میشه. چرا؟

رایج‌ترین دلیلش تنظیماتیه که فقط تو محیط ساخت وجود داره، مثل کلیدهای API یا آدرس سرویس‌ها. دلیل بعدی کش مرورگره که نسخه قدیمی رو نشون می‌ده. اول صفحه منتشرشده رو با Ctrl+Shift+R یه بار کامل رفرش کن. اگه درست نشد، کنسول همون صفحه منتشرشده رو باز کن و خطاش رو بده، نه خطای پیش‌نمایش رو.

برای اینکه اعتبارم کمتر خرج بشه چی کار کنم؟

بیشترین اعتبار تو حلقه خطا می‌سوزه. قاعده دو تلاش و بعد برگشت، گرفتن فرضیه قبل از تغییر و استفاده از حالت‌هایی مثل Plan mode که کد رو تغییر نمی‌دن، هر سه مستقیم مصرف اعتبار رو پایین میارن.