§ Approach
How we work — and why the order matters.
This page expands the argument you'll have read on the homepage. If you want the short version, the three disciplines on the homepage are the short version. Here, we unpack why each one is a discipline — not a preference.
The inversion.
Conventional delivery orders the work as: design → build → test → refactor. Agents compress the build step to minutes, and for small changes they compress test too. That leaves design as the one step the agent cannot do on your behalf.
The industry response so far has been to route around this in one of two ways: let agents design too (fragile), or keep humans writing every line and trust agents only for suggestions (slow, and it doesn't scale).
We invert the order. Architects settle the system before a line of code is written, and agents operate inside the boundaries the architecture defines. That inversion is the condition under which agentic speed and architectural durability can coexist in the same codebase.
A qualification
What we mean by "architecture."
Most teams hear "architecture first" and recognise themselves in it. Usually that means a diagram in a wiki, a decomposition around what the system does today, a design that's allowed to evolve with the code. For humans, that's often enough. For agents it isn't.
Agents need boundaries the machine can read, contracts the machine can check, and a model that doesn't drift out of sync with the code. Architecture that can't do those three things isn't a rail — it's documentation.
The kind we practise is engineered for the loop: decomposed around where change is likely to land, written down in the repository beside the code, and enforced by tests instead of reviewers.
The three disciplines, in depth
Three disciplines, applied without exceptions.
Architecture first
Decomposition is an architect's act. Architects decide what parts the system is made of, how they depend on each other, and — critically — where the change is likely to come next. That last question is the one agents cannot answer.
Most systems get decomposed by function: auth, billing, catalogue, notifications. It is the easy cut, and it is the cut that rots. We decompose instead by the axes of change the system will have to bend to — new markets, new data sources, new regulations, new integrations. Each axis gets a seam; each seam gets a component. When change comes, it stays local to the seam it was designed to hit, instead of rippling through the codebase.
What the architects produce is a model — components, responsibilities, contracts, the change-axes they protect. It lives in the repository, not on a wiki page that rots beside the code. It is the one artefact agents cannot generate, and the artefact that lets the software stand past the team that built it.
Agent workflows
Contracts, tests, CI, review gates — the workflow is where the model's boundaries become machine-checkable. A contract is an interface, a data schema, a protocol, an error taxonomy: anything that constrains what a piece of code is allowed to do.
Contracts are fixed as part of the design, not as a byproduct of the code. Once a contract is in place, the agent's job is well-defined — and the test that proves the implementation is the contract's first consumer.
Every agent run has a testable boundary. Drift gets caught by the tests the agent runs itself — before the commit, before CI, before a human ever reads the diff.
Taming the agent
Rails are the sum of contracts, tests, and the model itself. They don't supervise the agent; they define the space in which it is allowed to operate.
Inside the rails, the agent has autonomy. It writes code, runs tests, refactors within a component, reads and extends the model. Outside the rails, nothing ships: a pull request that violates a contract, breaks a test, or deviates from the model is rejected by CI, not by a reviewer.
The shift in posture is subtle but important: reviewers stop catching symptoms ("this function is ugly") and start noticing structural issues ("we're missing a contract here"). The rails handle everything below that threshold.
The verification loop
Four phases, in order.
- 01
Design.
An architect commits to the decomposition and the contracts. Any change to the model happens here — before implementation.
- 02
Generate.
The agent produces the implementation, the tests, and the documentation.
- 03
Verify.
Contract tests, property tests, integration tests, and static checks run automatically. A human reviews what remains.
- 04
Integrate.
The change lands in main.
The first time through a component, architects spend most of the time building the rails — contracts, test harness, review checklist. On later passes, when the model grows and the component extends with it, verification is fast: the rails already exist.
Honest boundaries
What we don't do.
- —
We don't ship unreviewed agent output. The rails catch most of the drift; a human catches the rest.
- —
We don't sell you a methodology, a framework, or a tool. The discipline is the product.
- —
We don't brand our approach with someone else's name. The ideas are older than the field they sit in — we apply them without putting a label on them.
What you get
A codebase your team can maintain, extend, and regenerate.
An architecture artifact that stays in sync with the code — because it is the code's source of truth, not a document drifting beside it.
Software that arrives sooner, changes cheaper, and fails in fewer places.