There is a strange way we talk about AI coding. We celebrate how quickly an agent can write a function, fix a bug, generate a test, or build an entire feature.
But I think we’re asking the wrong question.
The point of AI coding isn’t to make engineers better typists. It’s to make them better architects.
The hammer
Imagine you’re building a house. You spend your day hammering nails, cutting wood, laying floors, carrying materials, and fixing small mistakes. After ten years, you become incredibly good at it. You can hammer faster, cut more precisely, and build more efficiently.
Then someone gives you machines that can do all of those things.
What happens to your value? It doesn’t disappear. It moves.
You no longer need to spend your day asking, “How do I hammer this nail?” You can spend it asking, “What house are we building?” And more importantly, “Where should the load-bearing walls go?”
That’s what I think AI coding is doing to software engineering.
We’re automating the hammer
For most of the history of software, writing code was a significant constraint. You had an idea, translated it into a design, and then spent hours turning that design into thousands of lines of code. The implementation itself consumed enormous amounts of attention.
AI changes the economics. Agents can write code, refactor it, generate tests, investigate errors, work across repositories, and operate tools. As more of that execution becomes automated, the scarce resource starts moving.
It isn’t necessarily code anymore.
It’s judgment.
The new engineering problem
When implementation becomes cheaper, we can spend more time on questions that were previously crowded out by execution.
Instead of asking, “How do I implement this function?”, we can ask, “What should this system look like three years from now?”
What happens when usage grows 100x? What happens when the database fails? Where are the security boundaries? What should be observable? What should be extensible? How much will this cost to operate? What happens when another team needs to build on top of it? What does this architecture prevent us from doing later?
These questions don’t disappear because AI can write code.
They become more important.
Less coding does not mean less engineering
This is where I think some of the AI coding conversation gets confused.
If an agent writes 10,000 lines of code, that doesn’t mean an engineer has 10,000 fewer things to worry about. It may mean they have 10,000 fewer things to type. Those are very different things.
AI-generated code can still be insecure, overly complex, poorly designed, difficult to operate, or subtly wrong. So the future isn’t AI writes everything and engineers do nothing.
It’s AI handles more implementation while engineers take more responsibility for the system.
The abstraction level moves upward.
The leverage changes
This is the part that excites me. A good engineer used to be constrained by how much they could personally build. If you could write 1,000 lines a day instead of 500, you had more leverage. But you still had one pair of hands.
Agents change that. One engineer can increasingly direct multiple implementation processes in parallel. That makes the bottleneck less about execution and more about deciding what deserves to exist in the first place.
And that is a much more interesting job.
The best engineer may not be the person who produces the most code. It may be the person who can look at a problem and say, “We shouldn’t build this.” Or, “We should build it differently.” Or, “If we’re going to build this, we should design it so that it becomes the foundation for five other things.”
That’s architecture.
AI makes bad decisions cheaper too
There is a darker side to this.
When code becomes cheap, bad ideas become cheap too. You can now turn a vague product idea into a working prototype in hours. You can also create a giant mess in hours.
The cost of implementation falling doesn’t mean the cost of complexity falls. In fact, it may do the opposite. If building something costs almost nothing, we’ll build too much: abstractions nobody needs, features nobody uses, and systems nobody understands.
The ability to build faster makes the ability to say no more valuable.
That may become one of the most important skills in an AI-native engineering organization.
So what should engineers do?
Do less.
Not less thinking. Less mechanical execution.
Spend less time typing boilerplate and repetitive code. Spend less time manually moving information between tools. Spend less time implementing things a machine can reliably implement.
Instead, spend more time on the things that become more valuable as implementation gets cheaper: architecture, product judgment, systems thinking, security, trade-offs, taste, and knowing what not to build.
The irony is that AI coding may ultimately make engineering feel more like engineering, not less.
For years, we treated software development as a mixture of design and typing.
AI is removing some of the typing.
What’s left is the interesting part.
The point of AI coding isn’t to make engineers better programmers. It’s to make them better at deciding what should be programmed.
The hammer was never the job.
Building the right house was.