The Collapse of Workflows
When writing code was the long pole in the tent, building software using a standardized workflow just made sense.
We adopted workflows that had served us well for many years, in everything from factories to fast food restaurants, and applied the normal constraints of building software to it. When it takes a long time to build something, you want to make sure you’ve thought through all of the options beforehand. If you need to rebuild from zero then you’ve wasted weeks (or months).
But what happens when the amount of time that it takes to build the individual parts drops to almost zero?
In a classical factory sense, what if your car didn’t have just one engine to choose from, but instead could choose from 10 or 100?
Suddenly the whole model falls apart. The set of tradeoffs that you’re working under is totally different.
You need a new way of working to handle the coordination and overhead between all of the pieces.
In the new world, the spec around what you’re building becomes the most important input to the system. As you change the spec, the tasks, UI, and code underneath it should update automatically. A rebuild starts to become as simple as getting better at defining what you want to build.
It’s worth sitting with what this actually changes.
For decades, the bottleneck in building software was writing code. The whole shape we built around how teams worked (roadmaps, sprints, design reviews, handoffs, spec docs, etc) was a response to that constraint. If a build takes two months, you front-load all the thinking, because you cannot afford to be wrong.
When the build cost trends toward zero, the math inverts. Being wrong stops being the expensive thing and indecision becomes the expensive thing, because you can no longer hide behind “we have to be careful, this takes a while to make.” The whole workflow we built up to compensate for slow builds ends up being what’s slowing us down.
We’re moving from a code first world to a words first world and because of that, we don’t just need a new workflow, we need a different shape for our work.
In the old shape, the artifact you cared about was the code. The spec was a planning document, written before, abandoned during, and rediscovered when you tried to remember why you built something a certain way. Whatever was in the code was ultimately the truth.
In the new shape, the artifact you care about is the specification. The code is what gets rendered from it. If your spec says the checkout flow should ask for the address before the payment method, the system materializes that. If you change your mind tomorrow, you change the spec, and the system updates. The code becomes a downstream artifact of the intent.
This sounds like a simple change, but it’s not. Right now your tickets, mockups, and docs sit alongside your code. They get out of date within a week, quietly degrading and becoming a liability.
Specs that aren’t driving the system aren’t really specs, they’re just memos about the system.
What post-workflow software looks like, in practice, is this: humans and agents shape the spec together, and the system continuously produces the build that satisfies it. When the spec changes, the build catches up.
When the build can’t satisfy the spec then the system surfaces that as a question for the team. It doesn’t become a silent divergence in the background.
This changes a lot of things downstream. Engineering’s role switches from “writing code that implements X” to “shaping the spec so X is unambiguous enough for the system to satisfy.” Versioning becomes versioning of intent rather than versioning of the implementation. Disagreements about what’s being built surface earlier because you have a working implementation to play with, not just mockups.
This also changes the way that you coordinate work. In the old world you coordinated by passing artifacts between specialists. A PM writes the brief, a designer makes the mockup, an engineer implements, a QA engineer tests and you lose information at every step.
In the new shape, the spec is the shared artifact, and the coordination happens around shaping it. PMs, designers, engineers, and agents all work on the same living thing, with the parts of it being authored and transformed by all of the participants.
The old workflow at higher speed is not the same thing.
Most of the AI tools shipping right now are still playing the old game. They speed up the build step, which was already the cheapest step in the new world, and leave the spec and the handoffs untouched. You get a faster code generator inside an unchanged process. The result is the same vague aspiration owned by the same working group, just with more code generated against it.
The companies that will compound with AI are the ones that change the shape of the work, not just the speed of it. The build is what the spec produces, not the master document the team is anxiously protecting.
If we have it right, what changes is what the work of building software actually consists of. Less typing and rebuilding when someone changes their mind. More thinking, deciding, and articulating what you are actually trying to do.
Korey is a workspace for agents and people to build software in a words first (vs code first) world. Your team shapes the spec and the agents do the work underneath. Tasks and code stay in sync as the spec changes.
Built by Shortcut, the project management tool where humans and agents collaborate to build great software, used by tens of thousands of teams.