AI Coding Assistants After the First Year: What Sticks and What Gets Turned Off

The first few weeks with GitHub Copilot feel like a superpower. It finishes your lines, sometimes entire functions, with eerie accuracy. You type a comment describing what you want and the code appears below it. You start to think the skeptics were wrong. Then, maybe two or three months in, you start noticing things. The autocomplete suggests plausible-looking code for the wrong library version. You accept a suggestion without reading it carefully, and you spend an hour debugging a subtle mistake you wouldn’t have made yourself. You realize you’ve been copy-editing an AI instead of writing code, and you’re not sure that’s faster.

That experience — the arc from honeymoon to adjusted expectations — is nearly universal among developers who’ve been using AI coding tools seriously for more than a few months. The tools that survive the adjustment period in daily workflows are genuinely useful. But which features of which tools earn that survival is surprisingly specific, and the conventional wisdom about what AI coding assistants do well is overdue for revision.

What Actually Gets Used Six Months In

Line-completion and single-function autocomplete are still the stickiest feature of AI coding tools. The acceptance rate data that GitHub and Sourcegraph have published — somewhere between 25% and 40% of suggestions accepted in active codebases — overstates utility because it includes trivial completions (completing obvious syntax, finishing repetitive boilerplate). But even discounting those, AI autocomplete for repetitive patterns within a codebase genuinely reduces keystrokes and maintains flow state in ways that developers report as valuable. You don’t have to remember exact API parameter order. You don’t have to look up the method name you know exists but can’t immediately recall. That friction reduction is real.

Writing tests is probably the clearest productivity win with AI coding tools in mature teams. Given a function, generating a test scaffold — complete with setup, teardown, happy path, and a few edge cases — is something the current models do reliably well. The tests still need review: AI-generated tests often miss the genuinely tricky cases, over-test trivial behavior, or test implementation details rather than contracts. But they get you to a starting point faster, and for developers who delay writing tests because the initial investment feels high, that starting point has real value.

Explaining code is underrated. Most AI coding tools let you select a block of code and ask “what does this do?” — and for unfamiliar codebases, legacy code without documentation, or code in a language you’re less fluent in, the explanations are generally good enough to be useful. The models sometimes hallucinate behavior that isn’t actually in the code, which requires keeping a skeptical eye, but as a first-pass orientation tool for code archaeology, it works.

What Gets Turned Off

Multi-file context-aware suggestions — where the AI is supposed to understand your whole codebase and generate code consistent with your architecture — disappoint almost everyone who tries them seriously. The tools are better at this than they were two years ago, but “better than nothing” is not the same as “useful for production work.” Generated code that looks plausible in isolation frequently violates conventions, misuses internal abstractions, or duplicates logic that already exists elsewhere in the codebase. Catching those problems takes more review effort than writing the code yourself, for developers who know the codebase well.

AI “chat” features embedded in IDEs — “ask your codebase a question” — are useful for searching and navigating but fall apart for complex reasoning. “Why does this function return null sometimes?” sounds like exactly the kind of question an AI should be able to answer, but the actual answer usually requires understanding call chains, mutable state, and runtime conditions that the static context window doesn’t capture. The AI’s response is often confident and wrong, which is worse than unhelpful.

Automatic PR review suggestions, code refactoring proposals, and “generate a whole feature from a description” are the features most likely to be turned off in team settings. Not because they’re never useful, but because the failure rate is high enough that the overhead of reviewing and correcting them exceeds the value of the starting point they provide. Teams that kept these features on tend to be ones where the AI output is used as a first draft in domains with clear patterns (CRUD APIs, migration scripts, standard tooling configs) rather than anywhere near business logic or complex state management.

The Trust Calibration Problem

The central challenge with AI coding tools after the first year isn’t the quality of individual suggestions — it’s the inconsistency. A tool that was right 90% of the time in a predictable pattern would be straightforward to use: you build calibrated trust, apply appropriate review effort, and integrate it into your workflow. The actual experience is more like a tool that’s right 70% of the time in unpredictable ways. The 30% of wrong suggestions don’t look wrong. They look like the other 70%.

That inconsistency has a measurable cost: it keeps you in review mode even for suggestions that turn out to be fine. You can’t relax your attention the way you can with a deterministic autocomplete (where wrong means obviously wrong). The cognitive overhead of maintaining skeptical attention adds back some of what the tool saves in typing time — not all of it, but a meaningful fraction.

This is why developers who report the highest satisfaction with AI coding tools tend to be the ones who have learned to apply them selectively rather than universally. They use AI autocomplete for the parts of their work where wrong suggestions are obviously wrong and easy to reject: boilerplate, repetitive patterns, test scaffolding. They turn it off or ignore it for the parts where wrong suggestions look right: business logic, data transformations, security-sensitive code.

Differences Between Tools in Practice

Copilot, Cursor, Codeium, Tabnine, and the various other AI coding assistants have all improved substantially, and the differences that mattered most 18 months ago — raw suggestion quality on common languages — have mostly narrowed. The differentiators now are integration quality and workflow design.

Cursor’s approach of building the IDE around AI rather than adding AI to an existing IDE gives it workflow advantages for developers who work in agentic AI-assisted development sessions (where you’re iterating on a task across many files with the AI’s help throughout). The context window management is better integrated, and the chat/edit workflow feels more natural for that use case. For traditional line-completion autocomplete, the quality difference with Copilot is smaller.

Copilot’s advantage is breadth: it works in nearly every editor, integrates into GitHub’s PR workflow, and has the training data breadth that comes from being trained on the largest corpus of public code. For large diverse codebases in uncommon languages or frameworks, Copilot’s broad training often shows.

Codeium and Tabnine are worth considering for teams with privacy requirements — both offer on-premises deployment options where your code never leaves your infrastructure, which matters in regulated industries or when working with proprietary codebases where sending code to a third-party API is a compliance issue.

The Genuine Long-Term Change

The thing that AI coding tools have durably changed, for developers who’ve used them long enough, isn’t exactly productivity in the traditional sense. It’s the shape of the work. Writing the first version of something — the initial function, the scaffold for a new module, the test file for a new class — has gotten faster and less friction-heavy. The exploratory, generative part of coding has accelerated.

What hasn’t accelerated is the hard part: understanding what the code should do, verifying that it does it correctly, debugging the cases where it doesn’t, and making architectural decisions about how pieces fit together. Those tasks haven’t become easier or faster in any way that most developers have noticed. The AI is a better typist, not a better engineer, and calibrating your expectations to that reality is what separates developers who get lasting value from these tools from those who cycle through enthusiastic adoption and eventual disillusionment.

Turned off: automatic whole-file rewrites, magical “explain my bug” chat, any autocomplete on security-sensitive paths. Kept on: test scaffolding, line completion in familiar patterns, doc generation, code explanation for unfamiliar territory. That’s roughly where most experienced users seem to land after the adjustment period — and it’s a more modest but honest picture of where the technology actually is right now.