The accountability gap
Your team opens 60 PRs this week. 30 are AI-assisted or AI-generated. Your architect reviews 4. The other 56 are reviewed for code quality only.
The 56 contain design decisions. Service boundary crossings. New dependencies. Pattern deviations. None were checked against architectural intent.
When one of those decisions causes a production incident in sprint 8, the post-mortem will trace it back to sprint 3. Nobody will know who made the decision — or whether any human was aware it was being made.
This is not a hypothetical. This is the current state of every engineering team shipping AI-generated code without a design gate.
The hidden costs
Design issues introduced without a gate do not disappear. They surface later — at higher cost, under greater pressure, with less context.
Rework cycles
Design issues surface during code review, forcing re-architecture after implementation. A PR that should have taken one cycle takes three. The engineer re-does work that was already done. The sprint absorbs the cost silently.
Architect bottleneck
The architect becomes the scarce resource for every ambiguous PR. They review PRs reactively, without context, under time pressure. They are not doing architecture. They are doing triage.
Post-merge reversions
Design violations discovered post-deploy require rollbacks, hotfixes, and emergency architecture decisions. The violation was preventable at the PR. The cost of not catching it is an incident, a rollback, and a post-mortem.
Sprint predictability
When stories hit design rework mid-sprint, velocity estimates collapse. The sprint misses. The cause is logged as a delay — not as a design gate failure — and the pattern repeats.
Untracked approved debt
Every sprint, a corner is cut to ship on time. The PR merges with a 'tech debt' comment — no owner, no stated justification, no documented risk. The approved exception is invisible in every metric until the incident it causes six months later. Nobody can trace it back to a named decision.
It’s not just post-mortems
The production incident is the visible failure. But the gate absence costs you every day in subtler forms — in onboarding friction, in exploration that goes off-track, in product work that hits architectural constraints nobody surfaced.
New engineer joins with no architectural awareness
A new hire joins and starts contributing within their first sprint — which is what you hired them to do. They do not know about the ADR that prohibits direct database access across service boundaries. They do not know about the caching constraint established after the incident six months ago. The wiki exists. They have not read it. Nobody checked. Their first three PRs introduce violations that the team will absorb silently or catch in review at cost. This happens on every new hire. The Steering artifacts that would have caught it — assembled into the Lenses covering that service area — were never evaluated against this PR. There is no gate that catches it.
Self-directed exploration becomes the baseline
An engineer prototypes a new capability independently. The prototype crosses a service boundary. It introduces a data flow pattern that was explicitly ruled out twelve months ago. The prototype is good enough — it ships with minor clean-up. The architectural violation ships with it. Without a gate on exploration, the prototype's structural decisions become the production baseline. What looked like a contained spike is now a design commitment.
Product discovery that hits constraints mid-sprint
A product team scopes a new feature without knowing which components are architecturally constrained. The scope looks clean in planning. Halfway through the sprint, an engineer hits a boundary violation, flags it to the architect, waits two days for a response, and re-architects mid-delivery. The sprint misses. The post-sprint retrospective calls it technical complexity. It was actually a planning signal that was never available.
KPIs you cannot currently answer
Four metrics that define engineering quality at the architectural level. None of them exist in your current reporting.
PR rework rate due to design issues
How many PRs required re-work because of a design problem identified after implementation had started? This is the most direct signal of gate absence.
Currently: counted as review iterations. Cause not tracked.
Architect review bottleneck
Average time PRs wait for an architect on design questions. This is the cost of having one human as the only design gate for a team shipping at AI velocity.
Currently: anecdotal.
Post-merge reversion rate from design violations
How often does a design violation discovered after deployment require a rollback, hotfix, or emergency architecture decision? This is the tail-risk metric.
Currently: buried in incident reports.
Design conformance rate by team
What is the CDA conformance rate per team per sprint — the percentage of PRs that passed evaluation against the Lenses active for each team's service area? Which teams are generating the most Lens violations? Which are improving?
Currently: does not exist as a metric.
How rkito addresses this
The Continuous Design Audit gate runs on every PR. 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 the Architecture Ledger, the live baseline of every system component and boundary. It produces a finding or a pass without requiring an architect to be present.
CDA runs before code review
Design issues are found before a human reviewer sees the PR. The engineer knows about the violation at the earliest possible point — when it is cheapest to fix and when re-work cost is lowest.
Architect called only when CDA detects drift
The finding is specific, with full context already attached. The architect is not doing triage across 56 PRs. They are making a judgment call on one finding that requires it.
Conformant PRs flow through without architect involvement
The 47 PRs that were compliant move forward. The bottleneck dissolves for all but the PRs that genuinely require architectural judgment.
Rework moves left
Design issues caught at the gate are not rework. They are a first review cycle that found the problem at the right moment. The three-cycle PR becomes a one-cycle PR.
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.
Design Conformance Score
- The blind spot it removes
- Which teams produce the most design violations, at what rate, and whether it's improving. You have test coverage and code quality grades — but no design conformance rate per team.
- How rkito produces it
- Per-audit pass/fail from the CDA pipeline, aggregatable by team or contributor, per sprint, over any rolling window.
Pillar Drift Trend
- The blind spot it removes
- Directional decay in a specific architectural domain before it becomes visible in the overall numbers. A pillar at 75% PCR with PDT of −12 is deteriorating even though the absolute number looks acceptable.
- How rkito produces it
- PCR computed for the current 30-day window vs the prior 30-day window, per pillar. Delta = PDT.
Intent-First Rate
- The blind spot it removes
- Whether teams are approving design before building or after. Low IFR = engineers writing code before architects have approved the architectural change, leading to expensive rework.
- How rkito produces it
- CHI approval timestamps compared against first commit dates per branch.
On the roadmap
These capabilities are in development
The current rkito CDA gate produces per-PR findings and a conformance result. The following reporting capabilities for engineering management are on the product roadmap and are not yet available.
Engineering manager view
Per-team CDA pass rate and rework prevention rate. The numbers that tell you which teams are drifting and which PRs would have caused rework without the gate.
Sprint-level design health metric
CDA findings per sprint, trend over time. Sprint predictability starts with knowing whether design conformance is improving or degrading across the delivery cycle.
PR-to-incident correlation
Link production incidents back to the architectural decision that caused them. When the post-mortem runs, the trail exists — which PR, which finding, which decision was not reviewed.
Accountability trail
Every design decision has a record: what was evaluated, what was found, who was notified. When accountability is questioned, the record answers.
The question your next post-mortem will ask is not what the code did. It will ask why the architectural decision that caused it was never reviewed. Right now, you do not have an answer.