I've always loved coding. Genuinely. The problem-solving, the elegance of a clean abstraction, the small dopamine hit when a tricky bug finally surrenders. Close to thirty years in and that part hasn't faded.
But I also always had to understand what I was coding. Why this ticket and not the other one. Who was going to use this. What the customer actually needed, not what the spec said they needed. I'd ask. Sometimes too much. I'd open the product on weekends, click around, get annoyed at things that felt off, then write the fix on Monday whether anyone asked me to or not. I always tried to see the product, the user, the bigger picture around the lines I was writing. For me that was the fun part. The code was the means.
Over the years I worked with a lot of engineers who didn't do any of that. Some of them were friends. Most were genuinely talented. They wanted the spec, they wanted the ticket, and they wanted to be left alone to write the code. "That's not my job" came up a lot. And honestly, at the time, that was a fair answer. It was normal. It was accepted. It was not flagged in performance reviews. Nobody put it on a job ad. The org chart said engineers wrote code and PMs thought about users, and most companies pretended that was true.
Looking back, it was never really true. It just didn't show. And today it shows, brutally.
It was never hidden, it was just easier to ignore
Here's the thing I notice when I run through twenty years of colleagues in my head. The engineers who got promoted faster, who got recruited away first, who founded the next thing, who survived layoffs, who never seemed to be the ones updating their LinkedIn during a reorg. They were not always the strongest technical minds in the room. Some of them were genuinely average coders. What they had was a kind of entrepreneurial reflex. They cared. They opened the product. They DM'd support. They argued with PMs. They had opinions.
The pure-technical engineers around them, the ones who wanted only the spec and only the code, did fine too. Mostly. They got their salary, they shipped their tickets, they had a reasonable career. But "fine" is not "thriving." The compounding advantage was always going to the other group. It just took ten years to show up as a number on a payslip, and by then nobody was tracking the comparison anymore.
I remember a guy I worked with around 2018. Brilliant engineer. Could write a custom scheduler from scratch over a weekend. Hated talking about features. Hated meetings with product. Said, more than once, "that's not my job." He's a friend, so I'll be fair: he was right that it wasn't formally his job. He was wrong that it didn't matter. Five years on, he's the one still grinding leetcode for interviews while three less technically gifted colleagues from the same team have all been promoted, started companies, or moved into roles he'd actually love.
This was visible if you knew where to look. Most of us didn't look. I almost didn't, for a long time, because I just assumed it was obvious that you'd care about what you were building. Turns out it wasn't obvious at all.
What AI actually did
Let me be blunt about the AI part, because I think it's getting both over- and under-credited at the same time. AI did not invent this dynamic. It just stripped the cover off it.
For two decades, the technical-only engineer was protected by a simple economic fact: writing code took time, and time was scarce. If you could turn a spec into working software, you had value, even if you contributed nothing else. The market was forgiving because the bottleneck was real.
That bottleneck is gone now. According to GitHub's enterprise Copilot research with Accenture, developers using Copilot saw 8.69% more pull requests merged and 84% more successful builds. Stack Overflow's 2024 Developer Survey found 76% of developers are using or planning to use AI tools, with 81% citing productivity as the main benefit. The mechanical, type-things-into-an-editor part of the job, the part that used to absorb most of an engineer's week, is largely automated.
So what's left? The part that was always the actual job. Knowing what to build. Knowing why. Noticing when the spec is wrong. Knowing which of three reasonable approaches will hold up in two years. Pushing back when needed. Talking to a customer and walking away with the right insight, not the loudest one.
Those things were already what separated good engineers from average ones. AI didn't change the criteria. It just removed the camouflage.
Product thinking was always the moat
Here's the thing nobody wants to say out loud at engineering all-hands. The engineers who are doing fine right now, the ones still getting hired, still getting promoted, still feeling reasonably secure, are not necessarily the best coders in the room. They're the ones who care about the product.
I mean genuinely care. They open their own product daily. They notice when something feels off. They DM the PM with a question before the spec is even written. They push back on a designer's flow because they've watched users get stuck on the same step three times. They're the ones who, when a customer email lands in the support channel, actually read it.
This was always the differentiator. It just used to be a "nice-to-have" line in a performance review. Now it's the entire game.
A friend of mine who runs engineering at a Series B startup put it this way last month: "I don't need someone who can write better code than Claude. I need someone who knows what code Claude should be writing."
That's the shift. And it's brutal.
Why this feels new but isn't
The cruel part is that this was never hidden. Every senior engineering blog post for the past decade has been screaming about it. "Talk to your users." "Understand the why." "Engineering is a product role." Every staff engineer ladder I've seen in the last five years explicitly lists product judgment as a senior expectation.
The reason it feels new is because the market was forgiving. Companies were over-hiring. The bar for staying employed was lower than the bar for being good. You could ignore the advice, do the narrow technical work, and still be safe.
That gap closed in late 2023 and it has not reopened. Layoffs.fyi tracked over 264,000 tech layoffs in 2024 alone. The engineers I see landing on their feet aren't necessarily the most senior. They're the ones who can sit in a room with a customer and a designer and a PM and contribute on equal footing. The ones who got let go and stayed unemployed, in painfully many cases, are the ones who built a career on technical execution alone.
I'm not celebrating that. It's a sad thing to watch. Some of the most technically talented people I know are in this exact position right now, and they did not deserve a market that lied to them for ten years about what the job was.
What actually helps now
If you're an engineer reading this and feeling defensive, I get it. Some of this lands hard. But here's what I'd say if you cornered me at a meetup.
You don't need to become a PM. You don't need to learn design. You don't need to memorise OKR frameworks. You need to do one specific thing: understand the product you're building well enough to have an opinion about it.
That's it. That's the whole intervention.
Read the support tickets. Use the product on a real device, with a real account, the way a customer would. Sit in one customer call a quarter. When a PM hands you a spec, ask why. Not in a confrontational way. In a curious way. "What problem is this solving for which user?" Most PMs will be relieved that someone is finally asking.
The work that AI cannot do, will not do, and is not even trying to do, is figuring out what should be built. That work is sitting on the table waiting for someone to pick it up. The engineers who pick it up are going to be employed for the next twenty years.
Some of the best engineers I know have always quietly done this. They don't talk about it as "product thinking." They just call it doing their job. Maybe that's the lesson hiding in all of this. The job was never just writing code. It only ever looked that way from the outside.