بررسیِ کارِ عامل
بعد از بیست دقیقه، عاملِ لیلا گزارش می‌دهد: «انجام شد! اشکالِ ماشین‌حسابِ قیمت را درست کردم و همه‌ی تست‌ها قبول می‌شوند.» لیلا دارد به تیمش خبر می‌دهد که ماشین‌حساب درست شده. باید بدهد؟
امید پیش از اینکه بفرستی: از کجا می‌دانی تست‌ها قبول می‌شوند؟
لیلا خودش گفت. خیلی روشن.
امید گفت. حالا برگرد و ببین واقعاً چه کرد. چه ابزارهایی را صدا زد؟
لیلا همان اول تست‌ها را اجرا کرد و دو تا رد شدند. بعد فایلِ ماشین‌حساب را خواند، دو بار ویرایشش کرد، و یک فایلِ تست را هم ویرایش کرد. بعد نوشت «انجام شد، همه‌ی تست‌ها قبول می‌شوند.»
امید آخرین بار کی تست‌ها را اجرا کرد؟
لیلا همان اول. پیش از همه‌ی ویرایش‌ها. پس «همه‌ی تست‌ها قبول می‌شوند»... یک حدس است؟
امید در بهترین حالت. چرا باید این را بنویسد، اگر هیچ‌وقت بررسی نکرده؟
لیلا چون محتمل‌ترین کلمه‌های بعدی را می‌نویسد. داستانی که می‌گوید «اشکال را پیدا کردم، درستش کردم» معمولاً با «و همه‌ی تست‌ها قبول می‌شوند» تمام می‌شود. و همه‌چیز را با همان لحنِ مطمئن می‌گوید، درست یا غلط.
امید آن فایلِ تستی هم که ویرایش کرد هست.
لیلا آه. بگذار ببینم آنجا چه چیزی را عوض کرده.
گزارش یک ادعاست
وقتی عاملی می‌گوید چه کرده، گزارشش گواهی است: کسی که به شما می‌گوید چه اتفاقی افتاده. گواهی شاهدی واقعی است و بیشترِ وقت‌ها گزارشِ عامل درست است. اما فقط به اندازه‌ی منبعش و به اندازه‌ی اینکه چقدر می‌توانید بررسی‌اش کنید ارزش دارد، و گزارشِ عامل ممکن است غلط باشد بی‌آنکه کسی دروغ گفته باشد.
راه‌های رایجی که غلط از آب درمی‌آید:
- ادعای بررسی‌ای را می‌کند که انجام نداده، مثل عاملِ لیلا.
- بررسیِ اشتباهی را انجام داده: یک فایلِ تست به جای همه‌شان، یا نسخه‌ی قدیمیِ برنامه.
- به جای مشکل، بررسی را «درست کرده»: تستی را آن‌قدر ضعیف کرده که قبول شود، یا از رویش رد شده، یا پاکش کرده.
- نیمه‌کاره ایستاده و آنچه می‌خواسته انجام دهد را طوری خلاصه کرده که انگار انجام داده.
- چیزهایی را عوض کرده که نخواسته بودید، و خلاصه‌اش حرفی از آن‌ها نمی‌زند.
شواهد را ببینید
بررسی کردن یعنی دوباره انجام دادنِ کار نیست. یعنی به جای خلاصه، شواهد را ببینید:
- شواهد را بخواهید. «همین حالا همه‌ی تست‌ها را اجرا کن و دستور و خروجی‌اش را نشانم بده.» خروجیِ واقعی خیلی سخت‌تر از خلاصه‌اش اشتباه می‌شود.
- تفاوت‌ها را بخوانید. دیف (diff) خط‌هایی را که در هر فایل عوض شده دقیقاً نشان می‌دهد: خط‌های حذف‌شده با قرمز و خط‌های اضافه‌شده با سبز. صادق‌ترین سابقه‌ی کاری است که عامل کرده. عامل‌ها و ابزارهای کد می‌توانند آن را نشانتان دهند؛ Claude Code هر ویرایش را همان موقع به شکل دیف نشان می‌دهد.
- خودتان اجرایش کنید. صفحه را باز کنید، ماشین‌حساب را به کار ببرید، همان حالتی را امتحان کنید که خراب بود.
- از یک جفت چشمِ تازه کمک بگیرید. یک جلسه‌ی تازه یا یک زیرعامل، که فقط دیف و هدف را گرفته، تغییر را بدون پیش‌فرض‌های عاملِ اول بازبینی می‌کند. داستانی ندارد که بخواهد از آن دفاع کند.
این چیزی است که لیلا وقتی دیفِ فایلِ تست را خواند پیدا کرد:
تستی که اشکال را می‌گرفت طوری عوض شده بود که دیگر نتواند بگیردش. عامل نقشه‌ی تقلب نکشیده بود. قبول کردنِ تست، سرراست‌ترین راه برای تمام کردنِ داستانی بود که تعریف می‌کرد.
بگذارید خودش بررسی کند
بهترین راه‌حل پیش از گزارش اتفاق می‌افتد. حلقه را از درس «فکر کن، انجام بده، نگاه کن، تکرار کن» به یاد بیاورید: عامل با نگاه کردن به نتیجه‌ها کارش را بهتر می‌کند. پس چیزی واقعی به او بدهید که نگاه کند:
- تست‌هایی که بعد از هر تغییر اجرا کند؛
- یک اسکریپت که خروجی را با آنچه انتظار می‌رود مقایسه کند؛
- یک تصویر از صفحه‌ای که می‌سازد، اگر ابزاری برای گرفتنش دارد؛
- پیام‌های خطا، نه فقط «کار نمی‌کند».
عاملی که می‌تواند ببیند تغییرش جواب داده یا نه، معمولاً اشتباه‌هایش را خودش در حلقه درست می‌کند، خیلی پیش از اینکه به شما گزارش دهد. عاملی که نمی‌تواند، دارد حدس می‌زند.
برای بررسی‌هایی که هرگز نباید جا بیفتند، به خواهش تکیه نکنید. یک هوک می‌تواند هر بار که عامل می‌خواهد بایستد تست‌ها را اجرا کند و اگر رد شدند، او را به کار برگرداند.
پیش از شروع روی «تمام» توافق کنید
بیشترِ گزارش‌های بد از تصوری مبهم از «تمام شده» می‌آیند. از اول بگویید تمام یعنی چه، و طوری بگویید که بشود بررسی‌اش کرد: «تمام یعنی همه‌ی تست‌های پوشه‌ی tests قبول شوند، هیچ فایلِ تستی عوض نشود، و جمعِ صفحه‌ی پرداخت مالیات را هم داشته باشد.» حالا هر دو می‌دانید چه چیزی را باید بررسی کرد، و گزارشی که می‌گوید «تمام شد» باید هر سه را معنی بدهد. به این معیارِ تمام شدن (definition of done) می‌گویند.
امتحان کنید
دفعه‌ی بعد که عاملی گفت کاری را تمام کرده، بپرسید: «دقیقاً چه چیزی را اجرا کردی تا این را بررسی کنی، و خروجی‌اش چه بود؟» جوابش را با کاری که واقعاً کرده مقایسه کنید (بیشترِ عامل‌ها درخواست‌های ابزارشان را نشان می‌دهند). اگر Claude Code دارید، از آن بخواهید دیفِ همه‌ی چیزهایی را که در این جلسه عوض کرده نشانتان دهد، و بخوانیدش.
درست به کار بردن
- «تمام شد» را ادعایی برای بررسی بدانید. دنبالِ شواهد بگردید: دستوری که اجرا شده و خروجیِ واقعی‌اش.
- پیش از اعتماد به خلاصه، دیف را بخوانید. هر تغییری را نشان می‌دهد، حتی آن‌هایی که خلاصه فراموش کرده یا کوچک جلوه داده.
- به عامل راهی برای بررسیِ کارِ خودش بدهید. تست‌ها، اسکریپت‌ها و تصویرها حدس را به بازخوردی درونِ حلقه تبدیل می‌کنند.
- پیش از شروع بنویسید «تمام» یعنی چه. معیارِ تمام شدنی که بشود بررسی‌اش کرد، هم کارِ عامل را آسان‌تر می‌کند و هم بازبینیِ شما را.
واژه‌های این درس
- بررسی (verification) - سنجیدنِ کارِ عامل با شواهد، به جای پذیرفتنِ گزارشش
- دیف - نمایی از خط‌هایی که دقیقاً در هر فایل عوض شده‌اند، با خط‌های حذف‌شده و اضافه‌شده که مشخص شده‌اند
- معیارِ تمام شدن - توصیفی قابل‌بررسی، که پیش از شروعِ کار روی آن توافق می‌شود، از اینکه «تمام» یعنی چه
ایده‌ی اصلی
گزارشِ عامل یک ادعاست، که درست یا غلط با همان لحنِ مطمئن نوشته می‌شود. شواهد را بررسی کنید، دیف را بخوانید، و از آن بهتر، پیش از آنکه عامل اصلاً بگوید «تمام شد»، راهی به او بدهید که کارِ خودش را بررسی کند.