When AI generates both code and tests in the same sprint, your existing ceremonies are measuring the wrong things. The fix is straightforward in principle and demanding in practice: human engineering judgment must explicitly verify that generated artifacts meet acceptance criteria before they are merged, not after. Every ceremony — refinement, planning, review, retrospective — needs a corresponding gate that makes that verification visible, repeatable, and accountable.
This is not a workflow optimization. It is a structural change to where engineer cognition gets applied.
What Changes in Backlog Refinement When AI-Generated Code Is in Scope
Refinement must now produce artifact specifications, not just acceptance criteria. A well-groomed story used to define what the feature must do. In an AI-first sprint, it must also define what a generated artifact is allowed to look like — its expected seams, its external dependencies, its test surface, and the conditions under which a generated test is considered independent enough to be trusted.
When an AI model generates both the implementation and the tests that validate it, there is a real risk that the tests are shaped by the same assumptions — and potentially the same blind spots — as the code they cover. Refinement is the earliest point at which teams can surface that risk. Story authors and engineers should jointly answer three questions before a ticket enters a sprint:
- Which parts of this story are candidates for AI-assisted generation, and which require hand-authored logic?
- What does an independent test look like for this story — one that was not derived from the generated implementation?
- What human review is required before a generated artifact is considered a valid input to the sprint?
Teams that skip this work in refinement pay for it at the pull-request stage, where the cost of catching a structural flaw in generated code is significantly higher.
How the Definition of Done Must Expand for AI-Assisted Development
The definition of done for AI-assisted development must include an explicit evaluation of generated artifact coverage, not just a passing CI pipeline. A green build means the generated tests passed against the generated code. It does not mean the generated tests are adequate.
The expanded definition of done should include at minimum:
- Provenance annotation. Every merged file should indicate whether it was hand-authored, AI-assisted, or AI-generated. This is not punitive; it is diagnostic. Teams that cannot distinguish generated from authored code cannot improve their generation prompts, their review process, or their quality baselines over time.
- Independent test attestation. At least one test per story must be authored or meaningfully modified by a human engineer, confirming that the acceptance criteria were validated by a mind that did not generate the implementation.
- Judgment sign-off, not just approval. A PR approval that amounts to "the linter passed and the tests are green" is not a definition-of-done gate. The reviewer must attest that the generated code satisfies the story's intent, not merely its surface syntax.
At InWork, our engineering practice — built on a delivery legacy that traces to Nature Technologies, established in 2005 — treats AI-assisted generation as an input to the SDLC, never a replacement for the judgment layer that governs it. US CTO oversight on every engagement exists precisely to ensure that expanded definitions of done are enforced at the account level, not left to individual contributor discretion.
What the Pull-Request Review Process Looks Like When a Diff Is AI-Assisted
AI-assisted pull requests require a different review posture, not just more time. A reviewer examining a human-authored diff is primarily asking: does this logic correctly solve the stated problem? A reviewer examining an AI-generated diff must also ask: did the model solve the problem that was actually specified, or a plausible approximation of it?
That is a materially different cognitive task, and it requires the review checklist to change accordingly.
Effective AI-generated code review process gates should include:
Verify intent alignment, not just correctness
Generated code is often locally correct and globally wrong. The implementation may compile, pass tests, and satisfy the prompt — while still missing a constraint that was implicit in the story but not explicit in the generation context. Reviewers must trace the diff back to the original acceptance criteria, not just to the prompt that produced it.
Examine the test-to-implementation coupling
If the tests were generated alongside the code, pull them apart analytically. Would these tests catch a plausible regression that the model did not anticipate? If the answer is unclear, the test suite is not done — it is scaffolding.
Flag prompt artifacts
Generated code frequently contains patterns that are statistically common in training data but architecturally inappropriate for the specific codebase. This includes overly generic error handling, dependency choices that mirror common open-source patterns rather than the team's established conventions, and comment blocks that describe what the code does rather than why it exists. These are signals that the generation context was underspecified, and they should trigger a refinement conversation, not just a cleanup commit.
Engineering sprint structure for AI tools must make this review posture a ceremony requirement — documented in the team's working agreements, not left to the instincts of whoever picks up the review.
How Velocity Metrics Must Be Reframed to Avoid Rewarding Volume Over Quality
Velocity in an AI-first sprint measures engineering judgment applied, not story points closed. Teams that adopt AI-assisted generation without adjusting their velocity model will optimize for throughput and discover, several sprints later, that they have accumulated a class of technical debt that is particularly difficult to address: generated code that no one fully owns.
The reframe is not about slowing teams down. It is about measuring what actually matters in an AI-first delivery model:
- Gate throughput over story throughput. Track how many stories passed every expanded definition-of-done gate, not how many stories were marked complete. A story that closed without independent test attestation is not a velocity contribution — it is deferred risk.
- Prompt quality as a first-class metric. Teams that invest in refining generation prompts — making them more precise, more context-aware, more aligned to the codebase's actual constraints — produce better generated artifacts with less review overhead. That investment should appear somewhere in the sprint's accounting.
- Rework rate on generated artifacts. If generated code requires substantial modification at review or shortly after merge, that is a signal about generation quality, not just reviewer standards. Tracking it separately from hand-authored rework gives teams a clear feedback signal for improving their AI-first practices.
Reframing velocity is not comfortable. Teams that have been rewarded for closing points will resist a model that makes the quality of closure visible. That resistance is a leadership and process challenge, not a technical one — and it is one that senior engineering oversight must resolve explicitly.
The Judgment Layer Is the Product
The AI-first SDLC is not about removing engineers from the loop. It is about repositioning their judgment at higher-leverage points: defining what gets generated, setting the criteria by which generated artifacts are evaluated, and maintaining the architectural coherence that no model can derive from a prompt alone.
Sprint ceremonies are the mechanism through which that judgment becomes systematic rather than heroic. Backlog refinement specifies the generation context. Definition of done enforces independent validation. Pull-request review verifies intent alignment at the artifact level. Velocity metrics reward quality gates, not volume.
Organizations that get this right will find that AI-assisted generation accelerates delivery of the right things — because human engineering judgment is finally positioned to define what "right" means before the first line of code is written, not while debugging what the model produced.
That is where the leverage is. The ceremonies are just how you make it repeatable.