Can AI Replace Consultant Programmers?

The tech world is buzzing with excitement about Large Language Models (LLMs) and Generative AI. Companies and businesses, hungry for solutions, are turning to these technologies as their first port of call. With AI now capable of generating “vibe-coded” flight simulators, a seismic question has hit the industry: is there still a need for consultancies, for software engineers themselves? It’s a question that deserves to be asked, but let’s not forget the golden rule: if something sounds too good to be true, alarm bells should be ringing. Because right now, we are nowhere near the point of waving goodbye to human coders. In fact, even a basic “promise vs. reality” comparison falls flat on its face, since most LLMs don’t even promise working software, opting instead for disclaimers about the inevitability of errors. The hype around Generative AI is real, and the potential is undeniable, but in 2025, the idea that we can simply hand over the reins of software development to LLMs is still a distant dream. Let’s dive into why.

AI is making impressive – sometimes breathtaking – strides in specific coding tasks. It’s proving to be a valuable ally for simple, contained work: generating code snippets, refactoring existing code, scaffolding applications, and even debugging. AI can also whip up rapid prototypes to showcase concepts, and it can do it fast, but only so long as the functionality remains strictly limited.

There seems to be a complexity threshold: AI can be surprisingly helpful with isolated tasks. For example, I’ve used it to quickly generate a function to sort a list or even set up the basic structure of an API endpoint, which saved a good chunk of time. However, when I attempted to use the same AI to implement the core business logic of that API – the complex rules for data validation and interaction with other systems – it produced a tangled mess of incorrect code that was ultimately less efficient than writing it from scratch. This highlights a crucial point: AI’s usefulness diminishes rapidly as the complexity of the task increases. Even these seemingly successful applications come with significant caveats that we need to acknowledge.

The seductive power of AI coding tools can easily blind us to the very real challenges that emerge when we try to rely on them for serious software development. Here are some of the key limitations that underscore the irreplaceable value of human engineers:

AI can churn out code snippets and basic scripts, no problem. But crafting fully functional, production-ready applications? That’s a whole different ball game. To illustrate, consider a recent project where I needed to implement a user authentication system. AI was able to generate the basic code for handling logins and passwords. However, it failed spectacularly when it came to integrating that system with the existing database, handling complex session management, and implementing secure password recovery workflows. In my own experience, AI tools consistently hit a wall when trying to move beyond the simple stuff, failing to deliver code that can handle the complex demands of real-world software.

AI can sometimes generate code that actually works. But here’s the kicker: that code can be a complete black box. As engineers, we didn’t write it, which means we’re unfamiliar with it, and AI-generated code can be notoriously difficult to decipher. This presents a massive deterrent. It’s tempting to blindly accept AI-generated code, especially when it seems to work at first glance. However, this carries a significant risk: do we risk simply accepting blindly any suggestion? Do we even stop asking what’s acceptable or not? It requires strong ethics and diligence to remain vigilant and not derail into “vibe coding” by default. Would any engineer in their right mind pause their own productive work to wade through and try to really understand AI-generated code with the same intimacy as code they wrote themselves? Mostly, the answer is a resounding no.

I found that AI simply isn’t very good at adapting to changing requirements or circumstances. So, what happens when the project changes direction? Engineers can usually refactor and optimise their own code to accommodate evolving requirements. With AI, you’re often better off hitting the reset button and starting from scratch, because large-scale refactoring is a recipe for disaster, almost guaranteed to introduce a swarm of bugs.

AI models have a nasty habit of getting stuck in a loop. They reach a coding “conclusion,” implement it, and if you tell them it’s wrong, they’ll often give you the exact same wrong answer again. They’re more likely to offer a polite apology for their incompetence than to actually try and find a different solution. And then you’re stuck, deep in unfamiliar, broken code, completely on your own.

In every project I’ve been involved in, there are critical moments where you have to question everything – approaches, development patterns, even the technology itself. These are decisions that demand deep domain knowledge, contextual awareness, and a thorough understanding of the team’s skillset. It’s completely unrealistic, with the current state of the art, to expect any AI to handle these kinds of nuanced, high-stakes judgments that so heavily influence the code written by engineers.

AI is weakest in the one area that should be front-of-mind for every business: code maintenance. Even if, someday, you could use AI models to produce all your code and fire all your engineers, you’d still need those engineers to maintain that code. But now you’ve made their job exponentially harder, forcing them to grapple with code they don’t understand. Honestly, for a programmer, the thought of inheriting a “brownfield” project written entirely by machines is the stuff of nightmares. As the saying goes, “Today’s AI-generated code is going to create enough technical debt to give future engineers refactoring work for the next decade.” And any business that’s paying those programmers should be equally terrified.

It’s still somewhat miraculous that AI can write any working code at all. But expecting it to produce optimised code – optimised not just for performance but also for the specific needs of your business – that’s a bridge too far. I wouldn’t dream of putting AI-generated code into an API endpoint that handles millions of requests per second, where even a tiny drop in optimisation compared to human-written code could translate into a monstrous bill at the end of the month. Think Serverless billing model, where cost is a function of execution time and memory, multiplied by millions of executions.

Generative AI is undoubtedly one of the most groundbreaking technologies of the last decade. Yet, paradoxically, it struggles to keep pace with innovation, particularly in the realm of code generation. By design, large language models (LLMs) are trained on vast corpora of existing data and established industry practices. As a result, whenever a new language, framework, or even a simple library emerges, these models are effectively blind to it—sometimes for months, even years. This lag exists because new material must be incorporated into the model through retraining, fine-tuning, or retrieval-augmented techniques. But here’s the crux of the issue: if a developer isn’t even aware of a new tool or approach, they won’t know to extend the AI’s knowledge context to include it. The developer remains unaware, and the model remains unaware—creating a feedback loop of blind spots. And as we edge toward a future where many may stop actively searching for information and rely entirely on AI to provide answers, a worrying scenario unfolds: could today’s LLMs entrench the status quo, leaving innovative solutions buried in obscurity?

This isn’t hypothetical—it’s already happening. We frequently see LLMs generating code based on outdated, even deprecated, libraries and frameworks. In some cases, they suggest insecure practices due to the overwhelming presence of legacy examples in the training data. This behaviour is understandable from a model’s perspective—it reflects what has historically been most common. But it raises a critical question: should we accept this as the default? Should we stop striving for better, more innovative, more secure solutions? As things stand, LLMs don’t naturally promote forward-thinking approaches. The real question is: will we step up to close this gap ourselves—or will we quietly settle for a suboptimal standard?

Despite these very real limitations, AI is proving to be a valuable co-pilot, particularly for those smaller, more contained tasks. In my personal experience, AI is helping me greatly with single file refactoring, repetitive tasks, intelligent completions, and to an extent debugging, and in that respect it’s saving me a lot of time that I can now dedicate to progressing harder, more involved tasks.. It’s currently in a sweet spot, helping programmers complete their lines of code more intelligently, refactoring code to accommodate changes in an instant. But it’s not ready for anything bigger, and given the challenges outlined above, you really shouldn’t want it to be. We’ll give it more responsibility when – and if – it earns it.

The question of whether AI can replace engineers is a valid one, and it’s generating a lot of heat. But my take is that we’re a long way from that reality: I wish AI worked the way some people wished it did (or indeed, they believe it currently does!), then I could wholly dedicate myself to higher level tasks such as application/infrastructure/code architecture design. AI is a powerful tool, but it’s not yet capable of replicating the nuanced skills, the critical thinking, and the sheer ingenuity of human programmers. As Bill Gates recently pointed out, coding is one of the professions safe from AI, at least for now. AI is best seen as a co-pilot, augmenting the capabilities of engineers, freeing them from the more tedious tasks, and allowing them to focus on the high-impact, complex work that truly drives innovation.