AI Coding Agent چیست؟

AI Coding Agent سیستمی است که از یک مدل زبانی بزرگ یا LLM به‌عنوان موتور اصلی استفاده می‌کند و در کنار آن مجموعه‌ای از ابزارها را در اختیار مدل قرار می‌دهد.

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

• خواندن و نوشتن فایل
• جست‌وجو در پروژه
• اجرای Terminal
• اجرای تست
• اجرای Build
• کار با Git
• جست‌وجوی اینترنت
• دسترسی به API
• بررسی Documentation
• کار با Database
• تحلیل تصویر و Screenshot

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

Hugging Face نیز Agent را سیستمی تعریف می‌کند که یک LLM را به‌عنوان موتور در اختیار دارد و می‌تواند از Functionها یا Toolهایی برای انجام وظایف استفاده کند. در معماری‌های Agent، مدل می‌تواند اقدامات را برنامه‌ریزی کرده و ابزارها را به‌صورت مرحله‌ای اجرا کند.

تفاوت LLM با Coding Agent چیست؟

فرض کنید از یک LLM معمولی بپرسید:

مشکل این کد چیست؟

شما کد را در Prompt قرار می‌دهید و مدل پاسخ می‌دهد.

مثلاً ممکن است بگوید:

در خط ۴ احتمالاً مقدار null دریافت می‌شود.

اما مدل لزوماً نمی‌تواند خودش فایل را باز کند، کد را تغییر دهد و تست را اجرا کند.

حالا همان مسئله را به یک Coding Agent بدهید.

Agent می‌تواند:

1. فایل مربوطه را پیدا کند.
2. کد را بخواند.
3. فایل‌های مرتبط را بررسی کند.
4. علت احتمالی خطا را پیدا کند.
5. کد را اصلاح کند.
6. تست را اجرا کند.
7. نتیجه تست را بررسی کند.
8. در صورت شکست، اصلاح دیگری انجام دهد.
9. در پایان تغییرات را گزارش کند.

بنابراین تفاوت اصلی فقط در «هوش مدل» نیست.

تفاوت اصلی در سیستم اطراف مدل است.

Chatbot، Copilot و Coding Agent چه تفاوتی دارند؟

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

Chatbot

Chatbot معمولاً یک رابط مکالمه‌ای برای تعامل با مدل است.

شما سؤال می‌پرسید و مدل پاسخ می‌دهد.

مثلاً:

این Function چه کاری انجام می‌دهد؟

یا:

برای این مسئله یک الگوریتم پیشنهاد بده.

تمرکز اصلی Chatbot روی گفت‌وگو و تولید پاسخ است.

AI Coding Assistant

Coding Assistant یک قدم جلوتر است.

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

• تکمیل کد
• پیشنهاد کد
• توضیح کد
• Refactoring
• تولید تست
• رفع خطا

را انجام دهد.

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

AI Coding Agent

Coding Agent یک قدم دیگر جلو می‌رود.

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

مثلاً:

قابلیت احراز هویت با Google را به پروژه اضافه کن.

Agent ممکن است:

• ساختار پروژه را بررسی کند.
• فایل‌های Authentication را پیدا کند.
• Package مناسب را بررسی کند.
• فایل Configuration را تغییر دهد.
• Routeها را اضافه کند.
• Controller را ایجاد کند.
• UI را تغییر دهد.
• تست بنویسد.
• تست اجرا کند.
• خطاهای احتمالی را اصلاح کند.

در اینجا دیگر با یک «تولیدکننده کد» ساده طرف نیستیم.

با یک سیستم اجرای وظیفه نرم‌افزاری طرف هستیم.

اجزای اصلی یک AI Coding Agent

یک Coding Agent معمولاً از چند بخش اصلی تشکیل می‌شود.

1. مدل زبانی

در مرکز سیستم یک LLM قرار دارد.

مدل وظایفی مانند این‌ها را انجام می‌دهد:

• فهم درخواست کاربر
• تحلیل کد
• برنامه‌ریزی
• انتخاب ابزار
• تحلیل خروجی ابزار
• تولید کد
• تصمیم‌گیری درباره مرحله بعد

مدل‌هایی مانند Qwen، DeepSeek، Claude، GPT و مدل‌های تخصصی Coding می‌توانند در این نقش استفاده شوند.

اما خود مدل به‌تنهایی Coding Agent نیست.

این نکته بسیار مهم است.

2. Context

مدل باید اطلاعات لازم درباره پروژه را ببیند.

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

• Prompt کاربر
• فایل‌های مرتبط
• ساختار Repository
• Documentation
• خطاها
• خروجی Terminal
• Git Diff
• تست‌ها
• تاریخچه اقدامات Agent

اگر Context مناسب در اختیار مدل قرار نگیرد، حتی یک مدل بسیار قدرتمند هم ممکن است تصمیم اشتباه بگیرد.

3. Tools

Toolها دست و پای Agent هستند.

مدل بدون Tool می‌تواند فقط متن تولید کند.

با Tool می‌تواند اقدام انجام دهد.

Hugging Face در معماری Agent خود Tool را یک Function مستقل برای انجام یک وظیفه مشخص معرفی می‌کند. هر Tool دارای نام، توضیح، ورودی و خروجی است و این اطلاعات در اختیار Agent قرار می‌گیرد تا مدل بداند چه ابزاری را چه زمانی استفاده کند.

برای Coding Agent، Toolهای مهم می‌توانند شامل این موارد باشند:

File Tool

برای:

• خواندن فایل
• ایجاد فایل
• ویرایش فایل
• حذف فایل

Search Tool

برای:

• جست‌وجوی کد
• پیدا کردن Function
• پیدا کردن Class
• پیدا کردن Referenceها

Terminal Tool

برای:

• اجرای Command
• نصب Package
• اجرای Build
• اجرای Test
• اجرای Script

Git Tool

برای:

• مشاهده Status
• مشاهده Diff
• ایجاد Branch
• Commit
• بررسی تاریخچه

Browser Tool

برای:

• جست‌وجوی Documentation
• بررسی API
• پیدا کردن راه‌حل خطا

Agent چگونه تصمیم می‌گیرد از کدام Tool استفاده کند؟

فرض کنید کاربر می‌گوید:

خطای تست Authentication را پیدا و برطرف کن.

Agent ابتدا باید بفهمد چه اقداماتی لازم است.

ممکن است فرایند چیزی شبیه این باشد:

User Request
     ↓
LLM
     ↓
بررسی ساختار پروژه
     ↓
Search Tool
     ↓
پیدا کردن تست Authentication
     ↓
File Tool
     ↓
بررسی کد
     ↓
Terminal Tool
     ↓
اجرای Test
     ↓
دریافت Error
     ↓
LLM
     ↓
تغییر کد
     ↓
Terminal Tool
     ↓
اجرای دوباره Test
     ↓
موفق؟
   ↙     ↘
بله       خیر
 ↓         ↓
پایان    اصلاح دوباره

این حلقه، قلب یک Coding Agent است.

Agent Loop چیست؟

به چرخه تکرارشونده تصمیم‌گیری Agent معمولاً Agent Loop گفته می‌شود.

در ساده‌ترین شکل:

Observe
   ↓
Think
   ↓
Act
   ↓
Observe
   ↓
Think
   ↓
Act

مدل ابتدا وضعیت فعلی را می‌بیند.

سپس تصمیم می‌گیرد چه کاری انجام دهد.

Tool را اجرا می‌کند.

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

سپس بر اساس نتیجه، مرحله بعدی را انتخاب می‌کند.

این چرخه تا رسیدن به هدف یا رسیدن به محدودیت مشخص ادامه پیدا می‌کند.

Hugging Face در مستندات Agentهای خود نمونه‌ای از همین رویکرد را با ReAct توضیح می‌دهد که در آن Agent به‌صورت مرحله‌ای فکر می‌کند، Tool را اجرا می‌کند و نتیجه را برای تصمیم بعدی دریافت می‌کند.

ReAct چیست؟

یکی از الگوهای شناخته‌شده برای ساخت Agentها ReAct است.

نام ReAct از ترکیب:

Reason + Act

به وجود آمده است.

ایده ساده است:

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

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

مثلاً:

Task:
مشکل Login را پیدا کن.

↓
Reason

ابتدا فایل Authentication را پیدا می‌کنم.

↓
Act

Search Authentication

↓
Observation

auth/login.ts

↓
Reason

حالا باید تست مربوط به Login را بررسی کنم.

↓
Act

Read login.test.ts

↓
Observation

Test failed: token is undefined

↓
Reason

باید منبع تولید token را بررسی کنم.

و این فرایند ادامه پیدا می‌کند.

Hugging Face نیز ReAct را به‌عنوان یکی از الگوهای Agent برای تصمیم‌گیری مرحله‌ای بر اساس Observationهای قبلی توضیح می‌دهد.

Coding Agent چگونه یک Repository را می‌فهمد؟

یکی از بزرگ‌ترین مشکلات برنامه‌نویسی با AI، اندازه پروژه است.

فرض کنید پروژه‌ای دارید با:

src/
  auth/
  users/
  payments/
  products/
  orders/
  dashboard/
  services/
  database/
  utils/

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

حتی اگر Context بسیار بزرگ باشد، انجام این کار همیشه منطقی نیست.

Coding Agent باید ابتدا اطلاعات مرتبط را پیدا کند.

Repository Search چیست؟

Agent معمولاً با جست‌وجو شروع می‌کند.

مثلاً کاربر می‌گوید:

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

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

payment
payments
checkout
transaction
gateway

را جست‌وجو کند.

بعد فایل‌های مرتبط را پیدا کند.

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

این فرآیند باعث می‌شود مدل به جای خواندن کل Repository، ابتدا محدوده مسئله را پیدا کند.

Codebase Indexing چیست؟

در پروژه‌های بزرگ‌تر، فقط Search ساده کافی نیست.

ممکن است سیستم یک Index از Codebase ایجاد کند.

این Index می‌تواند اطلاعاتی مانند موارد زیر را نگه دارد:

• نام فایل‌ها
• Functionها
• Classها
• Importها
• Dependencyها
• Referenceها
• Symbolها
• Documentation

در این حالت Agent می‌تواند سریع‌تر بفهمد:

این Function کجا استفاده شده؟

یا:

این Class چه وابستگی‌هایی دارد؟

یا:

اگر این فایل تغییر کند، چه بخش‌هایی تحت تأثیر قرار می‌گیرند؟

این بخش از معماری Coding Agentها به‌تدریج اهمیت بیشتری پیدا کرده است.

Agent چگونه فایل را تغییر می‌دهد؟

پس از پیدا کردن فایل مناسب، Agent باید تغییر را اعمال کند.

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

مثلاً:

Full Rewrite

کل فایل دوباره تولید شود.

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

Patch

فقط بخش موردنظر تغییر کند.

مثلاً:

- old code

+ new code

این روش معمولاً کنترل بیشتری ایجاد می‌کند.

Structured Edit

Agent می‌تواند با شناخت ساختار کد، فقط Function یا Class مشخصی را تغییر دهد.

این روش برای پروژه‌های بزرگ‌تر مناسب‌تر است.

چرا اجرای Test برای Coding Agent حیاتی است؟

فرض کنید Agent یک Patch تولید کرده است.

از نظر خودش:

مشکل حل شد.

اما این حرف هیچ ارزشی ندارد تا زمانی که سیستم بتواند آن را بررسی کند.

اینجاست که Test وارد می‌شود.

Agent می‌تواند:

Edit
 ↓
Run Test
 ↓
Pass?

اگر تست موفق شد:

Task Complete

اگر تست شکست خورد:

Read Error
 ↓
Analyze
 ↓
Edit
 ↓
Run Test

این حلقه یکی از مهم‌ترین تفاوت‌های Coding Agent با Chatbot است.

یک نمونه واقعی از Coding Agent

Hugging Face نمونه بسیار جالبی از این معماری را در پروژه‌ای به نام Serge پیاده کرده است.

Serge یک Agent برای بررسی خطاهای واقعی پروژه Transformers است.

این Agent:

1. خطاهای مهم را انتخاب می‌کند.
2. خطا را بازتولید می‌کند.
3. بررسی می‌کند آیا شخص دیگری روی آن کار می‌کند یا نه.
4. Patch تولید می‌کند.
5. تست‌ها و بررسی‌های لازم را اجرا می‌کند.
6. Patch را دوباره بررسی می‌کند.
7. در صورت موفقیت Pull Request ایجاد می‌کند.

این پروژه کاملاً جالب است چون دیگر با یک Demo آزمایشگاهی طرف نیستیم.

Agent در یک Repository واقعی و روی تست‌های واقعی کار می‌کند. طبق گزارش Hugging Face، طی حدود ۸۰ روز، ۲۹ اصلاح ایجادشده توسط Serge به پروژه Transformers راه پیدا کرده‌اند.

معماری Serge چگونه است؟

فرایند Serge تقریباً به این شکل است:

CI Failures
     ↓
Filter Failures
     ↓
Reproduce
     ↓
Investigate
     ↓
Generate Patch
     ↓
Run Checks
     ↓
Verify Fix
     ↓
Open Pull Request
     ↓
Human Review
     ↓
Merge

نکته مهم اینجاست:

Agent مستقیماً اجازه تغییر main را ندارد.

Serge در یک محیط موقت Kubernetes اجرا می‌شود و دسترسی‌های آن محدود شده است.

در نهایت فقط می‌تواند Branch مخصوص خودش را ایجاد و Pull Request باز کند و Merge نهایی توسط انسان انجام می‌شود.

این دقیقاً یکی از اصول مهم طراحی Agentهای نرم‌افزاری است:

Agent باید بتواند اقدام کند، اما نباید بدون کنترل مناسب اجازه خرابکاری نامحدود داشته باشد.

Sandbox چیست و چرا برای Coding Agent مهم است؟

فرض کنید یک Agent به Terminal دسترسی دارد.

اگر به آن اجازه اجرای هر Commandی را بدهید، عملاً یک مدل زبانی را با دسترسی مستقیم به سیستم‌عامل تنها گذاشته‌اید.

این ایده از آن دسته ایده‌هایی است که روی کاغذ خیلی هوشمندانه به نظر می‌رسد و در دنیای واقعی احتمالاً پنج دقیقه بعد کسی می‌پرسد «چرا کل پروژه پاک شد؟»

به همین دلیل Coding Agentها معمولاً باید در محیط‌های محدود اجرا شوند.

مثلاً:

• Container
• Sandbox
• Virtual Machine
• Temporary Environment

در نمونه Serge، هر Task در یک Kubernetes Pod کوتاه‌عمر اجرا می‌شود و دسترسی‌های آن محدود شده است.

Memory در Coding Agent چه نقشی دارد؟

Agent ممکن است در طول اجرای یک Task اطلاعات زیادی جمع کند.

مثلاً:

Step 1:
فایل Authentication پیدا شد.

Step 2:
مشکل مربوط به Token است.

Step 3:
Test شکست خورد.

Step 4:
کد اصلاح شد.

Step 5:
Test دوم موفق شد.

اگر Agent نتواند این اطلاعات را نگه دارد، در هر مرحله دوباره از اول شروع می‌کند.

به همین دلیل Coding Agent می‌تواند از چند نوع Memory استفاده کند.

Short-Term Memory

اطلاعات مربوط به Task فعلی.

Conversation Memory

تاریخچه تعامل با کاربر.

Repository Memory

اطلاعاتی درباره ساختار و تاریخچه پروژه.

External Memory

اطلاعات ذخیره‌شده خارج از Context مدل.

Context با Memory چه تفاوتی دارد؟

این دو مفهوم نباید با یکدیگر اشتباه شوند.

Context اطلاعاتی است که در حال حاضر در اختیار مدل قرار گرفته است.

Memory سازوکاری برای نگهداری و بازیابی اطلاعات در طول زمان است.

برای مثال:

اگر Agent بداند:

فایل auth.ts در Repository وجود دارد.

این می‌تواند بخشی از Context فعلی باشد.

اما اگر سیستم این اطلاعات را ذخیره کند تا چند ساعت بعد دوباره از آن استفاده کند، وارد حوزه Memory می‌شویم.

این تفاوت در ساخت Agentهای بلندمدت بسیار مهم است.

Coding Agent چگونه خطا را پیدا می‌کند؟

فرض کنید Agent یک Test را اجرا می‌کند.

خروجی:

FAILED

Expected:
200

Received:
500

Agent باید این خروجی را بفهمد.

سپس ممکن است:

1. Stack Trace را بررسی کند.
2. فایل خطادار را پیدا کند.
3. Function مربوطه را بررسی کند.
4. Dependencyها را بررسی کند.
5. تغییر پیشنهادی ایجاد کند.
6. Test را دوباره اجرا کند.

بنابراین Test Runner فقط یک ابزار برای بررسی نهایی نیست.

Test می‌تواند به Agent اطلاعات جدید بدهد.

این Observation دوباره وارد چرخه تصمیم‌گیری می‌شود.

چرا Feedback Loop برای Coding Agent مهم است؟

یک مدل زبانی می‌تواند کدی تولید کند که ظاهراً درست باشد اما واقعاً کار نکند.

مثلاً:

Generate Code

بدون بررسی، مدل ممکن است:

• API اشتباه استفاده کند.
• Function اشتباه را صدا بزند.
• Type اشتباه تولید کند.
• Dependency ناموجود اضافه کند.
• Test را خراب کند.

اما اگر سیستم بتواند نتیجه واقعی را مشاهده کند، مدل می‌تواند بر اساس Feedback خودش را اصلاح کند.

بنابراین:

Generate
 ↓
Execute
 ↓
Observe
 ↓
Correct
 ↓
Execute Again

یکی از پایه‌های اصلی Agentic Coding است.

آیا Coding Agent واقعاً خودش برنامه‌نویس است؟

این سؤال کمی گمراه‌کننده است.

Coding Agent یک برنامه‌نویس انسانی نیست.

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

مثلاً:

• پیدا کردن فایل
• جست‌وجوی کد
• تولید Patch
• اجرای Test
• بررسی Error
• اصلاح کد
• تولید Documentation
• ایجاد Pull Request

اما هنوز مسئله‌هایی مانند:

• تصمیم معماری
• درک اهداف کسب‌وکار
• Trade-offهای فنی
• امنیت
• تصمیم‌های Product
• بررسی نهایی

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

نمونه Serge در Hugging Face نیز همین مدل را نشان می‌دهد: Agent می‌تواند Patch و Pull Request تولید کند، اما Merge نهایی همچنان توسط Maintainer انجام می‌شود.

Agentic Coding چیست؟

به استفاده از Agentها برای انجام وظایف مهندسی نرم‌افزار، معمولاً Agentic Coding یا Agentic Software Engineering گفته می‌شود.

تفاوت اصلی با Coding معمولی در میزان استقلال سیستم است.

در روش سنتی:

Human
 ↓
Code
 ↓
Human Test
 ↓
Human Fix

در Coding Assistant:

Human
 ↓
AI Suggestion
 ↓
Human Edit
 ↓
Human Test

در Agentic Coding:

Human Goal
 ↓
Agent Planning
 ↓
Tool Use
 ↓
Code Change
 ↓
Test
 ↓
Observation
 ↓
Correction
 ↓
Verification
 ↓
Human Review

این تغییر، یکی از مهم‌ترین تحولات استفاده از AI در برنامه‌نویسی است.

چرا Coding Agentها به مدل‌های قوی‌تر نیاز دارند؟

یک مدل برای تولید یک Function ساده ممکن است نیازی به Reasoning بسیار پیچیده نداشته باشد.

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

مثلاً:

آیا مشکل از Backend است یا Frontend؟

بعد:

کدام فایل را باید بررسی کنم؟

بعد:

آیا این Dependency مرتبط است؟

بعد:

آیا این Patch خطر ایجاد Regression دارد؟

بعد:

کدام Test را اجرا کنم؟

بنابراین Agentic Coding به مدل‌هایی نیاز دارد که در موارد زیر عملکرد خوبی داشته باشند:

• Reasoning
• Code Generation
• Tool Use
• Long Context
• Planning
• Error Recovery

به همین دلیل مدل‌های جدیدی مانند Qwen و DeepSeek تمرکز زیادی روی Coding Agent و Tool Use دارند.

آیا Context بزرگ به‌تنهایی یک Coding Agent خوب می‌سازد؟

خیر.

Context بزرگ فقط به مدل اجازه می‌دهد اطلاعات بیشتری را ببیند.

اما مسئله اصلی این است که مدل بتواند اطلاعات مرتبط را پیدا و استفاده کند.

فرض کنید یک Repository شامل ۵ میلیون Token اطلاعات باشد.

اگر تمام آن را به مدل بدهیم، لزوماً مدل بهتر عمل نمی‌کند.

ممکن است:

• اطلاعات مهم گم شود.
• Context شلوغ شود.
• هزینه افزایش پیدا کند.
• سرعت کاهش پیدا کند.

به همین دلیل Coding Agentهای حرفه‌ای به ترکیبی از:

Search + Retrieval + Context Management + Reasoning

نیاز دارند.

آینده Coding Agentها به کدام سمت می‌رود؟

مسیر توسعه Coding Agentها احتمالاً از «تولید کد» به سمت «انجام وظیفه کامل نرم‌افزاری» حرکت می‌کند.

یعنی به جای:

این Function را بنویس.

دستورهایی مانند:

این Issue را حل کن.

یا:

این Feature را به پروژه اضافه کن.

یا حتی:

این پروژه را بررسی کن و مشکلات امنیتی مهم را پیدا و اصلاح کن.

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

نمونه واقعی Serge در Hugging Face نشان می‌دهد این مسیر فقط یک ایده نظری نیست. یک Agent می‌تواند خطاهای واقعی CI را انتخاب کند، آن‌ها را بازتولید کند، Patch ایجاد کند، تست بگیرد و Pull Request آماده کند.

MCP چه نقشی در آینده Coding Agent دارد؟

یکی از مشکلات Agentها این است که باید به ابزارهای زیادی دسترسی داشته باشند.

MCP یا Model Context Protocol یکی از استانداردهایی است که برای اتصال مدل‌ها و Agentها به ابزارها و منابع خارجی اهمیت پیدا کرده است.

Hugging Face نیز اکنون امکان اتصال Agentها به Hub را از طریق MCP فراهم کرده و Agent می‌تواند از طریق MCP به مدل‌ها، Datasetها، Spaces و ابزارهای مختلف دسترسی پیدا کند.

در نتیجه می‌توان آینده‌ای را تصور کرد که Coding Agent فقط به Repository محلی محدود نباشد.

بلکه بتواند به:

• Git
• Documentation
• Hugging Face
• Database
• Cloud
• Monitoring
• CI/CD
• Issue Tracker
• Browser

متصل شود.

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

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

محدودیت‌های Coding Agent چیست؟

با وجود پیشرفت زیاد، Coding Agentها هنوز محدودیت دارند.

Hallucination

ممکن است API یا Functionای را اختراع کنند که وجود ندارد.

اشتباه در درک پروژه

ممکن است Context اشتباه را انتخاب کنند.

تغییر بیش از حد

گاهی Agent برای حل یک مشکل کوچک، فایل‌های زیادی را تغییر می‌دهد.

Loop

Agent ممکن است بین چند راه‌حل ناموفق گیر کند.

هزینه

وظایف طولانی می‌توانند Token و زمان زیادی مصرف کنند.

امنیت

دادن دسترسی Terminal و File System بدون Sandbox خطرناک است.

تصمیم‌های معماری

مدل ممکن است یک راه‌حل فنی درست اما از نظر معماری نامناسب انتخاب کند.

به همین دلیل Coding Agent هنوز جایگزین کامل مهندس نرم‌افزار نیست.

یک Coding Agent خوب چه ویژگی‌هایی دارد؟

اگر بخواهیم یک Coding Agent حرفه‌ای طراحی کنیم، فقط انتخاب یک LLM قدرتمند کافی نیست.

یک سیستم خوب باید حداقل این اجزا را داشته باشد:

مدل قدرتمند

برای Reasoning و Code Generation.

Context Management

برای انتخاب اطلاعات مرتبط.

Repository Search

برای پیدا کردن کدهای موردنیاز.

Tool System

برای دسترسی به محیط واقعی.

Terminal

برای اجرای دستورات.

Test Runner

برای بررسی تغییرات.

Git Integration

برای کنترل تغییرات.

Memory

برای نگهداری اطلاعات مهم.

Sandbox

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

Error Recovery

برای تلاش دوباره پس از شکست.

Human Review

برای تصمیم‌های حساس.

این ترکیب است که یک LLM را به Coding Agent تبدیل می‌کند.

جمع‌بندی

AI Coding Agent را نباید فقط یک «مدل هوش مصنوعی که کد می‌نویسد» در نظر گرفت.

یک Coding Agent یک سیستم کامل است که در مرکز آن یک LLM قرار دارد و در اطراف آن ابزارهایی برای تعامل با محیط توسعه وجود دارد.

مدل می‌تواند مسئله را تحلیل کند، اما Toolها به آن امکان اقدام می‌دهند.

Agent می‌تواند فایل را بخواند، اما Search به آن کمک می‌کند فایل درست را پیدا کند.

Agent می‌تواند کد تولید کند، اما Test Runner مشخص می‌کند کد واقعاً کار می‌کند یا نه.

Agent می‌تواند اشتباه کند، اما Feedback Loop به آن امکان اصلاح می‌دهد.

در یک معماری کامل، چرخه می‌تواند چنین باشد:

User Goal
   ↓
Understand
   ↓
Plan
   ↓
Search
   ↓
Read Code
   ↓
Use Tools
   ↓
Modify Code
   ↓
Run Tests
   ↓
Observe Result
   ↓
Fix
   ↓
Verify
   ↓
Human Review

و این دقیقاً همان نقطه‌ای است که Agentic Coding از یک Chatbot ساده جدا می‌شود.

نمونه‌هایی مانند Agent داخلی Hugging Face برای رفع باگ نشان می‌دهند که این معماری دیگر صرفاً یک Demo نیست و می‌تواند در پروژه‌های واقعی نیز بخشی از فرایند مهندسی نرم‌افزار را انجام دهد.

در نهایت، آینده برنامه‌نویسی احتمالاً نه «انسان در برابر AI» است و نه «AI جایگزین کامل برنامه‌نویس».

سناریوی محتمل‌تر این است:

انسان هدف را مشخص می‌کند، Agent بخش بزرگی از اجرای کار را انجام می‌دهد و انسان نتیجه را بررسی و تأیید می‌کند.

و این تغییر، احتمالاً یکی از مهم‌ترین تغییرات تاریخ ابزارهای توسعه نرم‌افزار خواهد بود.