I’ve been writing software long enough to remember when being stuck was just part of the job.
You’d get a ticket. You wouldn’t know how to do it. You’d read documentation. Search Stack Overflow. Put breakpoints everywhere. Stare at a stack trace for an hour.
Sometimes you’d spend half a day chasing a bug only to discover you’d misspelled something.
It was frustrating as hell.
But something was happening during those hours that I didn’t appreciate at the time.
I was learning how software actually worked.
Today, when I get stuck, I can ask AI and usually get something useful back in seconds.
Increasingly, I don’t even have to do that.
I give an AI coding agent access to the repository and tell it what I want.
“Add this feature.”
“Fix this bug.”
“Write tests for this.”
“Refactor this.”
Then I watch it work.
It searches the repository. Opens files. Writes code. Runs tests. Notices something failed. Changes the code. Runs the tests again.
Sometimes I barely touch the keyboard.
A few years ago, if you’d shown this to a room full of programmers, they would have assumed you were demonstrating technology from the future.
And when it works, it’s incredible.
Tasks that used to consume an afternoon can be finished before lunch. Boilerplate is almost free. Writing tests is dramatically faster. When I enter an unfamiliar codebase, I can ask the AI:
“Trace what happens after the user clicks this button.”
And it’ll walk through the codebase for me.
But there’s another side to this that people outside software development probably don’t see.
We’re generating more code while spending less time actually writing code.
Those aren’t necessarily the same thing.
I’ve had AI generate code that looks beautiful.
Good variable names. Nice abstractions. Comments. Tests. Everything looks professional.
And it’s wrong.
Not obviously wrong.
That’s the dangerous part.
It can be wrong in ways that require you to understand the system to notice.
So increasingly my job feels less like being the person building the house and more like being the building inspector.
The AI builds.
I walk around afterward checking whether the plumbing actually connects to anything.
That changes what being “good at programming” means.
Before AI, a large part of the skill was knowing how to produce code.
Now another skill is becoming equally important:
Knowing when code that looks correct isn’t correct.
And that requires experience.
Which creates a weird problem for junior developers.
I’ve watched younger programmers get an error and immediately give it to AI.
AI suggests a fix.
They apply it.
New error.
They give that one to AI.
Another fix.
Eventually the program works.
But ask them what was actually wrong and sometimes they can’t explain it.
I heard about one junior developer debugging an authentication system who couldn’t explain how the authentication flow actually worked.
Why?
The AI had written it.
That’s the part that worries me.
Not because using AI is cheating. Nobody in professional software development cares about cheating. If a tool makes you faster, you’re supposed to use it.
The problem is that struggle used to be part of the training.
Junior developers got crappy tickets.
They wrote crappy code.
A senior developer reviewed it and asked:
“Why did you do this?”
The junior explained their reasoning.
The senior explained why it was wrong.
The junior rewrote it.
Repeat that process hundreds of times and eventually the junior becomes the senior developer.
Now imagine removing the first half of that loop.
The junior doesn’t write the crappy code anymore.
AI writes surprisingly competent code.
Now we’re asking someone who hasn’t developed engineering judgment to review work that may look more sophisticated than anything they could write themselves.
That’s a strange apprenticeship model.
One young developer described realizing this when they started interviewing for other jobs. Suddenly they had to solve programming problems without AI.
They discovered they’d effectively outsourced much of their problem-solving ability.
And there’s another consequence that may end up being even bigger.
Expectations are changing.
Once management knows these tools exist, the productivity gain doesn’t necessarily become free time.
It becomes the new baseline.
AI saves you two hours?
Great.
Now you’re expected to produce two more hours’ worth of work.
AI gets better?
Now you’re expected to produce even more.
I’ve heard developers describe managers asking why features still take so long when AI can supposedly write the code. Employees get shown stories about engineers running multiple AI agents simultaneously and are asked why they aren’t doing the same.
The problem is that AI doesn’t eliminate all the work.
It moves the work.
Less typing.
More reviewing.
Less searching documentation.
More verifying.
Less writing boilerplate.
More architecture.
Less “How do I implement this?”
More “Is this implementation actually safe to ship?”
I’m certainly not giving AI up.
The productivity gains are too useful.
But I’ve changed how I think about it.
I don’t want AI to be the engineer.
I want it to be an extremely fast engineer working underneath me.
I still need to understand the architecture.
I still need to decide what we’re building.
I still need to understand the tradeoffs.
And most importantly, if AI writes 500 lines of code, I’m still responsible for those 500 lines.
“I don’t know, AI wrote it” isn’t going to be a particularly comforting explanation when production goes down.
That may ultimately be where software engineering is headed.
The valuable engineer won’t necessarily be the person who can type code the fastest.
Typing code may become one of the cheapest parts of software development.
The valuable engineer will be the person who can look at a complicated system and understand:
What should we build? How should these pieces fit together? What could go wrong? Is this secure? Is it maintainable? Does it actually solve the problem?
And is the machine confidently doing something stupid?
In other words, AI may reduce the value of writing code while increasing the value of understanding software.
But there’s one question I don’t think the industry has figured out.
If AI does more and more of the beginner-level programming, how are beginners supposed to acquire the experience necessary to develop that judgment?
For decades, the way you became a great programmer was by spending years being a mediocre programmer.
You wrote code.
You broke things.
You debugged them.
You made architectural mistakes.
You got embarrassed in code reviews.
You learned.
Eventually thousands of tiny lessons turned into intuition.
AI can eliminate a remarkable amount of that friction.
That’s exactly what makes it useful.
But friction was also how we learned.
So I don’t think the most interesting question for software developers is:
“Will AI replace programmers?”
It’s this:
“What happens when we automate the process that used to create good programmers?”
That one I don’t think anybody knows the answer to yet.