There's a pitch behind every AI coding assistant: it makes you faster. Fewer keystrokes, less boilerplate, more shipped features per sprint.
The pitch is half true. What it leaves out is the gap between a tutorial demo and a real codebase under real pressure. In a demo, every suggestion is correct because the demo was built to make the suggestion look correct. In production, the assistant doesn't know your architecture, your team's conventions, or the ticket you're actually trying to close. It just knows what tends to come next in code that looks like yours.
That gap is where the noise lives.
Say a developer is mid-flow, wiring up a new endpoint. The assistant suggests a validation helper that looks reasonable, so they hit tab. It compiles, tests pass, they move on.
Three weeks later a teammate finds two nearly identical validation helpers in the codebase: one written by a human eight months ago, one autocompleted last sprint. Nobody meant to duplicate logic. The suggestion was locally correct and globally redundant, and nothing about "correct code that compiles" caught that.
(This is an illustrative scenario, not a specific incident, but most teams running Copilot or similar tools for more than a few months will recognize the shape of it.)
No single autocompleted line breaks your architecture. That's exactly the problem. An assistant trained on generic patterns will happily suggest a new abstraction, a new dependency, a new way of doing something you already do three other ways elsewhere in the codebase, because it has no visibility into "elsewhere." Accept enough of these one at a time and the codebase drifts into a dozen small dialects of the same idea, none of them wrong in isolation.
The real cost isn't the code that's obviously bad, that gets caught. It's the code that's plausible enough to pass a quick glance and wrong enough to need real review time later. If you accept every suggestion without evaluating it against the code you already have, you're not saving time, you're deferring the thinking to code review, or worse, to whoever debugs it in production. Teams that measure this honestly often find they're spending more time reviewing and pruning generated code than they would have spent writing the smaller, more deliberate version themselves.
Strip away the tooling and this isn't new. Junior engineers have always generated more code than senior engineers, because judgment about what not to write is a skill that takes time to build. AI assistants didn't invent that gap, they just made it faster to fall into, because the suggestion arrives before you've had time to ask whether you need it.
There's no universal right answer here, but there is a decision worth making deliberately instead of by default:
None of these are wrong. They're trade-offs between speed and friction, and the right one depends on how much you trust your own review discipline in the moment.
So: do you keep autocomplete on at all times, use AI only on-demand for specific tasks, or limit it to research and planning? And has your answer changed since you started using these tools?