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
The systems discussed throughout this series are part of the Masterplan Infinite Weave ecosystem. While not every project has appeared in the story yet, you can explore the technology, examine the source code, and follow its ongoing development.
- Nodus — The programming language that began as the experiment documented in this series. Explore Nodus
- A.I.N.D.Y. Runtime — The governed execution substrate supporting workflow orchestration, persistent execution, memory, and agent coordination. Explore A.I.N.D.Y. Runtime
- A.I.N.D.Y. Platform — The application platform built on the runtime, bringing the underlying capabilities into usable applications and interfaces. Explore A.I.N.D.Y. Platform
- Masterplan Infinite Weave — The broader ecosystem connecting these projects and their ongoing development.
Previous Work
This series builds on the ideas, experiments, and lessons documented in my earlier work.
- 2025 ChatGPT Case Study Series — The original exploration of learning, building, and executing through sustained human-AI collaboration. Read the Series
- 2025 Duality of Progress Series — An exploration of the relationships between constraints, creativity, iteration, and progress. Read the Series
Originally published at https://www.linkedin.com.
Top comments (0)