Your Coding Agent Has an Architecture Problem

Your coding agent is doing exactly what you asked. That's the problem.

It picks up a ticket, writes working code, passes the tests, and opens a clean PR. Locally, everything is correct. But on the way to that green check, it made a dozen architectural decisions, and it made every one of them blind: blind to the rest of your system, blind to your objectives and constraints, blind to the architecture standards your best people spent years encoding.

I've spent the last few years watching engineering orgs adopt AI coding tools, and the pattern rarely changes. The demo is magic. The first quarter is euphoric. Then, somewhere around the third or fourth month, the mood shifts. Velocity is up, and confidence is down. Teams are shipping more than ever and trusting the system less than ever, and nobody can quite say why. Here's why.

The thing that got faster, and the thing that didn't

AI made one part of building software almost free: writing the code. Throughput exploded. What didn't move is everything above the code. Strategic and functional architecture. System-level reasoning. The judgment about whether a change belongs in this service or that one, whether it respects a boundary or quietly erodes it, and, above all, whether it advances the objective function of the whole organization: the business objectives, the product constraints, the standards and strategy the architecture exists to serve. That still happens at human speed, in a few people's heads, in review comments and hallway conversations.

So the gap widens. Execution runs at machine speed while the decisions that should guide, and then govern, that execution run at human speed. Every coding agent you deploy widens the gap a little more, because it produces more decisions per hour that no system is guiding on the way in or checking on the way out.

But be careful naming the problem. The widening gap is just the symptom; the underlying disease is the lack of tools to make the right architectural calls at AI speed. So teams don't make them at all. Or they make the wrong calls fast. Or they take so long making the right one that by the time they commit, it isn't right anymore: the system has already moved underneath it.

There's a reason no tools exist for this. Every other part of software delivery has had a system of record for years. Code has version control, CI gates, and security scanning. Infrastructure has its platforms and pipelines. Architecture never got one. It still lives in senior engineers' heads, and in diagrams that went stale the day they were drawn. When implementation was the slow part, you could get away with that. Now implementation is automated, architecture is the slow part, and it's the one thing with no source of truth underneath it.

And this doesn't just squeeze the small calls. The seven-, eight-, and nine-figure modernization and re-architecture moves, the ones that decide whether your platform can carry the business, are stuck in the same bottleneck. Your team labors on the big move for months, with whiteboards and stale docs as their only instruments, while agents keep shipping. The stack you're trying to reason about grows more complex faster than you can decide what to do with it. The decisions got harder, the window got shorter, and the system won't hold still long enough to think.

We're keeping score on the wrong side of the shift

This is the real shift, and you can see teams measuring the wrong side of it in the numbers the industry now celebrates:

• 50% more output per developer
• Cycle time under 24 hours, from signal to production
• Autonomy ratio of 67%: the share of merged work completed end to end by agents, with no human touch
• Cost per merged PR of $20

Every one of these measures how fast and how cheaply code gets produced. Not one of them measures whether it was the right code: whether it fit the system, respected the constraints, or advanced the objectives the system exists to serve. The autonomy ratio, celebrated on its own, is the strangest of all. It's a claim that human judgment was successfully removed from the loop, presented as the headline win.

We've run this experiment before. The offshore outsourcing boom optimized for exactly these two variables, speed and cost per unit of code, and the buyers who chose purely on those metrics got exactly what they measured: high volumes of low-cost code, produced without the judgment and system understanding needed to make the right calls, and years of integration debt to show for it. Today's agents write far better code than that era ever did. But the scoreboard is repeating the same mistake, and the compounding is much faster now.

To be fair, the industry also surfaces some quality-adjacent numbers: incident MTTR, how long shipped code stays untouched, time-to-merge improvements paired with more compliance findings caught. Those are better, and they're honest code-quality metrics, aligned with ones the industry has used historically to measure quality developer productivity. But they still measure the health of the code, not the health of the system. You can ship a quarter's worth of code that is perfectly good in general, perfectly good for the feature, and perfectly unhelpful to what you're trying to achieve with your system. The feature lands. The system degrades. No code metric catches that.

MTTR is the most revealing of those metrics, because of what it concedes. It measures how fast you recover after the system tells you something went wrong. The counterpart we hold ourselves to is Mean Time to Informed Decision (MTID): how fast you land the right call before anything ships. Not solely a fast decision, but even more so an informed one: grounded in the live system, the objectives and constraints it serves, and human and AI judgment working together on the whole picture. Recovery speed tells you how well you clean up. Decision speed, at full information, determines how much there is to clean up.

What your agent literally cannot see

A coding agent operates at the resolution of the task. Give it a ticket and a repo, and it will usually produce a locally optimal answer. That's what it was built for, and it's good at it.

But the things that determine whether the work was right don't live at the task's resolution. Start at the top: the objective function of the whole organization. The business objectives, the product constraints, the finance policy, the architecture standards and the strategy your senior people thought through deeply and encoded over years. Architecture is the mapping of that objective function onto the system: the purpose of the whole organism expressed in its structure, not the behavior of one cell. And then there is the system itself: the boundaries between services, the dependencies that creep in, a decision made six months ago that this change is about to contradict, the drift between what the system was designed to be and what it has actually become. None of that is visible in the file the agent is editing. It's a property of the whole, and a one-off agent only ever sees a part.

So the agent does something subtle and expensive. It makes a change that is correct in the file and wrong for the system, or right for the feature and wrong for the objective. It rebuilds a capability that already exists three services over, because it had no way to know. It reaches across a boundary because reaching across was the shortest path to green tests. Each of these is defensible on its own. Together, they're how a clean architecture turns into an amoeba, one locally correct decision at a time.

Velocity doesn't cause this. It reveals it.

Plenty of people will tell you the fix is to slow the agents down, and it isn't. The gap between decision speed and execution speed has always been there, and architecture has always been drifting. What AI did was take that drift and put it on a compounding curve.

Think about what compounding means here. Every architectural decision that ships without system context becomes the ground truth on which the next decision is built. Get one slightly wrong, and the next change inherits the error, and the one after that. At human coding speed, you had months to notice and correct. At agent speed, you have days, and the overwhelming majority of decisions in flight are now being made by agents rather than people. The faster you ship, the faster these blind calls accumulate, and the faster a small misalignment hardens into a structural one. By our estimate, 30 to 40% of engineering time already went to rework from this kind of drift and the debt it left behind, and that was before agents multiplied the change rate.

This is why the euphoria fades on a predictable schedule. The tools didn't get worse; the compounding just finally became visible. And drift is only the visible piece: the receipts for all the calls agents made blind, at agent volume, plus the ones your people made too slowly, or never got to make at all.

Your principal engineers became human middleware

There's a human cost to all of this, and it lands on exactly the people you can least afford to burn out.

When no system holds architectural truth, a handful of staff and principal engineers become the system. They're the ones who know why the boundaries sit where they do, which dependencies are load-bearing, what breaks if you touch this. And they're the ones holding the objective function too: the business goals, the product constraints, the finance policy, the encoded standards and strategy that were thought through deeply and that actually matter. AI multiplied your developers, but it did not multiply them. So the same three people are now expected to review exponentially more output, hold the whole system and its purpose in their heads, and absorb the risk of everything they don't have time to look at.

They know they're waving through designs they haven't fully reasoned about, because the alternative is becoming the bottleneck that kills the velocity story. That's your most important people quietly choosing between being slow and being anxious, every single day. And these are people who love this work. Reasoning about systems and solving hard business problems with technology is their calling, the thing they spent twenty years getting great at. They aren't asking anyone to ship less. They want to build the right things, at AI speed, and nothing in their stack lets them.

The fix is a layer above the agent, not a better agent

The instinct is to tighten the linter or the CI gate. That helps at the edges, but it still operates at the file's resolution. The problem doesn't live in the file. Nothing connects what's true about your architecture, what your organization is actually trying to achieve, what you've decided to do about it, and what actually gets built.

That connecting layer is what's missing, and it's what we've spent the last few years building at Catio to power orgs like yours: not another tool that writes code, but a loop that sits above the ones that do.

Understand the system as it actually runs, alongside the objectives, constraints, and standards it exists to serve. Decide on the 7-9 figure strategic optimization calls, with target architectures, gap analyses, trade-offs, and ROI made explicit. Turn changes or new features into execution-ready specs, grounded in the whole system and the whole objective function, not just the ticket. Let your teams and agents execute against those designs in the tools they already use, whether that's Cursor, Claude Code, or Copilot: the spec guides the agent before a line is written, and the loop governs what ships after. Then compound the result, so each change strengthens the system instead of eroding it. We call the operating model "Architect, then Ship," one that translates into an Architecture-Led AI SDLC, and the point is that architecture stops being a document someone updates when they remember it, and becomes a system that guides first, governs second, and compounds in the right direction.

The same loop cuts two ways: one for your new feature development, one for your strategic calls. For new features, a PRD becomes a system-and-objective-aligned, ship-grade spec in minutes instead of review cycles, so machine-speed execution starts guided instead of blind. For the strategic calls, they finally get made at the speed they deserve: the modernization move sized, the trade-offs priced, the decision committed in days instead of quarters, against the system as it actually is rather than as anyone remembers it.

Reviewing more code was never the goal. When the tech spec accurately reflects the change that drives a key optimization or re-architecture, or a feature your product team needs in front of customers to win business, and it's explicit, system-grounded, and aligned to your business objectives and product constraints, your principal engineers stop reviewing everything and start reviewing only the exceptions: the places where what shipped diverged from what was intended. That's how judgment scales at the same rate as output: not by cloning your best architects, but by giving the system context, system-level reasoning, lifecycle memory, and a spine.

The scoreboard that belongs next to the velocity numbers

If the industry's scoreboard measures the speed and cost of producing code, the missing half measures whether the system got better. These are the numbers we hold ourselves to, and the ones we'd suggest any engineering leader start asking every vendor, and their own org, to report:

• Mean Time to Informed Decision (MTID): about 5 minutes. From any architecture question to a decision-grade answer, against a live model of your system, its objectives, and its constraints, instead of weeks of archaeology through stale diagrams. This is the number the rest of the scoreboard hangs off.
• Time to a committed modernization plan: 2 to 3 hours. A decision-grade plan, aligned to a 2 to 3 year roadmap, for the class of moves that used to consume quarters of whiteboarding. That's MTID at the scale of a strategic call.
• Design throughput, at alignment: multiple execution-ready specs per day. System-and-objective-aligned specs your agents can execute against, versus roughly one reviewed design per week the manual way. Speed and alignment in the same number, which is the entire point.
• Exception rate, not review rate. The share of shipped changes that diverged from their aligned spec. Architects review the exceptions instead of everything; the healthier the loop, the smaller this number gets.
• Drift, detected as it happens. Divergence between the architecture as designed and as built, surfaced continuously rather than discovered at the next outage, audit, or failed modernization.
• The rework tax, trending down. Today, 30 to 40% of engineering effort goes to rework from drift and technical debt. That's the single number the whole loop exists to attack.

Notice what these have in common: every one of them prices judgment, alignment, and intent, the exact things the velocity scoreboard treats as free. Cost per merged PR tells you what the code cost. These tell you what the code was worth.

The question worth asking

Your coding agents aren't going to slow down, and you don't want them to. The teams that win the next few years won't necessarily be the ones generating the most code, but the ones whose architecture gets a little better every time an agent ships, rather than a little worse. The ones who can make the right calls, aligned to what the business is actually trying to achieve, at the speed their agents execute them.

So the useful question isn't really whether your agent writes good code (it does), but whether anything in your stack is making sure all that good code adds up to a system you'd actually want to own in two years, and to the outcomes you built it for. If the answer is "our best engineers, in their heads, when they have time," then your coding agent has an architecture problem, and it's only going to get louder.

The teams that solve it get the thing every great engineer actually wants: to build the right things, at AI speed.

Where does that loop break first in your org? That's usually the tell.

How to move your side of the scoreboard

Our whitepaper, The Architecture Control Plane: A Framework for the Architecture-Led AI SDLC, lays out the full case. It covers the five surfaces an architecture control plane has to guide and govern (architectural truth, system- and objective-aligned design, drift detection, architecture memory, and agent coordination), a five-level maturity model to pinpoint where your organization stands today, the business case as three outcomes (optimize your architecture, build to aligned specs, and ensure it compounds), and the operating model we call Architect, then Ship. Written for the tech leaders guiding and governing AI-generated software at enterprise scale.

📘 Read the white paper →

⚡ Short on time? The same workflow on a single page: Get the Architecture-Led AI SDLC one-pager →

And if you're ready to test this on your own stack: book a demo to see the loop run against a real architecture, or sign up for a free trial and try it out for yourself.

‍