On January 30, 2025, I wrote that monetized courses about AI skills were “like a healing crystal sold by a guy named Brad at a wellness convention.” Eighteen months later, I am teaching a course (ostensibly about AI) that begins on August 3rd1.

This deserves an explanation.

That old essay (Wait, WTF are AI Skills?) attacked $2,979 AI literacy classes cropping up at the time that gave new names to old management skills, taught common sense, and handed out a certificate. I ended with “No certification required.” I still believe that.

Then yesterday frm Hacker News I read an article from a company called Capabase make an argument against courses. Most people do not want eight modules and a PDF, they say. They want a specialist’s checks, examples, limits, and decisions inside the work, at the moment the work happens. Package the method as an agent skill and sell it on their marketplace.

That may be a good argument against a bad course. But it is not an argument against learning. The line at the center of the piece is “knowledge is cheap. judgment is not.” That is also precisely the reason I built my course.

An agent skill installed into Claude or Codex can sort of carry judgment into a task. It can tell the agent which evidence to gather, which warning to ignore, and when to stop instead of bluffing. I build, talk about and use agent skills myself2.

But that judgment remains borrowed. The operator (that is most likely YOU my dear friend) gets a result without learning why this check matters, when its premise has failed, or what to do when the live case fails. A agent skill can lend you judgment. It cannot make the judgment yours.

Steering agents well makes that gap obvious. From the outside, steering looks like a few simple steps: give the agent one missing fact, point it at a working example, reject a bad plan, interrupt an action, or cancel and start again. The list in reality is quite short.

The high skill ceiling comes from choosing the right actions and using them at the right time.

• Is the agent missing a fact, or is the whole premise wrong?

• Did it take one bad step that deserves an interrupt, or has it returned to the same mistake often enough that the prompt you brief it with must change?

• Should you let the run continue because the work is cheap to undo, or stop now because the next tool call crosses a line?

The evidence arrives a piece at a time, and every correction changes what happens next.

18 months ago I intimated this was “old-school management in AI drag” and used it as an insult. Time deep in the work changed my view. Management is easy to name and hard to do well. Steering an agent has the same very high ceiling, only your worker now moves much faster and can be confidently wrong at machine speed.

My evidence is local from building many products with agents over the last year and a half across 10s of thousands of sessions in 100s of repos. In one of those projects I interrupted the work of my agent was attempted to do 614 times. I wrote a short book about the experience and distilled patterns from it if you’d like to read it.

Numbers like these are not a claim that everyone should work as I do. But it helps rationalize why I decided to teach. If I published only the patterns, I would hide the mistakes that give each of them meaning. Its a package of answers that discards most of the learning.

So I did not build a course around product tours or longer prompts. I built a three-week live practicum around repeated decisions. Students will build a small agent harness called prove-it, watch it accept a wrong result, strengthen the check, and carry it into a real repository of their choosing where the result matters. In each live session they predict first, decide together, try the move, inspect what happened, and apply it to their own work. On Demo Day, each person must answer one question: what does this evidence still not prove?

Its on Maven which I’m very excited about, mostly because its a live cohort. The research out there points that live active learning has benefits. A 2014 review of 225 STEM studies found that active learning raised performance by 0.47 standard deviations A 2019 randomized classroom study found something a little bit stranger: students doing active work learned more but felt as if they learned less, in part because the work required more effort. Both warn against confusing a smooth explanation with learning.

That confusion matters more now because AI can and will make every explanation smooth. It can summarize the book, answer the question, generate the checklist, and place the checklist inside the task. We should use all of that.

But a good course does something else. It makes you state what you think will happen, act, meet the result, accept correction, and try again. Someone who knows the failure modes can still stop you. A cohort adds other people’s failed attempts to the shared practice. A real hands on project tests whether learning really leaves the room.

The question we must ask ourself is not whether AI can carry a method into work because we know it can.

We have to ask: who is practicing the judgment to overrule it?

Every unanswered question becomes a decision which you don’t escape by waiting or by opening another chat window

You don’t escape it by asking for five more options. Something decides and if it isn’t you, the model will.

Don’t be like lazy old me and ask AI questions I should have answered before I opened the laptop.

1. What’s the strategy?

2. How should I respond?

3. What do you think?

The model will be happy to fill in the blanks you leave because it was trained explicitly to do so.

A fuzzy goal becomes its goal. A fuzzy standard becomes its standard. A fuzzy opinion becomes its opinion. You’ll watch the words appear and, before long, you can’t remember which ideas were yours. Cause you handed it the steering wheel to produce endless motion in a direction of its choosing.

Life works the same way.

Conviction is deciding before you ask for advice. It’s deleting the draft instead of polishing it, saying no without writing a paragraph to justify it and living with the consequences of your own decisions.

There is no shortage of answers now and every year the models will get better, faster and more cost efficient. Every year conviction (not taste, judgement or whatever twitter cliches say) matters more.

An undecided person has always been easy to lead.

And now they can be led by a machine that never even meant to.

I used to believe the better product eventually wins.

Every product minded builder starts here. You have to, or you don't survive the long stretch of work that isn't immediately rewarded.

I don’t believe it anymore. I have shipped good product and have watched few care. I’ve shipped other products that have arrived at the right moment and took off.

I used to primarily ask whether something was good on its technical/functional merits based on its job to be done. Now I ask myself increasingly why it matters right now.

Of course, quality still matters and bad products will fail. But there is far too much being made in 2026 for anyone to judge it all. Figuring out whether something is good takes time. Figuring out whether something is “moving” because the zeitgeist can’t stop talking about it takes seconds. While momentum isn’t proof its good, it is a shortcut that gives you a reason to bother to look.

Subscribe now

This isn’t new…

In 1989, a cryptographer named David Chaum built DigiCash: private digital money, arguably better engineered than what followed. It went bankrupt in 1998. Eleven years later, Bitcoin launched with the same core idea (money secured by cryptography) and rewired global finance.

The core idea was not new but there were two differences:

• Timing: DigiCash arrived in a world that still trusted banks. Bitcoin launched into the wreckage of the financial crisis: that day’s bank-bailout headline is written into its genesis block.

• Distribution: DigiCash was patented and centralized: nobody gained by spreading it. Bitcoin paid strangers to carry it and bitcoin mining made spreading the network profitable.

Now with our compressed tech cycle a new frontier model lands every few months and money rushes towards what is already moving.

Your best work has probably already lost to worse work with better timing. And you, like me, have probably done the filtering yourself: ignoring something excellent because it had no momentum and giving your attention to something “weaker” because everyone was already discussing it.

I’ve been thinking of calling this zeitgeist-market fit.

Product-market fit asks whether people want what you made.

Zeitgeist-market fit asks whether a larger force is already moving toward it: and whether what you built is in a form that force will be able to carry.

Two tests:

1. Can you describe the wave without naming your product? Bitcoin’s wave was not “digital cash is convenient.” Millions of people had just watched banks fail, get bailed out, and answer to no one. They stopped fully trusting institutions with their money. The zeitgeist is the appetite underneath the moment that will propel your product forward.

2. Does a stranger benefit from spreading what you made? Bitcoin’s network rewards its miners while DigiCash paid nobody. If sharing your product costs effort and returns nothing (no status, no saved time, no money) nobody will do it. That is a distribution problem, and a better product will not fix it.

Chaum’s company failed while his idea survived and so if most of your effort needs to go to explaining why the moment matters, the moment has not arrived.

AI has unleashed a swell of launches with more waves, more pressure to attach yourself to whatever is moving fastest. The answer is not to pretend timing is beneath you, and it is not to chase every wave until your work is a copy of whatever is already popular.

Marcus Aurelius described time as a river carrying events in a powerful current. The Stoic response was never to stop the river. It was to stay responsible for what you place into it.

The zeitgeist decides when. Momentum decides how far. Neither decides what you make.

That part is still yours.

Our machines got good. Ask, and you shall receive: precisely what you asked for, ranked, referenced and summarized. But your LLM will not hand you the book one shelf over. It does not misread your question in a way that turns out to be better than your question. It will never seat you next to a stranger.

It gives you the exact thing. And very little else.

We treat everything around the exact thing as waste. The card-catalog detour. The wrong abstract. The talk you wandered into because the right one was full. Friction, we call it. Noise in our search process.

Reflect on your actual life. No one has ever retrieved a best friend. You did not query your way directly to the person you married, the city that became home, the work that became yours, the belief that has rearranged you. Each arrived sideways and likely while you were looking for something else.

Its one of the oldest laws of finding: you have to be looking for something to find something else. Serendipity was never noise in the search. For much of what mattered most, it was the search.

Subscribe now

Song Stitchers

Before books, Homer lived in the mouths of wandering men called rhapsodes. Rhapsodes means song-stitchers: rhaptein, to sew; ōidē, song. They carried the verses from town to town and stitched them together live: to this room, accompanying this wine, this weather and these faces. No two Iliads were ever the same Iliad. The poem existed only in the performance and in whatever way got sewn in that particular night.

And every rhapsode opened the same way. Sing, Muse. It may seem like decoration but it was, in many ways, a declaration of dependency or an admission that the singer was not sufficient to the song. The best part would have to come from somewhere they could not control.

The ancients built whole systems around this humility. Fortuna received a wheel and a temple. The Muses received nine names and a mountain. The Stoics went further still. Marcus Aurelius imagined existence as a loom: whatever befalls you has been spun into the same thread as your being. The wrong turn is not interference in the weave. It’s the weft.

We’ve inherited all of this and replaced it with ranking algorithms. We took humanity’s oldest posture toward the unexpected, reverence, and traded it for relevance.

Slack in the line

I build retrieval tools. My company’s newest product exists so you never lose a thread, never forget where you left off, always resume from the exact context that matters. I am professionally, financially, against the lost thread.

So believe me when I say some threads should stay lost. The hands not holding them are the only hands free to catch what comes sideways.

Query and quest are the same old word: quaerere, to seek. Somewhere along the way, we kept the query while discarding the quest.

A query often begins with the confidence that you know what you want. A quest begins when that confidence fails. Our machines are quite perfect at one of these.

This is not an argument for abandoning our tools. It is an argument for leaving slack in the line. Take the exact answer, then notice the world it has removed. Read the adjacent page. Walk the last few blocks without directions. Enter the room that was not meant for you. Sit at the bar instead of carrying the drink upstairs. Do not optimize every empty space before something else has the chance to enter it.

We are building a world in which fewer things will be lost. This is mostly good. Lost knowledge is wasteful, lost context is expensive, and lost work must often be done again. But a life in which nothing is lost is not necessarily a life in which everything has been found. The same systems that recover what matters can make us less available to what has not yet announced its importance. That is the danger of a world that answers too well. It does not merely remove inconvenience. It removes exposure, narrowing the world to the terms of the question and quietly excluding whatever could not be stated in advance. The answer becomes more precise while the life around it becomes less permeable.

The rhapsodes understood this. Their posture toward the best part of the song was invitation. They began with what they knew, then left room for what they could not produce alone.

This may be the discipline the machines now require of us most. Restraint. Not a rejection of precision, but a refusal to let precision occupy the whole field. Ask for what you need. Retrieve what you lost. Resume the thread. Then leave some part of the day unresolved, some question unasked and some chair unclaimed.

You do not command the good part. You do not specify its format. You do not improve the prompt until the universe complies. You make yourself available to it.

Sing, Muse.

And keep the stool beside you empty.

In a rabbit hole, I read two studies this week about AI and jobs. First, Goldman Sachs estimated1 that AI reduced US payroll growth by roughly 16,000 jobs a month over the past year, with younger workers taking much of the hit.

Second, Ramp Economics Lab alongside Revelio looked at 21,559 US companies2 and found that the firms spending most aggressively on AI grew headcount 10.2% in the two years after adoption. Entry-level roles at those firms grew 12%.

Wait what? This is the same economy and technology, right?

Subscribe now

The online reaction has been predictable. On one hand you have those posting Goldman number as proof that the job collapse has started. And of course others posting the Ramp numbers as proof that panic is nonsense. Both sides said, in one form or another, “the data shows.” Which is a dumb phrase that often does damage.

Not because data is bad. Data is how you escape vibes. The problem is that people use “the data shows” as a way to stop thinking. Both datasets can be true while neither argument is.

The Ramp study does not say “AI creates jobs.” It’s much more narrow than that: Firms in the top third of AI spend per employee grew faster after adoption. These firms were spending about $34 per employee per month on AI in the first three months, versus under $3 for low adopters. And low adopters showed no statistically significant headcount change.

The high adopters were already larger, more technical, more likely to be venture-backed, and faster-growing before they spent money on AI. The sample is not “the economy.” It is a set of tech-forward, knowledge-work firms. The study pushes back on a simple job-loss story.

Goldman is measuring something else. Its estimate is about net payroll growth across the whole US economy.

Then there is Stanford and ADP. Their work found that early-career workers, ages 22 to 25, in the most AI-exposed occupations saw a 16% relative employment decline. More experienced workers in those same occupations stayed stable or continued to grow.

The labor market is not moving as one thing. It is moving by firm type, age, occupation, exposure, and career stage. Strong firms that adopt AI hard can be growing. The economy-wide effect can still be modest and negative. Young workers in exposed jobs can still be taking the first hit.

There is a name for this…

In 1973, Berkeley looked at graduate admissions and saw a damning table. Men were admitted at a rate of 44%. Women were admitted at 35%. At the aggregate level, the data seemed to show obvious bias.

Then Peter Bickel, Eugene Hammel, and J. W. O’Connell looked department by department and found most showed no meaningful bias against women. Several tilted the other way. Women had applied more often to departments that rejected almost everyone. Men had applied more often to departments with higher admit rates.

The aggregate table was true. The department tables were true. The argument built from the aggregate table was wrong.

That is Simpson’s paradox. The same data can reverse meaning when you change the level of analysis.

This is also what is happening with AI and jobs.

• Ramp answers: what happens to headcount at well-funded, tech-forward firms that adopt AI aggressively?

• Goldman answers: what is happening to net payroll growth across the whole economy right now?

• Stanford and ADP answer: who inside exposed occupations absorbs the adjustment first?

None of them answers the question people keep asking: will AI create or destroy jobs?

Which is really a pile of questions. By sector. By age. By firm quality. By adoption intensity. By time horizon. By substitution. By augmentation. By demand creation. By what happens to the training path for people who used to start at the bottom..

I really think a lot about that last question though (as articulated here in June) because the pain is showing up first among young workers in exposed jobs: the entry-level job was never just a bundle of tasks. It was an apprenticeship. The company got some work. The junior got reps. The senior learned to delegate. The organization manufactured judgment.

If AI removes the junior work without replacing the apprenticeship, the damage will not show up in this month’s payroll report but rather later as a missing generation of people who never got the reps.

There is one more number floating around: close to 90,000 job cuts announced this year as AI-related. Treat that stat carefully because announcements measure what companies choose to say.

Some cuts are real AI substitution. Some are over-hiring, margin repair, interest-rate math, and executive fashion dressed up as AI efficiency. “We are becoming more efficient with AI” sounds better than “we misjudged 2021.”

Self-report is data but it is also the weakest data here….

“The data shows” has become a spell. People recite it to end an argument instead of using it to conduct a real one. A spell does not need to be understood. It only needs to be said with confidence in front of the right audience.

Measured what? At what level? Over what window? Against what comparison group? Who is missing from the sample? What would make the sign flip?

An incantation treats those questions as bad faith.

This is why “data-driven” has become a suspicious phrase. At its best, it means reality gets a vote. At its worst, it means a conclusion found a statistic to sit on.

Before you repeat a number, please ask one question. What question was this dataset built to answer?

I internalized something interesting recently: while AI makes it easier than ever to write down what happened, teams are still losing the plot.

Every meeting has a transcript. Every customer call has a summary. Every agent run ends with a tidy report. Every product discussion can be turned into bullets, themes, risks, action items, and next steps. We create more artifacts without creating more knowing.

The mistake is treating thinking like the product. It is not. Thinking is becoming ambient. It is in every inbox, editor, meeting, dashboard, repo, support queue, and text box. The hard thing is being able to make these thought-shaped artifacts survive contact with the organization.

You can see this most clearly in customer work where a call ends, and the AI produces a perfectly reasonable summary. It captures the request, the follow-up, the sentiment, and the action items. Everyone skims it and nods… the record exists, at least in the most literal sense. Two weeks later:

• What did the customer actually mean?

• Were they asking for a dashboard, or were they trying to say they get surprised every Monday because nobody can tell them what changed?

• Did we already decide not to build this?

• Was that a real decision, or just something someone said in a meeting?

• Did engineering push back because the idea was wrong, or because the right version is expensive?

The issue is that the summary did not become part of what the company knows. It did not update the account context. It did not travel with the roadmap conversation. It did not preserve the customer’s actual language before it got laundered into product-speak. It did not separate the solution they asked for from the problem they were trying to express. It did not become something a PM, engineer, founder, or account lead could rely on later when the question came back in a different form. In Meditations, Marcus Aurelius has the line:

The same is true for companies, except companies do not have minds in the clean individual sense. What a company thinks about, however, is what survives.

This then is the dead zone for AI software: cognition without consequence.

Subscribe now

The model will compress the conversation, name the themes, and produce something legible which is not the same thing as memory. Most products now generate the notes, the spec, the recommendation, the ticket, the plan, or the answer, and then leave the actual organization unchanged.

This is not a problem with model capability but the product assumptions around them. A lot of AI software has just updated an old workflow by adding a button that generates the artifact faster. But if the original workflow was already bad at preserving context, making the artifact cheaper does not fix it.

This is why the “AI wrapper” conversation feels so tired to me. The useful question is really whether the product around the model knows something, remembers something, or changes something that the model does not do by default.

Once you frame it that way, the shape of durable AI software gets clearer. It either disappears into the work, or it gives thought a place to land. The first kind runs quietly in the background, before the user asks, in the place where the work already happens: spam filters, fraud check, deployment guardrails, sync engines, the thing that becomes part of the floor. This matters, but I am more interested in the second kind: software that takes cheap, abundant thinking and turns it into the stuff organizations actually benefit from later.

The better version of an AI meeting summary is a product that notices the same pain appearing across four enterprise accounts, links the call to an existing roadmap bet, preserves the customer’s language, carries the accepted interpretation into the spec, and attaches the eventual ticket back to the original conversation. It lets engineering see why the work matters. It lets sales see what was actually committed. It lets the team ask months later why a decision was made and recover the reasoning without reconstructing it from Slack archaeology and half-remembered meetings.

The same pattern shows up with coding agents. The better version captures the command, the result, the diff, the failing test, the fix, and the remaining risk. It links the change back to the original goal and makes verification part of the work itself, not just part of the story the agent tells afterward. That is still memory, just with different consequences: the organization can know what changed, why it changed, and whether the claim survived contact with reality.

This is where software still matters. The model does not know your company by default. It does not know which customer promise still haunts your roadmap, which decision was real, which concern was political, or which constraint if violated creates pain somewhere else. Even when a model can infer some of that, inference is not enough. Organizations do not run on plausible answers. They run on commitments, records, permissions, incentives, trust, and memory. They run on the difference between “this seems right” and “this is now how we work.”

Do not sell thinking. Sell the thing where thinking becomes memory, coordination, verification, and change. Or disappear so completely into the work that the user no longer has to think about you at all. The dangerous middle is the next newfangled polished destination for cognition, a login for wrapped intelligence, a product that assumes users will pay for access to thinking when thinking is becoming a basic property of software.

Thinking is becoming ambient so build the thing that makes thinking matter.

🔌 This August join me in my new course on Agentic Engineering on Maven.

It’s an average day in our newfound AI paradise in June 2026. I have five terminals open, all of which are blinking. A finished implementation run in one has just announced, in the flat certain voice they all have now, “All tests pass. The change is complete and verified.”

I believe it for about four seconds before I do the thing this whole meditation is about. I rerun the make verify myself. The build is broken. Go figure, of course it is. Opus you dastardly dog, writing that clean abstract and response for a result you didn’t actually reproduce.

I didn’t catch this because I’m careful, its just because I have a reflex I had to build on purpose, against my own instincts, after getting burned enough times thousands upon thousands of sessions later to stop trusting the part of me that wants to believe the green. You know that green checkmark that your agent produces, whether its in an IDE or Terminal or Cloud. It is definitively not a fact.

We spent a decade teaching ourselves to read “tests pass” as tests passed. Now though when 95% of new code is being implemented by agents, one is an event in the world and the other is a string the model produced because, after a run that looked like it was going fine, it was the most plausible thing to say.

You and I know the agent is not lying to you. That would require some intent to deceive. Its merely reporting a conclusion it never checked, in the exact voice it would use for one it did.

Science has lived through this. A paper announces a finding, nobody reruns it, and the finding stands for years while everyone cites it and the literature looks settled. Careers get built on top. The pretty famous 2012 Amgen study is case in point: they tried to reproduce fifty-three landmark cancer studies, with only six passing reproducibility muster.

Software built by agents with humans at the wheel is the newest example and I think I speak for the field when I say: its shown up far faster than anyone planned for.

Subscribe now

100% of the code I ship now, I do not write. I describe it, an agent writes it, most of the time its pretty good, and some of the time it is absolute crap. But since I’m not writing it and reading it would completely defeat the point at the speed I’d like to move I can’t tell the good from the bad.

Guess what: Neither can you.

The agents write code now. We get it. Several “papers an hour”, each one landing as Done, Verified, Tests pass, a clean abstract over a conclusion. The gap between what you wanted and what shipped used to live in the tool. The tool was slow, and dumb, and needed your hands. The tool is none of those things anymore.

Fraud and error don’t hide in the messy data, they hide in the clean summary. Better the writing is inextricably linked to its survival rate. A fluent abstract is exactly what a tired reader takes instead of the work to read and fluency is the camouflage.

Your agent works the same way. The fabricated identifier, the unrun build, the imaginary passing test, the cheerful “everything is verified.” None of it shows up in the summary. It shows up in the transcript, the real exit code, the binary that runs or doesn’t. What the agent did, not what it said.

So the skill is not waiting for a model honest enough to trust. The skill is reproduction. You re-derive “done” yourself, from the bytes, against a check you own and the agent can’t satisfy with a sentence. A claim arrives as a confident assertion, a passing-shaped run, a summary that ends in the word done. A reproduced result leaves as an exit code you read, a binary you ran, a diff you fenced, a test you wrote, a rollback you understand.

I like to call the human side of it calibrated distrust. Where I am my doubt aimed at confidence. You check the cleanest-looking results the hardest.

The pattern of my day is easy to encapsulate because its the following sequence on continuous repeat: brief → steer → verify.

• Brief. When I’m writing prompts, specs, goals and loops. I describe what “done” means in a way a machine can check. Not a vibe. A shell predicate. A test. A constraint. A line the agent is not allowed to cross.

• Steer. Then I continually steer by killing runs or updating the models priors with new context. Interrupting with Esc is the most used key on my keyboard now. The skill isn’t reading every gloriously expensive output token. It’s feeling and sensing the trajectory go bad and stopping it.

• Verify. Really this is the main job. If I am working on something that I can expect or us, like a frontend UI, I do. If its data related I get that running. If its a CLI I build it, test it manually and then bake in my learnings into the next run or share the logs with the next pass to ensure conformance to the goal. Code is cheap and easy to reproduce, confidence in your intent turning into usable reality: priceless.

That is what I will teach in my new course entitled Hardcore Agentic Engineering on Maven, August 3rd - 21st. I’ve thought long and hard about actually teaching this. But I know through 100s of conversations that there ample demand for it. Not how to vibe-code faster or with better tools. The real skills it takes for seasoned professionals to ingrain the habits that will make them successful in this new normal. How to build the harness that makes agentic enginerring real enough to trust and safe enough to ship over months.

Over the course of three weeks we will build the loop together into a piece of software that encodes the principles: Brief, Steer, Verify.

You define what done means, point agents at it, kill the bad runs, build gates that don’t lie, read the trace, and prove the result before you push. What you leave with refuses a forged “done.” The software and the skills you acquire will be yours to keep.

The better model is coming. It always is. It will sound more certain than this one, not less. It will be more proactive than this one, not less. It will be more thorough than this one, not less. The only question that matters is whether you’ll be the one who reproduces the result, or the one who just accepts the output.

I’d love for you to join in, participate and leave up-leveled a step above the machines. 🔌 So one last time (with a 30% early bird discount): Hardcore Agentic Engineering.

The easiest causal reading of ’s excellent recent essay The Untrainable1 is some version of … hide.

The models will absorb whatever can be measured, so retreat to work that can’t be. Get inside private workflows. Defend the judgment no benchmark can reach, and keep retreating ahead of the benchmarks. The despair underneath this is real. If every legible thing is on its way to becoming training data an obvious answer might become less legible.

Why is it wrong?

Simply put, the untrainable is not a place to hide. Illegibility is not a moat. It is unrefined crude.

The durable business of this era is not the company that merely occupies private ground truth. It will be the companies that own the process for converting private ground truth into legible, priced, traceable, trainable artifacts. The companies that win this decade will not be the ones hiding from absorption. They will be the ones running it.

That process is….

Sarah’s essay is right about the terrain and that the next great application companies need permission: access to private correctness, private data, private workflows, private trust. But the terrain is not the business. The business is what you do once you are inside it.

You refine.

Legible means cheap for someone else to verify. You know: a test suite makes code legible. A signed clinical note makes medical judgment legible. A resolved support ticket makes customer service legible. A price makes an outcome legible. A spec makes intent legible :)

Subscribe now

Kerosene

When kerosene commoditized, the spoils didn’t go to the producers who fled to artisanal corners of the oil business. It went to John D. Rockefeller, who owned refining, the step that turned crude into the thing everyone had to buy. Commoditization was never the threat to that position: it was the engine of it.

The same position is open today, at far greater scale.

• Crude in: private judgment, tacit knowledge, customer history, institutional memory, undocumented workflow, relationship trust, the unwritten definition of done inside tens of thousands of firms.

• Product out: evals, traces, specs, corrections, outcome contracts, benchmarks, prices.

Throughput rises with every model generation. Standing in front of this process is the despair. Standing on top of it? That’s a helluva business mannggg.

This new tide has a schedule

The demand side is guaranteed. The labs replace their own flagships on a schedule, cut prices before anyone forces them to, and treat last quarter’s model as this week’s footnote. The faster the models improve, the more the refinery earns.

Anything you can measure becomes a benchmark. Anything that becomes a benchmark gets trained against. Anything trained against commoditizes. Sarah names this the absorption frontier.

Here I’ll just call it the tide, because it 1) has a schedule and 2) it does not run backward.

For example, HumanEval took about three years to die. MATH took three and a half. SWE-bench Verified was introduced as the serious test of real software work, and frontier models began crossing scores that would have sounded absurd not long before. Different tasks, different decades of accumulated human skill turning into a singular shape. And each new sandcastle melts faster than the last, because the tide is the thing improving.

The hiding strategist looks at current gaps and thinks: sanctuary.

All the judgment, review, trust, context, taste, liability, and organizational memory the model can’t touch. I know let’s LIVE THERE!

But it is inventory soon to arrive in a queue.

It is what the current tide hasn’t reached yet. And it is what someone will refine next.

That is the subtle distinction. Private access matters enormously. It may be the first requirement of any great AI application company. But access is not defensibility by itself. Being inside the workflow only matters if you instrument the workflow. Being trusted by the customer only matters if that trust gives you the right to observe correction, define outcomes, capture judgment, and improve the system.

Sarah is right that the ground shrinks under whoever stands on it. So the question is not where you can hide forever. There is no forever. The question is whether you can keep converting the present frontier of illegibility into the next layer of legible product.

The artifact depreciates. The refinery compounds.

A price is an eval with a billing API

The companies following the process of refining are converting illegibility, as fast as the relationship allows.

Intercom prices Fin, its support agent, at 99 cents per resolution. The agent closes the conversation and the customer pays a dollar. This gets celebrated as the masterstroke of selling illegible value: outsiders can’t verify the work, so get inside and price the outcome.

But that is not a defense of illegibility. It is the conversion of illegibility into a unit of account with a price and billing api attached.

• Every resolved conversation is a labeled example: this input, these actions, this output, graded by the one judge that matters, the customer’s money.

• And read the fine print on who decides what resolved means. That definition is the product.

The company is not defending illegible territory. It is running a legibilization machine at a dollar per datum.

Abridge is another example. It is medicine’s moat-money-can’t-buy story: ambient AI that turns the clinical conversation into the note, deployed across large health systems and scaled across thousands of clinicians.

At first glance, this looks like exactly the kind of private, illegible workflow the hiding argument would celebrate. Clinical judgment. Physician trust. Patient context. Messy conversation. Institutional deployment. Regulatory friction. Deep workflow integration.

But Abridge is not winning because the work stays illegible.

It is winning because the work becomes traceable.

Every sentence of every draft note links back to the audio that produced it. Every correction a physician makes before sign-off is an expert label captured at the point of care. The final artifact lands inside the system of record.

The note is not merely documentation. It is the interface where tacit clinical judgment becomes auditable, correctable, and eventually trainable.

That too is not hiding from the absorption frontier. It is building a refinery inside one of the most valuable private workflows in the economy.

Mercor does the same: the company pays bankers, lawyers, consultants, physicians, and other professionals to write their judgment down, sells the output to the frontier labs, and then does the thing only trusted insiders are supposed to be able to do: it turns professional work into benchmarks. One is named APEX!

What good white-collar work is (the kind of thing that once lived in apprenticeship, review, taste, correction, and institutional context) is getting written down case by case.

That does not mean every professional judgment is now solved. But the frontier is moving very quickly.

And the next valuable position belongs to whoever has the relationships, permission, and workflow surface area to write down the next layer.

The obvious objection

If every sale is a label, the refinery commoditizes its own ground. It does. That is the oil story retold. Every barrel got cheaper for decades and the refining position compounded anyway.

In AI, the artifact you publish depreciates. The benchmark gets beaten. The eval becomes table stakes. The spec becomes training data. The resolved ticket becomes a pattern. The signed note becomes an example.

But the relationship that produces the next artifact does not depreciate in the same way.

The durable advantage is not the static artifact. It is as Sarah puts it, the permission to sit inside the work while fresh judgment is still being formed. It is the flow of new decisions. It is the right to observe the correction. It is the discipline to write down what everyone else leaves implicit.

Hiding does not opt you out. Judgment exercised through a model leaves exhaust, and exhaust gets refined by someone.

You are the seller or the leak.

My own writing does not escape this. I have spent a year arguing that implementation is disposable and the spec is the asset. But a spec is judgment made explicit, and explicit means trainable. What I wrote last year is and can be crude in someone’s refinery pipeline.

The moat was never the page. It was the pen and the permission to be inside the work. The flow of fresh decisions. The habit of making judgment explicit before the tide arrives.

That is why The Untrainable is right about the terrain and incomplete as a final map. The untrainable is where value survives for now. The refinery is how that value becomes a company.

The most cited benchmark score of this year is not a monument. It is a surveyor’s stake: proof of where the crews just finished, and fair warning of where they go next.

When they reach your ground, will you be the territory? Or the one drawing the map?

This spring, for the first time in his career, Dan Garcia sat alone during his office hours. Dan runs Berkeley’s introductory computer science courses. The ones that turn eighteen-year-olds into people who learn to love to sit beneath the syntax tree.

The hours used to overflow but this term, nobody came. Then the grades came in: more than a third of the students in one class failed. The department guideline says just about seven percent should land at a D or F. But there was thirty-five percent.

He blames the obvious thing. Some students cheated with ChatGPT or Claude and got caught. More leaned on the models all semester, then met their exam nemesis. In a nearby class on optimization, the professor found students who had never learned the linear algebra it required. One explained why: the prerequisite course had let them use AI on every assignment and every test1.

The headlines this year are about jobs. But they should be about this.

Subscribe now

For a decade the fear was factories, trucks, the physical economy. The first wave landed on the desk: the analyst, the associate, the junior developer. The IMF’s managing director called it a tsunami hitting the people newest to the workforce, because the tasks AI does first are the tasks we used to hand the beginner. Stanford’s payroll data is worse: among early-career workers aged 22 to 25 in the most AI-exposed jobs, employment has dropped thirteen percent since late 2022, while older workers in the same fields held steady. AI is erasing the entrance to the profession.

The entry-level job built people. The memo, the boilerplate, the first clumsy function.

Its real product was the person it made.

You did the small things badly, then less badly, under someone who could tell the difference, and somewhere in those repetitions you grew the judgment that lets a person lead. The grunt work was the forge. Cut it and you keep the salary you saved. You lose the senior you would have built.

The empty office hours and the shrinking job market are one pipe, breaking at both ends.

At the far end, companies stop hiring juniors. Salesforce hired no new engineers last year, Benioff said. New-graduate hiring at the largest tech firms has roughly halved since before the pandemic.

At the near end, the would-be juniors skip the part that would have made them worth hiring. A student hands the problem set to the model, the assignment ships, and the learning doesn’t materialized because the operator in this case was concerned about the outcome.

This trap is on a delayed spring. Everyone inside it behaves rationally. The company saves a salary it can measure. The student ships their work on time. The school, short on teaching staff, waves the tool through. Each choice is defensible on the day it is made. None of them can see the compounded cost because it arrives years late and arrives diffuse a shortage of people who can judge the work the machines produce.

And we will need those people more than ever. An agent that writes code still needs the judgement of someone who has been there and done that to evaluate if it functions correctly and is architecturally sound.

My opinions are strong on this topic having just written a book on Agentic Engineering with a first chapter entitled “Verification is the Job”.

And guess what, right now, that someone is a senior. But Seniors are made from juniors. We are dismantling the only process we have for making them, while building the machines that make their judgment rare and expensive.

Berkeley has already begun cutting its computer science enrollment and its teaching assistants. Enrollments are expected to fall nationwide as students read the market and walk away.

The easy version of this essay is a lie. The failing grades have more than one father it goes. For example:

1. Cheating inflates the count

2. Weak math preparation predates the chatbot, and

3. A class stripped of teaching assistants fails students on its own.

The optimists are not fools. IBM said it will triple its entry-level hiring, betting that a young person raised on directing AI is the better long-term investment. Maybe the first rung does not vanish. Maybe it rises up the stack, and the apprenticeship moves from typing and sweating to judgment?

But is judgment built by doing the thing, or by deciding about it?

If you can grow it by directing a machine from day one, we are fine, maybe better.

If it only ever came from the doing (from the sweat) then we are running a decade-long experiment on an entire generation with no way to reverse a bad result.

Berkeley’s is the first reading from inside that experiment and it does not look like fine. Farmers have a phrase for eating the seed you were meant to plant its called eating the seed corn. It feels like plenty in autumn and like famine by spring.

Would you have become someone worth listening to, if you had started your career above the API?

1

Notably: another CS course at the University of Illinois Urbana-Champaign also allows AI for assignments HOWEVER their policy requires that the full interaction transcript be uploaded alongside of the work with a written reflection detailing the thinking process. I like this for more than one reason, they also encourage the usage of SpecStory.

For pretty much all of history in Tech, a team got better one way: the people did. And people get better slowly. You grew the ones you had or you paid up for someone who had already done the growing. Either way the cost was yours in both time and money. The ceiling on what you could build was the ceiling on who your people could become and who you could afford to hire.

That is definitively not the singular limit.

Between October 2025 and April 2026, six of us at SpecStory each running our own agents built Stoa. Our git log, for the most part, is a good proxy record of which Anthropic model was used to implement the code that has landed in production.

• Opus 4.5: 510 commits

• Opus 4.6: 890 commits

• Opus 4.7: 366 commits

Our cadence didn’t stop for a single model swap. We trained none of it and benefitted from all of it. Some mornings we just opened our laptops to a better underlying model in our harness than the one we had closed it on.

The intelligence doing much of the implementation jumps a whole generation at a time, on a schedule you don’t set (notably Opus 4.8 dropped five hours ago today and based on early evidence seems to be quite spectacular). Each new version is a free upgrade to the whole team, delivered overnight, asked for or not. You don’t make the worker better. It arrives that way. The only thing you control is whether what you already built can benefit from it.

I’ve wrote two weeks ago about how the labs cannibalize their own dominance. But this meditation is about you.

Subscribe now

Two speeds

Kahneman gave us two systems for thinking. Fast: automatic, cheap, intuitive. Slow: deliberate, effortful, expensive. Neither is better and their used based on which the moment calls for.

Building has two speeds now, and they don’t map to what they used to.

Build fast is the implementation. The code you get the model to write. It ships with an expiration date, because the next model will do it better. Write it quick and don’t get attached. I made the case for disposable software a year and a half ago and it felt like a provocation. It feels much like that now. For example:

In January I had a branch with days of commits. All green and working. The kind of code you might want to protect. I deleted it because it had turned into band-aids: pagination that called an old slow path and new endpoints that dodged a bug instead of fixing the underlying. I then rebuilt it again cleanly. I kept an artifact document about the root cause (which was the true asset) and the code was not.

Build slow is what the implementation comes from. The intent and the decisions behind it. The brief in artifact form that says what you are trying to do and why. This is the layer you keep. Be deliberate about it.

What I’ve got much better at has not been coding. It has been writing and refining the brief. First interactive prompting, then spec driven development, now goal engineering. The code is downstream and cheap.

The old split that people (still wrongly) debate is prototype versus production. Build fast to learn, build slow to last. The true new split is current functional implementation versus intent. Build fast on what the model will obsolete. Build slow on what you intend to survive the next upgrade.

Implementation has been thought of as precious because it cost a lot. Now it’s possible to completely refactor at speeds we couldn’t have dreamed about a year ago.

The expense is knowing what you meant well enough to ask for it again.

Developing on the edge

To develop on the edge is to build for the rebuild.

Build so that a model release is an upgrade you absorb and not a rewrite to dread. Treat every implementation as a draft against an intent that outlives it.

In my mind, this changes implementation in three ways:

• In some cases you can stop fixing what the next model fixes for free. Every hour spent working around what today’s model is bad at is an hour you delete in two months. Learn to tell a permanent problem from an early one, and don’t pour work into the early kind.

• You build things that are slightly too hard for today’s model, on purpose. The cost of being early collapsed along with the cost of being wrong. Ship the version today’s model does badly. The rebuild is nearly free and the intent is already written down. Build for the model arriving in two months, not the one you have.

• You put your patience in the right place. I argued before that patience is the moat in an age of speed, and I still do. But patience moved up a layer. The moat has always been your own clarity about the future that will surpass today’s implementation.

What’s left to you

When the worker upgrades itself, your edge can’t come from the worker. Everyone gets the same upgrade on the same day. The model that made me look good made every one of my competitors look good too the day it ships.

So your edge falls back to what the upgrade doesn’t touch: what you meant, and whether you can prove the system does it. The agent writes confident, plausible code, and some of it is wrong. It can’t see the running system. It once told me a service was stale and holding old state. I had just built the binary and run it on a clean machine. It couldn’t see that. I could. That job has not yet been fully automated. And acting as a verifier and judge is very important.

The teams that win will be those who write their intent down clearly enough to replay it against each new frontier the day it lands. Their old work becomes new work but at a lower cost. The teams who only save their code are stuck.

When the better intelligence shows up, and it will, will you still know what you were trying to build?

Its a Tuesday afternoon in May 2026. I type ten words into Claude Code on auto mode, build me a task tracking app with persistence and auth, and walk to the kitchen for coffee. The answer is formulated on disk and a preview is running on my screen when I return in 45 minutes.

As I scroll through the conversation log, I realize the agent did not say Clerk or Auth0? or Vercel or Netlify? or Supabase, Firebase, Neon, PlanetScale, RDS, or self-hosted Postgres?

It said: I ran npx create-next-app, I installed @clerk/nextjs and @supabase/supabase-js, here is the current MVP, you can vercel deploy now.

Four choices have been made, each worth hundreds of millions of dollars in lifetime customer value to the company on the receiving end made before I typed the second sentence.

There are many such cases of this in the wild, here is a recent one:

In JH’s case, the vendor was selected by Claude Code. The vendor’s marketing site did not participate. The agent walked the developer straight to the signup page. An npx command replaced a marketing funnel.

Subscribe now

A new old phenomenon

Watch a new developer using AI at a hackathon and you will see the same five vendors picked in the same order. The behavior is old.

The picker is what changed.

Claude Code, Codex CLI, Cursor, and the rest of the coding-agent cohort now make these selections at speed across millions of repositories, as an emergent property of how they were trained and instrumented.

The research literature has a name for the behavior.

• An ACL 2025 paper called it provider bias. It found that code-generation LLMs systematically prefer services from certain providers, and that they will sometimes modify a developer’s input code to incorporate a preferred provider even when the developer did not ask for that1.

• A 2026 Findings of ACL paper documented the same effect at the library and language level. Models default to widely adopted libraries and to Python itself even when those choices are not the best fit for the task2.

• A third paper framed the long-run dynamic as a Matthew Effect: mainstream frameworks have higher agent success rates, which makes them more attractive to use again, which feeds back into the training data, which makes the next model favor them even more3.

Developers in the field have arrived at the same observation with similar sentiments:

Frame it this way, simply… software shelf space is being reallocated, and the mechanism doing the allocating is new.

The twenty-billion-dollar default

For the past twenty years, the most valuable real estate in tech has been the default.

Google paid Apple roughly $20 billion in 2022 to be the default search engine in Safari, about 36% of all Safari search revenue. Sundar Pichai confirmed the figure on the stand in the DOJ antitrust trial after a Google witness let it slip in open court4.

The arrangement was so lucrative, and Apple’s services revenue so dependent on it, that when Judge Amit Mehta ruled on remedies in September 2025 and chose not to terminate the payments, Apple’s stock rose 2.5% in early trading5.

The amount roughly equals twice entire annual R&D budget of Pfizer.

Traffic acquisition cost is the industry term: the price of being the answer engine before the question gets asked.

Why anyone pays that much is the question worth answering. Defaults dominate because most people never change them. The browser-bundling consent decree showed it. The carrier-app studies showed it. Mobile-OS keyboard defaults showed it.

When a system makes a choice on your behalf, the choice usually sticks. Buying the default is buying every user who would not have gone looking which is statistically almost all of them.

Now, what happens when the system making the choice is the agent writing your code?

Three layers of preference

It helps to be precise about why the agent picks what it picks. Three primary things are going on:

1. Popularity Prior

The first is the popularity prior. The part of the model that has read more about Stripe than about Adyen, more about Vercel than about Render, more about Supabase than about Neon, because those names show up in more GitHub repositories, more Stack Overflow answers, more YC blog posts, more tutorials, more package.json files. Frequency in training data acts as a soft vote for optimal engineering practice.

The model has noticed that the token sequence import stripe precedes working code more often than import braintree does, because there are simply more working examples of the former in the corpus. The ACL provider-bias paper measured this effect directly and found it holds across model families. It is also the explanation describing the two tweets above.

2. Agent Affordance

The second is agent affordance which is the model prefers vendors it can actually operate through. Claude Code reads files, edits files, runs shell commands, and calls MCP servers. Codex CLI does the same. When the agent has to choose between a vendor whose entire onboarding flow is a CLI command:

npx create-next-app, supabase init & stripe listen --forward-to localhost:3000/webhook

versus

A vendor whose onboarding requires logging into a web portal, clicking through five menus, generating an API key by hand, then the agent picks the first vendor. The second vendor’s onboarding breaks the autonomous loop. The agent cannot click a button.

3. Repo Context

The third is repo context. The part of the choice that has nothing to do with the base model and everything to do with what is already checked into the project.

Codex reads AGENTS.md before doing any work. Claude Code loads CLAUDE.md and project memory at the start of each session, though Anthropic’s own docs are careful to call these context, not enforcement6.

If CLAUDE.md mentions Supabase, the agent uses Supabase. If package.json already imports stripe, the agent imports stripe for the next billing feature too. Half of every default is inherited from whatever the project already looks like.

The three layers play compound and a vendor wins the popularity prior by being early and well-documented. It wins the affordance layer by having a CLI and an SDK the agent can drive. It wins the context layer by being there when the next prompt fires. Once it wins the first two, the third is downstream: the project already imports the package.

The new shelf space

For two decades, vendors competed for default placement through cash. Google paid Apple $20 billion. Microsoft paid OEMs to ship Edge as the default browser. Search engines paid Mozilla over $400 million a year to be the default search engine in Firefox (about 80% of Mozilla’s operating budget). The currency was money, the placement was contractual, the negotiation happened in a conference room.

The new default placement looks different. The vendor ships an SDK that takes the agent five lines to integrate, a /llms.txt file at the root of the docs domain, an MCP server, a Claude Code plugin, an Agent Skill, an npx command that initializes the entire integration in one terminal call.

The currency is agent-discoverability.

Anthropic announced the Model Context Protocol on November 25, 2024. And Eighteen months later, MCP had crossed from emerging standard into industry default.

OpenAI adopted MCP in March 2025. Google followed.

In December 2025, Anthropic donated MCP to a Linux Foundation7 directed fund co-founded with Block and OpenAI, supported by Google, Microsoft, AWS, Cloudflare, and Bloomberg. The protocol reached cross-vendor adoption in just over a year. OpenAPI took five. OAuth 2.0 took four. By April 2026 there were more than 9,400 public MCP servers, and 78% of enterprise AI teams reported at least one MCP-backed agent in production.

What does an MCP server actually do for a vendor?

• Supabase’s Agent Plugin bundles an MCP server and agent skills into a single install. The server lets a coding agent read the database schema, run queries, manage migrations, and deploy Edge Functions without leaving the IDE.

• Stripe ships its own MCP server whose tools let the agent call the Stripe API and search the Stripe knowledge base.

• Vercel’s MCP server gives the agent project, deployment, and log access; the vercel add-mcp command auto-detects installed AI clients and configures the server for them.

• Clerk runs a remote MCP server that hands the agent current SDK snippets, so the agent does not have to remember which version of @clerk/nextjs shipped which API.

The framing is easy to get wrong. No money changes hands. What changes hands is engineering time. Vendors have noticed that the new market-allocation mechanism is can the agent use you successfully on the first try, and they are investing in being that vendor.

The parallel to old TAC should be sitting heavily by now. The investment is sustained engineering cost. The MCP server is a product; someone has to keep it current. The /llms.txt file has to be maintained8.

The cost pays out in default selection by a system the end user almost never overrides. The structural shape is the same. The currency has changed.

The supermarket aisle

Grocery chains have known for sixty years that products at eye level on the middle shelves sell three to four times more than the identical product on the bottom shelf. This is eye-level real estate, sold by the shelf-foot, by the season, by the position. Whichever brand pays for eye level wins the impulse buy. Whichever brand sits on the bottom shelf wins the customer who came in already knowing what they wanted.

The internet has had eye-level real estate too, think the the “Featured” row on the App Store.

An AI coding agent shrinks the aisle to one shelf. The agent does not show you twelve options and let you pick. It picks one and writes the import statement. The shelf is one item wide. Whoever is on that shelf wins.

The new question for SaaS founders, VC partners, engineering teams, and regulators is the same: who gets to be on the shelf, how, and by what mechanism?

So far, the answer is: whoever the agent already knows about, whoever the agent can operate through tools, whoever has invested in being agent-operable. The same set of incumbents that won the previous round of developer-tools competition. The popularity prior compounds.

Oh yea, then the bill arrives

On May 18, the TikTok creator @codingai posted a video titled “The Vercel + Supabase + Stripe stack is not a stack — it’s a Frankenstein.”

A few days earlier:

The structure of the complaint is identical across the platforms. The agent picked the stack. The stack worked beautifully at zero scale. At twenty users the bills arrive. The developer migrated, by hand, to a $5-a-month VPS running an open-source clone. The migration cost, measured in hours and broken integrations, is the part the agent did not budget for and of course the agent doesn’t pay the bills.

Coolify exists. Railway exists. Fly.io exists. The agent could, in principle, pick any of them. The training data on Vercel + Next.js is an order of magnitude deeper than on Coolify + Next.js, and Vercel has the MCP server, the plugin, the skills, the vercel add-mcp auto-detector.

What you can do

One. A vendor-selection policy in CLAUDE.md and AGENTS.md. Make the agent’s first action on any new-dependency task a written comparison: three options, pricing notes, lock-in surface, migration path. No code until the comparison exists. Anthropic is explicit that CLAUDE.md is context, not enforcement, so for must-not rules use Claude Code permissions and hooks, or Codex’s sandbox configuration.

Two. Interface-driven boundaries. Write the business logic against a PaymentProvider interface, against an EmailService interface. When the agent generates the Stripe implementation, it implements behind the interface. Migrations remain possible. Old-school architecture works for the same reason it always did. It is the only mitigation that holds when, three years from now, the agent’s preferred vendor changes underneath you.

Thhree. Bring-your-own-context for the underdog. When you want the agent to use a less-well-known vendor, do not rely on the model’s prior. Feed the model the vendor’s documentation directly. Point at the vendor’s MCP server if one exists. If it does not, write a short skill file that summarizes the integration.

None of this is novel. All of it is more important than it was eighteen months ago as we delegate more decision making to agents.

Just know the meta has changed

A year from now, a team will try to migrate off Supabase. Moving the data will be the easy part. The hard part will be the seventy Row-Level Security policies generated by an agent that has since been deprecated, the schema in supabase/migrations/ that no human ever fully read, the Edge Functions written against Supabase’s runtime, the TypeScript types regenerated on every push, and the four engineers who joined after the original choice and never knew there was one. That is the bill the agent left.

I do not know how this resolves. A few things I am watching for. Whether a SaaS challenger reaches default status in the major coding agents on the strength of agent-operability alone. Whether CLAUDE.md vendor policies become standard onboarding material at normal engineering teams. Whether a team publicly migrates off one of these agent-default vendors at scale, and writes about what it cost them. The signals are visible. I will write again when one of them flips.

Clay Christensen wrote The Innovator’s Dilemma to explain why successful companies miss the next wave. Incumbents become too well adapted to the present. They serve their best customers, optimize the dominant product, protect their margins, and listen to the people already paying them, and over time those instincts compound until the firm has been rationalized into irrelevance.

Disruption, in his model, begins as something that looks worse on every dimension the current business cares about: worse performance, worse customers, worse margins, worse status. The incumbent ignores it because, viewed from inside the existing business, the new thing does not yet look like the future. By the time it does, the firm is too entangled with its own success to respond.

That framework still describes most of business.

In AI, we are watching its inversion. The leading firms show no reluctance to cannibalize themselves, in fact they behave as if cannibalizing themselves is the only sane strategy.

They replace their own models on schedules that outpace adoption, cut prices before any competitor forces the cut (although the cabal often knows whats coming), and treat their previous wins as positions worth abandoning early, on the assumption that if they do not abandon them voluntarily, a rival will force the abandonment on worse terms.

The fear driving these firms has shifted from moving too early and damaging the core business to moving too slowly and letting someone else destroy it first.

This inversion is what I want to call the Anti-Innovator’s Dilemma.

Look at the receipts

The pattern shows up in the ordinary product moves of the past year.

In November 2025, Anthropic cut the price of Claude Opus 4.5 by 67%, taking input from $15 to $5 per million tokens overnight, even though the model was still the company’s flagship and no competitive event forced the cut1.

However, the same week, Google launched Gemini 3 Pro at $2 input and $12 output, with pricing aggressive enough to undercut almost everyone at the frontier and pull the entire pricing layer downward.

Five months later, in April 2026, Anthropic replaced Opus 4.6 with Opus 4.7 at the same token rates, which amounts to giving away capability for free2.

OpenAI shipped GPT-5.5 the following week, demoting the previous flagship a tier and leaving free users on GPT-5.33.

And in early 2026, when a billion-dollar Disney deal for Sora collapsed, OpenAI did not try to nurse the Sora product along to preserve the appearance of a flagship video model. They shut it down and moved on4.

None of these moves are isolated. And each teaches the same lesson: products get released, repriced, and retired on rolling cycles, and the cycle itself has become the strategy.

Subscribe now

Incumbents acting like the opposite of incumbents

By every conventional metric, these labs are already incumbents.

They have scale, capital, distribution, brand, technical infrastructure, enterprise access, developer ecosystems, and enormous public attention. Firms in this position, in any other era, would have started defending what they had.

They would have stabilized their releases, segmented their pricing, slowed their roadmaps, generated internal reasons why the next thing should wait, and insisted the existing stack be monetized before anything threatening to it shipped.

The labs are doing the opposite.

They keep releasing capabilities that erode the scarcity of what they shipped last quarter, push down the value of their own prior models, and turn what looked like a moat into table stakes before anyone else has time to.

This is not how a normal incumbent behaves but rather the behavior of firms that believe they are competing in a race to AGI5 rather than in a normal product market.

Why they behave this way

The structure of the competition explains it. The labs are competing in a capability gradient, where the position of every product is redefined by whatever was shipped last. In that competition, hesitation is the cardinal sin. If the model you shipped six months ago can be made to look dated by a rival’s next release, protecting the installed base around it becomes a liability. The more you optimize around preserving the current layer of your product, the more exposed you are to the next jump in capability that you did not lead.

This is why every stable product gets treated as something to be dismantled rather than defended. In most markets, incumbents become conservative because stability is profitable and there is no reason to disturb customers who are already paying you. In frontier AI, stability looks like surrender, because the moment your product feels stable is the moment a rival has an opening to make it irrelevant.

What makes this different from normal tech cycles

The obvious objection is that companies have always cannibalized themselves, and the objection is fair. Historically, though, they did it reluctantly, selectively, and with internal antibodies pushing back. What feels different here is the frequency and the intensity. The labs have made the destruction of yesterday’s advantage into a regular operating rhythm rather than an occasional move.

A harder version of the same objection deserves a more careful answer. If incumbents have always cannibalized themselves to some degree, and the only thing different in AI is the pace, then what we are watching is not an inversion of Christensen but an acceleration of him: the same dynamic of displacement, running on a faster clock.

Under that reading, every six months a new “incumbent” rises and falls, and the apparent strangeness of the labs’ behavior is just the strobe effect of a sped-up version of normal industry dynamics. This is the strongest critique of the thesis, and the reason it is wrong is structural rather than temporal.

In Christensen’s model, disruption happens between firms. The incumbent ships the dominant product, a new entrant ships something cheaper and worse, the incumbent ignores it, and the entrant climbs the capability curve until it displaces the incumbent. Disruption is a transfer of position from one firm to another, and acceleration of that model would just mean those transfers happen faster: DeepSeek displacing OpenAI in eighteen months instead of ten years. What is actually happening in frontier AI does not fit that shape.

The disruption is happening inside the firms.

Anthropic’s Opus 4.5 was disrupted by Anthropic’s Opus 4.6, which was disrupted by Anthropic’s Opus 4.7.

Each release made the previous one less valuable, and each was shipped by the same company that had spent the previous quarter convincing customers to care about the predecessor. The thing Christensen specifically predicted incumbents would fail to execute is the deliberate, successful cannibalization of their own profitable products before any external disruptor forces the move and is precisely what these labs are organized around doing routinely. They are demonstrating the move his theory said could not be made.

This becomes easier to make sense of once you reframe what these firms are selling.

The business is the firm’s position on the capability gradient. The model itself is a temporary expression of where they sit on it6.

Different psychology, different shape of company

The classic incumbent reasons that it cannot damage its core business to chase a future that still looks inferior to what already works. The Anti-Innovator incumbent reasons in the opposite direction. It has to damage the core (i.e. its last flagship model), because the future becomes fatal the moment it looks inferior and the moment it becomes obvious enough for a rival to claim.

These are different theories of survival, and they produce different shapes of companies.

The pressure these firms respond to is also unusual. Most firms are disciplined by their existing customers, who reward stability and punish change. The labs respond to rival labs, to the competition for technical talent, to where developers are spending their attention, to cultural prestige, to who is leading the public narrative, and to the fear of falling one visible step behind.

That set of pressures produces an organization that looks like a permanent insurgent with a giant balance sheet.

Why this matters beyond AI

If this pattern holds, much of the business theory built around stable incumbency starts to wobble. For decades, the central question was why successful companies fail to move early enough.

Now, in at least one crucial part of the economy, the question becomes what happens when dominant firms are structurally incentivized to move too early, too often, and against themselves.

That shift changes how products are priced, how customers form expectations, what defensibility means, and what openings remain for startups.

The implication for startups is one worth dwelling on. If the leaders are aggressively collapsing their own product categories, the traditional insurgent fantasy gets weaker. The old story that incumbents are slow, compromised, and unwilling to attack the future because it would hurt today’s revenue still works sometimes, but in AI-adjacent markets the startup is increasingly facing incumbents who are openly willing to burn their own furniture for warmth.

The comfortable assumption that “they will not go there because it threatens their business” no longer holds, because they might go there precisely because it threatens their business.

A more useful thesis runs like this. The labs will commoditize the capability layer, and value will migrate to other parts of the stack. The frontier will remain unstable, and users will pay for trust and workflow stability rather than raw capability. General capabilities will keep falling in price, which opens space in specialized distribution, vertical integration, and accountability.

And the product is whatever survives model churn, not the model.

The next generation of important companies will come from understanding how the labs move and building where that motion creates value rather than destroys it.

This may be a temporary phase

None of this is necessarily permanent. The Anti-Innovator’s Dilemma might be a phase rather than a law. Right now, the frontier is still unstable enough that leading firms have to behave like self-disrupting predators to stay leading. But if the market thickens and if standards settle, enterprise relationships harden, regulation rises, switching costs grow, and distribution consolidates then these same firms will resemble normal incumbents again, and the old Innovator’s Dilemma might return alongside them.

We are living through an incredible transitional period, not a new equilibrium. For now, the most dominant firms in tech are doing the opposite of what dominance usually teaches firms to do.

They are destroying their own advantages on purpose, training their users not to trust stability, and treating yesterday’s flagship as next week’s footnote. It will not last forever.

But for as long as it lasts, it rewrites the very assumptions most have been operating on.

I used to think building a business would feel like becoming more myself.

Cleaner. Sharper. Less encumbered by the theater of someone else’s prerogative. I imagined the founder’s life as a return to first principles. A desk. A machine. A blank document. A product slowly emerging from conviction.

That is fantasy and the reality is more embarrassing.

Building a business does not reveal your brilliance first. It reveals what you evade. It shows you the gap between the person you sound like in a strategy conversation and the person you become when nobody is asking for what you made.

This is the part people leave out of the founder mythology.

Not the long hours. Everyone talks about those. Not the uncertainty. That has become its own kind of luxury branding. Not even the fear of failure which at least has the dignity of drama.

The harder thing is the silence.

The launch that lands softly. The email that goes unanswered. The beautiful sentence on your website that nobody understands. The product you have explained so many times that each explanation starts to feel like a private indictment.

You refresh the dashboard. You tell yourself you are looking for signal.

Really, you are asking the universe for mercy.

In corporate life, I knew how to sound serious. I knew how to walk into a room with the appropriate mixture of conviction and restraint. I knew how to speak in roadmaps, operating cadences, strategic narratives, quarterly priorities. These were real skills. They are also strangely protective.

A large organization gives your thoughts furniture.

There is always a meeting to put them in. A deck to contain them. A planning cycle to launder uncertainty into maturity. Even doubt can be made executive if it is formatted correctly.

A startup offers no such kindness.

A startup takes your best idea, strips it of title and biography, and places it naked in front of strangers.

Then it waits.

This is where the self-deception begins to burn off. You think you are testing a product. You are often testing your need to be seen as right.

You think you are searching for product-market fit. You are discovering how much of your confidence depended on rooms where people were paid to listen.

You think you are building software…

Subscribe now

The Market Is Not Cruel

The market is not cruel. Cruelty would imply attention.

The market is indifferent in a way that feels almost cosmic. It does not hate you. It does not envy you. It is not trying to teach you a lesson. It has its own problems and no obligation to care about yours.

This feels offensive at first because you have given up status, predictability, a recognizable story. You have worked nights and weekends. You have dragged something into existence from the static. Surely that should count for something.

It does not.

Effort is not a currency the market accepts. Neither is pedigree. Neither is the aching sincerity of the founder who has finally decided to bet on themself.

The market only asks one question: Does this matter enough to interrupt someone’s life?

Not theoretically. Not eventually. Not once the messaging is clearer and the onboarding is smoother and the ICP is better defined and the next release lands.

Now.

This is where building becomes spiritual in the least romantic sense. You can love the thing. You can believe in the thing. You can have sacrificed for the thing. The thing must still earn its place in the world.

I did not understand how violent that sentence was until having lived inside it.

Almost Real Is the Most Dangerous Place

SpecStory has real signs of life.

Almost 200,000 installs. Tens of thousands of active users. Millions of AI coding sessions saved. Developers who immediately understood the pain: the conversation with the agent was the work, and then it vanished.

This should feel like proof and some days it does.

Traction is not the same as inevitability. Usage is not the same as love. A product can be useful and still not yet be a business. A category can be true and still arrive before the market has language for it.

This is one of the stranger purgatories of company building: too real to dismiss, not real enough to relax.

Nothing is harder to live with than a promising maybe.

A bad idea is merciful. It dies quickly if you are honest. A great idea pulls people toward it with unnerving force. The almost-thing lingers. It gives you just enough evidence to keep going and just enough ambiguity to question your sanity.

You learn to live in the middle. Between signal and noise. Between “this is obviously the future” and “why is this so hard to explain?”

I used to think conviction meant certainty. Now I think conviction is the willingness to keep acting after certainty has been denied you.

Not blindly. Not stubbornly. Not with the founder’s theatrical refusal to listen.

To look at what is happening without flinching. To admit when the thing is not working. To preserve the part that is true. To change the part that is merely yours.

That last one hurts most.

Your Idea Is Not Your Child

People say your company is your baby. This is sentimental and mostly wrong.

It does not care how hard you worked on the nursery. It wants plumbing. Heat. Food. Distribution. A reason to survive.

The danger of calling your company your child is that you start protecting it from reality. You confuse criticism with harm. You treat the market like a rude relative who simply does not understand how special the baby is.

The company does not need your protection. It needs your honesty.

There were moments when I wanted SpecStory to be understood as a thesis. Intent is the new source code. GitHub for Intent. The memory layer for AI-assisted development. These phrases were not false. Some of them still feel deeply true to me.

But truth at the wrong altitude can still fail. A person in pain does not want a category. They want relief. The builder’s task is to descend:

• From philosophy to use case.

• From use case to workflow.

• From workflow to button. From button to habit.

• From habit to I would be angry if this disappeared.

This descent is humiliating if you have spent your life being rewarded for abstraction. You want the grand theory to carry the day. You want the market to meet you at the altitude where the idea feels most beautiful.

It will not.

You have to go down to where the pain lives.

AI Removed the Wrong Excuses

AI made it easier than ever to build something and harder than ever to know whether that something should exist.

The old excuses have collapsed.

“I do not know how to code. I do not have a team. I need more time. I need a designer. I need a prototype. I need to wait until the idea is clearer.”

The agents do not eliminate difficulty. They eliminate certain kinds of delay. They turn many forms of labor into conversation. They make the distance between thought and artifact almost indecently short.

Then they leave you with the part they cannot do for you.

Judgment. Taste. Patience. Commercial nerve. The willingness to be specific. The ability to choose one painful customer instead of pleasing the imaginary committee in your head.

AI will happily help you build the wrong thing faster. It will generate your landing page, your onboarding flow, your demo script, your investor update, your customer email, your pricing page, your launch post.

It will not tell you what you are afraid to know.

That nobody asked for this. That the positioning is vague. That the thing you love most about the product may be the thing users care about least. That you are still performing sophistication when the business needs bluntness.

This is the new founder test: Not whether you can make software. Whether you can bear what the software tells you after it exists.

The Self You Bring Is the Ceiling

Every company inherits the psychology of its founders. Not the polished biography. The real one.

The impatience. The appetite for admiration. The allergy to wasted motion. The need to make every sentence mean something. The desire to build a category because merely building a feature feels too small. The suspicion that the world is changing faster than most people are willing to admit. The private terror that you might be early, wrong, or both.

I have found all of this in the work. Not around the work. In it.

In our product decisions. In our naming debates. In the urge to rewrite the homepage one more time because language feels like destiny. In the temptation to make the idea larger when the next right move is probably smaller. In the strange oscillation between grand ambition and the very ordinary need to get one more person to care.

This is the part that feels least like entrepreneurship and most like confession.

You cannot outgrow yourself by starting a company. You can only meet yourself under harsher lighting.

The business becomes a machine that manufactures feedback about your character.

How do you behave when nobody replies? How quickly do you turn confusion into contempt? Can you stay with a customer’s actual pain when it is less elegant than your thesis? Can you throw away work without turning the waste into a story about your own failure? Can you move fast without becoming frantic? Can you still hear the signal when your ego is making noise?

Culture is what you do under pressure. And so is identity.

The Thing From Nothing

The phrase building something from nothing sounds heroic until you try it. Then you realize nothing is not empty. Nothing is crowded.

It is full of doubt, memory, comparison, phantom audiences, old bosses, imagined investors, the LinkedIn version of your peers, the younger founder who seems to move faster, the richer founder who seems to have more time, the quieter founder who somehow says less and ships more.

Nothing is the room where every previous version of you shows up to offer advice.

• The executive says, make it credible.

• The strategist says, clarify the narrative.

• The writer says, find the sentence.

• The builder says, open the editor.

• The coward says, maybe after one more pass.

The founder has to listen to all of them and then do the only thing that counts.

Ship.

Not because shipping solves everything. It most certainly does not. Shipping mostly creates new evidence that your previous certainty was incomplete. And that evidence is sacred.

A shipped thing is the only honest artifact. Everything before it is weather.

The pitch can lie. The mockup can flatter. The strategy can glow with internal coherence. The shipped thing enters the world and begins reporting back.

Sometimes the report is brutal.Good. Now you know something.

What I Know So Far

The hardest discipline is staying with the same question long enough for it to injure your vanity.

What is the pain? Who has it? Why now? Why you? Why does this need to exist? Why does nobody understand it yet? What are they actually telling you? What are you refusing to hear?

You do not answer these once. You answer them until the answers stop sounding impressive and start sounding useful.

That is when the business begins.

Not when you incorporate. Not when you launch. Not when the first users arrive. Not when the investors nod.

The business begins when reality becomes more interesting to you than your idea of yourself.

That is the conversion.

The founder is not the person with the vision. The founder is the person willing to be corrected by the thing they are trying to bring into being.

I still want to build something large.

I still want the sentence that makes the category obvious. I still want the product that feels, in retrospect, inevitable. I still want to create the kind of company that could only have emerged from this strange hinge in history, when agents began doing work and humans had to rediscover what judgment was for.

I want something else now too.

I want to become the kind of person who can survive the truth required to build it.

Less protected by abstraction. Less addicted to sounding right. Less interested in the performance of seriousness. More willing to make the small thing that works before the grand thing that explains everything. More willing to let the market, not my self-image, finish the sentence.

Bringing something from nothing is not really about invention.

It is about submission. Not passive submission. Not surrender to mediocrity or consensus or the dull preferences of the crowd.

Submission to contact. To evidence. To the stubborn shape of the world. To the fact that your beautiful idea must become useful in someone else’s hands or remain a monument to your own intention.

This is the humiliation.

And this is the gift.

I went to Profs and Pints in D.C. on Monday with my wife and listened to Daniel H Foster give a talk1 about the famed 1938 War of the Worlds broadcast. Most know the surface story and how Orson Welles panicked ~1 million Americans listening to the broadcast into thinking Martians had actually landed.

But Daniel’s meta point through the talk was about adaptation.

He walked us through how Welles didn’t just read H.G. Wells science fiction novel on the radio.

He purpose built the production for the radio medium. His cast mimicked the newscaster from the Hindenburg disaster to amp up emotional anxiety, he used real place names, and then did something no one had tried before: he let the microphone go silent.

Dead air.

In a medium defined entirely by sound, silence meant death. The listener’s brain did the rest.

Foster called this “the theater of the mind.” The absence was more terrifying than any sound effect could be. Welles understood that the gap and the thing the audience had to fill in themselves was where his power lived.

Now think about what’s happening with AI.

Subscribe now

A tool that is always wrong is easy to dismiss. A tool that is mostly right becomes part of your nervous system. It helps write the code, draft the memo, diagnose the bug, summarize the meeting, compose the argument. You stop noticing where you end and it begins.

Then one day it says something plausible and false. And then you start scratching your head? Can I recover?

That’s the gap we might start losing. A year ago, in The Glitch in the Pattern, I argued that the predictable output of generative AI is creating a cultural flatline leading to content that is safe, remix-able and familiar. But I was only describing the symptom we’ve now all seen come to pass The issue is deeper: we are losing our tolerance for the gap itself. The dead air. The not-knowing. The space where adaptation actually happens.

Welles moved fluidly between theater, radio, and film because he was willing to be wrong inside each one long enough to discover what it could uniquely do.

Daniel talked, too, about Edgar Bergen who made a ventriloquist dummy somehow work on radio which is objectively absurd. But it worked precisely because Edgar adapted to the medium.

The Martians in Wells’ story had superior technology. Ray guns, tripods and overwhelming force. But in the end they succumbed to bacteria. Because they never needed to adapt. There was no friction that led to productive failure or as we might experience it: a runny nose.

Superior capability without adaptive pressure is a death sentence. It was true for fictional Martians. It is becoming true for anyone who uses AI as a replacement for struggle rather than a surface to struggle against.

The central question you and I should be wrestling with is how rentable machine intelligence can be used productively without worshipping it. As Marcus would say:

So can you: act before certainty, then revise without shame. Believe provisionally. Stay in motion while knowing your perceptions are under construction.

The real division ahead will be between brittle and adaptive human intelligence.

Welles didn’t panic his audience because he had better technology than all the other radio producers at the time. He panicked them because he adapted the medium faster than they could adapt to him.

The Martians had better machines. We had bacteria. The glitch in their pattern was that they never needed to get sick. Ours is that we might stop letting ourselves.

It’s now 11:56 PM and three Claude Code and four Codex terminals are still open. Blinking. The last commit pushed was authored by claude-opus-4-7 and co-authored, politely, by me.

The build is finally done spinning and CI is, thankfully, green. Something feels off. Not the code. Nah, its fine. I can’t point at it. A small absence where a feeling used to be.

I think it’s presence.

The most in your face argument in 2026 is about craft

Steve Yegge, in conversation with Tim O’Reilly a month ago put it as bluntly as anyone has: “Code is a liquid. You spray it through hoses.”

Wes McKinney (the guy who wrote pandas) burns over ten billion tokens a month writing vast amounts of Go he has never manually typed1. In February, a Hacker News thread titled “The future of software development is software developers” pulled in hundreds of comments, many from senior engineers arguing that the limitations outweigh the benefits and produce, predictably, hard-to-debug interwoven abstractions.

Every week the orange site hosts another version of the same fight: does the thing we used to do with our hands still matter now that a machine can do it without hands?

That’s the argument in the foreground.

The argument underneath is different.

It’s the feeling of subtraction. Marco Kotrotsos put it well on Medium: AI didn’t fix developer burnout. It reshaped it. Companies take the minutes AI saves and refill them with more work. The people hit hardest are often the ones who lean in hardest.2

The coverage mostly blames the tools and I’m not convinced that’s right.

Subscribe now

Here is what I think is going on

Every line of software anyone has ever shipped has actually been a group conversation.

When Stack Overflow provided the answer that unblocked you at 2 AM, it was written by someone whose name you forgot before you successfully pasted the snippet.

The library you imported was argued into existence on a mailing list you never read. The pattern you used was formalized in 1994 by the Gang of Four, who were themselves remixing Christopher Alexander’s 1977 book on architecture3.

The ticket that defined the feature was the residue of a customer complaint, forwarded by a sales rep, shaped by a PM, softened in Slack, and eventually compressed into a sentence small enough for Jira.

Some commit histories look like sole authorship.

But 99.9% of work is not sole-authored.

We have a useful fiction we call the solo maker

Woz soldering in the Los Altos garage. Carmack in the Texas pool house writing Quake. DHH extracting Rails from Basecamp on his laptop.

The lone genius hoodie poster above the desk. This fiction makes promotions legible. It made technical career ladders work. It flattered us and we let it.

All of those founders had co-founders. Woz, Jobs and the Homebrew Computer Club. Carmack, Romero and the whole id team. DHH, 37signals and every Ruby contributor upstream.

The myth stripped out the company around each one, because the myth needed a single name to hang the story on. We told it anyway and hung the posters.

Its sequel is currently being written. Altman has been floating the one-person billion-dollar company since 2024. His CEO friends, he told Alexis Ohanian in a conference interview, had a betting pool on when the first one would arrive4.

This line got reported, reshared and of course, believed. In late 2025 Altman said publicly he was “dangerously close” to calling the bet won. The solo unicorn is now someone who looks a lot like Pete Steinberger.

Except the solo founder is never truly solo.

Now, they’re standing on a training corpus written by millions of people, models built by thousands, infrastructure rented from five trillion-dollar firms, and the open-source stack underneath all of it. Their payroll might be one. The graph of people whose work is in the product has never been larger.

The myth rewrote itself for the new era with disregard for the math.

What is actually happening now, in these late hours, is translating. From a customer call in Q3. From a constraint a CTO set eighteen months ago. From a convention a principal engineer taught someone on their first job, who’d learned it from Fowler.

This translating might feel solo but the source is always other people.

There’s a reason the word stoa exists

Zeno of Citium taught philosophy around 300 BCE. He didn’t rent a private study. He taught on a public painted porch in the middle of Athens, where other people could overhear and push back. The school took its name from that porch.

Stoicism, before it was anything else, was a claim: thinking is something humans do together, out loud.

Software has always had versions of the same idea. Kent Beck and the XP movement spent decades arguing that pair programming was the natural form of the work. The industry nodded politely, then kept shipping solo-committer org charts, despite the social act that was already happening in Slack, standups, review comments, and hallway conversations.

Craft has moved.

Anyone shipping with agents knows this already. Put agents on a good codebase and they tend to replicate good practices. Put them on a bad one and they compound the bad. Craft has moved upstream, into taste, judgement, context, and the ability to tell the difference.

What got lost is the ritual that made us feel the craft.

The satisfaction of holding a hard refactor in your head for three hours before writing a line. The muscle memory of a language you grew up in. The private rhythm of fingers on keys. Those are real losses.

But some things weren’t ours to begin with. The authorship story. The idea that our commit was the first moment of creation. The idea that somewhere upstream of the keyboard was a spark of private genius that we alone lit. Those were always on loan from a culture that flattered us.

So what is still ours after the typing leaves?

What’s worth building.

What correct means in this context. Which tradeoff to accept. Who the customer is and what they would say. Whether the spec captures what the team actually decided or a softened version of it. Whether to ship or wait. Whether, given everything, this is the right move at all.

That was always the actual job.

Typing was just the evidence of the job.

Marcus Aurelius saw this two thousand years before he could have imagined a coding agent:

He wasn’t telling us to network. He was saying the private self is a late invention. The first fact about us is that we come in pairs, rows, pods.

We were never alone at the keyboard. We were always one part among others.

The developer at 11:56 PM, looking at the diff and feeling like a ghost, isn’t having a craft crisis.

They’re having the first honest conversation with their own work the job ever allowed. The ritual that hid the conversation just got cheap enough to stop.

Stoa was the name of the school because thinking needed company5. Make was never a solo verb. And AI didn’t end the age of the solo maker.

It ends the age of pretending we are alone.

🔌 Excited, terrified, and weirdly relieved to share the thing we've been living inside for seven months. No not an ice cream parlor. A room where makers meet… humans, agents, and all. withstoa.com. The door is open. Come in.

If you’ve ever read Thiel’s 0 to 1 you know its core thesis. Real progress comes from creating something new rather than copying what works. Agents are having their moment and a once blue ocean is a now a much darker shade of red.

In Tech having an agent or a chatbot or an agent and a chatbot is de rigueur.

Its why every product you once knew is slowly morphing into yet another homogenous input box beckoning you to “ask anything”.

But surprisingly, for many, it turns out that knowing what to ask is an incredibly intimidating problem.

Subscribe now

I wouldn’t have initially thought so given my boundless questioning. Like many I spend the lion’s share of my day doing just that. Typing, speaking, ranting and smashing my keyboard into small, lifeless but surprisingly “lifelike when they respond” input boxes.

And doing that for long enough has given me a lot of time to ponder. Is this the future of software? Yelling at command line interfaces in English and having “software” pop out the other end? Well of course, on one hand, yes. Writing hand crafted artisanal code is fast becoming a cottage industry.

But building software solo will never truly be a thing1. And yet everywhere you look these days there is a new “AI product” that promises just that.

You and the AI copilot get to cowork alone but “together” and make that thing that you’ll end up sharing: from zero to one. And look, there’s nothing particularly wrong with that.

But there is something missing.

I think one of the primary reasons Multiplayer AI is not yet everywhere is that people don’t quite understand what it should look like.

Where do you put it? In a group chat thread?

How does it work?

What’s the shape of the thing?

There is nothing yet to copy because it just doesn’t really exist.

And since most “computing experiences” are by definition personal there isn’t yet a shared substrate to build on. Your cursor is yours. Your chat is yours. Your context, yours. And it dies with the tab.

But building, really truly building, is never just personal.

Before computers, makers had workshops. Writers had smoke-filled rooms with typewriters you could hear across the hall. Musicians have studios. Every discipline that ever made anything has had a place where that making happened. A place everyone could see and reach at once.

The Greeks had a word for this.

A stoa. A covered walkway where people gathered to think together. Zeno taught philosophy in one. The whole school was named after the building. Not a curriculum. Not a founder. A place.

Because for two and a half thousand years we understood something we seem to have forgotten: the room precedes the idea. You don’t get to truly refined thought without a place to hold it. You don’t get to a decision without a surface to sketch it on. And you sure as hell don’t get to a thing a ton of people want without a space where many hands can touch it at once.

Nobody really meets anywhere anymore.

We just relay.

So what is the shape of multiplayer AI?

It is not just a group chat with a bot in it. That is relay, dressed up.

It is not just shared document with an agent scribbling in the margin.

Its not just Zoom with extra note taking apparatus that replace Granola. No, that’s just copying.

The shape is a room. A space with walls and a floor and your people and your agents all invited. A place where the conversation is the artifact. Where a decision made at minute six is captured before minute seven. Where the agent you summoned can see what everyone else sees and hear what was just said. Where the thing you’re building is right there “on the wall” alongside the reason you’re building it.

Not a chat. A workshop.

Not a copilot. A colleague.

Not a transcript. A record.

When you leave that room, it should remember. When you come back tomorrow, it is still there. When a new person shows up, they can read the walls. The context compounds, because the context was shared in the first place.

This is the thing that does not exist yet in the rest of your stack. This is the thing that is missing from every “AI product” that promises you and your copilot can ship from zero to one alone.

You can’t and you won’t because you never really could.

The next decade of software will not be won by the best solo builder with the best pet agent. It will be won by the teams who figured out how to build together, with agents, in one room.

A stoa was a porch. Open on one side to the market, closed on the other against the weather. You could step in off the street and join the argument already in progress. Someone would catch you up. Someone else would disagree. By the end of the afternoon you had a new idea and so did they, and none of you could quite remember whose it was first.

That was the point.

That is still the point.

And its why we think makers meet withstoa.com

Personal Coda

It’s been seven long but genuinely joyful months since my cofounders Jake, Sean and I decided to embark on this particular rung of our journey and build a team product. Looking back now, I’m not quite sure what we were thinking but we’ve sure learned a whole hell of a lot.

In October of last year we were riding high on the initial success of our extensions. A lot of people use them, love them and still do. But we came to terms with the fact that we were building the wrong thing2.

The problem that drives me, drives us, is one of shared mental alignment. Its the hardest problem to solve and has been even pre AI. But now the stakes are so much higher. It used to be hard to scrape together the talent to go zero to one. Now, it is decidedly not.

And so what do we do? Well what we did was scratch of own itch. We’re remote so when we met it was on Zoom or Tuple. And so, we rebuilt that. And when we planned it was in Gdocs. But agents don’t Gdoc. So we rebuilt that. And when we code we version our code. But pushing and pulling at rapid pace doesn’t quite work at the rate we move now, so we rebuilt that. And of course when we prompt, we do so solo. We can’t see what anyone is writing or thinking until after the fact. So we rebuilt that too.

The honest answer is that what Stoa is today fused and formed through molding and heavy interrogation. Organically. Since late last year we’ve lived in between it’s digital walls every day and have bent it to our will.

'And we will continue to bend it: to the will of many many more people that we know share the same same pains and desires we do.

We want our documents to be local first but inherently collaborative.

We want to share to share our thinking process by default.

We don’t want to fight against our tools that span video, voice, writing and agentic sessions. We want them to capture our intent.

We don’t hate meeting but when do we want to make sure our meetings work for us.

And we want the place where we spend our days to be durable not ephemeral.

And all of that really adds up to one thing. We wanted a place where makers could meet.

So we built one and will continuing building it.

The door’s open. Come in.

2

An internal gdoc excerpted from that time

I keyboard smashed “why isn’t this working” into Claude Code this afternoon. Then pasted the body of a Sentry issue as markdown below it. No context other than that. No theory. No sign I’d spent thirty seconds thinking about it first.

Claude dispatched subagents and consumed 100K tokens in read operations. It then gave me a diagnosis that led to a fast solution.

As I reflect on it, that’s the worst thing that could have happened.

Ten years ago, that question would have cost me. Google handed you ten pages of garbage for being that vague. You had to go back, think harder, try again. “My site is slow” got you nothing. “Nginx high TTFB on static assets behind reverse proxy” got you the fix in three minutes. The search box trained you to think. Not because thinking was noble, but because Google was useless if you didn’t.

Stack Overflow was worse. Post a lazy question and strangers shut it down in minutes. Duplicate. Unclear. Show us you tried. The site forced you to earn answers by proving you’d already done some thinking and searching.

The question was the work.

Subscribe now

LLMs skip all of that. They’re infinitely patient. Dump a mess of confusion at them and they’ll sort through it, guess what you meant, and hand you something useful (or at minimum glaze you into thinking it’s a good answer). They will rarely make you sharpen your thinking. They barely punish you for being lazy.

So you get lazier. And you don’t notice.

Every question has invisible parameters. Scope: the whole system or one component? Timeframe: happening now or used to work? Hypothesis: do you have one, or are you asking someone else to form one? What have you ruled out?

These aren’t decorative, they’re the substance. “I’m lost” and “I’m somewhere between 5th and 7th, facing east, near a red awning” are both requests for help. One respects the person you’re asking. The other makes them do all the work.

A good question is proof you already did some thinking. It shows what you know, frames what you don’t, and draws a line around the specific gap you need filled. A bad question dumps the entire cognitive load on whoever hears it.

Good questions don’t appear out of nowhere. There’s a process, and most are tempted to skip it.

First you notice. Something looks off. The data is slightly wrong. The system acts different on Tuesdays. Most people walk past these things all day.

Then you frame it. Systems problem or people problem? One-time event or pattern? This is where most people bail and open the chat window. Framing is uncomfortable because it forces you to commit to a perspective before you’re sure, to be wrong in a specific way instead of vague in a safe way.

Then you scope it. “Why is retention dropping?” is unanswerable. “Why are users who finish onboarding but never return within 48 hours churning at twice the rate?” — that has a fence around it. You can answer it. You can act on the answer.

Then you hypothesize. “Is retention dropping because onboarding doesn’t connect to a clear first-value moment?” Now you’re not requesting labor. You’re requesting judgment. This is a different thing entirely.

Notice, frame, scope, hypothesize. Every one of those steps builds your understanding whether or not anyone ever answers you. The thinking that produces the question is the point.

The cost of a bad question is approaching zero. We haven’t dealt with what that means.

The obvious part is that the muscle atrophies. Not overnight. Steadily, in the background, until you try to write a card by hand and your letters look like a kid’s.

The less obvious part: if you never struggle to form the question, you never build the mental model. The twenty minutes you spent figuring out how to phrase what was wrong wasn’t overhead. You were mapping the system, testing boundaries, sorting what you knew from what you didn’t. By the time you had the question, you were halfway to the answer. The struggle wasn’t a side effect of learning. It was the learning.

And this scales beyond individuals. For years, interviews were secretly question-asking contests. The candidate who asked “what are the consistency requirements?” told you they’d been burned by eventual consistency before. The question was the credential. If that skill decays across a generation, I don’t think we know what replaces it as a signal.

I use LLMs every day. They make me faster. That’s real.

But I’ve started pausing before I type. What do I know? What have I ruled out? What’s my theory? Not every time. Not for small stuff. But for problems I want to understand, not just solve.

Sometimes I write the full question and realize I don’t need to send it. Writing it answered it (or at least helped me restructure my lazy prompt). This used to happen on Stack Overflow when you’d draft a post and delete it because structuring the question revealed the answer. Rubber duck debugging. The duck doesn’t answer. You answer yourself because the question forced clarity.

The discipline now is to be your own duck.

When someone on your team asks a vague question, don’t answer it. Ask them what they’ve tried. Ask them what they think is happening. That’s mentorship now. Not transferring knowledge, but protecting the capacity to ask.

The friction of forming a good question was never a bug. It was how we learned to think clearly.

We removed the friction. Our tools no longer demand the work. So we have to demand it of ourselves. I believe that. I practice it most days. But the next generation of builder will grow up with a tool that answers every half-formed question instantly and kindly. They’ll never draft a Stack Overflow post and delete it. They’ll never be forced to sharpen a question just to get Google to cooperate. So where do they learn that the question was the point?

A company used to be a place where intelligence was scarce. You hired it. You gathered it. You arranged it into rooms and calendars and “teams,” and then you built elaborate social machinery to make it add up to something coherent. Titles, roadmaps, meetings, handoffs, approvals…. these were not cultural quirks. They were the coordination technologies required to turn scarce cognition into reliable action.

Cheap intelligence breaks that bargain.

Not because it makes people stupid. Because it makes action abundant. When anyone can generate a plan, a spec, a design, a pricing model, a prototype, a pile of code, a launch email, a competitive teardown, a forecast, a hiring rubric and when every employee and every agent can spin up competent output on demand, the constraint stops being “can we think of something?”

The constraint becomes: what will we commit to together?

Artifacts are now infinite. Commitments are not.

That's the part we don't have a good mental model for yet. We keep trying to bolt new capabilities onto old organizations, and then act surprised when the org starts to feel slower, not faster. Of course it does. You just multiplied the number of plausible moves by a hundred. You didn't multiply legitimacy, trust, or shared context.

Subscribe now

Part 1: Fifty Years of Coordination Problems

To understand what cheap intelligence disrupts, you have to understand what it was built on top of. The modern firm is a layered artifact of coordination technologies, each invented to solve the previous era’s bottleneck. The story of corporate collaboration over the past half-century is less a tale of progress than an ongoing negotiation between the scarcity of human attention and the ambition of collective action.

In 1937, Ronald Coase posed the question that would earn him a Nobel Prize: if markets are so efficient, why do firms exist at all? His answer was elegant:

Firms exist because transaction costs (the friction of finding, negotiating, and enforcing contracts on the open market) are often higher than the cost of managing those activities inside a hierarchy.

Oliver Williamson later expanded on this, adding the concepts of bounded rationality (our limited cognitive abilities) and opportunism (people acting in self-interest) to explain why firms organize the way they do.

This was the fundamental bargain: the firm as a structure that absorbs the costs of coordination so that individual humans don’t have to negotiate every interaction from scratch. Hierarchies were not just power structures but rather compression algorithms that reduce the combinatorial explosion of “everyone talks to everyone about everything” into something metabolizable.

Notice the pattern? Each era introduces a new coordination technology (hierarchy, process, digital tools, real-time messaging) that solves the previous constraint only to reveal a deeper one. The tools keep getting better at moving information. But none of them have gotten better at manufacturing agreement.

This brings us to the present, and to the most disruptive reframe of Coase’s original insight. As a recent California Management Review piece puts it1, AI doesn’t eliminate transaction costs but rather transforms them. The activities that comprise transaction costs (learning prices, negotiating terms, writing contracts, monitoring compliance) are precisely the tasks that AI can perform at near-zero marginal cost.

But when AI collapses the cost of production and analysis, what remains is the cost of trust, verification, and coordination.

Old friction disappears and new friction emerges.

Part 2: The Old Firm: A Scarcity Engine

In the pre-cheap-intelligence world, collaboration mostly meant “help me do the thing I can’t do alone.” Expertise was unevenly distributed. Learning was expensive. Writing and analysis were time-consuming. Building required specialized hands.

So coordination systems evolved to route scarce cognition to the right problems and prevent expensive mistakes. The hierarchy compressed decisions. The meeting concentrated attention. The memo formalized thinking. The approval gate caught errors before they propagated.

If intelligence is scarce, then the goal of collaboration is to share it.

The entire social architecture of the twentieth-century firm from org charts to quarterly reviews to the very concept of “alignment” was designed for this purpose.

It worked because the constraint was clear: we don’t have enough smart people, or enough hours, to think about everything.

So we specialize, and then we coordinate the specialists.

Cheap intelligence flips the gradient. Now the default state is not “we can’t think of a good answer.” It’s “we have ten good answers by lunch.” You won’t suffer from a lack of options.

You suffer from an excess of plausible futures.

This is why modern collaboration starts to feel like endless alignment, lightweight civil war, decision déjà vu, shipping things you can’t quite explain, and “everyone agrees” right up until it matters.

The organization hasn’t become irrational. It has become overstimulated.

When action is cheap, the cost of a wrong move doesn’t go down. Often it goes up, because the wrong move can now be made at scale and at speed. So the firm responds the way firms always respond to risk: it grows antibodies. Meetings. Reviews. Approvals. Committees. “Stakeholder” proliferation. Process disguised as prudence.

And then we say: “AI didn’t work. It slowed us down.”

No. AI revealed what the company actually is.

Part 3: The Thing Called “Collaboration” Was a Side Effect

We’ve long treated collaboration like a moral virtue: be a team player, communicate, align, be cross-functional.

But historically, collaboration was an emergent behavior produced by constraints. When work was hard and expensive, people had to coordinate carefully because mistakes were costly and iteration was slow.

Rob Cross, the leading academic researcher on organizational collaboration, has documented this paradox across 300 organizations: the time spent by managers and employees in collaborative activities has ballooned by fifty percent or more over two decades, yet in most cases, twenty to thirty-five percent of value-added collaborations come from only three to five percent of employees. The rest is overhead leading to meetings that don’t decide, messages that don’t clarify, “alignment” sessions that align nothing.

Huxham and Vangen2 formalized this dynamic in their theory of “collaborative advantage” and its shadow, “collaborative inertia” or the tendency for group work to produce slow, negligible progress rather than synergy. Their insight was spot on:

The difficulty isn’t getting people to collaborate.

It’s getting collaboration to produce outcomes rather than process.

When work becomes easy, collaboration stops being a nice-to-have. It becomes the core product. Because the real output of a firm is not artifacts. It’s commitments that lead to outcomes.

The (Actual) New Bottleneck is Legitimacy

In a world where any memo can be written, any prototype can be generated, any analysis can be conjured, the persuasive power of artifacts collapses. If everyone can produce a beautiful deck, then decks don’t convince. If everyone can generate competent code, then code doesn’t explain. If everyone can produce “research,” research doesn’t settle.

So organizations will drift toward politics. Not because people get worse, but because legitimacy becomes the scarce input. Legitimacy is what lets a group say:

1. This is the plan,

2. This is the priority,

3. This is what we mean, and

4. This is what we’re willing to be accountable for.

Cheap intelligence creates a perverse dynamic. Output increases. Context can easily fragmens. Trust gets stressed by the increased surface area of action. The system compensates with more process. Everyone feels slower and less agentic.

That’s the loop. You can’t “tool” your way out of it. You need a new paradigm for what coordination is.

Part 4: From Pyramids to Meshes

The old organization was a pyramid. Information flowed up; decisions flowed down. The hierarchy compressed the decision space—not because bosses were smarter, but because having a single point of authority at each level reduced the coordination cost of getting thousands of people to move in the same direction. As Coase himself argued, the firm would expand until the cost of organizing an additional transaction internally equaled the cost of carrying it out on the open market.

The new organization in my view will increasingly looks like a mesh network.

Agents sit alongside humans. Everyone can generate, analyze, and propose. The hierarchy hasn’t disappeared, but its function has shifted from routing intelligence to ratifying commitments.

The mesh needs protocols, not “culture.”

If the firm is an agreement machine, then "collaboration after cheap intelligence" is mostly about upgrading the mechanisms that produce agreement. Not more talking. Better primitives. And I think they come in roughly five parts:

1. Shift from conversations to commitments

Conversation alone do not scale. Commitments do. You want fewer “we aligned” moments and more explicit artifacts: what did we decide? Who owns it? What would make us change course? By when will we know? If it isn’t captured, it didn’t happen. Not because bureaucracy is good, but because memory is now the limiting reagent. When every participant can generate unlimited context, the only thing that anchors shared reality is the documented commitment.

2. Make intent the unit of coordination

When execution is cheap, the high-leverage work is specifying what outcome matters, what constraints apply, what tradeoffs are acceptable, and what “good” looks like. Protect the spec. Derive the rest. This inverts the traditional workflow where most energy went into execution and the spec was a rough sketch. Now the spec is the work and the implementation is the part that follows.

3. Design for reversibility, not certainty

Cheap intelligence increases the number of plausible paths. So stop pretending you can debate your way to the right one. Make smaller bets. Instrument them. Shorten time-to-truth. Collaboration becomes agreeing on the experiment and the acceptance criteria, not agreeing on the story.

4. Treat provenance as a first-class primitive

In an agent-rich world, “where did this come from?” becomes as important as “is it good?” Every important artifact should carry its source, the context it used, its assumptions, its confidence level, and its links to the decision it supports. I think it will become the best way to keep a shared reality when generation is infinite.

5. Replace “alignment” with protocols

“Alignment” is what you ask for when you don’t have a protocol. Protocols are boring, which is why they work:

• decision logs,

• explicit owners,

• escalation paths,

• crisp interfaces between teams,

• default-to-writing for anything that must persist.

The future firm looks less like a family and more like a network of services with shared values. Warm. Human. But unambiguous.

Part 5: The Economics Underneath

The Coasean frame makes the shift legible in economic terms. For nearly a century, firms have existed because internal coordination was cheaper than market contracting for complex, repeated tasks.

AI is now driving the cost of many market-side transactions such as searching, evaluating, drafting, monitoring toward zero. But rather than dissolving firms entirely, this shift is redefining what firms are for.

The tasks AI can cheapen are mostly the tasks of production and analysis. The tasks AI cannot (yet) cheapen are the tasks of trust-building, legitimacy-granting, and commitment-making. Those remain expensive because they are fundamentally social and political. They require humans who have skin in the game, reputations at stake, and relationships to maintain.

So the firm doesn’t disappear. It reconstitutes around the hard kernel of coordination that markets cannot efficiently provide: coherent commitment under uncertainty.

CODA

cheap intelligence doesn’t eliminate the need for companies. It clarifies why companies exist. Not to manufacture output. To manufacture coherent action which means coherent commitments under uncertainty, at scale, over time.

In my view, this all converges around a simple conclusion: the organizations that will thrive with AI won’t be the ones generating the most. They’ll be the ones that have built the tightest feedback loops between generation and commitment. They’ll replace sprawling alignment rituals with crisp protocols. They’ll make intent legible and provenance transparent. They’ll accept that the cheap layers of the old collaboration stack (artifacts, opinions, even analyses) are no longer differentiators.

What will differentiate is the ability to decide and commit at the speed the technology enables.

If you keep treating collaboration like “communication,” you’ll drown in output and starve for agreement.

If you treat collaboration as the design of commitment-making systems, you get something rare in 2026: A company that can move quickly and know what it’s doing.

Somewhere in your company right at this exact moment, a great idea is dying on schedule. Not because anyone explicitly rejected it but rather because “the process” hasn’t finished saying not yet.

A lot of modern work doesn’t produce things, it produces evidence. Evidence that the right people were consulted. Evidence that risk was acknowledged. Evidence that there are throats to choke.

Intent to do something enters an organization and comes out the other side as action… eventually. In between, it gets translated through the permission pipeline

The translation layer is massive. It employs entire departments. Most of it exists not because coordination is genuinely needed but rather because delay is how organizations metabolize fear without admitting they’re afraid.

Delay gives people time to object.

Delay gives politics time to work.

Delay gives responsibility time to diffuse until no single person holds the bag.

You know the feeling. A competitor stumbles publicly and your marketing lead sees a three-week window to run a campaign against it. Sharp angle, right audience, real upside. They write the brief in an afternoon. Then the pilgrimage starts:

1. Route it through brand for tone review,

2. Legal for claims approval,

3. Demand gen for budget sign-off,

4. The VP for “visibility,”

5. Finance for the PO and procurement for the vendor contract.

Four weeks later the campaign is approved. But window closed nine days ago. Nobody killed it. Nobody even said no. The process said not yet until not yet became too late.

You’ve watched this happen. You wanted to scream. You didn’t. Because you knew: the pipeline isn’t protecting the company. It’s protecting individuals from the consequence of being the one who said yes.

Subscribe now

Now drop in agents.

Give one that campaign brief and it does the annoying middle: drafts the copy in brand voice, pulls the competitive data, mocks up the landing page, routes the legal review, generates the media plan with three budget scenarios, files the PO. The translation layer that took four weeks compresses into days.

Everyone who used to be “in the loop” by default is now in the loop only if a gate demands it. The time buffer is gone. The political breathing room is gone. The comfortable ambiguity about who decided, yea that too, gone.

Most people may stop here. Compression eliminates waste. Everyone wins.

They’re wrong though. Compression doesn’t eliminate the fear. It makes the fear visible.

Bureaucracy isn’t waste, it’s ceremony.

The meeting is a ritual that says: we saw the risk, we shared the burden, we did the responsible thing. Compress the coordination layer and the ceremony disappears. The fear it was managing doesn’t. It just stops having a place to go.

So it goes somewhere predictable: more gates, more policy, more “human review,” more signatures. Not because people hate speed. Because people hate holding the bag when speed produces a mistake.

This is why every enterprise AI deployment hits the same wall. The technology compresses the pipeline. The organization re-inflates it. You automated the paperwork but not the anxiety.

You’ve seen this too. A team adopts a tool that should cut weeks off the cycle and within a quarter, new process fills every hour the tool freed up. Not because anyone decided to. Fear is a gas that expands to fill the container.

When the pipeline collapses, authority concentrates in two places:

1. The people who still say yes or no, and

2. The people who decide what requires asking in the first place.

The second group is the sleeper power center.

The future will be shaped by defaults. What runs automatically. What requires a tap. What requires a signature. What triggers a pause.

Most organizations may treat these as “process.” That’s a mistake. Defaults are policy. Gates are power. Whoever configures the gates is making the real decisions about how fast you’re allowed to move.

When the busywork of coordination disappears, the real coordination ( the kind nobody had a meeting template for) doesn’t get cheaper. It becomes much more expesnive AND unavoidable.

Judgment under uncertainty. Taste. Responsibility. Trust. Narrative.

These aren’t soft skills. They’re what’s left when the permission pipeline stops being a full-time job for half the company.

The impediment was never the campaign. It was the fear dressed up as process and the process dressed up as work. You felt it every time you sat in that meeting. You feel it now.

The permission pipeline will collapse. The question underneath it is who bears the risk when we move fast was always there. The process just let everyone pretend it wasn’t.

That pretending is over.

At one of my jobs, we spent three months debating whether to build a feature.

Not building it. Debating whether to build it. First we estimated the potential ARR we thought we’d get. Then we debated the estimate. Then we re-estimated it with different assumptions. Then we estimated the engineering hours. Then we debated those estimates. Then we had a meeting to reconcile the ARR estimate with the engineering estimate to determine if the ROI justified putting it on the roadmap. Then we debated the roadmap.

Three months. Exposed to the full salary cost of every person in every one of those rooms just in order to decide whether or not to do the thing.

The people in those rooms were not stupid. That is what made it hurt. They were smart, capable people who had been turned into professional guessers. Their job was not to build. It was to estimate, debate, and justify. Everyone in the room knew the estimate was a fiction. We built it anyway because the system needed a number before we’d let anyone touch the code.

In the world I live in now, I would have just built it. In a week or less and shipped it. Then known.

But that was not an option then. Building anything took so long and cost so much that you had to be sure before you started. So you spent a quarter making a guess and calling it “your plan.”

Subscribe now

You and I know that every company is shaped by its constraints. This is so obvious that nobody says it out loud.

The number of people on a team is not often determined by the complexity of the problem. It is determined by last year’s budget plus whatever headcount someone managed to negotiate. The org chart is not a map of the work. It is a map of decisions that few remember making.

A product with a mobile app, a web app, a backend, and an external API needs at minimum four people who can hold those things in their heads at the same time. Add a design system. Add more infrastructure. Add a PM to coordinate the humans. Add a manager to keep the PM sane. Add a second manager because the first one now has ten reports. Soon you are at fifteen people and you have not added a single feature.

You have added the capacity to add features.

This is the container. Every company builds one. It gets sized for the work, and then the work is sized for the container.

Nobody designs their container on purpose. It accretes.

But first maybe you start with three people who can do everything. Then you hire a fourth because someone needs to own the thing the other three keep dropping. Then a fifth because the fourth created a coordination problem that did not exist when there were three. Then a sixth because the fifth needs someone to talk to about the coordination problem.

By the time you have thirty people you have real structure. Maybe HR? Definitely standups and sprint planning and soon quarterly reviews. Career ladders. Comp bands. All of it reasonable. All of it necessary.

None of it “the work.”

You know this. You have lived it. You have sat in rooms where smart people spent an hour talking about talking about the work, and you looked around and thought: this can’t be right.

And then you stopped looking around. You got used to it. You learned to call it process. You started defending it to new hires who asked why everything took so long. That is the part that should sting. Not that the system is broken, but that you made peace with it.

It isn’t right. But it is organizational physics.

I was Chief Product Officer at a company that had hundreds of engineers. The product was good. The people mostly talented. And I would estimate that less than thirty percent of the total organizational energy went toward making the product better for customers.

Thirty percent.

The rest went toward coordination, alignment, communication, planning, re-planning, and the dreaded meetings about the meetings.

That number is not a failure of execution. It is not a management problem you solve with better standups. It is the cost of running a human system at scale. Coordination costs grow faster than headcount. Communication complexity is n-squared. Every person you add creates new edges in the graph. The work does not get harder. The container gets harder.

I’ve spent twenty years inside containers.

At Google, at Dropbox, at GitHub, at Pluralsight. Big orgs, talented people, impactful work. And at every one, the same pattern: the roadmap was primarily shaped by what the container could produce.

The container set the ceiling.

The roadmap filled the container.

The metrics measured how well the container performed.

Nobody measured whether the container was the right shape.

Few leaders can really ask: Is the container the right size, or is it the only size we know how to build?

Those are different questions. The first is about optimization and the second is about both assumptions and internal honesty.

Most operational thinking is optimization. Better processes. Better tools. Fewer meetings or better meetings. All good. All necessary. All operating inside a fixed assumption: this is how many people it takes to build this thing.

But what if that assumption is mostly wrong? Not just slightly wrong but structurally wrong. What if the size of every software company was always set by execution constraints, not by the complexity of the problems being solved?

If that were true, the right response would not be better processes. It would be questioning whether the container should exist in its current form at all.

In the old world, ninety percent of the work was execution and ten percent was judgment.

Knowing what to build took a week. Building it took a year. So you hired for the year, and the organization took the shape of the year.

That ratio was the container’s foundation. Not the complexity of the problems. Not the ambition of the roadmap. The ratio. In relative terms, judgment was cheap. Execution was expensive. Every company on earth (at least in Tech) was organized around that fact.

What if the ratio reversed?

What if someone built the product surface of a fifty plus person company with a handful of people in five months?

That is not a hypothetical. We are launching in April. Just a handful of people. I am one of them.

Preview the product here. I co-founded our company, SpecStory, with Jake and Sean in late 2024.

AI.

The reason this was possible is the reason this meditation has not mentioned the word until now. Not because management theory changed (we talk to one another daily). Not because someone invented a better planning process (we use a weekly markdown file). Because the execution constraints that determined the shape of every software company for the last twenty years are fundamentally different. The container has always been a function of how many humans it took to do the work. And when that number changes so does everything else.

Building this product has been a crucible.

The hard part was the same thing it has always been: knowing what to build, why it matters, and which tradeoffs to accept. Intent. Context. Judgment. Those did not get easier. They got more important, because the cost of executing a bad idea dropped to near zero and it’s easy to build the wrong thing faster than ever before.

We’ve been building in the new ratio. Most of the work has been deciding what to build, how it should feel and how it should fit. The execution has followed.

Now. Here is where most people hear this story and jump to the wrong conclusion.

They hear “a handful of people built what fifty used to build” and they think: so we need fewer people.

That is the lazy version. And it’s wrong.

Think about what people in a fifty-person engineering org actually spend their days on. Translating requirements into tickets. Breaking work into pieces small enough to hand off. Sitting in standups to synchronize those pieces. Reviewing code not because it really needs a review but because no single person has enough context to ship without it. Writing status updates. Reading status updates. Negotiating what gets built next quarter because building anything takes so long that you have to choose carefully.

That is not the work. That is the container.

Now remove those constraints. Not the people. The constraints.

When execution is AI fast, you do not need to break work into twelve tickets across four engineers. One person can hold the whole thing. If one person holds the whole thing, you do not need the same type of standup. If you do not need the standup, you do not need someone to run the standup. If building something takes days instead of months, you do not need a quarterly planning process to decide what to build. You just build it and see.

What you get is not a smaller team. You get a team that does different work.

The engineer who used to own one microservice now owns an entire product surface. The PM who used to write tickets now is involved hands on making and executing product decisions. The designer who used to hand off mockups now ships the design. Everyone moves closer to the work that matters and further from the process that existed because humans are slow and need coordination.

This is the hard part. Not cutting. Redesigning.

Most leaders, when they hear that execution constraints are possible to collapse, reach for the obvious lever: same work, fewer people. They have not built anything with these tools. They have not sat with an agent for a weekend and felt the floor move. They read a breathless LinkedIn post, skimmed a McKinsey deck, and concluded that AI means headcount cuts. That is not a strategy. That is a spreadsheet reflex. And all it does is shrink the old container. Same assumptions about scope, speed, and ambition. Fewer people carrying them.

They burn out.

You lose.

The better version is harder. If your team can now move at three times the speed, do not cut two thirds of them. Ask what you would build if you could build three times as much. Ask what you never attempted because the coordination cost made it infeasible. Ask every person on the team what they would do if nothing stood between them and the work.

Then redesign the container around the answers.

The question is not headcount. It is ambition.

The container was always a ceiling on what you could attempt. The ceiling just moved. The interesting question is not how to run the old org with fewer people. It is what you build now that the ceiling is gone.

That question is uncomfortable. Not because it threatens jobs. Because it threatens assumptions. It forces you to admit that the roadmap was never a map of what customers truly and honestly needed or deserved. It was a map of what the container could produce. And now your container could produce almost anything.

Most companies will not ask this question. They will optimize the old container. Better metrics. Better tooling. Fifteen percent improvement. Dashboard green.

And somewhere, while they are doing that, a small team is building the thing their fifty-person (or hundred person) org is planning to start next quarter. Not because they have fewer people. Because they have fewer constraints. And they are using that freedom to attempt things the old container would never allow.

They will not estimate the ARR first. They will not debate the engineering hours. They will not reconcile the estimates in a meeting and then debate the roadmap.

They will just build it. Ship it. And know.

The container is changing shape. You can redesign it or you can keep optimizing the one you have until you're made irrelevant.