Why developers are becoming product thinkers faster than expected
I used to think coding would always be my core work. Not just part of it, but the core. Even when AI tools started improving, I assumed the impact would be incremental, helpful, faster, but not fundamental.
I was wrong.
Today, I probably spend 10–20% of my time actually coding, and if I’m honest, that number is artificially high. I still code because I enjoy it, not because it is the bottleneck anymore. That shift surprised me, and what surprised me even more is that I don’t miss it.
Getting Lost in Code Used to Be the Job
For most of my career, getting lost in code was not a distraction; it was how I became good. I would go deep into things that didn’t strictly matter, tuning performance nobody would notice, exploring edge cases that would never happen, refactoring code that was already working fine.
From the outside, that looks inefficient. From the inside, that is how you build intuition. That is how you learn systems. That is how you become a senior developer.
You don’t learn it by following a clean path. You learn it by getting sidetracked, making mistakes, and slowly understanding why things behave the way they do.
AI doesn’t do that. It goes straight to the answer.
And now, so do I.
The First Change Was Speed
The first thing I noticed was not a role change, but a change in pace. The small things disappeared. Boilerplate became trivial, debugging became faster, searching for solutions became almost irrelevant, and shipping became continuous instead of something you worked toward.
It didn’t feel like a modest improvement. It felt like a different game. I expected that to feel uncomfortable, like I was skipping steps I shouldn’t skip. Instead, I enjoyed it, because the parts that disappeared were never the parts I cared about most.
What Took Its Place
When coding moved to the background, something else filled the space. Not something new, but something that had always been there, just underused.
I started spending more time thinking about the problem itself, what we are actually trying to solve, what should exist and, more importantly, what should not. I paid more attention to friction in the user experience and to the simplest version that still delivers value.
I found myself writing more specifications, making more product decisions, and thinking more about flows than functions. In short, I was doing product work.
I had always liked that part, but I was “the developer,” and later “the architect.” Those labels come with expectations: you are supposed to build. Now, building is no longer the scarce skill.
Two Moments That Make More Sense Now
Looking back, there were already signals.
Years ago, a manager told me:
"I think you are a better requirement analyst than a developer."
At the time, I didn’t agree. I was already a senior developer, and it felt like he was missing the point of what I was good at.
Now I understand what he meant.
There was another moment. A team was struggling with a solution for months, going in circles. I was added to the team and approached it differently.
Team lead said:
"We were stuck for 3 months. You solved it in a week."
That wasn’t about writing code faster. It was about understanding the problem better. At the time, it felt like a compliment; now, it reads like a job description.
What This Looks Like in Practice
Recently, I had to build a website for my wife’s private clinic, she is a doctor. Normally, I would reach for something like WordPress or another platform, not because I love those tools, but because they accelerate humans. They give you structure, plugins, and guardrails; they help you move faster.
This time, they got in the way.
Those platforms are built for humans managing websites, not for AI building them. The abstractions that help a human often constrain an AI.
So, I dropped that approach and went closer to the metal: raw code, Astro, no heavy platform.
I set up multiple AI agents with clear responsibilities, one focused on building the site, one handled the copy, another focused on marketing and positioning, and an orchestrating agent to distribute the work.
My role wasn’t to write every line. It was to define what needed to exist, to make decisions, and to guide the outcome so everything stayed aligned.
The result was done in a day.
That is not a small improvement; it changes how you think about work entirely. And it raises a bigger question: if AI works better closer to the metal, do we still need all these platforms, or were they always a workaround for human limitations?
Most Developers Are Optimizing the Wrong Skill
Most developers are still optimizing for coding speed, faster frameworks, better patterns, cleaner abstractions. But that is no longer the bottleneck.
The bottleneck is understanding: understanding the problem, understanding what should exist, and understanding what should not. If you optimize the wrong skill in this shift, you don’t become faster; you become irrelevant faster.
The Role Is Already Different
At this point, calling this “AI makes developers faster” feels too shallow. It changes what the job is.
The value is no longer in writing code, but in deciding what should be built, why it should exist, and how it should behave. You need to explain things clearly enough that an AI can execute them, spot when the output is wrong, and understand trade-offs even if you are no longer implementing every detail yourself.
That is product thinking, whether you call yourself a developer or not.
What That Means for Developers
If you want to stay relevant, the shift is quite clear. You are no longer just building; you are defining outcomes instead of tasks, writing specifications instead of implementations, managing AI instead of doing everything yourself, removing ambiguity early, and making decisions faster and more often.
This is not a softer version of engineering. It is a different layer of it, and in many ways it is less forgiving. If you misunderstand the problem, you will scale the wrong solution faster.
The Real Problem: How Do Juniors Learn This?
This is the part I don’t have a clean answer for. Everything I described above comes from experience.
You learn it by building things that fail, by debugging your own mistakes, by making decisions that turn out wrong and understanding why. That process creates seniors.
But if AI is doing most of the building, where do juniors get those reps? How do you develop intuition without going through the pain of building something yourself? How do you learn trade-offs without feeling the consequences?
We might end up with developers who are very good at prompting, but lack a deeper understanding of systems. That gap is going to matter, and I think we’re only starting to see it.
Final Thought
AI didn’t take away my value; it shifted it,from writing code toward deciding what is worth building.
I didn’t expect to enjoy that shift, but I do. And that might be the real change happening here, not that AI writes code for us, but that it forces us to think more clearly about what we are actually building in the first place.
We spent years building tools to help humans write code.
Now we might need to rethink everything for machines that do it better.
And that raises an uncomfortable question in my own field: if AI works best closer to the metal, what is the role of platforms like the Power Platform in the future?
Maybe they still matter, but for different reasons than we think. Or maybe they become a layer we bypass more often than we expect.
Either way, it forces a rethink.
Not just of tools.
But of where the real value sits.
