Sonith ManakkatA fair question I hear: if an AI can produce a working feature in an afternoon, do we still need agile? My answer, from building small apps with AI help, is yes: keep agile and compress it. The ideas (small steps, real feedback, honest status, one person deciding priorities) matter more when code is cheap to produce, because it is also cheap to produce the wrong thing. This article is general and personal, not a claim about any company or survey. Each section has a plain picture and an Expert view.
The short answer
A classic cycle
- Two-week sprint, planned up front
- Most of the time goes into building
An AI-era cycle
- Two to three day cycles, planned lightly
- Most of the time goes into deciding and verifying
Expert viewAgile is a set of values, not a calendar
The Agile Manifesto's values (working software, responding to change, customer collaboration, individuals and interactions) say nothing about two-week sprints; the sprint is one popular implementation. What compresses with AI is the build step. What does not compress is deciding what to build, checking that it is correct and safe, and learning from real use. So the sensible move is shorter timeboxes with the same feedback discipline, not dropping the discipline.
- 1Product BacklogThe ordered list of work. Its commitment is the Product Goal
- 2Sprint PlanningStarts the Sprint by laying out the work to be performed
- 3Daily ScrumInspects progress towards the Sprint Goal and adapts the Sprint Backlog
- 4IncrementWork counts as part of it only when it meets the Definition of Done
- 5Sprint ReviewInspects the outcome of the Sprint and determines future adaptations
- 6RetroThe Sprint Retrospective plans ways to increase quality and effectiveness
Takeaway. Scrum is a loop of plan, inspect, adapt. A shorter beat keeps the loop and shrinks the time.
What changes and what stays
What stays the same
- A prioritised backlog with one person deciding
- Real user feedback shaping the next step
- Honest, visible status
What changes
- Cycles shrink from weeks to a few days
- Briefs become the main product of planning
- Verification takes a bigger share of the time
Where the time goes
The bottleneck moved: building got cheap, so judgement and checking became the work.
Expert viewWhy the bottleneck moves
When one stage speeds up, the next constraint dominates, which is the idea behind the theory of constraints. If generation is fast, the queue forms at review and testing, and a large unreviewed change is a risk, not an achievement. Teams that ignore this tend to measure output (lines produced) and quietly accumulate defects. Measure flow and outcomes instead: how quickly a small change reaches users safely, and how often changes need fixing afterwards.
The short cycle
- BriefThirty minutes to write the outcome, checks and limits
- PlanAsk the AI for a plan and questions before any code
- SliceWork in small pieces you can review in minutes
- VerifyTests, smoke tests, and a try on a real device
- Ship smallTo a small test group first, not everyone
- RetroFifteen minutes, and the lesson goes into the instruction file
Expert viewCadence options
Scrum can be compressed (short sprints with the same events shortened to match). Kanban with explicit work-in-progress limits suits AI-assisted work well because it keeps the number of open changes reviewable. A shape-up style approach sets an appetite (how much time the idea is worth) and a small team builds within it. Pick one, write it down, and keep the feedback step. For a solo developer, a light Kanban board with a limit of two or three items in flight and a fixed weekly review is usually enough.
Speed is not the same as care. For an honest look at building by describing and accepting without reading, and the checks that make it safe, see Vibe coding explained.
- 1Is the work a steady stream of small requests that arrive at any time?Yes Kanban with work-in-progress limits, so open changes stay reviewable.No keep going
- 2Are you unsure how much an idea is worth?Yes Set an appetite first: a time budget the idea must fit inside.No keep going
- 3Do you want a fixed rhythm with a team and stakeholders?Yes Scrum, with short sprints and the same events shortened.No keep going
- 4OtherwiseA solo developer: a light Kanban board, two or three items in flight and a weekly review.
Takeaway. Pick one, write it down, and keep the feedback step.
A good brief
The brief is where the human adds the most value. A vague brief gives the AI room to invent; a precise one gives you something to check against.
- OutcomeWhat a user can do afterwards, in one sentence
- Acceptance checksSpecific things that must be true, so you can test them
- Out of scopeWhat not to build, which stops scope creep
- ConstraintsRules to respect: privacy, data format, style
- ExamplesOne or two concrete cases, including an awkward one
BRIEF
Outcome: A user can mark a bill as paid from the bill screen.
Acceptance checks:
- Tapping Paid moves the bill to the Paid list.
- Undo restores it within 10 seconds.
- Nothing is sent off the phone.
Out of scope: reminders, editing amounts.
Constraints: keep the existing data format; follow current code style.
Examples: a bill paid twice by mistake; a bill with no due date.
First: read the relevant files, then give me your plan and questions. Wait for my OK.Expert viewBriefs as testable specifications
Good acceptance checks read like tests. Write them so they could be turned into automated checks, and ask the AI to propose tests first. Examples help because they pin down edge cases (empty input, duplicates, boundaries) that models otherwise skip. Keep a brief short enough to review in a minute; if it takes a page, the slice is too big.
Done means verified
- Tests passNew behaviour has tests, old tests still pass
- A human read itThe diff was reviewed, not just accepted
- It runs for realTried on a real device or realistic environment
- SafeNo secrets, no surprising network calls, data handled as intended
- DocumentedNotes and instruction files updated
Review effort scaled to change size
Expert viewSmall changes, trunk-based habits
Small, frequent merges to the main branch (trunk-based development) keep each review manageable and make problems easy to locate. Pair that with feature flags (hide unfinished work behind a switch) and staged rollout (release to a small group, then widen) so that shipping small does not mean exposing everyone to risk. A useful rule: if you cannot explain a change in two sentences or review it in ten minutes, it is too large to merge.
Guardrails that matter more with AI
- Automated testsFast unit tests for logic, a few integration tests for wiring
- Smoke testsScripted taps through the main screens on a device or emulator
- Random-input testingThrow unexpected input at the app to find crashes
- Staged releaseA small test group sees it before everyone does
Expert viewTest strategy as the safety net
The test pyramid (many fast unit tests, fewer integration tests, a handful of end-to-end tests) is a good default. Two techniques suit generated code especially well: contract tests (check that components honour the agreed interface) and mutation testing (deliberately break the code to confirm the tests notice). Watch for tests that merely restate the implementation, and for an agent that makes failing tests pass by weakening them. Read the tests, not only the green tick.
Instruction files are team process
The most valuable output of a retro is a better written instruction. Each lesson becomes a line in the project's instruction file or a reusable skill, so the next cycle starts smarter. See CLAUDE.md and memory, Skills explained, and Reuse context and share it with your team.
What can go wrong
AI makes planning unnecessary
Planning shifts from estimating build time to writing clear briefs and acceptance checks.
If the demo works, it is done
A working demo hides edge cases. Done means tested, reviewed and tried for real.
Big batches save time
Large unreviewed changes hide defects and make problems hard to trace. Small slices are faster overall.
Feedback can wait until the end
Wrong turns get more expensive every day. Ship small and ask early.
Expert viewSecurity and parallel work
Generated code needs the same security review as any other code, and a little more suspicion: check dependencies the AI suggests, input handling, authentication and secrets, and any new network calls. Running several agents in parallel can be productive but creates merge conflicts and review overload; limit parallelism to what you can review, and give each agent a separate slice and branch. There are two working modes: pair mode (you steer step by step) for unclear or risky work, and delegated mode (the agent works from a good brief and you review the result) for well-defined slices.
A sample weekly rhythm for a solo developer or small team
| Day | What happens | Output |
|---|---|---|
| Monday | Pick the next slices, write briefs (30 minutes each) | Two or three briefs |
| Tuesday and Wednesday | Build, verify, ship one small slice to the test group | A released slice |
| Thursday | Build and verify the next slice, read feedback | A second slice, feedback notes |
| Friday | 15-minute retro, update instruction files, tidy the backlog | Better instructions, a clean backlog |
Expert viewMeasuring without fooling yourself
DORA, a long-running software delivery research programme, defines these delivery metrics (checked at dora.dev on 2026-10-21): change lead time (the time for a change to go from committed to version control to deployed in production), deployment frequency (how many deployments over a period), failed deployment recovery time (how long it takes to recover from a deployment that fails and needs immediate intervention), change fail rate (the ratio of deployments that need immediate intervention) and deployment rework rate (the ratio of unplanned deployments that happen because of a production incident). They work best as trends within your own team, used to learn, not as targets to hit. I will not quote benchmark numbers here because I cannot verify them.
Faster building is only an advantage if verifying and learning keep up.
Frequently asked questions
So is Scrum dead?
No. Its ideas still work. What changes is how long each loop takes and how much effort goes into briefs and verification.
Should AI write the tests too?
It can draft them, and often does well, but a human should read them and make sure they test real behaviour.
Does this only work for solo developers?
No. Teams add shared instruction files, small pull requests and review habits, and the same loop applies.
Where do I start?
Write one good brief for one small slice, verify it properly, ship it to a few people, and hold a 15-minute retro.