A Visio Call That Stuck With Me

A few days ago, I found myself in one of those Visio calls that starts as a routine catch-up and somehow turns into something you're still thinking about days later. A few colleagues, the usual small talk, and then somehow we ended up deep in a debate about the future of software engineering. Not the tired "AI will replace developers" conversation, but something more honest than that: what do we actually become in the next 2 to 3 years?

The first few opinions were pretty much what you'd expect. Some people thought AI would take over most of the coding and leave engineers as glorified reviewers. Others pushed back, arguing that nothing really changes at the core, that programming has always demanded human logic and creativity and always will.

But the longer we talked, the more one thing became obvious. The role isn't disappearing. It's turning into something different.

From Coders to Problem Architects

The idea that stuck with me most was this gradual shift from writing code to designing solutions. Writing code is getting easier and faster by the month. But figuring out what to build, why it actually matters, how it connects to everything else in the system, that part doesn't get automated. That's where the judgment lives.

So instead of grinding through feature implementation, more of the job becomes drawing the boundaries, making the architectural calls, and bridging the gap between what the business needs and what the technology can do. The code is still there. It just stops being the whole point.

Working With AI, Not Alongside It

Something else came up that I thought was worth sitting with. Future engineers won't just use AI as a tool they open when they're stuck. It becomes more like a collaborator you have to actually manage.

And that flips what matters. Syntax fluency becomes less important. What takes its place is knowing how to prompt well, how to read AI-generated code critically, how to catch what it gets wrong and understand why. The engineers who figure out how to direct AI rather than just consume its output are going to be in a completely different position from those who don't.

Getting Pulled Out of the Technical Bubble

There was a point in the call where someone said something that felt pretty true: the days of staying purely in the technical layer are numbered. Not because technical depth stops mattering, but because the expectation is expanding.

More and more, engineers are going to be expected to understand the product they're building, talk to the people using it, and care about outcomes rather than just outputs. Less "I shipped the feature," more "did this actually solve the problem."

The Specialist vs. Generalist Question

We argued about this one for a while without fully landing anywhere. But what emerged was something like: generalists will do well in fast-moving environments where adaptability is the whole game. Specialists will remain hard to replace in the areas that genuinely require depth, distributed systems, security, AI infrastructure. The people who are probably best positioned are the ones who are broad enough to hold the big picture and deep enough in at least one area to be genuinely valuable there.

What I Actually Took Away

I didn't leave that call worried. I left it energized, maybe a little unsettled in a good way.

Because the point isn't to write more code or write it faster. It's to think more clearly about the right problems, design solutions that actually hold up, and keep pace with tools that are evolving faster than most of us expected. The measure of a good engineer is quietly shifting from output to impact.

The tools will keep changing. The abstractions will keep rising. But the job underneath all of it, building things that matter and making good decisions under uncertainty, that part isn't going anywhere. We're just being asked to do it at a higher level than before.