۳۰۰۰+ ساعت وایب کدینگ؛ ستاپ من رو کپی نکنید

۲۵ شهریور ۱۴۰۵

سلام سلام!

این یکی قراره یه کم شخصی‌تر باشه.

بیشتر از ۳۰۰۰ ساعت از وقتی که تقریباً جدی رفتم توی داستان AI Coding می‌گذره.

مدل عوض کردم.

Harness عوض کردم.

Skill ساختم.

Skill پاک کردم.

MCP نصب کردم.

MCP پاک کردم :))

Agent Team ساختم.

Workflowهایی ساختم که فکر می‌کردم شاهکار مهندسی‌ان و دو روز بعد فهمیدم برای عوض کردن رنگ یه Button دارن هفت تا Agent Spawn می‌کنن.

یه عالمه Token سوزوندم.

یه عالمه کد خوب تحویل گرفتم.

یه عالمه کد هم تحویل گرفتم که در ظاهر خیلی قشنگ بود ولی اگر پنج دقیقه بیشتر نگاهش می‌کردی می‌فهمیدی باید مستقیم بره تو سطل آشغال.

و اگر بخوام کل این مقاله رو همین اول توی یه جمله خلاصه کنم:

ستاپ من رو کپی نکنید.

جدی می‌گم.

ازش ایده بگیرید.

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

Toolهایی که به دردتون می‌خوره بردارید.

ولی اینکه Config یه نفر رو خط‌به‌خط بردارید و انتظار داشته باشید برای شما هم بهترین Workflow دنیا بشه، به نظرم یکی از بدترین کارهاییه که می‌شه توی Agentic Coding انجام داد.

چرا؟

چون من Full-stack و Backend کار می‌کنم.

یکی دیگه ML Engineerـه.

یکی Firmware می‌نویسه.

یکی یه SaaS سه‌هزارخطی داره.

یکی Monorepo ده‌ساله‌ای داره که اگه اشتباهی یه Package رو Update کنی سه کشور سقوط می‌کنن.

حتی دو نفر که روی یک پروژه کار می‌کنن ممکنه Workflow متفاوتی لازم داشته باشن.

و اینجا می‌رسیم به چیزی که به نظرم از کل Setup مهم‌تره.

قبل از Tool، خودت

جادی توی بحث اخیرش درباره‌ی AI و برنامه‌نویسی یه نکته‌ی خیلی مهم داشت:

خودت باید متخصص بشی.

و به نظرم این دقیقاً چیزیه که وسط تمام هیجان Agentها راحت فراموش می‌کنیم.

AI باعث نشده تخصص بی‌ارزش بشه.

برعکس.

هرچی Agent قوی‌تر می‌شه، ارزش کسی که می‌تونه خروجی Agent رو قضاوت کنه بیشتر می‌شه.

اگر Backend بلد نیستی و Agent یه معماری Backend برات می‌نویسه، از کجا می‌فهمی خوبه؟

اینکه Compile شده؟

کافی نیست.

از کجا می‌فهمی Transaction Boundary درست گذاشته؟

از کجا می‌فهمی Race Condition نداره؟

از کجا می‌فهمی Queryـش با ده میلیون Row منفجر نمی‌شه؟

از کجا می‌فهمی Authentication Flow ظاهراً کار می‌کنه ولی یه Security Hole مسخره وسطشه؟

همین برای Frontend.

Distributed Systems.

Networking.

Linux.

Database.

Security.

ML.

هرچی.

AI می‌تونه Implementation رو خیلی سریع‌تر کنه.

ولی برای اینکه بفهمی چی باید ساخته بشه و چیزی که ساخته شده خوبه یا نه، هنوز خودت وسط داستانی.

من حتی می‌گم هرچی AI بهتر بشه، این تفاوت شدیدتر می‌شه.

چون امروز یه آدم متوسط و یه آدم واقعاً متخصص هر دو می‌تونن با Agent در چند ساعت ده هزار خط کد تولید کنن.

فرقشون اینه که یکی ده هزار خط درست تولید می‌کنه.

اون یکی ده هزار خط Technical Debt تولید کرده که هنوز خودش خبر نداره.

پس قبل از اینکه بریم سراغ Harness و Skill و MCP:

روی تخصص خودتون کار کنید.

این احتمالاً بهترین Upgrade برای Coding Agent شماست.

---

۱ — مدل؛ هنوز مهم‌ترین قطعه

یه دوره‌ای بین AI Coding Community مد شده بود بگن:

Model مهم نیست، Harness مهمه.

نه :))

Harness خیلی مهمه.

ولی Model هنوز موتور ماشین شماست.

یه Harness فوق‌العاده نمی‌تونه Reasoning، Coding Ability یا Knowledge ضعیف یه Model رو به‌طور جادویی درست کنه.

من تقریباً این شکلی نگاه می‌کنم:

Model = Capability

Harness = How much of that capability you can actually use

Workflow = Where that capability gets used

You = Who decides whether any of it is good

و نکته اینجاست که بهترین Model هم برای همه‌ی Taskها یکی نیست.

گاهی یه Model سریع و ارزون برای:

• Rename
• Boilerplate
• تست ساده
• Docs
• Migration کوچیک

کاملاً کافیه.

لازم نیست برای تغییر اسم یه Function بزرگ‌ترین Frontier Model موجود رو بیدار کنید.

از اون طرف یه Migration معماری، Debug عجیب یا Security Review ممکنه دقیقاً جایی باشه که خرج Model بهتر ارزشش رو داره.

من سعی می‌کنم Model رو بر اساس Task انتخاب کنم، نه Fanboy بودن نسبت به Provider.

---

۲ — هارنسسسسسس

حالا می‌رسیم به Harness.

Harness اون محیطیه که Model داخلش تبدیل می‌شه به Coding Agent.

مدل به تنهایی که نمی‌تونه بره فایل پروژه شما رو بخونه.

Harness بهش می‌ده:

Model
  │
  ├── filesystem
  ├── shell
  ├── git
  ├── search
  ├── LSP
  ├── MCP
  ├── skills
  ├── subagents
  ├── context management
  ├── compaction
  ├── permissions
  └── agent loop

اینجاست که می‌بینید یه Model دقیقاً یکسان ممکنه توی دو Client عملکرد کاملاً متفاوتی داشته باشه.

یکی Context رو بهتر مدیریت می‌کنه.

یکی Search بهتری داره.

یکی Editهاش مطمئن‌تره.

یکی LSP رو می‌فهمه.

یکی Agent Loop خیلی Aggressive داره و قبل از اینکه بفهمی چی شده کل Repository رو Refactor کرده :))

یکی Context رو بهینه‌تر می‌چینه.

یکی نصف Tokenهات رو برای پیدا کردن یه Function می‌سوزونه.

ستاپ من

برای کارهای General و بخش بزرگی از Coding روزمره:

OpenCode

و خیلی وقت‌ها مدل‌های DeepSeek از طریق OpenCode Go.

برای Code Review و بعضی Taskهایی که می‌خوام یه Agent مستقل‌تر داشته باشم:

Codex

و برای مدیریت Codex خیلی وقت‌ها از:

T3 Code

روی Server استفاده می‌کنم.

ولی نکته دوباره همونه.

من به شما نمی‌گم:

برید OpenCode نصب کنید چون بهترینه.

ممکنه برای Model شما Claude Code بهتر باشه.

ممکنه Cursor بهتر باشه.

ممکنه Codex CLI بهتر باشه.

ممکنه حتی یه Harness ساده‌تر برای کارتون کیفیت بیشتری بده چون Noise کمتری وارد Workflow می‌کنه.

Harness رو Benchmark کنید.

باهاش ازدواج نکنید.

---

۳ — Harness تنها نیست؛ Plugin Layer

بعد روی Harnessها یه لایه‌ی دیگه داریم.

چیزهایی مثل:

Oh My OpenAgent

Oh My Codex

OMP / oh-my-pi

و کلی Plugin و Extension دیگه.

اینا میان Harness خام رو یه مرحله جدی‌تر می‌کنن.

مثلاً ممکنه اضافه کنن:

• Agentهای تخصصی
• Planner
• Reviewer
• Researcher
• LSP integration
• Hooks
• Task routing
• Better compaction
• Background agents
• Debugger
• Git workflows
• MCP management
• Better search
• Parallel workers

من خودم Oh My OpenAgent رو دوست دارم و استفاده می‌کنم.

چون بعضی Taskها واقعاً با orchestration بهتر خیلی بهتر انجام می‌شن.

ولی یه نکته.

هر Feature مجانی نیست.

ممکنه قیمتش Token باشه.

Latency باشه.

Context Pollution باشه.

یا حتی Complexity باشه.

فرض کنید Task شما:

توی Footer سال 2025 رو کن 2026.

و Setup شما می‌گه:

Research Agent started
Architecture Agent started
Explore Agent started
Frontend Expert started
Reviewer started

داداش :))

یه grep می‌خواست.

هر چیزی که Agent رو قوی‌تر می‌کنه، لزوماً Workflow رو بهتر نمی‌کنه.

---

۴ — Skillللللللل

اینجا به یکی از قسمت‌های مورد علاقه‌ی خودم می‌رسیم.

Skills.

Skill از نظر ظاهری خیلی وقت‌ها چیز عجیبی نیست.

یه سری فایل Markdown.

شاید چندتا Reference.

شاید Script.

شاید Template.

ولی اثرش می‌تونه خیلی زیاد باشه.

چرا؟

چون دارید یه Behavior تکرارشونده رو از Promptهای موقت تبدیل می‌کنید به Procedure دائمی Agent.

مثلاً من هر بار برای SEO Review نگم:

صفحه رو بخون، Metadata رو چک کن، Canonical رو ببین، Schema رو بررسی کن، Internal Linking رو بررسی کن...

یه Skill دارم.

Agent می‌فهمه وقتی این نوع Task میاد، Procedure چیه.

ولی Skill Collector نشید

این خیلی مهمه.

یه نفر میاد می‌گه:

این Skill Pack زندگی منو عوض کرد.

و شما ۱۲۷ تا Skill رو Install می‌کنید.

نه.

اول بخونش.

بعد تستش کن.

ببین:

آیا روی Model تو خوب جواب می‌ده؟

آیا بیش از حد Context مصرف می‌کنه؟

آیا Agent رو زیادی rigid می‌کنه؟

آیا اصلاً برای Taskهای تو نوشته شده؟

آیا یه مشکل واقعی رو حل می‌کنه؟

من خودم از Skillهای Matt، Superpowers و Skillهای Custom استفاده می‌کنم.

ولی کلی Skill هم دیدم که برای Workflow من فقط Token Tax بودن.

---

۵ — بهترین Skill احتمالاً Skillیه که خودت می‌سازی

اینجا به نظرم Workflow از حالت Generic خارج می‌شه.

فرض کنید طی دو هفته پنجاه بار به Agent گفتید:

قبل از تغییر API همه‌ی Consumerها رو پیدا کن. Compatibility رو بررسی کن. تست‌ها رو Update کن. Breaking Change رو Report کن.

تبریک.

شما الان یه Skill دارید که هنوز فایلش رو نساختید :))

قاعده‌ی خودم:

اگر یه Prompt طولانی رو مرتب تکرار می‌کنم، بررسی می‌کنم آیا باید Skill بشه یا نه.

مثلاً:

---
name: safe-api-change
description: Use when modifying existing API contracts.
---

Before implementation:

1. Find all consumers.
2. Inspect current request/response contracts.
3. Identify compatibility constraints.
4. Check migrations.
5. Implement the smallest safe change.
6. Update unit and integration tests.
7. Report breaking changes.

حالا لازم نیست هر بار از صفر Behavior رو توضیح بدید.

Skill خوب چه شکلیه؟

Skill خوب معمولاً:

یه هدف مشخص داره.

Trigger مشخص داره.

Procedure مشخص داره.

Verification مشخص داره.

و از همه مهم‌تر:

سعی نمی‌کنه دنیا رو حل کنه.

مثلاً:

frontend-development

Skill خیلی گنده‌ایه.

ولی:

review-react-component-accessibility

خیلی دقیق‌تره.

برای ساخت Skill هم من رویکرد writing-great-skills رو خیلی دوست دارم.

اصلش ساده‌ست:

ما نمی‌تونیم Model stochastic رو deterministic کنیم.

ولی می‌تونیم Processش رو deterministicتر کنیم.

---

۶ — AGENTS.md و CLAUDE.md شوخی نیستن

اگر پروژه‌ی جدی دارید، Agent نباید هر بار وارد Repository بشه و مثل یه توریست بگه:

سلام، اینجا کجاست؟

AGENTS.md برای من تقریباً README مخصوص Agentـه.

اما نه یه README معمولی.

چیزهایی باید توش باشه که فقط با خواندن Code احتمالاً مشخص نمی‌شن.

مثلاً:

# Architecture

- Handlers must stay thin.
- Business logic lives in internal/service.
- Database access only through repositories.
- Public API changes require backwards compatibility.

# Commands

Backend:
go test ./...

Frontend:
bun test
bun run typecheck

# Rules

- Never edit generated files.
- Do not add dependencies without justification.
- Never bypass authentication in tests.

این اطلاعات خیلی باارزش‌تر از اینه که بنویسید:

This project uses React.

Agent خودش Package.json رو می‌بینه داداش :))

AGENTS.md رو ۵۰ هزار خط نکنید

این فایل باید Agent رو راهنمایی کنه.

نه اینکه Context Window رو بکشه.

من دوست دارم ساختارش چیزی شبیه این باشه:

AGENTS.md
   │
   ├── docs/architecture.md
   ├── docs/database.md
   ├── docs/auth.md
   ├── docs/deployment.md
   └── docs/decisions/

یعنی AGENTS.md بیشتر Map باشه.

جزئیات برن توی Documentation مناسب.

CLAUDE.md

اگر Claude Code استفاده می‌کنید، CLAUDE.md هم همون Role رو برای Claude داره.

من ترجیح می‌دم Ruleهای مشترک رو چند بار Duplicate نکنم.

یه Source of Truth داشته باشم و فقط Harness-specific detailها جدا باشن.

چون بدترین چیزی که می‌تونه اتفاق بیفته:

AGENTS.md:
Use PostgreSQL.

CLAUDE.md:
Use SQLite.

docs/architecture.md:
We migrated to MySQL six months ago.

Agent هم وسطش:

☠️

---

۷ — Agent باید Codebase رو بشناسه؛ Codebase Memory

حالا یکی از چیزهایی که توی Workflow خودم خیلی مهم شده:

Codebase Memory.

مشکل Agentها روی پروژه‌های بزرگ اینه که هر Session انگار دچار فراموشی می‌شن.

می‌گی:

این Function از کجا Call می‌شه؟

Agent:

grep
read
grep
read
grep
read

بعد ۲۰ هزار Token خرج کرده فقط بفهمه چه خبره.

برای Repository کوچیک قابل تحمله.

برای Codebase بزرگ خیلی بد می‌شه.

اینجاست که ابزارهایی مثل Codebase Memory برام جذاب شدن.

ایده‌ش اینه که Codebase رو به یه representation ساختاریافته‌تر تبدیل کنی.

مثلاً Knowledge Graph از:

Functions
Classes
Modules
Imports
Calls
Routes
Types
Dependencies

بعد Agent برای فهمیدن:

اگر این Function رو تغییر بدم چه چیزهایی ممکنه بشکنه؟

لازم نیست هر بار نصف Repository رو از صفر بخونه.

می‌تونه اول ساختار رو Query کنه.

مثلاً مفهومی:

UserService.create()
        │
        ├── called by /api/users
        ├── called by AdminService
        └── writes UserRepository

بعد فقط فایل‌هایی که واقعاً لازم داره رو باز کنه.

چرا این مهمه؟

چون یه مشکل بزرگ Agentic Coding:

Exploration Cost

ـه.

خیلی وقتا Model پنج دقیقه Code نمی‌نویسه.

داره می‌فهمه Repository چیه.

اگر این فهمیدن رو سریع‌تر و ساختاریافته‌تر کنیم:

Token کمتر.

Tool Call کمتر.

Hallucination کمتر.

و مهم‌تر:

Agent قبل از تغییر، Impact رو بهتر می‌فهمه.

من Codebase Memory رو جای Search معمولی نمی‌ذارم.

هر دو لازمن.

Graph می‌گه:

احتمالاً اینجاها مهمن.

بعد Agent می‌ره Source واقعی رو می‌خونه.

یعنی:

Codebase Memory
      ↓
Find relevant structure
      ↓
Source files
      ↓
Verify reality

این خیلی بهتر از Blind Graph Trustـه.

---

۸ — Memory فقط «یادش بمونه چی گفتم» نیست

خیلی‌ها وقتی می‌گن Agent Memory، فکر می‌کنن منظور اینه:

اسم منو یادش باشه.

برای Coding، Memory چند لایه داره.

من تقریباً این‌طوری می‌بینمش:

Level 1
Global preferences

Level 2
Project instructions

Level 3
Architecture / docs

Level 4
Codebase structural memory

Level 5
Feature spec

Level 6
Current task/session context

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

یه Session پنج‌ساعته با دویست هزار Token Context.

Agent اولش همه‌چی می‌فهمید.

آخرش نمی‌دونه اسم خودش چیه :))

Context بیشتر همیشه بهتر نیست.

Context مرتبط بهتره.

---

۹ — Spec بنویسید؛ جدی

اینجا یکی از بزرگ‌ترین تفاوت‌های Workflow امروزم با اول کاره.

اوایل:

من:
یه Dashboard کامل بساز.

Agent:
حتما!

سه ساعت بعد:

یه چیزی ساخته.

کار هم می‌کنه.

ولی چیزی که من می‌خواستم نیست :))

مشکل Agent نبود.

مشکل این بود که:

من نمی‌دونستم دقیقاً چی می‌خوام.

برای Featureهای جدی الان خیلی بیشتر Spec-first کار می‌کنم.

نه اینکه برای تغییر Padding یه RFC هشتادصفحه‌ای بنویسم.

ولی Feature بزرگ باید قبل از Implementation یه تعریف درست داشته باشه.

مثلاً:

# Goal

کاربر بتواند Sessionهای فعال حسابش را ببیند و revoke کند.

# Non-goals

- تغییر Login flow
- تغییر token format
- اضافه کردن device fingerprinting

# Requirements

- list active sessions
- revoke one session
- revoke all other sessions
- current session مشخص باشد

# Constraints

- API فعلی backward-compatible بماند
- migration بدون downtime باشد

# Acceptance Criteria

- revoked sessions immediately fail authentication
- current session can remain active
- tests cover multi-device login

حالا Agent چیزی برای Align شدن داره.

---

۱۰ — Spec-driven development و Spec Kit

برای Featureهای بزرگ‌تر من Spec Kit و رویکرد Spec-driven رو خیلی منطقی می‌بینم.

ایده اینه که مستقیم از:

Idea
↓
Code

نپری.

یه مسیر داشته باشی:

Idea
↓
Specification
↓
Clarification
↓
Technical Plan
↓
Tasks
↓
Implementation
↓
Verification

فرقش خیلی زیاده.

Specification

می‌گه:

چی می‌خوایم و چرا؟

نه اینکه:

از PostgreSQL و Redis و Kafka استفاده کن.

اون Implementationـه.

Spec باید Problem رو تعریف کنه.

Clarification

اینجا Agent باید سؤال بپرسه.

مثلاً:

وقتی کاربر account خودش رو delete کرد، sessionهای child account چی می‌شن؟

این سؤال قبل از Coding هزار برابر ارزون‌تر از بعدشه.

Plan

بعد تازه می‌ریم سراغ:

کدوم فایل‌ها؟

چه Schema change؟

چه API؟

چه Migration؟

چه Test؟

Tasks

Plan تبدیل می‌شه به unitهای قابل اجرا.

مثلاً:

T1 Add session repository query

T2 Add revoke endpoint

T3 Add authorization check

T4 Add integration tests

T5 Add frontend session list

T6 Verify backwards compatibility

حالا Agent یه Checklist واقعی داره.

Implement

اینجا Coding Agent تازه اجازه داره وحشی بشه :))

Converge / Verify

قسمتی که خیلی‌ها فراموش می‌کنن.

Agent نباید فقط بگه:

Done.

باید برگرده Spec رو بخونه و بگه:

Requirement 1 ✓
Requirement 2 ✓
Requirement 3 ✗
Test scenario 4 ✗

این Loop خیلی مهمه.

چون Agentها عاشق اینن که ۸۰ درصد Task رو انجام بدن و با اعتمادبه‌نفس ۱۰۰ درصد اعلام کنن.

---

۱۱ — ولی Spec هم می‌تونه Overengineering بشه

باز هم همون مشکل.

Feature:

یه دکمه Logout اضافه کن.

Workflow:

constitution
spec
clarify
research
plan
architecture review
risk analysis
tasks
implementation
convergence
postmortem

نه :))

من Workflow رو بر اساس اندازه‌ی Task Scale می‌کنم.

تقریباً:

Tiny change
→ مستقیم اجرا + تست

Medium task
→ mini-plan + implementation + review

Large feature
→ spec + plan + tasks + implementation + review

Architectural / risky
→ research + spec + ADR + plan + staged implementation

Process باید Complexity رو کنترل کنه.

نه اینکه خودش Complexity جدید بسازه.

---

۱۲ — ADR؛ چرا این کد عجیب اینجاست؟

Agentها یه عادت بد دارن.

یه چیز عجیب می‌بینن و می‌گن:

اینو تمیزش می‌کنم.

ولی بعضی چیزهای عجیب دلیل دارن.

مثلاً:

// عجیب به نظر میاد
time.Sleep(250 * time.Millisecond)

Agent:

unnecessary delay removed.

Production:

💥

شاید اون Delay workaround یه Bug توی upstream service بوده.

برای تصمیم‌های معماری مهم، ADR خیلی کمک می‌کنه.

مثلاً:

ADR-014

Decision:
SQLite is used instead of PostgreSQL.

Reason:
Application must run fully offline on Windows.

Do not migrate to a network database without
changing the deployment model.

حالا Agent می‌فهمه چرا.

این Contextیه که از Code به تنهایی نمی‌شه فهمید.

---

۱۳ — Context Engineering

یه مدت همه Prompt Engineering می‌گفتن.

به نظرم برای Coding Agent:

Context Engineering خیلی مهم‌تره.

Prompt شما شاید ۵۰ خط باشه.

ولی Agent روی Repository صد هزار خطی کار می‌کنه.

مسئله اینه:

چه چیزی باید وارد Context بشه؟

چه چیزی نباید بشه؟

من دوست دارم Context مثل یه Funnel باشه:

Task
 ↓
Relevant spec
 ↓
Relevant architecture docs
 ↓
Codebase graph/search
 ↓
Relevant source files
 ↓
Tests

نه:

cat entire_repo/*

Context Window انبار نیست.

هرچی بیشتر بریزی داخلش الزاماً Agent باهوش‌تر نمی‌شه.

گاهی بدتر می‌شه.

---

۱۴ — Session Hygiene

این چیزی بود که با درد یاد گرفتم :))

یه Session رو از صبح باز کردی.

اول:

Backend bug.

بعد:

CSS.

بعد:

Database migration.

بعد:

SEO.

بعد:

Docker.

بعد می‌گی:

حالا Payment رو درست کن.

Context الان آش شله‌قلمه.

من برای تغییر Domain بزرگ Session جدید رو ترجیح می‌دم.

ولی Session جدید نباید Brain Reset کامل باشه.

چون:

AGENTS.md

Docs

Spec

Codebase Memory

Git

همه اطلاعات پایدار رو نگه داشتن.

یعنی:

Session باید Disposable باشه. Knowledge نه.

---

۱۵ — Agent اول Research کنه، بعد Edit

یکی از چیزهایی که خیلی کیفیت رو بهتر کرده جدا کردن:

Explore

از:

Implement

ـه.

مثلاً اول می‌گم:

فعلاً هیچ فایلی رو تغییر نده. Architecture این Feature رو پیدا کن، مسیر Data رو توضیح بده و بگو چه چیزهایی تحت تأثیرن.

بعد خروجی رو نگاه می‌کنم.

اگر منطقی بود:

حالا Plan بده.

بعد:

Implement.

این خیلی بهتر از اینه که Agent همزمان در حال فهمیدن سیستم باشه و Code هم تغییر بده.

---

۱۶ — Plan خوب باید قابل رد کردن باشه

یه Plan خوب فقط این نیست:

1. Update backend
2. Update frontend
3. Add tests

مرسی Sherlock :))

Plan خوب باید جوری باشه که بتونم قبل از Code بگم:

نه، مرحله ۲ غلطه.

مثلاً:

1. Add repository method in user_repository.go
2. Expose service-level revokeSession()
3. Add DELETE /sessions/:id
4. Reuse existing auth middleware
5. Add integration test for revoked token
6. Update SessionList component

حالا واقعاً می‌تونم Review کنم.

---

۱۷ — Multi-agent؛ کمتر از چیزی که Twitter می‌گه

من Multi-agent رو دوست دارم.

ولی Twitter یه جوری نشونش می‌ده انگار اگر کمتر از ۱۶ Agent داشته باشی برنامه‌نویس نیستی :))

بهترین استفاده‌ای که من از Subagent دیدم:

Parallel exploration

مثلاً یکی Backend رو بررسی کنه.

یکی Frontend.

یا:

Independent review

Implementer یه Agent.

Reviewer یه Agent دیگه با Context تمیز.

یا:

Domain specialist

Security Agent.

Database Agent.

UI Agent.

چیزی که دوست ندارم:

manager
→ manager's manager
→ architect
→ planner
→ planner reviewer
→ coding coordinator
→ implementer

برای TODO App.

هر Agent اضافه یعنی Communication Cost.

---

۱۸ — Code Review باید مستقل باشه

این خیلی مهمه.

Agent یه Feature رو نوشته.

بعد می‌گی:

Review your own code.

Agent:

Excellent implementation! Only minor improvements.

:))

من Review مستقل رو خیلی ترجیح می‌دم.

حتی اگر بتونم Model یا Harness رو عوض می‌کنم.

Implementer شاید DeepSeek باشه.

Reviewer Codex.

یا برعکس.

Reviewer باید دنبال اینا بگرده:

Correctness
Architecture
Security
Performance
Edge cases
Tests
Compatibility
Unnecessary complexity

بعد Findings بده.

نه اینکه کل Code رو دوباره Rewrite کنه چون سلیقه‌ش فرق داره.

---

۱۹ — Tests، بهترین زبان برای حرف زدن با Agent

یکی از بزرگ‌ترین اهرم‌ها برای Agent، Testـه.

چون به‌جای:

فکر کنم درسته.

یه Oracle داریم:

PASS
FAIL

هرچی Task objectively verifiableتر باشه، Agent بهتر کار می‌کنه.

مثلاً:

"Fix login."

ضعیفه.

ولی:

These tests currently fail:

TestExpiredRefreshToken
TestRevokedSession
TestConcurrentRefresh

Make all three pass without changing the public API.

عالیه.

Agent می‌تونه Loop بزنه:

edit
↓
test
↓
failure
↓
inspect
↓
edit
↓
test

اینجا autonomy واقعاً ارزش پیدا می‌کنه.

---

۲۰ — Worktree و Branch خیلی مهم‌تر شدن

وقتی چند Agent همزمان داری، نباید همه توی یه Working Tree وحشی بشن.

من جداسازی رو دوست دارم.

مثلاً:

main

├── worktree-auth
├── worktree-dashboard
└── worktree-review

هر Agent فضای خودش.

Commit خودش.

Diff خودش.

بعد می‌شه Review کرد.

Agent بدون Git Safety Net مثل اینه به یه Intern خیلی سریع Root بدی و Auto-save هم روشن باشه :))

---

۲۱ — AI in Production

اینجا دیگه بازی تمومه.

Prototype رو می‌تونی Vibe کنی.

Production رو نه.

برای پروژه‌ی جدی:

Feature
↓
Branch / Worktree
↓
Implementation Agent
↓
Tests
↓
Static checks
↓
Independent AI Review
↓
Security Review if needed
↓
PR
↓
CI
↓
Human review
↓
Merge

AI سرعت Pipeline رو زیاد می‌کنه.

قرار نیست Pipeline رو حذف کنه.

اگر قبل از AI:

Test

Review

CI

Security

داشتیم، الان دلیل کمتری برای حذفشون داریم، نه بیشتر.

چون الان می‌تونیم خیلی سریع‌تر کد بیشتری تولید کنیم.

یعنی خیلی سریع‌تر هم می‌تونیم Bug بیشتری تولید کنیم :))

---

۲۲ — Security برای Agent جدیه

این یکی مخصوصاً وقتی MCP و Shell و Browser وارد می‌شن مهمه.

Agent ممکنه دسترسی داشته باشه به:

Repository.

SSH.

Database.

Cloud.

GitHub.

Browser.

Email.

Production.

فقط چون Agent می‌تونه کاری رو انجام بده به این معنی نیست که باید Permissionش رو داشته باشه.

من اصل:

Least Privilege

رو خیلی جدی می‌گیرم.

Agentی که Code Review می‌کنه چرا باید Production Delete Permission داشته باشه؟

نداره.

Agent Deployment چرا باید Billing تغییر بده؟

نداره.

Secretها هم تا جای ممکن نباید مستقیم توی Context مدل بچرخن.

---

۲۳ — MCP عالیه، ولی هر چیزی MCP نمی‌خواد

یه مدت همه‌چی داشت MCP می‌شد.

Calculator MCP.

Git MCP.

Weather MCP.

احتمالاً یه نفر Toaster MCP هم ساخته :))

MCP وقتی خیلی خوبه که:

یه Service ساختاریافته داری.

چند Agent باید ازش استفاده کنن.

Tool discovery مهمه.

Authorization مهمه.

ولی گاهی Agent از قبل اینو بلده:

git
gh
docker
kubectl
rg

و یه Skill که بهش Workflow درست رو بگه کافیه.

من همیشه می‌پرسم:

آیا MCP واقعاً ارزش Integration Tax رو داره؟

یا:

CLI + Skill

تمیزتره؟

---

۲۴ — Token یه Resourceـه

یه Workflow ممکنه خیلی خفن به نظر بیاد ولی برای هر Task:

۱.۵ میلیون Token بخوره.

خب اگر خروجی ۲ درصد بهتره...

ارزشش داره؟

شاید.

شاید هم نه.

من Token Efficiency رو بخشی از Quality می‌بینم.

یه Agent خوب فقط Task رو حل نمی‌کنه.

با هزینه‌ی منطقی حلش می‌کنه.

چیزهایی که معمولاً Token رو الکی می‌سوزونن:

• Subagent زیاد
• MCPهای پرسر‌و‌صدا
• Skillهای حجیم
• Search بدون جهت
• Context عظیم
• Sessionهای خیلی طولانی
• Read کردن فایل‌هایی که لازم نیست
• Review تکراری بدون معیار

اینجاست که Codebase Memory و Context Engineering دوباره مهم می‌شن.

---

۲۵ — Benchmark شخصی بسازید

این شاید یکی از مهم‌ترین پیشنهادهای کل مقاله باشه.

به حرف من اعتماد نکنید.

به Twitter اعتماد نکنید.

به Benchmark خود Tool هم کورکورانه اعتماد نکنید.

Workflow خودتون رو Benchmark کنید.

مثلاً پنج Task واقعی نگه دارید:

1. Fix a backend bug
2. Implement a small feature
3. Refactor an old module
4. Review a PR
5. Add tests to legacy code

بعد هر تغییر Setup رو روی این‌ها بسنجید.

مثلاً:

Correctness
Time
Tokens
Human interventions
Number of retries
Test pass rate
Diff quality
Architecture quality

حالا اگر Plugin جدید:

Token رو دو برابر کرد.

زمان رو ۵۰ درصد زیاد کرد.

ولی کیفیت فرقی نکرد.

Delete.

این خیلی بهتر از:

حس می‌کنم با این Plugin مدل باهوش‌تر شده.

ـه.

---

۲۶ — Model Routing

همه‌ی Taskها به یه Model نمی‌رن.

این یکی از جاهاییه که خیلی هزینه رو کم می‌کنه.

مثلاً:

Simple mechanical task
→ cheap fast model

Normal implementation
→ main coding model

Architecture / hard debugging
→ strongest model

Review
→ independent model

Research
→ model with good tool/search behavior

لزومی نداره یه Model تمام شرکت شما باشه.

---

۲۷ — Documentation حالا Return on Investment بیشتری داره

قبلاً Documentation می‌نوشتیم برای:

انسان‌های آینده.

حالا یه Reader جدید هم داریم:

Agent.

Documentation خوب باعث می‌شه Agent کمتر حدس بزنه.

مثلاً:

docs/
├── architecture/
├── decisions/
├── product/
├── deployment/
├── runbooks/
└── domain/

یه Domain Rule که فقط توی ذهن Developer Senior بوده، برای Agent وجود خارجی نداره.

بنویسش.

یه Deployment Gotcha که همه شفاهی می‌دونن؟

بنویسش.

AI عصر Documentation رو نکشته.

به نظرم برعکس، دوباره ارزش Documentation رو زیاد کرده.

---

۲۸ — Legacy Project با Greenfield فرق داره

Greenfield رو Agent عاشقه.

هیچی نیست.

هرچی دوست داره می‌سازه :))

Legacy Project یه چیز دیگه‌ست.

اونجا مهمه اول:

index
↓
map architecture
↓
find invariants
↓
read docs
↓
run baseline tests
↓
make small changes

برای همین ابزارهایی مثل Codebase Memory روی Brownfield به نظرم خیلی بیشتر ارزش دارن.

چون قبل از Edit یه نقشه می‌دن.

---

۲۹ — بهترین Agent اون نیست که بیشتر Code می‌نویسه

این یه Metric خیلی بدیه:

امروز Agent من ۴۰ هزار خط Code نوشت.

خب چرا؟ :))

من Agentی رو ترجیح می‌دم که بگه:

این Feature با تغییر ۸۷ خط قابل انجامه؛ نیازی به معماری جدید نیست.

Agent خوب بعضی وقت‌ها باید کمتر بنویسه.

YAGNI هنوز نمرده.

---

۳۰ — چه وقت خودم وارد Code می‌شم؟

من کاملاً از Coding دستی فرار نکردم.

بعضی وقت‌ها سریع‌تره خودم یه Fix رو بزنم.

بعضی وقت‌ها می‌خوام دقیقاً یه Algorithm رو بفهمم.

بعضی وقت‌ها Agent چند بار مسئله رو اشتباه فهمیده.

بعضی وقت‌ها هم فقط Code زدن حال می‌ده :))

هدف من:

حذف خودم از برنامه‌نویسی نیست.

هدف:

حذف کارهای کم‌ارزش از وقتمه.

---

۳۱ — Setup فعلی من

حالا بعد از اینکه سی بار گفتم Setup من رو کپی نکنید...

Setup من :))

در زمان نوشتن این مقاله چیزی نزدیک به اینه:

                 ME
                  │
         Define problem / taste
                  │
                  ▼
              SPEC / PLAN
                  │
        ┌─────────┴─────────┐
        │                   │
   project docs       codebase memory
        │                   │
        └─────────┬─────────┘
                  ▼
               AGENT
                  │
       ┌──────────┼──────────┐
       │          │          │
   OpenCode     Codex     other tools
       │          │
   DeepSeek    T3 Code
       │
       └──────────┬──────────
                  │
                Skills
                  │
        custom + Matt + selected
             Superpowers
                  │
              Tool layer
                  │
        CLI / MCP / LSP / Shell
                  │
            Implementation
                  │
                Tests
                  │
        Independent reviewer
                  │
                 PR
                  │
                 CI
                  │
                Human

برای پروژه‌های بزرگ‌تر:

Spec Kit هم وارد جریان می‌شه.

برای Codebaseهای پیچیده:

Codebase Memory.

برای رفتارهای تکراری:

Skill.

برای Context دائمی:

AGENTS.md و Docs.

برای Quality:

Reviewer مستقل.

برای Production:

Git + Test + CI + Permission.

این برای من جواب می‌ده.

برای من.

---

۳۲ — اگر از صفر بودم چه کار می‌کردم؟

اگر امروز تازه می‌خواستم Workflow Agentic خودم رو بسازم، اصلاً با ۴۰ تا Tool شروع نمی‌کردم.

شروع:

1 Harness
1 good model
1 AGENTS.md
Git
Tests

همین.

بعد کار می‌کردم.

هرجا درد داشتم یه Tool اضافه می‌کردم.

Agent Codebase رو نمی‌فهمه؟

Codebase Memory.

Requirementها گم می‌شن؟

Spec Workflow.

یه Prompt رو هی تکرار می‌کنم؟

Custom Skill.

Review ضعیفه؟

Independent Reviewer.

Toolهای خارجی لازم دارم؟

MCP یا CLI.

Taskها بزرگ شدن؟

Subagents.

نه اینکه روز اول همه‌ی دنیا رو Install کنم و بعد نفهمم مشکل از کدوم لایه‌ست.

---

۳۳ — Workflow شما باید از Pain ساخته بشه، نه FOMO

به نظرم این بهترین روش انتخاب Toolـه.

نبین:

فلانی اینو داره.

ببین:

من چه مشکلی دارم؟

مثلاً:

Pain:
Agent repeatedly misunderstands architecture.

Solution:
Better AGENTS.md / docs / codebase map.

یا:

Pain:
Large features drift from requirements.

Solution:
Spec-driven workflow.

یا:

Pain:
Agent spends huge tokens exploring repository.

Solution:
Codebase Memory / better search.

یا:

Pain:
Same review instructions repeated every day.

Solution:
Custom skill.

Tool باید جواب Pain باشه.

نه جواب یه Tweet.

---

۳۴ — و دوباره برگردیم به تخصص

آخر همه‌ی اینا دوباره می‌رسیم به همون حرف اول.

فرض کنید فردا Agentها ۱۰ برابر بهتر بشن.

همه‌ی Harnessها رایگان بشن.

Context Window بشه ده میلیون Token.

Agent بتونه ۲۴ ساعت مستقل کار کنه.

کی بهش می‌گه چی بسازه؟

کی Architecture رو قضاوت می‌کنه؟

کی می‌فهمه Requirement اشتباهه؟

کی می‌فهمه Security Risk وجود داره؟

کی می‌فهمه Feature اصلاً ارزش ساختن نداره؟

کی می‌فهمه Code قشنگه ولی Design افتضاحه؟

شما.

AI داره هزینه‌ی Translation بین:

idea
→
software

رو پایین میاره.

ولی اینکه Idea خوب باشه، Requirement درست باشه و Result ارزشمند باشه هنوز مسئله‌ی آدمه.

برای همین اون حرف «خودت متخصص شو» به نظرم از تمام Toolهای این مقاله مهم‌تره.

اگر Backend کار می‌کنی:

Backend رو واقعاً یاد بگیر.

Database رو بفهم.

Network رو بفهم.

Concurrency رو بفهم.

Security رو بفهم.

اگر Frontend کاری:

Browser رو بفهم.

Accessibility رو بفهم.

Design رو بفهم.

Performance رو بفهم.

نه برای اینکه همه‌ی Code رو خودت تایپ کنی.

برای اینکه وقتی یه Agent در پنج دقیقه چیزی ساخت، بدونی چی ساخته.

---

آخرش

۳۰۰۰+ ساعت بعد، من کمتر از قبل دنبال:

«بهترین AI Coding Setup دنیا»

می‌گردم.

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

الان بیشتر دنبال اینم:

بهترین Workflow برای این Task، روی این پروژه، با این محدودیت‌ها چیه؟

گاهی جواب:

Codex + Reviewer.

گاهی:

OpenCode + DeepSeek.

گاهی:

Spec Kit + چند Agent.

گاهی:

Codebase Memory + یه Model ارزون.

گاهی:

یه Skill.

گاهی:

rg.

و گاهی هم جواب خیلی ساده‌تره:

خودم اون ۲۰ خط Code رو می‌نویسم و می‌رم سراغ زندگیم :))

Toolها رو تست کنید.

Setup آدم‌ها رو ببینید.

ازشون ایده بدزدید.

Skillهاشون رو بخونید.

Workflowهاشون رو خراب کنید و دوباره بسازید.

ولی هیچ‌وقت فکر نکنید چون Config یه نفر رو کپی کردید، چیزی که باعث شده اون Config برای اون آدم خوب کار کنه هم کپی شده.

اون بخش توی JSON نیست.

تخصصشه.

Tasteـشه.

تجربه‌شه.

درکش از مسئله‌ست.

و به نظرم توی دوره‌ای که تقریباً همه می‌تونن با چند Prompt حجم خیلی زیادی Software تولید کنن، دقیقاً همین چیزها قراره ارزشمندتر بشن.

مدل عوض می‌شه.

Harness عوض می‌شه.

Skill عوض می‌شه.

Setup من هم احتمالاً چند ماه دیگه با چیزی که الان نوشتم فرق داره.

ولی اون قسمت اصلی قرار نیست تغییر کنه:

ابزار رو برای Workflow خودتون بسازید، نه خودتون رو برای ابزار.

و مهم‌تر از همه:

روی خودتون سرمایه‌گذاری کنید.

چون آخر داستان، اهرم هرچقدر هم بزرگ بشه...

کسی هنوز باید بلد باشه کجا بذارتش.

تا بلاگ بعدی، بدرود!