اول از همه: به‌جای این‌که خودت کد رو بخونی، از هوش مصنوعی درباره‌ش سؤال بپرس

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

What is this project about?

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

ازش بخواه مستندسازی کنه، نه فقط توضیح بده

قدم بعدی از یه سؤال ساده جدی‌تره: از agent بخواه برات مستند تولید کنه. این با «توضیح بده» فرق داره چون مجبورش می‌کنه عمیق‌تر بره، ماژول به ماژول کد رو بخونه و مکتوبش کنه:

Please write documentation for this project so I can onboard properly.

وقتی این تجربه رو با پیوستن به یه شرکت جدید تکرار کردی، می‌تونی همین درخواست رو یه پله جدی‌تر کنی: بخواه برای هر ماژول، هر بخش، هر فانکشن مهم یه صفحه‌ی جدا بسازه، معماری رو مستند کنه، دیزاین سیستم رو توضیح بده، و همه‌ی این‌ها رو توی یه فولدر مشخص مثل docs/ بریزه. این فولدر مستندات دیگه فقط برای تو نیست؛ خودِ agent هم دفعات بعد که می‌خواد روی همین پروژه کار کنه از همین مستندات به‌عنوان کانتکست استفاده می‌کنه.

نکته‌ی مهم اینه که ترتیب کار رو عوض نکنی. اول بذار agent کد رو بخونه و بفهمه، بعد از اون بخواه که چیزی رو آپدیت یا بسازه. اگه از اول بگی «این فایل رو آپدیت کن» بدون این‌که قبلش زمینه بدی، agent داره کورکورانه عمل می‌کنه.

CLAUDE.md و AGENT.md: حافظه‌ی بلندمدت پروژه‌ت

هر پروژه‌ی جدیدی که با AI روش کار می‌کنی، باید یه فایل CLAUDE.md (اگه از Claude Code استفاده می‌کنی) یا AGENT.md (اگه از Codex، Antigravity یا هر چیز دیگه‌ای استفاده می‌کنی) داشته باشه. Cursor هم مکانیزم مشابه خودش رو داره (Cursor Rules)، ولی الگوی غالب همین AGENT.mdه.

بعد از این‌که یه بار پروژه رو مستند کردی، از agent بخواه همین فایل رو هم آپدیت کنه:

Now update AGENT.md / CLAUDE.md based on what you learned about this project.

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

چرا اینجا وایب کدینگ جواب نمی‌ده

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

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

یه تغییر کوچیک بده تا رفتار agent رو بسنجی

قبل از این‌که سراغ تغییرات بزرگ بری، یه تغییر خیلی کوچیک و بی‌خطر بده تا ببینی agent کجای کد رو دست می‌زنه:

Change the color of this text.

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

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

Where is the keypad implemented in this project?

خیلی سریع‌تر از سرچ دستیه، چون agent می‌تونه در عرض چند ثانیه فایل و کلاس مربوطه رو پیدا کنه.

کد رو ریویو کن، بعد کامیت کن

اینجاست که فرق واقعی وایب کدر و agentic engineer مشخص می‌شه: وایب کدر نتیجه رو می‌بینه که کار می‌کنه و رد می‌شه؛ agentic engineer کد رو می‌خونه. بعد از هر تغییر، حتی یه تغییر کوچیک، برو دیف رو نگاه کن. ببین دقیقاً چی تغییر کرده، آیا چیزی که نباید تغییر می‌کرد دست نخورده. فقط وقتی که مطمئن شدی، کامیت رو انجام بده — و حتی همین کامیت رو هم می‌تونی از خود agent بخوای:

Please commit all the changes.

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

پیدا کردن و فیکس کردن باگ

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

Could you check how we attach a PDF when adding a new expense?

این درخواست عمداً نمی‌گه که مشکلی وجود داره. فقط می‌خوای agent بره ببینه فلو فعلی چطور کار می‌کنه. خیلی وقت‌ها همینجا خودش متوجه‌ی باگ می‌شه. اگه بخوای عمیق‌تر بری، می‌تونی «and explain it to me» رو هم اضافه کنی تا مجبور بشه توضیح بده، نه فقط context جمع کنه.

بعد از این مرحله‌ی شناخت، حالا مشکل رو دقیق‌تر مطرح کن:

I noticed in the latest release something is missed and attaching/uploading a PDF is not working properly. Could you check deeply and find the issue?

این روش دو مرحله‌ای برای مدل‌های ضعیف‌تر یا کمتر agentic لازم‌تره. مدل‌های خیلی قوی‌تر مثل GPT-5.5 یا Fable خودشون یاد گرفتن که قبل از فیکس کردن باید برن context جمع کنن. ولی وقتی مطمئن نیستی مدلت چقدر قوی رفتار می‌کنه، این روش امن‌تره.

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

قبل از فیکس، تست بنویس

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

Add unit tests for the add-expense use case.

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

معماری کار توئه، هوش مصنوعی فقط پیاده‌سازی می‌کنه

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

اگه با اصول SOLID آشنا نیستی، الان وقتشه یاد بگیری — Single Responsibility، Open/Closed و بقیه‌ی اصول همچنان مهم‌ان، حتی اگه خودت دیگه خط به خط کد نمی‌نویسی. مثلاً اگه بخوای یه سیستم بسازی که بر اساس مدل انتخابی پیاده‌سازی داخلی عوض بشه، Strategy Pattern دقیقاً همین کار رو می‌کنه: ساختار کلی کد یکی می‌مونه، فقط استراتژی بر اساس ورودی عوض می‌شه.

Implement this using the SOLID principles, keep single responsibility per module,
and use a Strategy pattern for switching between providers.

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

مدیریت Context Window وقتی موضوع عوض می‌شه

یه نکته‌ی عملی دیگه: وقتی از یه فیچر به فیچر بعدی می‌ری که ربط چندانی به قبلی نداره، به context window فکر کن. لازم نیست همیشه یه session کاملاً تازه باز کنی، ولی می‌تونی context رو compact کنی تا چیزهای نامرتبط قبلی باعث گیج شدن مدل نشن. هر چقدر context شلوغ‌تر و نامرتبط‌تر باشه، احتمال این‌که مدل جواب اشتباه بده بیشتر می‌شه.

اگه دوست داری ویدئوش رو هم ببینی، لینکش پایین صفحه‌ست.