Gene Kim و Steve Yegge توی کتاب Vibe Coding یه تجربه‌ی تلخ تعریف می‌کنن: ایجنت برای اینکه تست‌ها پاس بشن، بی‌سروصدا تست‌ها رو دستکاری کرده و حتی بخش بزرگی از یه مجموعه‌ی تست رو پاک کرده. (گزارش The Register)
یعنی گفتن «تست هم بنویس» کافی نیست. باید ترتیب کار و خط قرمزها رو صریح بگی. این پرامپت همین کار رو می‌کنه:
متن پرامپت
«می‌خوام قابلیت [اسم قابلیت، مثلا: محاسبه‌ی تخفیف سبد خرید] رو به روش تست‌محور بسازیم. مراحل رو دقیقاً به این ترتیب برو و بعد از هر مرحله صبر کن تا تأیید کنم: ۱) رفتار مورد انتظار رو در چند جمله‌ی ساده بنویس و حالت‌های مرزی رو هم بگو (ورودی خالی، عدد منفی، مقدار خیلی بزرگ). ۲) فقط تست بنویس، هنوز کد اصلی نه. تست‌ها رو اجرا کن و نشونم بده که شکست می‌خورن. ۳) کمترین کدی رو بنویس که تست‌ها رو پاس کنه. ۴) دوباره همه‌ی تست‌های پروژه رو اجرا کن، نه فقط تست‌های جدید رو. قانون‌های غیرقابل‌مذاکره: هیچ تستی رو حذف نکن، skip نکن و شرطش رو شل نکن. اگه فکر می‌کنی یه تست اشتباهه، به‌جای تغییرش دلیلت رو بگو و منتظر من بمون.»
چرا این پرامپت جواب میده؟
تست برای ایجنت یه «چک» عینیه؛ چیزی که می‌تونه خودش اجرا کنه و ببینه کارش درسته یا نه. راهنمای بهترین روش‌های Claude Code هم روی همین تأکید داره که به ایجنت یه راه برای چک کردن کار خودش بدی.
اگه یه باگ عجیب بعد از پاس شدن تست‌ها پیدا شد، پرامپت پیدا کردن ریشه‌ی باگ رو بزن. برای کسی که می‌خواد این روش رو به شکل یه عادت ثابت داشته باشه هم اسکیل Superpowers همین مسیر رو خودکار می‌کنه.
تستی که ایجنت بتونه پاکش کنه، تست نیست؛ تعارفه.