Architecture review when half the code was generated

Classic review hunted style and cleverness. With AI in the loop, volume rises and local quality often looks fine while structural mistakes hide in plain sight: new coupling, silent schema drift, duplicated domain logic under new names. A pull request can be well-formatted, well-commented, and still wrong for the enterprise.

Architecture review has to evolve from reading every line to interrogating fit. That is not lowering the bar. It is aiming the scarce human attention where failure is expensive.

Ask different questions

Does this change respect the capability boundary? Which invariants still hold? What happens when the model or library version moves? Is there an exit path if the AI-assisted path stalls? Who owns the new concept introduced in this diff?

Demand diagrams or decision notes for anything that crosses trust zones, persists new entities, or alters customer-facing behaviour. Diff size is not a severity score. A twenty-line change to authorization can matter more than a thousand-line generated DTO layer.

Also ask what was deleted or simplified away. Assistants are eager to “clean up” quirks. Some quirks are load-bearing: a strange validation that encodes a regulatory edge case, or an odd retry that survived a partner’s broken API. Reviewers should treat unexplained deletions as suspicious.

Make review scalable

Automate the boring checks: formatting, dependency licenses, secret scanning, contract tests, static rules for banned packages and disallowed regions. Reserve human review for ownership, risk, and fit to the target operating model.

Establish review lanes. Routine changes inside a bounded context with green contracts can use a lighter path. Changes that create a system of record, expose a new external interface, or touch payment and identity need architecture eyes even if the code “looks fine.”

Publish a short checklist that reviewers actually use. Long quality manuals get ignored. Five questions that map to your principles beat fifty that do not.

Evidence over vibes

Generated code often arrives with confident comments. Confidence is not evidence. Prefer executable proof: contract tests against the real interface, property tests for invariants, migration dry-runs, and evaluation cases for any probabilistic component.

When a change claims to preserve behaviour, require a characterization suite before the refactor lands. When it claims to improve latency or cost, require a measurement plan. Architecture review should be allergic to unmeasured claims dressed as engineering judgment.

Social dynamics

AI-assisted authors may not fully understand the code they submit. That is a process smell, not a personal failing. The review culture must make it acceptable to say “I generated this; here is what I verified.” Hiding the tool creates cargo-cult ownership.

Conversely, reviewers should not reject work merely because AI was used. Reject work that lacks verification, violates boundaries, or invents parallel architectures. The standard is fitness for the estate, not purity of authorship.

Keep the enterprise story intact

Architecture review is still the agreement between business and IT. Generation does not waive it. If reviews only optimize for merge speed, you will ship a coherent-looking codebase that cannot answer who owns the customer journey or why three services compute the same premium differently.

Hold the line on the target shape. Local elegance that fractures the enterprise story is not a successful review—it is a missed one.

How this plays out in delivery

In practice, the difference between a slide and an operable change is whether teams can point to owners, controls, and evidence under pressure. That pressure arrives as an incident, an audit question, a vendor outage, or a steering committee that wants to scale a demo. If those answers are improvisations, the feature was never production-ready—regardless of how polished the interface looked in a pilot.

Delivery leaders should therefore reserve explicit capacity for the boring work: contracts, runbooks, evaluation packs, fallback paths, and decision records. Boring work is what makes ambitious AI and platform change survivable. Skipping it to protect a velocity chart is how organizations repurchase the same programme every three years under a new name.

Questions worth asking in design review

Who owns the outcome after launch? What fails first when the dependency is slow or wrong? Which data classes are in motion, and under which policy? What would make us pause or roll back within an hour? What evidence will we examine weekly to know quality is holding?

If a proposal cannot answer those questions without hand-waving, keep the scope in a controlled experiment. Experiments are useful. Unowned production traffic is not an experiment—it is a risk acceptance you forgot to record.

Working habits that keep quality compounding

Write short decision records when you cross a boundary. Keep a living list of invariants for each critical capability. Review with a checklist that targets blast radius rather than style. Instrument silent failure modes, not only HTTP errors. Revisit model, prompt, and vendor changes with the same seriousness as database migrations.

None of these habits require a new framework brand. They require leadership attention and a refusal to confuse demos with operable systems. Teams that practice them can adopt assistants, agents, and new platforms without losing the enterprise plot.

A note on language and accountability

Replace slogans with operational nouns: capability, owner, control, fallback, evidence, exit. Language shapes governance. Teams that speak only in broad transformation slogans struggle to assign accountability. Teams that speak in capabilities can fund, staff, measure, and stop work when the evidence says stop.

Hold that vocabulary in architecture forums and programme boards. Over time it becomes the shared spine that lets software development absorb AI tools without fragmenting into disconnected experiments.

Closing

The through-line is simple: treat AI-related change as architecture and operations work, not as magic. Make ownership explicit, put uncertainty where blast radius is acceptable, measure what can silently fail, and refuse to scale what you cannot run. That discipline is how software organizations get durable value from new techniques instead of a temporary theatre of progress.

Sample checklist for AI-heavy pull requests

Intent written by a human in five lines. Capability and owner named. New or changed external interfaces listed. Data classes and residency called out. Invariants that must still hold. Tests or evals that prove them. Explicit note on what the assistant generated versus what was hand-verified. Rollback path.

If any item is blank for a cross-boundary change, the review is not ready. That is not bureaucracy. That is how you keep volume from defeating judgment. Inside a well-tested module with no new dependencies, a lighter path is fine. Match ceremony to blast radius.

Handling disagreements

Authors sometimes defend generated structure because “the model suggested a clean pattern.” Clean relative to what? Patterns must fit the house style and the target architecture, not a generic textbook service layout. Reviewers should be allowed to require alignment even when the generated code is locally elegant.

When disagreement persists, escalate to the decision record. Either the ADR already forbids the pattern, or you are proposing to change the ADR. Do not resolve enterprise questions inside a single pull request comment thread under time pressure.

Review load and staffing

AI increases diff volume. If you do not change staffing or automation, review quality collapses. Options: more architects on rotation, stricter paved roads that reduce novelty, stronger pre-merge fitness functions, and splitting mechanical generation from semantic PRs.

Measure review latency and escaped defects together. Fast merges with rising production pain mean you optimized the wrong variable. Slow merges with no learning mean your checklist is theatre. Aim for fast on low risk, deliberate on high risk, and continuous improvement of the gate itself.

Putting it into the operating rhythm

None of this sticks if it appears only in a one-off workshop. Put the checkpoints into existing forums: design authority, risk intake, sprint reviews, and operations reviews. Assign named owners. Review the same metrics until the behaviour becomes muscle memory. Tools change. Operating rhythm is how architecture survives tool change.

When you expand scope—new channel, new market, new model provider—re-run the same questions rather than assuming last quarter’s controls still fit. Scope expansion is where quiet regressions hide. A short re-certification beats a long incident report.

What good looks like after six months

You can name owners for each AI-touched capability. You can show evaluation trends and cost trends. You can pause a feature without heroics. Engineers can explain the boundaries without opening a chat history. Sponsors hear outcome language and evidence, not only model brand names. That is the standard. Aim for it deliberately.

Field notes from programmes that stuck

The programmes that keep their gains share a few unglamorous traits. They name a single accountable owner for each capability touched by AI or platform change. They keep a thin evidence pack current: what the feature does, which data it uses, how quality is measured, and how to pause it. They review cost and quality on a fixed weekly or biweekly cadence instead of waiting for a quarterly surprise.

They also refuse to expand scope while basic controls are missing. That refusal feels slow in the week it happens and fast in the year it saves. Sponsors accept it more readily when you offer a dated path: we can widen to segment B when override rates stay under threshold and fallback drills pass. Conditional speed is still speed—just adult speed.

Common failure modes to watch for

Eternal pilots that serve real customers without on-call. Prompt edits in production with no version history. Retrieval corpora that mix clearance levels. Success metrics that count messages sent instead of outcomes achieved. Architecture reviews that only admire diagrams after contracts are signed. Cleanup work that is always scheduled after this critical launch.

Each failure mode is preventable with a small control. The danger is not that teams cannot invent controls. The danger is that delivery pressure makes skipping them look rational until the incident report is written.

A ninety-day improvement plan

Days 1 to 30: inventory AI-touched journeys, owners, and gaps in logging, evaluation, and fallback. Publish the list without blame. Days 31 to 60: close the top three blast-radius gaps; stand up a short design-authority slot for new use cases; put cost alerts in place. Days 61 to 90: run one controlled promotion from pilot to production using a written exit report; kill or contain at least one unmanaged experiment.

At day ninety, present evidence trends rather than tool logos. Leaders can fund what they can see. Visibility is a prerequisite for sustained investment in quality.

How this article should change Monday morning

Pick one capability you touch. Write the owner, the invariant that must not break, the fallback if the AI dependency fails, and the metric you will check next week. Share it with the people who can correct you. Then make one concrete backlog item that turns a gap into a control.

Long articles do not improve estates. Changed operating habits do. Use this piece as a mirror, not as literature. If nothing in your plan of record moves after reading it, the reading did not count.

Further depth for practitioners

If you lead architecture or engineering in this space, keep a personal register of decisions you refuse to leave implicit: where models may advise, where humans must commit, which data products are canonical, and which vendor exits you still believe are feasible. Revisit the register when a programme asks for exceptions. Exceptions are fine. Untracked exceptions become the real architecture.

Pair that register with two drills a year: a model-provider outage drill and a quality-regression drill. Prove you can fail closed or fail to human without inventing the process during the incident. Drills are cheaper than press releases.

Stakeholder conversations that unblock work

With executives, speak outcomes, cost to serve, and residual risk—not model parameter counts. With risk, bring evidence packs and known failure modes early. With delivery, bring paved roads and review checklists that match blast radius. With vendors, bring exit and data-use questions before demos set the emotional agenda.

Most stalled AI and platform work is not stalled for lack of tools. It is stalled for lack of a shared decision. Your job is often to force that decision into the open, record it, and help the organization live with it.

Keep the bar honest

Shipping is not the same as absorbing. A feature that requires permanent heroics is still a prototype, even with thousands of users. Hold the bar at operable, explainable, and pausable. When those three are true, growth is earned. When they are not, growth is borrowed from future incidents.

Long articles do not improve estates. Changed operating habits do. Use this piece as a mirror, not as literature. If nothing in your plan of record moves after reading it, the reading did not count.