Software in a Spec-First World

Michael Wirth — Fri, 20 Feb 2026 10:46:32 +0000

Reading one of Andrej Karpathy’s recent articles made me think a lot about the future of software and software engineering.

The obvious part is that we’ll “code in English” more and more. The less obvious part is what replaces code as the main thing we build, share, and sell. My bet: specs.

Specs become the product

For anything non-trivial, the hard part stays the same: what should this software do, exactly? That’s domain knowledge, tradeoffs, edge cases, definitions, and taste: an intuition for what “good” software should feel like. A lot of what designers and great engineers contribute lives there.

This is why the near future isn’t “everyone asks super-Siri for a serious business app and instantly gets it.” For real systems, you still need iterative clarification, disagreement, and decision-making. Agents compress the build, not the thinking.

The big change is who gets to participate: dedicated domain experts (not just engineers) can be directly involved in shaping software, because the bottleneck shifts from typing code to expressing intent precisely.

From “Open Source” to “Open Spec”

I expect a shift from “GitHub repo = code” to “GitHub repo = spec + tests”.

Projects publish specs, constraints, and test suites.
The “code” becomes closer to today’s build artifacts: generated, regenerated, swapped out.
Tooling grows around spec-writing to make it less like prose and more like engineering. Think structured requirements, invariants, property tests, traceability, simulation. SpecKit feels like an early hint of the direction. We’re still at the very start.

And specs likely won’t be one monolithic “plan doc”. More like many small, nested files - code-like structure, but written for humans and agents.

If you’re thinking about starting a company, my bet is that 2026 will be a great year to work on this problem.

Specs get composable (even more than code)

If the runtime is an agent and the interface is “English + tests + constraints”, then implementation language stops mattering. Specs become inherently more portable and combinable than today’s codebases.

You can imagine “spec dependencies” the way we currently have package dependencies - except the boundaries are defined by behavior and tests, not by APIs and language ecosystems.

A market for specs

If specs are the durable asset, you’ll start being able to buy specs instead of finished software.

First among engineers: “Buy this spec bundle, customize it, generate your own implementation.”

Later for businesses: “Buy the spec for this workflow/system so you can adapt it to your org.”

That means specs will also be worth protecting. Cue spec obfuscation, watermarking, and DRM.

The agent as runtime

For a while, generated code will still exist because regenerating everything on every run will be too slow/expensive. Eventually the execution engine could just be the agent, directly following the spec to perform tasks.

Feels like we’re heading from “programming as code” to “programming as intent + verification”. Code doesn’t disappear, but it stops being the center of gravity.

An F1 car for the mind

If your goal is to solve people’s problems, in my opinion that will stay economically valuable for a long time. If your joy is crafting beautiful code by hand, that will become relegated to a hobby.

Personally: I don’t miss writing code. Working on Lumenfall, I’m more productive than ever, and having more fun. For the first time, it feels like the tooling isn’t in my way, but actually making me faster - a true bicycle for the mind, except it now feels more like an F1 car or rather a rocketship.