The Trivial Token Timeline

That moment in a leadership meeting when I started to say, "Well, if you recall Frederick Brooks..." -- I realized I was probably already screwed.

There is a very specific kind of sentence that sounds persuasive only to the person saying it, perhaps in that millisecond when it's still in your head and not out of your mouth yet. I wasn't just trying to make a point about staffing and timelines, I was trying to smuggle in a credential: I have read the right books. I know the old laws. Please -- let me invoke them before you bring in the consultancy-programmers-wearing-ties and we somehow move even slower.

If you don't recall Brooks, his book The Mythical Man-Month has been correct for fifty years, and its correctness has felt, in a very specific way, a little like civilization itself. As solid as the very earth we live upon, and yet also an ominous warning sign -- like that last scene in Planet of the Apes, where the Statue of Liberty isn't revealed so much as finally recognized.

And then, while we were still fussing about Jira tickets and arguing about headcount, the cost of building something dropped to a handful of tokens and a prompt just coherent enough to be dangerous. The prototype appeared before the argument finished.

The myth stayed. The month stayed. Even the man stayed.

The Mythical Man-Month quietly became something else -- call it the Trivial Token Timeline -- where the cost of building collapses, but the cost of being wrong doesn't.

The Simulation We Called Planning

Most of the upfront time in software planning was an expensive simulation layer -- which is a polite way of saying we were all sitting in conference rooms pretending a document was the product. I have personally watched four adults debate a wireframe as if it might begin moving if we believed hard enough. Someone asks if the button should be blue -- not because it matters yet, but because it's the only part we can actually see.

None of this was superstition. It solved a real problem. Building software was expensive enough that you had to communicate the thing before you committed to making it.

But only a small slice of those documents was actually answering questions.

The rest was something else -- a codification of engineering beliefs and corporate culture, wrapped in a cloak of post-facto-failure ass-coverage.

We weren't discovering the truth. We were rehearsing what we already believed, in slightly more formal language.

Rodney, who actually has to build the thing, is sitting there nodding -- because disagreeing means another meeting, and agreeing means maybe we can start. And this wasn't about his tickets or sprints. This was the higher-order decision: what do we fund, how do we staff, what do we show the board?

Those decisions had weight. So we built an elaborate simulation layer to justify them. Six months of research and deep thinking -- which is a nice way to say polite fighting -- to arrive at something that felt like knowledge, a little like certainty, but mostly tasted like a leap of faith.

It felt real.

And it wasn't nothing. It just wasn't what we thought it was.

Plan in POCs

There is, of course, a very seductive version of this story now.

It's Saturday morning. I have coffee, a slightly dangerous prompt, and just enough spite to prove everyone wrong. By lunch, something real exists. By dinner, I'm wondering why the company needed six months.

But this is how bad decisions get made. Because even if that prototype feels like an answer, it isn't. It's the question -- made visible.

If you can replace some of that massive spec document with something real, you've done something important. You're no longer asking people to imagine the thing from a sketch of a sketch. You can point at it, you can touch it. You can argue about it, and you can break it. And you can improve it -- or kill it quickly and move on.

That's the Trivial Token Timeline -- where you can build anything quickly, but still have to decide what matters. Now that writing code is cheap, you can plan in prototypes -- but only if you're honest about what a prototype is. It's a planning tool that happens to look like a product.

That distinction matters.

The organizations that figure this out won't skip the hard thinking. They'll just move it earlier and test it against reality instead of letting it sit unchallenged in a document that nobody ever updates again.

For execs, the question changes from "Are we confident enough to fund this?" to "What is the fastest thing we can build to find out if this is even the right question?" That used to be impractical, as even a month-long prototype raised eyebrows: "You're going to throw it away?" finance would ask. "Maybe?" was my answer (But "Hell, yes" was my honest answer).

Cheap code doesn't make decisions easier. It just makes them sooner.

Now you can place a dozen bets in the time it used to take to approve one. But the bets still matter. Because selecting the right one -- understanding why it worked, why the others didn't, and what it actually means -- that part hasn't gone away, nor has it been solved by AI magic.

It's just been moved.

The top of the statue is still there.

Not buried in the sand -- just sitting in the room with you, every time we mistake a plan for the thing itself. You just don't need six months anymore. You need one or a dozen honest prototypes, and the willingness to throw them away.

That part -- deciding what actually matters -- still isn't free.