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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
How often does a design violation discovered after deployment require a rollback, hotfix, or emergency architecture decision? This is the tail-risk metric.
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?
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.
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.
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.
The 47 PRs that were compliant move forward. The bottleneck dissolves for all but the PRs that genuinely require architectural judgment.
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.
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.
Per-audit pass/fail from the CDA pipeline, aggregatable by team or contributor, per sprint, over any rolling window.
DCS is NOT a performance metric. Do not use it to pressure individuals or calibrate performance reviews. It is a system health signal — an engineer working on complex architectural boundaries will naturally produce more Lens findings.
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.
PCR computed for the current 30-day window vs the prior 30-day window, per pillar. Delta = PDT.
PDT of −3 for one sprint is noise. PDT of −3 for three consecutive sprints is a signal. Do not escalate single-sprint PDT declines.
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.
CHI approval timestamps compared against first commit dates per branch.
IFR pressure produces rubber-stamped CHIs approved in under 2 minutes with zero comments. Track CRPR (Comment Resolution Rate per Review) alongside IFR. A high IFR with low CRPR is worse than a moderate IFR with genuine reviews.
On the roadmap
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.
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.
CDA findings per sprint, trend over time. Sprint predictability starts with knowing whether design conformance is improving or degrading across the delivery cycle.
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.
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.