The method on AIgile

The working loop

Mon, 01 Jan 0001 00:00:00 +0000

Every aigile team runs the same loop, whatever its size or level of automation.

The forward flow has seven steps. A human writes the intent. The feature is cut into slices. Each slice gets a one-screen spec. An agent builds the slice. The change is reviewed as one unit. A human checks the running software at defined points. A retrospective sorts what was learned into the right documents.

Slicing the work

Mon, 01 Jan 0001 00:00:00 +0000

Slicing sets the pace of everything else in the method. Review stays honest only when a change fits one sitting. An agent stays coherent only when a slice fits one session. Demos happen only when every slice can run end to end. And a wrong decision costs one slice only when slices are actually small. For these reasons, slicing deserves more attention than it usually gets, and this page covers the how and the why.

The artifact layers

Mon, 01 Jan 0001 00:00:00 +0000

Agents keep nothing between sessions; every context window starts near zero. Some written knowledge layer is therefore necessary. At the same time, writing everything down and keeping it all current fails on cost, because a document pile grows until nobody can afford the upkeep, and then it decays all at once. Aigile handles this tension by splitting all project documents into three layers, each with its own maintenance rules.

The constitution

Mon, 01 Jan 0001 00:00:00 +0000

The constitution is a one-page statement of the project’s binding rules. Because every agent reads it at the start of every session, a wrong sentence in it affects all ongoing work at once, and for that reason this document gets stronger governance than any other artifact in the project.

What goes in

A single test decides admission: would violating this statement justify stopping work? If not, the statement is a preference rather than a rule, and it belongs somewhere else. Here are a few clauses from an order system’s constitution:

Deviation and drift

Mon, 01 Jan 0001 00:00:00 +0000

Specifications and systems drift apart over time. People and agents discover mid-build that a spec is wrong, hotfixes slip in outside the loop, and assumptions quietly go stale. Aigile treats all of this as a normal part of the work. Experience with earlier methods suggests that teams which treat drift as shameful end up with hidden drift instead of less of it, so the goal here is fast detection and repair rather than a spotless record.

The validation architecture

Mon, 01 Jan 0001 00:00:00 +0000

It helps to keep two questions apart. Verification asks whether the system was built as specified, and it has something to check against: the tests, the spec, the constitution. Agents handle it increasingly well. Validation asks whether the specified system is the right one, and the only reference for that question is human intent itself, including the parts nobody has put into words yet. Those parts tend to surface when a person uses the running software, and for that reason validation stays with humans in this method, at every level of automation. The limit comes from the structure of the question, so it does not shrink as models improve.

The authority matrix

Mon, 01 Jan 0001 00:00:00 +0000

Discussions of agentic development often assume two separate modes: a collaborative one, where humans take part in every check, and a fully agentic one, where agents run the delivery. Aigile describes both with one structure. A close look at the fully agentic end shows that humans still own the intent there as well; what differs between the two is who performs each kind of check. That is a setting per checking layer rather than one big switch, and the figure below shows the layers with typical positions for both setups.