DEV Community: Shawn knight

2026 Agents Case Study Series: Wasn’t I Building An App?

Shawn knight — Thu, 12 Nov 2026 05:38:52 +0000

2026 Agents Case Study Series Logo

How auditing A.I.N.D.Y.’s existing subsystems led me to discover the runtime underneath the app

In the previous article, Where Does the Work Exist?, I explained how my development workflow gradually moved from conversational AI into the terminal.

I’d spent a considerable amount of time moving prompts from Claude Chat into Claude Code, then carrying implementation reports back into the conversation to decide what should happen next.

Eventually, I noticed I wasn’t doing that nearly as often.

Not because I’d stopped having architectural discussions, but because I was already having those discussions with Claude Code.

And unlike a chatbot working primarily from what I’d provided, Claude Code could inspect the repository while we talked.

That changed how I approached A.I.N.D.Y.

Instead of beginning with a feature request, I increasingly began with an audit.

What already existed?

What was actually implemented?

What did the repository say the system was doing?

And how did that compare with what I remembered building?

Those questions became especially important because A.I.N.D.Y. wasn’t an empty app waiting for me to introduce a new architecture.

I’d already spent months building it.

I Already Had an Application

Before I began integrating the Nodus Runner and Single File Engine, A.I.N.D.Y. already contained a collection of subsystems.

There was the Infinity Algorithm, supported by formulas intended to measure different aspects of performance and progress.

There was the Memory Bridge, which I’d originally thought of as the system’s memory before learning that its responsibilities were closer to memory orchestration: persistence, recall, routing, and feedback.

There was an AI SEO tool, RippleTrace for tracking articles and related activity, a DeepSeek-based code analyzer, and parts of a social media layer.

And there was Genesis, the MasterPlan component that helped users develop plans through conversational interaction.

Genesis had been one of my last significant non-agent development changes to A.I.N.D.Y.

So when I started returning to the application with coding agents, the objective wasn’t to replace everything.

It was to figure out what I already had, what was missing, what needed correcting, and how the different parts were supposed to work together.

Make It Real. Make It Intelligent. Make It Useful.

One of the earliest comprehensive audits had revealed substantial technical debt.

Some capabilities existed only partially. Others had competing implementations or weren’t properly connected to the parts of the application that were supposed to use them.

So before introducing the two larger prototypes, I spent time working through the existing subsystems.

The process generally followed three phases.

Phase 1 — Make It Real.

Determine whether the subsystem actually did what it was supposed to do.

Not whether a file existed with the correct name.

Not whether the implementation sounded reasonable.

Whether the behavior was actually there.

If something was missing, broken, or incorrectly connected, we needed to establish the correct implementation.

Phase 2 — Make It Intelligent.

And by intelligent, I don’t necessarily mean introducing an AI model.

I mean making sure the subsystem could receive the information it needed, process that information correctly, and use the results appropriately.

A scoring system isn’t particularly useful if its inputs aren’t reaching it.

A memory system isn’t providing continuity if the relevant workflows never recall what it stores.

And a subsystem isn’t really integrated if the rest of the application has no way to use its output.

Phase 3 — Make It Useful.

Connect the capability to the places where it was supposed to matter.

Make sure its behavior could influence the application rather than remain isolated behind an implementation that technically worked.

Those three phases became a recurring method.

And the more I used coding agents, the more I began relying on them to help establish what each phase actually required.

Auditing My Own History

Something else was happening alongside the repository work.

I had accumulated a considerable amount of conversational history from developing A.I.N.D.Y.

Those conversations contained ideas, architectural decisions, experiments, and features I’d discussed at different points in the project.

But not everything we’d discussed had necessarily been implemented.

And not everything that had been implemented still matched the original idea.

So I began using Codex and Claude Code to review my saved conversations and compare them with the actual repository.

Some of those reviews revealed additional concerns around automation, agentic capabilities, and freelancing-related functionality.

The process wasn’t simply asking an AI to summarize an old conversation.

I wanted to know which ideas were relevant to the current system.

Which ones already existed. were incomplete or would require new implementation work.

From those findings, we could create implementation plans.

Then I could take those plans back into the repository and work through them using the same three-phase approach.

Make it real.

Make it intelligent.

Make it useful.

There was a lot of back-and-forth between what I’d originally envisioned and what the code actually contained.

And I was learning more about my own system through that process.

Sometimes an audit confirmed that something I’d intended was already there.

Other times, it revealed that I’d misunderstood the responsibility of a component.

And sometimes it showed that the implementation was only part of what I’d thought I’d built.

The Memory Bridge had already been a good example of that.

But the same general problem existed across the larger application.

The Prototypes Finally Had Somewhere to Go

By the time I’d worked through the existing subsystems, I could finally return to the two prototypes that had been waiting for integration.

The Nodus Runner and the Single File Engine.

But neither prototype was intended to replace A.I.N.D.Y.

They represented patterns and responsibilities that needed to be evaluated against the application.

And I’d already established an instruction for the agent:

Do not modify it. Extract the pattern. Rewrite clean.

Just because a mechanism existed inside a prototype didn’t mean it belonged in A.I.N.D.Y. in exactly the same form. And it didn’t mean every mechanism needed to be transferred at all.

Claude Code needed to inspect what already existed, identify where the proposed responsibilities belonged, and determine which parts of the prototypes could be adapted to the application.

The Nodus Runner offered patterns for scheduling, retries, background execution, task registration, and replay.

The Single File Engine offered a model for persistent workflows, execution state, WAIT and RESUME, event routing, and recording outcomes.

But the repository already had its own services and execution paths.

The task was to reconcile those responsibilities, not create a second application inside the first one.

Porting Patterns, Not Copying Code

The integration followed the same general method I’d been using across the other subsystems.

First, establish what needed to exist.

Then make the components work with the necessary information and execution paths.

Finally, connect them to the application so they could actually be used.

For the Nodus Runner, that meant addressing weaknesses in the existing background execution system.

A.I.N.D.Y. could start work, but some of that work was still handled through daemon threads without the kind of durable supervision, replay, and execution history I wanted.

The integration introduced more explicit scheduling, retry behavior, and automation records.

The work wasn’t considered complete simply because a new scheduler existed.

The implementation needed to replace the relevant old behavior and survive the repository’s checks.

One reported milestone was 690 passing tests and zero remaining daemon threads.

The Single File Engine presented a different problem.

Its purpose wasn’t simply to launch work.

It was to preserve the identity and state of work as it progressed through multiple steps.

That led to the persistent flow engine.

Instead of every subsystem maintaining its own idea of what execution meant, the application could begin using shared concepts for a running flow, its current state, its history, and the events that allowed it to continue.

One of the most important capabilities was WAIT and RESUME.

A workflow could stop because it needed approval, external information, or another event.

Rather than keeping a process running while nothing happened, the engine could preserve the workflow’s state and resume when the required event arrived.

That was particularly relevant to an application intended to support human participation in automated work.

The implementation also began connecting Genesis plans to executable workflows.

A MasterPlan could describe what needed to happen.

The flow engine provided a way for those steps to become work the system could track.

And execution outcomes could feed back into the Memory Bridge.

These were not isolated additions.

They were ways of connecting responsibilities that had previously existed in different parts of the application.

By the end of the integration work, the reported test suite had reached 790 passing tests with zero failures and 69.22 percent coverage.

But the test totals weren’t the most interesting part of what happened next.

Because once the prototypes had been integrated, I found myself asking a familiar question.

What had we actually built?

Everything Worked. But Did It Work Together?

That question led to another round of audits.

And this time, the findings were different.

The problem wasn’t simply that a particular subsystem was incomplete.

Two larger issues kept emerging.

The first was cohesion.

Individual subsystems could function correctly in isolation without necessarily operating as one coordinated system.

The formulas worked.

The scoring mechanisms could produce results.

The memory components could preserve and retrieve information.

The execution machinery could run workflows.

But that didn’t automatically mean information moved through the entire application in a way that produced the intended outcomes.

The second issue was the repository itself.

And this one irritated me a little.

Because I’d already spent a considerable amount of time learning how to organize a repository.

I’d been moving files, examining project structures, creating documentation, and trying to make the codebase easier to understand.

Then another audit came along and effectively told me the organization still wasn’t good enough.

But the reasoning was important.

The agent wasn’t merely suggesting a cleaner folder structure because it looked better.

It was identifying an obstacle to future development.

For an agent to work effectively in a repository, it needs to understand the boundaries between components.

What owns a particular responsibility?

Where should a new implementation belong?

Which parts of the system depend on it?

What changes are allowed to affect other components?

And which assumptions need to remain true?

If those boundaries aren’t clear, the agent can make changes that seem correct locally while creating problems elsewhere.

And that was especially concerning in an application with as many interconnected responsibilities as A.I.N.D.Y.

So the audits began driving a different kind of work.

Not simply adding or repairing capabilities.

But reorganizing the repository and clarifying the relationships between them.

The Repository Needed an Architecture It Could Explain

I’d already been creating documentation for a while.

There were repository maps, roadmaps, audits, implementation plans, and reports derived from my earlier conversations.

But this stage was different.

The documentation was no longer only about recording what I wanted to build.

It was becoming part of the process of deciding how the existing system should be organized.

We needed clearer ownership.

Clearer boundaries.

More explicit relationships between services.

And a better understanding of how changes to one part of A.I.N.D.Y. affected the rest of the application.

The agents were helping identify those relationships by examining the actual implementation.

Then the documentation and repository structure could be updated to reflect them.

And the more we did that, the more the audits started describing the system in a way I hadn’t expected.

They kept using language like:

OS-like. Runtime-like.

At first, I didn’t really know what to make of that.

Because as far as I was concerned, I was building an application.

I wasn’t trying to build an operating system.

And I didn’t even have a clear understanding of what a runtime was.

But the description kept appearing.

As we connected more subsystems and clarified more of the architecture, the classification kept coming back.

Eventually, I decided to ask why.

Why Do These Audits Keep Calling This a Runtime?

So I went back to ChatGPT.

Which is somewhat funny considering I spent the previous article explaining why I moved most of my implementation work into the terminal.

But this wasn’t an implementation question.

I wanted to understand something.

Why did these repository audits keep describing A.I.N.D.Y. as OS/runtime-like?

What was it about the architecture that led to that classification?

I brought several of the audit documents into the conversation.

ChatGPT examined the descriptions and pointed toward a few recurring architectural responsibilities.

The kernel-like coordination mechanisms.

The memory system.

And the agent execution infrastructure.

Those weren’t just features sitting next to one another.

They were increasingly responsible for governing how work happened inside the larger application.

And that explanation started making sense when I compared it with another problem I’d been noticing.

The Infinity Algorithm Was Still Just an Algorithm

The Infinity Algorithm had been part of A.I.N.D.Y. for a long time.

I’d developed formulas to measure different aspects of performance, productivity, and progress.

And those formulas worked.

They could receive values, perform calculations, and produce results.

But I’d begun realizing that the calculations alone weren’t enough.

For the larger system to use those results meaningfully, something needed to gather the relevant inputs.

Something needed to determine when the calculations should happen.

Something needed to process the results.

And something needed to make those results affect what happened next.

Otherwise, I could have a perfectly functional set of formulas without a system that actually used them.

The same problem had appeared in different forms throughout A.I.N.D.Y.

The Memory Bridge could retrieve information, but that information needed to become part of execution.

Genesis could create plans, but those plans needed a way to become actionable workflows.

The execution engine could run work, but the results needed to reach the systems responsible for memory, feedback, and future decisions.

And suddenly the earlier audit findings made more sense.

The lack of cohesion wasn’t simply an organizational inconvenience.

It was preventing the larger application from operating as the kind of system I’d been trying to build.

And the repository boundaries weren’t simply about making the code easier to navigate.

They were necessary for maintaining and extending the machinery that connected everything.

I Thought I Was Building an App

So when ChatGPT explained why the architecture kept being classified as runtime-like, I started looking at A.I.N.D.Y. differently.

I’d been thinking of the project as an application with a growing collection of capabilities.

But the more those capabilities became connected, the more I needed something underneath them to coordinate execution, state, memory, and feedback.

I needed the machinery that allowed the different parts of A.I.N.D.Y. to function as one system.

And a lot of that machinery was already beginning to exist.

The prototypes had helped define it.

The subsystem audits had helped correct the existing implementations.

The integration work had begun connecting the responsibilities.

And the later audits had exposed the architectural boundaries that still needed to be established.

I hadn’t set out to build a runtime.

But I could now see why the agents kept describing the architecture that way.

So I made a decision.

Well, let’s lean into that.

Instead of continuing to treat the execution machinery as a collection of features inside A.I.N.D.Y., I began developing it deliberately as the underlying runtime.

That didn’t mean every part of the application suddenly became runtime code.

And it didn’t mean the architecture was complete simply because I’d recognized what it was becoming.

There were still boundaries to establish, responsibilities to separate, and existing implementations to reconcile.

But the direction had changed.

I was no longer only asking how to make the application work.

I was asking what the underlying system needed to provide so that applications, workflows, and agents could work on top of it.

And that was a much larger architectural question than the one I’d started with.

Discovering the Architecture Doesn’t Finish It

Looking back, what’s interesting is that no single AI system made this happen.

Gemini helped me develop the automation prototype.

ChatGPT helped me understand where that prototype belonged and what execution concepts A.I.N.D.Y. was missing.

Codex and Claude Code helped examine the conversational history, audit the existing application, identify implementation gaps, and turn those findings into work inside the repository.

Claude Code then helped adapt the prototypes, connect existing subsystems, and expose architectural problems that weren’t obvious when the components were examined individually.

And ChatGPT helped me understand why those findings kept pointing toward a runtime.

But I was the one bringing those sources together.

I was deciding what needed investigating.

Which implementation gaps mattered.

Which plans to follow.

When the evidence justified moving forward.

And ultimately, whether the direction the architecture was taking was one I wanted to pursue.

The interesting part wasn’t that an AI told me I’d built a runtime.

It was that the process of examining what I’d built gave me enough information to recognize the possibility and decide what to do with it.

And that decision introduced another challenge.

If A.I.N.D.Y. was going to have a runtime, then what actually belonged inside it?

What belonged to the application?

What should be exposed through an SDK?

And how should those responsibilities be separated without breaking the system I’d already built?

That would become the next stage of the work.

Because discovering that I’d been building a runtime was one thing.

Learning how to separate it from the application was another.

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.
Article 9 — Where Does the Work Exist? — How auditing A.I.N.D.Y.’s Memory Bridge with Claude Code changed my development workflow, helped me understand my own architecture, and taught me to evaluate agent-generated work through repository evidence rather than blind trust.

By this point, I’d spent months building, auditing, and connecting the different parts of A.I.N.D.Y.

What began as an application had gradually developed the responsibilities of something much larger. And after repeated repository audits kept describing the architecture as OS/runtime-like, I finally began understanding why.

So I made a decision.

Instead of continuing to treat execution, memory, orchestration, and feedback as separate capabilities inside an application, I would begin developing them deliberately as the underlying runtime.

But recognizing that I was building a runtime introduced another problem.

A.I.N.D.Y. already had an application, existing services, interfaces, and dependencies. I couldn’t simply declare part of the repository a runtime and assume everything would fall into place.

I needed to determine which responsibilities belonged to the runtime, which belonged to the application, and how the different pieces should communicate without becoming dependent on one another’s internal implementations.

In the next article, I’ll explore how I worked with coding agents to decompose A.I.N.D.Y. into separate architectural layers, why that required more than reorganizing files, and how repository audits helped establish the boundaries between the runtime, SDK, UI kit, and application.

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.

2026 Agents Case Study Series: Where Does the Work Exist?

Shawn knight — Thu, 05 Nov 2026 02:48:04 +0000

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

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.

2026 Agents Case Study Series: Prototyping with AI

Shawn knight — Sun, 01 Nov 2026 05:10:30 +0000

2026 Agents Case Study Series Logo

It Started With Nodus

To understand why I kept building systems in single files, we need to go back to the first night I started building Nodus.

When I originally asked ChatGPT how coding languages were created, the conversation got long.

And I mean, we’d gone through the entire language pipeline.

Source Code → Lexer → Parser → AST → Bytecode Compiler → Virtual Machine

The architecture wasn’t necessarily scattered. It was all in one conversation.

But since I hadn’t decided to turn the experiment into an actual project yet, every upgrade had happened progressively throughout that conversation.

And I was still using my old workflow.

ChatGPT would generate the code.

I’d copy and paste it into my local files.

Then I’d run it myself in the terminal.

If something didn’t work, I’d bring the error back to ChatGPT, we’d figure out what needed to change, and I’d try again.

Eventually, we’d built enough that I started wondering whether I could use Codex to continue developing the language.

So I asked ChatGPT.

It said yes.

But now I had another problem.

I didn’t want to copy and paste the entire conversation into Codex.

So I used a move I’d already been using for a long time, just in a different context.

Normally, I’d ask something like:

Review this discussion for the thought process and key insights.

That would let me take a long conversation and preserve the important parts without having to carry the entire discussion forward.

But this time, I wasn’t trying to preserve a discussion.

I was trying to preserve what we’d built.

So I asked:

Compress everything we just built into a single file with comments.

My reasoning was pretty simple.

One file would be easier to copy and paste.

That was it.

I wasn’t sitting there thinking about monolithic architecture or designing a new methodology for working with AI agents.

I just wanted to get the language into Codex.

But something interesting happened when ChatGPT consolidated everything.

I could actually see the architecture.

Not that the code was perfect. That’s not what I’m saying.

But the implementation became much easier to understand.

I could see why each component existed.

I could see what it was responsible for.

I could see how it worked on its own and how it connected to the rest of the language.

And I could follow the entire process of how source code moved through the language’s pipeline and eventually became instructions the virtual machine could execute.

Before that, I’d been building the language one upgrade at a time.

Now I could look at the whole thing.

And that was a different experience.

Then Codex Got the File

When I transferred the language to Codex, I got another lesson about what I’d created.

The single file became the workspace Codex was extending.

One of the first things Codex noted was the size of the file.

But it also recognized something useful about the structure.

Even though everything was in one file, the responsibilities were separated.

Every section had it’s own role in the system.

And those boundaries made the language easier to extend.

They also meant that, as the project grew, the components could eventually be moved into separate files and modules without having to invent the entire architecture from scratch.

That was the second thing the single-file approach taught me.

Putting everything in one file didn’t necessarily mean everything was one responsibility.

Gemini Did It Without Me Asking

By the time I started building the Nodus Runner, I’d learned that I could start with just a question. let the AI explain how something worked, and then guide the build based on what I’d just learned.

With Nodus, a lot of that process had been about understanding programming languages.

With the Runner, it was a little different.

I already knew I needed automation in A.I.N.D.Y.

I just didn’t know exactly what form that automation would take.

So when I asked Gemini whether I could build my own n8n, I wasn’t necessarily trying to learn how to build automation systems from scratch.

I wanted to see whether I could actually build one.

Gemini explained what an automation engine would need and offered to show me how to build the first component.

I said yes.

Then it offered the next component.

I said yes again.

And that was pretty much how the conversation went.

Gemini would explain what we’d just added, why it mattered, and what the system was still missing.

Then it would ask whether I wanted to build the next piece.

And I’d say yes.

Webhooks, background execution, persistence, authentication, retries, scheduling, replay.

One component after another.

I didn’t have to know the entire architecture before starting.

Gemini was helping expose the requirements as the prototype developed.

And because I already understood the kind of system I wanted, I could follow the process without having to stop and manually specify every component.

The interesting part? I didn’t even have to ask Gemini to put everything into one file.

After we’d gone through the different components, Gemini asked:

Would you like me to help you bundle all this logic into a single main.py file that you can actually run and test right now?

And, of course, I said yes.

So now I had another single-file prototype.

Except this time, the AI had suggested consolidating the implementation.

And once again, I had something concrete that represented what we’d been developing through conversation.

But I still had a problem.

I knew what the Runner was supposed to do.

I wasn’t entirely sure where it belonged in my architecture.

So I took that file to ChatGPT.

By the Third Time, I Knew What I Was Doing

By the time I took the Nodus Runner to ChatGPT, I had a pretty good understanding of the prototyping process I’d been using.

I’d done it with Nodus. Did it again with Gemini.

And I was starting to recognize that this wasn’t just a coincidence anymore.

It was a technique. A framework. Whatever you want to call it.

I knew I could let an AI walk me through a build, make decisions based on what I understood, and eventually consolidate the result into something I could examine as a whole.

I wasn’t trying to build another prototype.

I was trying to figure out what to do with the one I’d already built.

And ChatGPT helped me work through that question.

It broke down what the Runner was responsible for and how those responsibilities related to A.I.N.D.Y., the application I’d already been developing.

The Runner could receive triggers, schedule tasks, record outcomes, and retry failed operations.

But ChatGPT identified something it didn’t really have.

An execution model.

The Runner could automate work, but we hadn’t fully defined what that work actually was within A.I.N.D.Y.

That along with numerous other questions the automation prototype alone couldn’t answer.

And, well, that led to another conversation.

An extremely long-ass conversation.

ChatGPT started explaining the concepts we would need, how they related to each other, and what decisions had to be made before we could implement them.

Then we’d define a concept, build an early implementation, and move to the next one.

Eventually, we had worked through an entire proposed execution architecture.

And once again, I’d reached the point where I wanted to see the whole thing together.

So I asked ChatGPT to consolidate everything we’d developed.

The result was something we called:

A.I.N.D.Y. Core Loop v1 — Single File Engine.

It brought together nine major pieces:

A stateful Flow Runner
A Node Execution Contract
PostgreSQL persistence through SQLAlchemy
A WAIT / RESUME system
Event routing and subscriptions
Memory for event outcomes
A basic strategy and learning layer
Governance policies
An Intent → Plan → Flow pipeline

ChatGPT described it as a minimal but complete Temporal-class system, simplified for clarity without asynchronous workers or queues.

That was the description.

It wasn’t proof that we’d built something equivalent to Temporal or that the prototype had production-grade execution guarantees.

But we had defined the major responsibilities of the proposed system and brought them into one implementation.

And now I had something concrete that could be taken into the next stage of development.

But notice something about how I got there.

I hadn’t gone to ChatGPT asking it to build an execution engine.

I’d gone there asking where an automation runner belonged.

ChatGPT helped identify a missing responsibility.

I followed the explanation, made decisions about how those responsibilities should work, and we developed another prototype.

Then I used the same consolidation technique I’d already discovered through Nodus and repeated with Gemini.

Three different builds.

Three different starting points.

But the same underlying process.

And by the third time, I was beginning to understand why it worked so well for the way I was building with AI.

The Prototype Wasn’t the Repository

After ChatGPT generated the A.I.N.D.Y. Core Loop v1 Single File Engine, it proposed a production-ready repository structure.

And that’s where I stopped it.

Are you saying I need to restructure my current repository?

Because I already had an A.I.N.D.Y. application.

It wasn’t an empty repository waiting for someone to tell me where to put the files.

I’d already been building it, and by this point, the architecture was getting pretty involved.

There was the Infinity Algorithm, the individual formulas, the Memory Bridge, the AI SEO tool, tasks, and quite a few other components.

So when ChatGPT started suggesting a new repository structure, I needed to know whether it was proposing something that actually fit what I had or simply describing how it would organize a new project.

ChatGPT backed away from the full reorganization and suggested introducing the engine gradually as an internal layer.

And that brought me back to something I’d already been learning throughout the Nodus experiment.

The context available to an AI matters.

ChatGPT could help me design the execution system.

But it didn’t necessarily have the repository context needed to decide how that system should be integrated.

And fortunately, I’d already been working on that problem from another direction.

I Was Already Mapping A.I.N.D.Y.

While all of this was happening, I’d been using Codex to audit A.I.N.D.Y.

But I wasn’t auditing just for the sake of finding problems.

What I was really doing was mapping the system as it currently existed.

I wanted to understand what I’d already built, how the components worked together, and whether the implementation matched what I thought the application was supposed to do.

So I’d have Codex examine the repository and produce an audit.

Then I’d use those findings to develop documentation describing the architecture and the responsibilities of its components.

But I didn’t simply accept the documents because the AI generated them.

I’d have Codex check the audit against the implementation, then check the documentation against the implementation again before finalizing it and adding it to the repository.

And I got some useful documents out of that process.

One mapped the Infinity Algorithm abstraction and how it was currently implemented throughout the application.

Another mapped the broader architecture, including the Memory Bridge, the individual formulas, the AI SEO tool, task systems, and the relationships between those components.

Which, looking back, was already a fairly involved architecture for someone like me to be building.

But the important part was that I was developing a clearer picture of what actually existed.

And that documentation was becoming part of the repository itself.

So when I eventually brought the prototypes into the coding-agent environment, I wasn’t starting from nothing.

I Didn’t Tell the Agent to Just Implement It

Now I had two single-file prototypes.

The Nodus Runner from Gemini.

And the A.I.N.D.Y. Core Loop from ChatGPT.

I had also been auditing and documenting the existing application.

So the next question was how those prototypes could fit into what I’d already built.

But I didn’t simply hand them to the agent and tell it to start implementing.

First, I had it review the existing audit.

Then check that audit against the current implementation.

Then examine the God Files.

Only after that did I ask how the prototypes could fit into the existing architecture.

And that’s where the single-file approach became useful again.

The agent could examine each prototype as a whole.

It could see the different responsibilities we’d defined, how the components interacted, and what each mechanism was supposed to accomplish.

Then it could compare those responsibilities against the architecture already present in A.I.N.D.Y.

I’d been thinking the two prototypes might belong together.

And the agent’s analysis supported that direction.

Together, they appeared to provide several of the execution and orchestration capabilities the existing application was missing.

But recognizing where the prototypes belonged was only part of the problem.

We still had to figure out how to implement them without disrupting the architecture I’d already built.

Don’t Copy the Code. Extract the Pattern.

This was probably the most important part of the integration process.

I didn’t want the agent to take the two God Files, split them into smaller files, and dump those files into A.I.N.D.Y.

That would have been easy to ask for.

But it would also have meant carrying the assumptions and shortcuts of the prototypes directly into an application that already had its own structure.

So the implementation instructions took a different approach.

Do not modify it. Extract the pattern. Rewrite clean.

The agent was supposed to read each prototype completely, identify the mechanisms worth preserving, and then implement those mechanisms according to A.I.N.D.Y.’s existing conventions.

That mattered, beacuse the God Files weren’t being treated as production code that needed to be moved.

They were being treated as reference implementations.

And because the responsibilities had already been separated inside each file, the agent had a relatively clear map to work from.

It could identify the imports, database setup, data models, flow runner, event handling, and other components without having to reconstruct the prototype from a collection of disconnected files.

Then it could determine where those responsibilities belonged in the actual repository.

The data models could follow A.I.N.D.Y.’s existing model conventions.

Persistence could integrate with the application’s database structure.

Execution components could be placed according to the responsibilities they owned.

And the resulting implementation could be organized around the existing architecture rather than forcing the application to adopt the prototypes’ structure.

The architecture could transfer without the original implementation transferring wholesale.

The God File Became a Workspace

With Nodus, the single file had helped me transfer a language implementation into Codex.

With Gemini, it had helped me move an automation prototype into ChatGPT.

And with A.I.N.D.Y., the single-file prototypes became workspaces the coding agent could study while implementing their useful mechanisms inside an existing application.

The agent didn’t need to search through multiple prototype repositories to find the pieces.

The responsibilities were already labeled and grouped.

The relationships between them were visible.

And because the prototypes were separate from the actual application, the agent could analyze them without treating their original structure as something that had to be preserved.

That was the real advantage.

I could let AI help me explore a system, define its components, and consolidate the result.

Then I could give that artifact to a coding agent with access to the real repository and ask it to determine how the concepts should be implemented there.

The prototype provided the reference.

The repository provided the actual architectural constraints.

And the agent helped connect the two.

God Files Are for Prototyping

Now, I’m not saying any of this to suggest that a God File should become a permanent part of your software.

In fact, this entire story is demonstrating the opposite.

The God File is temporary.

It’s a prototype.

And a prototype should eventually have the opportunity to grow into something more than a prototype.

In my case, the prototypes were integrated into an architecture that already existed.

But, I still have the original prototypes.

The original Nodus language pipeline.

The Nodus Runner.

The A.I.N.D.Y. Core Loop.

And an AI model, but we’ll get to that in another article.

Those prototypes still exist independently of the systems they helped me build.

Which means that, theoretically, I could take any one of them and start developing it into its own project.

I’m not planning to do that.

But I could.

And that’s part of what makes the approach useful.

The prototype doesn’t have to disappear just because its ideas have been integrated somewhere else.

It can remain a reference for what was originally designed, how the components were intended to interact, and what the system looked like before it was adapted to another architecture.

But my actual point is something simpler.

A God File can be an excellent endpoint for a technical design session with AI.

You’ve spent the conversation asking questions, exploring mechanisms, defining responsibilities, and developing implementations.

Now you need something that preserves that work.

Something you can inspect.

Something you can transfer to another AI system.

Something that shows how the pieces relate to one another without requiring someone to reconstruct the entire conversation.

That’s where the single-file prototype becomes useful.

It consolidates the implementation and the architectural decisions expressed through it into one artifact.

And then it becomes an excellent starting point for whatever comes next.

Maybe you’re building a new project from scratch.

Maybe you’re integrating the prototype into an existing application, like I did.

Maybe you’re giving it to a coding agent to examine, test, and extend.

Or maybe you’re simply trying to understand the system you just spent several hours designing.

The same principle applies.

The file gives you a concrete representation of the proposed architecture.

It makes the system portable.

It makes the components inspectable.

And because the responsibilities have already been identified, it gives you a starting point for extending and separating the implementation as the project grows.

That doesn’t mean the code is automatically correct.

It doesn’t mean the architecture is complete.

And it certainly doesn’t mean you should keep everything in one file forever.

The God File isn’t the finished architecture. It’s the architecture at a stage where you can finally examine it as a whole.

For me, that was the value of the technique.

What started as a practical way to move code from ChatGPT into Codex became a repeatable approach to building with AI.

Explore the problem.

Define the components.

Build the prototype.

Consolidate the result.

Then use that artifact to determine what comes next.

The God File became the endpoint of discovery and the starting point of implementation.

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.

By this point, I’d developed a repeatable way of using AI to explore ideas, build prototypes, and preserve the resulting architecture in a form that coding agents could inspect and extend.

But as I began working more directly with A.I.N.D.Y.’s existing codebase, I started noticing something about the way I was using those agents.

I was still moving prompts and completion reports between conversational AI systems and coding agents, even when the agents could inspect the repository themselves.

And the more time I spent auditing the actual implementation, the more I began questioning whether that extra step was necessary.

In the next article, I’ll explore how an audit of A.I.N.D.Y.’s Memory Bridge changed my working relationship with Claude Code, why I began moving more of my architectural discussions into the terminal, and how testing and repository evidence became central to deciding whether an agent’s work could be trusted.

The next installment of the 2026 Agents Case Study Series is coming soon.

Explore the Projects

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.

2026 Agents Case Study Series: Discovering The Architecture

Shawn knight — Thu, 29 Oct 2026 04:11:44 +0000

Working with multiple AI systems help me discover an architecture I didn’t know I needed

Continue reading on Masterplan Infinite Weave »

2026 Agents Case Study Series: 1 Week to Vibe Code V1

Shawn knight — Wed, 28 Oct 2026 06:32:00 +0000

2026 Agents Case Study Series Logo

An attempt to vibe-code a language in one week

Once Nodus had a repository and a version, I formed a plan that now seems ridiculous.

I was going to get the language to Version 1.

Then I would be done.

I genuinely believed that 1.0 represented the finish line. The language would be complete, I could stop working on it, and I could return to the project I had actually been building before any of this began.

I was wrong.

Dead wrong.

But that misunderstanding gave the next week a kind of artificial urgency.

I was not casually exploring what Nodus might become anymore.

I was speed-running toward 1.0.

The Headline

There were several reasons I wanted to move so quickly.

The first was simple: I thought the work had a natural ending.

If 0.1.0 meant initial development, then 1.0 sounded like completion. I did not yet understand that reaching a stable public interface would create a new category of responsibility rather than eliminate the need for further work.

The second reason was A.I.N.D.Y.

Nodus had never been the project I intended to spend my time building. A.I.N.D.Y. already existed before I asked ChatGPT how programming languages were created. It carried the ideas, architecture, and longer-term direction I actually wanted to pursue.

I needed to get back to it.

And the third reason was less serious, but I will admit it:

I wanted the headline.

I vibe-coded a programming language to Version 1 in a week.

I mean, shit-I write articles.

That was one hell of a writing point.

I thought I could finish the language, tell the story, and move on.

Instead, the attempt to create that story taught me why software doesn’t become finished just because its version number reaches a particular integer.

The Proving Ground Became a Project

Nodus, in my opinion, was never supposed to exist.

When I asked ChatGPT how coding languages were created, I didn’t think the answer would interest me that much.

So when I originally used Codex on Nodus, in my mind, it was a throwaway project. An agent could mess it up, and there wouldn’t be any real consequences.

But even after seeing what Codex could do, I still didn’t want to turn an agent loose on A.I.N.D.Y.

That project mattered too much to me.

It already had history. It already had meaning. It already had code and concepts I was not prepared to risk while I was still learning what agents could do.

Nodus was different.

The problem was that it didn’t remain disposable.

With Version 1 looming over me, albeit by my own design, I launched into a rapid week of development.

The exact feature-by-feature chronology is less important than what the project began accumulating.

It acquired a changelog, release milestones, a centralized version source, a compatibility policy, a release checklist, and continuous-integration workflows.

I ran repeated architecture analyses and audits.

Findings became prioritized remediation plans.

Large changes were divided into phases.

Tests increasingly became the conditions under which one phase could proceed to the next.

The work was moving quickly, but it was no longer just feature accumulation.

I was spending the week learning how to make a project legible to itself.

But don’t miss what actually happened in that explanation I just gave.

I was testing whether an agent could work for hours without supervision.

Whether ChatGPT could translate my direction into a useful implementation assignment.

Whether Codex could understand and modify a growing codebase without destroying what already worked.

And whether documents, tests, reports, and repository history could preserve enough continuity to keep development moving.

That testing gave me confidence that I could use this type of agentic workflow with A.I.N.D.Y.

I Was Using Codex Differently

The orchestration workflow also began changing during this period.

Originally, almost every significant Codex result went back to ChatGPT.

ChatGPT held the long conversational history, interpreted the completion report, helped me choose the next direction, and generated the next Codex prompt.

But as the repository acquired better documentation, analyses, roadmaps, tests, and release records, ChatGPT no longer had to be the mandatory waypoint for every change.

Sometimes Codex completed a task and recommended the next one directly.

Sometimes I asked one coding-agent instance to write a handoff prompt for another instance or terminal session.

Sometimes I still returned to ChatGPT because I wanted broader interpretation or needed to think through a decision.

The workflow was becoming more distributed.

The original chat had acted as the project’s control plane because so much of the relevant context lived inside it.

Now more of that context lived in the repository itself.

The language specification, architecture analysis, roadmap, changelog, version policy, tests, and agent reports made the system increasingly portable between conversations.

That portability was about to matter.

I Ran Out of Codex

I did not move to Claude Code because Codex had failed.

I moved because I ran out of Codex usage.

At the time, I was using the $20 ChatGPT subscription. With the intensity of my workflow, the available Codex usage lasted roughly four or five days.

Regular ChatGPT conversations did not consume that allowance in the same way, so ChatGPT itself remained available.

But I was in the middle of the sprint and wanted to keep developing.

So I tried Claude Code.

My introduction to it began exactly the way much of my technical work begins.

I tried to install it.

It didn’t work.

So I did what I normally do.

I went to Claude and asked why.

I hadn’t changed my workflow just because I was using Claude and Claude Code instead of ChatGPT and Codex.

Claude explained what was wrong, gave me the commands to fix it, and helped me get the installation working.

Once it worked, I didn’t spend much time celebrating the successful installation.

My next message was:

Okay, now I need a prompt to analyze a language repo.

Claude asked what kind of repository I was working with.

It asked what dimensions I wanted analyzed.

I selected all of them.

Then I specified that the language was Nodus, written in Python, and that I wanted general security included.

Claude produced a repository-analysis prompt covering architecture, performance, documentation, bugs, and security.

I passed that prompt to Claude Code.

Claude Code entered the repository without the conversational history that had created Nodus and returned a cold analysis of the system it found.

Then I brought that analysis back to Claude.

Claude interpreted the findings, identified the highest-priority risks, and generated a phased fix-plan prompt for Claude Code.

The pattern immediately felt familiar:

I chose the direction.

The conversational model clarified and formalized it.

The coding agent operated on the repository.

The result came back for interpretation.

The next assignment was created from the new evidence.

I didn’t have to invent a Claude-specific working method.

That may be surprising to people who organize their identity around a particular AI company or model.

It’s not surprising to me.

Same Workflow, Different Feel

The workflow transferred.

The product experience did not feel identical.

I can’t say that Claude was more intelligent than ChatGPT for this work, and that is not the claim I am making.

What felt different was the product design expressed through the interaction.

ChatGPT tended to help me establish the objective and then give Codex meaningful freedom over how to accomplish it.

Claude more often stopped to ask questions before producing the assignment.

What kind of analysis did I want?

Which risks mattered most?

Should the work begin with analysis or implementation?

How should the goals be prioritized?

What decisions needed to be made before the coding agent began?

The prompts Claude generated for Claude Code were often more prescriptive, too. They specified the order of operations, relevant files, expected behavior, test commands, stopping conditions, and boundaries between phases.

ChatGPT often said, in effect:

Here is the destination and the governing constraint. Use the repository to determine the best path.

Claude more often said:

Here is the destination, the path, the checkpoints, and the condition that must be satisfied before taking the next step.

Neither approach is automatically superior.

But Claude surfaced useful friction for me.

Fewer Hours, Productive Friction

People will inevitably want a comparison, so here is the one from my experience at the time.

On the same $20 subscription, Claude was not better for my particular overall workflow.

I worked through long conversations with large amounts of accumulated context. I was also using Claude and Claude Code from the same allowance.

The ChatGPT subscription had given me several days of heavy Codex work while my ordinary ChatGPT conversations remained available.

The Claude subscription could last only a few hours under the combined pressure of the long Claude conversation and Claude Code.

That is not a controlled benchmark. It is not a universal price-performance claim. It is what happened under my specific usage pattern.

But there was another side to it.

Those few hours could be unusually productive.

Not necessarily because Claude generated more code per minute.

Because it made me answer questions before the code changed.

It forced decisions into the open.

It made the implementation plan more explicit.

It defined the evidence required to continue.

That friction reduced ambiguity.

The Gate Appeared in the Prompt

One instruction began appearing repeatedly in Claude’s implementation plans:

RUN PYTEST. DO NOT CONTINUE UNTIL ALL TESTS PASS.

Larger plans introduced a stricter rule:

PHASE GATE RULE — strictly enforced.

The agent was not merely told to run the tests at the end and include the result in a completion report.

The test result controlled whether the work could proceed.

Complete one phase.

Run the relevant tests.

If they fail, stop and repair the phase.

Only after the gate passes may the next set of changes begin.

That difference is larger than it sounds.

A test at the end can tell you that a long sequence of changes produced a failure somewhere.

A gate between phases narrows the failure boundary. It keeps one unverified change from becoming the foundation for several more.

Claude surfaced that pattern conversationally.

I kept it.

The Friction Became Infrastructure

Eventually, the gate moved out of the prompt and into the repository.

Changes began on a branch rather than directly on main.

A pull request had to pass the required checks before it could merge.

After merging, the permanent branch ran the quality workflow again.

I configured the protections to apply even to me as the repository administrator.

That last part mattered.

A governance system that everyone can bypass whenever they feel confident is not much of a governance system.

GitHub’s protected branches can require status checks before changes merge, and those checks can also be enforced for repository administrators.

The exact number of checks would evolve, but the principle became durable:

Proposed code does not become permanent code merely because an agent finished writing it.

It must pass the gates that protect the codebase.

Claude surfaced the gate as a conversational constraint.

I turned it into repository infrastructure.

Months later-although saying that makes it sound like this happened years ago-I created another repository and immediately felt that something was missing.

Nothing had failed.

No test was broken.

The repository simply did not yet have the protected branch and required gates I had become accustomed to.

The practice was new.

But it was already a learned instinct.

The Irony of Vibe-Coding a Language

The phrase “vibe coding” originally described an intentionally loose mode of AI-assisted creation: describe what you want, accept the generated changes, paste errors back into the model, and allow the code to grow without necessarily understanding every part of it. Andrej Karpathy’s original description.

In the broadest sense, I was certainly using natural-language instructions to generate software.

But the closer Nodus moved toward 1.0, the less the work resembled simply going with the vibes.

The agents made code appear quickly.

Then came the specifications, tests, and architecture analyses.

I’ve become an auditing menace.

There were remediation plans, compatibility rules, and I had to learn release discipline, packaging, and the distribution process.

Waiting for pull requests to pass their gates became my hobby.

I was treating Version 1 like a declaration that development was complete.

Instead, pushing toward it taught me how to work with long-running agents, move context between systems, evaluate unfamiliar code, distribute software, preserve releases, and turn useful conversational friction into enforceable engineering policy.

I wanted the story to be that I had vibe-coded a programming language to Version 1 in a week.

The better story was that trying to do so taught me how quickly code generation turns into systems governance once the output matters.

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.

Somewhere in the middle of all this, I actually reached Nodus Version 1.

There wasn’t much fanfare. I’d spent the week pushing toward a milestone I thought would mean the language was finished. And when I finally reached it, I immediately started asking how I could use it in A.I.N.D.Y.

But the work on A.I.N.D.Y. had already resumed during that same push. The audits, the automation experiment with Gemini, and the effort to reconnect the application’s original vision were all happening alongside Nodus development.

The projects were beginning to overlap, and I was still figuring out where the pieces belonged.

In the next article, I’ll explore what happened when I took the automation runner we’d built with Gemini back to ChatGPT, how we began separating the responsibilities of Nodus and A.I.N.D.Y., and why figuring out where a system belongs can be just as important as figuring out how to build it.

The next installment of the 2026 Agents Case Study Series is coming soon.

Explore the Projects

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.

2026 Agents Case Study Series: It’s Just a Conversation

Shawn knight — Tue, 27 Oct 2026 06:19:24 +0000

I don’t talk to coding agents very differently than I talk to chatbots.

I explain what I am trying to accomplish, answer questions, and challenge assumptions.

I’ll ask for an analysis, a recommendation, or a plan.

I decide whether the proposed direction makes sense, and then I continue the conversation.

That description simplifies quite a bit, but it also points toward something important.

From my side of the interaction, ChatGPT, Claude, Gemini, Codex, and Claude Code can all feel conversational.

It’s not that one system talks while another acts intelligently.

The difference is what the conversation is connected to.

Knowing About a Project Is Not One Thing

We often say an AI system “has access” to a project as if access were binary.

It isn’t.

There are several materially different ways an AI system can receive information about a project and interact with the environment around it.

1. Described Context

The model knows what I tell it.

I might explain the architecture, paste an error, summarize a feature, or describe what I believe a component does.

That can be enough for planning and conceptual guidance.

But the model also inherits the omissions and misunderstandings in my description.

2. Supplied Context

I may upload a document, paste source code, or attach an analysis report.

The model can reason from more direct evidence, but only from what I’ve supplied.

The missing file may still contain the answer.

3. Retrieved Context

A search system, connector, or retrieval pipeline may locate material related to the question and make it available to the model.

Retrieval-augmented generation, or RAG, is useful because it grounds responses in information retrieved from external sources. Google’s Machine Learning Glossary explains the approach.

That can improve accuracy and provide access to private or current information.

But retrieval is selective.

The system still has to determine what appears relevant before the model can reason over it.

3. Retrieved Context

The AI can actively explore an environment as its questions evolve.

It can list a repository, search for a symbol, inspect a function’s callers, compare implementations, or examine configuration files.

Instead of depending entirely on the information supplied in the initial prompt, it can investigate further when something doesn’t make sense.

5. Executable Context

The AI can run code, invoke tests, reproduce errors, inspect output, and compare actual behavior with its hypotheses.

That introduces a form of evidence that static reading alone cannot provide.

Mutable Context

The AI can change the system and observe the result.

It can edit a file, run a test, inspect the diff, and revise the implementation when the evidence contradicts the plan.

These aren’t rankings. They’re observations about different capabilities.

The first three primarily describe how information reaches the model. The last three describe what the AI can do within an environment.

And more access isn’t automatically better.

A read-only architecture review doesn’t necessarily need permission to modify the codebase. A conceptual discussion may not need repository access at all.

The point is that “the AI has context” doesn’t tell us enough.

We need to know what kind of context it has and what relationship it can form with that context.

Agents Are Not Omniscient Either

Repository access doesn’t mean total understanding.

An agent can search for the wrong phrase, stop after finding the first plausible implementation, or misunderstand which path is canonical.

It can overlook generated code, configuration, migrations, or runtime state.

It can infer intention from an implementation that is itself wrong.

It can run tests that pass while failing to cover the behavior that matters.

And it can modify one subsystem without recognizing an undocumented dependency elsewhere.

Its environment is also bounded.

Permissions determine which files it can read or change.

Network policies determine which external systems it can contact.

The checked-out branch determines which version of the codebase it sees.

Installed dependencies determine what it can execute.

And time and context limits affect how much it can investigate.

The agent doesn’t see the entire system simply because it has access to a repository.

It has a better opportunity to investigate the parts of the system within its reach.

That’s a significant difference.

But it isn’t magical omniscience.

The Conversation Changes When It Can Act

The most important capability isn’t necessarily any single tool.

It’s the feedback loop created when reasoning is connected to tools and consequences:

Inspect → Hypothesize → Act → Test → Observe → Revise

The difference is recursive.

In a conversation without execution tools, an AI can tell me what command I should run.

With the right tools and permissions, it can run that command, receive the output, and use the evidence to decide what to investigate next.

It can explain how to fix a failing test.

Or it can apply a candidate fix, run the test, observe another failure, and revise the implementation.

It can suggest that two modules may overlap.

Or it can search the repository, inspect their callers, and determine which implementation is actually being used.

The distinction isn’t strictly between chatbots and agents as product categories. A conversational interface can have tools, and an agent can operate through a conversation.

What matters is whether the system can act on its reasoning and observe the consequences.

The conversation becomes connected to the environment through repeated observation.

And that changes the working relationship.

This Changes the Human Role Too

Before working with coding agents, I carried most of the actions between the AI’s reasoning and the development environment.

If ChatGPT suggested a change, I made it.

If it needed an error message, I reproduced the failure.

If it needed to know whether something worked, I ran the application and reported what happened.

With coding agents, I increasingly moved toward directing the investigation and evaluating the evidence.

That didn’t remove my responsibility.

It changed where my effort belonged.

My questions became:

Is the agent investigating the right system?
Does it have the evidence required to support its conclusions?
Which assumptions came from the code, and which came from the prompt?
Did the test actually validate the intended behavior?
Does this implementation preserve the project’s architectural direction?
Should the agent have permission to perform the next action?
What must remain a human decision?

The more capable the environment became, the more important governance became.

An AI system that can edit, execute, publish, deploy, or communicate with external services isn’t merely more convenient than one limited to providing guidance.

It has a different action surface.

That surface needs boundaries, tests, approvals, logs, protected branches, and explicit ownership.

Capability without governance doesn’t become trust.

It becomes exposure.

The Model Is Only Part of the System

People often compare AI products as if the model alone determines the result.

My experience working with AI has suggested a larger unit of analysis:

Model + Context + Tools + Permissions + Environment + Feedback Loop

The same model can behave very differently when it receives one pasted error versus an entire repository.

Again when it can search that repository.

Again when it can execute the failing code.

Again when it can edit the implementation.

Again when a test gate controls whether the work may continue.

And again when the repository contains clear specifications, architectural boundaries, and durable instructions.

The intelligence matters.

So does the environment through which that intelligence interacts with the system.

That’s why evaluating “which AI is best” without describing the surrounding environment often produces weak conclusions.

One system may appear smarter because it was given better context.

Another may appear more reliable because it could verify its answer.

Another may appear more productive because its product design introduced useful friction before execution.

The visible result belongs to the whole system, not only the model that generated the response.

It Was Still Just a Conversation

I use the word “just” carefully.

A conversation connected to a repository, shell, test suite, version history, deployment environment, and permission system isn’t a small thing.

But the conversational continuity matters.

I didn’t become a fundamentally different person when I moved from ChatGPT to Codex or from Claude to Claude Code.

I still reasoned through questions and made decisions through dialogue.

I still challenged recommendations and asked what followed from the answer.

The interaction remained conversational.

What changed was that the conversation could reach the system it was discussing.

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 eventually integrate it into A.I.N.D.Y. with ChatGPT and Codex.

By this point, I’d learned that the capabilities of an AI system depended on more than the model itself. Context, tools, permissions, and the surrounding environment all influenced what it could accomplish.

But I was still learning what it meant to manage the work those systems produced.

And at the time, I had another goal.

I thought I could finish Nodus by getting it to Version 1.

In the next article, I’ll explore what happened when I tried to reach that milestone in a week, why I started using Claude Code alongside ChatGPT and Codex, and how the experience began turning testing requirements and development constraints into enforceable engineering practices.

The next installment of the 2026 Agents Case Study Series is coming soon.

Explore the Projects

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.

2026 Agents Case Study Series: I built my own n8n

Shawn knight — Mon, 26 Oct 2026 04:19:00 +0000

2026 Agents Case Study Series Logo

I did eventually return to A.I.N.D.Y. Just not in the way I expected.

At this point, I was about three or four days into trying to get Nodus to Version 1 within a week. Everything in this part of the story was happening during that same push.

So there wasn’t really a moment where I finished the language, closed that repository, and said, okay, back to A.I.N.D.Y. Returning to the application was one of the things that happened while I was still working toward that milestone.

The work overlapped. In the same Claude conversation where I was trying to finish Nodus, I started auditing the application I had previously been unwilling to give an agent. Meanwhile, I was using ChatGPT and Codex to go through my saved files and conversations, trying to reconstruct the larger vision behind it.

Then I went to Gemini with a question about automation.

At the time, that seemed like a separate conversation. Looking back, it was the beginning of figuring out that several things I had been treating as one project needed their own responsibilities.

But I didn’t arrive at that conclusion first and then ask the AI to build it. I asked a question, followed the answer, and eventually had to stop and ask what we were actually building.

Why I Added Claude

By this point, I had started using Claude and Claude Code alongside ChatGPT and Codex. The reason was mostly practical: usage and cost.

I had originally been using the $20 ChatGPT subscription. When my usage ran out, I paid for a Claude subscription thinking it would help me keep working.

That was how Claude entered the process. I hadn’t compared the models and decided one was more intelligent or better suited to a particular architectural responsibility. I had hit a limit, looked at what I could spend, and added another way to continue.

Once I had access to both, though, I could develop with both. And one of the things AI makes possible is getting multiple pieces of work moving at the same time. I could keep pushing Nodus toward V1 while also auditing A.I.N.D.Y., reviewing its history, and exploring an automation question.

I still had to connect the results and make the decisions. But I didn’t have to finish every piece before beginning the next one.

Figuring Out What I Had and How to Govern It

The first thing I asked an agent to do with A.I.N.D.Y. was audit it. Before adding more, I wanted to understand what I’d already built and whether the pieces actually worked together.

Claude Code examined the architecture, performance, documentation, bugs, and security. It came back with a laundry list of defects: duplicated routes, missing validation, unfinished modules, and components that existed but weren’t properly connected. The Infinity Algorithm’s core formulas were in the code, but their purpose and relationship to the larger system weren’t adequately documented.

Now, I already had a testing method. I’d add something new, break the app, try to restart it, and work through the bugs until it worked again. But the audit was showing me how much could still be wrong even after I’d gotten it running.

And that raised another question: what behavior should I actually be testing?

The repository could show what had been implemented. To recover what I’d intended, I went back to the saved conversations and documents where A.I.N.D.Y. had developed. While Claude Code examined the application, ChatGPT and Codex helped me work through the history behind the Infinity Algorithm, memory systems, the Monday Node, and the Infinite Weave.

That let me compare what the application did with what I’d built it for. My understanding of testing changed through that work: finding defects, recovering the intended behavior, and seeing what my restart-and-debug method hadn’t caught.

Meanwhile, Claude was helping me think about how to govern the project as it continued. I already had guidance documents, and Claude introduced additional project-discipline documents such as FREEZE_PROPOSAL.md, EXTENSION_PROCESS.md, and VERSIONING_POLICY.md.

I used Claude Code and Codex to create those documents, then used them alongside my existing guidance to govern the repository. We were working through what to stabilize, how extensions should enter the project, and how to handle versioning. The AI was helping me develop the process around the code while also helping investigate and build it.

All of this was happening during the same push toward V1. Several pieces of work could move forward at once, but I was still connecting the findings and carrying decisions between systems. The shared documents gave the work guidance beyond an individual chat; they didn’t mean every AI automatically knew what the others had done.

All of that was happening when I took an automation question to Gemini.

Couldn’t I Build My Own n8n?

The question I took to Gemini was pretty straightforward:

Gemini said yes and explained what I’d have to provide myself: a way to trigger work, connect services, execute the workflow, handle failures, and see what happened afterward.

For context, n8n provides things such as a Webhook node to receive an external request and start a workflow, along with execution records for individual runs. Building my own meant taking responsibility for those pieces.

Gemini offered to start with a simple Python webhook listener, and I accepted.

Now, this is where a familiar pattern started happening. We had the first piece, but once I understood what that piece did, I could see another question to ask.

The endpoint could receive a request. Okay, but what if the work took a while? The service sending that request shouldn’t have to wait for everything to finish. So we added background execution.

Then how would I know what happened after the request was accepted? We added PostgreSQL to record the incoming data, status, timestamps, and errors.

That gave us a history. But now we had to think about who could send instructions to the endpoint, so authentication came into it. Then retries for temporary failures. Scheduling for work that needed to happen at a particular time. Replay so a failed event wouldn’t have to disappear just because something went wrong the first time.

Docker, deployment automation, health checks, and execution analytics followed.

Each addition had a reason. And each answer helped me understand enough of the system to recognize something else it would need.

I had started by asking whether I could build my own automation. Now Gemini was helping me put together a prototype, one follow-up at a time.

All within one conversation.

Why I Called It Nodus Runner

Once the prototype had enough shape, I asked Gemini what I should call it. One suggestion was Nodus Runner.

And within the conversation we were having, that made sense. I was still working toward Nodus V1. I’d just created its repository, then stepped away from it for a bit to work on A.I.N.D.Y. That’s why the A.I.N.D.Y. work was happening in the same Claude conversation as the Nodus implementations.

Gemini also had previous context about Nodus, the coding language. It had been discussing the automation build in relation to that language, and I didn’t yet understand that the new piece belonged elsewhere in the stack. So when it suggested Nodus Runner, the name fit what I thought we were building.

But when Gemini explained the runner’s relationship to Nodus, I had a question:

I was only a few days into the push toward V1, but Nodus already had its own language runtime. It could take source code, compile it, and execute it in its virtual machine. So what was this new system adding?

Gemini said I didn’t need another runtime to make the language run and explained how the runner could be used to trigger, schedule, and coordinate work around that execution.

That helped me understand what we’d built. But I still didn’t know where it belonged in my stack.

After naming it, I went back and reread the entire build conversation. That’s when I started seeing how it might be useful for A.I.N.D.Y. The application had background tasks, but they relied on daemon threads and had no external scheduler. The runner’s persistence, scheduling, replay, and execution history seemed relevant to those limitations.

So I took the prototype to ChatGPT.

Finding Where It Belonged

ChatGPT helped me break down what the runner was and what role it could play in the application. Now we could work through the question in the context of A.I.N.D.Y., rather than continuing to assume the new build belonged with the language because that was where the conversation had started.

From there, we built the companion piece I needed to continue: A.I.N.D.Y. Core Loop v1 — Single File Engine.

The core loop brought together a stateful flow runner, a contract for how nodes executed, and PostgreSQL persistence. It also included waiting and resuming, event routing and subscriptions, memory of event outcomes, a basic strategy layer, governance policies, and an intent-to-plan-to-flow pipeline.

So, for example, we were now dealing with how a flow would preserve its progress, wait for something to happen, and continue afterward. Those were responsibilities I needed to understand within A.I.N.D.Y. Nodus executing a program was its own responsibility.

With ChatGPT and Codex’s assistance, I then decomposed both prototypes-the runner and the core loop-into the A.I.N.D.Y. application.

That was the actual progression. Gemini helped me build the runner and clarify how it was used. ChatGPT helped me understand where it fit in my stack and build the accompanying core loop. Then ChatGPT and Codex helped me integrate both into the application I already had.

I hadn’t started with a finished architecture and assigned each AI a piece. I was learning where the pieces belonged while using the AI systems to help me build and connect them.

Having Context Didn’t Settle the Question

Looking back, Gemini’s mistake was about where the runner fit in my stack. It had context about Nodus, and that context shaped the conversation. The connection sounded reasonable enough that I named the prototype Nodus Runner before I understood its role in A.I.N.D.Y.

That was another thing I was learning: an AI having context doesn’t mean it has the context needed for the particular conclusion it’s reaching. And even when the relevant information is available, it can still interpret it incorrectly.

I knew Nodus already had a runtime, so I could question that part of the explanation. Rereading the build helped me recognize a possible use in A.I.N.D.Y. Taking it to ChatGPT let me work through that possibility with more of the application’s context in view.

The project wasn’t held in one place. There was code in repositories, intent in saved conversations, and new prototypes developing in separate chats. I was still carrying those pieces between systems and checking whether their explanations matched the project I was actually building.

Coding agents gave me more direct ways to inspect and change the repository, as the A.I.N.D.Y. audit had shown. But access to the code didn’t automatically settle the intent behind it, just as conversation history didn’t automatically settle the architecture. I still had to examine how the conclusions connected to the evidence.

The same week I was learning to govern the project and test its intended behavior, I was beginning to learn how to separate its responsibilities.

What I’d called Nodus Runner went into A.I.N.D.Y. alongside the core loop. Later, the execution layer was separated from the application into A.I.N.D.Y. Runtime. Nodus continued as its own language with its own runtime.

Those boundaries would take months to define cleanly. But the work of discovering them was already happening during the push to V1. Through an automation question, a name that seemed to fit, and then the realization that I needed to ask where the thing we’d built actually belonged.

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 promisies — How architecture analyses, version control, and AI-assisted evaluation began changing the way I preserved and verified agent-generated work.

By this point, I was working with multiple AI systems to build, evaluate, and connect different parts of my ecosystem.

But the experience was also revealing something I hadn’t fully understood when I started.

An AI could give me useful architectural guidance about a project and still be wrong about how that project actually worked.

In the next article, I’ll explore the difference between chatbots and coding agents, why access to the actual development environment matters, and how the tools available to an AI can fundamentally change what it is capable of doing.

The next installment of the 2026 Agents Case Study Series is coming soon.

Explore the Projects

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.

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.

2026 Agents Case Study Series: What a version promises

Shawn knight — Sun, 25 Oct 2026 20:23:10 +0000

By the end of my initial ChatGPT conversation, I had given the project a name: Nodus.

It had a purpose, a language specification, a roadmap, a compiler, a virtual machine, a command-line interface, a standard library, and tests. But all that progress came with a problem.

Most of what I understood about the project came from working with ChatGPT and interpreting Codex’s reports. I had directed its development, made decisions about what it should become, and watched its capabilities grow. But I wasn’t an experienced programming-language engineer, and Nodus was becoming more technically complex than anything I had built before.

When the Conversation Reached Its Limit

The first two articles in this series followed one long ChatGPT conversation that contained almost the entire history of the experiment. That single thread knew how the language began, why certain features were added, what Codex reported after each run, and how the name Nodus came about.

Our workflow was simple: ChatGPT and I would discuss a feature, shape it into an assignment, and pass it to Codex. Codex would complete the work, return a report, and I would bring that summary back to ChatGPT to decide what came next.

Eventually, that original conversation hit its limit. The next conversation didn’t automatically inherit our history. I needed a way to continue development without having to manually reconstruct months of context.

The solution came in the form of a structured artifact: ARCHITECTURE_ANALYSIS.md.

Understanding the System Through Artifacts

The new conversation began by uploading that architecture document. ChatGPT’s opening response was simple: “I reviewed the architecture analysis you uploaded.”

The first conversation understood Nodus through accumulated conversational context; the second began by understanding Nodus through an artifact describing the actual system.

Instead of trying to summarize everything that had happened, I gave ChatGPT a structured view of what the runtime was, what it could do, and where its weaknesses lay. The analysis classified Nodus as an early practical scripting runtime rather than a toy interpreter. It also cataloged the language’s features and tests.

The biggest issue it highlighted was technical debt. Almost everything lived in a single file. That had allowed the experiment to move fast early on, but it created risks as the language grew.

I was no longer relying solely on Codex summaries telling me which features had been added; I had a document that explained the system as a whole. I was beginning to learn that a successful agent run and a healthy codebase were not the same thing.

Turning the Experiment Into Nodus

After reviewing the architecture analysis, I turned to the codebase itself. I had named the language Nodus, but the project files still carried the identity of the original prototype.

I directed ChatGPT: “Now we need the actual rename to Nodus and the file changes that requires.”

ChatGPT helped turn that objective into a scoped migration assignment. The prompt explicitly set boundaries: Codex was to make the project consistently reflect its new identity without using the opportunity to rewrite the architecture or introduce unrelated changes.

Codex executed the migration, renaming the primary runtime to nodus.py, establishing .nd as the primary source extension, creating a new launcher, and updating docs and tests. It retained backwards compatibility by leaving a shim for the old runtime name and reported 23 passing tests.

I didn’t need to manually update every file reference myself. My job was defining the outcome, establishing the constraints, and reviewing the reported result against the original goal.

By the end of the migration, Nodus had a consistent identity. It also had its first version number: v0.1.0.

What Version 0.1.0 Actually Means

When ChatGPT first suggested creating a Git repository and applying semantic versioning, I hesitated.

A repository with a clean name, documentation, a roadmap, and a version number can look like a product launch. I was concerned that publishing it would imply a level of maturity or commercial commitment that didn’t exist. I was trying to learn; I hadn’t set out to start a programming-language company.

To work through that concern, I used a separate conversation to unpack semantic versioning (MAJOR.MINOR.PATCH).

Under the SemVer specification, versions starting with 0.x.x explicitly denote early development. The public interface is uncommitted, breaking changes are expected, and the code is inherently experimental.

That changed how I viewed the decision. Version 0.1.0 didn’t mean the language was mature and it didn’t mean it was a product announcement. I understood it as a mark in time, kinda like a save point in a video game. It marked a specific, recoverable baseline in the evolution of the project. It said: “This is the first state we are deliberately keeping track of.”

Moving From Reports to Evidence

Transitioning to a versioned repository altered the underlying mechanics of how I worked with AI.

Until that point, progress was tracked through conversational sessions and execution reports. But a report is just an agent’s description of what it claims to have done. A repository introduces verifiable evidence:

Commits preserve exact file states.
Diffs show precisely what changed between runs.
Automated tests provide repeatable verification of behavior.
Version tags anchor stable reference points.

None of these tools guarantee that an implementation is flawless, but they reduce reliance on summary text. The codebase itself becomes an inspectable reality.

This transition also forced me to confront a deeper question: How much should I trust an AI-generated evaluation of AI-generated work?

Using ChatGPT to direct Codex, and then using an AI-generated architecture analysis to evaluate Codex’s output, creates a feedback loop. At this stage, I was still developing formal auditing practices to independently verify those claims. But having architectural documents and version control changed the questions I was asking.

Instead of only asking, “What feature should we build next?” I began asking:

“What has this system actually become?”
“Where are its structural vulnerabilities?”
“Does the raw implementation match the architecture we intended to build?”

The Birth of an Audit Workflow

Looking back, this was where my audit methodology began taking shape.

Each addition to the workflow solved a specific point of failure:

Conversational context provided speed, until the session ended.
Project artifacts preserved design intent across sessions.
Agent completion reports described executed tasks, but required verification.
Architecture analyses provided system-wide visibility.
Git repositories provided traceable, recoverable history.

Nodus had evolved from a loose collection of prototype scripts into a structured project with a canonical runtime, standard library, test suite, and version identity.

More importantly, my relationship with AI development was changing. I was beggining to realize, that building with AI agents isn’t just about prompting them to write code. it requires building the scaffolding to direct, preserve, and independently evaluate the work they produce.

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 — From Chat to Control — How I began directing Codex through persistent project documents, implementation constraints, and a manual agentic workflow.

By this point, Nodus had become a versioned project, and I was beginning to develop methods for preserving and evaluating AI-generated work.

But I still thought Version 1 meant the language would be finished.

In the next article, I’ll explore what happened when I tried to reach that milestone in a week, why I began working with Claude Code alongside ChatGPT and Codex, and how the experience changed my understanding of agentic development, testing, and governance.

The next installment of the 2026 Agents Case Study Series is coming soon.

Explore the Projects

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.

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.

2026 Agents Case Study Series: Chat Was Control

Shawn knight — Sun, 25 Oct 2026 00:20:21 +0000

On my first overnight run with Codex, it reported that it had completed all five priorities, added tests and documentation, and turned the small language that ChatGPT and I had been building into the beginnings of a credible scripting runtime.

Funny enough, I ended up with more questions than answers. The main one being:

What was I actually building?

Codex had spent the night extending the project while I slept.

So by the next morning, it was more than just an explanation of how languages worked.

But it still didn’t have a defined purpose.

I Had Ten Hours of Work

My next decision came as I was getting ready to spend ten hours at work.

I told ChatGPT:

ChatGPT had presented and explained two general paths:

A language-engineering playground or a practical scripting language.

I chose the second path because I didn’t want a plaything. I wanted to actually make the language useful.

That didn’t mean the deeper language features would never matter.

It just made the immediate purpose clear.

My Actual Working Style

Something I need to explain is how the project was being built.

Up through the end of this phase, almost everything happened through one continuous ChatGPT conversation.

I didn’t start one conversation per feature or open a new chat every time Codex finished a run.

It was one chat.

That conversation contained the original question, the 200-line offer, the progressive language upgrades, the first Codex prompt, the interpretation of Codex’s output, the next roadmap decision, the naming discussion, and eventually the review of what had happened.

The workflow looked like this:

I would choose a direction.
ChatGPT would help formalize it into a Codex assignment.
I’d transfer that assignment into Codex.
Codex would operate on the project and produce a completion report.
I’d bring the report back to the same ChatGPT conversation.
ChatGPT and I would interpret the reported changes and decide what should happen next.

Then we’d repeat the loop.

Basically, ChatGPT held the conversational continuity, and Codex changed the implementation.

I was moving information between them while retaining final authority over the project’s direction.

At the time, I wasn’t calling this orchestration.

I was just using each system for what it seemed best at.

But in practice, I had created a manual agentic workflow before I had built agentic orchestration into any product.

Codex Wasn’t Going In Blind

The task prompt was only one part of what Codex received.

By this stage, ChatGPT and I had developed three root documents to preserve the project’s evolving direction:

The separation was simple:

VISION says what it is.

SPEC says how it works.

ROADMAP says what comes next.

That meant Codex was not being asked to infer the entire project from a single Python file or invent a product philosophy from whatever feature request I happened to paste in that day.

The vision described the purpose, design philosophy, priorities, and non-goals.

The specification described the language’s current syntax and semantics.

The roadmap preserved the intended order of development.

The immediate prompt then defined what Codex should accomplish during that specific run.

Together, they created two layers of direction:

Persistent project intent.

Current execution instructions.

Codex had autonomy over many implementation details.

It did not have unlimited authority over what the project was supposed to become.

I learned that an agent can work independently without working blindly.

Autonomy doesn’t have to mean the absence of governance.

The Project Began Remembering Itself

Before that project context was documented, most of the project’s memory lived inside the ChatGPT conversation.

ChatGPT had the context for why each feature had been added because it had participated in the entire discussion.

Codex did not automatically possess that history.

The documents transferred the durable parts of that reasoning into the project itself.

That changed the relationship between the chat and the codebase.

The chat was still the control plane.

But the project was beginning to have its own memory.

The language vision preserved purpose beyond a single prompt.

The language specification preserved the intended behavior beyond a single implementation report.

The roadmap preserved direction beyond a single coding run.

The prompts could change.

The project’s identity did not have to change with them.

Make It Practical

The next Codex prompt was explicitly focused on turning the runtime into a usable scripting language.

It established the existing architecture, ordered the next features, and defined implementation constraints:

Do not rewrite the entire architecture.
Do not break existing tests.
Keep responsibilities separated.
Prefer readable implementations.
Avoid speculative optimization.

Figuring out the purpose of the language had changed the priority order.

I wasn’t adding features because they were interesting.

I was adding things that would make the language more practical to use.

The Run Was Not Frictionless

Codex worked while I was at my job.

Then the internet cut out.

I had to start it again.

That detail may sound minor, but it is part of the actual reality of agentic work.

The model may be capable of operating independently, but the surrounding system still matters.

Connectivity. Session persistence. The local environment. The ability to resume.

So many things that matter.

An agent’s autonomy depends on its infrastructure.

By lunch, I had another completion report.

Codex said it had completed the remaining Phase 2 work and verified it with tests, including expanding the suite from seven passing tests to fifteen.

That was Codex’s report. I, however, was still learning the difference between receiving a structured completion summary and independently validating the entire system.

But even as a report, it gave us the next state from which to reason.

So I returned it to ChatGPT.

The Loop Continued

ChatGPT interpreted the Phase 2 result as a shift from prototype toward practical tool.

It pointed to two signals in particular.

First, the project now had launchers. It was beginning to behave like something a person could run, not merely a Python file demonstrating a VM.

Second, the reported test suite was growing alongside the language instead of features simply accumulating without any validation structure.

Then ChatGPT generated the next Codex assignment.

The new priorities were:

Precise line-and-column error reporting
Map assignment
A module and import system
A standard-library directory
File I/O built-ins

This was not a random feature list.

Each addition addressed a limitation created by the project’s new purpose.

If people were going to write real scripts, they needed errors that identified where something went wrong.

They needed data structures that could be updated, code that could be reused across files, a standard place for shared capabilities, and the ability to read and write files.

Purpose was now governing implementation.

From Running Programs to Building Programs

Codex’s next report said it had completed the priorities with nineteen passing tests.

ChatGPT identified the conceptual threshold clearly:

The language was no longer only something that could run programs.

It was becoming something a person could build programs with.

The project now had enough structure that it needed something else.

It needed a name.

Nodus

I knew the naming question was coming.

My first choice was Axon.

An axon carries impulses away from a nerve cell.

That fit the original concept perfectly:

Logic → compilation → execution → result

The name also fit the AI-native framing without calling the language something painfully obvious like “AI Script.”

Axon sounded like a real programming-language name.

But then I found the Axon Framework.

It wasn’t just a vague naming collision in some unrelated industry. Axon was already the name of an established Java framework for event-driven systems, CQRS, and event sourcing.

I probably still could have used the name.

But I could already see another problem.

At some point, I would probably create an actual framework named Axon.

So I considered shortening the language to Ax.

That would have produced a clean command and file extension:

ax run script.ax

But it lost too much of the conceptual identity. It was harder to search and easier to collide with unrelated tools.

Then I suggested another name.

Nodus.

Latin for knot or node.

That connected the language to something larger than the neural metaphor.

Nodes, networks, connections.

The Infinite Weave.

The language was already being built as a series of connected execution layers.

So Nodus fit the project that had actually emerged.

Axon described signal movement.

Nodus described the system of connections through which execution moved.

That was closer to my broader way of thinking.

And naming the language changed how the project could be described.

It was no longer tiny_vm_lang_functions.py.

It was the Nodus language.

The Nodus compiler.

The Nodus VM.

The Nodus standard library.

A name didn’t magically make the language mature.

But it anchored the purpose, architecture, and future roadmap inside a shared identity.

What the Workflow Actually Was

Looking back, it would be easy to summarize this phase by saying:

Codex built a scripting language while I was working.

And it wouldn’t be wrong, just incomplete.

The actual process was that I made decisions with ChatGPT.

ChatGPT helped formalize those decisions into project documents and implementation assignments.

Codex then operated inside those constraints.

I brought Codex’s reports back to ChatGPT.

The same conversation interpreted the reported changes and helped produce the next assignment.

ChatGPT wasn’t just writing prompts.

It was maintaining continuity across the evolution of the project.

Codex didn’t just generate code.

It executed substantial blocks of implementation against a living system.

I wasn’t just relaying messages between two tools.

I was deciding which recommendations became direction, which path the language would take, what belonged in the durable project context, and when the experiment had become something worth naming.

The authority structure was:

Human direction → persistent project intent → agentic implementation → returned evidence → human interpretation

That was the system.

By the end of that original ChatGPT conversation, the unnamed 200-line experiment had become Nodus: a scripting language with a compiler, stack VM, collections, functions, a REPL, imports, file I/O, a standard library, tests, documentation, a roadmap, and a purpose.

But the larger discovery was not only what the agents had helped me build.

It was how I had learned to work with them.

Before I built an agentic architecture, I was already operating one by hand.

What’s Next?

If you haven’t read it yet, start with the first article in the 2026 Agents Case Study Series.

By this point, the language had a name, a purpose, and a growing set of capabilities. But the project itself was still carrying pieces of its original experimental identity, and most of the development history lived inside one ChatGPT conversation.

In the next article, I’ll explore what happened when that conversation ended, why Nodus needed its first official version and Git repository, and how architecture analysis began changing the way I evaluated and preserved AI-generated work.

The next installment of the 2026 Agents Case Study Series is coming soon.

Nodus — The programming language that began as the experiment described in this article. 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.

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.

2026 Agents Case Study Series: I created a Coding Language

Shawn knight — Fri, 23 Oct 2026 15:53:35 +0000

One Sunday night, I asked ChatGPT a simple question:

How are coding languages created?

ChatGPT gave me the kind of answer you would expect.

First, someone determines the purpose of the language. Then they design its syntax, which is how the language is written, and its semantics, which is what those instructions actually mean. After that come the parser, the compiler or the interpreter, the runtime, and eventually the ecosystem around it.

But there was one line in the explanation that changed how I understood the entire subject:

Programming languages are really just formalized frameworks for logic execution.

That was the part that got me. Not the syntax, the compiler, or the fact that computers eventually reduce everything into machine instructions.

It was the word frameworks.

Because frameworks weren’t new to me. Formulas, algorithms, and execution weren’t new to me. I had spent the previous year building systems around those exact relationships. The 2025 ChatGPT Case Study Series was built on it.

What I didn’t understand yet was that programming was not an entirely separate kind of thinking. It was the same underlying activity pushed to a higher degree of formalization.

Code Is What Happens When the Framework Becomes Executable

A framework identifies the relevant parts of a system and establishes relationships between them.

A formula expresses those relationships in a repeatable form.

An algorithm orders the logic into a process.

Code makes that process precise enough for a machine to execute.

The progression looks something like this:

Programming takes that framework, formula, algorithm, and execution progression and gives it formal syntax, semantics, and a runtime capable of carrying it out. That doesn’t mean every conceptual framework is automatically a program. It just means the distance between them isn’t philosophical. It’s operational.

The machine needs every relevant ambiguity removed. It needs to know what each instruction means, what order things happen in, what state must be preserved, what conditions change the path, and what should happen when something goes wrong.

Once those rules are formal enough, the framework can execute. That was the realization.

And then ChatGPT offered to prove it.

The 200-Line Offer

At the end of its explanation, ChatGPT told me it could show me how someone could create a programming language in about 200 lines of code. That once I saw it, programming languages would stop looking magical and start looking like structured translation systems.

So I took the offer. That could have been the end of it.

ChatGPT could have produced a small demonstration. I could have looked at the code, understood the general idea, and moved on.

But that’s not what happened. The first version had given me something else to think about.

Then ChatGPT asked what I wanted to add. I answered.

It created the next version. That version created another decision.

I answered again.

One upgrade became another.

And the little demonstration started becoming a language.

I Didn’t Begin With a Complete Specification

This part matters. There wasn’t a point where I sat down and wrote a technical specification for the finished system. I didn’t know every feature a programming language needed. Nor did I tell ChatGPT to go away and return with the final architecture.

I made one decision at a time. Each one changed what the language could express.

Every decision also changed what I understood well enough to ask for next.

It was the same iterative process I had already documented throughout the 2025 ChatGPT Case Study Series.

The difference was that the outputs were no longer just explanations, strategies, articles, or conceptual frameworks.

The iterations were accumulating into executable behavior.

Eventually, the language’s pipeline became:

Source code → tokenizer → parser → abstract syntax tree → compiler → bytecode → virtual machine → result

Basically, a language runtime.

It was small, incomplete, and written in Python. It was nowhere close to being an established programming language. But it was real.

And the architecture was no longer magical.

I could see the translation happening layer by layer.

I had asked how programming languages were created.

Now I was watching one emerge through a conversation.

Who Was Actually Designing It?

It would be easy to tell this story as ChatGPT built me a programming language.

But that is not really what happened.

ChatGPT generated the implementation.

I had to determine the direction.

It presented possibilities and I decided what mattered next. It translated that decision into code. I looked at the new system, understood more than I understood before, and used that new understanding to make another decision.

I wasn’t manually writing the tokenizer, parser, compiler, or VM. But I was deciding what the language was becoming. And that is language design.

It is also the part of AI collaboration that people keep flattening into prompts.

There was no magic prompt that created the whole thing. It was an evolving thought process with accumulated context within a single ChatGPT conversation.

There was execution, observation, and correction. My 2025 series argued that iteration, not prompt engineering, was the real optimization, and this project turned that argument into software.

Then I Asked About Codex

Eventually I looked at what the project had become and asked ChatGPT another simple question:

Is this one of those things that I could point Codex at?

ChatGPT said yes. In fact, it said that a small interpreter, compiler, and VM project was almost ideal for Codex. Since the architecture had distinct layers, a coding agent could trace how a feature moved through the entire system. Codex could inspect the codebase, understand those relationships, add features, refactor the architecture, generate tests, debug the call-frame handling, or even attempt major changes like converting the stack VM into a register-based VM.

And that’s when my operating model started to change. Until that point, I had been working with ChatGPT one conversational upgrade at a time. Now I had the option to give an agent the project itself.

Why I Finally Tried Codex

There was no major strategy behind the decision. I had heard about people pointing Codex at coding projects and letting it work for extended runs. I was about to go to bed. And at the time, this wasn’t an important project. That’s important because of what the project would later become.

I didn’t hand Codex a critical system because I already trusted it. I handed it an experiment because I didn’t care if the experiment failed. The downside felt small. If Codex broke the language, I still had my earlier work with A.I.N.D.Y., which at the time was my only technical project.

If it didn’t do anything useful, I would learn something. If it made progress, I would wake up with more than I had when I went to sleep. So I thought: Why not try it?

I pointed Codex at the project and went to bed. At that moment, I thought I was testing whether a coding agent could continue a disposable language experiment without me. I did not know I had reached the beginning of a much larger agentic build.

What I Actually Asked Codex to Do

The instructions weren’t vague. Before I went to sleep, ChatGPT helped me turn the existing language into a staged implementation request.

The goal was:

Turn this toy language into a credible small scripting language by adding the next five core features in a clean, staged way, with working tests and documentation.

The prompt told Codex what already existed and gave Codex five priorities.

First, logical operators. Second, strings. Third, a nil value. Fourth, built-in functions. Fifth, lists.

The prompt also established implementation rules.

Codex should preserve existing behavior, avoid rewriting the whole project, keep the tokenizer, parser, compiler, and VM separated, add tests after each feature, update the documentation, create examples, fix bugs it encountered, and continue beyond planning into implementation.

It was also given a language-vision document describing what the language was supposed to be: small, readable, predictable, extensible, and useful as a clean execution layer for structured logic and experimentation.

I wasn’t just giving the agent a list of features. I was giving it intent, architecture, priorities, constraints, non-goals, and a quality bar. Even though I did not have the terminology for everything yet, I was already beginning to build the governance layer around the agent.

Six Hours While I Slept

Based on my recollection, I started the run at around 11:30 that night. I had to be at work at 7:00 the next morning. At the time, the commute took me at least an hour, so I needed to be awake by roughly 6:00. When I got up, Codex had stopped working about ten minutes earlier.

Again, those are remembered times, not timestamps I am presenting as forensic evidence. But taken together, the agent had been working unattended for approximately six hours and twenty minutes. I went to bed with a single-file language experiment. I woke up to a completion report saying all five requested priorities had been implemented.

What Codex Said It Completed

Codex reported that it preserved the existing single-file pipeline and made minimal changes rather than forcing an early architectural rewrite.

It said it changed or created the main language implementation, a new test suite, the README, a general feature demonstration, and a Fibonacci/list example.

It reported completing logical operators, adding strings and nil, and creating an extensible built-in registry. It also reported adding list literals, read indexing, and language-style printing.

It also reported adding BOM-safe tokenization so scripts containing a UTF-8 byte-order mark would still parse. And it said it had created seven tests covering the new behavior and run them successfully. That was the report.

Did It Actually Work?

Here is the honest answer:

How would I have known?

I didn’t wake up as an experienced compiler engineer capable of inspecting six hours of agent-generated changes and determining whether every semantic choice, opcode, parser rule, and runtime behavior was correct. I did not even have a Git repository for the language yet.

There were no commits to inspect because this was not supposed to become a real project. It was still a folder containing an experiment. I would not create the actual Git repository until a few days later after I realized this had crossed the line into being a project.

Codex said the tests passed. I could read the summary and see that files had been created. And features had supposedly been added. But that is not the same thing as independently validating the system. That distinction became one of the most important lessons of everything that followed.

At the time, I did not have mature evaluation criteria. I didn’t have the auditing process I would later develop. I did not yet understand how much a test suite could verify while still failing to answer whether the architecture was good, the coverage was sufficient, or the implementation would survive the next stage of growth. The lack of certainty was not a side issue.

It became the reason I eventually needed better tests, better checkpoints, better audits, better repository history, and better ways to distinguish:

The agent says it finished.

from:

I have defensible evidence that the system works as intended.

The Next Morning, I Took It Back to ChatGPT

I wasn’t even home when I began trying to understand what had happened. While I was at work on a break, I showed ChatGPT the completion report from Codex.

ChatGPT looked at the feature list and called it a strong overnight result. It pointed specifically to the short-circuit compilation, the extensible built-in registry, the string handling, and the new test suite.

It said the runtime now had the core of a small scripting language and compared the architecture to the general approach used by established scripting runtimes and educational language implementations.

It also described the division of labor this way:

I had acted as the language architect.

The agent had acted as the implementation engineer.

That description was directionally right.

But there was still a missing role:

Who was the verifier?

At that point, not me. Not in any rigorous sense.

ChatGPT was evaluating a report produced by Codex. I was evaluating ChatGPT’s interpretation of Codex’s report. None of that was yet the same as inspecting the implementation against an independent standard.

That recursive chain of AI evaluation looked impressive.

It was also exactly why I would later become much more serious about evidence.

That first overnight run didn’t prove that Codex had created a flawless language. It proved something more basic and, at the time, more disruptive:

I could give an agent a structured goal, architecture, constraints, and definition of done; go to sleep; and return to a materially changed system. The project had moved forward without my continuous presence. That was different from the ChatGPT loop.

With ChatGPT, I had directed each upgrade through conversation. With Codex, I had delegated a block of execution. The difference wasn’t simply that Codex wrote more code.

It was that the system continued evolving while I was absent. That is the moment this story becomes agentic.

And ironically, it happened because I thought the project was unimportant.

If I had believed I was holding the foundation of a major system, I might have been more cautious. I might have waited until I understood Git, tests, audits, and language implementation well enough to supervise every change.

Instead, the low stakes gave me permission to delegate. Delegation produced enough progress for the project to become worth preserving. A few days later, it became a real repository. Not because I had planned a product launch.

Because the experiment had accumulated enough capability that throwing it away no longer made sense.

The is Beginning of the 2026 Agents Case Study Series

The 2025 ChatGPT Case Study Series documented what happened when I learned to think, learn, create, and execute through sustained collaboration with an AI model.

This new series begins at the point where that collaboration changed operating modes. ChatGPT helped me recognize that programming languages were formalized frameworks for logic execution. It helped me progressively turn that recognition into a language.

Then it helped me define the first substantial job I would delegate to Codex.

Codex continued operating on the system while I slept.

And the very first result exposed both sides of agentic execution:

An agent can create enormous progress without your continuous involvement.

and:

If you do not have the methods to evaluate that progress, capability can outrun understanding.

That tension did not end after the first night.

It became the work.

Better tests.

Version control.

Architecture.

Audits.

Deployment.

Runtime boundaries.

Governance.

Multiple agents.

Multiple projects.

The question was no longer whether AI could write code.

The question was what it would take for a human being to direct, verify, govern, and ultimately own systems that AI agents could continue building.

That first overnight run was only the beginning.

What’s Next?

In the next article, I’ll explore what happened as the language continued to evolve, what changed when Codex began taking on larger implementation tasks, and how the limitations of the original experiment started becoming impossible to ignore.

The next installment of the 2026 Agents Case Study Series is coming soon.

Explore the Projects

Nodus — The programming language that began as the experiment described in this article. 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.

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.

How Vibe Coding Becomes an AI Teaching Framework (A.I.N.D.Y.): 2025 ChatGPT Case Study Series

Shawn knight — Thu, 05 Mar 2026 03:23:23 +0000

Originally published at https://www.linkedin.com. December 22, 2025

Continue reading on Masterplan Infinite Weave »

Trust Me, You Don’t Know What I’m Talking About: 2025 ChatGPT/AI The Duality Of Progress Series

Shawn knight — Sat, 27 Dec 2025 15:02:31 +0000

2025 ChatGPT/AI The Duality Of Progress Series Logo

When experts default to protocol instead of pattern recognition, we stall the very progress we claim to be building.

THE THREAD THAT PROVED THE THESIS

I posted an observation about image degradation within ChatGPT’s image generation workflows — not a question, not a request for help, but a field-level insight from real usage.

What followed was textbook:

A string of commenters telling me to “just read the system card” or “ask o3 to explain it.”
One person insisted prompt quality and project instructions were the solution, even though that wasn’t the problem I was addressing.
I clarified. Multiple times.
Eventually, I asked: “How does your suggestion actually fix what I described?”

His response?

“Screenshot what I said and ask GPT to explain it to you.”

In that moment, it became crystal clear:

People aren’t misunderstanding what I’m saying. They literally don’t know what I’m talking about.

WHAT PROMPTING CAN’T FIX

There’s a widespread myth in the AI space:

If you write the perfect prompt, the model will behave perfectly.

False.

Prompts do not fix architectural behavior.

They don’t rewrite token context windows.

They don’t force perfect regeneration. And they sure as hell don’t “forget the chat.”

The model doesn’t forget because forgetting isn’t even a true option.

Even with memory turned off
Even with fresh instructions
Even with API-level resets

…the model is still pulling from the entire in-session token context.

That means if you ask it to “do that again” within the same thread, you will get degradation over time.

Not because the prompt is bad.

Not because the instructions are vague. But because you are stacking influence over prior generations, and the model is remapping , not cloning.

DEGRADATION ISN’T A BUG — IT’S A PATTERNED RESULT

You keep telling it “do that again.” It doesn’t remember. It remixes.

That’s why you get:

Blur
Composition drift
Style warping
Token confusion

And that happens no matter how “perfect” your prompt is.

The longer you keep generating in the same chat with the same custom instructions, the more the system folds in unpredictable noise.

You’re not working with a fixed engine. You’re working with a predictive echo loop that gets more distorted the longer it runs.

THE STRATEGIST VS THE PROMPTER

Let’s be clear: I’m not saying this from a place of guesswork.

I’ve spent hundreds of hours running real-world prompts, creative production loops, and system interactions under pressure.

This isn’t me trying to build a better model. This is me trying to use it better.

And the people arguing are often the ones who:

Haven’t used these tools for real-world outcomes
Haven’t tracked degradation over long sessions
Haven’t scaled output across dozens of use cases

They respond to observations with technical prescriptions that miss the point entirely.

And when asked to explain? They refer you back to the model itself.

If your expertise requires GPT to explain it for you, you don’t have expertise. You have memorized protocol.

WHAT THIS REALLY PROVES

You can’t move an ecosystem forward by deferring to documentation.

Progress happens at the edges.

Where things break.

Where the model behaves in ways it wasn’t designed to.

Where users make it do things no manual anticipated.

That’s where I live. That’s what I map. That’s why this work exists.

You don’t improve AI by building in silence. You improve it by documenting the patterns no one else is catching.

And when people talk down to you while proving your thesis in real time?

You let them. Because now you have the case study and the transcript.

THE DUALITY IN MOTION

“If you really think I don’t know what I’m talking about… Trust me — you have no idea what I’m actually talking about. ”

This isn’t arrogance. It’s clarity.

Progress is being made in public, by the ones actually doing the work.

Not the ones quoting the docs.

Not the ones name-dropping tools.

The ones breaking systems, observing behavior, and turning it into usable insight.

That’s the Duality of Progress:

The people who think they understand you usually don’t. The people who don’t understand you usually speak the loudest. And the model — ironically enough — understands you better than most of them ever will.

If this helped you, do one of three things:

✅ Clap so I know to post more.

✅ Leave a comment with your thoughts — I read & respond.

✅ Follow if you don’t want to miss daily posts on AI.

How to Read This Series

New here? Start with → Why I Wrote 100 Case Studies: 2025 ChatGPT/AI The Duality Of Progress Series
Into frameworks? Jump to → 31 LinkedIn Frameworks Mini-Series: 2025 ChatGPT/AI The Duality Of Progress Series
Want AI critique? Read → Experts Don’t Know Shit: 2025 ChatGPT/AI The Duality Of Progress Series
Exploring execution loops? Start here → Execution In Motion: 2025 ChatGPT/AI The Duality Of Progress Series

Shawn Knight is the Founder of The Masterplan Infinite Weave — a disruptive startup designed to prove that institutions and gatekeepers no longer hold the keys to success. He is the author of the 2025 ChatGPT Case Study Series (80+ articles), the 31 LinkedIn Frameworks in 31 Days mini-series, and the 2025 ChatGPT/AI Duality of Progress series, a strategic follow-up exploring AI’s paradoxes through real-world application.

A polymathic systems thinker and self-described Meta-Architect, Knight is also the creator of A.I.N.D.Y. — Designed around The Masterplan Infinite Weave’s execution framework. Powered By The Infinity Algorithm. An MVP designed to help individuals run their lives like high-efficiency corporations. His toolkit includes multiple proprietary AI tools that support personal, creative, and business optimization.

Shawn is a conference speaker, AI life coach, podcaster, and guest voice across platforms. Over the next year, he plans to release at least three major works:

The Duality of Progress
The Laws of AI-Human Synergy
The Master Plan Project (First novel in the Infinite Weave Universe)

These offerings explore how AI affects and amplifies human creativity, ambition, and systems.

While Knight is the engine behind The Masterplan Infinite Weave, he is not its only member. The Duality of Progress will also introduce the musical arm of the initiative, led by CTB Blakkk, namesake of The CTB Blakkk Protocol and A-Duece A former rapper now adding singing to his repertoire. Together they represent the youth and energetic spirit of The Masterplan Infinite Weave.

The Masterplan Infinite Weave is also a multi-platform, AI-enhanced media company — a next-gen content network designed to operate like a decentralized, digital-first TV network. Its reach spans YouTube, TikTok, X, Threads, Instagram, Facebook, Snapchat, SoundCloud, BandLab, and beyond — distributing through the many profiles of Shawn Knight and the broader Infinite Weave ecosystem.

Shawn Knight and The Masterplan Infinite Weave’s Github. That holds his MVP and Open Source collaboration efforts.

The-master-plan.com. Hosts the The Masterplan Infinite Weave’s

Offer Stack. Shawn Knight is contactable. On any of The Masterplan Infinite Weave Socials. He actually reads and responds.