The Developer's Value Has Shifted from Speed to Verification

For two decades, a developer's value was measured by how quickly they turned an idea into working code. That metric has lost its meaning. With AI generating code in minutes, the bottleneck has shifted to defining intent and verifying the outcome—and this changes everything about the job.

The shift is not a prediction; it's already observable in team metrics. Faros AI, analyzing data from over 10,000 developers and 1,255 teams, found that pull request review time grew by nearly 91% in high-adoption AI teams. The time that used to go into writing code is now spent reviewing code that an AI generated—and that review is harder than writing was.

This is not the same job with a faster tool. It's a different job with a different center of gravity. The primary cost of engineering used to be converting business logic into syntax. Frontier models made that almost free. Value has migrated to two activities: precisely articulating what you want, and rigorously checking that the generated code actually does it.

The best analogy is the shift from manual bricklayer to architect with construction oversight. You produce the blueprint—the specification—commission the build to a team of AI agents, and sign off on the technical acceptance. Code becomes one possible realization of the design, not the design itself.

This idea has a name: spec-as-source. In its most radical form, you edit only the specification, and the generated code is marked "do not edit manually." Most teams live somewhere between spec-first and that extreme, but the philosophical shift is universal: intent becomes the source of truth, and code is its generated artifact. A good specification starts to function as a contract—it defines what "correct" means before anything is built.

The scale is already significant. The share of code co-authored by AI grew from a few percent in 2023 to tens of percent today, and more than half of professional engineers report using AI tools daily. This is not a future we're contemplating; it's a present we're already working in.

Sean Grove from OpenAI captured this shift sharply, arguing that writing code represents only about 10–20% of the value an engineer brings, with the remaining 80–90% being "structured communication"—organized articulation of intent. You can argue with those proportions, but the direction is hard to dispute: less code doesn't mean less work; it means different work, whose core is intent.

The polarization of competencies is real. Some advantages that served you well are losing value almost overnight; others are multiplying. Kent Beck put it sharply: ninety percent of his skills have lost their value, and ten percent have gained a thousandfold. That's a deliberate exaggeration, but it captures the asymmetry well.

On the rising side are several competencies worth naming explicitly:

• Architectural thinking—designing system boundaries and making decisions the agent won't make for you.
• Requirements precision—translating a vague "we want it to work" into an unambiguous, testable specification.
• Verification and judgment—what Beck calls "taste"—the ability to assess whether an outcome is genuinely good, not just technically correct.
• Context engineering—providing the agent with the right context at the right moment.
• Agent orchestration—coordinating several parallel instances working on different parts of a task.

The least obvious of these is context engineering. An agent is only as good as the context you give it. Mechanically, you supply the specification, constraints, examples, and relevant fragments of the existing system—in the right order and the right quantity—so the model reasons from the right material. Without this, the agent delivers the letter of the prompt, not your intent, and that's the source of most bugs you catch in review.

On the declining side sits what was bread and butter for years: writing boilerplate, manually translating requirements into code, debugging line by line, memorizing syntax and APIs. That doesn't mean this knowledge becomes useless—without it, you can't evaluate the agent's output. It only means that raw fluency in typing it out is no longer a competitive edge.

The bottleneck hasn't disappeared—it's shifted to verification. When code generation jumps from hundreds to thousands of lines per day, writing isn't the constraint anymore; review, integration, and accountability are. Simon Willison put it well: the entire software lifecycle was designed around the assumption that producing several hundred lines of code takes a day—and now it doesn't. Your job is to ship code you've proven works; an agent didn't change that—it moved the proving to the center of the profession.

In practice, that comes down to one brutal rule: whoever clicks "merge" owns the responsibility. You can't call a machine on the carpet or hold it accountable for an outage. So the more code AI generates, the more valuable what it can't do becomes—taking the consequences.

Does AI actually speed us up? The data looks contradictory until you look at the conditions. AI speeds things up on simple and greenfield tasks, and can slow things down on large, existing systems (brownfield) for experienced engineers. Those are different conditions and different results—not "same conditions, opposite outcomes."

Concretely, in a controlled experiment on a simple HTTP server, developers with an assistant finished the task noticeably faster (Peng et al., n=95, greenfield—arXiv:2302.06590). In a controlled field experiment across nearly five thousand developers, the number of merged pull requests grew by about 26%.

The results shift dramatically in a different context. When METR studied experienced open-source developers on their own large repositories (n=16, brownfield, millions of lines of code), they found developers were 19% slower with AI—even though the developers themselves believed they were 20% faster. Different sample size, different type of codebase, different result. A number without context misleads. METR later revised that study due to a sample selection error—so treat its result as one signal, not decisive proof.

On top of that sits the trust paradox seen in nearly every team. AI co-authors a significant share of production code today, yet 76% of developers simultaneously report frequent hallucinations and low confidence in AI code (Qodo, State of AI Code Quality 2025). That gap between the scale of delegation and the level of trust is exactly where verification debt is born—a hidden cost where time saved on writing comes back as a tedious audit of someone else's code.

One of the loudest advocates of the spec-centric approach, Guy Podjarny, acknowledged this limitation by shifting his own narrative from "spec" toward "context" (Tessl podcast, ep. 101). Natural language is simply too ambiguous to fully replace formal precision—and no next generation of models will fix that, because it's a property of language itself, not of the model.

The failure whose cost nobody budgeted for usually looks the same: AI-generated code ships to production without review by an experienced engineer, and a few hours later someone is counting losses. That's not an argument against AI; it's an argument for planning the process with verification time built in from the start—because saving on writing without verifying is an illusion.

Success doesn't depend on whether you deploy the tool; it depends on whether team members become active integrators rather than passive delegators—and that's a leader's job, not a configuration task. You can mandate AI use. You can't mandate trust or judgment. The difference between those two stances maps directly onto whether AI builds the team's competencies or erodes them.

At the individual level, it comes down to one decision: do you treat the agent as a thinking partner or a generator you approve? This distinction isn't soft—a pilot study by Shen and Tamkin (Anthropic, 2026) with about fifty participants learning a new library shows that developers who used AI to investigate "why" scored significantly better on comprehension tests than those who passively delegated generation and clicked "accept" (Anthropic Research). Active use builds understanding; passive delegation erodes it. Hence the same rule as before: don't commit code you don't understand.

At the team level, several concrete levers are worth deploying deliberately:

• Explicit AI use policy—where autonomous delegation is allowed, and where human review is required.
• Mandatory review of critical and security-related code—this isn't a place for auto-accept.
• Small batches and fast feedback loops—to catch an agent's mistake before it propagates.
• Evaluating specification quality, not line counts—measure what's now actually the bottleneck.
• Regular "no-AI days"—so the core skill set doesn't rust.

There's a trap, though, that even well-managed teams fall into. A top-down "use AI" mandate, issued without cultural scaffolding, can do more harm than good. Cat Hicks's research on what she calls AI Skill Threat—stress and professional identity uncertainty in the face of AI—shows it affects 43–45% of engineers (study across more than 3,200 developers), and a culture of learning and belonging reduces that threat, while pressure based on competition and "innate talent" amplifies it. In other words: a leader who builds a learning culture lowers resistance; one who only applies pressure raises it.

The market is polarizing, and the bar is rising—not falling—and every previous "end of developers" ultimately confirmed that. The number of simple junior roles at companies with deep AI adoption is shrinking, and the wage premium for AI and architecture competencies is growing. At the same time, some market forecasts show net employment in the industry still growing—and both signals are true simultaneously, depending on which layer of the market you're looking at.

The psychological cost of this change is real, and it's not a sign of weakness. Moving from the role of a creator who "holds code in hand and shapes it like clay" to the role of a reviewer of someone else's work strikes at an identity built around craftsmanship. Anxiety about your own role is a normal response to real change, not a reason for shame—and it's worth saying that directly, because silence on the subject only deepens it.

History provides a surprisingly strong reality check here. Every layer of abstraction in programming was born with the same prophecy—that it would eliminate the developer role—and every time, the prophecy was wrong. Compilers were supposed to let business analysts write their own programs without specialists. Fourth-generation languages and CASE tools promised application generation directly from specifications. DevOps was supposed to eliminate the database administrator role. Every time, something different happened than foretold.

The pattern is consistent and worth remembering: a lower barrier to entry increases the volume of software being built, which increases demand for more advanced engineers. Compilers didn't eliminate developers—they eliminated the need to write assembly by hand and raised the level at which we operate. The database administrator role didn't disappear with DevOps—it transformed into a platform engineer. SDD is the next such layer, not the first "end."

That's why Eric Hoffer's observation hits the mark: "In times of change, learners inherit the earth, while the learned find themselves beautifully equipped to deal with a world that no longer exists." In times of this kind of change, the winners aren't those who mastered the old craft best, but those who treat the new role as learning from scratch. Whoever clings to the identity "I'm the one who writes the fastest code" ends up beautifully prepared for a world that's just vanishing. Whoever adopts the identity of an intent author and verifier—inherits the one that's coming.

The difference between the developer in 2019 and the one today isn't that one works less. It's that the center of gravity of their value has shifted from coding speed to precision of intent and rigor of verification. That's the entire thesis of this article, reduced to one sentence.

Five things worth taking away as concrete actions:

1. Rising in value: architecture, requirements precision, judgment, and orchestration; declining: boilerplate, line-by-line debugging, and syntax memorization.
2. The bottleneck has shifted, not disappeared—"tests passed" is not "matches intent," and savings without verification are debt, not gain.
3. Build verification time into estimates from the start, rather than pretending code generation is the end of the work.
4. As a leader, build a learning culture, not just a mandate—active integrators outperform passive delegators on every metric that matters.
5. The profession isn't ending—the bar is rising, and the historical precedents confirm it.

There's something here that's easy to overlook in the panic about your own role. The work of an intent author is harder than the work of an executor—but it's also more interesting. Less time goes to mechanically typing out what you already knew how to write; more to what genuinely requires thinking: what do we want to build, and how do we prove we got it.