TL;DR: AI coding tools have cut coding time by about 30%. The same tools also double the number of architectural decisions buried in every pull request. Teams track lines of code and cycle time. As a result, they miss the silent architectural drift shipping into production. Reclaiming integrity requires treating prompts and PR descriptions as architectural artifacts. Senior architects need the context to own decisions AI cannot make.

Key Takeaways: - AI coding assistants reduce coding time but double implicit architectural decisions per pull request. - Architectural drift in AI-generated code passes tests and linters, then ships silently into main. - PR review must shift from a correctness lens to an architectural lens with three named questions. - Treat the prompt as a living architecture brief, not a throwaway string. - The architect's role did not shrink. It moved up the stack to decision authority.

Engineering leaders are celebrating a 30% cut in coding time from AI assistants. What they're not measuring is even more important. The same assistants are doubling the number of architectural decisions buried in every pull request. Those decisions are going unreviewed.

The 30% figure has become the headline metric for AI coding adoption. It shows up in board decks, vendor pitches, and engineering town halls. It is also one of the least useful signals an architecture can produce.

The same assistants that compress the keystrokes needed to ship a feature also surface unfamiliar patterns. They also surface redundant abstractions and duplicated logic. The result is a doubled count of implicit architectural decisions per PR.

The dashboard problem is straightforward: - Teams track lines of code, PR throughput, and cycle time. - Almost nobody tracks "decisions per merge" or "unreviewed architectural choices shipped to main." - Code reviews get faster because the diff looks smaller. They do not get faster because the reasoning is better.

The result is a codebase that gets shorter on the surface. Underneath, it gets more fragmented. Each new module quietly inherits patterns the team has never agreed on. Two senior engineers looking at the same AI-generated file will often disagree on what abstraction it belongs to. The reason: no architectural intent was ever declared.

If the output looks shorter, why does the architectural surface area keep expanding? The answer is not in the code AI writes. It is in the context AI does not have.

Most AI coding tools operate with limited context. They see the current file, a few related files, and the prompt. They do not see the module dependency graph, the team's prior decisions, or the history of why certain patterns were chosen. That blindness is structural, not a quality bug. It has measurable consequences.

Without the right context, an AI assistant cannot tell a new abstraction that solves a real recurring problem. It also cannot tell one that just looks novel. It generates both with equal confidence.

The code compiles, passes tests, and even reads well in isolation. It does not slot into the existing architecture cleanly. Every prompt is a coin flip on whether the result preserves the system's intent. It may also quietly invent a new one.

This is why code churn has doubled in the AI era. We have covered the broader pattern in our analysis of why AI coding assistants are breaking engineering metrics. The architectural layer is the part most leaders are missing.

Reviewers, sensing the code "works," approve faster. The architectural review is happening with less time per PR. This happens exactly when it needs more.

Anders Hovmøller, a 30-year veteran, captured it precisely: "AI writes most of my code now. The architecture is still mine." The architect's job has not disappeared. It has shifted to a layer most teams have not yet instrumented.

Architectural drift happens when code that compiles and passes tests gradually diverges from the team's intended structure. Each small decision was locally reasonable but globally inconsistent.

AI accelerates this drift in three specific ways: - It introduces parallel implementations of existing functionality. That means two ways to do the same thing, neither officially deprecated. - It invents new abstractions for problems already solved by current ones. This adds layer upon layer of "helpful" indirection. - It places logic in layers that do not match the module's actual responsibility. It scatters business rules across controllers, services, and utilities without a coherent home.

None of these are bugs. None of these are caught by linters, type checkers, or unit tests. They are architectural decisions wearing the costume of routine code changes.

We have written about a related failure mode in how your AI architecture accumulates six abstraction layers you do not own. The mechanism is the same: locally tidy, globally incoherent.

The "mandate context in PR descriptions" rule from leading practitioners is a direct response. PRs now have to explain the human intent, the prompt strategy, and why this approach was chosen. The code alone no longer carries that information.

The lesson is uncomfortable: coding time is a vanity metric. Decisions per merge, abstraction reuse rate, and cross-module consistency are the metrics that actually matter.

The standard PR review asks three questions: does it work, is it tested, does it pass CI. Those questions still matter. However, they are no longer enough.

AI-generated code needs an architectural review, not just a correctness review. The lens is different. The questions are different. The time budget has to match.

Step 1: Require architectural review, not just correctness review. Ask three questions before approval: - Does this code belong in this module? - Does it reuse existing abstractions or create new ones unnecessarily? - Does a similar implementation already exist elsewhere in the codebase?

Step 2: Check for duplication explicitly. AI-generated code should be reviewed against existing implementations of similar functionality. This single step catches the majority of drift in our enterprise engagements.

Step 3: Mandate context in every PR description. When AI generates the code, the description must explain the human intent, the prompt strategy, and why this approach was chosen. No description, no review.

Step 4: Add an "AI-assisted" label to PRs. This signals reviewers to allocate more time and apply a stricter lens. It is a workflow change, not a process change.

Step 5: Track the ratio of "architectural comments" to "correctness comments" in code review. When the proportion of architectural comments falls relative to correctness comments, drift is silently shipping.

This is not a slowdown. The reason is simple: catching drift at review costs minutes. Catching it in production costs weeks.

Teams that instrument architectural review hold their stability numbers while peers do not.

Prompts are the most underused architectural artifact in an AI-native team. Most teams treat them as throwaway strings. The teams with consistent output treat them as living documents. Those documents carry the architecture's intent into every generation.

Four practices separate the two.

Build a living architecture brief that gets injected into every AI prompt. Include the module's responsibility, the abstractions it owns, the patterns it must follow, and the patterns it must avoid. One page, updated quarterly. The brief is not documentation for humans. It is context for the model. Treat it as code, with versioning and review.

For every recurring architectural pattern in your system, such as repository, saga, or anti-corruption layer, maintain a short reference snippet. Tell AI to "match this style." This is more effective than describing the pattern in prose. Models imitate structure better than they imitate rules.

Tell the AI what not to do. "Do not introduce a new abstraction if one exists in module X." "Do not place business logic in the controller layer." These are the constraints that prevent the most common drift patterns. Negative constraints also keep prompt strategies from doubling your team's cognitive debt instead of reducing it.

When a relevant Architecture Decision Record exists, include its number and link in the prompt. AI cannot infer your ADR history. It can respect it when pointed at it explicitly. The ADR is the long-term memory your prompt strategy needs.

Teams that treat the prompt as a first-class architectural artifact see AI-generated code slot into the existing system with far fewer rework cycles. This discipline is what separates teams that ship incrementally from those that accumulate rework debt.

Stop spending architect hours on routine coding decisions. AI handles those faster. The volume has also made them impractical for senior staff to own. Redirect that time to three high-impact activities: - Writing and maintaining the context package described above. - Reviewing PRs through the architectural lens, not just the correctness lens. - Authoring ADRs at the decision points where drift typically begins.

AI is genuinely useful here, but only as a drafter. The architect provides the intent, the constraints, and the final call. AI formats, summarizes, and surfaces alternatives.

This is the right division of labor. It scales in a way that AI-driven codebases accumulating three times more debt does not.

Durable production systems share a common trait: the architect remained the decision authority even as the coder became the AI. The role did not shrink. It moved up the stack.

The pattern is consistent across mature engineering organizations. Tooling varies. Discipline does not.

Coding time drops and stays down, because AI is not redoing what the architecture already provides. Refactoring frequency drops, because new code slots into existing patterns instead of inventing new ones. Onboarding new engineers gets faster, because the architecture is consistent enough to learn rather than reverse-engineer.

The architect's calendar fills with decisions and reviews instead of code. That is what the role was originally designed for.

The trade-off is real: you will review more PRs, more carefully. You will maintain context artifacts you did not have to maintain before. Teams that accept this trade-off ship faster, not slower, in the medium term.

The work that disappears is the rework. The work that remains is the judgment. Judgment is what AI cannot rent.

Q: Why does AI-generated code create more architectural decisions, not fewer?

A: AI coding tools operate with limited context, typically the current file and a few related files. They cannot see the module dependency graph, prior decisions, or existing abstractions.

They cannot tell whether a new pattern is necessary or redundant. The result is locally reasonable code that introduces globally inconsistent choices. This doubles the number of implicit decisions per pull request.

Q: What is architectural drift in AI-assisted development?

A: Architectural drift is the gradual divergence of working code from the team's intended system structure. AI accelerates it by generating parallel implementations, inventing unnecessary abstractions, and placing logic in layers that violate the module's responsibility. None of these are caught by tests or linters. That is why drift ships silently.

Q: How should you review AI-generated code differently from human-written code?

A: Apply an architectural review lens, not just a correctness review.

Ask: Does this code belong in this module? Does it reuse existing abstractions or create new ones? Does a similar implementation already exist?

Require PR descriptions that explain human intent, prompt strategy, and why this approach was chosen. Track the ratio of architectural comments to correctness comments to detect silent drift.

Q: Can AI help write Architecture Decision Records (ADRs)?

A: Yes, but only as a drafter. AI is well-suited to formatting, summarizing, and surfacing alternatives against a fixed template.

The architect must own the intent, the constraints, the trade-off analysis, and the final decision. Treating ADR drafting as a one-prompt hack is how architectural reasoning gets outsourced to a tool that does not have your context.

Q: Should AI be allowed to make architecture decisions on its own?

A: No, not yet. AI lacks access to your module dependency graph, the history of why patterns were chosen, and the cross-team constraints that shape real architecture.

It can propose and draft. However, the decision authority should remain with a human architect. The most durable enterprise systems share this discipline.

See this lens in action during a 14-day Levitation pilot.