It occurs to me that we may not have been clear about what we mean by low overhead.
We do not mean less rigor.
We do not mean fewer checks.
We do not mean skipping validation.
And we do not mean a smaller version of the same large agent architecture.
What we mean is more specific:
the diagnostic state does not have to live inside the coding agent.
That distinction matters.
The common assumption
A lot of current AI coding work starts from a very understandable assumption:
the coding agent needs to understand the repo before it can safely patch the repo
So the surrounding system gives the agent more support.
More project context.
More repository instructions.
More tool access.
More memory.
More feedback loops.
More orchestration.
That direction makes sense if the agent is expected to discover the system for itself.
A coding agent is often described as a model wrapped with tools, memory, environment feedback, and control flow. The surrounding system manages context, prompts, tool use, state, and verification.
We can see the same trend in things like AGENTS.md, which is described as a predictable place to give coding agents project context and instructions before they work. AGENTS.md describes itself as a README for agents.
OpenAI’s Codex documentation also describes AGENTS.md as a way to give Codex extra instructions and context for a project. Codex reads AGENTS.md files before doing work.
Again, none of that is unreasonable.
If the agent has to wander through the repo, infer the architecture, remember what it saw, and then patch from that inferred model, it needs help.
But that raises a different question.
Does the agent need the whole repo?
Does a coding agent really need to understand the entire repo?
Or does it need to know the exact boundary it is working inside?
Those are not the same thing.
A complex repo is not just a pile of files.
It is a system of ownership boundaries.
This layer owns setup state.
This layer owns serialization.
This layer owns code generation.
This layer owns lifecycle handling.
This layer owns dependency ordering.
This layer owns platform integration.
This layer owns protocol shape.
When a bug appears, the useful question is not only:
where did the error show up?
The better question is:
which boundary made this failure possible?
If that boundary can be diagnosed before the coding agent starts working, the coding task becomes much smaller.
The agent does not need to carry the repo.
It needs the repair lane.
Another kind of overhead
There is another overhead problem too.
Some systems try to understand complex software by reconstructing architecture from the target system’s own implementation language or technology stack.
That can get heavy quickly.
In polyglot systems, architecture reconstruction often has to deal with different languages, different frameworks, different build systems, different dependency models, and different conventions.
One recent paper on polyglot and multi-repository architecture reconstruction describes using technology-specific modules called “extractors,” then merging their outputs into a unified model. It also notes that existing approaches can run into technology limitations, mono-repo constraints, and high implementation barriers. Distributed Architecture Reconstruction of Polyglot and Multi-Repository Microservice Projects
That is a real engineering problem.
But it is not the only possible model.
What low overhead means here
When we say low overhead, we are pointing at a different architecture.
Scarab’s diagnostic core is Python/JSON.
It does not need to become JavaScript to work against a SvelteKit issue.
It does not need to become Rust to work against a pnpm path.
It does not need to become Go to reason about Prometheus.
It does not need to become C# to reason about LEAN.
The diagnostic layer stays stable.
JSON matters here because it is a lightweight, text-based, language-independent format for structured data. RFC 8259 defines JSON as a lightweight, text-based, language-independent data interchange format.
That means the diagnostic evidence can be represented outside the target repo’s implementation language.
The target repo may be JavaScript, Rust, Go, C#, Java, Python, or a mix of all of them.
The diagnostic substrate does not have to change.
What the repo-native tools are for
This does not mean repo-native tools do not matter.
They matter a lot.
But they are downstream.
They validate the repair inside the repo’s own world.
That means:
text
test
lint
build
typecheck
focused regression
Those checks matter because they prove the patch still coheres with the target repo after the repair is made.
But they are not the thing producing the diagnostic boundary.
That is the distinction.
The repo-native tools validate the movement.
They do not have to generate the diagnostic state.
Why this changes the agent’s job
If the diagnostic layer has already surfaced the repair boundary, the coding agent does not need to build a private theory of the whole repo.
It does not need to remember a long wandering journey through the codebase.
It does not need to summarize its own exploration and then patch from that summary.
It receives a bounded repair problem.
The coding work becomes:
implement the bounded fix
add or update the regression
run the repo-native checks
stop
That is a much smaller job.
It is also a more appropriate job for a coding agent.
The model is very good at implementation once the boundary is clear.
The expensive part is letting the model discover the boundary by approximation.
The repair packet question
Some agent systems also try to produce a repair packet.
That is useful.
But the source of the repair packet matters.
If the repair packet is produced by the agent’s own exploration, then the chain is still:
agent approximates repo
agent summarizes approximation
agent patches from approximation
That can work.
But at scale, approximation creates drift.
The more efficient path is to produce diagnostic evidence outside the coding agent before patching begins.
Not because the agent is weak.
Because the agent should not have to become the system in order to repair one boundary inside the system.
A plain office analogy
Imagine walking into work.
On one desk, there are seven old folders, three handwritten notes, two conflicting summaries, a stack of forwarded messages, and someone saying:
“Just read through all of this and figure out what the job is.”
On the other desk, there is one clean assignment:
Here is the problem.
Here is where it belongs.
Here is the evidence.
Here is the boundary.
Here is how we will know the repair worked.
Most people would rather start with the second desk.
That is the point.
The worker does not need the entire office history to do one bounded job.
They need the right assignment.
The actual claim
Low overhead is not less process.
It is not less rigor.
It is not “just trust the AI.”
It means:
Python core
JSON evidence
bounded repair lane
repo-native validation
small patch surface
The goal is not to recreate the repo inside the agent.
The goal is to produce enough diagnostic evidence that the agent does not need to.
That is why the resulting patches can stay small.
That is why token use can stay low.
That is why a fresh agent should be able to enter the same workspace, receive the same diagnostic evidence, and make the same repair direction without carrying a memory trail from the previous session.
The diagnostic state is not inside the agent.
The diagnostic state is externalized before the coding starts.
That is what we mean by low overhead.
Closing thought
AI coding agents are going to keep getting better.
The question is not whether they can write code.
They can.
The more interesting question is how much system understanding we should ask them to carry.
Maybe the best coding-agent workflow is not the one that gives the agent the biggest memory.
Maybe it is the one that gives the agent the least it needs to remember.
Find the boundary.
Hand over the evidence.
Patch the boundary.
Validate in the repo’s own world.
That is the operating model.
Top comments (0)