AI-Augmented Developer Sprint: discipline at machine speed

What the AI-augmented developer sprint covers

AI assistants changed the cost of producing code, not the cost of owning it. A developer with Copilot or Cursor can produce a week of diff in an afternoon, and none of that changes what the Definition of Done asks for, how long review takes, or how much of the system a team can hold in its head. This module puts you inside that gap. Each scenario is an ordinary engineering moment, a generated migration, a test suite that passes for the wrong reason, a pull request bot that approves itself, and asks what a Developer accountable for a Sprint Goal should actually do.

The first half is about trust. Generated code arrives with the confidence of code that was reasoned about, and reviewers respond to that confidence rather than to the evidence. You practise the counter-habits: reading the diff against the acceptance criteria rather than against the prompt, writing the failing test before accepting the suggestion, and treating an assistant like a fast junior whose work still has to earn its way through the same gates. Teams that skip this step do not get faster. They move the delay from writing to firefighting, which is the more expensive place to put it.

The second half is about Sprint mechanics. Capacity forecasting breaks when typing was never the constraint, so the module works through what to do with the freed hours: shrinking batch size, paying down the review queue, or absorbing the extra verification that AI-heavy work demands. It also covers the Definition of Done in an assisted codebase, where provenance, licence exposure and test meaningfulness become Done criteria rather than architectural nice-to-haves, and where saying an item is Done because the suite is green is the single most common way trust erodes.

By the end you should be able to defend three positions in front of a team and a stakeholder: which parts of delivery AI genuinely accelerates, which parts it quietly loads with risk, and why a Sprint commitment made on assisted velocity still has to be made honestly. The module awards a certificate on completion, and the scenarios are drawn from the same engineering arguments teams are having right now, not from a hypothetical future where the tooling has settled.

Mistakes teams make with this material

Treating a green test suite as evidence

Generated code often ships with generated tests that assert the implementation rather than the behaviour. If the test would still pass with the requirement removed, it proves nothing about Done.

Re-forecasting capacity on typing speed

Assuming a team is two or three times faster because code appears faster. Review, integration, verification and decision-making did not speed up, and those were usually the constraint.

Letting provenance sit outside the Definition of Done

Licence exposure and unclear origin of generated code are Done criteria in an assisted codebase. Leaving them to a later audit turns a Sprint decision into a legal one.

Questions people ask

Do I need to use an AI coding assistant to take this module?

No. The scenarios describe the situation in full, so you can reason about the trade-offs without any specific tool. Teams already using Copilot or Cursor will recognise the moments faster, but nothing depends on having them.

Does this module replace the Developer campaign?

No. It assumes you already understand the Definition of Done, Sprint Backlog ownership and Sprint Goal commitment from the Developer campaign, and extends them to assisted delivery.