What AI coding assistants actually change on an engineering team

Ask ten engineering leaders what AI coding assistants have done to their teams and you get two answers that cannot both be true. One group says everything is faster now and the tools have changed the job completely. The other says they tried it, saw a lot of confident nonsense, and mostly turned it off. Both are describing the same tools honestly. The gap is that the assistants are genuinely great at one kind of work and genuinely unhelpful at another, and whether you love them or not depends on which kind of work you were hoping to speed up. So it helps to be precise about what they change and what they leave unchanged.

Here is what we have seen across a lot of real projects, and how to adopt these tools without quietly lowering your quality bar.

What they actually speed up

Start with the benefits, because they are real. AI coding assistants are excellent at the mechanical parts of writing software. Boilerplate, the repetitive setup code that is the same in every project, comes out in seconds instead of minutes. A first draft of a function, where the shape of the answer is fairly standard, arrives fast enough that you edit instead of writing from scratch. And when you need to use a library or API you do not know, the assistant gives you a working starting point far quicker than reading the documentation with no prior knowledge.

The useful way to picture the tool is a very fast junior engineer who has read almost everything and understood almost none of it. It has seen millions of examples of how code usually looks, so it can produce something plausible for almost any request instantly. That is a real help for the parts of the job where "usually looks like this" is actually the right answer. Getting started when nothing is written yet, drafting the obvious version so you can react to it, moving quickly through the unfamiliar-API problem: these are genuine time savings, and any team that refuses to use them for this is giving up speed it could have.

What they do not touch

Now the part the marketing skips. The tasks the assistants speed up were, for a strong team, never the slowest step. The hard part of senior engineering was rarely typing. It was deciding what to build, choosing how to structure it, weighing the trade-offs between two designs, and knowing when a clever solution is actually the wrong one. None of that is what these tools do.

They cannot do it because of what they are. An assistant predicts likely code based on patterns it has seen. Judgment is not a pattern-prediction problem. Deciding what to build requires understanding the customer, the business, and the problem behind the request, and the assistant sees none of that. Choosing an architecture requires understanding the whole system at once and thinking about how it will change over the next two years, which is exactly the context the tool does not have. We wrote a whole piece on the hardest of these, knowing what to build, and nothing about AI assistants changes that argument. The thinking is still the job. The tool just types faster.

This is why the speed gain is smaller than it first looks. If typing was ten percent of the real work and thinking was ninety, making the ten percent instant is nice but not transformative. The engineers who feel let down by these tools are usually the ones who expected them to help with the ninety percent, and were quietly hoping the machine would do the part that was actually hard.

The subtle risk: plausible and wrong

Here is where it gets dangerous, and where teams run into real problems. The assistants are not just sometimes wrong. They are specifically good at producing code that looks right and is subtly wrong. It compiles, it reads cleanly, it uses the right function names, and it has a bug or a security weakness that you only find if you actually understand what it is doing.

That failure mode is worse than obvious errors, because obvious errors get caught and plausible ones get released. Catching a confident mistake takes an experienced engineer who understands the system well enough to notice that the clean-looking code is doing the wrong thing. This connects directly to security: generated code can reproduce common vulnerabilities without meaning to, so the categories of problem that groups like OWASP have documented for years do not go away just because a machine wrote the code. If anything they get easier to introduce, because the code arrives faster than a person can think about it.

So the real danger is in staffing. It is tempting to conclude that if AI writes the code, you can rely on more junior engineers and skip the expensive seniors. The truth is the opposite. When more code is generated quickly, more plausible-but-wrong code needs catching, and the only people who can catch it are the experienced engineers you were hoping to need less of. A team of juniors plus AI, without strong senior review, does not save money. It releases confident mistakes faster.

How to adopt them without lowering the standard

The good news is that the right way to use these tools is not complicated. Treat the assistant as a fast way for experienced engineers to produce first drafts, and do not lower the standard for what counts as good.

In practice that means a few things. Use the assistant for drafts, boilerplate, and unfamiliar APIs, where its strengths are real. Treat every suggestion as a draft from a fast but unreliable source, and check it the way you would check work from a new hire on their first week: assume it might be subtly wrong until you have understood it. Keep your code review standards exactly where they were, or raise them, because review is now the main place quality is protected. When writing gets faster and review does not, you have simply built a system that releases problems more quickly.

Above all, make sure a person who understands the system approves what gets released. The standard for what is good does not change; only the speed of reaching a first draft does. A strong engineer using the tool well produces good work a little faster. A weak process using the tool badly produces bad work a lot faster. The tool decides neither. Your standards do.

What it means for measuring your team

One last shift, because these tools quietly break a metric that was already broken. If the assistant makes it easy to produce more code, then counting code, lines written, volume released, becomes even more misleading than it used to be as a measure of value. A person can now generate a large amount of plausible code in an afternoon, and none of it is worth anything until judgment has shaped and checked it.

So the arrival of these tools is one more reason to measure engineers by outcomes rather than output, which we argued in measure engineers by outcomes, not output. What matters is still whether the right thing got built and works, and that is a judgment the assistant cannot make for you. Seen that way, these tools do not lower the value of good engineers. They raise it. They remove the excuse that the easy, mechanical part took all the time, and they leave the hard part, deciding what is right and making sure it is, unchanged, and now more clearly the whole job.

We have taken this further than most teams, so it is worth reporting what happens when a team goes all the way. When one hundred percent of the code is generated, the changes described above stop being adjustments and become the job. Reviewing is no longer a task an engineer does after building, it is most of what building means. Specification stops being documentation and becomes the primary engineering artifact. Teams experimenting with copilots tend to feel these shifts as problems that slow them down. They are how the work is done now, and these teams are seeing it early.

Sources

• OWASP, application security resources: https://owasp.org/