اول برنامه، بعد کار
لیلا از عاملش می‌خواهد «گزارشِ فصلی را با رقم‌های تازه‌ی فروش به‌روز کن». عامل بی‌درنگ دست به کار می‌شود: سی دقیقه، چهل ویرایش، سه نمودارِ تازه. وقتی لیلا نگاه می‌کند، می‌بیند عامل گزارشِ پارسال را از نو ساخته، نه گزارشِ همین فصل را، و چیدمانِ جدولی را که مدیرش به آن تکیه می‌کند تغییر داده است. تک‌تکِ ویرایش‌ها با دقت انجام شده بود. کلِ کار اشتباه بود.
لیلا کجا باید جلوی این را می‌گرفت؟
لیلا آن‌قدر سرش شلوغ بود. اگر فقط می‌گفت می‌خواهد چه کار کند، در ده ثانیه گزارشِ اشتباه را می‌دیدم.
امید پس ارزان‌ترین لحظه برای پیدا کردنِ اشتباه کِی بود؟
لیلا پیش از اولین ویرایش. درخواستم را از همان اول بد فهمید؛ هر چه بعد آمد روی همان ساخته شد.
امید و پیدا کردنش در پایان چقدر هزینه داشت؟
لیلا سی دقیقه کارِ عامل، به‌اضافه‌ی وقتِ خودم برای بررسیِ چهل ویرایش، به‌اضافه‌ی برگرداندنشان.
امید بیشترِ اشتباه‌های عامل همین شکل را دارند. نه لغزشی در یک گام، بلکه برداشتی نادرست از خودِ کار، که خیلی خوب اجرا شده است. حالا، مدل برنامه‌اش را همان‌طور که پیش می‌رود، گام‌به‌گام می‌نویسد. اگر وادارش کنی اول کلِ برنامه را بنویسد و بایستد، چه؟
لیلا آن‌وقت برنامه را می‌خواندم. «گامِ ۱: باز کردنِ reports/2025-Q3...». گزارشِ اشتباه. با یک خط درستش می‌کردم.
امید درست کردنِ برنامه‌ی اشتباه یک جمله خرج دارد. درست کردنِ گزارشِ اشتباه یک بعدازظهر.
حالتِ برنامه‌ریزی
حالتِ برنامه‌ریزی (plan mode) شیوه‌ای از کار است که در آن عامل می‌تواند نگاه کند ولی دست نزند: می‌تواند فایل‌ها را بخواند، جست‌وجو کند و فکر کند، ولی نمی‌تواند چیزی را ویرایش کند یا هیچ فرمانی را اجرا کند که چیزی را تغییر دهد. کارش این است که با یک برنامه برگردد. شما برنامه را می‌خوانید، اصلاحش می‌کنید، و فقط وقتی تأییدش کنید عامل کار را شروع می‌کند.
در Claude Code (در سال ۲۰۲۶) با Shift+Tab به حالتِ برنامه‌ریزی می‌روید، همان کلیدی که حالت‌های اجازه را عوض می‌کند، چون حالتِ برنامه‌ریزی خودش یک حالتِ اجازه است: حالتی که در آن هر تغییری رد می‌شود. می‌توانید پیامی را هم با /plan شروع کنید. وقتی برنامه آماده شد، Claude Code آن را نشان می‌دهد و می‌پرسد ادامه بدهد یا نه، و شما می‌توانید اول بگویید چه چیزی در آن عوض شود. در هر عاملی می‌توانید تقریباً به همین برسید، اگر بگویید: «هنوز چیزی را تغییر نده. هر چه لازم است بخوان و یک برنامه به من بده.»
چرا جواب می‌دهد
سه دلیل دارد، و هر کدام به چیزی برمی‌گردد که درباره‌ی عامل‌ها می‌دانید.
اشتباه در آغاز ارزان‌تر از همه است. برداشتِ نادرست در آغاز به همه‌ی گام‌های بعدی منتقل می‌شود، و مدل به‌ندرت برمی‌گردد تا انتخاب‌های قبلیِ خودش را زیرِ سؤال ببرد. اگر در برنامه پیدا شود، درست کردنش یک خط است.
بررسیِ برنامه آسان است. چهل ویرایش را به‌راحتی نمی‌شود بازبینی کرد، ولی ده خط برنامه را می‌شود خواند و دید: «گزارشِ اشتباه»، «رقم‌های ماهِ آخرِ فصل را جا انداخته»، «چیدمانِ جدول را تغییر نده».
برنامه در زمینه می‌ماند. برنامه‌ی تأییدشده بخشی از چیزی می‌شود که مدل در همه‌ی گام‌های بعدی می‌بیند. مثل یک یادداشتِ خوب، کارِ طولانی را در مسیر نگه می‌دارد. برای یک کارِ بزرگ، از عامل بخواهید برنامه را در یک فایل ذخیره کند و همان‌طور که پیش می‌رود گام‌ها را تیک بزند، تا حتی اگر نشست فشرده شود، برنامه بماند.
گام‌ها و نقطه‌های بازگشت
دو عادتِ دیگر هم کارهای بزرگ را امن‌تر می‌کنند.
کار را به گام‌هایی بشکنید که بتوانید بررسی‌شان کنید. به جای «کلِ گزارش را از نو بساز»، برنامه‌ای را تأیید کنید که هر گامش به چیزی ختم شود که بتوانید ببینید: «۱. جدولِ فروش را به‌روز کن، بعد بایست تا بررسی‌اش کنم.» گام‌های کوچک‌تر یعنی اشتباه‌های کوچک‌تر.
راهِ برگشت را بشناسید. نقطه‌ی بازگشت (checkpoint) جایی ذخیره‌شده در یک نشست است که می‌توانید به آن برگردید. Claude Code در حین کار نقطه‌های بازگشت نگه می‌دارد، و /rewind گفت‌وگو، فایل‌ها یا هر دو را به نقطه‌ای قبل‌تر برمی‌گرداند، تا یک راهِ اشتباه در یک لحظه برگردانده شود. (فایلی که فقط با فرمان‌هایی که عامل اجرا کرده تغییر کرده باشد، و هرگز با ابزارهای ویرایشِ فایلش، برگردانده نمی‌شود. این هم یک دلیلِ دیگر است که کارتان را در یک سامانه‌ی کنترلِ نسخه مثل git نگه دارید.)
امتحان کنید
دفعه‌ی بعد که کاری به عامل می‌دهید که بیش از چند دقیقه طول می‌کشد، این‌طور شروع کنید: «هنوز چیزی را تغییر نده. هر چه لازم است ببین و یک برنامه‌ی شماره‌دار بنویس.» پیش از آنکه بگذارید شروع کند، برنامه را بخوانید. بشمارید چند چیز را اصلاح کردید که وگرنه به ویرایش‌هایی برای برگرداندن تبدیل می‌شدند.
درست به کار بردن
- برای هر کارِ بزرگ یا مبهمی اول برنامه بخواهید. اگر کار به فایل‌های زیادی دست می‌زند، بیش از چند دقیقه طول می‌کشد، یا می‌شود آن را به دو شکل فهمید، پیش از هر تغییری برنامه بخواهید.
- برنامه را برای برداشتِ نادرست بخوانید، نه برای کلمه‌ی نادرست. دنبالِ هدفی بگردید که بد فهمیده شده، بخشی که جا افتاده، یا تغییری در چیزی که باید همان‌طور بماند.
- بخواهید برنامه بگوید هر گام چطور بررسی می‌شود. «بعد check_report.py را اجرا کن» یا «بعد بایست و جدول را نشانم بده» برنامه را به چیزی تبدیل می‌کند که بتوانید همراهش پیش بروید.
- زود برگردید. اگر گام‌های اول اشتباه رفتند، به عقب برگردید و برنامه را اصلاح کنید، به جای اینکه از عامل بخواهید روی اشتباه‌های خودش وصله بزند.
واژه‌های این درس
- حالتِ برنامه‌ریزی (plan mode) - شیوه‌ای از کار که در آن عامل می‌تواند بخواند و بگردد ولی چیزی را تغییر ندهد، و با برنامه‌ای برمی‌گردد تا آن را تأیید کنید
- نقطه‌ی بازگشت (checkpoint) - جایی ذخیره‌شده در یک نشست که می‌توانید به آن برگردید و آنچه بعد از آن رخ داده را برگردانید
ایده‌ی اصلی
پرهزینه‌ترین اشتباه‌های عامل برداشتی نادرست از کارند که خوب اجرا شده است. خواستنِ برنامه پیش از هر تغییری آن‌ها را وقتی پیدا می‌کند که درست کردنشان یک جمله خرج دارد، نه یک بعدازظهر.