Koda-C

Inspiration

I've approved pieces of (my own) work whose review I had never read.

The review existed. It was thorough, it was independent, and it had caught something real. And it just never entered my decision process. When I realized that, the mistake itself was not what unsettled me. It was how quietly it had happened. Nothing refused. Nothing complained. The skill system let me skip the one step the whole system existed for.

I am a designer and imaginator, not a coder. I direct products written in C++, Swift, and Rust by working with AI, and over time I developed a session rhythm that kept those projects from losing their ground: brief the work, orient in the code, plan, produce, review independently, summarize, push. The rhythm worked. But it ran on the honor system, mine. Completing a session meant manually copying artifacts and reviews between separate chats, and a review could exist without ever touching the decision that moved the work forward.

Koda-C is being created so that cannot, quietly, happen again.

Why Koda-C matters to me

I have seen a lot of harnesses. Tons of skills. The simplest ones and the most complex ones. I have written both, chained them into flows, and watched those flows fail over and over again.

Part of it is that I am not a person who hands work over. I will not tell an agent setup "build me something like this" and walk away. What I build is personal. An audio plugin, a piece of writing, a piece of software, consciouss AI: I build stuff that matters to me.

Most of what I see coming out of agentic tooling is generic. Better "to-do lists", sometimes impressively complex ones, elaborate connective tissue between "to-dos". A lot of things get done, and they get done fast. But there is no sense of purpose in what is being produced.

Koda-C is a gated harness, and a gate is demanding. To use it with purpose, you need a process, and you need to believe a developed process is worth having. Each skill has to be written by you, for how you want your work done. The reviewer has to reflect what you actually care about in the work. None of that transfers for free. A writing project needs different skills and a different flow than a coding project, which needs something different again from a music project.

That is the interest for me. I wanted to take the most capable models available, have them genuinely work together, and stay in the loop directing them. It is not about getting more tasks done. It is about producing better work.

What it does

Koda-C is a dependency-free, plain-file workflow for AI-produced work. A phase cannot advance until four facts agree on disk:

  1. the phase artifact exists and is non-empty;
  2. an independent review is bound to the artifact's current content hash;
  3. the verdict permits movement; and
  4. that review's unique receipt appears in the owner's approval ledger.

The gate re-derives those facts from ordinary files, every time. Change an artifact after review and the review goes stale. If a review says REVISE, no receipt can override it. Hand it a receipt from another phase and it refuses, and every refusal names the condition that failed, in plain language.

One thing I want to say plainly, because Koda-C says it plainly: the receipt does not prove I understood the review. Nothing on disk can prove that. What it proves is that the review entered my decision loop, so ignoring it is no longer a passive omission. The verdict controls movement; the receipt raises the floor.

The reference workflow runs three persistent, separated contexts. Guide holds the project across sessions. Producer does the work but is closed to my input. Reviewer is my own session conversation, and it independently reviews every phase. Their shared truth lives on disk, never in chat memory I would have to ferry between windows.

How I, Codex, and GPT-5.6 built it

Koda-C is my first project built with Codex. We started Saturday morning, July 18, 2026, I just stumbled upon the email about the Dev Week and have had this thought nagging me for months, so... about 51 hours later I ran the first complete session end to end, competition-ready core and all. Sleep, meals, and helping my relative move house included; this was no controlled speed benchmark. We spent the days after hardening the recovery paths and the judge experience.

I brought the phase method, the original failure, and the product decisions: one persistent reviewer, review receipts, frozen phase inputs, boundary-only direction, an immutable Git close, owner acknowledgement at every gate, and honest limitations stated up front. Then I let Codex choose its own engineering order. Just to see and experience.

GPT-5.6 Codex turned those decisions into the CLI, the repository-local skills, the Guide/Producer/Reviewer relay, the permission profiles, the recovery mechanics, mutation tests, security boundaries, documentation, and durable evidence. The recorded session ran GPT-5.6 Sol as Producer and GPT-5.6 Terra as the persistent Reviewer. Sol, Terra, and Luna were also run as reviewers against sealed fixtures, with expected results committed to the repo before any of them saw the tests.

The deterministic suite now holds 267 checks. Most of them are hostile: they break gate conditions on purpose, attack receipt binding, mutate files behind the CLI's back, and validate every recovery command the tool ever prints. The suite also covers both Ghostty and manually opened terminal windows over the same runtime.

The session in the video

The video compresses one real 30-minute session to 2 minutes 24 seconds. Partway through, the Reviewer found an unsupported claim and returned REVISE.

That wasn't staged.

Producer stayed blocked, corrected the artifact, received a fresh independent review, and only then passed the gate. The repository preserves everything: the artifact, both reviews, the approvals, the transcript, and the pushed close.

Challenges and lessons

Making a gate refuse in a unit test was never the hard part. The hard part was making the complete human journey survive real mistakes and first-use conditions: terminal permissions, role-start ordering, malformed acknowledgement input, closed windows, and a non-technical owner who should never become the transport layer between agents.

We kept the failures. Every time something broke, it became a dated incident, then a repair, then a regression test. The suite grew up alongside the product instead of staying frozen around the first implementation.

Model serving was not the dominant bottleneck in our recorded work. Across repeated Sol, Terra, and Luna runs, the models responded reliably enough that the harder problems were everything around them: orchestration, provenance, recovery, and human clarity. Capable models do not remove the need for workflow design. In my experience, their speed makes trustworthy boundaries matter more.

I am seriously impressed with Codex, this being the first time I truly used it. Not using my process was a deliberate choice. That is how we started out. I wanted to apply my process to building this, but then I thought, nah, let me see what Codex has got. And it is pretty wild. I was going to say it is human, but it is not human. It is like any other LLM. It forgets things. It hallucinates. It believes it has done things it has not done. And the whole reason Koda-C exists is for that not to happen when you build something that matters to you.

What comes next

The long-term direction is a compiled, headless Rust core with the interfaces kept separate from it. A macOS client may come first, but terminal, browser, editor, mobile, and remote should all connect to the same evidence contract. The disk-separated roles also leave room for adapters where different providers occupy Producer and Reviewer. That is a future direction, not a claim about this Codex-only release.

What will not change is the premise. A review that never enters the decision is not a review. Koda-C is just a seed to something bigger.

Built With

Share this project:

Updates