Trending Articles
Trending Topics
Trending
This article is part of our Opinions section, where we invite industry professionals to share their views on the most pressing technology questions of our time.
Last month, I finished a piece of work in 60 seconds that would normally take me six hours. I’m not going to pretend that wasn’t impressive; it was. What I’m not going to do is credit the AI agent with the full story, because those 60 seconds only happened after I’d spent considerably longer thinking about what I actually wanted.
Ask the same AI for the same task without that preparation, and you get something else entirely. The code it produces is unreadable, unmaintainable and untestable. It duplicates logic across files. It solves the wrong problem in the most complicated way possible. It fails not by making things up, but by being completely useless.
The gap between those two outcomes is not the model. It’s the instructions.
There’s a dominant narrative in enterprise AI that the problem is hallucinations. The model makes things up; you can’t trust it; it’s not ready for production. These are real issues, but they’re used as a convenient explanation for a much more common failure, which is that people give AI vague or poorly structured input and are surprised when they get vague or poorly structured output.
I’ve been watching this happen across organisations for the past year. A team will spend three months evaluating which AI tool to use. They’ll run benchmarks, compare pricing, and fight procurement battles. Then they’ll deploy it with minimal guidance, watch it produce something mediocre, and conclude that AI isn’t ready.
The tool was probably fine. The instructions were not.
When I work with an AI agent on code, I tell it, before anything else, that the output needs to be readable by a human, that it should solve the problem in the shortest way possible, and that it should never duplicate logic. These aren’t suggestions, they’re constraints. And they change everything about what comes back.
What AI does very well is optimise for whatever it’s been told to optimise for. Tell it nothing, and it optimises for what it’s seen most of in training, which tends towards verbose, patterned and generic. You get bulk instead of quality.
Once you’re specific, the dynamic shifts. The agent starts asking, in effect, what is the simplest version of this? That question alone produces better software than most teams get from junior developers working without oversight.
I want to be careful here, because the obvious reading of what I’ve just said is that individuals need to become better at prompting. That’s true, but it’s not the main point.
The main point is that this is a governance problem. The quality of AI output in any organisation is a function of how clearly that organisation has defined what good looks like. Not just in AI terms, but in operational terms. If your team doesn’t have clear standards for what maintainable code means, or what a useful customer response looks like, or how decisions should be documented, then giving them an AI tool doesn’t improve things. It accelerates the existing confusion.
What I’ve found working with software delivery teams is that the organisations getting the most out of AI agents are the ones that already had strong delivery standards before they introduced AI. They didn’t need AI to help them figure out what good was; they needed it to help them do good faster. That’s a very different starting point.
Enterprise buyers of AI tools are currently obsessed with model benchmarks. This one scores better on reasoning, that one is better at code, and the other has a longer context window. These comparisons matter at the margins, but they’re not the variable that explains the difference between AI working and AI not working in practice.
I’ve seen the same model produce outstanding work in one team and rubbish in another. Same tool, same task, very different results. The difference was always in how clearly the team could articulate what they needed. In one team, they could tell the AI exactly how output would be used, what constraints it operated under, and what failure looked like. In the other, they handed it a task description and hoped. One of these approaches works. The other produces something that looks fine in a demo and falls apart immediately in production.
I’m not dismissing hallucinations as a problem; they’re a genuine limitation, and anyone running AI in a regulated environment needs to account for them. But they’ve become a convenient excuse for avoiding the harder conversation, which is about what organisations actually need to change to use AI well.
The harder conversation is this: most organisations don’t have the operational clarity to give AI useful instructions. They don’t have it for their human workers either, which is why so many transformation efforts fail before anyone writes a line of code. Adding AI to that situation doesn’t fix it.
The teams I’ve seen get this right have one thing in common: they treated the introduction of AI as a reason to get clearer about what they were actually trying to do, not as a shortcut to avoid that conversation.
If your AI output is disappointing, the model is rarely the culprit. Start with the instructions.
