Understand what happens after delegation — then build around it, not against it
There was a time when using AI for software development meant leaving the development environment.
You had a problem in your codebase. You described it to ChatGPT. It produced a code snippet. You copied that snippet back into the project, adjusted it to fit the surrounding code, discovered what context the model had missed, corrected it, and continued.
Before that, we did roughly the same thing with Stack Overflow.
The source of the answer changed.
The interaction model did not change nearly as much.
Early copilots improved the experience. AI moved into the editor. It could see more of what we were doing, complete code, generate methods and help with implementation.
But the human was still carrying most of the context and coordinating most of the work.
Agentic development changed that.
The important difference was not simply that the model became better at writing code.
The important difference was what started happening after we delegated the task.
That is what I mean by the inner loop of agentic development.
The inner loop is the agent's loop, not the developer's
“Inner loop” is used in software development in several ways, so the distinction matters.
I am not talking here about the developer feedback loop:
change → build → test → inspect → change again.
And I am not talking about the broader product loop:
idea → implementation → production → customer feedback.
Those loops matter, perhaps more than ever, but they are not the subject of this essay.
The agentic inner loop begins after the human delegates something and ends when the agent returns a result.
Conceptually, it contains activities such as:
acquire context → reason → use tools → act → observe → adjust → continue
The exact sequence is not important.
Modern agents do not necessarily follow one rigid loop, and their internal mechanics change constantly.
What matters is the qualitative shift.
The model no longer waits outside the system for a human to bring it fragments of information.
It can operate inside the environment where the problem exists.
From answering questions to operating inside the system
Consider the old interaction:
“Here is a method. There is a bug. Can you fix it?”
The model knew what you pasted into the conversation.
Maybe you also pasted a related class.
Maybe you explained some architecture.
Everything outside that manually supplied context was effectively invisible.
That created an obvious limitation.
The generated solution might be correct in isolation while being completely wrong for the actual system.
Perhaps the codebase already had a reusable implementation.
Perhaps there was a domain rule elsewhere.
Perhaps the project followed a different architectural pattern.
Perhaps the proposed dependency was incompatible with the runtime.
Perhaps the behavior had already been solved three folders away.
The model simply did not know.
With an agent, the request can instead be:
“Fix this behavior.”
And the agent can investigate.
It can inspect the repository.
Search for similar implementations.
Read configuration.
Follow dependencies.
Look at tests.
Run the application.
Inspect an error.
Search documentation.
Query an API.
Connect to an external system.
Modify files.
Install a dependency.
Run validation.
See that its first attempt failed.
Revise it.
And continue.
The change from conversation to action inside context is what made agentic development fundamentally different.
Tool use turned reasoning into work
Reasoning alone is not enough to make an agent useful.
A model might conclude:
“I should inspect the existing implementation.”
Without tools, that thought ends there.
With tools, it can actually inspect it.
It might conclude:
“The API contract has changed.”
Then retrieve the current documentation.
It may discover:
“This behavior already exists in another bounded context.”
Then search the repository and examine that implementation.
It might modify the code and wonder whether it works.
Then run the tests.
The output of one action becomes context for the next decision.
That is the loop.
Tools turn reasoning into interaction with reality.
And that is why modern coding agents feel much less like somebody giving advice from outside the room and much more like somebody actually working inside the project.
Context became an engineering problem
Once an agent can explore the system itself, another problem becomes obvious:
what should it look at?
A repository can contain hundreds of thousands or millions of lines of code.
There may be documentation, tickets, architecture records, databases, product specifications and years of decisions.
Giving an agent access to everything does not mean putting everything into its active context at once.
Context remains constrained.
Even when context windows become larger, attention is not free.
Every irrelevant file competes with something useful.
Every repeated investigation consumes effort.
Every obsolete document can introduce confusion.
A large part of effective agentic development therefore becomes context engineering.
Not:
“How do I put as much information as possible into the prompt?”
But:
“How can the agent obtain the right information when it needs it, without repeatedly rediscovering the whole system?”
That is a very different problem.
Don't explain what the agent can discover
A common temptation is to prepare enormous context documents before giving the agent work.
We explain:
- how the system works,
- where everything is located,
- what every component does,
- what technologies we use,
- how existing features behave.
But much of that information already exists.
It exists in the code.
In architecture documents.
In tests.
In configuration.
In previously recorded decisions.
An agent with access to those sources should normally retrieve that information itself.
What deserves explicit explanation is usually what is new.
The new requirement.
The new constraint.
A business decision the code does not yet express.
A change in direction.
A relationship between the requested work and an existing system that cannot easily be inferred.
The existing system should increasingly become retrievable context, not something a human must rewrite into every specification.
That is both more efficient and more maintainable.
Investigation is not free
This does not mean agents should rediscover everything from scratch every time.
That is the opposite failure mode.
Imagine an agent spends half of its useful capacity repeatedly working out:
- which architecture is used,
- where a domain lives,
- why a particular dependency exists,
- how two legacy systems interact,
- which implementation is canonical.
Then less capacity remains for the problem we actually asked it to solve.
Investigation competes with problem solving.
This is one reason clean architecture, recognizable patterns, documentation and durable context matter so much in agentic systems.
If something expensive to discover is stable and likely to matter again, preserve that knowledge somewhere predictable.
The next agent should not need to repeat the archaeological excavation.
Context engineering should reduce repeated discovery.
It should not create another documentation bureaucracy.
Know your agent's inner loop
There is an old principle from The Pragmatic Programmer that remains remarkably relevant:
Know your tools.
Coding agents are tools, even if increasingly capable ones.
A developer working seriously with them should understand what they can do.
How they explore a repository.
How they use tools.
How their context works.
How they preserve or lose information.
How they validate work.
What changes between releases.
What new capabilities have become native.
This matters because the internal loop is improving extremely quickly.
Features that required elaborate custom workflows a few months ago may become built-in capabilities.
A weakness you worked around yesterday may disappear tomorrow.
Understanding that evolution changes what you should build yourself.
The internal harness is getting better very quickly
I find it useful to think about two different harnesses.
The first is the internal harness.
This is effectively the operating system around the model supplied by the agent itself.
It handles generic capabilities such as:
- repository exploration,
- context selection,
- tool execution,
- code editing,
- planning,
- command execution,
- validation,
- recovery,
- increasingly sophisticated software-engineering reasoning.
Claude Code, Codex and similar systems keep improving this layer.
Rapidly.
And that creates an architectural consequence for us.
Be careful when building external machinery that tries to reproduce what belongs inside that internal harness.
Don't compete with the agent vendor
Suppose I create a complicated external system teaching my coding agent:
- how to explore a repository,
- how to plan an ordinary implementation,
- how to write generic backend code,
- how to refactor,
- how to decide which files to inspect,
- how to perform standard frontend work.
Perhaps today my custom workflow improves the result.
Then the underlying agent improves.
Its internal repository exploration becomes better.
Its planning changes.
Its context management improves.
Its validation becomes more capable.
Now my carefully engineered external workflow may be redundant.
Worse, it may actively interfere with the better internal behavior.
I can accidentally make a stronger agent weaker by forcing it through assumptions designed around an older version.
This is one of the reasons I hesitated for a long time before building substantial external harnesses around coding agents.
Anything generic felt temporary.
And much of it was.
Build the external harness around what only you know
Eventually the boundary became clearer.
The external harness should concentrate on what the general-purpose coding agent cannot know by itself.
Your context.
Your organization.
Your constraints.
Your preferred way of working.
For example:
- how your legacy and new systems must coexist;
- business rules that are not represented clearly in code;
- company-specific architecture decisions;
- which environments the agent is allowed to modify;
- your intake process;
- risk-sensitive approval points;
- how work should be isolated;
- what validation your organization requires;
- your definition of done;
- domain vocabulary;
- organizational ownership boundaries;
- specific workflows your team wants to follow.
A vendor cannot build these things generically because they are not generic.
That makes them much more durable targets for external harness engineering.
The internal harness supplies increasingly capable intelligence.
The external harness supplies local reality.
Shape the environment, don't micromanage the intelligence
This leads to a principle I increasingly use:
Understand the agent's inner loop deeply. Shape the environment around it. Avoid overriding its mechanics without a strong reason.
This is different from doing nothing.
A good external harness can dramatically improve an agent.
But it should improve the agent primarily by giving it:
- better context,
- safer boundaries,
- access to relevant tools,
- organizational knowledge,
- clearer feedback,
- appropriate constraints.
Not by trying to dictate every reasoning step.
The distinction resembles good organizational design.
You do not improve capable people by prescribing every thought they should have.
You create an environment where good decisions become easier.
Agentic systems increasingly deserve the same treatment.
Internal and external harnesses should evolve at different speeds
There is another useful consequence of separating the two layers.
The internal harness can change daily.
That is fine.
Agent vendors are competing to improve exactly that layer.
Your external harness should ideally be more stable.
Your business does not fundamentally change every time a coding agent releases a new version.
Your domain language does not need rewriting because context retrieval improved.
Your architectural constraints do not disappear because tool calling got faster.
Your validation expectations are still yours.
So a good external harness should sit at a level of abstraction that survives underlying capability changes.
That is also why tool-specific hacks deserve suspicion.
The closer your workflow is tied to a temporary limitation of today's agent, the more likely it is to age badly.
Patterns, clean code and documentation become context infrastructure
This also connects to something broader.
A well-structured codebase is itself part of the harness.
Clean boundaries make investigation easier.
Recognizable patterns communicate intent.
Consistent naming reduces ambiguity.
Tests provide executable feedback.
Architecture records preserve decisions.
Good documentation captures what cannot easily be inferred.
These practices were valuable before AI.
Now they also improve the environment in which agents operate.
A messy codebase does not just increase cognitive load for developers.
It forces agents to spend more effort rebuilding context before they can safely act.
The better the structure, the more of the agent's capacity can be spent on the actual problem.
Agentic development is no longer mysterious
When coding agents first appeared, explaining their inner loop was itself valuable.
The transition from:
“AI gives me code”
to:
“AI works inside my system”
was significant enough to deserve explanation.
That transition has largely happened.
Tool use is no longer surprising.
Repository context is expected.
Autonomous editing is normal.
Agents interacting with external systems is becoming normal.
So the interesting question has changed.
It is no longer:
What is an agentic inner loop?
It is:
How should we engineer around an inner loop that is becoming more capable every week?
My answer today is much simpler than it would have been when this transition began.
Know the tool.
Keep up with its capabilities.
Build good systems around it.
Preserve useful context.
Make your codebase understandable.
Encode the things that are specific to your organization.
And resist the temptation to reproduce generic intelligence outside an agent that is getting better at that job continuously.
Closing principle
Agentic development changed software engineering because the AI stopped merely answering questions and started acting inside the environment where the work exists.
Context, reasoning and tool use created an inner loop capable of turning intent into implementation with increasingly little human intervention.
That inner loop will keep evolving.
We should understand it.
We should use it.
But we should be careful about competing with it.
The durable engineering opportunity is outside the loop:
Give capable agents the context, constraints and environment they need to work effectively in your world — and let their internal machinery keep getting better.
Know the inner loop.
Build around it.
Don't fight it.