مهندسی با چند ایجنت

در جلسه‌ی قبل دیدیم یک ایجنت چطور کار می‌کند. این جلسه درباره‌ی مقیاس است: چطور یک نفر با چند ایجنت هم‌زمان کاری را انجام دهد که قبلاً یک تیم انجام می‌داد. اول دو plugin واقعی را باز می‌کنیم تا ببینیم سازوکارهای جلسه‌ی قبل در عمل چطور کنار هم می‌نشینند.

مطالعه‌ی موردی ۱: Superpowers#

Superpowers یک plugin برای توسعه‌ی نرم‌افزار است. ایده‌ی اصلی‌اش جالب است: همان مدل و همان ابزارها، اما روند کار متفاوت، که فقط با دستورالعمل ساخته شده است. ایجنت پیش‌فرض معمولاً این‌طور کار می‌کند:

درخواست قابلیت ─◄ شروع کدنویسی ─◄ اصلاح با آزمون و خطا

و Superpowers همان کار را این‌طور پیش می‌برد:

شفاف کردن مسئله ─◄ تأیید طراحی ─◄ برنامه‌ی دقیق ─◄ ساخت با TDD ─◄ بازبینی و تأیید ─◄ ادغام شاخه

سه قدم اول «برنامه‌ریزی» است، ساخت با TDD «ساخت» است و دو قدم آخر «تحویل».

این روند از ۹ skill کوچک ساخته شده است:

ساختار مخزن plugin:

superpowers/
├── .claude-plugin/plugin.json      # plugin metadata
├── hooks/
│   ├── hooks.json
│   └── session-start               # session hook
├── skills/                         # skill library
│   ├── using-superpowers/
│   ├── brainstorming/
│   ├── writing-plans/
│   └── test-driven-development/
└── tests/                          # agent behavior tests

plugin فقط ظرف توزیع است؛ رفتار را skillها و hookها می‌سازند.

کالبدشکافی یک SKILL.md#

نسخه‌ی ساده‌شده‌ی skill «brainstorming» (کنار SKILL.md یک فایل مرجع visual-companion.md و پوشه‌ی scripts هم هست):

---
name: brainstorming
description: Use before creative work.
---
## Workflow
1. Inspect the project
2. Classify the scope
3. Clarify requirements
4. Compare approaches
5. Present a design
6. Wait for user approval
7. Invoke writing-plans

فایل یک skill شش جزء دارد:

و یک skill فرایندی معمولاً این‌ها را تعریف می‌کند:

• شرط ورود: کی این skill اجرا شود
• عمل‌های لازم و ممنوع
• دروازه‌های تأیید انسانی: کجا باید منتظر کاربر ماند
• الزام تأیید: چه مدرکی لازم است
• skill بعدی: بعد از این، کدام skill اجرا شود

چرا skill به‌تنهایی کافی نیست#

نصب یک skill باعث نمی‌شود ایجنت از آن استفاده کند. راه‌حل Superpowers یک hook از نوع SessionStart است: در شروع هر نشست، پیش از اینکه ایجنت کاری بکند، و دوباره بعد از clear و compaction، یک «skill راه‌انداز» را مستقیم به کانتکست تزریق می‌کند. این skill به ایجنت می‌گوید skillهای دیگر را کی و چطور پیدا و اجرا کند.

تعریف hook در hooks/hooks.json:

{
  "hooks": {
    "SessionStart": [{
      "matcher": "startup|clear|compact",
      "hooks": [{ "type": "command", "command": "run-hook.cmd", "async": false }]
    }]
  }
}

matcher تضمین می‌کند hook در شروع نشست، بعد از /clear و بعد از compaction اجرا شود، و async: false یعنی پیش از اینکه ایجنت کاری بکند تمام می‌شود.

اسکریپت این hook کار ساده‌ای می‌کند. نسخه‌ی ساده‌شده:

#!/usr/bin/env bash
set -euo pipefail
ROOT="$(plugin_root)"                                  # 1. locate the installed plugin
skill="$ROOT/skills/using-superpowers/SKILL.md"       # 2. read the bootstrap skill
content="$(cat "$skill")"
printf '{"hookSpecificOutput": {
  "hookEventName": "SessionStart",
  "additionalContext": "%s" }}' \
  "$(escape_json "$content")"                          # 3-4. escape and return it

Claude Code مقدار additionalContext را به کانتکست اضافه می‌کند.

یک مثال کامل، «احراز هویت اضافه کن»:

skill راه‌انداز بار می‌شود ─◄ brainstorming سؤال می‌پرسد و طراحی را تأیید می‌گیرد ─◄ writing-plans برنامه می‌نویسد ─◄ worktree ایزوله ─◄ ساخت با TDD ─◄ بازبینی ─◄ تأیید ─◄ ادغام شاخه

درس‌های طراحی این plugin:

• skillهای کوچک و ترکیب‌پذیر
• یک skill راه‌انداز که hook تزریقش می‌کند
• بار کردن بقیه‌ی skillها فقط هنگام نیاز، برای صرفه‌جویی در کانتکست
• هر skill دروازه‌های تأیید و skill بعدی را صریح نام می‌برد
• همه‌چیز در قالب یک plugin بسته‌بندی شده است

مطالعه‌ی موردی ۲: Caveman#

Caveman از هر پنج سازوکار توسعه استفاده می‌کند و یک پروکسی محلی هم اضافه دارد. مسئله‌ای که حل می‌کند: کانتکست با لاگ و خروجی ابزار پر می‌شود، هر نوبت توکن و زمان می‌خورد (هم پولش را می‌دهید و هم منتظرش می‌مانید)، و compaction دیرهنگام جزئیات مهم را از بین می‌برد. مثال اسلاید:

BEFORE — 786 lines of test output
$ npm test
FAIL src/api/client.test.ts
  ● client › retries on 5xx
    connect ETIMEDOUT 10.0.3.8:443
      at client.ts:88
  … 776 more lines …
3 failed, 214 passed

AFTER — what the model reads
3 tests fail: ETIMEDOUT at client.ts:88

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

• خروجی مدل: یک skill پاسخ، مدل را به نوشتن کوتاه وادار می‌کند. واژه‌های فنی، کد، مسیرها، خطاها، اعداد و نفی‌ها حفظ می‌شوند. تعارف، تردید و پرگویی حذف می‌شود. طبق گزارش سازنده، خروجی حدود ۶۵٪ کوتاه‌تر می‌شود، ولی خود skill توکن ورودی اضافه می‌کند، پس صرفه‌جویی کل نشست کمتر است.
• ورودی مدل: یک پروکسی محلی لاگ، نتیجه‌ی ابزار، diff و فایل‌ها را پیش از رسیدن به مدل فشرده می‌کند.

فشرده‌سازی ورودی به نوع محتوا حساس است؛ هر نوع، بخش مهم خودش را نگه می‌دارد:

Caveman در عمل#

کاربر می‌نویسد /caveman ultra و بعد «تست‌ها را اجرا کن و شکست را توضیح بده». اتفاقی که می‌افتد:

hook حالت را ذخیره می‌کند ─◄ یادآور «کوتاه جواب بده» تزریق می‌شود ─◄ ایجنت دستور را اجرا می‌کند ─◄ پروکسی خروجی را فشرده می‌کند ─◄ مدل تشخیص کوتاهی می‌دهد ─◄ در صورت نیاز MCP نسخه‌ی اصلی را برمی‌گرداند

اجزای بسته:

نمونه‌ی فایل دستور (commands/caveman.md) که سطح را از آرگومان می‌گیرد:

---
description: Activate Caveman mode
argument-hint: [lite|full|ultra|off]
---
Activate Caveman mode: $ARGUMENTS
If no level is supplied, use full. If off, deactivate.

و پیکربندی سرور MCP و یک نتیجه‌ی نمونه:

{"mcpServers": {"caveman": {"command": "npx", "args": ["-y", "caveman-mcp"]}}}

{"compressed": "3 tests fail. Root error: timeout.", "ratio": 0.72, "recovery_handle": "ccr_abc123"}

TOON یک قالب فشرده‌ی متنی برای داده‌ی ساخت‌یافته است که به جای JSON توکن کمتری مصرف می‌کند. در یک نمونه‌ی اسلاید، نسبت فشرده‌سازی ۰٫۷۲ بود.

پروکسی یا MCP؟#

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

• hookها نمی‌توانند درخواستی را که به مدل می‌رود بی‌صدا بازنویسی کنند. (اگر هارنس خودتان را بنویسید، البته می‌توانید.)
• ابزار MCP فقط وقتی اجرا می‌شود که مدل صدایش بزند و نمی‌تواند کانتکست را تغییر دهد.
• فقط پروکسی بین ایجنت و ارائه‌دهنده می‌نشیند و هر درخواست را می‌بیند.

پس Caveman از هر سازوکار برای کاری که فقط از عهده‌ی آن برمی‌آید استفاده می‌کند. skill سبک پاسخ را شکل می‌دهد، command حالت را انتخاب می‌کند، hook حالت را بعد از compaction حفظ می‌کند، پروکسی ورودی را فشرده می‌کند و MCP نسخه‌ی اصلی را هر وقت لازم شد دقیق برمی‌گرداند.

سه محور مقیاس‌پذیری#

تیم ایجنت و workflow پویا این سه محور را با هم ترکیب می‌کنند. و یک هشدار از اسلاید: ایجنت‌ها موازی پخش می‌شوند؛ صورت‌حساب هم همین‌طور.

ایجنت‌های موازی با دست#

ساده‌ترین روش: برای هر نشست یک git worktree. یک مخزن، چند checkout جدا، بدون stash و بدون تداخل فایل:

claude -w feature-payments     # نشست ۱ در worktree جدا
claude -w fix-login-timeout    # نشست ۲ در worktree دیگر

worktree یعنی یک پوشه‌ی کاری و شاخه‌ی جدا که تاریخچه‌ی مخزن را به اشتراک می‌گذارد:

.git (one history)  ─┬─ ../repo-main   branch: main              Agent 1: review
                     ├─ ../feat-auth   branch: feature/auth      Agent 2: build
                     └─ ../fix-flaky   branch: fix/flaky-test    Agent 3: debug

نسخه‌ی دسکتاپ Claude Code برای هر نشست جدید خودکار یک worktree می‌سازد.

این روش تا حدود ۳ نشست خوب کار می‌کند، چون برنامه را می‌توانید در ذهن نگه دارید. در ۲۰ نشست به یک کپی از خودتان نیاز دارید. نشست‌ها همدیگر را نمی‌بینند، ادغام شاخه‌ها با خود شماست و هیچ چیزی از روند اجرا ثبت نمی‌شود که بشود تکرارش کرد.

زیرایجنت‌ها#

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

فایده‌هایش:

• حفظ کانتکست: لاگ‌ها و جستجوهای طولانی وارد گفتگوی اصلی نمی‌شوند
• اعمال محدودیت: ابزارها یا مدل محدود
• استفاده‌ی دوباره: یک پرامپت متمرکز برای چند پروژه
• موازی‌سازی
• کنترل هزینه: کارهای ساده روی مدل ارزان‌تر، مثلاً با model: haiku در front matter زیرایجنت

مثلاً سه زیرایجنت style-checker، security-scanner و test-coverage می‌توانند هم‌زمان اجرا شوند و کندترینشان زمان کل را تعیین می‌کند.

Claude Code چند زیرایجنت داخلی دارد: Explore برای جستجوی فقط‌خواندنی کد، Plan برای تحقیق در حالت برنامه‌ریزی، و general-purpose برای کارهای چندمرحله‌ای که هم جستجو و هم تغییر لازم دارند. Explore و Plan برای سرعت، CLAUDE.md و وضعیت git را بار نمی‌کنند.

تعریف زیرایجنت#

یک فایل Markdown در .claude/agents/ (پروژه) یا ~/.claude/agents/ (شخصی):

---
name: test-runner
description: تست‌ها را اجرا و شکست‌ها را خلاصه می‌کند. بعد از هر تغییر کد استفاده شود.
tools: Bash, Read, Grep
model: haiku
---

تست‌های پروژه را اجرا کن. اگر همه پاس شدند فقط بگو «همه پاس شدند» و تعدادشان.
اگر شکستی بود، برای هر شکست فقط این‌ها را برگردان: نام تست، پیام خطا، فایل و خط،
و حدس تو درباره‌ی علت در یک جمله. لاگ کامل را برنگردان.

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

زیرایجنت تودرتو#

زیرایجنت می‌تواند خودش زیرایجنت بسازد، به شرطی که ابزار Agent در فهرست ابزارهایش باشد:

---
name: my-orchestrator
tools: Read, Grep, Agent
model: claude-sonnet-5-0
---

اسلاید می‌گوید تا ۵ سطح تودرتو مجاز است و ۲ تا ۳ سطح نقطه‌ی بهینه است. مستندات فعلی Claude Code پیش‌فرض را سه لایه زیر گفتگوی اصلی و حداکثر ۲۰ زیرایجنت هم‌زمان می‌گوید؛ هر دو عدد قابل تنظیم‌اند. یک الگوی رایج:

ایجنت اصلی (صاحب برنامه)
┤── پیاده‌ساز ─◄ نویسنده‌ی تست
┤── اشکال‌زدا
┘── بازبین کد ─◄ تأییدکننده

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

کی زیرایجنت، کی گفتگوی اصلی؟#

دلیل این تقسیم: زیرایجنت تازه شروع می‌کند، هیچ تاریخچه‌ای نمی‌بیند و برای جمع کردن کانتکست هزینه‌ی تأخیر می‌پردازد.

اگر یک روند تکرارشونده می‌خواهید که در کانتکست اصلی بماند، skill مناسب‌تر است.

تیم ایجنت‌ها#

تیم ایجنت‌ها چند نشست کامل Claude Code است: یک رهبر و چند هم‌تیمی. تفاوت اصلی با زیرایجنت این است که هم‌تیمی‌ها مستقیم با هم حرف می‌زنند و یک فهرست کار مشترک دارند که هر کس کاری از آن برمی‌دارد.

این قابلیت آزمایشی است و به‌طور پیش‌فرض خاموش است. با متغیر محیطی CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 روشن می‌شود. کاربردهای خوبش: بازبینی از چند زاویه (امنیت، کارایی، پوشش تست)، ماژول‌های مستقل، و اشکال‌زدایی با فرضیه‌های رقیب که در آن هم‌تیمی‌ها سعی می‌کنند نظریه‌ی هم را رد کنند. برای کار ترتیبی، ویرایش یک فایل مشترک یا کار پر از وابستگی مناسب نیست. مستندات پیشنهاد می‌کند با ۳ تا ۵ هم‌تیمی شروع کنید. هم‌تیمی‌ها گفتگوی شما را به ارث نمی‌برند؛ CLAUDE.md و skillها را خودکار بار می‌کنند، پس جزئیات کار را در پرامپت ساختن هم‌تیمی بنویسید.

workflowهای پویا#

وقتی کار به ده‌ها یا صدها ایجنت نیاز دارد، دیگر نمی‌شود هماهنگی را به یک گفتگو سپرد. در workflow پویا، Claude یک اسکریپت JavaScript می‌نویسد که خودش زیرایجنت‌ها را هماهنگ می‌کند. حلقه، شاخه‌ها و نتایج میانی در متغیرهای اسکریپت می‌مانند و فقط جواب نهایی به کانتکست برمی‌گردد. مثال‌ها: بازرسی همه‌ی routeهای یک مخزن، مهاجرت ۵۰۰ فایل، یا تحقیقی که منابعش باید با هم تطبیق داده شوند.

با کلمه‌ی کلیدی ultracode در پرامپت (یا /effort ultracode برای کل نشست) این حالت فعال می‌شود. فرق اصلی این است که چه کسی برنامه را نگه می‌دارد: در زیرایجنت و تیم، مدل نوبت‌به‌نوبت تصمیم می‌گیرد؛ در workflow، اسکریپت. پس روند قابل خواندن، ذخیره و تکرار است.

ایجنت‌های طولانی#

برای ادامه دادن یک ایجنت تا رسیدن به نتیجه، اسلایدهای درس دو الگو را معرفی می‌کنند:

• /goal: یک وضعیت پایانی قابل بررسی تعیین می‌کنید. بعد از هر تلاش یک ارزیاب بررسی می‌کند و اگر هدف برقرار نبود، ایجنت را دوباره به کار می‌فرستد. وقتی هدف برقرار شد، یا وقتی --max-tries تمام شد، متوقف می‌شود. «همه‌ی تست‌های integration پاس شوند» کار می‌کند؛ «کد را refactor کن» نه.
• /loop: یک پرامپت را در فاصله‌های زمانی تکرار می‌کند، تا وقتی Esc بزنید. این یک ماشه است، نه یک تست. پرامپت پیش‌فرض را می‌شود در .claude/loop.md گذاشت.

/goal "npm run lint exits with zero errors"
/loop 5m "check CI, fix whatever broke"

/goal وقتی شرط برقرار شد متوقف می‌شود؛ /loop وقتی شما بخواهید.

نمونه‌ی واقعی: ۱۶ ایجنت یک کامپایلر C ساختند#

در یک آزمایش Anthropic، ۱۶ ایجنت موازی در دو هفته و حدود ۲۰۰۰ نشست، یک کامپایلر C به زبان Rust ساختند:

• حدود ۱۰۰ هزار خط کد، با هزینه‌ی API کمی کمتر از ۲۰ هزار دلار
• کامپایل هسته‌ی لینوکس 6.9 برای x86، ARM و RISC-V
• اجرای QEMU، FFmpeg، Postgres، Redis و Doom
• نرخ قبولی حدود ۹۹٪ در مجموعه‌تست‌های اصلی

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

مخزن را بخوان ─◄ کاری را با lock file بردار ─◄ در container پیاده و تست کن ─◄ merge، push، آزاد کردن lock

هیچ چت و هیچ ایجنت مدیری در کار نبود؛ هماهنگی فقط از راه وضعیت مشترک git انجام می‌شد:

• خواندن مخزن: clone، خواندن مستندات و لاگ‌ها
• برداشتن کار: یک lock file در پوشه‌ی current_tasks/
• پیاده‌سازی و تست در container خود ایجنت
• ادغام: اول pull کارهای بقیه، بعد merge و push، و آزاد کردن lock

حلقه تکرار می‌شد و هر ایجنت خودش «کار واضح بعدی» را برمی‌داشت. اگر یک کار دو بار برداشته می‌شد، git تکلیف را روشن می‌کرد و یکی از ایجنت‌ها سراغ کار دیگری می‌رفت. کانتکست را هم محصولات حمل می‌کردند: READMEها، فایل‌های پیشرفت و شکست‌های CI نشست‌های تازه را در جریان قرار می‌دادند. ایجنت‌های تخصصی مستندات، کارایی، کیفیت و حذف تکرار را بر عهده داشتند و سیگنال پیشرفت تست‌های خودکار بود.

محدودیت‌ها هم آموزنده‌اند: merge conflict زیاد بود. وقتی همه‌ی ایجنت‌ها به یک خطای مشترک در کامپایل هسته رسیدند، موازی‌سازی دیگر کمکی نکرد. بخشی از x86 شانزده‌بیتی هنوز به GCC وابسته بود و کد تولیدی از GCC کم‌بازده‌تر بود.

برنامه‌نویسی ۳.۰ و عدم قطعیت#

اسلایدهای درس این تحول را این‌طور صورت‌بندی می‌کنند:

(Karpathy تعریف دیگری دارد: ۲.۰ وزن‌های شبکه‌ی عصبی است و ۳.۰ پرامپت به LLM.)

بهره‌وری بالاتر می‌رود، اما عدم قطعیت هم بیشتر می‌شود. دانستن اینکه مرز بین این پارادایم‌ها را کجا بکشیم، یک مهارت کلیدی مهندسی است.

به گفته‌ی اسلاید، عدم قطعیت موضوع اصلی برنامه‌نویسی ۳.۰ است و باید یاد بگیریم با آن زندگی کنیم. اما عدم قطعیت تازه نیست؛ «کد یکسان، خروجی متفاوت» خیلی پیش‌تر هم بود:

و منابعی که مخصوص ۳.۰ هستند:

یک لایه‌ی دیگر هم هست: شکاف نیت تا نتیجه. در ۱.۰ و ۲.۰ زنجیره این بود: انسان (مدیر محصول) ← برنامه‌نویس ← برنامه ← نتیجه. فاصله‌ی بین نیت مدیر محصول و برنامه وجود داشت ولی نادیده گرفته می‌شد، و برای فاصله‌ی برنامه تا نتیجه تأیید رسمی (formal verification) هست. در ۳.۰ زنجیره انسان ← ایجنت LLM ← برنامه ← نتیجه است، و چون ورودی یک پرامپت تنها است، ابهام بیشتر است. اسلاید می‌گوید این بخش هنوز به پژوهش نیاز دارد. نکته‌ی مهم این است که کد تولیدشده معمولاً خودش قطعی است، مگر اینکه در زمان اجرا مدل یا ابزار صدا بزند؛ عدم قطعیت در فرایند تولید است.

بهترین روش‌ها:

از ایجنت قطعیت انتظار نداشته باشید. سیستم اطرافش را قابل اتکا کنید و میزان خودمختاری را با میزان ریسک تنظیم کنید.

شواهد از میدان: Codex در OpenAI#

گزارش‌های OpenAI در ۲۰۲۶ تصویری از این تحول می‌دهند، به نقل از اسلایدهای درس. اول تفاوت دو حالت: در AI گفتگویی، انسان کار را اجرا می‌کند. در AI ایجنتی، انسان واگذار می‌کند؛ ایجنت برنامه می‌ریزد، ابزار صدا می‌زند، فایل ویرایش می‌کند و دستور اجرا می‌کند، و انسان بازبینی و یکپارچه‌سازی می‌کند.

پذیرش (ژوئن ۲۰۲۶)

• کاربران فعال در نیمه‌ی اول ۲۰۲۶ بیش از ۵ برابر شدند.
• سهم کسانی که در ۲۸ روز اخیر از Codex استفاده کرده بودند: کمتر از ۱٪ کاربران فردی، ۱۷٫۳٪ کاربران سازمانی و تقریباً همه‌ی کارکنان OpenAI.

اندازه‌ی کارها

تعداد کاربرانی که کارهای یک‌روزه را به Codex می‌سپارند ۱۲ برابر شد.

یک انسان، چند ایجنت (ژوئن ۲۰۲۶)

• ۲۸٫۶٪ کاربران داخلی OpenAI در یک هفته ۵ ایجنت یا بیشتر را هم‌زمان اجرا کردند.
• میانه‌ی کارکنان روزانه حدود ۲٫۵ «ساعت-ایجنت» داشت. صدک ۹۹ حدود ۷۱ ساعت-ایجنت در روز، ۸۸٪ بیشتر از آوریل.

کار ایجنت در برابر انسان (سپتامبر ۲۰۲۶)

• تا پیش از ژوئن ۲۰۲۶ زمان اجرای ایجنت‌ها از کار انسانی کمتر بود. حالا ایجنت‌ها حدود ۳٫۱۴ برابر پژوهشگران انسانی کار انجام می‌دهند.
• بیشتر پژوهشگران چهار روند کاری یا بیشتر را هم‌زمان اجرا می‌کنند.
• مهندسان تقریباً ۸ برابر سریع‌تر کد منتشر می‌کنند.
• ایجنت‌ها کارهای پیچیده‌تری حل می‌کنند، اما دخالت انسان هنوز لازم است.

نقش انسان به برنامه‌ریز، واگذارکننده، ناظر، بازبین و یکپارچه‌ساز تغییر کرده است.

یک نردبان واگذاری:

1. چت‌بات: AI جواب می‌دهد، انسان کار می‌کند
2. دستیار: انسان و AI با هم کار می‌کنند
3. ایجنت: انسان یک واحد کار را واگذار می‌کند
4. کارگر چندایجنتی: انسان چند ایجنت را هماهنگ می‌کند
5. روندهای سیستماتیک: skillها و ایجنت‌ها فرایندها را اجرا می‌کنند

به گفته‌ی اسلایدها، نیروی کار OpenAI هنوز نزدیک پله‌های پایین این نردبان است.

وضعیت ایجنت‌های کدنویس خط فرمان (میانه‌ی ۲۰۲۶)#

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

و پنج محور برای مقایسه‌شان:

جمع‌بندی#

پرسش‌هایی برای فکر کردن#

• آخرین کار بزرگتان را در نظر بگیرید. کدام بخش‌هایش واقعاً مستقل بودند و می‌شد موازی‌شان کرد؟
• در آزمایش کامپایلر، چرا وقتی همه‌ی ایجنت‌ها به یک خطا رسیدند، موازی‌سازی کمکی نکرد؟ این درباره‌ی «تجزیه‌ی کار» چه می‌گوید؟ (جلسه‌ی ۵)

منابع#

• اسلاید جلسه: Agents use II: 100x Engineer with Multi-agents (3_agent_use_2.pdf)
• Claude Code agent teams
• Claude Code subagents
• Claude Code dynamic workflows
• Andrej Karpathy، Software is changing (again)
• OpenAI، Research acceleration: The view inside OpenAI