Engineering After Coding
The job is not disappearing.But the job you became good at is.
For years, software engineers were told that learning to code was learning how to build the future.
So we learned.
We spent thousands of hours staring at broken programs.
We learned strange languages, stranger frameworks, and the particular kind of patience required to discover that the bug was one character long.
We learned how systems behave by building them.
We developed taste by creating bad abstractions.
We developed judgment by making decisions we later regretted.
We learned how to debug because production eventually forced us to.
And somewhere along the way, many of us started identifying with the craft itself.
We are engineers.
We write software.
Then something changed.
You describe a problem to a machine and, a few seconds later, it starts building.
Not a snippet.
Not autocomplete.
The feature.
The tests.
The migration.
The documentation.
Sometimes the review.
Sometimes most of the pull request.
And it is getting better remarkably quickly.
That should feel incredible.
Sometimes it does.
But if you have been building software for a while, there may be another feeling underneath it.
Something slightly uncomfortable.
If the machine can increasingly do the thing I spent years becoming good at...
what exactly am I becoming now?
That is the question I think our industry has barely started confronting.
This is not another developer productivity tool
We keep talking about AI as if it belongs in the same lineage as better IDEs, higher-level languages, Stack Overflow, cloud infrastructure, and autocomplete.
It does not.
Those tools made implementation easier.
AI is starting to make implementation abundant.
That is a much bigger change.
For most of software history, implementation was one of the central constraints.
Ideas were cheap.
Working software was expensive.
You needed engineers to translate intentions into functioning systems, line by line, interface by interface, bug by bug.
Companies were organized around this scarcity.
Projects were organized around it.
Engineering careers were organized around it.
We created tickets because implementation capacity needed to be allocated.
We estimated work because implementation took time.
We broke large problems into small pieces because humans had limited throughput.
We hired more engineers when we wanted to build more software.
We promoted people partly because they became capable of implementing increasingly difficult things.
Then the cost of implementation started collapsing.
And when a constraint disappears, the system built around that constraint has to change.
That includes us.
Coding is becoming cheaper. Judgment is not.
Imagine that generating a reasonable implementation eventually costs almost nothing.
What remains difficult?
Knowing whether it is the right implementation.
Knowing whether the problem should be solved at all.
Understanding the business constraint hiding behind the requested feature.
Choosing between five architectures that all look plausible.
Recognizing the solution that works today but creates six months of pain.
Knowing when a model has misunderstood the domain.
Finding the assumption nobody wrote down.
Seeing the security boundary.
Understanding the failure mode.
Deciding what "good enough" means.
Explaining the tradeoff.
Taking responsibility when the system meets reality.
None of these become less important because AI gets better.
They become more important.
If a machine can generate ten solutions in the time it once took us to build one, generation is no longer the bottleneck.
Selection becomes the bottleneck.
Judgment becomes the scarce resource.
The future engineer owns problems, not tickets
There is a version of AI adoption that is deeply unimaginative.
The same backlog.
The same tickets.
The same engineering organization.
The same way of working.
Except everyone finishes their assigned implementation faster.
That is not transformation.
That is acceleration.
And eventually acceleration runs into another bottleneck.
The more interesting possibility is that the unit of engineering work changes.
Instead of:
Implement this endpoint.
It becomes:
Our customers cannot understand why their payments fail. Figure it out.
Instead of:
Build this dashboard.
It becomes:
Our operations team is wasting twenty hours a week on this process. Own the problem.
Instead of:
Complete these five tickets.
It becomes:
Take responsibility for this part of the business.
AI makes this possible because one engineer can potentially explore, prototype, implement, test, and iterate across a much wider surface area than before.
The engineer becomes less of an implementation resource and more of an owner of outcomes.
That sounds empowering.
It is.
It is also harder.
Tickets come with boundaries.
Problems usually do not.
There is something we need to be careful not to lose
Engineers are already starting to describe a strange experience.
They are dramatically more productive.
And they enjoy their work less.
The sprint finishes early.
The pull requests multiply.
Features that once took days appear in hours.
But the work starts to feel different.
Less building.
More supervising.
Prompt.
Wait.
Read.
Correct.
Prompt again.
Merge.
Repeat.
Pair programming disappears because everyone has their own agent.
Code review becomes difficult because the amount of generated code exceeds the amount humans can meaningfully inspect.
AI writes the implementation.
Then AI summarizes it.
Then another AI reviews it.
And somewhere in that loop is a human who is theoretically responsible for the system.
This is where the uncomfortable question appears:
Are we becoming more capable engineers, or are we becoming more efficient operators of systems we understand less every month?
Those are not the same thing.
"The tests pass" cannot become our definition of understanding
AI can produce code you did not write.
That is fine.
You already run code you did not write every day.
What matters is whether someone understands the system well enough to reason about it.
Why is it built this way?
Where is state stored?
What happens if this dependency disappears?
Which assumptions must remain true?
What is the dangerous part?
Where would you start looking if production started behaving strangely at 3am?
What breaks at ten times the current scale?
If nobody can answer those questions because the implementation emerged through hundreds of interactions with an agent, something has gone wrong.
The danger is not AI-generated code.
The danger is AI-generated systems without human mental models.
We cannot outsource understanding simply because we outsourced implementation.
The junior engineer problem should worry us
Senior engineers currently have a huge advantage when working with AI.
They know when it is wrong.
Not always.
But often enough.
They have seen systems fail.
They have built abstractions that looked beautiful until reality arrived.
They have spent entire afternoons debugging bugs that made no sense.
They have received brutal code reviews.
They have introduced incidents.
They have removed code they were once proud of.
That history became intuition.
We now call that intuition "seniority."
And much of it was created by doing the exact work we are now excited to delegate.
So we need to ask a question that is much bigger than "How should juniors use AI?"
How does someone become senior in a world where the machine does much of the work that previously created senior engineers?
I do not think we know yet.
But "they'll learn faster with AI" is not enough of an answer.
Maybe they will.
Maybe they will learn different things.
Maybe we are about to produce an entire generation of engineers who can generate sophisticated systems before they have developed the judgment required to evaluate them.
If so, engineering organizations cannot leave learning to chance anymore.
We will have to design it deliberately.
Architecture discussions.
Deep debugging.
Explaining generated code.
Defending decisions.
Teaching.
Pairing.
Reading systems instead of only generating them.
Understanding why, not just verifying that.
Not because hand-coding is morally superior.
Because judgment still has to come from somewhere.
Seniority itself is changing
For a long time, one signal of a strong engineer was:
Give them a difficult implementation problem and they can solve it.
That remains useful.
But it may no longer be enough.
The more important question becomes:
How large and ambiguous a problem can this person be trusted to own?
Can they enter a domain they do not understand and build a model of it?
Can they figure out which questions matter?
Can they recognize when the requested solution is solving the wrong problem?
Can they make architectural decisions without hiding behind convention?
Can they direct AI effectively without surrendering judgment to it?
Can they recognize when the output is subtly wrong?
Can they communicate the tradeoffs?
Can they operate what they build?
Can they take responsibility when reality disagrees with their assumptions?
That is a very different definition of seniority.
And arguably a much more demanding one.
This is why "10x engineer" is becoming the wrong mental model
The original idea of a 10x engineer was usually interpreted as one unusually capable person producing dramatically more than another.
AI changes the equation.
Almost everyone may soon have access to extraordinary implementation leverage.
So producing ten times as much code becomes less interesting.
The question is what we do with the leverage.
A team of five engineers might eventually be capable of producing what once required twenty.
That sounds like 4x productivity.
But there is a catch.
Those five people also have to carry the understanding, context, judgment, operational responsibility, and architectural coherence that were once distributed across twenty minds.
Otherwise you did not create a 4x engineering team.
You created a 4x software generation machine attached to a shrinking pool of human understanding.
The real opportunity is much more ambitious.
Not 10x output.
10x capability.
A small number of people capable of understanding larger systems.
Owning larger problems.
Making better decisions.
Moving from idea to reality with radically less coordination overhead.
That is a transformation worth pursuing.
And yes, something may be lost
We should be honest about this too.
Some engineers love coding.
Not because it is the most economically valuable part of their job.
Because they love it.
There is satisfaction in turning an idea into a working system with your own hands.
There is joy in discovering an elegant solution.
There is a state of deep concentration that comes from wrestling with a difficult technical problem until suddenly everything clicks.
There is identity in mastery.
AI does not need to destroy that.
But it may change how often the job gives it to us.
And pretending engineers should feel nothing about that is absurd.
Every major technological transition destroys some forms of mastery while creating others.
The interesting question is what the new mastery becomes.
I suspect it will involve much more than prompting.
Understanding complex systems.
Connecting technical decisions to human problems.
Seeing consequences before they happen.
Building mental models quickly.
Asking unusually good questions.
Making decisions under uncertainty.
Knowing when to trust the machine.
Knowing when not to.
Taking an ambiguous problem and carrying it all the way to an outcome.
There is enormous craft in that.
We just do not have thirty years of mythology around it yet.
The worst possible outcome
There is a future where all the metrics improve.
Cycle time falls.
Output rises.
Headcount stays flat.
PRs multiply.
Roadmaps move faster.
Leadership celebrates.
And quietly, the engineers get worse.
They understand less of the systems they own.
They stop reading code carefully.
They talk to each other less.
Architecture becomes whatever the model happened to generate three months ago.
Reviews become summaries of summaries.
Junior engineers never develop the instincts senior engineers rely on.
Nobody notices at first.
Because everything is shipping.
Until the organization reaches a level of complexity nobody inside it actually understands.
That is the version of AI transformation we should be afraid of.
Not because AI became too powerful.
Because humans stopped becoming more capable alongside it.
So what do we do?
Use AI.
Aggressively.
There is no prize for manually doing work a machine can do better.
Generate the boilerplate.
Explore five architectures.
Have the agent write the migration.
Ask it to find the bug.
Let it build the prototype.
Use every ounce of leverage available.
But move your ambition up with it.
Do not use AI to become the same engineer, only faster.
Use it to own things you could not own before.
Understand domains you previously would have avoided.
Explore more alternatives before committing.
Build the prototype and investigate the business problem.
Go deeper into architecture.
Get closer to customers.
Take responsibility for a larger surface area.
And most importantly:
Do not surrender the difficult human parts of engineering simply because the machine can now perform the visible ones.
Keep the judgment.
Keep the curiosity.
Keep the mental model.
Keep talking to other engineers.
Keep asking why.
Keep understanding what you ship.
Keep owning the outcome.
The role is changing
Maybe the title "software engineer" survives unchanged.
Titles usually lag reality.
But the role underneath it is already moving.
From code production to problem ownership.
From implementation to judgment.
From knowing syntax to understanding systems.
From receiving specifications to challenging them.
From writing every line to taking responsibility for every consequence.
From being measured by output to being trusted with complexity.
This transition will be uncomfortable.
Especially for people who spent years becoming exceptionally good at the part that is becoming cheap.
But cheap implementation does not make engineers irrelevant.
It makes mediocre implementation less valuable.
And it raises the ceiling on what an exceptional engineer can do.
The future does not need fewer people who understand technology deeply.
It needs more.
Because we are about to produce vastly more technology.
The question is no longer:
How much code can you write?
It is becoming:
How much complexity can you understand?
How large a problem can you own?
How good are the decisions you make when the machine can build almost anything you ask for?
That is the transformation.
And we are already inside it.
Read the beyond10x vision this reasons from, or start one governed change with Claude to see judgment stay explicit in practice.