GitHub published data showing that nearly half of all code committed to repositories using Copilot is AI-generated. That number has been climbing. For developers working in Cursor, Copilot, or similar tools on a daily basis, 60% feels conservative - on some days, on some types of work, the ratio is higher.

This trend has two common reactions. One is anxiety: if AI writes the code, what’s left for the developer? The other is dismissal: AI is just autocomplete, a fancy search engine, nothing has really changed. Both reactions miss what’s actually happening.

What AI Is Good At

AI tools are genuinely excellent at a specific category of work: translating a clear specification into code. If you can describe what you want precisely enough - the function signature, the behavior, the edge cases, the data structures involved - the model can usually produce working code faster than you would write it by hand.

This includes: boilerplate, scaffolding, standard CRUD operations, test cases for well-defined functions, converting between data formats, implementing algorithms that are well-documented in training data, writing code in languages or frameworks you use infrequently.

The common thread: the hard part has already been done before the model sees the prompt. The problem is understood. The solution is specifiable.

What AI Consistently Gets Wrong

AI tools fail in predictable ways, and understanding the failure modes matters more than the success rate.

Context outside the prompt: the model only knows what you tell it. It doesn’t know that the team has a pattern for this kind of problem, that a similar function was deprecated last week, that there’s a known bug in the library it just used, or that the database schema changed three days ago. Every missing context is a potential bug.

Correctness under ambiguity: when the specification is fuzzy, the model confidently produces something that is internally consistent but may not match what was intended. Fuzzy spec + confident output is a dangerous combination because the code looks fine until it doesn’t.

Non-obvious constraints: security requirements, performance characteristics, backward compatibility, operational concerns. These are often not in the prompt because they feel implicit. The model doesn’t infer implicit constraints - it does what the literal prompt says.

Novel problems: anything that doesn’t pattern-match to common problems in the training data. New library versions, internal APIs, unusual requirements, domain-specific edge cases - these are where AI suggestions become unreliable and where developers who accept suggestions without reading them accumulate debt.

What Shifts to the Developer

When AI handles the mechanical coding, what remains?

Specification: the quality of AI output is bounded by the quality of the specification it receives. Writing a good specification - precise enough that the model can produce the right code, complete enough that important constraints are captured - is now a core part of the work. This is harder than it sounds.

Review and judgment: generated code needs to be read and understood before it’s accepted. Not just “does this look right” but “does this handle the failure cases, does this make the right tradeoffs, will this be maintainable in six months, does this fit the existing patterns.” This requires genuine understanding, not surface approval.

Architecture: the high-level structure of a system - how components relate, where boundaries are, what the data model looks like, how failure propagates - cannot be delegated to a model. These decisions shape everything else. Their quality determines whether the code that gets generated even has a chance of being right.

Context maintenance: someone has to understand the full system well enough to notice when a generated solution conflicts with something elsewhere. Someone has to know what’s changed recently, what constraints are real vs aspirational, what the production behavior actually is. This is the work that keeps generated code from accumulating silent problems.

Verification: the testing mindset shifts. Less writing tests for things you just wrote; more specifying tests first so the generated code has something to be wrong against. More integration testing because unit tests of generated code don’t catch the contextual failures.

The Uncomfortable Part

The 60% number is a productivity lever if used well and a liability accumulator if used carelessly.

The developer who uses AI to move faster through the work they understand deeply is more effective. The developer who uses AI to avoid understanding the work is building a codebase full of code they can’t reason about, can’t debug, and can’t change safely.

This distinction won’t show up in short-term velocity metrics. It shows up in the quality of incidents, in how long features take to build as the codebase grows, in how quickly new team members can contribute, in whether the system degrades gracefully or brittles over time.

The question isn’t whether to use AI tools - the productivity gains are real enough that not using them is its own disadvantage. The question is whether you remain in command of what they produce. The developer role isn’t disappearing. It’s becoming more about judgment and less about mechanics. Whether that’s a downgrade or an upgrade depends on whether the developer wanted to be a mechanic in the first place.