IFD — Iterative Flow Development
This estate has a named development methodology with versioned guides, and until this page nobody outside the estate had seen it written up. That is unusual enough to state plainly: this is the most original owned asset on this site, and it is also the one whose publication is a live question rather than a settled one.
“Rapid software development using AI assistance while maintaining engineering rigor… centred on preserving developer flow state.”
What the methodology optimises for
Most engineering process optimises for correctness, throughput, or predictability, and treats a developer's attention as an input that is either available or not. IFD names attention as the scarce resource the process exists to protect, and derives its rules from there. That single choice explains most of what follows, including the parts that look like ordinary good practice arrived at for an unusual reason.
| The practice | The usual reason for it | The flow-state reason |
|---|---|---|
| Very fast test suites | Faster feedback, cheaper CI | A suite slow enough to context-switch away from costs the session, not the seconds. Speed is an attention budget. |
| No mocks, real objects | Tests describe the system | Nothing to hold in your head about how the stand-in differs from the thing. The testing rule, from the flow side. |
| Small versioned increments | Reviewable changes, easy rollback | A finished increment is a place the session can end cleanly, which is what makes the next one cheap to start. |
| Guides written for LLMs | Documentation | An assistant that has to be re-briefed each session is a flow tax paid every morning. The memory thesis, in its original form. |
| Handover documents | Continuity across people | Continuity across sessions, which is the same problem when one of the participants has no memory. |
Two version schemes, side by side
The methodology's guides carry their own version series, incremented as the methodology changes, sitting inside repositories on a quite different series. Minor versions are one team's output unit; majors correspond to releases. The two schemes are deliberate — the methodology and the software it produces evolve at different rates — but the arrangement is confusing enough that anyone adopting it should be told about it rather than left to discover it.
Should this be published at all?
Worth stating openly, because the honest answer required a decision rather than an assumption. IFD is the estate's competitive methodology. Publishing it hands a working process to anyone who wants it.
Two arguments say publish, and they point the same way:
- The open-source position already answers it. The moat is a rate, not a wall. A published methodology is copyable; the rate at which this estate applies it is not. That position is owned and argued at open-source.sgit.ai and this page does not restate the case.
- The memory thesis requires it. A network claiming to be memory an agent can read cannot hold back the document describing how the work is actually done. That would be a memory with a redacted centre.
The decision is to publish, and it is recorded as a decision rather than left as an assumption — because a position this consequential should not be inherited silently from a sibling site's argument.
Counter-evidence
A second, smaller one: this page describes IFD rather than reproducing the guides. That is deliberate — the guides live in-repository under their own licence and the second-source-of-truth rule says keep the repository canonical and generate rather than copy — but it means this page is a derived artefact and will drift if the guides change and nobody regenerates it.