Day 5 — The First Code

An image-composition experiment with Nano Banana 2 via Gemini: I fed it two real photos of my studio, told the banana to merge them and make it look like nighttime — and this is what came back. AI is not taking over the world any time soon, I'll tell you that for sure.

Four days in, Fret-o-Matic had rather a lot to its name. It had a name, for one. Four architecture decisions. Two more specifications. A constitution, a source of truth, the beginnings of its own documentation system.

What it did not have, after all of that, was a single line of working code.

Day five is the day that finally changed, and I'd be lying if I said it didn't feel good.

The morning was the last of the unglamorous groundwork. I patched a handful of small gaps that had crept into the governance, archived the documents that had served their purpose and were now just clutter, and formally ratified the last amendment that had been quietly standing between me and the first real task.

It is tidying, mostly — clearing the runway so that when the thing finally moves, nothing trips it. By midday the way was clear.

Catching mistakes on paper

Then the discipline did the most valuable thing it does, which is to catch a mistake while it is still cheap.

Before a single line of the engine was written, the spec for it went to one of my coding agents that I use for spec writing, audits and Quality Assurance (QA), and it came back with two real faults.

One was a build setting that was subtly, fatally wrong — the kind of thing that wouldn't reveal itself until you tried to actually package the software and watched it refuse.

The other was a pair of command-line options that I had decided on days earlier and then, somewhere between decision and document, simply lost.

Both were fixed on paper in minutes.

This is the whole argument for working the way I do: a fault caught in a specification costs you a few edits; the same fault caught in code, a week later, can cost you a day. Catching them on paper is the cheapest victory in software, and I take it every single time.

The first commit

And then, at last, the engine got built.

The coding agent took the corrected spec and produced the skeleton: thirteen Python modules, arranged as a nine-stage pipeline that runs all the way from a raw audio file at one end toward finished guitar tab at the other.

Every stage was there — stubbed, hollow, waiting to be filled in, but present and correctly shaped. Sixteen acceptance criteria, every one of them met. Eight tests, all of them passing.

And then the part I had been four days getting to: the first commit. The first real software of the project, written down into the repository, permanent.

Doing nothing in exactly the right shape

I will be honest about what that skeleton actually did on day five, which is nothing.

You could run it end to end and it would walk politely through all nine of its stages and produce essentially no music whatsoever, because every stage was still a placeholder.

But it did nothing useful in exactly the right shape, and that distinction is the entire point.

The hard part of a pipeline is never any single stage; it is getting the stages to stand in the right order, hand the right things to one another, and agree on what they are passing back and forth. That architecture was now real, and running, and tested.

Filling in the stages is comparatively the easy part — that is just work. Getting the shape right is the bit that takes judgement, and the shape was right.

There was one small bit of housekeeping that wormed its way into the afternoon: I upgraded the version of Python the whole thing runs on, rebuilt the environment from scratch around it, and re-ran every test to make sure the new ground was solid. All still green.

With that, the first task was fully closed, reviewed twice, and committed.

The scaffold was up. The engine had a skeleton, standing in the right shape, doing nothing at all with great precision. Now it just had to learn to hear.

---

Written by Torgrim Nyerrød — May 5, 2026