When implementation got cheap

Most of what AI tools changed about engineering work, they changed by making implementation cheap. A change that used to take a week now takes an afternoon. A pattern that used to require an experienced engineer now emerges from a junior engineer with a tool. A refactor that used to be too expensive to attempt is in scope. The implementation phase — the part where intent becomes code — compressed in a way that reorganized the rest of the work around it.

What did not get cheap is architecture. The decisions about what to build, how the pieces fit together, which contracts the system commits to, where the boundaries sit, which constraints have to be honored — those decisions still take the time they used to take. The time they take is shaped by judgment, context, and the slow accumulation of “what did we try last year and what failed.” The model has not been trained on your team’s last year. It has been trained on a distribution of other teams’ last years, which is a different artifact, and not as useful as it looks.

The result is a relative-weight shift most teams haven’t yet absorbed. Engineering work used to be roughly half implementation, half everything else; the half called everything else was structural but proportionally smaller. Now implementation is a sliver, and everything else — design, review, integration, the slow conversations that decide which way the thing should bend — is the actual engineering. The teams that organize around the new ratio do well. The teams that keep organizing around the old one ship the wrong thing very efficiently.

Three changes deserve naming.

1. Decision foreclosure ended

Pre-AI, a lot of architectural decisions were de facto resolved by implementation cost. “We could do it as separate services, but it’ll take a quarter” was an answer that ended the conversation. “This abstraction would be cleaner, but the migration is two months” was an answer that ended the conversation. The team picked the implementable thing, and the architectural question was foreclosed by the cost of the better answer.

Call this decision foreclosure. It was never explicit, never deliberate, never written down — but it was the silent tiebreaker on most architectural debates a team had over the last decade. When the cost of implementation dropped, the foreclosure ended. The conversation no longer terminates. What was previously a forced choice (“do the achievable thing, not the right thing”) is increasingly a real choice.

This is good news on net: more architectural freedom is more architectural freedom. It is also more decisions to make, made worse by the fact that the team’s silent decision-maker just retired without anyone hiring a replacement. Many teams are noticing that more meetings are needed to land architectural calls than before, even though the implementations are faster. The meetings aren’t pathology. They are the conversation that used to be foreclosed by reality and now has to be had explicitly.

The uncomfortable implication: teams need to be better at architecture than they used to be, not merely more willing to make decisions. The skill of resolving an open architectural question on its merits — without the implementation-cost tiebreaker — is rarer than the field acknowledges. Many teams don’t have it. Many teams that don’t have it haven’t yet noticed, because they were borrowing the absent skill from the old constraint.

2. The brake on bad direction is gone

Slow implementation was, accidentally, a brake. Bad architectural choices used to ship more slowly because implementation was slow; the team had time, while building, to notice the design was wrong and pivot before too much was committed. The brake was never deliberate, and most teams underrated it because nobody likes pointing at their own slowness as an asset. But it was real, and AI removed it.

Bad direction now ships fast. A team that has decided to build the wrong abstraction can build it in two weeks instead of two months. The wrong is unchanged; only the speed at which it gets entrenched into the codebase changed, and the speed at which other code accumulates around it. The cost of catching a bad direction late used to be measured in person-weeks of building; it is now measured in entire subsystems quickly grown around the wrong center.

Two responses are sane, and both are unfashionable.

The first is to deliberately slow architectural decisions even though implementation is fast. Force more review. Require a written design before non-trivial changes. Add explicit checkpoints that ask, in writing, is this the design we want, or is this the design we are building because we can? The instinct will be to skip these, because implementation is fast and waiting for review feels like throwing away the speed dividend. The teams that skip the review are the ones who, six months in, find themselves rebuilding the foundation of a system they over-built on the wrong axis.

The second is to commit harder to small, reversible architecture. If you cannot slow the decision-making down, at least make the decisions cheap to undo. Smaller services with cleaner boundaries, fewer cross-cutting abstractions, less premature consolidation. A team that ships fast should be shipping in shapes that allow fast pivots, not in shapes that make every wrong direction expensive to walk back from. Reversibility was always a virtue; under cheap implementation it is the difference between a team that adapts and a team that has to apologize.

Teams that pick neither — who keep making architectural decisions at the old cadence while implementing them at the new cadence — accumulate something the field doesn’t yet have a clean name for. AI-accelerated debt is a working label, but the mechanism is more specific: it is the gap between how fast a team can build and how fast a team can decide what to build. Call it architectural latency. When implementation latency was high, architectural latency was hidden inside it. When implementation latency dropped, architectural latency became the dominant cost, and most teams have not yet learned to measure it, much less reduce it.

3. The artifacts moved upstream

The most underrated consequence of cheap implementation is that the artifacts of engineering work shifted upstream. Pre-AI, the canonical artifact of an engineering decision was the implementation. The code is the spec; if you want to know what the team decided, read the code. This was always an imperfect heuristic — the code is dense with intent but incomplete about reasoning — and it is more imperfect now, for reasons that compound: more of the code is authorless, more of the design space is open, less of the team’s reasoning is visible in the artifact that survives.

The artifact that now matters most is the design record, in whatever form a team writes them. ADR, RFC, design doc, long Slack message pinned to a channel — the format does not matter, the existence does. The code can no longer reliably carry the team’s design thinking. The thinking has to live somewhere outside the code.

Teams that didn’t write design records before are now writing them, often awkwardly. Teams that wrote them sloppily before are now writing them carefully, because they are increasingly the only durable record of why the system is shaped the way it is. The description of a design record’s purpose has shifted from “in case someone needs to understand this later” — a low-stakes future-proofing exercise — to “in case anyone, including the author, needs to reconstruct what the team actually decided.” The reconstruction is now harder than it used to be, because the decision is less visible in the code that resulted.

The other consequence of upstream artifacts is upstream bottlenecks. The constraint on team throughput is no longer implementation speed; it is the rate at which architectural questions can be resolved well enough to feed the implementation pipeline. Senior engineers are increasingly the constraint, and they are increasingly the constraint specifically on architectural review and decision-formation rather than on writing code. Teams that optimize for ship more code are optimizing the wrong axis. Teams that optimize for make better architectural calls, faster are optimizing where the leverage actually is.

This is uncomfortable for orgs that have spent a decade measuring engineering throughput in commits, PRs, and tickets shipped. None of those metrics has anything to say about whether the architecture is right; all of them go up when implementation gets cheaper. A team can post the best velocity numbers of its history while shipping in a direction that requires a rewrite in eighteen months. The numbers don’t catch it. The senior engineer who keeps asking do we want to be doing this? catches it. The org that listens to them keeps catching it.

Closing

The pattern across these changes is not subtle: AI made the cheap part of engineering cheaper, and the expensive part is still expensive — relatively more expensive, because it is a larger share of the work that remains. This is the thing the vendor pitch leaves out. The leverage is real, but it isn’t free; it is purchased by getting better at the parts of the work the tool cannot do, faster than the tool gets better at imitating them.

The teams that have noticed are reorganizing. More architectural review. More design-record discipline. More senior time spent on decisions and less on writing code that any senior could write quickly anyway. Junior engineers paired with the tool on smaller, well-scoped pieces, with the architectural envelope already drawn around them. Mid-level engineers asked to own problems that used to arrive as tickets, because owning means specifying, designing, and reviewing — the work that didn’t get cheap. The shape of the team flattens slightly toward the senior end, because the senior end is where the work is now.

The teams that haven’t noticed are still budgeting their week the way they did three years ago — most of the calendar against implementation, a small slice for design, an even smaller slice for review. They will report higher velocity for two quarters, and lower trust in their own systems for the four quarters after that. The numbers will look fine. The codebases will not. The disconnect is the cost of the unbalanced budget, and the only way to fix it is to admit that the budget has to change, which is a conversation nobody enjoys and most teams therefore postpone past the point where the fix is cheap.

When implementation got cheap, the question stopped being how do we ship more of it and started being how do we know we are shipping the right thing. The first question still has its uses, and any team that has stopped asking it has a different problem. But the second question is the one whose answer determines whether the codebase, two years from now, is something the team is proud of or something they are quietly planning to rewrite. Most teams are still answering only the first. The conversation about the second is the conversation worth scheduling.