Programming Will Become Mostly Specification Work—and That Will Raise the Bar for Engineers

I think programming will eventually become mostly specification work: defining what must be true, what must never happen, and how we will know the system is correct. A reasonable engineer can disagree, because code is still where precision lives today—but I think treating code-writing as the permanent center of software work mistakes the current interface for the enduring job.

By “specification,” I do not mean writing a vague ticket such as “add team billing” and hoping an agent fills in the blanks. I mean expressing product behavior, invariants, interfaces, operational limits, security boundaries, migration plans, test cases, and acceptable tradeoffs clearly enough that an implementation can be generated, criticized, and revised against them. The developer becomes less of a transcriptionist from thought to syntax and more of the person responsible for turning an ambiguous human need into a system that can survive reality.

Typing code is already the least durable part of many engineering tasks

Anyone who has maintained a production service knows that the hard part is rarely remembering the syntax for a loop, an HTTP handler, or a database query. The hard part is deciding whether a retry is safe, what happens when an event arrives twice, which system owns a customer’s state, how a schema changes without downtime, and what should happen when an upstream dependency is partially broken. Those decisions are specifications, whether or not they were ever written down.

Traditional programming hid this fact because implementation was expensive. If writing a feature required several days of hand-authored code, engineers understandably centered their process around code production. AI coding agents change the economics. Once an agent can produce a plausible service, test suite, migration, and documentation in minutes, the scarce resource is no longer keystrokes. It is reliable judgment. The bottleneck moves upstream into deciding what to ask for and downstream into verifying whether the result actually deserves to ship.

That shift will be especially sharp in ordinary product work. CRUD flows, API clients, forms, data transformations, integration glue, internal tooling, test scaffolding, and familiar refactors are not intellectually trivial, but they are highly patterned. Agents will increasingly assemble those patterns faster than a person can type them. Engineers who insist that real programming only counts when a human writes every line will sound like developers who once insisted that using a standard library was somehow less authentic than implementing a hash table from scratch.

A useful specification is executable enough to fight back

The implication is not that engineers should become better prompt writers. Prompting is a weak substitute for specification because it is easy to sound precise while leaving the important parts undefined. “Build a secure multi-tenant dashboard” is a prompt. “Every database query must be scoped by organization_id; cross-organization reads must be impossible through both application code and administrative endpoints; failed authorization attempts must be auditable without logging secrets” is the beginning of a specification.

The best teams will make those requirements mechanically useful. They will encode behavior in contract tests, property tests, type constraints, database constraints, authorization policies, schemas, observability checks, deployment gates, and fixtures that model ugly production states. Natural-language instructions will remain important because products are made for humans, but the durable parts of intent should become artifacts that can reject bad agent output.

• A feature brief should name the user-visible behavior and the non-goals.
• An interface contract should define inputs, outputs, failure modes, and compatibility expectations.
• Invariants should state what can never be corrupted, exposed, duplicated, or silently lost.
• Tests should cover examples and properties, including adversarial cases an agent is likely to miss.
• Operational requirements should define latency, cost, rollback, logging, alerting, and data-retention expectations.

This is why I expect specification work to make engineering more rigorous, not less. When implementation is cheap, sloppy thinking becomes visible sooner. An agent will confidently generate ten versions of whatever you asked for. If your request omits tenant isolation, idempotency, accessibility, cost ceilings, or deletion behavior, the agent has not failed by failing to invent your missing product and operational decisions. You have failed to make them.

Review will become design verification, not line-by-line proofreading

The code review we inherited from human-only development does not scale cleanly to agent-produced changes. A reviewer cannot responsibly inspect five thousand generated lines by scanning every branch and congratulating themselves for noticing formatting problems. Nor should they accept a giant diff merely because tests are green. The right review question becomes: does this implementation satisfy the intended constraints, and do our checks provide credible evidence of that?

That means reviewing at several levels. Engineers will inspect the architecture for ownership and boundaries; inspect a few critical paths for implementation sanity; run tests designed around invariants; examine migrations and permissions separately; and use production telemetry to validate assumptions after release. We will still read code, especially at security boundaries, performance-critical paths, novel algorithms, and failure-prone integrations. But reading every line will become less central than constructing a system where many wrong lines cannot pass unnoticed.

The strongest counterargument: software is too contextual to specify

The best objection is that most meaningful software requirements cannot be fully specified in advance. Products evolve through feedback. Users contradict themselves. Edge cases are discovered only after a system meets the world. A developer who understands a gnarly codebase has tacit knowledge about its history, politics, performance traps, and accidental dependencies that no ticket or formal contract captures. On this view, agents may speed up coding, but programming remains implementation work because implementation is where vague intent becomes concrete knowledge.

That argument is right about the limits of complete specification—and wrong to treat those limits as a defense of code typing as the core job. We will never write a perfect, final spec before building. But that is not how specification work operates in practice. Good engineers already work through a loop: state the current intent, implement a hypothesis, observe the result, learn from failures, and tighten the constraints. Agents accelerate the implementation step inside that loop. They do not eliminate discovery; they make it cheaper to run more deliberate experiments.

Tacit knowledge also does not disappear just because it resists formalization. It becomes the material engineers must extract, test, document, and use to steer work. If only one staff engineer knows that a ledger event can be replayed months later after a vendor recovery, that is not a romantic argument for hand-written code. It is organizational risk. The new tooling creates pressure to turn crucial tribal knowledge into guardrails before an agent—or a new human hire—breaks something expensive.

What should change now

Engineering teams should stop measuring developer effectiveness primarily by code volume, ticket throughput, or apparent fluency with an agent. They should reward engineers who make ambiguity visible, identify invariants, create high-signal tests, reduce unsafe degrees of freedom, and leave behind specifications that another person or agent can use without guessing.

That means changing the artifacts around development. Put acceptance criteria and non-goals next to implementation plans. Treat migrations, permissions, rollback paths, and observability as first-class parts of a feature definition. Build test suites around properties instead of happy-path screenshots. Teach junior engineers to read systems, formulate constraints, and investigate failures—not merely to turn a task into a pull request. And make agents earn trust through narrow, verifiable scopes before giving them broad autonomy.

Programming will not vanish into English-language wishes. It will become the discipline of making intentions precise enough for machines to act on them—and skeptical enough to catch machines when they are wrong. We should redesign engineering practice for that job now, rather than waiting until code generation makes our old definition of programming obviously inadequate.