In a previous article, we talked about how AI is changing software engineering rather than replacing it. The more practical question now is: where is AI actually working well in software engineering today, and where does it still fall short?
AI is strongest when the work is repetitive, well-defined, and pattern based. It does well with generating boilerplate code, setting up basic project structures, writing simple CRUD logic, and producing first-pass functions. It’s also useful for unit test generation, documentation, and straightforward refactoring where the intent is clear and the context is limited. For engineers, this mainly means faster delivery and less time spent on low-level, repetitive tasks.
That said, one interesting observation from clients and teams is that while AI has clearly sped things up, it has also increased the amount of output expected. In some cases, this has created more work rather than less. Faster delivery cycles often lead to more iterations, more requests, and more surface area to maintain. So while productivity per task has improved, the overall workload hasn’t always decreased in the way people expected.
AI also helps when working with unfamiliar code. It can summarise sections of a codebase, suggest likely functions or patterns, and reduce the time it takes to get up to speed on a new system. In that sense, it acts as a support tool that removes friction, even if it doesn’t fully understand the system in the way a human would.
But that usefulness depends heavily on how it is used. When engineers rely on AI to explore or interpret unfamiliar systems, the way they ask questions – and the mindset they bring to them – becomes critical.
Rónán O’Suilleabháin, Director of Engineering at Proofpoint, put it simply: “It’s important who’s prompting the AI. Do you have a DevOps mindset, a product mindset, a security mindset, a testing mindset? They all shape what you get back, or don’t get back.”
In other words, AI reflects the thinking behind it. The output is shaped by the experience and instincts of the person using it. In that sense, it doesn’t remove engineering disciplines – it exposes whether they’re there in the first place.
That reliance on how a problem is framed also highlights where AI starts to fall short. When the work becomes less well-defined, prompting alone isn’t enough.
Software engineering is rarely just about writing code; it’s about working through unclear requirements, shifting priorities, and real-world constraints. AI struggles here because it doesn’t carry context, responsibility, or awareness of business impact. It can suggest solutions, but it can’t reliably judge trade-offs or long-term consequences.
The gap becomes even clearer in system design. Decisions around scalability, reliability, security, and cost require an understanding of how systems behave in production, not just how patterns look in training data. The same applies to complex debugging, especially in distributed systems where issues are often subtle and unpredictable.
There is also a trust factor. In critical systems, it’s not enough for code to work in theory. Someone has to own it, understand it, and be accountable for what happens when it fails.
So the picture is mixed. AI is very effective at speeding up execution, but much weaker when it comes to judgment and ownership. It speeds up building, but it doesn’t decide what should be built.
