When Developers Can't Imagine Working Without AI

According to data collected by TechCrunch, a significant fraction of programmers now refuse to work without AI assistance. Not as a preference, but as a condition. The shift in attitude is striking, but what concerns researchers cited in the article most is not the dependency itself, but what lies behind the speed increase: code generated by AI can be faster to produce while simultaneously having lower structural quality than hand-written code.

The warning cuts deep. Speed and quality are not the same thing, and in software engineering that distinction carries consequences that compound over time: technical debt, unexpected production failures, and above all, a gradual erosion of the ability to understand and debug your own code.

More Lines Per Hour, But Understood by Whom?

The pattern researchers describe is familiar in other contexts: when a tool automates a cognitive task, the skill to perform it manually atrophies. It happened with mental arithmetic versus calculators, with spatial orientation versus GPS. Now it's starting to be documented more systematically in software development.

The specific problem with code generated by language models is that the output can look correct—it compiles, passes surface-level tests, does what's asked in the happy path—without the programmer truly understanding why it works or what hidden assumptions it makes. When that code fails in production, the person who needs to fix it may lack the context to do so quickly.

This is not an argument against using AI in development. It's an argument against using it as a frictionless black box.

The Productivity Metrics Trap

Part of the problem comes down to metrics. If a company measures engineer productivity by delivery speed or volume of code produced, AI immediately boosts those numbers in visible ways. Quality issues, by contrast, appear later, are harder to attribute, and aren't always connected back to the original cause.

In teams already working with tools like Claude Code—Anthropic's official CLI, which chains subagents, invokes MCP servers, and automates complete development workflows—the temptation to delegate without review is real. The capabilities have grown substantially: with a one-million-token context window in Claude Opus 4.7, an agent can reason over entire codebases. But reasoning about code is not the same as understanding it with engineering judgment.

The most mature teams we've seen work with these tools in recent months establish stricter code reviews, not looser ones, precisely because they know output volume increases and human oversight has to compensate.

Who Should Pay Attention

This debate matters especially for three profiles:

• Junior developers, who can end up producing professional-looking code without having built the mental models needed to debug or extend it sustainably.
• Teams with weak review culture, where AI-generated code can slip into production with less scrutiny than hand-written code would receive, simply because "the AI did it".
• Companies that evaluate engineers by delivery speed, which may be implicitly incentivizing uncritical delegation.

Senior programmers with solid foundations who use AI as an amplifier—not as a substitute for judgment—aren't facing the same risk. For them, these tools are genuinely productive without compromising their understanding of the system.

Editorial View

The pace at which code assistance tools have matured over the past year and a half is remarkable, and it would be foolish to ignore them. But the industry would do well to start measuring what doesn't show up on the productivity dashboard: whether teams remain capable of reasoning about their own code when AI isn't available, or whether that ability is quietly eroding.