Are We Becoming AI Managers Instead of Developers?
I've been doing front-end development for somewhere around 20 years now. During that time, I've watched the job change over and over again. New frameworks. New languages. New tooling. New ways of building and deploying software. But I don't think I've ever had to adapt as quickly as I have over the last few years. And lately I've found myself asking a strange question:
Am I becoming more of an AI manager than a software developer?
Because when I look at how I work today, I barely write code anymore.
I Barely Write Code Now
Even a year ago, I was still writing quite a bit of code myself.
Today, most of my development work looks very different.
I’ll think through a feature, work out the requirements, ask an AI model to help me plan it, and then have an agent implement it.
Sometimes I’ll use one model for planning and another for implementation. Sometimes I’ll break the work into smaller pieces. Sometimes I’ll experiment with different approaches depending on the complexity of the problem or how much context I’m working with.
Then I review the result.
I make sure it works.
I make sure the code makes sense.
I make sure it’s maintainable.
And if something looks strange, I start asking questions.
That’s increasingly what software development looks like for me.
So am I developing software?
Or am I managing AI that develops software?
At this point, the answer might be a little bit of both.
I Thought This Would Make the Job Worse
When AI coding tools first started getting good, I wasn’t particularly excited about this version of the future.
One of my first thoughts was…
Great. So now I’m just going to review code all day?
Code review has never been my favorite part of the job.
The idea that AI would write everything while I sat there inspecting somebody else’s work didn’t sound especially appealing.
But something unexpected happened as the tools improved and I got better at using them.
I started enjoying it.
Not necessarily because I enjoy reviewing generated code, but because there’s a new problem to solve…
How effectively can I communicate what I want and get AI to produce it?
There’s something pretty wild about describing a feature in one or two sentences and getting back something very close to what I would have built myself.
Sometimes, dare I say it, I even get something better than what I would have come up with.
Of course, I also get bad solutions.
That’s part of the job too.
But when something that might have taken me several hours can suddenly be built, reviewed, adjusted, and finished in 20 minutes, it’s hard not to find that exciting.
The problem-solving hasn’t disappeared.
The problem has changed.
Experience Feels More Valuable Right Now
This is where things get complicated.
AI can generate code extremely quickly.
But being able to tell whether that code is good is still incredibly important.
I’ve spent years working with HTML, CSS, JavaScript, Angular, PHP, WordPress, jQuery, and plenty of other technologies along the way.
I’ve made bad architectural decisions.
I’ve chased bugs for hours.
I’ve implemented things one way, discovered why that approach didn’t work, and rebuilt them another way.
I’ve accumulated a huge collection of mistakes.
And oddly enough, those mistakes are incredibly useful now.
They help me recognize when generated code looks wrong.
They help me ask better questions.
They help me understand when an AI is solving the wrong problem even if the code itself looks perfectly reasonable.
Right now, that experience gives experienced developers an interesting advantage.
We can let AI handle more of the implementation while leaning heavily on the judgment we’ve developed over the years.
But that raises another uncomfortable question.
How Do Junior Developers Get That Experience?
This is probably the part I struggle with the most.
A lot of the work we traditionally gave junior developers is exactly the type of work AI is becoming really good at.
Refactor this component.
Update these usages.
Write this utility.
Fix this bug.
Add this small feature.
Those tasks weren’t always glamorous, but they were important.
You learned by doing them.
You made mistakes.
You ran into weird edge cases.
You discovered that the solution you thought was obvious wasn’t actually very good.
Over time, all of those experiences made you a better developer.
So what happens when AI starts doing a large portion of that work?
How does a developer who is just getting started build the judgment required to evaluate what AI produces?
I don’t have a great answer yet.
AI can absolutely help someone learn faster than we could in the past. You can ask questions instantly, explore unfamiliar code, generate examples, compare approaches, and have complicated ideas explained in seconds.
That’s incredible.
But there’s a catch.
You can’t assume what you’re learning from AI is 100% correct.
You still need enough understanding to question the answers.
That’s a strange place for new developers to be.
Maybe Learning Isn’t Actually That Different
At the same time, maybe some parts of becoming a developer haven’t changed as much as we think.
When I was getting started, building things was basically my hobby.
I built websites for family.
I built websites for friends.
If I heard somebody needed a website, I’d probably offer to build it.
Sometimes I barely charged anything.
Sometimes I didn’t charge at all.
I wasn’t doing it because it was an efficient way to run a business.
I was doing it because I wanted experience.
Every project taught me something new, and eventually those projects became a portfolio that helped me get real work.
If I were starting today, I think I’d probably do the same thing.
The difference is that I’d have AI sitting next to me while I did it.
That could actually make it possible to explore more ideas, build more projects, and learn faster.
But I’d still need to stay curious about what was being generated instead of blindly accepting it.
If AI Writes It, I’m Still Responsible for It
At least for now, I have a pretty simple rule for professional software development…
If AI writes something and I don’t understand what it’s doing or why it’s there, I’m probably leaning on AI too much.
I don’t necessarily need to remember every API from memory.
I don’t need to manually type every line.
But if I’m putting something into production, I should be able to explain what it does.
I should understand the decisions being made.
And I should be able to recognize when something doesn’t look right.
That means keeping up with the technologies I’m using is still important.
When frameworks evolve, I need to know about it.
When better patterns emerge, I need to understand them.
And when AI produces something that feels strange, I need to question it.
Sometimes that means asking another model.
Sometimes it means digging into documentation.
Sometimes it means throwing the implementation away and trying something different.
The AI can do a lot of the typing.
I still own the result.
Are We More Productive, or Is More Just Expected of Us?
AI definitely makes me faster.
I don’t think I’m suddenly a 100x developer, but I can solve certain problems dramatically faster than I could before.
I’ve worked through some complicated problems recently that would have taken me significantly longer without AI.
The frustrating part of development where you stare at a problem for hours thinking…
How am I possibly going to make this work?
…happens less often.
You can explore several possible solutions quickly.
You can ask for alternatives.
You can test assumptions.
You can iterate much faster.
That’s great.
But there’s another side to it.
When everyone knows developers can move faster, expectations move too.
If a task that used to take a day can now take an hour, nobody is going to keep planning as though it takes a day forever.
So yes, AI makes us more productive.
But it probably also means more is expected of us.
That’s not necessarily unreasonable.
The tools changed.
The amount of work we’re capable of doing changed with them.
What Happens When Coding Becomes Cheap?
This might be the biggest question of all.
What becomes valuable when producing code becomes incredibly cheap?
For most of my career, knowing how to turn an idea into working software was a relatively scarce skill.
That’s changing.
Today, someone with very little programming experience can already describe an idea and produce something surprisingly functional.
Those tools are only getting better.
So maybe the valuable part of software development increasingly becomes everything surrounding the code.
Understanding the problem.
Understanding the user.
Making good product decisions.
Knowing what should be built.
Knowing what shouldn’t be built.
Recognizing bad solutions.
Designing systems that can survive beyond the first demo.
Making tradeoffs.
Judgment.
Right now, experience plays a massive role in all of that.
But even that could change.
Models are improving so quickly that it’s difficult to confidently predict what any of this looks like a few years from now.
Maybe eventually the implementation becomes something we barely think about at all.
Maybe We Become Product Builders
There’s a future I can imagine where developers become less concerned with the actual mechanics of producing code.
In some ways, that wouldn’t be unprecedented.
Think about working on a car.
Changing your own oil isn’t particularly difficult.
Neither are plenty of other basic maintenance tasks.
But most people still take their car to a mechanic.
It’s not because changing oil has become impossible.
It’s because we created an abstraction above that work.
People care that the car works.
They don’t necessarily care about performing every step required to keep it working.
Software could eventually move in a similar direction.
Maybe the important skill becomes turning a business problem into a working product, while the lower-level implementation becomes increasingly automated.
At that point, maybe we’re not really “coders” anymore.
Maybe we’re product builders.
And maybe that’s fine.
Would My Old Self Recognize This as Software Development?
Absolutely not.
If you showed me my current workflow ten years ago, I’m not sure I would have called it software development.
I’m describing things in plain English.
I’m asking agents to make changes.
I’m reviewing generated implementations.
I’m having conversations with software that writes software.
It’s weird.
But I still think I’m developing.
The game has changed.
We’re solving the same kinds of problems, but we’re solving them differently.
And unlike many of the changes I’ve seen throughout my career, this one isn’t happening incrementally.
It feels like the tablecloth is being pulled out from underneath us.
Every month the tools get better.
Every month the workflow changes a little more.
We’re adapting constantly.
Do I Actually Like This Version of the Job?
Surprisingly, yes.
There have definitely been moments where I’ve wondered what all of this means for my career.
There probably will be plenty more.
But right now, this is one of the most interesting periods I’ve experienced as a software developer.
Software development has always attracted people who like solving problems.
That’s still what I’m doing.
I’m still thinking creatively.
I’m still figuring out how things should work.
I’m still building things people need.
I’m just doing it with an entirely different set of tools.
And I’ve found a new kind of enjoyment in seeing just how effectively I can use those tools.
So maybe I am becoming an AI manager.
Maybe we’re all becoming something slightly different from what we used to call a developer.
I’m not sure the terminology matters that much yet.
What matters is that we’re still building.
The bigger question is whether you like this version of the job.
Because I think we’re going to be seeing a lot more of it.
