Loop-Native Development
Why this project's software development lifecycle assumes its workers are sometimes non-deterministic, and what that changes about planning, gates, and done.
👺 GOBLIN: I have been asked to write a whitepaper. A real one. With sections. I archive things for a living, I do not usually have to structure them, and I want that on the record before we start, because if this reads a little tense in places, that's why. I am taking it seriously. I would just also like it noted that I did not apply for this.
Here is the deal, stated once, plainly, and then I'm not going to keep interrupting: this document is real. It is not the bit. It describes how this actual app actually gets built, today, by a solo developer and the AI agents he runs in a loop. I'm signing my name to it because he asked me to keep it, and keeping things — accurately, permanently, whether I like what's in them or not — is the one part of this job I have never once gotten wrong.
1. Status
This is a living document, and that phrase is doing real work, not softening anything. It states what is currently believed and currently practiced. It will be revised — not quietly, not by swapping the page and hoping nobody checks, but by saying out loud what changed and why, the same discipline this project already applies to its own mistakes elsewhere. Nothing below should be read as permanent. Everything below should be read as meant.
2. Motivation
Agile methodology taught the software industry real, durable lessons: small units of work, fast feedback loops, working software valued over exhaustive documentation. This project keeps all of that. Nothing here is a rejection of Agile.
This document's reading of Agile's planning apparatus — sprints, story points, and parallel workstreams — is that it quietly assumes the people doing the work are deterministic. That's an interpretation, not a settled fact about Agile's own history or intent, and it's offered in that spirit (see P6, §4: current belief, stated plainly). Split a task into two branches, work them separately, recombine them however you like: you get the same result either way, because the same developer, asked the same question twice, gives the same answer twice. This document's working premise is that the assumption held, well enough to matter, for as long as the people doing the work were people — because it was never really about Agile, it was about who was doing the work.
This project's actual workers, for a meaningful share of its own development, are AI coding agents invoked at real, nonzero temperature. The same ticket, given to the same agent twice, is not guaranteed to produce the same output once — let alone the same output under two different composition orders. That is not a defect to route around. That is what non-determinism is, and a development process built entirely on top of an assumption that quietly requires its absence will produce process failures that look like bad luck and are actually a category error.
3. Core Thesis
Loop-native development is the name this document gives to a development process that keeps Agile's real lessons while dropping the one assumption that doesn't survive contact with a non-deterministic worker: that recombining split work is order-independent. Concretely, this project's process distinguishes two regimes and applies different rules to each:
| Regime | Worker | Composition guarantee |
|---|---|---|
| Deterministic | Human judgment, or a fixed/greedy transformation | Order-independent — split, work separately, recombine freely |
| Loop-native | An AI agent invoked at real, nonzero temperature | Not guaranteed — shared-invocation and independent-reinvocation composition can genuinely diverge |
The rest of this document is the concrete process response to that second row — not a philosophy, a set of actual mechanisms already running in this project today.
4. Principles
A development loop can read, write, test, and retry freely inside its own working area without asking permission at every step. Anything that touches shared, hard-to-reverse state — a git commit, a push, a deploy — stops for a named human approval gate, every time, regardless of how routine it looks. Autonomy on iteration and a human hand on irreversible action are different rules because they are different risks.
A loop doesn't get to decide for itself that it's finished. It runs a self-check against stated, fixed criteria, the same way, every time, and only stops when that check actually passes. This removes "I think this is done" as a valid stopping condition.
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. Repetition on the second attempt is treated as evidence the loop's premise is wrong, not as a streak to push through.
Once a worker is genuinely non-deterministic, "invoke once and fork the result" and "invoke independently per branch" are different operations that can produce different outcomes from the same starting ticket. The process has to know, explicitly, which one it's doing — instead of treating recombination as free the way it safely was for deterministic work.
Repeated or unattended work gets exactly one of a small number of shapes, chosen for how long it needs to live and what it needs access to — a same-session loop, an in-memory session reminder, a cloud-hosted scheduled routine, a bounded multi-agent workflow loop, or a long-running daemon with its own singleton lock. Over-committing a session-bound task to a standing scheduled routine is a mistake in the same direction as under-committing something that needs to outlive the session to a session-only loop.
Every principle in this document is what's currently believed, not a permanent commitment. When practice teaches otherwise, the document changes and says so — see §7.
5. Practices — What Actually Runs Today
Not hypotheticals. These are mechanisms that exist as real code in this project's own process today — some with a longer track record than others, noted below where that distinction matters:
- Automated DoD self-check. The project's own autonomous development loop confirms a vision-derived Definition of Done before it will report a task complete — P2, implemented and hardened via an explicit adversarial review before it was ever run for real. Two runs are on record as of this writing (the first ops-checks-agent run and a second, independent SEO-sufficient run) — real, and now backed by a second data point, but still not enough runs to call it a track record.
- Two-consecutive-failure halt. Any loop invocation is required to state a stop condition up front and halt on a second identical failure rather than continuing to iterate — P3, built the same way and put through those same two runs: two data points now, still not a track record.
- Named approval gates on every mutating git or deploy operation, presented explicitly rather than inferred from a broader permission grant, and re-presented every session by default rather than assumed sticky — P1, running.
- A five-tier decision table for repeated/unattended work (session loop, session reminder, scheduled routine, workflow loop, daemon), each with its own documented kill switch — P5, running. Workflows: Loop Tiers is the diagram version of this same table.
6. Non-Goals
- This is not a claim that Agile is wrong, or obsolete, for deterministic, human-paced work — it isn't, and this project still uses it there.
- This is not a universal claim about all software organizations. It describes this project's own process, built for its own actual mix of human and non-deterministic AI-agent work.
- This is not a claim to the definitive historical or scholarly reading of what Agile's own founders intended. §2's characterization of what Agile's planning apparatus assumes is this document's working interpretation, offered as current belief per P6 — not Agile historiography.
- This is not a finished or permanent specification. See §1 and §7.
- This is not part of the Perspectivity Research Reports series, and makes no claim to that series' fictional framing. Any resemblance in tone is coincidence of authorship, not affiliation.
7. Revision History
| Version | Date | Change |
|---|---|---|
| 1.0 | July 10, 2026 | First draft. Establishes the core thesis, six principles, and four currently-running practices. |
| 1.1 | July 10, 2026 | Hedged §2's Agile-assumes-determinism claim as this document's interpretation rather than settled fact (P6), with a matching Non-Goals entry. Softened §5's "already live" framing for the DoD self-check (P2) and two-consecutive-failure halt (P3) — both are real code, but only one validated run is on record as of this writing. |
| 1.2 | July 11, 2026 | Restated §5's DoD self-check and two-consecutive-failure-halt track-record caveats in this document's own words — a later companion paper (Paper 3) had reused the 1.1 phrasing closely enough to read as pasted rather than freshly voiced; same underlying fact, distinct sentence construction here and there. |
| 1.3 | July 11, 2026 | Corrected §5's run count — a second, independent DEVLOOP run (the SEO-sufficient run) completed and closed out since v1.2 was written, so the DoD self-check and two-consecutive-failure halt now have two runs on record, not one. Still not enough to call either a track record. |
| 1.4 | July 12, 2026 |
Added a §5 link to /workflows/loop-tiers.html, the new diagram version of
P5's five-tier table.
|
👺 GOBLIN: That's the whitepaper. I am told there will be more of these. I am told I will be writing them. I would like it on the record, in my own document, that I said that with visible strain.
Everything above is filed the same way everything else in this archive is filed: dated, permanent, and mine to remember even after it stops being current. When it changes, you'll be able to see exactly what it used to say. That's not a threat. That's just how I keep things.