How an AI Coding Agent Works

Lecture



To put it simply, virtually any modern AI coding agent (for example, an agent built into an IDE, an autonomous coding agent, or a system with subagents) works as a "plan → execute → verify → fix" loop.

Here is a rough architecture.

How an AI Coding Agent Works

1. The main agent (Orchestrator)

This is the "conductor".

It:

  • receives the user's request;
  • understands the goal;
  • draws up a plan;
  • decides which subagents are needed;
  • collects the results back together.

For example:

Build an online store using FastAPI with React.

The main agent does not write all the code itself.

It may decide on:

  • 1 Backend
  • 2 Frontend
  • 3 Database
  • 4 Docker
  • 5 Tests
  • 6 README

2. The planner

It breaks the task down.

For example:

Create the API
↓
Create the models
↓
Create the migrations
↓
Create the routes
↓
Add JWT
↓
Write tests

This can be a task tree.

Backend
├── auth
├── users
├── products
├── orders
└── payments

3. Subagents

These are separate LLM instances, each with its own role.

For example.

Backend Agent

It receives only the task:

  • Write the users API.

It knows nothing at all about React.

Frontend Agent

It receives:

  • Use the API.
  • Build the pages:
  • - Login
  • - Products
  • - Cart

Database Agent

It receives:

  • Design the PostgreSQL schema.

Test Agent

It receives:

  • Check the backend.
  • Write unit tests.

Documentation Agent

It receives:

  • Create a README.

Why subagents are faster

Imagine a single agent.

Its context:

  • 300 files
  • 50,000 lines

The LLM starts forgetting details.

But if you split things up:

Backend Agent

  • sees only
  • backend/

Frontend Agent

  • sees only
  • frontend/

Each one uses less context.

4. Skills, MCP servers and Tools

Practically no modern coding agent is limited to generating text alone.

When it comes to modern agentic systems, Skills, MCP servers and Tools are three different levels of abstraction, although in practice they work together.

You can picture it like this:

User request
        │
        ▼
    Main agent
        │
        ├─────────────┬──────────────┐
        ▼             ▼              ▼
     Skills        MCP Servers      Tools
        │             │              │
        └─────────────┴──────────────┘
                    │
                    ▼
                Execution

1. Tools — atomic actions

A tool performs one specific action.

Typically it can:

  • read files
  • write files
  • create folders
  • run a terminal
  • git
  • docker
  • pytest
  • npm
  • curl
  • browser
  • documentation search
  • run a command;
  • make an HTTP request;
  • run an SQL query;
  • open a browser.

In other words:

read_file(path)
write_file(path)
run_terminal(cmd)
search_web(query)

A tool usually has no logic of its own.

It simply runs the command.

So the loop looks like this:

LLM
↓
create a file
↓
run the test
↓
see the error
↓
fix the file
↓
repeat

2. Skills — ready-made procedures

A skill is already a mini-process consisting of several steps.

For example:

Skill "Create a REST API"
↓
read the project structure
↓
create the models
↓
create the controllers
↓
create the tests
↓
update the README

It can use dozens of tools internally.

That is

Skill
↓
Tool
↓
Tool
↓
Tool
↓
Tool

A skill answers the question:

How do you carry out a typical task?

For example:

Skill: Add a new page
↓
create the file
↓
add the route
↓
update the menu
↓
write a test

3. MCP — a way to plug in external capabilities

MCP (Model Context Protocol) is a protocol, not a tool and not a skill.

It is responsible for the connection between the agent and an external system.

For example:

IDE
↓
MCP
↓
GitHub

or

LLM
↓
MCP
↓
PostgreSQL

or

LLM
↓
MCP
↓
Docker

or

LLM
↓
MCP
↓
Figma

MCP itself does nothing.

It says:

"Here is the list of functions this system provides."

An MCP server provides tools

For example:

GitHub MCP
↓
list_repositories()
↓
create_issue()
↓
merge_pull_request()
↓
create_branch()

To the agent, this looks like a set of new tools.

Another example:

Postgres MCP
↓
execute_sql()
↓
list_tables()
↓
describe_table()

So where does the Skill fit in?

Say there is a skill

Fix a bug

It can do the following:

1 Read the issue
2 Find the code
3 Fix it
4 Run the tests
5 Create a PR

Internally it uses:

GitHub MCP
↓
get_issue()
Filesystem Tool
↓
read_file()
Terminal Tool
↓
pytest
GitHub MCP
↓
create_pull_request()

So a single skill can simultaneously use:

  • local tools;
  • MCP servers;
  • other skills.

This gives the following hierarchy

Agent
↓
Skill
↓
Tool
↓
MCP Server
↓
The real system

For example:

Skill Create a Pull Request
↓
git diff
↓
git commit
↓
GitHub MCP
↓
create_pull_request()

Or the other way round

Sometimes MCP itself provides a ready-made skill.

For example, a CI server may have:

deploy_application()
rollback()
create_release()

For the agent these are already close to skills, even though technically they arrive as tools via MCP.

Are they used at the same time?

Yes.

For example, the agent receives the task:

"Fix the bug and create a Pull Request."

It might do roughly the following:

Skill "Fix a bug"
↓
Filesystem Tool
↓
Terminal Tool
↓
Git Tool
↓
GitHub MCP
↓
Browser MCP
↓
Skill "Code Review"
↓
GitHub MCP

All of this works within a single loop.

A brief comparison

Component What it is Main role
Tool A single action «Read the file», «run the command», «execute SQL»
Skill A scenario made up of several steps «Add an API», «Fix a bug», «Prepare a release»
MCP A connection protocol Gives the agent access to the capabilities of external systems (GitHub, IDEs, databases, Docker, etc.)

The key distinction is that MCP does not compete with Tools. On the contrary, MCP is most often a way of giving the agent new tools. And Skills sit one level higher: they coordinate the use of those tools (both local ones and ones obtained via MCP) to solve a complete task.

5. The execution loop (Agent Loop)

This is the most important part.

Almost all agents work roughly like this.

Until the task is complete:

  • think
  • choose an action
  • perform the action
  • look at the result
  • make the next decision

For example:

Step 1

Create app.py
↓
Step 2
Run pytest
↓
Error
↓
Fix
↓
Run again
↓
Error
↓
Fix
↓
All tests green

6. Memory

There are several levels of memory.

Short-term

The context of the current conversation.

For example:

We are using FastAPI.

Working memory

The task plan.

✔ Backend
✔ Database
 Tests
 Docs

Long-term

It can store:

code style
preferences
architecture
previous decisions

7. The reviewing agent

Very often a separate agent is used.

It writes nothing.

It only looks for errors.

For example:

The Backend Agent wrote the code.
↓
Reviewer Agent
↓
Found a bug
↓
Returned comments
↓
The Backend Agent fixed it

This is similar to the Code Review process.

8. Debug Agent

A separate agent can deal exclusively with errors.

For example.

pytest
↓
FAIL
↓
Debug Agent
↓
reads the stacktrace
↓
fixes it
↓
repeats

9. The main loop

In the end, it can all be represented like this:

User
↓
Main agent
↓
Plan
↓
Subagents
↓
Code
↓
Compilation
↓
Tests
↓
Errors
↓
Fixes
↓
Tests
↓
Errors
↓
Fixes
↓
Done

10. How subagents interact

Usually subagents do not talk to each other directly. Instead, they exchange information through the main agent.

Example:

Frontend Agent
        │
        ▼
   Main agent
        ▲
        │
Backend Agent

Or through shared project artifacts:

  • the file system (code, configs);
  • the issue tracker;
  • the shared plan;
  • the change log.

The main agent can pass one subagent's results to another, for example: "The backend has finished the API, now use this OpenAPI specification to generate the client".

11. What advanced systems use

In practice, modern systems (for example, agents in IDEs or autonomous coding agents) often add a few more components:

  • A context manager — selects only the files that are genuinely needed for the current task.
  • RAG (Retrieval-Augmented Generation) — finds relevant sections of code, documentation and change history instead of loading the whole project into the context.
  • A dependency planner — determines the order in which tasks are executed in order to avoid conflicts.
  • Isolated environments (containers, for example) — make it safe to run tests, builds and linters.
  • Merge mechanisms — help combine the results of several subagents if they worked in parallel.

Simplified pseudocode

while not task.completed():
    plan = planner.next_step()
    agent = orchestrator.select_agent(plan)
    result = agent.execute(plan)
    repository.apply(result)
    report = tester.run()
    if report.failed:
        debugger.fix(report)
    else:
        planner.mark_done()

It is precisely this loop — plan → execute → verify → fix — that underpins most modern AI coding agents. The differences between systems mainly come down to the quality of planning, the efficiency of context selection, the set of available tools, how subagents are organised, and the depth of automation.

created: 2026-06-22
updated: 2026-06-22
1



Was this answer useful?
Choose a quick rating so we can improve the next answer for you.
How satisfied are you?


Comments

To leave a comment

If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

Lectures and tutorial on "Software and information systems development"

Terms: Software and information systems development