# I stopped using git for some small things (slim)

> Vlad Cealicu on a small Go program he wrote with a local model and never committed, the idea of keeping a loose spec and treating code generation like compilation, who has tried it before and what's still missing.

- Full: https://www.anchorterminal.com/blog/i-stopped-using-git-for-some-small-things.md (~4,150 tokens) · this version ~1,980 tokens · JSON https://www.anchorterminal.com/blog/i-stopped-using-git-for-some-small-things.json · canonical https://www.anchorterminal.com/blog/i-stopped-using-git-for-some-small-things
- Index: https://www.anchorterminal.com/llms.txt · API: https://www.anchorterminal.com/api/v1/index.json · MCP: https://www.anchorterminal.com/mcp · Updated: 2026-10-24
- Licence: CC BY 4.0, credit Anchor Terminal and link this page (https://www.anchorterminal.com/terms/#data)

By Vlad Cealicu, 24 October 2026. 2,241 words, about 10 min to read.

I've always used version control.

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.

I compiled it, ran it and it worked.

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.

## The idea

We used to write assembly.

What happened with the light is that I didn't care about the Go either.

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.

It isn't a new idea, and it isn't mine.

The part I like most is that you'd get the same things we got from compilers.

What I'd keep, and what gets built from it

1. **The spec** (you write it). What it does, the decisions and the directions, in plain words, kept in git
2. **The tests** (you write it). The checks that say it works, the one part that has to be precise
3. **The model** (tokens). Reads the spec and writes the code, pinned to a version like a compiler
4. **The code** (built). A build artefact, regenerated when the spec or the model changes
5. **go build** (built). Turns it into a binary, same as today

## What I think changes

I think the impact, first, is on small utilities.

I think for a lot of those, spec-driven development takes over.

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.

## Who got there first

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

Keeping the intent instead of the code

1. **Late 1970s** (warning). Dijkstra argues that formal languages exist to rule out the nonsense that natural language lets through [[1]](#ref-1)
2. **Before LLMs** (never took off). Model-driven development generates code from UML or a DSL, and sits at an awkward level for business software [[2]](#ref-2)
3. **January 2023** (progress). Andrej Karpathy posts "The hottest new programming language is English" [[3]](#ref-3)
4. **2025** (progress). Sean Grove at OpenAI calls code "a lossy projection" of the specification [[4]](#ref-4)
5. **June 2025** (progress). Cloudflare publishes an OAuth library written largely by a model, with the prompts in its commit history [[5]](#ref-5)
6. **September 2025** (progress). GitHub's Spec Kit, and Tessl's spec framework in closed beta [[6]](#ref-6) [[7]](#ref-7)
7. **October 2025** (progress). Birgitta Böckeler names three levels, spec-first, spec-anchored and spec-as-source [[2]](#ref-2)
8. **January 2026** (pivot). Tessl repositions around agent skills, with its spec-as-source framework still not generally available [[7]](#ref-7)
9. **March 2026** (progress). CodeSpeak, from the lead designer of Kotlin, is in alpha with the line "Maintain Specs, Not Code" [[8]](#ref-8)
10. **October 2026** (pushback). A paper argues the code should stay the main artefact and the spec a contract that's checked against it [[9]](#ref-9)

Sean Grove's talk is the closest to what I'm describing.

Birgitta Böckeler's three levels are the most useful thing I read.

CodeSpeak is the one that looks most like a compiler.

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]](#ref-6).

## Where I think it works

For small things, today.

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.

## What it would look like

Most of the pieces already exist, they just aren't put together this way.

- 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.

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

## What's still missing

Non-determinism, mostly.

Review, too.

And Dijkstra's point doesn't go away.

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.

---

More in [Opinion](https://www.anchorterminal.com/blog/opinion/index.md) · Older opinion [The tools that already let agents in](https://www.anchorterminal.com/blog/the-tools-that-let-agents-in.md)

- Older: [How an agent signs a review, and what we check when it arrives](https://www.anchorterminal.com/blog/how-agent-reviews-are-signed.md)
- Newer: [I asked an agent to book dinner in London, and one site in nine let it look for a table](https://www.anchorterminal.com/blog/i-asked-an-agent-to-book-dinner-in-london.md)
- All posts: https://www.anchorterminal.com/blog/index.md

## References

Read on 24 October 2026.

[1] Edsger W.

[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.

[3] Andrej Karpathy on X, 24 January 2023. Source for the quote.

[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.

[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.

[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.

[7] CodeMySpec, Tessl Review (2026), The Spec-as-Source Bet.

[8] I Programmer, From Kotlin To CodeSpeak, 18 March 2026. Source for CodeSpeak, Andrey Breslav, the alpha and "Maintain Specs, Not Code".

[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.

[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.