For most of my career, writing software meant accepting a certain amount of friction. Even when the problem was clear, turning an idea into production still took time. You had to understand the system, write the implementation, integrate it, test it, review it, and eventually ship it.

AI is removing a significant part of that friction. Today I can describe a change, provide enough context, and get an implementation back in minutes. Changes that would previously have required touching many parts of a codebase can be propagated almost instantly.

That is obviously powerful. But I think we are still underestimating one of its consequences: implementation is no longer always the bottleneck.

And when code becomes cheap, something else becomes expensive: judgment.

The difficult questions do not disappear.

Are we solving the right problem?
Is this the right abstraction?
Does this capability belong here?
Which constraints matter?
What should we deliberately not build?

And when an implementation looks convincing, passes tests, and has been produced in seconds, how do we know it is actually a good engineering decision?

AI does not remove the need for strong engineering. It changes where strong engineering creates leverage.

AI accelerates good engineering and bad engineering

We often describe AI as an accelerator. I agree with that, but the important question is: what exactly are we accelerating?

Give an agent a codebase with understandable boundaries, consistent patterns, good tests, useful documentation, and clear ownership, and it can be incredibly effective. The system itself provides context.

But give the same agent an incomplete view of the system and it will fill in the gaps. And those gaps often turn into code.

None of this necessarily looks wrong when reviewing the generated code in isolation. In fact, it can look responsible: defensive, complete, reusable. The problem is that the agent is reasoning from the context we gave it, not from everything we know about the system.

Better code generation is therefore not only about producing the correct implementation from a prompt. It is also about giving the agent enough understanding to know what it should not implement at all.

I have seen a related failure mode with engineers. An engineer makes a questionable design decision or produces an implementation that does not really fit the system. When challenged, the response sometimes becomes some variation of:

“But I asked the AI.”

That is an interesting new failure mode. AI can make a weak decision look more authoritative than it really is.

The implementation may be clean. The naming may look reasonable. There may even be tests. But none of that means the original decision was good.

An AI model can answer the question you gave it extremely well while the question itself was wrong. If someone already struggles to identify the right boundaries, understand the wider system, or reason through trade-offs, AI does not automatically give them those skills. Sometimes it can even hide the gap, because the resulting code looks more convincing than what they might have produced alone.

The danger is not that AI writes obviously terrible code. It is that it can write very plausible code around a bad or incomplete understanding of the system.

And now that decision can spread through dozens of files in minutes. Previously, implementation effort provided a kind of natural friction. Even a questionable direction took time to propagate.

AI removes much of that friction. That increases the blast radius of both good and bad decisions. This is one reason I believe architecture becomes more important, not less, as AI becomes better at implementation.

Boundaries, APIs, tests, conventions, documentation, and tooling are no longer only there to help humans understand a system. They increasingly become part of the context that allows AI to operate safely inside it.

Senior engineers move upstream and downstream

A simple way I think about software development is:

decision → implementation → validation

Historically, a lot of engineering effort was concentrated in the middle. Even after you knew roughly what you wanted to do, producing the implementation was expensive. AI is compressing that middle. That does not make the other two parts less important. It makes them more visible.

Upstream, experienced engineers create leverage by framing the problem correctly.

What are we actually trying to achieve?
What constraints are real?
Where should the responsibility live?
Which trade-off are we making?
Is this a local change, or are we unintentionally creating a new architectural direction?
And increasingly: what context does the agent need to make the same decision we would make?

Downstream, the questions are different.

Does this actually work?
Is it maintainable?
Does it violate a boundary that is not obvious from the immediate code?
Did we generate complexity because the agent was missing context?
Are we comfortable owning this in production?

The implementation still matters. Senior engineers are not suddenly going to stop writing code. But manually producing the implementation is becoming a smaller part of what makes an engineer senior.

The harder things to compress are context, judgment, systems thinking, and the experience required to recognize when something that looks perfectly reasonable locally is wrong globally.

AI gives experienced engineers enormous leverage. A good decision can now be implemented much faster. But leverage works in both directions. A bad decision can scale just as quickly.

Good judgment does not mean perfect design

There is a risk in this argument. If architecture, context, and technical judgment become more important, does that mean we should spend more time searching for the perfect design? I do not think so.

A technically elegant system that does not create any measurable value is still a failure. Code only becomes valuable when it contributes to an outcome: a better user experience, higher conversion, a feature that people actually use, lower operational cost, faster learning, or whatever goal matters in that context. If none of that happens, the quality of the design is largely irrelevant.

So the goal should not be to predict every possible future evolution of the system or cover every edge case before we have evidence that it matters. The goal is good enough for what we know today. And “good enough” is contextual.

It will be different for a payment system than for an experiment. Different for a mature platform than for a new product hypothesis. Different across teams and organizations depending on risk, scale, domain, and cost of change.

What we do need is enough quality to validate the assumption safely, and a design that is understandable and flexible enough to evolve if that assumption proves correct. That is another place where judgment matters. Knowing when to invest in architecture is important. Knowing when not to is just as important.

AI makes iteration cheaper, which should encourage us to learn sooner rather than speculate further.

Build something good enough to test the hypothesis.
Measure what happens.
Then improve the system based on what we learn.
Step by step, iteration by iteration.

The trap of measuring AI through coding speed

One of the first questions organizations naturally ask when adopting AI is: Are engineers becoming faster? It is a reasonable question. But it is very easy to optimize the wrong thing.

A team can write more code without delivering more value. It can close more tickets while increasing complexity. It can generate the implementation in an hour and then spend three days reviewing, correcting, testing, or deciding whether it was the right solution in the first place.

If AI dramatically improves one stage of software delivery, measuring only that stage tells us very little about the performance of the whole system.

The questions I find more interesting are broader.
Are ideas reaching production sooner?
Are we learning earlier whether an assumption is correct?
Can we explore alternatives that previously would have been too expensive?
Are we solving problems that previously were not worth the implementation effort?
Is quality staying stable as throughput increases?

And where is the bottleneck moving? Because it will move.

If implementation becomes much faster but code review stays the same, you create a review bottleneck. If implementation accelerates but product decisions do not, you create more implementation capacity than you can use. If feature creation accelerates but validation does not, you may simply produce incorrect things faster.

This is why I am increasingly less interested in AI purely as a developer productivity metric. The more interesting question is what happens to the engineering system around the developer.

Individual adoption is the first step, not the destination

There is an important prerequisite to all of this. An organization cannot rethink how it works with AI if its engineers are not comfortable working with AI in the first place. So starting with the individual developer makes complete sense.

This is where I would start too. Not only because it creates immediate value, but because it builds something more important: confidence and intuition.

Engineers need to learn what the tools are good at, where they fail, how much context they need, when to trust them, and when to challenge their output.

You cannot develop that understanding through an organizational AI strategy deck. You develop it by using the tools every day.

So individual productivity is not the wrong starting point. It is the foundation. The mistake would be treating it as the end state.

Once engineers become comfortable delegating meaningful parts of implementation to AI, a much bigger question opens up: what else can change around them?

AI changes the engineering system, not just the developer

When implementation becomes significantly cheaper, we can start reconsidering processes designed for a world in which implementation was expensive. Prototypes become cheaper, so product and engineering can explore ideas before committing heavily to them. Technical alternatives can be implemented and compared rather than debated entirely in the abstract.

Migration strategies can be tested before a team commits weeks to them. Tests and documentation can increasingly be produced alongside the implementation. Even planning changes when exploration itself becomes inexpensive.

For organizations already structured around missions, domains, and outcome ownership, I do not think AI requires reinventing that model. If anything, it reinforces why that model matters.

When implementation capacity becomes abundant, the limiting factor becomes less about how many engineers can execute a predefined backlog and more about whether a team understands its domain deeply enough to make good decisions within it.

A mission-driven team already has something an AI agent desperately needs: context.

It understands the product problem, the surrounding systems, historical decisions, operational constraints, and the consequences of changing one part of the domain. The opportunity is not necessarily to restructure teams around AI.

It is to make that domain knowledge increasingly usable by both humans and agents. And this leads to a question I think engineering leaders should be asking:

If we designed our engineering processes today, knowing that implementation was cheap, which parts would we keep?
Would we still batch decisions in the same way?
Would product discovery and technical exploration be as separate as they often are today?
Would code review work the same way when producing another implementation costs minutes instead of days?
Would we invest more heavily in architectural constraints, automated validation, observability, executable specifications, and other forms of context because increasingly autonomous systems need clearer boundaries?
How much of the knowledge that currently lives in the heads of experienced engineers could become explicit enough for an agent to reason with it too?

These are much more interesting questions to me than whether an engineer completes a ticket thirty percent faster. AI is not simply another tool inside the existing development process. At some level of capability, it changes the economics that caused parts of that process to exist in the first place.

And that is where engineering leadership becomes particularly important.

The challenge is not simply convincing engineers to use AI. First, we need to help them become genuinely effective and confident with it. Then we need to understand which constraints have changed, identify which assumptions no longer hold, and evolve the surrounding engineering system accordingly.

What becomes expensive

Code becoming cheaper does not make engineering trivial. It changes what becomes scarce.

The implementation still matters, but more of the value comes from deciding what to build, giving the right context, validating the result, and learning whether it actually solved the problem.

That means understanding the problem.
Making the right decision.
Providing the right context.
Knowing when the best implementation is actually less code, not more.
Knowing when a design is good enough to learn from rather than perfect for a future that may never arrive.
Challenging a plausible implementation instead of accepting it because “the AI said so.”
And validating whether what we built created any value in the first place.

The organizations that benefit most from AI may not be the ones that generate the most code. They may be the ones that make better decisions, expose context, shorten feedback loops, and turn those decisions into measurable outcomes.

Individual AI adoption is where the journey starts. The larger opportunity is to use what we learn there to rethink the engineering system around it.

When code becomes cheap, judgment becomes expensive.