Almost Right - but Wrong
One of the things I care deeply about is helping other engineers grow. Over the last year, I’ve had a lot of conversations, some with folks just entering the field, others with seasoned pros, asking the same question: how is AI going to reshape our work? There is fear and uncertainty, but also some optimism.
There’s a rhythm to these tech cycles.
I’ve seen it before, big promises, huge hype, sweeping predictions. Right now, we’re being told that AI will replace entire roles, maybe entire industries. It’s the same energy we saw with self-driving cars. For years, we were told they were just around the corner. But today, in 2025, I still don’t see a 40-ton truck rolling down the Autobahn without a driver. Waymo works, yes, but in tightly controlled areas, in a few cities. Meanwhile, here in Europe, truck drivers are still very much in demand.
And I say this not just to throw shade on the tech, but to point out the gap between vision and execution.
Interestingly, that gap also shows up in my own life. Twenty years ago, I was fully in control behind the wheel. Today? On the highway, I let adaptive cruise control and lane keeping do a lot of the work. I still supervise. I’m still responsible. But my role has shifted, from direct control to oversight. That’s exactly how I think about LLMs right now. They help. They automate parts of the process. But they still need someone to guide, correct, and ultimately be accountable.
And that’s what’s missing in a lot of the hype around software automation.
We’re hearing bold claims that LLMs can “one-shot” applications. That you’ll describe what you want, and an AI will build it. But in practice, most of the time, the result is almost right. And that “almost” is a problem. Because the cleanup, the review, the debugging - it all takes time. Sometimes more time than doing it manually. Think about junior developer who is handing over a big project build from scratch to a senior for a review.
This includes the latest Stack Overflow developer survey from 2025, which found that a significant 66% of developers are frustrated with AI solutions because they are “almost right, but not quite.” That’s a real pain point. Developers want tools they can trust, not code that sounds smart but breaks in production.
And here’s the bigger truth: software engineering has never just been about writing code. It’s about making judgment calls. Understanding trade-offs. Navigating complexity, legacy systems, business constraints, and fuzzy requirements.
That’s not going to be “one-shotted” anytime soon. Think about customer asking for a new application, and you would just build it to his requirements, without any question, or CEO asking for a disaster recovery solution, and you would build it as you would like. Would any of those “customers” be happy with the result? Experience tells me otherwise.
And honestly, the idea that it could be has always felt more like investor pitch material than engineering reality. In my view, the so-called “illuminaries” from AI companies are, as you might expect, primarily engaged in marketing-raising more money by promising that fully autonomous AI agents will replace humans. CEOs are absolutely bought into the vision. They’re pushing adoption hard from the top down. Some are even making cuts in engineering teams to fund AI initiatives.
But the actual applications? They often fall well short of those big promises.
Of course, AI is driving real progress in software and beyond. Look at how it’s impacting medicine. Drug discovery, for instance, is moving faster than ever. The idea that we might not have to wait a decade for a new cancer treatment? That’s becoming more realistic.
We’re entering a phase of human acceleration. A few centuries ago, we moved from horses to steam engines. Then we built cars, planes, satellites, the internet. Today, we don’t ride carriages or store fish in salted barrels anymore, and no one misses it. Why? Because we figured out better ways. And we’re doing that again, right now. Not just in how we build, but in how fast we build.
Yes, the world is speeding up. But instead of panicking, we should see it for what it is: another shift in how we do our work, not an erasure of that work altogether.
If you’re in a field like copywriting, or doing basic customer support or templated graphic design, then yeah, AI is already knocking at the door. If the output is “good enough,” companies will take it. And if you’re in that space, it’s a good time to seriously rethink your career trajectory.
But for software engineers? And especially infrastructure engineers? That future’s not here yet, and it’s not close.
Our field has expanded, not shrunk.
I remember when we were just called engineers. Or administrators. Those titles barely exist now. Today, we’ve got DevOps, NetOps, SecOps, SREs, Cloud Architects, Staff Engineers, Principal Engineers, MLOps, Platform Engineers, the list grows every year. And it’ll keep growing. The complexity we deal with has scaled massively. The layers of abstraction, the integrations, the security needs, the compliance constraints, it’s a long, long way from building static web pages in the early 2000s.
And LLMs aren’t going to shrink that surface area. They’re going to stretch it.
Yes, more people will be able to write code. Yes, building an app will become easier. But who’s going to make sure that app is secure, scalable, observable, maintainable? Who’s going to facilitate all of that? Who’s going to connect it to production, monitor it, roll it back when it breaks?
That’s on us!
The role of the engineer is evolving, from maker to enabler, from coder to curator, from task executor to systems thinker. We’re moving up the stack.
At the same time, we have to be honest: the pressure is on. The reason many companies are pushing AI tools isn’t always because they improve output, it’s because they’re afraid of missing the boat. Fear of falling behind is driving adoption, even when the actual ROI isn’t there yet. We’re spending more time reviewing AI generated code than writing our own. We’re supervising tools that can’t be trusted blindly.
And then there’s the elephant in the room: if we really stop investing in junior engineers, because we assume AI will do the early work, where do the next senior engineers come from? You can’t build a pipeline of experienced people if you kill off the entry-level roles. It’s short-term thinking that leads to long-term pain.
We’re also seeing wild predictions that one engineer, aided by AI, will replace an entire product team. Maybe that’s true for simple MVPs. But complex systems? Large organizations? Regulated environments? That’s not reality. That’s a pitch deck fantasy.
In fact, if history teaches us anything, it’s that when things get faster, demand grows. That’s Jevons Paradox in action. LLMs may make us faster, but that doesn’t mean we’ll do less. It means we’ll do more. We’ll build more systems. Automate more processes. Launch more products. That’s not job elimination. That’s job transformation.
And that’s the key: transformation.
I use LLMs every day. They’re useful. They help me test ideas faster, reduce friction, and get moving. But they don’t replace what I do. They don’t think, reason, or judge. They don’t see the big picture. I do.
We’re not fighting AI, we’re shaping how it’s used. Our job now is to lead the integration of these tools into our workflows, to define how they improve, not undermine our standards. And we have to do it before someone else does it for us.
Software engineering isn’t going away. It’s shifting, just like it always has.
We don’t write assembler by hand anymore. We stopped caring about hardware we run on. We don’t configure each server with shell scripts in a dark corner of a data center. And we don’t need to. We’ve abstracted, automated, and moved up the stack. This is no different.
The LLM era isn’t the end of our craft. It’s the beginning of a new layer. And the people who understand how to build on top of it, who can reason, architect, lead, are the ones who’ll thrive.