Continuous flow

Iterative loops and rituals — rhythm without artificial cadence

AIAD loops are not prescribed fixed-duration cycles: their duration is dictated by the actual complexity of the work. A bug fix: two hours. A new feature: three days. A domain exploration: one week. Each task finds its natural cadence.

Fixed-duration cycles create artificial friction with the velocity of AI-assisted development: they produce either over-commitment or padding. Four characteristics define an AIAD loop: continuous flow (as soon as one feature is integrated, the next one starts), variable duration (complexity dictates duration, not the calendar), dynamic priority (feedback can redirect the next feature) and absolute focus (a single feature at a time per PE). What matters is not following a calendar — it is delivering value continuously.

The initialization phase

Before the first loop, an initialization phase lays the foundations — once per product, or at every major pivot. Without it, agents generate code without context and debt accumulates from day one. It produces seven deliverables: the product vision and Product Goal (PM), the initial PRD (PM), the ARCHITECTURE document (Tech Lead), the AGENT-GUIDE (AE + PE), the Definitions of Done (team), the repository with CI/CD (PE) and the first ready SPEC (PM + PE). The team must be able to start implementation between the fifth and the seventh day. Symmetrical anti-patterns: the initialization that drags on for weeks — no artifact is perfect at the start — or the rushed start without artifacts, whose first weeks cost months of debt.

Loop 1 — Plan

The Plan loop turns a business intent into a specification that agents can implement. Without explicit planning, the PE interprets the PM's intent, the interpretation diverges, and the delivered code does not match the need. Five steps: the PM presents the next priority, the PE questions and clarifies, the team decides on the decomposition, writes the SPEC collaboratively, then validates it. It produces a SPEC ready for implementation, defined Outcome Criteria and a shared PM/PE understanding. Indicators: the agent can implement without clarification, expected tests are 100% explicit, all edge cases are documented. Anti-patterns: the four-hour planning marathon as much as the three-line "Add login" SPEC — two anti-investments.

Loop 2 — Implement

This is where value materialises: a PE who orchestrates well produces more than a traditional team of five developers. The loop unfolds in seven steps: prepare the context (SPEC + ARCHITECTURE + AGENT-GUIDE, within the Context Engineering Budget), ask the agent for a plan before coding, validate continuously (compilation, linting, types), generate the tests, iterate if needed — three times maximum —, finalise (green tests, local commit), then carry out the artifact Sync micro-phase.

Indicators: first-time-correct code > 70%, generated/manual code ratio > 80/20, coverage > 80% backend and 70% frontend. Anti-pattern: the PE who fixes 80% of the generated code — a signal of a deficient SPEC or AGENT-GUIDE, not of a bad agent.

Loop 3 — Validate

Code that compiles is not necessarily code that works; code that works is not necessarily code that delivers value. Validation unfolds in five steps with distinct owners:

It produces a validation report, a list of minor fixes where applicable, and the green light for integration. Indicators: first-try validation > 70%, zero critical bugs, fewer than three minor bugs per feature. Anti-patterns: the rushed "it seems to work" validation (hidden debt) and the endless QA/PE ping-pong (needless friction).

Verification is designed, not bought

AIAD bets that the quality of verification depends first on the design of the process — what is checked, when and by whom — rather than on the power of the reviewing model. It is a position, not a demonstrated result: the evidence converges, none of it is sufficient on its own. It translates into four rules:

1. The critical conversation happens first at the Execution Gate. That is where we discuss what we want; code review then checks conformance to an intent already discussed. It remains the place where misunderstandings are detected, not where we discover what we wanted.
2. Two classes of defects. Structurally detectable defects (compilation, types, tooled architecture rules, secrets) are delegated to tooling and agents. Semantic defects — fidelity to intent, business correctness, design boundaries — remain under human review, relying on the Stranger Test.
3. Separate the producer from the critic. When review is entrusted to an agent, AIAD recommends — without mandating it — a reviewer from a different model family than the producing agent: a 2026 study on mathematics problems measured 35% false rejections in self-review versus 2% in cross-review. The cost (several providers, contracts, GDPR analysis) must be weighed.
4. Design before testing step by step. In an agent loop, complete upfront design — architecture, types, edge cases, contracts, in other words a SPEC — appears more effective than incremental TDD, which cost 3 to 8.5 times more tokens with no net gain in an exploratory 2026 experiment. An indication to be confirmed, not a rule.

Review exemplars. An organisation's review knowledge — what a senior reviewer spots and why — can be extracted into annotated examples, versioned in dedicated files (for example .aiad/review-exemplars/) and loaded only in review sessions — not in the AGENT-GUIDE, which is injected into every session and reserved for permanent instructions. An exemplar is built from real reviews, revised like an artifact and retired when it no longer reflects the team's standards.

Verification Tax. A 2026 literature review uses this name for the gap between the productivity gain in writing code and the much smaller gain in delivering reliable software. This is what the upfront investment in the SPEC and the Gate seeks to reduce.

Loop 4 — Integrate

Undeployed code has no value. The loop unfolds in eight steps: code review (self or peer depending on criticality), pull main and resolve conflicts, push, PR and CI/CD, staging then production deployment, post-deployment verification, CHANGELOG and AGENT-GUIDE update, Anti-Drift Check, and context cleanup with ticket closure.

Four deployment strategies are available: Continuous Deployment (non-critical features), Staged Rollout (major features), Feature Flags (experiments, A/B tests) and Manual Release (critical, compliance). AIAD recommendation: Continuous Deployment with Feature Flags. Indicators: merge → production in under one hour (ideally fifteen minutes), rollback < 5%, zero downtime.

Automated deployment: trust is a chain of evidence

Deployment without human intervention is only admissible if the code is trusted in the sense of a verifiable chain of evidence — Intent Statement, SPEC validated at the Gate, traced checks, Drift Lock — and not of declarative trust in the tool or the model. This is the criterion Roblox set for accepting agentic code in production (2026); AIAD makes it the entry criterion for Continuous Deployment of agent-produced code. For an organisation with more modest engineering resources, the practical consequence is to reserve automated deployment for features whose chain of evidence is complete. In the authority continuum, deployment authorisation remains a human act distinct from write authorisation.

Intentional synchronisations

Synchronisations are not ceremonies: they are moments of collective decision triggered by a real need, timeboxed, actionable and documented. Each one is supported by an /aiad command that prepares the data — never replaces the conversation.

• Daily standup (optional, 15 min max — /aiad standup): structured around three SDD questions — which SPEC today? what Context Engineering Budget? any drift to report? Over 80% of blockers resolved within the day.
• Demo & Feedback (weekly, or after each major feature, 30-60 min — /aiad demo): the demonstration is structured by the Intent Statements — first the original why, then what was delivered — before qualitative user feedback and backlog adaptation. Target: more than three actionable insights per session.
• Tech Review (monthly, or after a major architectural change, 1-2 h — /aiad tech-review): checks the coherence between ARCHITECTURE.md and the actual code — pattern drift, undocumented dependencies, ADRs to write, technical debt, agent ecosystem review.
• Retrospective (weekly or bi-weekly, 45-60 min — /aiad retro): a classic retrospective, then an AI retrospective — collecting Lessons Learned (recurring agent errors) and Human Learnings (intent/delivery gaps) fed into the AGENT-GUIDE, along with the iteration metrics (average SQS, drifts detected, first-time success rate). Oversight failures — an agent acting without approval, automated reviews stacked with no human left to decide — form a separate category of Human Learnings, with a dedicated question: "at what point should a human have been consulted, and why weren't they?" One to three actions maximum, with owners.

The Intent Workshop — a purely human space

The Intent Workshop (Atelier d'Intention) is AIAD's fundamental synchronisation: monthly, 60 minutes, the whole team. The other synchronisations ask "what did we deliver?", "does it work?"; this one alone asks the question that the agent cannot ask in our place: "Are we still building what we really wanted to build?" Four phases: reading the Intent Statements out loud (10 min), confronting them with reality (20 min), gap hypotheses (20 min), alignment or revision decision (10 min).

Target: intent/delivery alignment rate > 80%, two to five documented gap hypotheses, 100% participation. Anti-pattern: the workshop drifting into a technical review or a bug post-mortem — the questions stay at the level of intent.

Strategic Alignment synchronisation

Monthly or bi-monthly — or when a Product Goal is reached, or after a pivot —, 1 h 30 to 2 h (/aiad sync-strat), with the PM, PE, Tech Lead, QA, stakeholders and Supporters: outcome review, Product Goal review, backlog prioritisation — including what we decide not to do —, Supporter feedback on organisational obstacles, documented decisions. It relies on the DORA and Flow metrics to adjust priorities.

Loop and synchronisation anti-patterns

• "We plan everything at the start of the week." Back to batch mode: priorities change but the plan is frozen. Plan just before implementing, while the context is fresh.
• "Implementation always takes longer than expected." Insufficient SPECs or a poorly prepared agent context: thirty extra minutes of planning save hours of implementation.
• "We validate at the end, just before the release." Bugs pile up, validation becomes a bottleneck. Validate each feature immediately.
• "We hold every sync every week." Meeting overload: adapt the frequency to the real need, space them out as the team matures.
• "Nobody prepares the syncs." Inefficient improvisation sessions: every synchronisation has an owner who prepares the agenda and the inputs.