When I wrote my last post about AI and problem-solving, I left something unsaid. Buried underneath the observation that AI was making me think more carefully was a quieter anxiety: the constant background noise about whether software engineering, as a profession, has an expiration date.

A few months later, that noise is louder. The models are better. The demos are more impressive. The takes are more extreme in both directions. And yet, my actual day-to-day experience has pushed me toward a position that’s less about survival and more about what I think the role is becoming.

The fear is real, but it’s aimed at the wrong thing

The “end of software engineering” discourse tends to imagine a future where AI writes all the code and engineers become unnecessary. I think this misidentifies what’s actually at risk. What’s eroding isn’t the need for people who understand systems, but the value of people whose only contribution is translating requirements into code.

If your job is to take a spec and implement it, that gap is closing fast. But that was never the most valuable, and at least for me, not the most fun, part of the work anyway.

What AI is actually doing to the role

Here’s what I’ve noticed over the past several months of working closely with AI tools: the distance between “engineer” and “product thinker” is collapsing, but only if you let it.

When iteration is cheap, you stop asking “can we build this?” and start asking “should we?” When you can spin up a working prototype in an afternoon, the bottleneck shifts from execution to judgment. What problem are we actually solving? For whom? What does success look like? These were always the right questions. Now they’re the only questions that matter, because the implementation part has a capable, tireless collaborator.

This isn’t theoretical for me. I’ve found myself doing more of what I’d call value identification work: noticing a friction point, forming a hypothesis about what would fix it, and being able to test that hypothesis quickly rather than deferring it indefinitely because the implementation cost was too high. The cost of a wrong idea used to be weeks. Now it can be days, or hours. That changes what’s worth trying.

Slower thinking, faster execution

There’s a paradox here that I find genuinely interesting: AI makes execution faster, but it makes thinking more important, not less.

The engineers I see struggling with these tools are the ones who try to shortcut the thinking. They prompt vaguely, get vague output, patch it together, and end up with something fragile. The engineers who are getting leverage are the ones investing more in the front end of the process: sitting with the problem longer, articulating constraints clearly, reviewing outputs with real scrutiny. The execution is faster, but the thinking is slower and more deliberate.

This is the leverage: slower thinking plus faster execution compounds. A feature I would’ve deferred for a quarter became a two-day experiment I was willing to kill if it didn’t work out.

Owning outcomes, not tasks

What this points to, I think, is a shift in how engineers need to think about the value they add at a company. The question used to be “what can I build?”, but more and more it is becoming “what should exist, and why?”.

That’s product thinking. And the engineers who will do well in the next few years are the ones who can move fluidly between “what problem are we solving” and “here’s a working version of a solution,” not because they’re full-stack generalists in the technical sense, but because AI has lowered the cost of implementation enough that the intellectual ownership of the outcome becomes the differentiator.

This requires a different kind of relationship with the organizations we work in. It requires being in rooms where the problem is still being defined, not just handed a ticket. Some organizations will make that possible. Others won’t, and that, increasingly, feels like an important filter.

The anxiety about AI replacing engineers isn’t irrational. But I think it’s tracking the wrong variable. What’s being replaced is the engineer-as-implementer. What’s emerging is the engineer-as-product-owner. Not in the Jira sense, but in a deeper sense: someone who has lived inside the system long enough to feel its gaps before users can articulate them, and who can now do something about it the same afternoon.