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

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

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.

---