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
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.
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)