AI Coding Assistants in a Delivery Team: An Honest View
AI tools write a lot of code now. Whether that makes a team faster depends on review, tests and how clearly the work was defined in the first place.
Every few months a new tool is introduced as the thing that will replace software engineers. The demos are impressive: a ticket goes in, a pull request comes out. Clients reasonably ask whether this means software should now cost a fraction of what it did, and whether they need an engineering team at all.
We use AI assistants every day at Amygdal, so our answer comes from practice rather than from a press release. They have changed how we work. They have not removed the need for engineers who understand the system, and in some situations they make that understanding more important, not less.
Where assistants genuinely save time
- Boilerplate and scaffolding: endpoints, forms, data mappers, migrations and tests that follow an established pattern in the codebase.
- Reading unfamiliar code: summarising a module or explaining a library faster than searching documentation.
- Small, well-specified changes: renaming across files, adding a field end to end, updating call sites after an API change.
- Test drafting: proposing cases, including edge cases, that an engineer then reviews and trims.
- First drafts of scripts and one-off tools where the stakes are low and the output is easy to check.
In these areas, a competent engineer with a good assistant moves noticeably faster. The common thread is that the task is clear and the result is easy to verify.
The productivity gain is real but uneven. Experienced engineers working in a codebase they know benefit most, because they can judge output instantly. Engineers new to a codebase benefit less, because they cannot yet tell good suggestions from plausible ones.
Where they cost time instead
The picture changes when the work is ambiguous or the consequences are subtle. Assistants produce code that looks finished. If nobody fully understands it, the cost shows up later as bugs, inconsistent patterns and duplicated logic.
- Architecture and data modelling, where the right answer depends on context the model does not have.
- Concurrency, transactions and security, where plausible code can be dangerously wrong.
- Large autonomous changes that touch many files at once and are hard to review properly.
- Vague tickets. An agent given an unclear task will confidently build the wrong thing.
There is also a quieter cost. When an assistant writes a function that already exists elsewhere in the codebase, slightly differently, the codebase grows two ways of doing the same thing. Over months that inconsistency makes every later change slower. Good review catches it; rushed review lets it accumulate.
Autonomous agents: useful, with supervision
Agentic tools that plan, edit files, run tests and iterate are a real step forward. We use them for well-bounded tasks inside a branch, with a test suite that tells them when they are wrong. We do not hand them open-ended features and merge the result. The quality of what an agent produces tracks closely with the quality of the tests and specification it is given, which is an argument for investing in both.
Making the codebase agent-friendly
The same things that help a new engineer help an AI tool: clear module boundaries, consistent naming, typed interfaces, a fast test suite and a short document describing conventions. We now treat a concise contributor guide in each repository as part of the deliverable, because both humans and assistants read it. Teams that invest here find that generated code fits in with far less correction.
A fast feedback loop matters just as much. If tests take twenty minutes, an agent iterating against them is slow and expensive; if they take one minute, it can try, fail and fix several times while the engineer reviews something else.
Review is now the bottleneck
When code is cheap to write, reading it carefully becomes the scarce skill. Our working rules reflect that:
- The engineer who opens a pull request owns every line in it, whoever or whatever typed it.
- Pull requests stay small enough to review properly, even if an assistant could produce more.
- Generated code must follow the existing conventions of the codebase, not whatever the model prefers.
- Tests are required, and a human checks that they test meaningful behaviour rather than the implementation.
- Secrets, customer data and confidential code go only to tools approved for them.
We also keep a clear line on data. Client code and data are only used with tools whose terms the client has agreed to, and some clients require that no external AI tool sees their repository at all. In those cases we either work without assistants or use a model hosted inside the client's environment. That decision is made at the start of a project, not discovered halfway through.
What this means for buying software
AI assistance does reduce the time spent typing code, and good teams pass some of that saving on. But typing was never most of the cost of software. Understanding the problem, making good design decisions, integrating with real systems, testing and running the product in production still take experienced people. Be wary of proposals that promise a complete product in days because an AI will write it; ask who will review, test and maintain it. Our custom software development guide covers the questions worth asking any partner.
How we measure the effect
We judge AI tooling by delivery outcomes rather than lines of code: cycle time from ticket to production, defect rates after release, time spent in review and how often work is reopened. Lines of code produced is a misleading measure; an assistant can raise it while making the product worse. When a tool improves the outcomes, we keep it. When it only increases output, we look harder at how it is being used.
Skills that matter more now
The engineers who get the most from these tools are the ones who were already good: they write clear specifications, design clean boundaries, think in tests and read code critically. Junior engineers benefit too, but only with strong review, otherwise they learn to accept output they cannot explain.
Working with us
Our teams use AI tooling where it helps and keep experienced engineers accountable for every change. Learn more about our software development service, or get in touch to discuss a project.
