Two years ago these tools were described as "code completion". Today they do something else: take a task description, read the project, change files, run the tests and come back with a proposed change. Most software teams are either using them or arguing about whether they should.
This is not a tool list or a prediction about the future. It tries to answer a practical question for anyone who commissions software or manages a software team: how do these tools change the work, and what needs watching?
What actually gets faster
The gain is real, but it is not evenly distributed. Work that clearly speeds up:
- Repetitive code. Form validation, data models, API clients, test scaffolding. Tasks that took half a day now take minutes.
- The first step in unfamiliar territory. A library nobody has used, a module written in an old language, a complex configuration file. The tool shortens the "where do I even start" phase.
- Understanding existing code. In a large project, "where is this function called, where does this field change" takes minutes instead of hours.
- Mechanical transformations. Moving from one API version to the next, library upgrades, bulk renames.
Work that does not speed up, and sometimes slows down:
- Deciding what to build. What the customer wants, which business rule applies, whether the feature is needed at all. The tool does not know this; it guesses.
- Architecture decisions. How the data model is structured, how services are split. A wrong decision written quickly is more expensive, not less.
- Review. When the amount of generated code rises, the amount of code that must be read rises with it. A team that writes fast but does not make time to read finds the bug in production.
In short, typing got faster. Thinking and verifying did not. The team's bottleneck is no longer the keyboard; it is judgement and control.
Where it misleads
These tools do not fail randomly. They fail in recognisable patterns, and knowing the patterns catches most of them.
- It invents things. A function that does not exist, a wrong parameter, a package that was never published. The code compiles, appears to work, and breaks on an edge case.
- It builds something similar, not what was asked. Ask it to "cancel the payment" and it may delete the record. It looks right; the business rule is wrong.
- It does not think about security by default. Input validation, authorisation checks, secrets hard-coded into source. Unless explicitly requested, these are often skipped.
- It approves its own mistakes. Instead of fixing code that fails a test, it may change the test. The suite shows green and the problem stays put.
- It does not know your project's rules. Naming, layering and error-handling conventions the team has followed for years get broken unless they are spelled out.
None of these is a reason not to use the tools. All of them show why a process that checks the output is non-negotiable.
A practical adoption plan for a company
If you manage a software team or commission software from outside, these five steps lower the risk and keep the gain.
1. Draw the data boundary first. Which code and which data may be sent to an external model? Customer data, secrets and production database dumps should not be. When choosing a tool, ask for a written answer to "is our code used for training, and where is it stored?"
2. Do not relax the review rule; tighten it. Code written by AI is reviewed exactly like code written by a person. The difference is that "who wrote it" disappears and "who is responsible" remains. Whoever submits the change must be able to explain every line in it.
3. Keep tests independent of the tool. If the tool that writes the code also writes the test, the test is a mirror of the code and shares the same wrong assumption. Tests that verify business rules should be defined by a person. The tool can fill them in; it should not decide them.
4. Add a rules file to the project. Most tools read team conventions from a text file in the repository: what each layer does, how errors are handled, what must not be touched. When this file exists, the quality of generated code improves visibly. When it does not, the same mistakes keep coming back.
5. Measure. A feeling of "we got faster" is not enough. Track the time from idea to production, the number of bugs found in production, the share of changes that get reverted. If the tool improves those numbers, it is working. If it only increases lines written, you pay the cost later.
If you work with an external team
The questions companies should ask a software vendor have changed too:
- Does the team use these tools, and which data goes where?
- How is generated code reviewed?
- How are tests written, and which business rules are under test?
- Could your own team, or another vendor, take over the delivered code?
The last one matters most. Code that was produced quickly but that nobody fully understands becomes, a few years later, exactly the kind of legacy system that needs modernising.
Conclusion
AI tools did not make software development cheap; they made certain parts of it very cheap. The remaining part, deciding what to build and proving it was built correctly, is worth more than before.
To discuss how these tools and the processes around them fit your project, see our AI solutions page or go straight to the contact page.
