Why AI makes engineering judgment more valuable, not less
A team spent months rewriting a legacy service in a modern language.
The code compiled.
The tests passed.
A regression harness reported growing field-level parity with the original implementation.
By every delivery metric, the project was progressing.
It was also heading in the wrong direction.
The rewrite had become a transliteration exercise.
Legacy data structures became their modern equivalents.
Presentation logic became auto-generated mapping layers.
Mutable runtime state was bolted onto persistence objects to avoid rethinking the assembly model.
Every individual decision was defensible.
The overall direction was not.
What emerged was a codebase that faithfully reproduced the shape of the legacy system rather than solving the problem the service existed to solve.
The translation was successful.
The design was not.
The Sword in the Stone
For centuries, the lesson of the Sword in the Stone was simple.
Only the worthy could pull the sword free.
The challenge was access.
The challenge was strength.
The challenge was capability.
Software engineering worked the same way.
Ideas were cheap. Implementation was expensive.
Bad designs often died before they became dangerous because somebody eventually had to write the code. Every unnecessary abstraction, every misplaced responsibility, every architectural shortcut carried a cost.
The stone pushed back.
Then AI arrived.
Today, a single engineer can generate thousands of lines of structurally correct code in hours. Rewrites that once consumed quarters can be completed in days. Boilerplate, translation, scaffolding, and framework integration are no longer meaningful obstacles.
The stone is gone.
Which means pulling the sword is no longer the test.
Judgment is.
The Transliteration Trap
Historically, this kind of problem had a natural defense mechanism.
Pain.
The fifteenth bolted-on field felt wrong.
The five-hundredth line of mapping code felt wrong.
The eighth layer of translation logic felt wrong.
Eventually someone would stop and ask:
Are we building the right thing?
AI changes that dynamic.
The implementation accelerates.
The discomfort disappears.
The feedback loop weakens.
A developer can generate thousands of lines of structurally correct code before ever experiencing the friction that once forced architectural reflection.
AI does not create the wrong direction.
It removes the cost of following it.
When the Stone Disappears
The traditional interpretation of the Sword in the Stone assumes scarcity.
One sword.
One king.
One person capable of pulling it free.
Engineering used to work the same way.
Implementation was scarce.
Time was scarce.
Skilled developers were scarce.
The effort required to build something acted as a filter against bad decisions.
Not because engineers were wiser.
Because the economics demanded it.
AI changes the economics.
Today every engineer has access to extraordinary implementation capability.
The ability to generate code is no longer rare.
The ability to recognize what should be built remains rare.
That distinction matters more than most organizations realize.
The Design Was Always Available
The uncomfortable truth about this rewrite is that the eventual solution was not revolutionary.
The aggregate pattern was well understood.
The domain model was well understood.
The filter architecture was well understood.
The separation of persistence concerns from domain concerns was well understood.
Nothing about the redesign required a breakthrough.
The patterns were available from day one.
What changed was not technology.
What changed was the question being asked.
The original effort focused on:
How do we convert the legacy system into a modern language?
The redesign focused on:
What should this system become?
The first question produces translation.
The second produces architecture.
AI Changed the Economics, Not the Craft
This is where many conversations about AI become confused.
People assume that because AI can write code, software design somehow becomes less important.
The opposite is happening.
AI has collapsed implementation cost.
That means design mistakes become more expensive, not less.
A poorly considered abstraction can now be implemented across an entire codebase before anyone notices.
A flawed architectural direction can accumulate tens of thousands of lines of code in days instead of months.
Good judgment scales.
Bad judgment scales too.
The machine is indifferent.
It amplifies both equally.
The New Senior Engineer Test
For years, senior engineers were evaluated partly on execution.
Could they navigate complexity?
Could they deliver large systems?
Could they guide implementation?
Those skills still matter.
But AI is steadily reducing their scarcity.
The value migrates upward.
Toward judgment.
Toward architecture.
Toward the ability to identify the correct problem before generating the solution.
The most valuable engineer in an AI-assisted organization is not the person who can produce the most code.
It is the person who can recognize when producing more code is the wrong answer.
The Sword Was Never the Test
People keep asking whether AI will replace senior engineers.
I increasingly think they are asking the wrong question.
The interesting question is what happens when implementation becomes effectively free.
The answer is uncomfortable.
Everything we once used as a proxy for engineering value becomes less important.
Typing
Boilerplate
Translation
Framework expertise
The value that remains is judgment.
The lesson of the Sword in the Stone was never that Arthur was stronger than everyone else.
It was that he understood what the sword was for.
For most of software history, implementation was the stone.
It pushed back on bad ideas through effort, cost, and time.
AI removed the stone.
Now everyone can pull the sword.
Which means the thing we thought we were testing all along—our ability to build—was never the thing that mattered.
The real test was always judgment.
