Cursor Has 500,000 Developers. Most of Them Are Shipping Code They Cannot Debug.

Cursor crossed five hundred thousand paying developers earlier this year.

GitHub Copilot has millions more. Windsurf, Cline, Aider. The AI coding tool category is not an experiment anymore. It is the primary development environment for a significant fraction of the industry.

The tools are genuinely good. The velocity gains are real and measurable. Every team that has adopted them seriously ships more features per sprint than they did before.

Eighteen months into mass adoption, the second-order effects are becoming visible.

They are not what anyone advertised.

The pull request that nobody understood

Here is a pattern that engineering leads are describing with increasing frequency.

A developer submits a pull request. The code is clean. The variable names are descriptive. The logic is structured. The tests pass.

The reviewer reads it and something feels off.

Not wrong. Off. The code does what it should. But it does it in a way that the reviewer cannot quite follow. Not because it is complex. Because it is unfamiliar. The patterns are slightly different from how the team writes. The abstractions are reasonable but not the team’s abstractions.

The reviewer approves it. The code ships.

Six weeks later something breaks in that part of the codebase. The developer who submitted the PR is looking at their own code and struggling to remember why they wrote it this way. Because they did not write it. They accepted it. And accepting is not the same as understanding.

This is happening at scale right now. The PRs are getting approved. The understanding is not.

The test coverage that does not mean what it used to

Test coverage is how teams verify that code is understood.

Not consciously. But the act of writing a test for a function requires understanding what the function does, what it should do when inputs are unexpected, and what the consequences of it being wrong are. The test is proof of understanding.

AI coding tools have decoupled test writing from understanding.

The same tool that generates the implementation generates the tests. The tests cover the cases the model thought to cover. Which are the cases the model was confident about. Which are the happy path and the obvious edge cases.

The coverage number goes up. The understanding stays flat.

Teams are shipping code with ninety percent coverage that the team cannot fully reason about. The tests pass because the tests were generated alongside the implementation by a system that had consistent beliefs about both.

When production finds a case neither believed in, nobody has the mental model to diagnose it quickly.

What senior engineers are actually doing all day

Here is the job description for a senior engineer at a team that has adopted AI coding tools seriously.

Spend thirty percent of the time reviewing AI-generated code that junior engineers submitted without fully understanding. Spend twenty percent debugging production issues in AI-generated code that the author cannot fully explain. Spend fifteen percent answering questions about why the AI wrote something the way it did. Spend the remaining time on actual architecture work.

This is not the productivity story the AI coding tool vendors are telling.

The vendors are measuring lines of code generated and features shipped. They are not measuring how much senior engineering time is now spent cleaning up after AI-assisted junior engineering.

The junior engineers are more productive by output metrics. The senior engineers are less productive because more of their time is spent in review rather than creation.

The net at the team level is positive in the short term. The question nobody is asking is whether it stays positive over a two-year horizon as the codebase accumulates a growing layer of code that the team owns but does not understand.

The onboarding that broke

Here is an underreported consequence of AI-assisted development at scale.

New developers joining teams that code with AI assistance are struggling to onboard.

The traditional path for a new developer was to read the existing codebase, understand how things were built, ask questions about decisions they did not understand, and gradually develop a mental model of the system.

The AI-generated codebase is harder to read this way.

Not because it is worse code. Often it is syntactically cleaner than what humans write. But it lacks the fingerprints of the people who built it. There is no style that reveals the team’s thinking. There are no idiosyncrasies that prompt useful questions. The code is smooth in a way that makes it harder to understand deeply.

The new developer reads it. It makes sense locally. They cannot develop a global mental model from it the way they could from a codebase built by humans over time.

Teams that have been using AI coding tools for eighteen months are finding that their onboarding timelines have not improved despite the code being arguably cleaner. Some teams report they have lengthened.

The code got better. The knowledge transfer got harder.

The security review nobody ran

AI coding tools are trained on the public internet.

The public internet contains a great deal of code with security vulnerabilities. The models have learned from this code. They reproduce patterns from it.

Not maliciously. Statistically.

The pattern that looks clean and works correctly in the happy path but is vulnerable to a specific injection attack appears frequently in training data. The model has learned it as a valid pattern. It generates it. The developer who does not know what to look for does not catch it in review.

Security researchers have been documenting AI-generated vulnerability patterns for eighteen months. The specific classes of issue that AI coding tools reproduce at higher rates than experienced human developers have been catalogued.

Most engineering teams have not updated their security review processes to account for this.

They are reviewing AI-generated code with the same lens they used for human-generated code. The lens was calibrated to catch the mistakes humans make. AI makes different mistakes.

The vulnerability gap is widening between the teams that know this and have adapted and the teams that have not.

The architect who became the bottleneck

Something unexpected happened at teams that adopted AI coding tools earliest and most aggressively.

The developers got faster. The architects got slower.

Because the developers were generating implementation so quickly, the rate-limiting step became architectural review. Is this the right approach? Does this fit the system’s existing patterns? Will this create problems at scale? Does this introduce dependencies we do not want?

These questions used to be asked during implementation because implementation forced the developer to think through them.

Now implementation is fast and the questions get deferred to the architectural review that happens at PR time. The architect is now reviewing five times as many PRs as before, each requiring judgment about approach, not just correctness.

The architect is the new bottleneck.

The teams that have figured this out have moved architectural review upstream. Before implementation starts, not after. The developer and an architect spend thirty minutes on approach. The implementation is fast. The review is verification, not judgment.

This works. It requires admitting that the AI coding tool did not eliminate the need for architectural thinking. It relocated it.

What actually needs to change

The teams getting the most value from AI coding tools over an eighteen-month horizon are not the ones using them most aggressively.

They are the ones that identified which parts of development benefit from AI assistance and which parts require human understanding that cannot be delegated.

AI assistance is appropriate for implementation once the approach is clear. For generating boilerplate that would be tedious to write manually. For first drafts of tests. For code that fits well-established patterns.

Human understanding is required for architectural decisions. For security-sensitive code paths. For anything that needs to be debugged quickly under production pressure. For code that a new team member will need to learn from.

The distinction is not always clear. The teams that have been at this longest have built internal norms around it. They do not write them down always. They enforce them in review.

The review comment “this looks AI-generated and I am not sure you understood what you submitted” has become a real piece of feedback on real teams.

The teams that give that feedback are the ones whose codebases will remain maintainable.

The teams that do not will find out what happens when the system nobody fully understands needs to change quickly.

They will find out at the worst possible time.

The velocity was real.

The bill for it is arriving.