Tools like Claude Code and GitHub Copilot change how long it takes to produce code. They do not change who has to understand it two years from now.
I use these tools daily, and they are useful. But they have moved the bottleneck in development work, not removed it. The writer has become fast; the reader — the one who has to judge whether the code is correct and maintainable — is still a human being with experience. This is the trade-off that matters for a company weighing up what AI means for its development budget.
What the tools are genuinely good at
They are strong on work that is well defined and tedious: writing tests for code that already exists, converting one data format to another, drafting a first version of an integration against a well-documented API, tidying up naming across many files, writing migration scripts. All of these are tasks where the right answer can be recognised once you see it.
They are also good at getting started. An empty project with build setup, project structure and a couple of examples is often done in minutes rather than half a day. For a small supplier that is real value: more of the time goes to what the client is actually paying for.
Where they are weakest
The weakness lies in everything that requires context the tool does not have. Why the system was built the way it was. Which of two equally good solutions fits the operating environment the client actually has. Which assumptions in the specification are wrong. Which parts of the codebase look ugly because somebody made a deliberate decision four years ago.
Another weakness is subtler: the output always looks finished. Code that is almost right reads as code that is right, because it is well formatted and has sensible names. Mistakes that used to announce themselves through messy code now arrive neatly wrapped.
Maintainable is not the same as working
An application in production is not finished, it is a responsibility. It will be extended, fixed, upgraded when the framework gets a new major version, and eventually handed over to somebody else. The lifetime cost sits in those things, not in the first delivery.
What matters then is less where the code came from and more whether it has the properties that make change safe: a structure somebody can explain, names that describe what things are in the client’s domain, tests that actually fail when behaviour changes, and no duplication of the same logic in four places. Generate quickly without demanding those properties and you get a system that works now and is expensive to touch later.
The classic example is duplication. If the same validation gets generated into five endpoints because it was quick each time, the system is fully functional. Then the rule changes, and somebody has to find all five.
Competence is what makes the gain last
This is the core of it. The tools give the most value to someone who already knows the craft, because the gain depends on the ability to judge the answer. That requires reading code quickly, knowing the patterns of the language and framework, and understanding how the particular system fits together.
Concretely, there are questions I put to everything I have generated, and they are the same ones I would ask in an ordinary code review. What happens here on an error or an empty response? Is this a query that scales when the table holds millions of rows? Does this logic belong here, or was it put where it was easiest? Does this already exist somewhere else in the codebase? Has a dependency been added that we do not need?
Without that competence, the result is a codebase nobody in the organisation really knows. It can be tidy and perfectly functional and still be a problem, because every change has to be made by someone who must read their way in from scratch each time. It is the same situation as when an external developer disappears without documentation — except that nobody notices until the first change is needed.
Architecture and decisions cannot be delegated
There is a class of decisions that must be made by someone who carries the consequence: how data is modelled, where the boundaries between services fall, which parts have to be easy to change often, what gets logged and for how long. Such choices become hard to reverse quickly, and they depend on knowledge of the client and the operating environment.
The tools can certainly be used to explore the alternatives — they are useful as a sounding board in a design phase. But choosing between the alternatives is engineering work, and responsibility for it cannot be placed with a tool.
Practical rules I hold to
Small, bounded tasks at a time, with clear context, rather than "build this feature". Everything is read before it is committed, and I never commit anything I could not explain in a meeting. Tests are written or reviewed with the same scepticism as the code, or you end up with tests that confirm the wrong behaviour. New dependencies are treated as a deliberate choice, never as something that slips in because a draft happened to use them.
And on secrets: never keys, passwords or patient data in a request. In regulated environments it is also a question of what has been cleared with the client at all — some clients have requirements that mean an external service cannot see the source code. That gets settled beforehand, not afterwards.
What this should mean for a procurement
Whether a supplier uses AI tools is in itself neither a mark of quality nor a warning sign. The questions that matter are the same as before: can they explain how the solution is built and why, are there tests that describe the behaviour, can a new developer be brought in without rewriting everything, and what does it cost to change something a year from now.
It is also reasonable to ask specifically how the tools are used — whether generated code is reviewed, and whether source code or data is sent to external services. A clear answer to that says more about a supplier’s maturity than which tools they happen to run.
For my own part: I use AI where it saves time on work that can be verified, and keep architecture, data model and review with me. The client should be left with a system that can be maintained by someone other than whoever wrote it — that is the only goal that matters over time.