The IDE has been the centre of gravity for software engineering for roughly four decades. Emacs, Vim, Eclipse, IntelliJ, VS Code — different philosophies, same premise: a human sits in front of a file tree and edits text. Everything else (compilers, linters, debuggers, version control) orbits that surface.
We think that premise is about to invert. Not disappear — invert. Within two years, for most commercial software work, the IDE will be a verification surface, not a production surface. The primary artefact engineers author will be specifications, and the tools we currently call "AI coding assistants" will be better understood as compilers — deterministic-enough translators from intent to implementation.
This isn't a hot take about Copilot autocomplete getting better. It's a structural claim about where the work happens.
The compiler framing
When you write Rust, you don't audit the assembly. You read the compiler's errors, you trust the output, and you move on. The compiler is not perfect, but it's reliable enough that inspecting its output is a debugging activity, not a development activity.
Tools like Claude Code, Cursor's agent mode, Devin, and the current crop of coding agents are on a trajectory toward that same relationship with their output. Today we still read every line they produce. In eighteen months, for well-specified tasks inside well-understood codebases, we won't — any more than we read the x86 instructions our TypeScript eventually becomes.
The input to that compiler is a specification. Not a Jira ticket written by a product manager in ninety seconds. An actual spec: preconditions, postconditions, invariants, example inputs and outputs, edge cases that matter, performance envelopes, failure modes. The kind of document that today gets written maybe once per quarter, for the hardest problems, because writing it is expensive and most teams don't bother.
When the compiler is cheap and the spec is expensive, the spec becomes the bottleneck. That reverses a thirty-year assumption about where engineering effort goes.
What this does to the org chart
The current software org is shaped around the assumption that implementation is the long pole. You have a few people who decide what to build (PMs, staff engineers, designers) and many more who build it. The ratio is usually somewhere between 1:4 and 1:10 depending on the company.
Flip the economics of implementation and that ratio stops making sense. If one engineer with good spec-writing skills and a coding agent can produce what four engineers produced in 2023, you don't need four engineers. You need one engineer who can think clearly about requirements, one who can review generated code critically, and a shared pool of agent capacity.
We're already seeing the early shape of this at teams we work with. The highest-leverage people are no longer the ones who can produce the most code per week. They're the ones who can produce the clearest specifications per week — because a clear spec compiles reliably and an ambiguous one produces beautifully-written garbage.
This has uncomfortable implications for how teams hire. The interview loop optimised for "can this person implement a binary tree on a whiteboard" is measuring the wrong thing. The relevant signal is: can this person take a fuzzy business problem, identify the invariants that matter, enumerate the edge cases, and write a document that a competent-but-literal reader could execute against? That's a different skill, and it's not well-distributed across the existing workforce.
Where the new bottlenecks emerge
Two places, mainly.
The PR review queue. If generating a PR takes an agent twenty minutes and reviewing it takes a human two hours, you've just moved the bottleneck from authoring to reviewing. Teams that don't restructure their review process will find their throughput decreases with agent adoption, because they've industrialised the upstream step without touching the downstream one.
We think the response here is structural: PRs get smaller and more numerous, review becomes a near-full-time role for senior engineers rather than a tax on their other work, and review tooling starts to include AI-assisted triage — "these three PRs touch the auth invariants, look at them first; these seven are CSS changes, skim them." The humans are still accountable; their attention is just better allocated.
Feature grooming and ideation. This is the less-discussed one and we think it's the bigger deal. When implementation was expensive, the organisation could hide behind it. "We can't build that, it would take a quarter" was both true and convenient — it pruned the decision tree down to something manageable. When implementation is cheap, that filter disappears. Suddenly the product org has to actually decide what's worth building, and most product orgs are not structured for that volume of decisions.
The grooming session where six people spend an hour arguing about a ticket that will take two days to build is going to look absurd when the ticket takes two hours. But the underlying problem — figuring out what the user actually needs — doesn't get easier. It gets more load-bearing, because more decisions flow through it.
We predict the rise of something like a "spec engineer" or "product engineer" role that sits between traditional PM and traditional IC — someone who can write specifications rigorous enough to compile, in domains they understand deeply. This role exists today in small numbers at places like Stripe and Linear. In two years it will be a standard seat on most teams.
What stays the same
A lot, actually. Distributed systems will still be hard. Production incidents will still happen at 3am. Security will still be adversarial. The parts of software that are hard because reality is complicated — not because typing is slow — are unchanged.
Debugging, in particular, will become more important, not less. Code you didn't write is code you don't have a mental model of. When an agent-authored service starts returning 500s under load, someone has to reconstruct the reasoning, and that someone needs the old skills: reading code carefully, forming hypotheses, instrumenting, bisecting. The engineers who invested in those fundamentals will be disproportionately valuable. The ones who only learned to prompt will not.
Our working hypothesis
We're building Dreamware on the bet that the spec-to-code compiler is the next primary interface, and that the organisations which restructure around it early — review processes, hiring criteria, team topology, the grooming cadence — will have a meaningful advantage over the ones that bolt agents onto an unchanged IDE-centric workflow.
The IDE isn't dying. It's becoming what the assembler became: still there, still occasionally necessary, but no longer where the thinking happens. The thinking moves up a level, to the specification. And the teams that get good at writing specifications — precise, testable, honest about what they don't know — are the teams that will ship.
Everything else is downstream of that.