یک workflow سالم و خوب با AI در ۲۰۲۶ چه شکلیه

یک چیزی هست که کمتر کسی درباره‌اش حرف می‌زنه: AI coding tools می‌تونن به همون اندازه که کمک کنن، اگه باهاشون درست کار نکنی، اوضاع رو بدتر کنن. نه چون بد هستن — بلکه چون وقتی یه ابزار خیلی قوی داری و هنوز ندونی کِی ازش استفاده کنی، ممکنه در نهایت بیشتر وقتت صرف debug کردن چیزی بشه که خودت می‌تونستی سریع‌تر بنویسیش.

۲۰۲۶ از یه نظر نقطه‌ی عجیبیه. ابزارها از هر زمان دیگه‌ای بهترن، ولی noise هم از همیشه بیشتره. هر هفته یه agent جدید، یه model جدید، یه ادعای جدید که «این بار متفاوته». وسط این سروصدا، یه workflow سالم ربطی به اینکه از کدوم tool استفاده کنی نداره — ربط داره به اینکه چطور باهاشون فکر کنی.

اشتباه اول: context دادن به‌جای فکر کردن

آدم‌ها یه عادت دارن که بلافاصله وقتی به مشکل می‌خورن، می‌رن سراغ AI. این بد نیست — ولی مشکل اینه که اگه قبلش پنج دقیقه با خودت فکر نکرده باشی، مدل هم نمی‌دونه دقیقاً دنبال چی هستی. نتیجه یه جواب generic می‌شه که یا کامل نیست یا با context پروژه‌ات جور نیست.

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

اشتباه دوم: agent بدون context

agentها — Hermes، Claude Code، Codex — وقتی می‌دونن پروژه چیه، قبلاً چی شده، و چه محدودیت‌هایی وجود داره، خیلی بهتر کار می‌کنن. ولی بدون این context، حتی یه agent خوب هم می‌تونه چیزی بسازه که technically درسته ولی با معماری پروژه‌ات جور نیست.

راه‌حل‌هایی مثل skill file ها برای همین اومدن: به‌جای اینکه هر بار از اول توضیح بدی، یه بار درست توضیح می‌دی و می‌ذاریش جایی که agent هر وقت لازم بود بخونتش. این ساده‌ترین روشیه که workflow ات رو از «هر بار از صفر» به «agent می‌دونه کجاست» تبدیل می‌کنه.

اشتباه سوم: باور کردن خروجی بدون review

این شاید از همه‌شون خطرناک‌تره. مدل‌ها اشتباه می‌کنن — و اشتباهاتشون معمولاً خیلی مطمئن به نظر می‌رسن. کدی که مدل نوشته رو نخونده commit نکن. نه به‌خاطر اینکه کد بد باشه — بلکه چون review کردن کد همونی هست که باعث می‌شه تو بفهمی چی ساخته شده. اگه این رو skip کنی، چند هفته دیگه یه codebase داری که نمی‌دونی داخلش چیه.

این یه قانون نیست که هر خط رو خودت بنویسی. قانون اینه که هر خطی رو که merge می‌کنی، بدونی چیکار می‌کنه.

یه workflow که در عمل کار می‌کنه

یه الگوی ساده که در عمل جواب داده:

برای کارهای کوچیک (یه function، یه refactor کوچیک، یه bug): مستقیم از chat استفاده کن. context لازم نیست زیاد باشه، نتیجه سریعه، و راحت review می‌شه.

برای کارهای متوسط (یه feature جدید، یه سرویس): یه prompt با جزئیات کافی بنویس — معماری، محدودیت‌ها، output مورد انتظار. بعد خروجی رو بگیر و review کن. اگه چیزی جا افتاده یا جور نیست، iteration کن.

برای کارهای بزرگ و پیچیده: اینجاست که agent ها معنی پیدا می‌کنن. یه agent مثل Hermes یا Claude Code می‌تونه یه task چندمرحله‌ای رو مدیریت کنه — ولی فقط اگه بهش context کافی بدی، skill های مرتبط بهش دادی، و حواست به کارش باشه. «بذار agent همه چیز رو بسازه و من بعداً نگاه کنم» یه workflow نیست — یه روش برای ساختن چیزیه که نمی‌فهمیش.

درباره‌ی دسترسی و مرزها

یه چیزی که از تجربه‌ی مستقیم یاد گرفتم: به agent هایی که به filesystem دسترسی دارن، sudo ندید. نه به‌خاطر اینکه agent بد نیت داره — بلکه چون وقتی یه task پیچیده انجام می‌ده و اشتباه می‌کنه، sudo یعنی اشتباهش جبران‌ناپذیره. یه دیتابیس محلی پاک می‌شه. یه پوشه حذف می‌شه. این چیزیه که «بعید نیست» — اتفاق می‌افته.

محدود کردن دسترسی یه لایه‌ی safety net هست، نه بی‌اعتمادی به ابزار.

درباره‌ی مدل‌ها و هزینه

اکثر کارهای روزانه‌ی یه توسعه‌دهنده‌ی معمولی به بهترین و گران‌ترین مدل نیاز ندارن. توضیح یه مفهوم، بررسی یه کد، نوشتن یه test، refactor کوچیک — اینا رو مدل‌های ارزون‌تر هم خوب انجام می‌دن.

جاهایی که مدل قوی‌تر فرق می‌کنه: وقتی task پیچیده‌ست و نیاز به چندین مرحله reasoning داره، وقتی context بزرگه، یا وقتی agent باید خودش تصمیم بگیره چه مرحله‌ای بعدی باشه. برای بقیه، مدل ارزان‌تر کافیه — و ترکیب ابزارهایی مثل 9Router با agentها می‌تونه هزینه رو به حداقل برسونه.

یه جمله خلاصه

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