What the rework tax actually looks like
A story estimated at 3 days is picked up by an engineer. Day 2: they open a PR. Code review surfaces a design issue. The PR goes back. The engineer re-architects for 2 days. New PR. New review. The story takes 7 days. In the retrospective, it is described as “more complex than estimated.”
In a team shipping 30% AI-generated code, this pattern repeats on 20–30% of PRs. It never appears in velocity metrics as “design rework.” It appears as cycle time variance, carryover, and missed sprint commitments.
It accelerates. AI tools generate more code. More code means more design decisions. More design decisions with no gate means more violations. More violations means more rework. The sprint plan becomes fiction.
The post-release version is worse
Design violations that make it past code review ship to production. They surface as performance issues, security findings, or behavioral anomalies in the following sprint — or the following quarter.
In post-mortems, these are described as “unexpected” and “hard to reproduce.” They are neither. They are architectural decisions that were made without verification and caught at the worst possible time.
A design violation introduced in sprint 8 ships to production. It surfaces as a behavioral anomaly in sprint 11. The investigation takes 3 days. The fix takes 2. Nobody can explain why it was not caught earlier, because the gate that would have caught it did not exist.
A security policy violation travels through code review and QA. The SAST tool does not catch design decisions. Neither does the penetration test, which tests runtime behavior, not architectural conformance. The finding arrives from a customer.
A performance incident is traced to a service boundary crossed in a PR that passed all quality gates 6 weeks ago. The engineer who wrote it is no longer on the team. There is no record of the design decision or the context that made it a violation.
KPIs that would tell you the truth, but don’t exist yet
The metrics that would make the rework tax visible do not appear in your sprint tooling. They are currently proxied by the wrong numbers, or absent entirely.
The percentage of stories that required rework because a design violation was found during or after code review. This is the number that explains why estimates are chronically wrong.
The share of sprint carryover attributable to design issues discovered mid-sprint. Not complexity. Not scope creep. A PR that came back because the design was wrong.
Production incidents whose root cause is traceable to an undetected design violation shipped in a prior release. The most expensive version of the rework tax.
The ratio of stories completed as estimated versus stories affected by mid-sprint rework. A direct measure of how reliable your sprint plans actually are.
How rkito moves design issues left
The Continuous Design Audit gate runs on every PR. Before code review. Before QA. Before merge. It evaluates the change against the Lenses active for that PR’s service context — curated views of your Steering corpus scoped to the team and code area involved — and produces a specific finding: which Lens, which directive, which boundary, which decision.
Stories that would have hit rework in code review or post-merge are stopped earlier, with a specific finding and a resolution path. The engineer fixes the design issue before the PR enters review, not after it comes back.
PRs that pass CDA arrive at code review already conformant. Reviewers focus on logic and correctness, not architectural intent. The review cycle completes once. The story ships on the original estimate.
Violations are caught before they reach the codebase. The class of production incident that traces to an undetected design decision stops compounding. The post-mortem question of why nobody caught it has a different answer.
The rework events that inflate cycle time variance and drive sprint carryover are caught before they distort the sprint. Estimates reflect actual work. Commitments hold.
Your metrics — and where they can mislead you.
These are the rkito metrics that matter most to your role. Each one removes a blind spot. Each one can also be misused. Read both.
Why your team keeps getting blocked late in the sprint by design review. Low IFR = structural changes built before architectural approval. High IFR = architectural surprises arrive before the first commit, not after the PR.
CHI approval timestamps compared against first commit dates, per sprint.
IFR theater: teams rubber-stamp CHIs in under 2 minutes to improve the number. A product manager who uses IFR as a team performance target without monitoring CRPR is optimising for a metric while destroying the process it was meant to measure.
Why velocity feels high but shipped stable features feel low. Rework cycles from design violations are invisible to sprint tracking. DCS is the leading indicator: declining DCS precedes incoming rework.
Per-sprint CDA audit pass rate from the pipeline.
Do not use DCS to push architects to be less strict. Low DCS means the product direction is diverging from the architecture. The fix is realignment — not loosening the rules that catch the divergence.
How long known design compliance issues sit unresolved. MTTCD = 9 days means every blocked PR waits 9 days — the direct, measurable cause of sprint delivery unpredictability.
Time from CDA BLOCKED status to resolution, averaged across trailing 30 days.
MTTCD spikes near release dates are timing artifacts. Normalize over 90-day windows. Do not use MTTCD to pressure architects to approve faster — the goal is faster resolution of the architectural question, not faster rubber-stamping.
On the roadmap
The current rkito CDA gate produces per-PR findings and a conformance result. The following PO/PM-facing capabilities are on the product roadmap and are not yet available.
Rework prevention rate, sprint CDA pass rate, and delivery predictability trend in a single view. The numbers that explain why this sprint looked like the last one.
Flag user stories at planning time that touch components with high CDA violation rates against their active Lenses — service areas where recent PRs have consistently violated the Steering constraints that apply. Know which stories carry rework risk before the sprint starts, not after the PR comes back.
Before a sprint starts, identify which stories touch service areas with active Lens violations or high CDA finding rates. Build that context into the estimate rather than discovering it on day 2 of development.
CDA conformance as a release quality criterion. No release ships with open architectural violations. The post-release incident from a design decision made 6 weeks ago becomes structurally impossible.
Design violations are not a technical problem you should be shielded from. They are a delivery risk that is currently invisible in every metric you track. The sprint that feels unpredictable usually has a design issue at the root. Now there is a gate for that.