I stopped using git for some small things

I've always used version control. We had Subversion and then moved to git in 2009, self-hosted. All the code I've ever written is somewhere in a version control system, with backups and easy restores.

My sister-in-law is visiting and she's sleeping in my office, and she complained about the light my Razer Core X Chroma makes. That's the eGPU with a 12 GB RTX 4070 in it, attached to a Debian server and running Gemma 4. So I wrote a bit of Go code with an LLM (Qwen 3.6 on my Minisforum with 128 GB of unified memory). It just controls the lights on the Chroma X, and I made it turn them off between 23:00 and 10:00.

I compiled it, ran it and it worked. I mostly skimmed the code. I said what I wanted, and after I told it I didn't want to install any Razer modules and wanted a small Go binary to control it (generally the way I code most of the time now), it gave me the code, I compiled it and it worked. I installed it as a service and I didn't feel the need to commit it to git. I treated it as a throwaway piece of code that I can always regenerate if I need to or if my needs change.

Doing this two years ago would have taken me a few hours of reading and testing and playing around with the Go code, probably breaking a few things in the process, and I would have saved it in git and probably written a blog post about it. But now it's just throwaway code that I treat as easily replicable if needed (and I'm writing a blog post about it anyway, so not everything has changed).

The idea

We used to write assembly. Then we started writing in programming languages, and we never kept the assembly in the version control repository. We kept the code in the programming language and trusted the compilation, and we got improvements every time a new version of the compiler came out, and the compiler ported it to different instruction sets for us as well. I write Go, the compiler turns it into machine code, and I've never once committed the machine code. The Go is the thing I care about, so the Go is the thing I keep.

What happened with the light is that I didn't care about the Go either. What I cared about was what I asked for, the lights off at night, no Razer software, a small binary. The code was a step between what I wanted and the thing running on the server, the same way the machine code is.

So I thought we could in theory just keep a list of decisions and directions and features, and have it improve over time as the quality of LLM generated code improves. Like a spec document that isn't incredibly granular, and then treat the code generation the way we treat the compilation step. The spec gets compiled into code by a model, and the code gets compiled into machine language by the compiler, and you only keep the first one. I think that's the direction we're going in.

It isn't a new idea, and it isn't mine. When I went looking, people had been building it and writing about it for more than a year ^{[6] [7]}, and arguing about it for a lot longer than that. There's a name for it too, spec-driven development, and the version I'm describing is the far end of it, where the spec is the source.

The part I like most is that you'd get the same things we got from compilers. The code base gets better as the models get better, so you build the same spec with next year's model and you get next year's code, the way a new compiler release made the same source faster without anyone touching it. And the same spec can come out in a different language or for a different machine, the way the compiler gave us ARM and x86 from the same source, which is the comparison Sean Grove makes too ^[4]. The features and the quality of the code improve and the thing you wrote, the spec, stays the same size. Maybe this is what spec-driven development will be.

What I think changes

I think the impact, first, is on small utilities. Right now if you want a small thing that runs on its own (turn something off at night, copy new rows from one place to another, send a message when a file lands) and you don't want to write code, you open a drag-and-drop workflow builder like n8n or Make and join boxes with arrows. Those tools exist because writing and keeping a small program was too much work for most people, and for most programmers too, if they're honest about how many of these they've never got round to.

I think for a lot of those, spec-driven development takes over. You just say what you want and why and it gets built, as a small program that does that one thing. The what is the feature. The why is what lets the next build make the right call when something changes, a new API version, a different machine, a better model. And when you want it to do something else, you change a sentence, not a canvas of boxes.

The workflow builders still give you things a paragraph doesn't, somewhere to run it, retries, logs and the logins to most of the apps you use already set up. My light runs on my own server because I have one. For a lot of people that's the harder part, and it's probably where the workflow tools go next.

Who got there first

A lot of people, and the argument against it is older than I am.

Sean Grove's talk is the closest to what I'm describing. His complaint is that with prompting "we keep the generated code, and we delete the prompt", which he compares to how "you shred the source, and then you very carefully version control the binary" ^[4]. That's my eGPU program, except I didn't even keep the binary in git.

Birgitta Böckeler's three levels are the most useful thing I read. Spec-first is writing a spec before the task. Spec-anchored is keeping it after the task, to change the feature later. Spec-as-source is "only the spec is edited by the human, the human never touches the code" ^[2]. What I described is the last one. She tried Tessl, which puts // GENERATED FROM SPEC - DO NOT EDIT at the top of what it writes, generated code from the same spec several times and got different code each time. It got more repeatable as the spec got more specific, which she says "reminded me of some of the pitfalls and challenges of writing an unambiguous and complete specification" ^[2]. Her worry is that spec-as-source ends up with the downsides of both model-driven development and LLMs, "Inflexibility *and* non-determinism" ^[2].

CodeSpeak is the one that looks most like a compiler. You write specs in structured Markdown and compile them to Python, Go, JavaScript or TypeScript, and the specs are what's versioned in git ^[10]. One reviewer rebuilt parts of open source projects with it and turned 221 lines of Python into 23 lines of Markdown. He also found the ratio drops to 3 or 4 times on complex, stateful business logic, and that it doesn't apply to system-level algorithms ^[10].

Spec Kit keeps the code and treats the spec as "version control for your thinking", and says one spec can give you the same component in Rust and in Go ^[6]. Tessl raised a lot of money to build spec-as-source, and CodeMySpec, which sells a competing tool, reports that by June 2026 the framework that regenerates code from specs still wasn't generally available and the company had moved to a registry of agent skills ^[7].

Where I think it works

For small things, today. My spec for the light is three lines.

# chroma-night
Turn off the lights on the Razer Core X Chroma between 23:00 and 10:00.
One small Go binary, no Razer software or modules.
Runs as a service on the Debian server the eGPU is attached to.

If the model writes it differently next time, I don't mind, as long as the light goes off at 23:00. The test is my sister-in-law not complaining.

For a big code base I think the paper from October is right for now. It keeps the spec next to the code and blocks a merge when the two disagree, built on things we already know work, like architecture decision records ^[9]. That's spec-anchored, and it's where most teams can start. I think spec-as-source moves up from small things to bigger ones as the models get better.

What it would look like

Most of the pieces already exist, they just aren't put together this way. If I set up a repository for it today it would have these.

• A spec, loose, with the features and who they're for. Spec Kit's specs, Tessl's spec files and CodeSpeak's Markdown are all versions of this.
• A list of decisions and directions. Why Go, why no vendor modules, what it must never do. Architecture decision records are this already, and they're what keeps the next build from making a different call on something you already decided.
• Tests, written or at least read by a person. This is the one place that has to be exact, and the only thing you review closely, because the code changes every build and the tests are how you know it still does the same thing.
• A lock file. Which model, which version, and if it runs locally, a hash of the weights, plus a hash of what it produced, like go.sum. Changing the model is then a choice you make, you rebuild, run the tests and read what changed in behaviour, not in the code.
• The code, either not committed at all, or committed like a lock file nobody edits by hand.

The lock file is where local models matter. If your compiler is a hosted model, it can be retired and your build goes with it. If the weights are on your own disk, the same spec and the same weights, with a fixed seed and the sampling turned down, get you much closer to a repeatable build. We grade the models you can run yourself on our open weights page, and the two in this story are the kind that would be doing this.

Anchor Terminal is in git, every line of it, and it will be for a long time. This is for the small things.

What's still missing

Non-determinism, mostly. Böckeler saw it with the same spec and the same tool ^[2], and a build you can't repeat is hard to trust and hard to debug.

Review, too. Cloudflare kept the prompts in its commit history and a security engineer still found problems on a quick look, CORS that answers any origin, support for the implicit grant that OAuth 2.1 removed and token IDs with biased output ^[5]. For anything with keys or money in it, somebody reads the code, every build. Skimming is fine for a light.

And Dijkstra's point doesn't go away. The more exact you need the program to be, the more the spec has to say, and at some point the spec is code again ^[1]. I think that point moves further out every time the models get better, and for a lot of the small things people write for themselves, it's already far enough.

For now the light goes off at 23:00 and comes back on at 10:00, my sister-in-law can sleep, and the program isn't anywhere but on that server. If it breaks, I'll ask again.

References

Read on 24 October 2026.

1. [1]Edsger W. Dijkstra, On the foolishness of "natural language programming", EWD667, transcription at the University of Texas. Source for formal texts ruling out nonsense that natural language lets through. cs.utexas.edu
2. [2]Birgitta Böckeler, Understanding Spec-Driven-Development, Kiro, spec-kit, and Tessl, martinfowler.com, 15 October 2025. Source for the three levels, model-driven development, the Tessl header, the repeated generation and both quotes. martinfowler.com
3. [3]Andrej Karpathy on X, 24 January 2023. Source for the quote. twitter.com
4. [4]AI Engineer, Sean Grove, The New Code, AI Engineer World's Fair 2025. Source for "a lossy projection" and both quotes about keeping the code and deleting the prompt. ai.engineer
5. [5]Neil Madden, A look at CloudFlare's AI-coded OAuth library, 6 June 2025. Source for the library being written largely by a model, the prompts in its commit history and the problems he found. neilmadden.blog
6. [6]Den Delimarsky, Diving Into Spec-Driven Development With GitHub Spec Kit, Microsoft for Developers, 15 September 2025. Source for Spec Kit's date, "version control for your thinking" and one spec in Rust and Go. devblogs.microsoft.com
7. [7]CodeMySpec, Tessl Review (2026), The Spec-as-Source Bet. A competitor's account. Source for the framework's closed beta on 16 September 2025, the move to skills on 29 January 2026 and its status in June 2026. codemyspec.com
8. [8]I Programmer, From Kotlin To CodeSpeak, 18 March 2026. Source for CodeSpeak, Andrey Breslav, the alpha and "Maintain Specs, Not Code". i-programmer.info
9. [9]Hartwig Grabowski, The Spec Growth Engine, arXiv, 12 October 2026. Source for keeping code as the main artefact, blocking merges on drift and building on architecture decision records. arxiv.org
10. [10]Pasquale Pillitteri, CodeSpeak, 10x Less Code with Markdown (2026 Review), of alpha 0.1.0. Source for the Markdown specs, the target languages, specs versioned in git, 221 to 23 lines and the lower ratios. pasqualepillitteri.it