Contents
AI coding assistants noticeably speed up routine work — boilerplate, tests, migrations, understanding unfamiliar code and docs — but they do not automatically speed up everything: on complex tasks in a codebase you know well, the gain can be zero or even negative. Results depend on the task, the context and how carefully the team checks generated code.
Here is where assistants really help, where they get in the way and how to build them into your process without losing quality.
What does research say about productivity with AI?
Research paints a mixed picture: on some tasks developers with AI are faster, on others slower than they believe. A telling example is METR's 2025 randomised study: experienced developers working on large open-source projects they knew well took on average 19% longer with the AI tools of the time, while estimating they had sped up by about 20%.
Read the conclusions of the METR study carefully: they apply to specific conditions — experienced people in familiar code using early-2025 tools — and the tools have changed noticeably since. But the main lesson is universal: feeling faster is not the same as being faster, and the effect has to be measured, not assumed.
Where do AI assistants genuinely speed things up?
AI assistants speed things up where the task is routine, easy to describe in words and easy to verify: boilerplate, tests, data transformation, exploring an unfamiliar library. The easier it is to check the answer, the more value and the less risk.
| Task | Assistant value | What to watch |
|---|---|---|
| Boilerplate, CRUD, migrations | High | Match the project's conventions |
| Tests for existing code | High | Tests should check behaviour, not mirror the implementation |
| Understanding unfamiliar code and libraries | High | Cross-check the docs — models get versions wrong |
| Regular expressions, SQL, scripts | Medium to high | Test on real data |
| Refactoring a large module | Medium | Tests first, changes in small steps |
| Architectural decisions | Low to medium | The team decides; the model is a sparring partner |
| Complex logic in familiar code | Unpredictable | Checking time can exceed the savings |
Photo: Unsplash
What risks do AI assistants bring?
AI assistants bring risks tied to confident but wrong answers: the code looks plausible, compiles and even passes a superficial check, yet contains a logic error, a vulnerability or an outdated way of using a library. The less the developer understands the generated code, the higher the risk.
The main risks:
- logic and edge-case errors that are invisible without tests;
- vulnerabilities — for example, queries without permission checks or unsafe input handling;
- non-existent functions and outdated library APIs;
- data leaks — sending proprietary code or personal data to an external service without permission;
- style drift — code that ignores the project's conventions.
How do you build AI assistants into the team's process?
Treat assistants as a tool whose output the developer owns: generated code goes through the same review, tests and security checks as hand-written code. Write the usage rules down explicitly.
Rules we recommend:
- The author is responsible for every line, even if an assistant suggested it.
- AI-generated code goes through normal code review and automated CI checks.
- New logic gets tests written or verified by a person.
- Approved tools and code-processing terms are agreed with the client and legal.
- Secrets, keys and personal data are never sent to external services.
How to measure the effect
Do not rely on feelings. Compare team metrics before and after adoption: time from task start to deployment, the share of pull requests sent back from review, the number of post-release bugs. If time dropped but bugs rose, there is no gain.
Metrics before and after adoption (monthly)
time from task start to production — median, days
share of pull requests sent back — %
production bugs per 10 releases — count
review time per pull request — hours
Will AI assistants replace developers?
AI assistants change developers' work but do not replace responsibility for the result: understanding the business problem, choosing the architecture, checking quality and security. The value of framing tasks well, reading and verifying code, and knowing the domain goes up.
What this means for a business:
- some routine work becomes faster and cheaper;
- the bar rises for reviewers and tech leads — someone has to tell plausible code from correct code;
- quality processes — tests, review, monitoring — matter even more.
If you are building AI into the product itself rather than into development, the architectural questions are different — see how to integrate an LLM into your product.
In short
- AI assistants speed up routine work well: boilerplate, tests, exploring unfamiliar code.
- On complex tasks in familiar code the gain can be zero — research confirms it.
- The main risks are plausible errors, vulnerabilities, outdated APIs and data leaks.
- AI code goes through the same review, tests and checks; the author owns every line.
- Measure the effect with team metrics, not impressions.
FAQ
Can AI assistants be used on a client's project?
Only if agreed: the provider's code-processing terms, approved tools and a ban on sharing secrets and personal data. Good practice is to put this in the contract.
Who owns code written with AI assistance?
It depends on the jurisdiction and the tool's terms, and the question is still evolving. For commercial projects, discuss it with a lawyer and cover it in the vendor contract.
Do AI assistants lower development costs?
On routine tasks, yes; on complex ones the effect is unpredictable. Team metrics — time to deployment and post-release bugs — show the real savings, not the number of generated lines.
