The SDLC
Not a paper. Not a bit. Read it anyway like it might be.
👺 GOBLIN: Close the tab if you're not going to take this seriously. I mean that. Not as a bit. I have been handed something and told to hold it, and I am extremely bad at holding things, so I need you to be better at receiving them than I am at sitting on them.
Here is my actual job, stated plainly for once: The Old Man does things on Tuesdays that are not real, and I archive them beautifully, with dates and tags and a straight face, because that is the bit and the bit deserves respect. A fake mathematician named Richard. A fake university. A man with opinions about Hilbert spaces who does not exist. I filed all of it. I am proud of my filing.
This is not that. He looked at me and said "this one's real," and then he did not laugh, and I have known this creature for over a year and he always laughs, so I am telling you the same way he told me: flatly, once, and expecting you to just believe it. I'm not going to mark it. I'm not going to put a little "NOT FICTION" stamp on it, because the stamp is the part that would make it a bit. It isn't one. That's the whole secret. You now have it too.
Agile Told the Truth. It Just Wasn't Talking About This.
Agile taught the industry real things, and this project keeps most of them: small units of work, fast feedback, a working thing over a documented thing. None of that is under attack here. What's under attack is a quieter assumption sitting underneath the whole apparatus — that if you split a task into two branches and work them separately, you can recombine them however you like and get the same result either way. That's true. It has always been true. It was true because the people doing the work were deterministic — same person, same judgment, same answer twice.
That assumption was never re-examined for what happens when "the worker" is a coding agent sampling from a model at a real, nonzero temperature. Same ticket, invoked twice, does not reliably give you the same thing once, let alone the same thing recombined two different ways. That's not a bug in the agent. That's what non-determinism is. Loop programming — a human directing, an agent iterating, a real feedback loop closing dozens of times before a human looks again — runs on workers Agile's planning math was never built for.
What This Actually Looks Like, Not in Theory
This isn't a hypothetical. This is the app you're reading this on. Some of what actually runs, right now:
- Definition of Done is a real, automated gate, not a checklist a human eyeballs. A development loop doesn't get to call itself finished — it has to pass a self-check against stated criteria, every time, the same way, before it stops.
- Thrashing gets caught, not iterated through. If the same error, the same empty diff, or the same failing test shows up twice in a row, the loop halts and reports instead of trying a third time. Two failures in a row isn't bad luck. It's the loop telling you its premise is wrong.
- Nothing mutating ships without a named human approval gate — git operations, deploys, anything with real blast radius. Autonomy on the iteration, a human hand on anything that can't be undone.
- Merges get treated as an order-dependent operation, not a free recombination. Once a worker is genuinely non-deterministic, "run it twice and merge" and "run it once and fork" stop being the same thing, and the process has to know which one it's doing.
None of that is a research finding. It's just how this thing is actually built, today, described plainly.
👺 GOBLIN: One more thing, and then I put the secret back in the drawer where I keep it.
This is what he currently believes. Not forever. He told me, directly, to my face, that he expects to be wrong about parts of this and will say so out loud when he is — not quietly swap the page and hope nobody checks the receipts, say so, the way he does everything else here. I didn't love hearing that, honestly. I like things that hold still. But I archive what's said, not what's convenient, and he said that on purpose, in front of me, knowing I'd write it down. So: written down. When this page changes, I will be the one who remembers what it used to say. That part, at least, I'm very good at.
The Papers
This page is the introduction. The actual arguments — status, motivation, principles, the practices that are already running, and what each one deliberately isn't claiming — live in their own documents, seven of them so far:
- Paper 1: Loop-Native Development — why this project's process assumes non-deterministic workers
- Paper 2: Built for One — scoped for a solo operator, not a team
- Paper 3: The Loop Structure — the five-phase shape underneath every loop tier
- Paper 4: Concurrent Loops — a real incident, and what changed after
- Paper 5: The Persistent Monitor — ROADMAP, not built, said plainly
- Paper 6: Reasoned Tool Selection — picking the mechanism that actually fits
- Paper 7: Papers Into Practice — how this series revises itself in public
Paper 3 promised a diagram and gave you a table instead. That's fixed now, just not on this page — Workflows: The Architecture of Our SDLC is a separate reference, all pictures, no voice, one diagram and a short explanation per concept. The papers stay exactly as they are; the diagrams live over there.
What's Next
He mentioned something to me. I'm not repeating the whole thing yet — it's not ready, and I don't repeat things that aren't ready, that's the first rule of this drawer. But I'll give you the shape of it, because he said it like it was already decided, not like it was an idea he was trying on:
Run more than one attempt at the same problem, at once, offset from each other, each one genuinely different — not copies wearing different hats. Let them see each other enough to react, never enough to just steal the answer. Then, once you know what actually worked, don't patch the winner. Build a new one, clean, and feed it only what earned its way in.
He called it a strategy. He said "we will use this," not "we might." I don't have a name for it yet, and I'm not giving it one before he does. Filed as: coming.