We sell development work. So the honest way to write this article is not to tell you what we think, but to point at what the companies selling the tools say in their own documentation, and let you weigh it.
They are more candid than their marketing. None of the major vendors claims to replace a developer. All of them describe assistants that require human review. And one of them has published data suggesting that human review is a weaker control than almost everybody assumes, which is a genuinely uncomfortable thing for a tool vendor to disclose.
Two sibling articles cover the questions this one deliberately leaves alone: what fast-built software costs you six months later, and whether your agency should be using these tools on your product.
What the vendors concede in their own documentation
Read the official documentation for the major coding assistants and the same three admissions recur.
Output requires human review before it is trusted. This is not a footnote in any of them, it is stated plainly and repeatedly [1][2][3].
The tools can generate incorrect code, including references to things that do not exist. Generated code can call libraries, functions or packages that are not real [1][2]. That is a specific failure mode rather than vague unreliability, and it matters because the output looks correct until it runs.
Certain domains warrant additional caution. Vendor guidance typically names areas such as finance, healthcare and legal [1][2].
That convergence is the point. These are companies competing hard, with every commercial incentive to say something more flattering, and their documentation says the same thing.
The disclosure worth reading twice
The most useful finding in our research came from Anthropic's own engineering writing, and it undercuts the reassurance everybody reaches for.
They report that users approved roughly ninety-three per cent of permission prompts, and that reviewer diligence declines as approvals accumulate [4]. In a red-team exercise, a phished employee approved a malicious action twenty-four times out of twenty-five [4].
Sit with that for a moment. The standard answer to concerns about AI-generated code is that a human reviews it. This is a vendor publishing evidence that humans reviewing a stream of suggestions approve nearly all of them, and get less careful the more they see. That is not an argument against the tools. It is an argument against treating review as a checkbox that makes the risk go away.
Our own conclusion from it, offered as reasoning rather than as anyone's finding: a person who could not have written the code is not really reviewing it. They are approving it. Those look identical in a workflow and are entirely different in what they catch.
Where these tools genuinely earn their keep
These tools are genuinely good at work where the answer is already known and the typing is the cost.
They are very good where the answer is already known and the typing is the cost. Generating boilerplate. Writing tests for code that already exists. Explaining an unfamiliar codebase to somebody who has just inherited it. Migrating between framework versions. Producing a first draft of a small, self-contained feature.
Every item on that list has the same shape: the hard thinking is done, and what remains is execution somebody competent could verify quickly.
Two of those deserve singling out because businesses underrate them. Explaining an unfamiliar codebase is genuinely transformative for anyone who has inherited a system, and it is the closest thing to a free lunch on this list, because being wrong is cheap and being right saves days. Writing tests for code that already exists is work almost nobody does voluntarily, and having it become nearly free changes the economics of maintaining an older system. That is a real productivity gain, it compounds, and anybody dismissing it is not paying attention.
Where they do not, and it is not really about code
The expensive parts of software were never the typing.
What to build. What data model survives your business changing its mind in eighteen months. Which trade-offs matter and which are cosmetic. What the regulatory constraints are. What to leave out, which is the hardest one and the most valuable.
None of those are typing problems, and none of them get easier because code appears faster. If anything, cheap code makes the deciding matter more, because it becomes easier to build the wrong thing quickly.
There is also the specific difficulty of confidently wrong output. Obviously broken code announces itself. Code that runs, looks reasonable, and is subtly incorrect is much harder to catch, and it is exactly the category where a reviewer skimming their ninetieth suggestion of the day will wave it through.
What has genuinely changed for a UAE SME
Small jobs that were never worth commissioning are now realistic, and that is a bigger change than it sounds.
Small jobs that were never worth commissioning are now realistic. An internal tool saving your operations team two hours a week could not previously justify an agency engagement, because the cost of scoping and building it exceeded the value. A script to reconcile two exports. A simple internal dashboard. A prototype to test whether an idea is worth funding.
That category has moved, and it has moved a long way. If your instinct is that a small internal problem is not worth a supplier conversation, you are probably right, and you are more right than you were two years ago.
A pattern we see. A business owner builds a rough internal tool themselves over a weekend. It half works. They bring it to a scoping conversation, and it turns out to be a far better brief than any document would have been, because building it forced them to make twenty decisions they had never articulated. The tool gets thrown away. The specification it produced is worth more than the tool ever was.
That is, genuinely, one of the highest-return uses of these tools for a non-technical owner: not to build the thing, but to find out what the thing is. A prototype nobody ships is still the cheapest specification you will ever write, and it costs a weekend instead of a discovery phase.
What these tools do not change about a project
Worth stating, because the question people ask is usually narrower than the decision they are making.
They do not decide what to build. The most expensive failure in software is building the wrong thing competently, and nothing about faster code production reduces that risk. If anything it raises it, because the cost of starting down a wrong path has fallen and the cost of finishing one has not.
They do not make your requirements clearer. A vague brief produces a confident implementation of a vague brief. That has always been true of outsourced development and it is now true faster.
They do not create institutional memory. In six months, somebody needs to know why a decision was made. A tool does not remember your conversation, your constraints, or the customer complaint that prompted a change. That knowledge lives in people and documents or it does not exist.
They do not carry risk. If a system handles payments wrongly, the exposure sits with your business. No subscription changes that, and no supplier can transfer it back to a tool.
None of this argues against using them. It argues for being precise about which problem you are solving. If your constraint is that you cannot get code written, these help enormously. If your constraint is that nobody has decided what the product should do, they will help you produce the wrong thing sooner.
What still needs somebody accountable
The line is not about difficulty. It is about what happens when it is wrong.
Anything touching payments, personal data, authentication, or a system your business depends on daily sits on the far side of it. Not because the tools cannot produce that code, but because the failure is not recoverable the way a broken internal script is. A wrong number in an internal dashboard costs you an afternoon. A wrong permission check costs you customers, and possibly a regulator's attention.
Vendor guidance flags regulated domains for extra caution [1][2], and in the UAE that maps onto sectors with their own regulators and their own expectations. If you operate in one, the binding constraint is not tooling. It is that somebody has to be accountable for a decision that may be examined later.
The honest test is a single question. When this breaks at an inconvenient hour and nobody knows why, what happens? If the answer is that you lose a day, proceed. If the answer is that customers cannot pay you, you are buying accountability rather than code, and that is not something a subscription provides.
What you can verify without being technical
Three checks require no technical knowledge and catch most of what goes wrong: does it work tomorrow on another machine, does it handle wrong input, and can somebody else run it from written instructions.
Does it work tomorrow, on a different machine? A surprising amount of software works exactly once, on the computer it was built on, because something in the environment is doing quiet work nobody noticed. Running it somewhere clean is the single cheapest test available.
Does it handle the obviously wrong input? Put an empty value where a number belongs. Submit the same thing twice. Enter a name with an apostrophe in it. Software that only works when used correctly is not finished, and this is exactly the category that generated code tends to skip because nobody asked for it.
Can somebody else run it from written instructions? If the answer is no, you have built a dependency on yourself. That is fine for a weekend experiment and a problem the moment your team starts relying on it.
None of that tells you whether the code is well written. It tells you whether the thing is trustworthy, which for an internal tool is the question that actually matters.
The check that decides whether you got away with it
The interesting moment is not when you build something. It is a few months later, when you ask whether the business has started relying on it more than you intended. That is how an experiment becomes a production system without anyone deciding.
What to do at that point, and what it costs if you leave it, is the subject of our guide to what fast-built software costs later.
Two things that are not what they look like
No-code is a different category. No-code and low-code platforms assemble applications from pre-built components through an interface. AI coding tools generate code from natural language. The strengths, limits and failure modes differ, and conflating them leads to bad decisions. For a lot of internal tooling, no-code is the better answer, and our build versus buy guide covers that route.
Free tiers are a dependency. Google discontinued the free individual tier of its coding assistant in June 2026 and migrated users to a different product [3]. That is unremarkable commercially and worth noting operationally: if a free tool becomes load-bearing in your process, you have taken on a dependency whose terms you do not control.
On cost, where we will not give you a number
You will find claims that AI tooling has cut development costs by some specific percentage. We are not going to repeat any of them, because every version we traced came from a vendor or a self-selected survey.
What we will say is where cost moves when it moves: onto the typing, not onto the deciding. And the deciding was always the expensive half.
Our own figures have not changed. A focused first version of custom software starts from around AED 15,000 with us, and a fuller system with several roles and integrations from around AED 60,000. These are our own figures rather than a market survey. We would be sceptical of any supplier claiming a dramatic reduction without explaining precisely which part of the work disappeared, because that is an answerable question and a vague answer is informative.
What this means for hiring, if you were about to
These tools change the hiring calculation less than people expect, and in a direction that surprises them.
The tools change that calculation less than people expect, and in a direction that surprises them.
A single developer with good tooling is faster than a single developer without it. They are still one person, with one set of strengths, who takes leave, gets ill, and will not be equally good at design, backend, mobile, infrastructure and security. Tooling raises what one person can produce. It does not make one person into several, and it does not solve the review problem, because a person reviewing their own AI-assisted output is reviewing their own work.
What has genuinely changed is the bottom of the market. Work too small to justify hiring anyone, and too small to interest a supplier, is now within reach of the person who has the problem. That is a real expansion and it sits below the hiring question rather than replacing it.
If you are weighing a first technical hire against a supplier relationship, that decision turns on continuity, breadth and accountability rather than on typing speed, and it deserves its own analysis rather than a paragraph here.
How to decide, for your actual situation
Three questions, in order:
- Does anybody outside your business see it?
- Does it touch money or personal data?
- What happens if it is quietly wrong for a month?
No, no, and not much: try it yourself. You will either solve it or arrive at a supplier with a far better brief.
A fourth question is worth adding once you have answered those three, and it is about time rather than risk. Who maintains this in a year? Something you build yourself has an owner by default, which is you, and that ownership appears on nobody's job description. If the honest answer is that nobody will maintain it, that is not a reason to avoid building it. It is a reason to keep it small enough that throwing it away costs nothing.
Any other combination: the decision is about accountability rather than capability, and accountability is the thing you are actually buying when you commission software.
If you are somewhere in the middle and would rather talk it through than guess, contact us. Quite often the answer is that you should try it yourself first, and we would rather say that than scope a project you did not need.
References
[1] Anthropic, Claude Code documentation. docs.claude.com
[2] GitHub, Copilot documentation and responsible use guidance. docs.github.com
[3] Google, Gemini Code Assist deprecation notice, 18 June 2026. developers.google.com
[4] Anthropic, engineering post on containing Claude and agent permission approvals, 2026. anthropic.com
