The AIAD Manifesto

Many minds plan, one developer builds with AI, everyone tests and solves.

- AIAD Mantra

Definition: AIAD — AI Accelerated Development — is a way of building software in which the whole team plans together, one developer builds every change with AI, and everyone tests and solves problems as the product grows.

Why AIAD exists

Scrum, waterfall and their cousins were designed for a world where code was expensive to write. Typing was the bottleneck, so we split work across many hands and invented ceremonies to keep those hands in sync. Stand-ups, sprint boards, story points, hand-offs and status reports grew to manage the coordination, not the product.

AI has moved the bottleneck. One developer with AI can now produce what used to take a team. What remains hard is not writing code — it is knowing what to build, agreeing on it, and finding out whether it works. AIAD puts the whole team on those hard problems and removes the coordination tax that no longer pays for itself.

We are done paying for:

• Merge conflicts — parallel branches that collide and cost hours to reconcile.
• Divergent understanding — five developers holding five slightly different versions of the goal.
• Ceremony over contact — meetings about the work instead of work on the problem.
• Hand-off loss — intent that fades a little with every ticket, review and transfer.

The core idea

AIAD trades parallel work and orchestration for one fast, linear stream. A developer accelerated by AI builds faster than a team can coordinate, so the team steers instead of splitting the work.

1. Many minds plan. Developers, domain experts, designers, testers and stakeholders shape the project together. Every perspective enters before a line is written.
2. One pair of hands builds. All code flows through a single developer — the Builder — working with AI. One codebase, one branch of truth, one coherent understanding of the goal.
3. Everyone tests, talks, tackles and solves. The rest of the team does not wait for a hand-off. They use the product as it grows, find problems, investigate them and bring solutions back to the Builder.

Because there is only one stream of changes, there is nothing to merge. Because the plan was made together and is executed by one person, there is nothing to drift apart.

What we value

We value:

• Shared understanding over divided workload
• One coherent codebase over parallel branches
• Conversation at the problem over ceremony around it
• Testing the real thing over reporting on progress
• Expertise in the room over requirements on paper
• Fast correction over upfront certainty

The items on the right have their place. The items on the left decide how we work.

Principles

1. Plan together, fully. The whole team shapes the goal, the scope and the hard questions before building starts. No one learns the plan second-hand.
2. One stream of code. Every change reaches the codebase through the Builder. No parallel branches, no merge conflicts, no competing interpretations.
3. AI is the multiplier, not the decider. The AI writes, refactors and explains at speed. The Builder owns every decision and every line that ships.
4. The product is the status report. Progress is shown by running software the team can touch, not by boards, burndowns or percentages.
5. Everyone tests from day one. Experts and developers use the product continuously, in their own domain, as it grows.
6. Problems are swarmed, not ticketed. When something breaks or is unclear, the people who understand it gather, investigate and hand the Builder a solution — not a ticket.
7. Talk beats documents. A five-minute conversation with the right expert beats a five-page specification. Write down decisions, not discussions.
8. Short loops, always. Build a little, test it, learn, adjust. The cost of changing direction stays low because there is only one direction to change.
9. Ceremony must earn its place. A meeting, artefact or process exists only while it clearly helps the product. Otherwise it goes.

Roles

AIAD has three roles. One person may hold more than one, but the Builder role is held by exactly one person at a time. Any team member can take it over at any moment: the work is linear, everyone knows the plan and what comes next, and AI makes the handover cheap.

Developers who are not the Builder are not idle. They review architecture, prototype answers to hard questions, write test scenarios, pair with experts and step in as Builder at any time.

The rhythm

AIAD runs as one tight loop: plan once together, then build and test continuously until the product works.

The short loop between Build and Test runs many times a day. The long loop back to planning runs only when what we learn changes the goal itself. There are no sprints and no story points: the running product shows where we are.

Frequent check-ins steer the line. Every few days the team gathers at the running product with the Builder. Together they review what was done, what it revealed, and what comes in the next days and weeks. This one short session replaces sprint planning, stand-ups and retrospectives.

Where AIAD fits

AIAD is built for short, fast work where speed and one clear direction matter more than scale.

• Hackathons — hours to days, one goal, the whole team in one room.
• Short projects — weeks to a few months, a small team, a clear outcome.
• Early-stage technology at TRL 3–4 — proof of concept and lab validation, where the job is to learn fast whether the idea works.

Large, long-lived products further up the TRL scale need more parallel streams and structure. A project that outgrows AIAD splits into separate codebases, each with its own Builder, or moves to a heavier process.

Honest limits and safeguards

One stream of code is AIAD’s strength and its limit: at any moment, progress runs through one person’s capacity and judgement. We guard that deliberately.

• Bus factor. Decisions are written down as they are made, the AI keeps the code explained, and any team member can take over as Builder at any time. There is one linear history, everyone knows what was done and what comes next, and the AI brings the new Builder up to speed on the code.
• Builder overload. The team protects the Builder’s focus: problems arrive investigated and specific, not as interruptions. If one Builder cannot keep up, the project is split into separate codebases, each with its own Builder — never two Builders in one codebase.
• Blind spots. One person’s judgement shapes the code, so the team reviews architecture and key decisions regularly, and testing covers what the Builder cannot see.
• AI mistakes. AI output is treated as a fast draft. Continuous testing by the whole team is the net that catches what it gets wrong.

AIAD is not one person doing everyone’s job. It is everyone doing the work only they can do, with code flowing through one channel.

Our commitment

We commit to building software the way it can be built now, not the way it had to be built before.

We will plan together until we share one picture of the goal. We will let one Builder, accelerated by AI, turn that picture into code without collisions. And we will all stay in the work — testing, talking, tackling and solving — until the product does what we set out to do.

Less administration. More understanding. One stream of code. The whole team behind it.