Thoughts on AI from a software engineer (at heart)

Posted by & filed under , .

There’s been a lot of noise lately about AI “replacing” software engineers. I get it. Watching GPT-4 generate code on command or seeing Copilot autocomplete entire functions can feel like magic. For some, it sparks excitement; for others, existential dread; and for others yet the wrong belief that software engineering teams are a thing of the past.

My recent years of experience in various executive positions has seen me at times far removed from the code but I am still a software engineer at heart: I tinker with tech all the time, I play with code and frameworks and platforms (yes, including AI !) so I decided to add my 2 cents in these recent discussions.

And here’s the thing: software engineering is so much more than just writing code.

I’ve been building systems long enough to know that while AI tools are game-changing, they’re not taking our jobs. They’re changing how we do our jobs — and in many ways, making us better at them.

Let me explain.

Code Is Just the Tip of the Iceberg

Yes, AI can write code. Sometimes it even writes decent code. But software engineering isn’t a typing contest. If all we did was translate requirements into syntax, we would have been in trouble the moment IDE’s and automated code tools appeared. But code is just one part of a much bigger ecosystem.

Here’s what AI doesn’t (yet) do well (and to be clear, I think in years to come it will, however, I see at the moment all efforts being spent in the direction of coding, which is only a small part of software engineering):

System Architecture

Designing a system that’s modular, scalable, secure, and cost-effective isn’t something you can just prompt into existence. It requires deep understanding of the business domain, tradeoffs, constraints, team capabilities, and long-term evolution.

AI can assist in suggesting patterns or architectures, but it doesn’t understand the context behind your product. A good engineer designs for change — AI can’t anticipate product pivots or future scale challenges. We can.

I see it’s still often the case, when deciding to explore a new language or framework, that tutorials and books go down the path of building a Twitter (sorry, X!) clone — and more recently I have started seeing some building Netflix clones too; if writing the code was the only thing, by now both Twitter and Netflix would have been sunk by competing clones created from these tutorials, but they are still going strong! Because again the coding is just a small part of it, having a solid architecture which enables them to experiment quickly, with high uptime matters more than just the code.

Which brings me to next point:

Uptime & Reliability

The real world is messy. Users don’t care if your code compiles, or if it was written by Claude or if you were able to write it with the help of AI in only 10 minutes — they care if the app works at 3AM on a Sunday when traffic spikes.

Keeping a system alive under stress, managing graceful degradation, understanding service-level objectives (SLOs), and setting up observability pipelines? That’s not something you get from ChatGPT. It’s a craft in a way, it’s operational knowledge, it’s knowing your stack and its weak spots, it’s knowing the architectural decisions made and the reasons behind it.

With the user attention span (and patience!) at minimum nowadays, having your platform down for a while is the guaranteed way to lose users — and revenue! I believe frameworks and platforms will emerge, designed to take care of themselves, and systems will be built on top of those; we’re scratching the surface currently with the likes of Replit, eventually more complex systems will emerge which can manage uptime and reliability. The challenge will always be though to evolve these systems to keep up with the needs (which are growing exponentially in the current AI-enabled age); and a strong engineering team will be the one instrument to help navigate through this.

Incident Management

When things break — and they always do — the playbook isn’t “ask Copilot”; it’s diagnosing (yes with the help of AI!), collaborating under pressure, communicating with stakeholders, and post-mortem analysis to prevent future incidents.

That’s a human sport. It’s messy, nuanced, and requires cross-functional thinking. AI can help with suggestions and with a lot of aspects of it, sure. But the accountability, decision-making, and coordination? That’s us.

Turns out that still to this day one of the biggest problems are things like upgrading a live database with millions of transactions going through a minute while not degrading performance and not losing data. And despite all the tools (AI-enabled or otherwise), it typically requires planning and a strong team which can commandeer this process. Sure, AI can give you all the required steps but the answer to life universe and everything is 42 and so things rarely go as planned, and when they go wrong, the current AI systems are not designed to react and bring your data, your platform and your revenue back up! Again, in years to come solutions will emerge which can enable self-recovery and automatic incident management, and again the challenge would be to have these solutions map on all possible business configurations. And again, these AI system will be another tool in your team’s belt.

Security & Compliance

Security isn’t just about encrypting data. It’s threat modeling, understanding user behavior, applying the principle of least privilege, and staying ahead of evolving attack vectors.

Can AI write secure code? Sometimes. Can it reason about subtle vulnerabilities in your cloud infrastructure or compliance with SOC2 or HIPAA? Not without human oversight.

Will AI be able to do all this? Sure, and I’m seeing solutions crop up in this space and they are making progress, but we’re still scratching the surface. And in a ever-changing world, the same challenge applies of keeping up with the needs, so I see AI here as another tool to help an engineering team, not replace it.

AI as a Power Tool

So no, AI isn’t destroying software engineering. It’s giving us a new superpower. It lets us move faster in the low-level trenches so we can focus on the high-leverage work — architecture, system design, performance tuning, product intuition, and building things people actually need.

It’s like getting a calculator. It doesn’t make you bad at math — it frees you up to think deeper.

What This Means for Engineers

We should embrace this. The best engineers I know aren’t worried about being replaced. They weren’t worried about being replaced when ML became mainstream, or when everything started moving to the cloud, or when Linux became a thing and so on. They’re curious. They’re leveling up. They’re thinking about how to use these tools better than anyone else.

Want to future-proof your career?
• Double down on systems thinking.
• Get really good at understanding business context.
• Sharpen your skills in communication, mentoring, and architecture.
• Use AI to offload boilerplate so you can spend more time on what matters.

AI isn’t the end of software engineering. It’s the next evolution. And it needs thoughtful, curious engineers more than ever. Let’s stop talking about replacing entire teams with AI — if your whole product can be produced and managed entirely by an AI system then you probably don’t have a moat, or you don’t have a business. And for us, engineers, let’s stop worrying about being replaced — and start thinking about what we can build next.