AI Coding Agents Don't Fix Bad Architecture. They Amplify It.

Every team using AI coding agents right now is running the same natural experiment, whether they realize it or not. Same models, same prompts, wildly different results. Some teams ship agent-generated PRs that need a light review and go straight to merge. Others spend more time untangling what the agent broke than they would have spent writing the code by hand.

The instinct is to blame the model, or the prompt, or the developer’s skill at “AI-assisted workflows.” I think that’s mostly wrong. What actually separates those teams is architecture, and the agents are just the fastest, most unforgiving auditor your codebase has ever had.

The agent doesn’t know what you know

A senior engineer working in a messy module carries a mental model that never made it into the code: “don’t touch this function, it’s called from three places that assume synchronous execution,” or “this field looks unused but the mobile client still reads it.” That tribal knowledge is exactly what lets experienced humans move safely through architectural debt that would sink anyone else.

An agent has none of that. It only has what’s actually expressible in the code, the types, and the tests. If your architecture depends on unwritten rules to stay correct, the agent will break those rules with total confidence, because nothing told it not to.

This isn’t a new problem. It’s the same problem code review has always had with implicit invariants. AI agents just apply pressure to it constantly, at a volume and speed that makes the gaps impossible to ignore.

Coupling is where it falls apart

The clearest failure mode I’ve seen: an agent asked to add a field to a response object, a completely reasonable, scoped request. In a well-bounded codebase, that’s a one-file change plus a test. In a codebase where the same struct gets serialized three different ways, cached with implicit assumptions about its shape, and partially mirrored in a separate client-side type that nothing keeps in sync, the agent makes the change exactly as asked, and it’s wrong. Not wrong in a way that throws an error. Wrong in a way that ships, because it compiles, passes the tests that exist, and looks like exactly what was requested.

The tell isn’t a crash. It’s a change that’s locally correct and globally broken, and nothing in the codebase was structured to make that failure visible.

// The agent sees this and does exactly what was asked
interface UserResponse {
  id: string;
  name: string;
  status: string;
}

function toResponse(user: User): UserResponse {
  return { id: user.id, name: user.name, status: user.status };
}

// It doesn't see this, three files away, keyed on the same shape
function cacheKey(resp: UserResponse): string {
  return `${resp.id}:${resp.status}`;
}

Add a field to UserResponse and this still compiles cleanly, TypeScript’s structural typing has no objection. The cache key stays valid, the response looks richer, and the bug surfaces two weeks later as a support ticket about stale data. A human who’d been burned by this before might pause. The agent doesn’t care.

Tight coupling used to be a maintenance tax you paid gradually, in slower onboarding and occasional bugs. Agents collect that tax all at once, on every task, because they don’t have the accumulated caution that keeps humans from touching the wrong thing.

Explicit contracts are a force multiplier, not a nice-to-have

The teams getting real leverage out of agents tend to share a few traits that have nothing to do with AI: strong types, narrow interfaces, dependency injection over global state, and tests that actually encode the invariants that matter rather than just checking happy paths. None of this is new advice. It’s the same advice good architecture books have given for two decades. What’s different is the payoff is now immediate and measurable, instead of theoretical.

If your types make illegal states unrepresentable, an agent literally cannot generate the invalid case, the compiler stops it before you ever see the PR. If your module boundaries are real boundaries, enforced by the language or the build system rather than by convention and a comment saying “please don’t import this directly,” the agent can’t quietly reach across them. Every architectural discipline you already knew you should have gets a second, more urgent reason to exist: it’s the difference between an agent that’s a multiplier and one that’s a liability.

Tests are the other half of the contract

Types tell an agent what shape data can take. Tests tell it what the code is supposed to do. A codebase with real behavioral tests, not just coverage-padding assertions, gives an agent a way to check its own work before you do. A codebase where tests mock everything and assert that the mocks were called gives the agent nothing. It’ll pass those tests while breaking the actual behavior, because the tests never encoded the behavior in the first place.

This is worth saying plainly: if your test suite wouldn’t catch a regression when a human introduces it, it won’t catch one when an agent does either. Agents don’t lower your bar. They just stop letting you pretend the bar was higher than it was.

What this actually means for how you build

None of this is a case for rewriting your codebase before you let an agent near it, that’s not realistic and it’s not what I’m suggesting. It’s a case for noticing where the agent struggles and treating that struggle as a signal, the same way a new hire’s confusion about a module is a signal, except faster and less politically fraught to act on.

If an agent keeps breaking something in the same corner of your codebase, that corner has more implicit coupling than anyone’s been willing to admit. Fix the boundary once, and both the humans and the agents working there get faster. Fix it never, and you’ll keep paying an “AI tax” that has nothing to do with the AI, just a bill for architectural debt finally coming due.

The models will keep getting better. That’s not going to save codebases that only worked because of what experienced humans knew not to touch. Good architecture was always going to be worth the investment. Agents just moved up the due date.