The old wizard is away.
The apprentice’s job is to fetch water. But he thinks, why do all this work manually?
He remembers a spell he heard from his master, brings a broom to life, and tells it to fetch water.
The broom starts working.
Bucket after bucket. Incredible speed.
There’s just one problem.
The apprentice doesn’t know the spell to make it stop.
The room begins to flood.
Desperate, he grabs an axe and splits the broom in two.
Now there are two brooms.
And both are fetching water.
In 2026, many of us have this spell in our hands.
Write a prompt, and the feature appears.
Tests pass. PR gets merged. Sprint ends.
But one question is becoming increasingly uncomfortable:
Who actually owns this code?
Nobody intentionally pushes unreviewed code to production. But the incentives almost always point toward delivery.
Velocity is measurable. Understanding is much harder to measure.
You can carefully review a 40-line PR. With an 800-line AI-generated PR, at some point the temptation to skim through it and say “LGTM” becomes very real.
And the problem is, the code may not even look bad.
Clean naming.
Well-written comments.
Confident-looking abstractions.
Mistakes don’t necessarily look ugly anymore.
The more subtle difference lies somewhere else:
“It works” and “I understand why it works” are not the same thing.
Under deadline pressure, we often treat them as if they are.
In my previous post about technical debt, I wrote about how decisions often survive while the context behind them disappears.
With unreviewed AI-generated code, the problem is even stranger.
The context hasn’t been lost.
It may never have existed in a human mind in the first place.
Then, when something breaks in production, debugging becomes archaeology.
The same business logic appears in three different places in three different forms because there were three different prompts.
Then we ask AI to fix the AI-generated bug.
It adds more code.
The axe falls.
Now there are two brooms.
In the Mahabharata, Abhimanyu knew how to enter the Chakravyuha, but he didn’t know how to get out.
AI can take us deep into an unfamiliar codebase incredibly quickly.
But when production goes down at 3 AM, we still need to know the way out.
There’s little reason to expect engineers to stop using AI to write code. Nor should we.
Instead, AI is shifting where engineering value lies.
Writing code is becoming cheaper.
Understanding code is becoming more valuable.
The valuable engineer will not simply be the one who can generate code.
It will be the engineer who understands which code to accept, which code to reject, when to stop abstracting, and where to start debugging when the system begins to fall apart.
Because AI won’t sit in the postmortem.
It won’t explain an architectural decision to the client.
And it won’t own the production incident.
That ownership still belongs to us.
So use AI as a pair programmer, not a ghostwriter.
In Goethe’s story, the master eventually returns and stops the broom.
The story reminds us of something important:
Knowing how to use power and knowing how to control power are not the same thing.
In our story, though, no master is coming back to fix everything for us.
We have to become the master ourselves.
So before you hit the merge button, try one simple test:
If this code breaks tomorrow, can I explain, without AI, why it was written this way?
If the answer is no, maybe the code isn’t really yours yet.
You’ve only awakened the broom.
