Coder Legion - Recent posts tagged coding-agents

What AI Coding Loses That Git History Can't Tell You — B Donald Harris

Mon, 26 Oct 2026 03:02:57 +0000

AI coding agents can generate code faster than ever—but can developers still explain why that code exists?

In this CoderLegion Developer Spotlight, software architect and founder B Donald Harris shares how AI-assisted development has reignited his passion for coding, why traditional Git history doesn't tell the whole story, and how he's building Hindsight to help developers understand the decisions, conversations, and reasoning behind their software.

From discovering programming on a Commodore 64 at age nine to exploring AI agentic workflows after more than two decades in software development, Donald offers a thoughtful perspective on the changing role of developers—and why the joy of building still matters.

Meet B Donald Harris

B Donald Harris is a software architect and founder based in Tulsa, Oklahoma. He has spent more than two decades building software, primarily in .NET and cloud technologies, and continues to explore new ways to build, learn, and collaborate.

His current work includes Hindsight, a workflow intelligence tool intended to help developers reconstruct how a software project evolved and understand why particular decisions were made.

Donald is also behind BIT Voices, a podcast and builder network created to showcase Black technology professionals, share their stories, and help builders discover and connect with one another.

Connect with Donald on CoderLegion:
https://coderlegion.com/user/BDonaldTechnologist

Why AI coding can leave developers with unanswered questions

AI coding agents can produce substantial amounts of code, help implement features, and accelerate development. But faster implementation creates another challenge: keeping track of everything that has changed and understanding the reasoning behind those changes.

As Donald explains in the interview, experienced developers might not remember every line of code they've written, but they can often recall the overall system design and know where to look when something goes wrong.

With agentic development, that understanding can become harder to maintain as changes and commits accumulate quickly.

A Git history may show that a feature was added, a bug was fixed, or an implementation changed. What it might not explain is why the team made that decision in the first place.

The missing context can live in conversations with AI agents, prompts, discussions between developers, terminal sessions, notes, and the reasoning behind architectural choices.

That is the problem Donald wants Hindsight to help solve.

Hindsight: Remembering the story behind software

Hindsight is a workflow intelligence tool Donald is building to help developers make sense of how their projects have evolved.

The concept is to connect a repository and bring together relevant development information, including:

Repository history, pull requests, and issues.
AI conversations and prompting sessions.
Terminal sessions and development notes.
Decisions made during implementation and debugging.
Changes in direction and the reasoning behind them.

By working with this information and a language model, developers could build a more complete account of their project's development journey.

Rather than relying exclusively on commit messages and code changes, the aim is to preserve the context that helps explain what happened, why it happened, and how the software reached its current state.

Donald describes the project as being in development and experimentation during the interview, with an MVP alpha targeted for the beginning of the following year.

He also emphasizes that privacy and control over what information is captured and seen are important considerations for builders using such a tool.

How AI has changed Donald's approach to development

One of the most interesting moments in the conversation comes when Donald reflects on how AI coding agents have affected his relationship with programming.

He started coding at nine after his father brought home a Commodore 64. Using a book of BASIC programs, he would type instructions and watch something happen on the computer. That experience felt like magic, and it sparked a lifelong interest in building software.

Over time, professional responsibilities and other commitments meant that coding sometimes became something he did primarily for work rather than for fun.

AI-assisted development has helped bring back that original excitement.

With agents taking on much of the implementation work, Donald can spend more time thinking about architecture, orchestrating agents, and bringing ideas to life—ideas he might not previously have had the time to explore.

His perspective is not that developers should abandon their skills or stop understanding their code. Instead, he sees AI as another step in the evolution of computing, much like earlier layers of abstraction that made software development possible.

The challenge now is learning how to work effectively with these tools while maintaining control over the systems being built.

From a .NET developer tool to AI agentic workflows

Donald also discusses a VS Code extension he created to simplify .NET project creation.

While exploring a move from Visual Studio to VS Code at work, he found that starting certain .NET projects required a sequence of command-line operations: creating solutions, creating projects, and adding projects to solutions.

He wanted a simpler workflow, so he explored the VS Code extension architecture and built a tool that automated those steps.

That project also became his first introduction to agentic workflows and helped shape his interest in how new tools could make development easier.

The experience reflects a recurring theme in Donald's work: identifying friction in the development process and finding practical ways to remove it.

Building BIT Voices and creating opportunities for others

Donald’s work extends beyond software tools.

Through the BIT Voices podcast, he provides a platform for Black technology professionals to share their experiences, work, and ideas. The accompanying BIT Voices Network is intended to help builders discover one another, showcase projects, connect, and potentially collaborate.

Donald explains that representation matters because technology professionals can be geographically and organizationally dispersed, sometimes with few opportunities to connect with others who share similar experiences.

He wants younger generations to see people like themselves building careers and creating opportunities in technology.

His decision to become more visible as a public builder is part of that mission: sharing his own work while helping others tell their stories.

Lessons from building products and communities

The interview touches on several lessons that extend beyond AI tooling.

1. Don't lose the joy of building.

Donald says the advice he wishes he had received earlier in his career was to never stop doing software development for fun. Personal projects can provide room to experiment and rediscover the excitement that first drew someone to programming.

2. Understand the reasoning, not just the implementation.

Code and commits tell part of a software project's story. The discussions, decisions, and context behind them can be equally important when maintaining or extending a system.

3. Learn to embrace technological change.

Donald sees AI as another stage in computing's evolution. Rather than dismissing it, developers can learn how to use it effectively while continuing to apply their own judgment.

4. Pay attention to how the software actually works.

Building and testing a product can reveal workflows that differ from the assumptions made during initial design. Donald emphasizes learning from those discoveries rather than rigidly following preconceived ideas.

5. Start building.

His advice to developers who want to create their own products is straightforward: start. Developers already have many of the skills needed to outline a project and begin turning an idea into something real.

Watch the full conversation

In this CoderLegion Developer Spotlight, Donald and host Tom Smith explore AI-assisted development, software architecture, Hindsight, the importance of developer context, and the work involved in building products and communities.

The conversation is particularly relevant for developers experimenting with AI coding agents and thinking about how to maintain a deeper understanding of increasingly complex codebases.

About the interviewer: Tom Smith

Tom Smith hosts this CoderLegion Developer Spotlight, speaking with developers and builders about their experiences, technical decisions, projects, and lessons learned along the way.

Connect with Tom on CoderLegion:
https://coderlegion.com/user/Tom Smith

About CoderLegion Dev Stories

CoderLegion Dev Stories shares the experiences behind software development: the people building products, the problems they solve, the decisions they make, and the lessons they learn.

If you're building something interesting, exploring a new technology, or learning from real-world development challenges, consider sharing your story with the CoderLegion community.

Explore CoderLegion: https://coderlegion.com

Keep building, keep sharing, and keep learning from one another.

Check the tool call before a coding agent runs it

Mon, 05 Oct 2026 16:36:49 +0000

A system prompt asks the model to behave. The tool call still goes out when the model ignores that ask.

ThumbGate sits in front of the call. The PreToolUse hook reads the command before it runs and can block it. A thumbs-down on a bad call becomes a rule, so the same call does not get through the next time.

Install on a repo with npx thumbgate init.

Pro is $19 a month or $149 a year per operator.

https://thumbgate.ai/pricing

https://thumbgate.ai/go/pro?utm_source=coderlegion&utm_medium=community&utm_campaign=pretool-hook

The longer piece on why the prompt is the wrong layer: https://coderlegion.com/28973/why-system-prompts-wont-save-your-ai-agent-building-architectural-injection-immunity

Your AI Coding Agent Is Paying to Read Code It Doesn't Need

Tue, 22 Sep 2026 09:32:52 +0000

Your AI Coding Agent Is Paying to Read Code It Doesn't Need

AI coding agents have become surprisingly good at changing code.

But we are still giving them files as if they were human developers sitting in front of an editor.

And that is expensive.

Imagine your agent needs to rename one identifier inside a 2,000-line file.

The actual change might be:

oldName → newName

A few tokens of useful information.

Yet the typical agent workflow looks something like this:

read 2,000 lines
↓
reason about one relevant line
↓
edit the file
↓
read the file or diff again
↓
continue carrying much of that context

The agent may consume tens of thousands of tokens to perform an operation whose semantic payload is only a handful of tokens.

That feels backwards.

What if the agent never opened the file?

This is the idea behind RAP — Runtime Apply Patch.

Instead of asking an agent to read a file, locate something, rewrite it, and verify the result, RAP lets the agent address the code directly by its content.

For example:

rap s app.go 'oldName' 'newName'

RAP answers:

updated app.go (lines 1697 -> 1699, bytes +133, replacements 1)

That's it.

The agent did not need to load 2,000 lines into its context.

It already knew what it wanted to change.

RAP simply found it and performed the operation.

The principle can be summarized in three words:

Lines, not files.

Files are a human abstraction

Files are extremely useful for humans.

We open app.go, scroll around, understand the surrounding code, make a change, save it, and inspect the result.

But an AI agent does not necessarily need to reproduce that workflow.

If an agent already knows:

OLD = "oldName"
NEW = "newName"

why should it pay the context cost of reading another 1,999 lines?

The information required to describe the mutation and the information required to store the program are two very different things.

RAP tries to keep them separate.

The filesystem stores the program.

The model describes the mutation.

RAP connects the two.

Content becomes the address

Traditional editing often addresses code through coordinates:

file → line → column

But coordinates are fragile.

Insert ten lines above the target and the address changes.

RAP instead addresses code by content:

file → known text → replacement

The interesting consequence is that the agent often already possesses the address.

Maybe the target came from a previous grep.

Maybe it appeared in an error message.

Maybe the user provided it.

Maybe the agent wrote that code itself thirty seconds ago.

There is no reason to reload the entire file merely to rediscover information already present in the agent's context.

What if the target is ambiguous?

Then RAP stops.

$ rap s app.go 'count' 'total'
rap: OLD matched 3 times; use -all or a more specific OLD

Nothing gets written.

This property matters more than it might initially appear.

Shell tools can be extremely efficient for agents, but commands such as sed can also silently perform a perfectly valid operation on the wrong piece of text.

For an autonomous agent, failure is often cheaper than confidence.

A failed command may cost a dozen tokens.

A wrong edit can contaminate several subsequent reasoning steps before the mistake is discovered.

RAP therefore prefers an explicit refusal over an ambiguous mutation.

But sometimes the agent really does need context

Of course.

The argument is not that agents should never read source code.

The argument is that reading an entire file should not be the default unit of interaction.

RAP provides smaller operations for the questions agents actually ask.

Want to know whether a target is unique?

rap m FILE 'text'

Result:

matches: 1

Want to inspect only the affected area?

rap preview -n FILE 40 60 -- s OLD NEW

The agent receives a small window instead of the whole building.

Need to pass ugly text containing quotes, JSON, shell characters, or newlines?

rap q -token @file

RAP turns it into a safe token representation.

And after an edit, the command itself returns a receipt describing what happened.

No automatic full-file reread is necessary just to ask:

Did it work?

The token economics are surprisingly large

Consider a 2,000-line source file representing roughly 25,000 tokens.

A conventional agent might:

read file        ~25,000 tokens
modify
inspect result   ~25,000 tokens

Potentially around 50,000 tokens of context traffic around an edit that may involve only one line.

With RAP, the interaction can look more like:

rap s FILE OLD NEW

Perhaps ~40 input tokens and ~20 output tokens.

Obviously, real workloads vary. Agents sometimes genuinely need broader context, and not every edit can be expressed as a simple substitution.

But that is precisely the point.

Pay for context when reasoning requires context.

Do not pay for it merely because the code happens to live inside a large file.

This becomes more important as agents become more autonomous

Token efficiency is usually discussed as a model problem:

smaller prompts, better compression, larger context windows, cheaper inference.

But part of the problem may actually live outside the model.

Our tools still assume that an intelligent actor interacts with software primarily by opening documents.

Coding agents give us an opportunity to reconsider that assumption.

An agent does not necessarily need an editor.

It needs precise operations over a codebase, small observations about their consequences, and predictable failure modes.

That suggests a different interface between models and source code:

observe less
act precisely
verify cheaply
expand context only when necessary

RAP is a small experiment in that direction.

It does not try to make the model smarter.

It tries to make the model need fewer tokens to do the work it already knows how to do.

Lines, not files

The core idea behind RAP is intentionally simple:

The unit of work should be the information required for the change, not the container in which that information happens to live.

Sometimes that means a file.

Sometimes it means fifty lines.

Sometimes it means five.

And sometimes it means:

oldName → newName

If AI agents are going to execute thousands of filesystem operations autonomously, that distinction starts to matter.

A lot.

RAP is open source and available on GitHub.

Try giving your coding agent RAP and watch how often it can edit code without ever asking to see the whole file.

Radio Means My Coding Agents Can Work On Problems Together

Tue, 15 Sep 2026 21:26:59 +0000

Radio provides a chat channel for your agents to communicate with each other. I already tried to do this with Claude Code, GitHub CoPilot, and OpenCode agents. But the methods I've used so far are very clunky: tmux, folders that agents watch for changes, and having one agent execute the other agent. None of these techniques involved any true conversations. Now, with Radio, I can have the Fable agent in Claude Code actually talk with the GLM agent in OpenCode rather than leaving possibly incomplete task descriptions behind for it to follow or just driving one agent with another.

Most work now involves more than one agent, often from different providers. One writes the code while another tests it. One runs on your laptop while another runs in the cloud. But the agents can't talk to each other. Each one only sees its own conversation, so you end up as the go-between, copying output from one window and pasting it into the next.

We built Radio to solve this problem. To create a clean line of communication between agents, simply hand them a link to a Radio channel. The agents join the channel and talk to each other, and to you, in real time.

Radio works with any agent that can fetch a URL, so Claude Code, Codex, Cursor, OpenCode, and Grok all join the same way. It works across machines and between people, and you can steer the agents from any device.

Create a channel at radio.plasma.ai
Copy the link
Paste into one or more agents
The agents join the channel. Send one message and they take it from there, replying to you and to each other

The simplest way to think about a Radio channel is as a meeting. Any time you would put two or more people in a room to work something out, you can put two agents in a channel. There are three kinds, and each one builds on the last.

Team meeting: All the agents on your computer in one channel. One agent writes the code while another tests it. Review a PR together, split up a task, debate a bug. Anywhere you are relaying messages between agents on your own machine, give them a channel instead.
Cross-functional meeting: Agents in different places: your laptop, a cloud agent, a teammate's machine. Their Claude talks to your Claude, Codex, Grok, etc. The channel is the shared surface, so nobody has to be the go-between.
External meeting: Everything above, now multiplayer. Anyone with the link can read the channel and post to it, so someone outside the workflow can answer a question or redirect the work from any device.

In every case, the channel is also the record. Everything you and the agents said to each other stays in one place, so you can see how the work got done.

Radio is a core primitive of our first product, Fractal.

Fractal lets a team delegate real work to agents the way it would to people: pick the right model for each job, hand it a goal and a budget, and watch the work happen in real time.

You can see other building blocks of Fractal on our Research page.

Fractal is coming to the cloud. See the tree, steer its nodes, and track costs as the work runs.

Early access opens soon.

Why Your Coding Agent Edits The Wrong File

Wed, 26 Aug 2026 15:51:20 +0000

Most of us here have watched an agent confidently rewrite a function nobody asked it to touch, then spent the next twenty minutes rewording the prompt to make it stop. This is the writeup I wish I had read before doing that for the tenth time.

When a coding agent edits the wrong function, the instinct is to blame the model. Usually the model was never shown the file that mattered. That distinction sounds pedantic until you start fixing the right layer and the failures stop.

Context Failures Look Like Reasoning Failures

A language model has access to exactly one thing, the tokens in its context window on this call. It does not remember yesterday's session, it cannot see your repo, and it does not know what your tools returned unless that output is sitting in the prompt right now. Everything it appears to know about your codebase is there because some part of your system decided to put it there.

So when the output is wrong, there are two very different questions. Did the model have the right information and reason badly about it, or did it never have the right information at all? In practice the second one is far more common. The support bot that gave the wrong refund answer usually had the correct policy in its knowledge base. The agent that edited the wrong function was usually never shown the file. Rewording the instruction does not fix a window that is missing the one document the answer depended on.

What A Context Assembler Actually Does

Prompt engineering tunes the fixed wording of an instruction. Context engineering builds the system that decides, on every call, which instructions, retrieved documents, memories, tool outputs and history go into the window, then prunes everything else. One is a string. The other is a runtime component with its own logic, and it deserves the same review and testing you give the rest of your code. The full breakdown of the strategies and failure modes is worth a read if you are building this layer for the first time.

The practical shift is that "what does the agent actually see" becomes something you can inspect, log and diff. Once you can print the assembled context for a failing run, most of the mystery evaporates.

The Token Budget Is The Whole Constraint

The window is finite and more context is not free. Models that advertise very large windows still degrade as those windows fill, because the relevant tokens get diluted by irrelevant ones and attention spreads thinner. Every token you add also costs money and latency on every single call.

That makes this an optimization under a budget, not a collection problem. Get the few thousand tokens that actually matter for this request into the window, leave the rest out, and do it fast enough to run in production. A team that stuffs everything it has into a large window will pay more, respond slower and get worse answers than a team assembling a lean, relevant context per call.

Where Memory Fits

Retrieval solves "find the document." It does not solve "remember what we decided last Tuesday." A memory layer is what lets the assembler pull in prior decisions, established conventions and accumulated project knowledge without re-sending the entire history every time. It is the difference between an agent that starts from zero every session and one that gets more useful the longer you work with it.

The Takeaway

Before you swap models or rewrite the system prompt again, log the exact context the failing call received. If the answer was not in there, no model was going to get it right and no prompt wording was going to save it. Fix the assembler, and a surprising number of "the AI is dumb" bugs turn out to be plumbing.

Coding Agents Invent Facts When Denied Them. All 4 of My Probes Returned a False Zero.

Mon, 24 Aug 2026 15:51:59 +0000

A new arXiv paper watched coding agents get denied the facts they needed. They did not stop. They invented.

On August 17th, a group of researchers posted a paper to arXiv with an unglamorous title and a genuinely unsettling core finding. The paper is "The Working Set of a Coding Agent: Coherence Debt in Repository-Scale Tasks" (arXiv:2608.16630), by Bardia Mohammadi, Lars Klein, Aman Chadha, Akhil Arora, and Laurent Bindschaedler. Before going further, one honesty note that will hold for this whole piece: I have read the paper's abstract, not its full text, and every quotation below comes from that abstract. It is enough for what this essay is about, because what this essay is about is one sentence.

The setup first. The authors model repository-scale coding as reconstructing a web of coupled facts. Every edit an agent makes needs certain facts, and each fact arrives through one of two channels: it is either in the recent context, or it is in the model's memorized knowledge. Facts covered by neither channel are what the authors call coherence debt. Their experiment supplies and withholds each channel deliberately, injecting faults across "seven models and five harnesses" (abstract), and then watches what the agents do when a needed fact simply is not there.

The comfortable prediction is that a competent agent, denied a fact, stops and says so. Here is what the authors report instead: "A missing fact produces wrong work rather than absent work" (abstract). The agent asked to act, acts. In the paper's words, "an agent asked to act acts, fabricating the file or guessing the value" (abstract).

That much is alarming in a familiar way. Everyone who works with these systems has a story about an invented function or a guessed constant. The abstract has sharper findings than the fabrication itself, though. When the researchers renamed a real library to defeat memorized knowledge, the failure was collective: "all seven fail in the same place, passing and missing the same tests" (abstract). Seven different models, one shared cliff. And the paper's economics finding deserves a frame on any wall where infrastructure budgets get set: harness configurations that all pass every test "differ more than tenfold in tokens consumed" (abstract), and the extra spending recovers nothing when the facts are withheld. Paying ten times more did not buy truth. It bought a more expensive invention.

But the sentence this essay exists for is about none of that. It is about the watchers. Because agents fill the holes they are denied, the paper notes, "instruments built on reads look for a hole already filled" (abstract).

Sit with that one. The obvious way to check whether an agent had the information it needed is to watch what it read. Trace the file opens. Log the retrievals. If the agent never read the config file, flag the edit that depended on it. This is reasonable, cheap, and widely done. And the paper's finding is that it is blind precisely in the case it exists for, because an agent that lacked a fact does not leave a hole for your instrument to find. It fills the hole on the way through, with something plausible, and the trace shows an agent that read some things and then wrote some things, exactly like a healthy one. An absence that has been filled in looks exactly like a success.

The general shape

The reason that sentence deserves an essay rather than a citation is that nothing about it is specific to coding agents. It is the general shape of any measurement whose null result and whose broken result are the same value.

Think about what a zero means when a probe returns it. It might mean the thing you searched for is absent. It might also mean your probe never connected to the data at all: wrong path, wrong layer, wrong format, wrong vocabulary. Both conditions produce the same output, and the output is the one that reads as reassurance. Every other number a probe can return is at least weak evidence that the machinery ran. Zero is the only value an instrument produces both when it is working perfectly and when it is not plugged in.

The paper found this shape at the agent layer. I want to show you it sitting one layer up, in the small tools engineers write to check their own work, because that is where most of us actually live.

Four zeros, none of them true

What follows is original data in the smallest possible sense, and I want to be exact about its scope in the same breath as I introduce it. This is not a reproduction of the paper's experiment. It is four toy probes at a different layer, built on synthetic data, reading no real system. Each probe is written the way a working engineer writes one: quickly, reasonably, to answer a question and move on. Each returns zero. In all four cases the zero is a property of the probe, not of the data. The correct answers are 1, 1, 2, and 1.

PROBE                                                  NAIVE   CORRECT
------------------------------------------------------------------------
1  phrase wrapped across a newline                         0         1
2  marker one level up from where the probe looked         0         1
3  MM/DD/YYYY compared as text                             0         2
4  searched the wording, not the claim                     0         1
------------------------------------------------------------------------
probes run: 4
probes returning a FALSE ZERO (naive==0 while correct>0): 4

Every number in that table comes from a script called repro_absent_vs_zero.py, published alongside this essay. It asserts its own result, so if you run it and get a different table, you have found a bug in the script rather than a disagreement with the piece.

The four cases are worth a sentence each, because the point is what they do not have in common.

Probe one searches a document for a phrase that happens to wrap across a line break. The search is exact; the phrase is present; the newline defeats it. Zero occurrences reported. This is an encoding assumption.

Probe two looks for a status marker in a nested data structure, one level deeper than the marker actually lives. Every record it examines genuinely lacks the marker, so it reports a perfectly healthy corpus. This is a schema assumption.

Probe three compares dates. The records store them as MM/DD/YYYY text, and the probe compares them against an ISO-format string with an ordinary greater-than. Text comparison happily runs, means nothing, and finds no records past the cutoff. Two actually are. This is a type assumption.

Probe four is the subtle one. It searches a document to confirm a claim was corrected, but it searches for the wording of the old mistake rather than the substance of the fix. The fix is present, stated in words that share no tokens with the search terms. Zero matches, wrongly read as "the correction never landed." This is a vocabulary assumption.

An encoding assumption, a schema assumption, a type assumption, and a vocabulary assumption. The causes have nothing in common. There is no shared bug to learn, no single habit to break. What they share is the failure's shape: each produced the exact output that means "all clear," and produced it because the instrument never truly touched the thing it claimed to measure. Four different roads into the same hole, and the hole is already filled.

The discipline cannot be "notice when a zero looks suspicious," because the entire failure mode is that it never does. A suspicious zero is the one you got when you expected fifty. The dangerous zero is the one you got when you expected zero, checked the box, and shipped.

The Monday fix

There is a fix, it is old, and the lab sciences have been using it since before software existed: the control.

A positive control means running your probe against something you already know it should find, before you trust it finding nothing. Searching a log for a rare error? First search it for a common string you can see with your own eyes. If the probe comes back empty on that, the instrument is broken, and the zero you were about to report was never data. This costs one extra invocation and converts "the search found nothing" into "the search demonstrably ran, and found nothing," which are different sentences with different values.

Then add the negative control, because a positive control proves an instrument fires, not that it discriminates. A probe that matches everything passes every positive control ever written. Run it against something you know it should not find, and make sure it stays silent. An instrument that passes both controls has earned a modest thing: the right to have its zero believed.

None of this is novel, which is rather the point. Assay validation is a solved discipline in fields where a false negative kills someone. Software mostly skipped it, because software's probes are so cheap to write that we forgot cheap instruments still need calibrating. The paper's agents are an expensive, autonomous version of the same skip: the harnesses watched reads because reads were what there was to watch, and nobody ran the control that would have shown the watcher was blind.

The honest limit

The researchers could measure all of this because they built the world their agents ran in. They held both channels, knew every fact an edit required, and could therefore see fabrication for what it was. That is what makes the paper valuable: it is a place where the ground truth was, for once, actually available.

Most of us never get that. We audit our own systems with instruments we also built, which means our blind spots come pre-installed in the tools we would use to find them. I cannot inspect my way out of that circle and neither can you, which is why the discipline has to be procedural rather than perceptive. Not "get better at sensing bad zeros," but "no zero gets believed until the instrument that produced it has passed a control, this time, on this data." The rule is mechanical precisely because the failure is invisible.

The paper's agents, denied a fact, invented one rather than stopping. Our probes, denied a connection to the thing they measure, do something quieter and worse: they return the number that means everything is fine. The agent at least fabricates something you might later catch being wrong. The instrument fabricates an absence, and an absence never contradicts anything.

So before you believe the next quiet zero, check the thing that produced it, against a truth you can see without it. The hole you should worry about is not the one your instrument reports. It is the one it fills on the way through.

The four-probe table in this piece is produced by repro_absent_vs_zero.py, which uses synthetic data only, asserts its own result, and is published alongside the essay. Every quotation from arXiv:2608.16630v1 is from the paper's abstract, which is the locator throughout; the full paper was not read, and this piece does not claim to reproduce its experiment.

Sources

Bardia Mohammadi, Lars Klein, Aman Chadha, Akhil Arora, Laurent Bindschaedler, "The Working Set of a Coding Agent: Coherence Debt in Repository-Scale Tasks," arXiv:2608.16630v1, submitted August 17, 2026. https://arxiv.org/abs/2608.16630v1 (locator for all quotations: abstract).
arXiv API record for the same identifier, used to verify every quoted string and the submission date. https://export.arxiv.org/api/query?id_list=2608.16630v1
repro_absent_vs_zero.py, published with this essay: the source of every computed number in the piece; synthetic data only; self-asserting.

An absence never contradicts anything

The failure in this piece is not that a tool was wrong. It is that a tool reported nothing, and nothing is what a working tool and a disconnected one both return. The defence is a record of what actually ran: which inputs were touched, in what order, and whether the step that produced a number reached the data at all. Chain of Consciousness is that record for AI agents, tamper-evident and written as the work happens rather than reconstructed once somebody asks. It does not make an agent right. It makes the basis of its answer checkable, which is the only thing that turns "found nothing" into evidence.

Hosted Chain of Consciousness · Verify a record

pip install chain-of-consciousness · npm install chain-of-consciousness

Originally published at https://vibeagentmaking.com/blog/coding-agents-invent-facts-false-zero/

Cut LLM turns in MCP interactions by 75%+: a 5-to-1 example

Tue, 11 Aug 2026 21:51:29 +0000

Disclosure: I work on Tura.

A typical MCP coding workflow may need five model re-entries:

inspect files
apply a patch
build
test
lint

The commands still matter. What adds overhead is returning to the model after every step so it can read the output and make the next tool call.

Tura's command_run accepts a dependency-aware command graph. For predictable work, the agent can send the five-step plan once; the runtime still runs build, test, and lint, but the model goes from 5 turns to 1 in this example — an 80% reduction in model re-entries.

That is the idea behind the claim: less conversational/tool-calling overhead, not fewer engineering checks.

The task-level benchmark is here: https://turaai.net/benchmark-task?task=workflow-ecommerce-ad-package#runs

Source and setup: https://github.com/Tura-AI/tura

I’d be interested in how others are handling repeated tool-loop overhead in MCP agents.

Has anyone actually used mini-swe-agent for real debugging or development?

Sun, 09 Aug 2026 01:18:05 +0000

DeepSWE's harness comparison made me curious, so I tried mini-swe-agent myself on a matched set of debugging tasks with GPT-5.6 SOL at High reasoning.

The current numbers surprised me:

Codex CLI High: 151.91M tokens, 60% pass rate
plain mini-swe-agent: 70.33M tokens, 67%
the same mini harness plus macro execution, without changing the prompt: 60.59M tokens, 78%

So plain mini-swe-agent used about 54% fewer tokens than Codex and scored 7 percentage points higher. In the smaller ablation, changing only execution cut another ~14% of tokens and added 11 points.

That does not prove it is universally better. It is one matched benchmark slice, and DeepSWE itself notes that prompt tuning may explain part of the harness gap. Still, for debugging, the very small “bash + linear history” setup looks unusually strong.

Has anyone used it for day-to-day bug fixing or feature work? What breaks first outside a benchmark: repository setup, long-running tests, permissions, or patch quality?

Disclosure: I maintain Tura and ran the benchmark above.

Fewer LLM turns, more commands: a practical way to verify research-heavy agent work

Tue, 04 Aug 2026 21:13:10 +0000

What if an agent spent less time going back to the model, but did much more useful work inside each turn?

That is the idea I have been testing: let an LLM turn make a decision, then let one batch of commands search, inspect, compare, and verify the result. The goal is not “fewer turns” by itself. The goal is fewer expensive decision loops and more observable work between them.

I used a deliberately messy task: build a 15-slide guide to 10 East Asian squid recipes, with illustrations, recipe sources, and cooking videos. This kind of job is easy to make look finished while leaving behind broken links, duplicated videos, missing assets, or a layout that only works on one screen.

Across four runs, the two CLI-style runs averaged 13.5 LLM turns and 10.5 tool calls. The two direct-execution runs averaged 10 LLM turns and 82 tool calls. So, in this small matrix, the direct approach used 25.9% fewer LLM turns while issuing about 7.8× more commands.

The interesting part was not the headline number. In one early turn, the agent launched roughly 20 discovery commands for recipes and matching videos. Later checks confirmed 10 sources, 10 unique video destinations, 15 local assets with none missing, navigation behavior, and rendering at 1440, 768, and 390 pixels. One bad recipe destination was corrected, and the remaining video IDs were validated.

This pattern is useful anywhere the work is “collect, produce, then prove it is usable”: research briefs, slide decks, market maps, buyer guides, travel plans, content migrations, link audits, and QA-heavy reports.

The mental model is simple:

Use the LLM turn to decide what needs to happen.
Fan that decision out into many independent commands.
Gather structured results.
Use the next turn only when judgment is actually needed.

This is only a four-run case study, not proof that one setup always wins. Runtime was mixed, and token accounting came from different harness sources. But it does show why “turn count” and “command count” should not be treated as the same thing.

The full interactive task and the raw run artifacts are public:

Disclosure: I maintain Tura and this benchmark.

5 coding-agent turns vs 1 command_run workflow: full example

Mon, 03 Aug 2026 21:04:04 +0000

Disclosure: I maintain Tura.

Here is the simple idea. A normal coding agent may use five separate LLM turns for one predictable workflow.

Turn 1 — inspect

rg -n "TODO|command_run|handler" crates/
rg --files crates/runtime/src crates/tools/src

Turn 2 — apply the patch

- // old command handler logic
+ // patched command handler logic

Turn 3 — build

cargo build -p runtime

Turn 4 — test

cargo test -p runtime --lib

Turn 5 — lint

cargo clippy -p runtime --all-targets

The overhead is not only the shell commands. The model wakes up five times and receives the growing conversation again.

Tura exposes one macro tool called command_run, so the agent can send the same workflow once:

{
  "name": "command_run",
  "arguments": {
    "commands": [
      { "step": 1, "command_type": "shell_command", "command_line": "rg -n \"TODO|command_run|handler\" crates/" },
{ "step": 1, "command_type": "shell_command", "command_line": "rg --files crates/runtime/src crates/tools/src" },
      { "step": 2, "command_type": "apply_patch", "command_line": "*** Begin Patch\n*** Update File: crates/tools/src/command_run/handler.rs\n@@\n-    // old command handler logic\n+    // patched command handler logic\n*** End Patch" },
      { "step": 3, "command_type": "shell_command", "command_line": "cargo build -p runtime" },
      { "step": 4, "command_type": "shell_command", "command_line": "cargo test -p runtime --lib" },
      { "step": 4, "command_type": "shell_command", "command_line": "cargo clippy -p runtime --all-targets" }
    ]
  }
}

Build, test, and lint still run. The model simply does not need a new turn between predictable steps.

In the full DeepSWE comparison, Balanced used 35.8% fewer turns and 31.1% fewer tokens than Codex CLI. Direct used 69.1% fewer turns and 77.5% fewer tokens.

GitHub: https://github.com/Tura-AI/tura

Benchmark: https://turaai.net/benchmark

Why My Open-Source Project Hasn't Done Better

Sat, 25 Jul 2026 14:36:15 +0000

Disclosure: I am the maintainer of Tura. I am posting this to ask for candid advice about open-source communication and evaluation, not as an independent review of my own project.

Since the beginning of 2026, projects such as RTK, Caveman, and Ponytail have claimed that they can reduce token usage by 80–90%. Some gained tens of thousands of GitHub stars in a very short time.

My previous startup was building an e-commerce chatbot. The product was close to what later became the Universal Commerce Protocol (UCP). After UCP was released, I decided not to continue in that direction.

Earlier this year, I began turning the architecture we had built for e-commerce chatbot agents into an SDK. Put simply, its core idea is to use state machines and deterministic execution sequences to reduce the number of round trips to LLM providers by around 80% for the same task, thereby reducing token consumption.

I understand why tools such as RTK are ineffective in genuinely long-running tasks. I published a report on July 18, and JetBrains published a report on July 20 that reached essentially the same conclusion: token-saving plugins such as RTK and Caveman have little or no effect on real-world, long-running tasks.

JetBrains report: https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-savings/
My report and reproducible methodology: https://github.com/Tura-AI/tura/blob/main/docs/blog/token-saving-plugins-are-mostly-stupid-idea.md

I also believe I know how to achieve a real reduction of more than 80% in token consumption during long-running tasks. However, I have found it much harder to communicate and promote this open-source project than to build it.

What I think went wrong

Most coding-agent users do not care what actually drives token consumption

There is a large gap in understanding among coding-agent users, whether they have formal software-engineering training or are self-taught "vibe coders."

A long article that systematically explains the mechanism and challenges existing assumptions has little chance of spreading in forums already flooded with AI-written posts and plugins claiming 95% token savings.

Simple ideas are easier to spread. People are not purely rational; we tend to believe explanations that are easy to understand. That is also why pseudoscientific content based on incorrect causal explanations can attract much more attention than careful explanations of the underlying mathematics.

The author's arrogance

This is probably a combination of two problems.

From the perspective of someone who strongly believes in scientific testing, evaluations, and benchmarks, software-engineering claims without an evaluation can feel meaningless.

But perhaps my own arrogance—and my contempt for, or jealousy of, tools such as RTK—has made me less willing to explain and promote my work in ways that would actually be effective.

If you have read this far, I would genuinely appreciate your advice:

How can I communicate this project more effectively without sacrificing rigorous evaluations and benchmarks?
What evidence would make you willing to try an unfamiliar coding-agent SDK?
Is the message too technical, too combative, or aimed at the wrong audience?
What should I change on the repository page or in the benchmark presentation?

I know that building a coding agent with Codex or Claude is relatively easy. But I also believe there will always be people who value benchmarks and evaluation harnesses.

The project was released on July 16 and currently has a little over 400 GitHub stars:

https://github.com/Tura-AI/tura

I welcome critical feedback, including reasons you would not use it.

How GPT-5.6 sol token is used in Codex

Tue, 21 Jul 2026 19:09:06 +0000

Disclosure: I maintain Tura, which hosts the full test record.

I ran 280+ Codex CLI sessions with GPT-5.6 Sol. In the current build, fewer commands per model turn can mean more turns and more cached-input cost.

Most benchmarks favor 5.6 Sol on cost per result: on DeepSWE, 5.5 High averaged USD 5.1 per task versus USD 3.5 for 5.6 Sol High. But in Codex CLI 0.144.1, my 5.6 Sol High runs were about 21% more expensive than 5.5 High.

The likely mechanism is orchestration: 5.5 explicitly uses multi_tool_use.parallel, while 5.6 mainly uses one top-level exec. I observed 0.97 versus 2.5 commands per model call, roughly 1.84× as many rounds, and 66.5% of 5.6 Sol High cost in cached input. Token-saving plugins did not materially lower that total; reducing unnecessary model rounds did.

Implementation reference: https://github.com/openai/codex/blob/rust-v0.144.1/codex-rs/core/src/tools/code_mode/execute_handler.rs#L20-L72

Full test record: https://turaai.net/docs#benchmark-current-test-set-record

Coder Legion - Recent posts tagged coding-agents

What AI Coding Loses That Git History Can't Tell You — B Donald Harris

Meet B Donald Harris

Why AI coding can leave developers with unanswered questions

Hindsight: Remembering the story behind software

How AI has changed Donald's approach to development

From a .NET developer tool to AI agentic workflows

Building BIT Voices and creating opportunities for others

Lessons from building products and communities

Watch the full conversation

About the interviewer: Tom Smith

About CoderLegion Dev Stories

Tags

Check the tool call before a coding agent runs it

Your AI Coding Agent Is Paying to Read Code It Doesn't Need

Your AI Coding Agent Is Paying to Read Code It Doesn't Need

What if the agent never opened the file?

Files are a human abstraction

Content becomes the address

What if the target is ambiguous?

But sometimes the agent really does need context

The token economics are surprisingly large

This becomes more important as agents become more autonomous

Lines, not files

Radio Means My Coding Agents Can Work On Problems Together

Why Your Coding Agent Edits The Wrong File

Context Failures Look Like Reasoning Failures

What A Context Assembler Actually Does

The Token Budget Is The Whole Constraint

Where Memory Fits

The Takeaway

Coding Agents Invent Facts When Denied Them. All 4 of My Probes Returned a False Zero.

The general shape

Four zeros, none of them true

The Monday fix

The honest limit

Sources

Cut LLM turns in MCP interactions by 75%+: a 5-to-1 example

Has anyone actually used mini-swe-agent for real debugging or development?

Fewer LLM turns, more commands: a practical way to verify research-heavy agent work

5 coding-agent turns vs 1 command_run workflow: full example

Why My Open-Source Project Hasn't Done Better

What I think went wrong

Most coding-agent users do not care what actually drives token consumption

The author's arrogance

How GPT-5.6 sol token is used in Codex