This trend is being sold as inevitable. It deserves more skepticism than it is getting.
The recent wave of announcements about cheaper AI models handling routine coding tasks, orchestrated by larger frontier models, has sparked a seductive narrative: soon, most programming work won't require human expertise. Just plug in your requirements, let the agents swarm, and collect your software. It's a compelling story. It's also incomplete in ways that matter.
The logic seems sound at first blush. If frontier models can break down complex tasks into smaller chunks, then distribute that work to cheaper, leaner models, you achieve efficiency and cost savings. Some coding work is genuinely repetitive. Why not automate it? The technology is real. The improvements are measurable. But the leap from "AI can write much of the code" to "AI can handle most coding" glosses over organizational realities that won't disappear because the tech got better.
Here's what proponents rarely acknowledge: coding exists within systems. Those systems have histories, constraints, and human dependencies that no amount of token efficiency addresses. A developer isn't just writing lines that happen to compile. They're making decisions about maintainability, integrating with legacy infrastructure, considering security implications that aren't always explicit in requirements, and communicating intent to future teams.
When you reduce coding to a resource optimization problem, you miss that the actual bottleneck in many organizations isn't the act of writing code. It's understanding what code should do. It's negotiating between what different stakeholders need. It's knowing when a technical approach looks elegant but will create debt later. These are judgment calls that require context, experience, and accountability.
The governance problem that larger enterprises are grappling with, as recent industry commentary suggests, points to a harder truth: AI-generated code at scale creates new management burdens. Who owns the decision when an AI agent made a questionable tradeoff? Who maintains code written by systems that won't remember their own reasoning? Who ensures that cheaper models didn't cut corners in ways that won't surface until production failure?
This isn't an argument that AI won't help developers work faster. It will. But the narrative that "cheaper models can handle most coding" when properly orchestrated flattens the actual work of software development. It assumes that complexity lives primarily in computational difficulty, not in judgment and integration.
Consider the implications for how we teach and develop new programmers. If the industry genuinely believes most coding work will be automated, why invest in training? Yet the technical foundation that helps someone use AI tools effectively is the same one that helps them understand what shouldn't be automated. The causality matters here. You don't get better judgment by using worse tools, even if those tools are sufficient for specific tasks.
The vendors pushing this narrative have obvious incentives. Cheaper models solving more problems means better margins and stronger market positioning. Lower barriers to deployment means more users and more data. These aren't conspiracies; they're normal business dynamics. But normal business incentives don't always align with what's actually true about how work gets done.
This doesn't mean the technology is overstated or useless. Coding assistance has genuine value. Cheaper models handling well-defined, repetitive tasks is real progress. But inevitability is a sales pitch, not an analysis. The "most coding" claim requires that we believe human judgment, organizational knowledge, and accountability concerns simply evaporate when efficiency improves. History suggests they don't.
The smarter position isn't skepticism about AI in applications. It's skepticism about narratives that erase the human and organizational layers where software development actually happens.