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
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 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.
Top comments (0)