2026 Agents Case Study Series Logo
How auditing changed the way I worked with coding agents
Never trust that the agent will always be right. Build a process capable of finding out when it’s wrong.
In the previous article, I explained how I used AI to develop prototypes and consolidate them into single files that could be inspected, transferred, and eventually integrated into larger systems.
By the end of that process, I had an A.I.N.D.Y. Core Loop prototype.
A single-file implementation of a proposed execution system containing flows, nodes, state, events, memory, strategy, and governance.
ChatGPT could reason about the design because we’d developed it throughout the conversation.
But the prototype hadn’t yet been integrated into the actual A.I.N.D.Y. repository.
And the architecture we’d developed in conversation still needed to be compared against what I’d already built.
So I moved the work into a different environment.
Comprehensive Review
The handoff happened inside the same Claude conversation that had just helped me finish Nodus V1.
Claude asked whether I wanted to return to A.I.N.D.Y.
I answered with two words:
Comprehensive review.
That request started another audit.
But it also became the point where months of conversations, prototypes, architectural decisions, and existing implementations began coming together inside the actual codebase.
At the time, I was still using the workflow I’d developed while building Nodus.
Claude Chat helped me think through the work and prepare assignments.
Claude Code operated on the repository.
And I moved information between them.
Claude Chat had the conversational history. It knew how we’d approached the Nodus audits, what questions we’d been asking, and how we’d organized the work into phases.
Claude Code had something different.
It could inspect the actual files.
It could search the repository, compare implementations, examine dependencies, run tests, and report what the code was doing.
So Claude would help me create an audit prompt.
I’d take it to Claude Code.
Claude Code would examine the repository and return its findings.
Then I’d bring those findings back to Claude to interpret them and determine what should happen next.
It worked.
But I was still acting as the connection between the two systems.
The Memory Bridge
The comprehensive review gave us a concrete place to begin.
The Memory Bridge.
Memory had been part of the A.I.N.D.Y. concept for a long time.
But the repository didn’t contain one coherent memory system.
It contained evidence of different implementations and experiments that had accumulated as the project evolved.
And that’s an important. Because If I explained what I thought the Memory Bridge was supposed to do, an AI could reason about that description.
If I provided one implementation, it could examine that implementation.
But Claude Code could inspect the repository and compare the different pieces against one another.
It could ask which implementation was actually being used.
Where information was being stored.
Whether that information could be retrieved.
And whether the different parts of the system were even connected properly.
That exposed something conversational explanations could easily miss.
Having code related to a capability doesn’t necessarily mean the system actually provides that capability.
And in the case of the Memory Bridge, I was about to learn that the distinction went even further.
Learning What I’d Actually Built
There’s something important about this audit that I haven’t fully explained.
I wasn’t simply asking Claude Code to find problems in the Memory Bridge.
I was trying to understand what I’d actually built.
For a long time, I’d been thinking about the Memory Bridge as the memory for A.I.N.D.Y.
But as I reviewed my old conversations, examined the architecture audits, and worked through the implementation with Claude Code, I started understanding that its responsibility was more specific than that.
It wasn’t simply a storage layer.
It was supposed to be a memory orchestration system.
A system responsible for persistence, recall, and feedback as part of AI execution.
The goal was to enforce contextual continuity, preserve authorship and identity, and improve execution through feedback-driven recall.
And that mattered. Because if I thought the Memory Bridge was simply responsible for storing memories, I could test whether it saved information and retrieved it later.
But that wouldn’t necessarily tell me whether it fulfilled its actual purpose.
The audit wasn’t just about finding what was wrong. It was about determining whether the implementation did what I thought it was supposed to do.
And when it didn’t, defining what needed to change.
That’s what made the Memory Bridge work so important to how I was learning to use coding agents.
Mapping the Repository
The next important shift came through testing.
Before making changes to the Memory Bridge, Claude Code established a baseline of what already worked.
Then the architectural questions became testable requirements.
The diagnostic suite reported 135 passing tests and eight intentionally failing tests.
Those eight failures weren’t regressions introduced by the repair work.
They represented behaviors the audit had identified as missing.
And that changed how we could approach the implementation.
Instead of simply asking Claude Code to build the Memory Bridge I’d described in conversation, we could establish what the actual repository needed to do.
Then use tests to determine whether those behaviors had been implemented.
The work was divided into three phases.
Phase 1 — Make It Real.
Phase 2 — Make It Intelligent.
Phase 3 — Make It Useful.
Each phase addressed a different part of the problem.
And the tests continued growing alongside the implementation.
The reported totals progressed through 338, 362, and eventually 384 passing tests with zero failures.
Now, those numbers didn’t prove that the Memory Bridge was perfect.
They didn’t establish that every possible failure had been accounted for.
But they provided evidence for more specific claims.
That the implementation was being evaluated against behaviors we had identified as important.
And that those behaviors were becoming part of the repository’s test suite.
Trust Accumulates
This was where I began trusting the work Claude Code was doing more.
But not because Claude Code was especially persuasive.
I’d already seen how easily an AI could explain a system with more confidence than the implementation justified.
What mattered was that the work was increasingly being checked against evidence.
Claude Code could inspect the relevant files before making changes.
It could run tests after completing a phase.
It could identify failures, investigate their causes, and correct the implementation before continuing.
And the repository itself provided constraints that weren’t dependent on how confidently the agent described its work.
The tests had to pass.
The database models and migrations needed to agree.
The implementation needed to fit the existing services.
And the documentation needed to reflect what had actually changed.
That didn’t eliminate the possibility of mistakes.
But it gave me a process for identifying them.
And something else was happening at the same time.
Claude Code was helping me learn more about my own architecture.
It wasn’t just taking instructions and returning completed work.
It was examining the system, explaining what it found, comparing those findings with what I thought should exist, and helping me understand where the implementation differed from the intended design.
Sometimes that meant identifying a technical problem.
Other times, it meant helping me understand a responsibility or relationship within the system that I hadn’t fully recognized before.
The audit was becoming part of the learning process.
And that began changing where I wanted to have those conversations.
Architectural Assistance Moved Into the Terminal
I didn’t wake up one morning and decide I was finished using Claude Chat to manage development.
It happened gradually.
I’d spend long stretches working with Claude Code.
We’d examine something in the repository, discuss what it meant, decide what needed to change, and continue working.
Then, eventually, I’d return to Claude Chat.
And I’d realize I hadn’t brought any of those developments back.
So now I had to catch Claude up on where the project was.
Which was funny, because the whole reason I’d been using Claude Chat was to help me understand the project and decide what to do next.
But I was already doing that with Claude Code.
Claude Chat had been particularly useful because of the questions it asked before generating implementation assignments.
What was I trying to accomplish?
Which risks mattered?
What needed to be analyzed first?
What constraints should the implementation follow?
I’d found that kind of interaction useful while working toward Nodus V1.
But Claude Code could ask questions, too.
It could help me reason through the architecture.
It could examine a proposed implementation plan.
It could identify dependencies, question assumptions, and suggest alternatives.
And it could do those things while looking at the actual repository.
That was the difference.
I didn’t need to explain what I thought a particular component did and wait for the model to reason from my description.
The agent could inspect it.
If I wanted to understand how a component interacted with another part of the system, we could search the code.
If a proposed change conflicted with an existing implementation, the agent could identify that conflict before making the change.
And if we decided to implement something, we could test the result without moving the discussion into another environment.
The conversation hadn’t disappeared. It had moved closer to the work.
And the more I worked that way, the less useful it became to carry every decision and completion report back to a separate conversation.
Do the Work Where the Work Exists
I didn’t completely stop using conversational AI for development.
I still found it useful for exploring uncertain ideas, working through larger questions, and prototyping systems before they existed in a repository.
That’s largely how I separate the environments now.
When I’m trying to understand what something could be, a conversation can be a useful place to explore the possibilities.
But once the work exists in a repository, I increasingly prefer working with an agent that can inspect that repository directly.
Because then the discussion isn’t limited to what I remember, what I’ve uploaded, or what the model believes the implementation should look like.
We can examine what actually exists.
And that led me to a simple principle.
Do the work where the work exists.
If I’m exploring an idea, the work might exist in the conversation.
If I’m modifying a repository, the work exists in the codebase.
If I’m investigating database behavior, then the implementation needs to be checked against the database and its actual state.
And if I’m making claims about how something executes, those claims eventually need to be tested in an environment where the execution can happen.
That doesn’t mean the agent automatically understands everything because it has access to the repository.
It can still miss things.
It can still misunderstand the architecture.
And it can still make incorrect changes.
But now the conversation can be checked against the system being discussed.
And that changes the relationship.
The Prompt Stopped Being an Order
As this working style matured, my prompts changed, too.
They became less about telling an agent exactly what code to generate and more about defining the conditions under which the work should happen.
Read these files first.
Establish the baseline.
Preserve this architectural constraint.
Run the tests after each phase.
If the implementation contradicts an assumption, stop and investigate.
Document the changes.
Don’t continue until the acceptance criteria have been satisfied.
Those instructions weren’t meant to predetermine every implementation detail.
They established boundaries.
They defined what evidence I expected.
And they gave the agent room to investigate whether my assumptions were correct.
Because here’s the thing.
I can be wrong about my own system, too.
That’s part of what the Memory Bridge audit had demonstrated.
I thought I understood what I’d built.
But reviewing the history and implementation showed me that some of the responsibilities were different from how I’d been thinking about them.
So if I gave an agent an instruction based on an incorrect assumption, I didn’t necessarily want it to follow that instruction blindly.
I wanted it to investigate.
I wanted it to tell me when the implementation contradicted what I was asking.
And I wanted the decision about what should happen next to be based on that evidence.
The prompt provided direction.
The repository provided evidence.
The tests helped validate the implementation.
And I retained responsibility for deciding which changes belonged in the system.
What I Actually Trust
That brings me back to something I said at the beginning of this article.
Never trust that the agent will always be right. Build a process capable of finding out when it’s wrong.
Now, you might have noticed something.
I haven’t spent much of this article talking about the AI being wrong.
And that’s because I don’t approach development by asking whether the agent is going to make a mistake.
Of course it will.
What I’ve spent this article explaining is how I decide whether I have enough reason to trust the work it produces.
I don’t simply trust the agent because it tells me something is finished.
I want to know whether the implementation has been checked against the architecture.
Whether the tests validate the behavior I actually care about.
Whether the repository’s requirements have been satisfied.
Whether the implementation fits the rest of the system.
And whether the evidence supports what the agent claims it accomplished.
That’s what I’m trying to establish.
Not certainty.
Confidence supported by a process I can inspect.
And I’m not saying that process guarantees the code is perfect.
It doesn’t.
Have I found things that were implemented incorrectly?
Absolutely.
But I’ve also had agents identify problems that earlier agents missed.
That’s part of the tradeoff.
When you’re building an entire system, things get overlooked. Assumptions turn out to be wrong. Tests miss behaviors they were never designed to cover.
Hell, you can build an entire programming language and go a month without discovering that it doesn’t work on someone else’s machine.
I know because that’s exactly what happened with Nodus.
And that doesn’t mean the work was worthless or that the verification process had no value.
It means I’d discovered another thing the process needed to account for.
So my concern isn’t whether the agent might be wrong.
I already know that’s possible.
The question I keep coming back to is whether I’ve done enough to have confidence in what I’ve built.
What’s Next?
If you’re new to the series, you can catch up on the story so far:
- Article 1 — I Created a Coding Language — How a simple question to ChatGPT became a programming language experiment, and what happened when I let Codex work on it overnight.
- Article 2 — Chat Was Control — How I began directing Codex through persistent project documents, implementation constraints, and a manual agentic workflow.
- Article 3 — What a Version Promises — How architecture analyses, version control, and AI-assisted evaluation began changing the way I preserved and verified agent-generated work.
- Article 4 — I Built My Own n8n — How an automation question led me to build a runner with Gemini, question its place in my architecture, and begin integrating it into A.I.N.D.Y. with ChatGPT and Codex.
- Article 5 — It’s Just a Conversation — What working across different AI systems taught me about context, tools, execution environments, and why the model alone doesn’t determine what an AI can accomplish.
- Article 6–1 Week to Vibe Code V1 — How my attempt to finish Nodus in a week led me from Codex to Claude Code and helped turn conversational testing requirements into enforceable engineering practices.
- Article 7 — Discovering The Arcitecture — How Gemini, ChatGPT, and Codex helped me discover where the Nodus Runner belonged and begin defining the execution architecture A.I.N.D.Y. needed.
- Article 8 — Prototyping with AI — How I developed a repeatable AI-assisted prototyping method, used single-file implementations to preserve architectural ideas, and worked with coding agents to translate those ideas into existing software.
By this point, working directly with Claude Code had changed how I approached development.
I was no longer relying on a separate conversation to interpret every implementation report. I could discuss the architecture, investigate the repository, make decisions, and verify the results within the same working environment.
And the Memory Bridge audit had helped me establish something important.
I didn’t need to assume the agent was right. I needed a process that gave me enough evidence to decide whether the work met my standards.
But there was still another challenge waiting.
The Nodus Runner and A.I.N.D.Y. Single File Engine had been developed through conversations with Gemini and ChatGPT. They demonstrated different parts of an execution system, but they were still prototypes.
Now those ideas needed to become part of A.I.N.D.Y.’s actual architecture.
In the next article, I’ll explore how Claude Code helped me separate the responsibilities of those prototypes, identify which mechanisms belonged in the existing application, and turn their architectural concepts into a persistent execution system without simply copying the original implementations.
The next installment of the 2026 Agents Case Study Series is coming soon.
Explore the Projects
The systems discussed throughout this series are part of the Masterplan Infinite Weave ecosystem. While not every project has appeared in the story yet, you can explore the technology, examine the source code, and follow its ongoing development.
- Nodus — The programming language that began as the experiment documented in this series. Explore Nodus
- A.I.N.D.Y. Runtime — The governed execution substrate supporting workflow orchestration, persistent execution, memory, and agent coordination. Explore A.I.N.D.Y. Runtime
- A.I.N.D.Y. Platform — The application platform built on the runtime, bringing the underlying capabilities into usable applications and interfaces. Explore A.I.N.D.Y. Platform
- Masterplan Infinite Weave — The broader ecosystem connecting these projects and their ongoing development.
Previous Work
This series builds on the ideas, experiments, and lessons documented in my earlier work.
- 2025 ChatGPT Case Study Series — The original exploration of learning, building, and executing through sustained human-AI collaboration. Read the Series
- 2025 Duality of Progress Series — An exploration of the relationships between constraints, creativity, iteration, and progress. Read the Series
Originally published at https://www.linkedin.com.
Top comments (0)