The Last Expensive Thing
In 1958 the U.S. Navy faced a coordination problem that it had no tool for. The Polaris missile program spanned some nine thousand contractors and a deadline driven by the Cold War, and no one could say when the first missile would actually be ready to launch.
The Navy’s answer to this problem, with the help of Lockheed and Booz Allen, was PERT, a giant map of every task and every dependency as a network. Then they traced the longest path through this chain of tasks and solved for a finish date. It worked, and like every planning tool built since, it rested on the assumption that the expensive part of every project is doing the actual work.
This assumption is older than PERT itself. Henry Gantt had been drawing charts that organized factory work around it since the 1910s, and it outlived them both. It is still the premise underneath every tool that teams use for tracking today. The project tracker and the roadmap both exist to ration the time of the few people who can turn an idea into something real. Building was the bottleneck, so the discipline was to decide carefully what you were doing before you started doing it.
Sometime in the last year that stopped being true.
An engineer can open Cursor after standup and the sprint board will be wrong by lunchtime. Devin, meanwhile, has opened two pull requests that no-one scheduled. Our planning tools still ration engineering hours like the scarce thing they used to be. Nobody has told them that the famine is over.
Watch where a day goes instead.
Someone in support drops a message into Slack: “the export fails on files larger than a certain size, and here is one that broke.” A PM reads it and files a ticket, things get a little shorter. An engineer reads the ticket, can’t tell which sizes matter, and then rewrites it as a prompt for an agent, things get shorter still. The example file doesn’t survive the first handoff, and “fails on large exports” becomes “fix the export.” The agent ends up solving a much blurrier problem than the one support reported, and maybe not even the right one.
No Gantt chart has a row for any of that. It’s just glue work, the effort of keeping a request intact as it moves from person to person and tool to tool, and it is quickly becoming the biggest cost in shipping software. The tools can’t help, because a ticket is a file in a filing cabinet: it stores a description of the work, then sits there while the work moves on without it. The example file never left Slack. The constraint that mattered is buried in a thread nobody will scroll back to find. The ticket has neither.
We say this with some humility, because we spent the last decade building one of the nicer filing cabinets. Shortcut exists to help teams plan around scarce builders, and tens of thousands of teams use it for exactly that. So when we say the filing was never the hard part, that’s a conclusion we earned the slow way, after a decade of watching where work actually breaks down: the hard part was always that the work could not carry itself.
We’re taking a swing at this problem with what we’re building in Korey Projects.
Here is what it does today, for us. Say we want to add CSV import to the app. We drop the mockup into a Project and add the Slack thread where a customer first asked for it. A coding agent chips in a note about where the code should live. None of it gets flattened into a ticket first. The Project works that pile of context into a spec, breaks the spec into tasks, and hands the tasks to the coding agents we use, staying connected to GitHub and our tracker while they build. The feature we describe in the morning comes back in the afternoon as a pull request we can review.
Projects is in alpha. The screenshot below shows where it stands today. Things are changing quickly.
The agents writing the code are the least interesting part of this. Cursor and Devin already do that well, and the companies building them are all climbing toward planning and specs from the other side. What none of them can see is the example file sitting in the support thread, because by the time a coding agent gets involved, that file is three handoffs gone.
Go back to the export bug. A spec written from the ticket says fix export. A spec written from the original thread knows which sizes fail and includes the file that broke. Same agent, same afternoon, very different pull request. Projects exists to write the second kind of spec.
The spec keeps working after the agents finish. On its own, a pull request tells you what changed. It has no opinion on whether the export now survives the file that broke. Because the Project still holds the spec, it checks the build back against it. The example file becomes the test, and anything the build missed comes back to the team as a question instead of a divergence you discover in production three weeks later. Review gets simpler: you start from whether we got what we asked for, and read the code from there.
This is also why you won’t have to torch your workflow to get here. Korey connects to the tools your team already runs (GitHub, Slack, your project tracker, with Jira on the way) and earns its place by killing glue work first: requests arrive with their context attached, and status assembles itself instead of being chased. The words-first way of working grows out of that, at whatever pace your team trusts it. The old tools were built to plan around a scarce builder. Projects assumes the opposite: the builder is now cheap, and context and decisions about what to build are the things worth protecting. You stop being a translator and go back to being the person who decides what to build and whether the result is any good, which is the part that no agent is going to take from you.
If we have it right, the spec becomes the artifact teams actually maintain, the way code is today: versioned intent, with the build as its downstream output. Projects is the first piece of that, a single place where context lives and reaches whoever needs it next, person or agent, so the same intent never gets rebuilt from scratch along the way. It is early, and inside our own team it already turns a conversation into reviewable code faster than the meeting that would have started it.
For a hundred years the expensive thing was the build, and we organized all of our work around protecting it. That is no longer where the cost lives.
When anyone can build, the build itself stops being what sets your work apart. What sets it apart is the intent behind it and the specific thing you were trying to make. The retelling is where that intent leaks away. That is the cost we are done paying.
What the glue work was crowding out is the human work that was always the point: choosing what to build and judging whether it came out right. There turns out to be more of that than ever. That’s the last expensive thing.
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 your favorite coding 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.