What Makes a Coding Agent Agentic?

In the previous post, I learned more terminology than I expected. Models, parameters, quantization, context windows, tokens, inference, runtimes, tools, agents...

At least now I have a better picture of the pieces involved.

The model provides the reasoning. The runtime executes the model. Tools provide access to things such as files and the terminal. And the agent connects these pieces into a workflow.

But this description still leaves an important question:

What does a coding agent actually do?

If I give an agent access to my project, how is it fundamentally different from the AI assistance I already use every day?

I need to understand this behavior before giving permission to an agent to start changing my code.

From answering questions to performing tasks

My normal interaction with AI while coding looks something like this:

I might ask:

How should I add validation to this Spring Boot endpoint?

The AI explains an approach and probably generates some code.

Then I take over.

I decide which files need to change. I apply the code. I compile the project. If something fails, I copy the error back into the conversation. The AI suggests another solution, and I try again.

It's a very useful workflow, but I'm the one connecting all the steps.

With an agent, I can potentially change the request to:

Add validation to this endpoint.

Now the agent can use its tools to work with the actual project rather than only talking about it.

A possible workflow becomes:

The important transition is from producing an answer to performing a task.

An ordinary AI conversation produces an answer. An agentic workflow can use AI reasoning to perform actions, observe their results, and continue based on what happened.

First, the agent needs to inspect

If I ask:

Fix the failing test in TransactionServiceTest.

the agent shouldn't immediately start generating replacement code.

It first needs to understand what already exists.

This might involve finding and reading:

TransactionServiceTest
        ↓
TransactionService
        ↓
TransactionRepository
        ↓
Related entities or classes

It may need to search for similar implementations elsewhere, inspect configuration, or understand how the existing tests are structured.

The agent now has access to the actual state of the project, rather than only the code I manually include in a conversation.

This is important because I don't want an agent to solve the problem using the architecture it would have designed. I want it to understand the architecture I already have and work within it.

Then it can modify the project

Once it has enough information, the agent can use another tool to modify files.

The change could involve adding a method to an existing Service, changing a Controller, creating a test, updating configuration, or modifying several related files.

For example:

Inspect Controller
        ↓
Inspect Service
        ↓
Inspect Repository
        ↓
Determine required changes
        ↓
Modify Controller
        ↓
Modify Service
        ↓
Add tests

This is already considerably different from asking a chatbot to generate three files and manually copying them into the project.

But modifying files isn't the part I find most interesting.

What happens after the modification is where the workflow becomes more useful.

The agent can check what actually happened

Suppose the agent changes the code.

A language model can reason that the code looks correct. But software gives us something better than confidence: we can often execute it.

If the agent has access to the terminal, it can run something like:

./mvnw test

Maybe everything passes:

Tests: 47
Passed: 47
Failed: 0

Or maybe:

Tests: 47
Passed: 44
Failed: 3

The second result makes agentic coding much more interesting because the agent has received new information from the environment.

The model predicted a particular change might solve the problem. The test results now provide evidence about what actually happened. Tests are especially useful in this workflow because they give the agent an objective feedback signal instead of forcing it to assume generated code works.

In other words:

Generating code is a prediction. Running it creates feedback.

And software development is full of feedback.

Failure doesn't have to end the task

If three tests fail, the agent doesn't necessarily have to stop and hand the problem back to me.

It can inspect the failures.

Change code
    ↓
Run tests
    ↓
3 failures
    ↓
Read errors
    ↓
Reason about the cause
    ↓
Inspect more code
    ↓
Modify again
    ↓
Run tests again

Maybe the change introduced a compilation error. Maybe an existing test exposed a behavior the agent didn't understand. Maybe a mock needs updating. Maybe its original assumption was simply wrong.

The result of one action becomes information for the next decision.

This creates a loop:

The reason → act → observe → adapt cycle is the core idea behind the word agentic.

The ability to write files alone isn't what makes this interesting. The system can interact with an environment, see the consequences of its actions, and use those results to determine what happens next.

Agentic is different from normal automation

At first, this can sound a lot like a script. After all, developers have been automating development tasks forever.

A script might do this:

Run command A
      ↓
Run command B
      ↓
Run command C

The sequence was decided when I wrote the script.

An agentic workflow can instead look more like:

Perform action
      ↓
Observe result
      ↓
What happened?
      ↓
Choose next action
      ↓
Perform action

If the tests pass, it might finish.

If they fail, it might inspect the error.

If the error points to another class, it might read that class.

If it discovers its original plan was wrong, it might change the plan.

The autonomy comes from choosing subsequent steps based on what the system discovers, rather than simply following a fixed sequence.

Agentic doesn't mean unlimited control

The ability to choose the next action immediately creates another question: what am I actually allowing the agent to do?

Reading TransactionService.java is very different from deleting a database.

Running unit tests is very different from deploying something to production.

Looking at a Git diff is very different from pushing directly to the main branch.

So autonomy and permission aren't the same thing.

I might eventually be comfortable with something like:

Operation	Possible approach
Read source files	Allow
Edit project files	Allow
Run tests	Allow
Run builds	Allow
Inspect Git changes	Allow
Commit changes	Ask first
Push changes	Ask first
Delete files	Ask first
Production operations	Never

The exact rules aren't important yet. I'll define those later when I build the actual workflow.

The principle is more important:

An agent can have enough autonomy to work through a task without having unlimited authority over the environment.

This gives me a more reasonable boundary for the experiment.

And the developer doesn't disappear

Agentic coding doesn't require me to type:

Build this feature.

and then go for lunch while the AI does whatever it wants.

The workflow can still have human checkpoints.

For example:

Developer
    ↓
Define task
    ↓
Agent
    ↓
Inspect + modify + test
    ↓
Developer
    ↓
Review Git diff
    ↓
Accept / reject / continue

The agent can have autonomy inside the task while I still control important boundaries.

This balance will probably matter a lot in my experiment. I want enough autonomy to understand whether agentic coding actually saves work, but I also want to know what the system changed and why.

Current coding-agent tools follow this general pattern as well: they can inspect repositories, edit multiple files, run commands, and react to errors, while permissions or approval rules can keep consequential actions under developer control.

So what makes the agent agentic?

I started with this simplified architecture in the previous post:

Model + Runtime + Tools + Agent

Now I can add the missing behavior.

Tools aren't valuable simply because they exist. Their value comes from the agent using them as part of a feedback loop:

This changes the role of AI in my development workflow.

Instead of:

"Tell me how to do this."

I can move toward:

"Work through this task and show me what you changed."

How well a small local model can actually handle this responsibility is still completely unknown.

Can it find the right files? Can it make changes consistent with the existing architecture? Can it choose the right commands? Can it understand a test failure instead of making the situation worse? Can it iterate toward a solution without wandering through the project changing unrelated things?

These are exactly the questions I want the experiment to answer.

A coding agent isn't agentic simply because it can generate code or edit a file. It becomes agentic when it can use tools, observe the results of its actions, and use the feedback to decide what to do next.

I now understand the behavior I'm looking for.

The next step is finding out whether my Mac can run a model capable enough to support it.