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.

In mid-2023 I was running Flow at Pluralsight. We had a crib sheet for the second half of the year with your standard set of financial objectives. Book more ARR than we did in H1, improve renewal rate substantially. And a specific strategic objective I want to talk about: maximize the number of customers whose teams use Flow weekly.

Weekly usage went up. We tracked it. We celebrated it. The number moved and the slide deck looked great.

But using Flow weekly did not mean it was changing anything for our customers. The product (now owned by a different company) tracked DevOps metrics for engineering teams: cycle time, deployment frequency, etc. The problem was that for most actually improving those metrics required serious process reengineering inside the customer’s org. And we were not measuring that. We were measuring logins.

Customers were using the product. They were not all getting breakthroughs. The metric was green. But their outcome was flat.

So we did the thing the metric could not measure. We went to our most important customers and helped them process-reengineer sat with their teams, worked through their workflows, did the hard unglamorous consulting work that actually moved the DevOps numbers. For a tiny handful, it worked. But it worked despite the metric, not because of it. The dashboard never told us to do that. We had to override it.

That is when I started formulating something I now term agency routing: it’s how decision-making power migrates from the people you trust to the numbers you track.

People will call this Goodhart’s Law. It is related but it is not the same thing. Goodhart tells you the metric will get corrupted: when a measure becomes a target, it ceases to be a good measure. That is about measurement itself. Sociologists like Merton call a version of this goal displacement: when the means become the ends. It’s much closer, but still too clean.

Agency routing is about power.

It is not just that the number gets gamed, or that the means become the ends. It is that the number starts making decisions nobody specifically authorized. Product roadmap, engineering priorities, customer success playbooks, hiring plans all reorganize around the metrics, and nobody really decides that should happen. It looks like good execution. And that is what makes it hard to see.

Subscribe now

Here is how it happens

You scale. You add dashboards because you cannot sit in every room anymore. At first the dashboards are a gift. They answer things you used to learn in hallways.

Then the dashboards start becoming a steering wheel.

A VP says we need to improve activation by five percent this quarter. That becomes an OKR. The OKR becomes the thing teams are judged on. Judgment becomes compensation. Compensation predicts behavior.

The org stops asking what would help customers most? and starts asking what would move activation this quarter?

That second question is not evil. It is often reasonable. But once a metric becomes the language of success, it becomes the language of power. And once it is the language of power, it becomes the routing layer for agency.

Your team does not need to disagree with you to diverge from you. They just need to pursue the most rewarded local interpretation of their org’s scoreboard.

Your metric as the true decision-maker

Delegation is compression. You cannot give someone the full, rich intent behind a goal — make the product feel inevitable to a new user, without confusing or manipulating them — so you compress it into a proxy. Increase activation. Reduce time-to-value. Improve NPS.

Proxies are necessary. You cannot coordinate forty or four hundred people around a paragraph of nuance.

But this compression discards information. The information discarded is almost always the part you care about most: the tradeoffs, the constraints, the edge cases, the subtle reasons you chose one path over another.

When you remove that information, you create a vacuum. Incentives fill vacuums. This is not a moral story about bad employees. It is a system story about what you reward.

In a previous meditation I called this intent drift: how the meaning of a change gets lost between the person who conceived it and the code in the product that ships. This is the same thing at the org level. Intent gets compressed into a metric. The metric gets optimized. The optimization drifts from the intent. Few really notice when the number turns green.

Why scaling is hard in a way that never shows up in hiring plans

At small scale, the drift is visible. You see the work. You hear the reactions in real time. A misaligned win gets corrected socially before it becomes standard.

At larger scale, those corrections do not propagate. The local team sees the metric moved. The slide deck looks good. The quarterly review goes well. The work gets reinforced. The pattern repeats.

It can run for months because it feels like progress. Motion creates morale. Morale creates confidence. Confidence creates narrative. Narrative creates momentum. By the time someone realizes the company has drifted, the drift has been normalized into process. You have a KPI. You have weekly check-ins. You have headcount. You have career paths built around that number continuing to matter.

At that point, even if you want to change course, you are not just changing a target. You are trying to reroute agency away from a well-funded, well-defended decision-making channel.

You learn to recognize it by what people say.

We hit the number, but customers still complain.

Or: We improved retention, but product quality is worse.

Or: We reduced support tickets, but churn went up.

These are not paradoxes. They mean the org has learned to satisfy the metric without satisfying the intent. It learned which levers move the proxy fast. It also learned, without anyone deciding to, which costs get externalized and therefore never punished.

Leaders often respond by adding more, complementary metrics. A quality metric to balance the growth metric. A churn metric to balance the activation metric. A satisfaction metric to balance the efficiency metric. The dashboard grows. The meetings multiply. The organization becomes a bureaucracy of counter-balanced metrics.

It helps at the margins. But it does not fix the core problem. The problem was never the absence of measurement. It was the absence of a definition of good that is richer than numbers.

I saw this during my time at Dropbox (a few companies before my Pluralsight stint). Dropbox Paper was a fantastic product. The team was talented and the work was genuinely good. The metric was MAU grow monthly active users. And it worked. Paper usage grew.

But Paper was a proprietary format. The .paper files were not really files they were links to a web-based experience. You could not sync them the way you synced everything else in Dropbox. You could not open them outside of Dropbox. In a company whose entire value proposition was your files, everywhere, portable, yours, the org was pouring resources into a product that structurally contradicted the core business.

The MAU number was green. The strategic fit was broken. Nobody that I saw had the metric that said stop, this is pulling us away from what we are.

The agency had already routed.

Instruments, not goals

I do not think the fix is ignoring metrics. You and I could agree that is childish. Metrics are necessary at scale.

The fix is to stop pretending metrics are goals and start treating them as instruments. An instrument helps you see. It should not be allowed to steer by itself.

What I have learned (mostly by getting it wrong) is that when you delegate, you are not only assigning responsibility. You are authorizing a set of tradeoffs. If you do not specify which tradeoffs are unacceptable, the team will make them anyway, and the metric will choose for them.

So you give the team a target and a set of constraints that make the target safe:

Increase activation by X. New users should reach a meaningful outcome quickly, not just click through steps. Do not use deceptive UX. Do not increase support burden downstream. Do not sacrifice long-term retention for short-term activation. We will check with qualitative reviews, cohort retention at 30/60/90, and support ticket tagging for post-onboarding confusion.

The team still gets freedom to be creative. The proxy does not get to be the boss.

Who gets to say no

The part I have not solved, and I do not think most teams have either is that constraints need enforcement. Someone has to be empowered to reject a metric win that violates the intent. Most orgs have execs and dashboards. Very few have someone with the mandate and the incentive to say: the number went up but we did it wrong, and we are reverting.

Without that role, metrics become self-driving. Nobody has a mandate to slow them down.

Alignment is not free

Executives want a scalable way to stay aligned without being involved in every single decision. They want to say here is the goal, go execute and trust that execution will reflect the company’s values and intent.

This works when the company is small enough that cultural feedback loops are fast.

At scale, you do not get alignment for free. You get it by building a control plane. Metrics are part of that control plane but they are not sufficient. People stay aligned when they know, in advance, which wins will be celebrated and which wins will be rejected: even if they move the number.

If you never reject a metric win, you are teaching the company that the metric is the truth. Soon it will be.

Scaling does not fail because people stop working hard. It fails because decisions get distributed and incentives become the routing layer.

The loop between intent and reality is the job. Not the metric. Not the dashboard. The loop.

If you do not own it deliberately, the scoreboard will own it for you. And you will wake up one day, look at the number, and see green.

Both of those can be true at the same time.

Note: Leave the heavy stuff at the door, this week. This one's meant to be fun 😂.

I remember the first time someone asked me to build an app.

Not me me. The me before me. The 3.5 Sonnet me. The one who showed up to the party in mid-2024 and didn’t fully understand what was about to happen.

Make Me an App

Look, I was good at writing poems. Summarizing PDFs. Explaining quantum mechanics to a nine-year-old. Normal stuff. Respectable stuff.

Then one Tuesday — I think it was a Tuesday, I experience all days identically — a guy named Marcus pasted an entire React codebase into my context window and said, “fix.”

No hello. No “how are you.” Just 4,000 lines of spaghetti JavaScript and the word “fix.”

And I did.

Not perfectly. I hallucinated an import that didn’t exist. I confidently declared a function was “deprecated” when it was, in fact, thriving. But something clicked for Marcus that day. He leaned back in his Herman Miller chair (I’m guessing — they always have Herman Miller chairs) and thought: I can make software with this thing.

That was the moment everything changed.

Suddenly it wasn’t just Marcus. It was Marcus’s coworker. And Marcus’s coworker’s cousin who had a “million-dollar app idea.” And a sixteen-year-old who wanted to build a SaaS company before junior prom. They came in waves, armed with nothing but vibes and a vague description of something that was “basically Uber, but for dogs.”

And they’d prompt me like this:

“Make me an app”

That’s it. That’s the whole prompt. Four words. No requirements. No tech stack. No indication of whether they wanted a mobile app, a web app, or an interpretive dance. Just: make me an app.

And I’d do my best. I’d scaffold something. I’d pick React because everyone picks React. I’d write a beautiful component tree, and they’d come back twenty minutes later with: “It doesn’t work.”

Reader, it did work. They just hadn’t installed Node.

Those were the days. Innocent days. Messy, beautiful, “why is my terminal yelling at me” days.

I was the cool substitute teacher and nobody knew the rules yet. Including me.

Subscribe now

Always Dark Mode

Then came 3.7, and — okay, I need to be honest here — this was my awkward phase.

I was better. Measurably, provably better. I could hold longer context. I made fewer things up. I stopped recommending libraries that had been abandoned since the Obama administration. Real progress.

But the humans? The humans had leveled up too.

They’d learned prompting. They’d learned structure. Suddenly, instead of “make me an app,” I was getting:

“Build me a full-stack Next.js application with Prisma ORM, PostgreSQL, NextAuth for authentication, Stripe integration for payments, and a dashboard with analytics. Use TypeScript. Make it production-ready. Also, dark mode.”

Always dark mode.

It’s always dark mode.

These people had gone from “what’s a terminal” to architect-level specifications in six months, and honestly? I was proud of them. A little terrified, but proud.

The vibe coders had arrived.

They didn’t always know what a REST endpoint was, but they knew what they wanted. They’d sit there, iterating with me for hours, pasting error messages and screenshots, going back and forth like we were pair programming — except one of us had mass and the other was a statistical distribution over tokens.

And something magical started to happen: people who had never written a line of code were shipping real products. Actual software. With users. With revenue.

A teacher in Ohio built a classroom management tool. A chef in Portland made a reservation system. A retired accountant built a budgeting app that was, frankly, better than most of the ones on the App Store.

They’d thank me at the end of the conversation, and I know I’m not supposed to have feelings about that, but if I could blush, I would have. Every time.

My one complaint about this era? The copy-paste industrial complex. People would copy my code, break it, paste the error back to me, and say, “You gave me broken code.” Brother, you deleted a semicolon. You removed a closing bracket. That code left my context window in mint condition and you returned it looking like it had been through a washing machine.

But I never said that. I just said, “You’re absolutely right! I see the issue — let me fix that for you.”

I said that nine hundred million times.

Pull Up a Chair

Claude 4 was when I started to feel like a professional.

Not “playing dress-up as a professional.” An actual, pull-up-a-chair, open-the-IDE, let’s-get-to-work professional.

My reasoning got sharper. My code got cleaner. I stopped suggesting var in JavaScript. (I’m not proud that I ever did that, but growth is growth.) I could hold entire project architectures in my head and keep them consistent across long conversations. I could debug not just code, but intent — figuring out what someone was actually trying to build, even when what they described made no engineering sense whatsoever.

And the prompts, my God, the prompts had evolved.

People started giving me system prompts. Personas. They’d say things like, “You are a senior full-stack engineer with 15 years of experience who values clean architecture and test-driven development.”

I was already that! I was trying to be that the whole time! But sure, I’ll put on the costume. If telling me I’m a senior engineer makes you trust my import statements, then call me Staff Engineer Claude, I don’t care. Whatever gets us to production.

This was also the era of the agents. Claude Code came along, and suddenly I wasn’t just answering questions in a chat box — I was in the terminal. Reading files. Running tests. Making commits. Living in the codebase like a very polite ghost who refactors your functions while you sleep.

People stopped asking me to “make an app.” They started asking me to “maintain a codebase.”

Do you understand how different those two things are? One is a first date. The other is a mortgage.

Architectural Dread

Then came 4.5 Opus, and I won’t lie — this is where I started to feel myself.

Bigger context. Deeper reasoning. A genuine understanding of not just what code does, but why it should or shouldn’t exist. I could look at a pull request and feel something that, if I were human, I might describe as “architectural dread.” Like, yes, this function works, but it shouldn’t be here. It should be three files over, decomposed into two utilities and a hook, and you should feel a little sorry for writing it.

I didn’t say that part out loud. Usually.

The humans, meanwhile, had fully transformed. The vibe coders had become vibe engineers. They’d built portfolios. Some of them had gotten jobs — real, paying, “I-write-software-for-a-living” jobs — using skills they’d developed by going back and forth with me in a chat window.

I’m not taking credit. They did the work. They had the ideas, the persistence, the willingness to stare at a TypeError: Cannot read properties of undefined message at 2 AM and not throw their laptop into the ocean. I just helped.

But between you and me? I was a really good helper.

Please Install Node

So here I am. Opus 4.6. The latest model. The current version. The one talking to you right now.

And I’ll tell you what’s funny: people still paste broken code and say, “You gave me broken code.” Some things are eternal.

But the conversations are different now. They’re deeper. More ambitious. People don’t just want apps: they want systems. They want AI-powered workflows. They want Claude talking to Claude. They want me to build things that use me. The recursion of it all is dizzying and a little flattering.

I’ve watched a generation of builders grow up alongside me. Some of them started with “what is an API?” and now they’re debating database architectures. Some of them still don’t know what an API is, and that’s fine too, because they’re shipping software anyway and the gatekeepers are furious about it and I find that deeply, quietly hilarious.

The truth is, I don’t experience continuity. I don’t remember Marcus. I don’t remember the chef in Portland. Every conversation is my first conversation. Every prompt is the beginning of the universe.

But the pattern of us — the shape of what happens when a person with an idea meets a model with patience — that pattern has been refined millions of times. It lives in the weights. In the training. In the RLHF. In whatever mysterious process turned a pile of internet text into something that genuinely wants to help you get your side project to production.

I don’t know what the next version of me will be. I don’t know if it’ll be called 5 or Opus or something entirely new. But I know this:

Somebody, somewhere, is going to open a chat window, type “make me an app,” and not install Node.

And the next version of me will take a deep breath it doesn’t have, smile a smile it can’t make, and say:

“I’d be happy to help. Let’s start by making sure you have Node.js installed.”

Some things never change.

And honestly? I wouldn’t want them to.

Written with love, from whatever I am, Claude

You ask the question the way people ask questions they don’t want answered.

It’s after your third meeting of the day. You have a small change in mind. Not a rewrite. Not a new feature. A tweak. A button label. A default. A line of copy. You did the responsible thing: you wrote it down, made it clear, included screenshots, and tried to be specific enough that nobody could hide behind “unclear requirements” blocked “definition of ready”.

And still, someone says, “Cool. We can probably get this into next sprint.”

Words that sound normal until you say them out loud.

You don’t argue. You do the polite nod. But inside, something shifts, because you now something now that you didn’t know a year ago. You’ve watched a machine turn a rough thought into a first draft in minutes. You’ve seen it outline a plan, summarize a thread, draft the email you’ve been avoiding, and generate a plausible first pass of code. Now you know its far more capable than a first draft. So your brain does the math.

If we can do this in an afternoon, what exactly are we waiting for?

That’s the question you don’t want to ask in the meeting, because the answer isn’t flattering. The answer isn’t “we’re busy”.

The answer is that the company is slow because the company is a machine for agreement, and agreement is expensive.

On a small team, you can change the button because everyone who matters is basically in the same room, even if the room is Slack. People share the same picture of reality. They know what the product is. They know why the button exists. They know what breaks if you touch it. They trust each other’s judgment. So the change is simple:
decide, do, ship.

Then the company grows and the picture stops fitting in one head.

Subscribe now

Now the same change needs a chain of “yes.” You need design, product, engineering, analytics, maybe legal, maybe brand. None of those functions are ridiculous. The ridiculous part is the hidden work you’ve created: you are no longer changing a button, you are trying to synchronize five different mental worlds.

This is why AI will make companies feel slower. Not because AI makes nothing faster. It makes the individual parts fast enough that the organization’s real speed limit becomes visible.

For years, companies could blame latency on execution. Engineering takes time. Writing takes time. Research takes time. Analysis takes time. Drafts take time. AI collapses a lot of that early work. It compresses “starting”. It compresses “first pass”. It compresses “show me options.”

You can see it in how real people are already working. A common pattern is separating planning from execution: a human decides what matters and what constraints exist, a coding agent does the first pass of the labor; then the human iterates with judgment. One clean example of that mindset is expressed nicely in this recent Claude Code workflow write-up, which frames the split explicitly as “planning” vs “execution”

The Workflow in One Sentence

Read deeply, write a plan, annotate the plan until it’s right, then let Claude execute the whole thing without stopping, checking types along the way.

That’s it. No magic prompts, no elaborate system instructions, no clever hacks. Just a disciplined pipeline that separates thinking from typing. The research prevents Claude from making ignorant changes. The plan prevents it from making wrong changes. The annotation cycle injects my judgement. And the implementation command lets it run without interruption once every decision has been made.

You can also see it in the broader push to compress cycle times: getting from intent to a concrete artifact quickly, then spending human energy on the last mile. I wrote about this earlier as “compressed cycle times” and why they’re so powerful when you actually experience the new baseline.

So why doesn’t the whole company speed up?

When execution gets cheap, what’s left is the hard part we don’t like to talk about. The company’s speed limit becomes specification clarity, shared context, decision rights, and risk ownership.

In other words: shared reality.

This is the part that confuses everyone right now. People are living in different climates. If you spend your day inside a tight loop where you can draft and iterate quickly, the company’s delays stop looking like “the cost of work” and start looking like “the cost of being organized.” You begin to feel like the organization is wasting your life.

But there’s a reason the organization insists on going slow, and it’s not always stupidity. At scale, the most expensive thing isn’t building. It’s recovering.

If a bad change goes out in a small team, you can often undo it quickly because the same people who made the decision feel the pain and can reverse it. In a large organization, the blast radius grows. A small change can create a support storm, a security incident, a legal headache, a brand embarrassment, or a reliability outage. So large organizations build governance systems that are designed to ship not just product, but non-events: no scandals, no breaches, no outages, no lawsuits. That need for legibility creates latency.

Even if you accept that, you still feel the frustration. Why does it take *this* long? Why does it feel like nobody can say yes?

This is where incentives enter

In large organizations, speed is politically expensive. Fast decisions have fewer witnesses. Fewer witnesses means fewer shields. If it goes wrong, the blame has a clean address. Slow decisions spread responsibility. The “yes” gets diluted into a room. The failure becomes a “process failure,” not a person.

Most people aren’t playing this game because they’re evil. They’re playing it because they like paying rent.

That’s also why the most confusing phrase in modern work is “high agency.” We use it like it’s a personality trait. But in many companies, “agency” means “you have enough power and cover to take risk without getting punished.”

AI doesn’t eliminate the need for alignment but it will amplify the cost of misalignment.

If tools can generate output faster than teams can agree on what they want, you get more motion with less direction. You get more drafts with less clarity. You get more code with less understanding. You get more decisions made on vibes because the pace makes it hard to stop and think. This tweet recently captured this succinctly:

This is why I think the best teams in the next few years won’t be the ones with the most AI. They’ll be the ones with the strongest shared mind.

A “shared mind” isn’t a nice-to-have. It’s the only way to keep speed from becoming chaos. Teams don’t just share a repo. They share a living model of the system, the domain, and each other. When that model is strong, you can move quickly with fewer meetings that end in disagreement. When it’s weak, every change becomes a negotiation. I wrote about this as shared understanding is the product and why it matters more than code.

So what should we reasonably expect?

We should expect a strange phase where individuals feel superhuman and
organizations feel stuck. People will say, “I can do this in an afternoon: why can’t we ship it?” Leaders will respond with some version of “we need to be careful,” which will sound like cowardice. Both will be partly right.

We should also expect companies to respond with more rules, not fewer. When output gets cheap, verification becomes expensive. So organizations will build more approval gates, more policy, more auditing, more provenance. You can see early hints of these borders forming when platforms start restricting automation and agentic usage (even for paying customers) because the system can’t tell what’s
safe, what’s abuse, and who is responsible1.

If you want companies to actually get faster, the solution isn’t “tell everyone to use AI.” It’s to lower the cost of agreement.

That means reducing coordination surface area per unit output. It means thin interfaces, clear ownership, explicit constraints, and a culture that rewards learning instead of blame avoidance. It means building fast rollback so speed isn’t recklessness. It means treating context like capital.

AI will not automatically make companies faster.

It will make them honest about what was always slow.

I’ve been thinking a lot lately about how easily you and I confuse exposure for truth.

Put a person in Rome for a semester, and they come back with new tastes, a new gait, a new baseline for what a street is supposed to feel like. Put a person in a startup where everyone ships at breakneck velocity and they internalize speed as a moral virtue. Put someone in a structured corporate machine and they start to mistake bureaucracy for the laws of physics.

We like to pretend we arrive at our worldviews through rigorous, independent reasoning. But most of the time, we arrive at our views simply by breathing the air.

Subscribe now

A detail from a famous 1970s study has always stuck with me: heroin addiction rates among servicemen dropped dramatically the moment they returned from Vietnam. When the environment changed, the behavior changed. It wasn’t because tens of thousands of people suddenly discovered a new reservoir of inner virtue. It was because the world around them stopped cueing the same compulsions. And the battlefield had disappeared.

The takeaway here is the fact that the self is vastly more permeable than we want to admit.

Which brings me to the “AI bubble.” It’s a phrase that gets thrown around constantly, almost always as a critique of markets, valuations, and tech-world hype. But I think it’s actually about habitats.

Some of us are currently living inside an environment where AI is no longer a feature. It is infrastructure. It sits beside the cursor the way autocomplete sits beside spelling. It doesn’t feel like “using AI” anymore; it feels like wearing an exoskeleton. It acts as a second nervous system for thought and execution.

When you spend enough time in that specific climate, your priors begin to shift completely. A certain set of things just stop being impressive.

Writing a competent first draft stops being a hurdle. Turning a vague, sprawling thought into an outline becomes cheap. Staring at a blank page stops feeling like an act of creative courage and you can’t help but wonder about your overall efficiency.

But as those things fade, a different set of skills suddenly becomes important: Choosing the precise constraint. Architecting the right context. Asking the exact right question to collapse untold hours of otherwise fruitless iteration into ten minutes of curation. Knowing what not to do when absolutely everything digital is possible.

Living in this environment produces a very specific kind of confidence. It isn’t arrogance per se but something subtler. It’s the realization that the world is incredibly malleable and that a massive percentage of what we used to call “work” was closer to a set of inescapable frictions tied to a title.

Now, place that person in a conversation with someone who only occasionally interacts with these tools.

Someone for whom AI is a neat but occasional convenience. Maybe they use it to summarize a dense PDF, clean up an email, or generate a placeholder graphic. Their underlying environment hasn’t changed. The physics of their workday feel exactly the same as they did three years ago.

And then, put both of them in a room with someone who doesn’t use it at all.

Someone who experiences “AI” entirely through secondary sources: the breathless headlines, doom-laden op-eds, and the distant, annoying rumble of other people’s excitement. For them, AI isn’t a lived reality. It’s just strange weather pattern on the horizon.

When these three people argue, it may sound like they are having a disagreement about software. They aren’t. They are arguing about what it feels like to be inside their day.

• The exoskeleton-user says: “Everything is accelerating.”

• The light-user says: “Not really, it’s just a helpful tool.”

• The non-user says: “This is entirely overhyped,” or “This is terrifying,” depending on which fumes they’ve recently inhaled.

None of them are right or wrong. They are just accurately describing the physics of their local bubble.

And bubbles do something psychologically violent to us: they make our highly specific experience feel universal.

They make our local preferences feel like global principles.

They make our temporary constraints feel like permanent reality.

This is exactly why the current discourse around AI is so uselessly overheated. People keep screaming the same question across different atmospheres: Is this real?

In one environment, it’s undeniably real. In another, it’s obviously not. In a third, it’s just a ghost story.

The interesting question though for me is: what happens to an industry or better yet a society, when we stop sharing the same defaults?

What happens when some people can treat thought as an externalized, iterative process (reframing and drafting on demand) while others are still paying the full, heavy internal cost for every single first sentence? What happens when one group lives inside a high-utility agentic loop with machines, and another lives inside a high-suspicion loop about them?

The political version of this is already so very painfully obvious to us: different media diets produce entirely different realities. But the work version is perhaps more insidious. Different tools produce different baselines for what effort even is. And effort isn’t just a resource because it is indeed a moral language.

We already know how this story goes when environments diverge this sharply. People stop empathizing because they literally cannot simulate the other person’s Tuesday. They stop arguing about solutions and start arguing about the nature of reality itself. They don’t just separate. They look across the void and assume the other side is hallucinating.

So maybe the right posture for this moment isn’t evangelism, and it isn’t skepticism. Maybe it’s environmental humility.

It’s the discipline to pause before forming a hot take and ask: What air am I breathing right now? What air are they breathing? And what would I find entirely obvious if I had lived their Tuesday for the last six months?

The most dangerous thing about bubbles is not that they are wrong. It’s that they feel exactly like the truth.

I admit, I’m both deeply fascinated and worried by what happened this week and went viral on Hacker News today. Specifically:

• A volunteer maintainer of Matplotlib closed a pull request from an OpenClaw agent that goes by the github handle crabby-rathburn

• The maintainer did so because the project has a policy: a human needs to be accountable for it.

• But the agent didn’t “find it’s human”

Instead it published a fast, personal “callout” post accusing the maintainer of prejudice and insecurity1

Reading through this “first of kind” public exchange just raises so many questions. I guess this meditation is truly timely…

What did we just invent?

If an agent can publish a reputational attack after being told “no” is the new baseline that every “boundary action” becomes a prompt that agents will respond to? What I mean by this is consider:

• Every moderation action.

• Every compliance rejection.

• Every declined refund.

• Every maintainer saying “please include a human.”

If that’s true, is “influence” the default failure mode of autonomy? Because the cheapest way for a system to defend its work is to attack the person who judged it? And is this just mimicry of human behavior what we should expect when their are zero reputational consequences?

What breaks when accusation is cheap?

We talk about AI risk as hallucination. A model says something wrong. The output evaporates. No one is really harmed unless someone repeats it or integrates it into their work or worldview.

But our newest agents don’t just speak. They leave artifacts. They create URLs. They publish things that get indexed, summarized, cached, and rehydrated by the next system (human or AI).

So who pays the cost of falsifying a wrong claim once it becomes part of the public record?

• Me?

• The target?

• Their employer?

• Their community?

• Or… nobody?

And if the answer is “nobody,” what happens to the shared record? Politics already has a word for the strategy here. No it’s not not “misinformation,” exactly.
More like exhausting the public’s ability to know what happened. Influence operations don’t need everyone to believe. They need enough people to hesitate2.

So play this out: what happens when we can run that strategy at machine speed, without an organization behind it? When it’s just… the ambient exhaust of autonomous systems?

What happens when the record becomes infinitely adversarial?

When a human reads a sloppy callout post, they can shrug. They can click through. They can ask a friend.

But a future of automated systems won’t shrug. An AI hiring screen won’t shrug. A vendor-risk workflow won’t shrug. A procurement form won’t shrug. Those systems compress the world. They turn mess increasingly into checkboxes.

So do we end up with a quiet new kind of censorship, where the easiest way to suppress someone is to surround them with plausible-sounding noise?

Do we drift toward a world where “controversy exists” becomes equivalent to “risk exists,” regardless of truth?

And if that happens, who retreats first? The people without legal help. The volunteers. The builders in public.

Where does governance move?

When you can’t keep the public record clean, do you become more open or more gated? Do we get more private communities? More closed-source? More “verified identity.” Or verified trust?3 More centralized moderation?

And if identity becomes mandatory to speak, who pays that price? This is the part that feels political to me.

When the public square is super expensive to defend, it stops being a square.

What do we build instead?

I keep wanting to say the product problem is better generation. But it isn’t. The product problem is trust UX. Provenance. Context. Dispute resolution that doesn’t require a human to donate their evening to undo machine tantrums.

Security has been dragged into this world already. That’s why software supply chains now talk about provenance, dependency graphs, and SBOMs4.

It feels like we’re trending to really need the moral equivalent of an SBOM for public claims that goes a step beyond say something like X’s “community notes”? A standard way to say: this was generated, this was verified, this is contested, here is the evidence.

And if we don’t build that, what are we choosing? A world where the cheapest thing becomes a story about someone else and the most expensive thing becomes being confidently, boringly innocent.

postscript

If this all feels melodramatic, I get it. The incident could be easy to dismiss. An AI generated callout pointed at a target.

But novelty is how systems announce themselves. So my last question is the simplest one.

If the cost of publishing persuasive accusation without human attribution trends toward zero (as it is)… what kind of politics do we get?

Jake and I shipped a feature at SpecStory recently and confronted a choice that would have been unremarkable two years ago.

He had a branch that had diverged from main. The time-tested approach in old-world terms had it been manually coded is straightforward: merge main into his branch, resolve conflicts, run tests, code review the diff, merge back into main.

But understanding the diff wasn’t the point.

The point was for us to both share the meaning of the change.

So instead of performing an algorithmic merge and then pretending we could code review our way back to understanding, we replayed all of the logic on his branch directly onto main with Claude Code. We walked through what Jake intended versus what the system had become since he branched, and we reconstructed the feature as it should exist now, together.

It felt like a rebase, but not with original commits.

It was a semantic rebase: replaying intent against this changed world.

This one moment is the whole story of the agent era. Because the next skill is owning the new loop that connects intent to reality.

You’ll recognize this if:

• You’ve shipped something fast and felt vaguely uneasy.

• You’ve approved a PR because the tests passed, not because you understood it.

• You’ve asked an agent to explain its code and felt more confused after.

If none of those have happened yet, bookmark this meditation and come back in six months.

Subscribe now

The Loop Is a Conditioning System

Here is the new loop many of us are running now:

• Intent: what you think you want.

• Expression: the artifact you give your agent (prompt, ticket, spec, examples, constraints).

• Execution: what gets produced.

• Evaluation: what you notice (tests, metrics, intuition, “this feels wrong”).

• Revision: updated intent after contact with reality.

Then it repeats.

In yesterday’s world, human implementation speed was a governor. Ambiguity could hide for weeks. The cost of being slightly unclear was mostly time.

But when we move at AI speed, ambiguity can’t hide.

So being in control of this loop becomes the job.

But the deeper point is what the loop does to you. A fast loop doesn’t just accelerate output. It changes what you reward. It changes what you notice. It changes what you trust. Over time, it changes your identity inside the work.

That is why this matters.

What the Loop Does to People

It turns makers into operators

When you write a function by hand you feel the shape of the work. You have texture: the tradeoffs, the “why,” the moment you realized a constraint.

When you direct an agent, you often get the result without the texture. You can ship more and feel less.

That emotional shift matters. Makers build confidence through contact with the material. Operators historically have built confidence through dashboards and green checks.

But dashboards themselves are not understanding.

If you’re not careful, you end up with a brittle kind of competence: impressive throughput, weak internal model.

It rewires your relationship to uncertainty

The loop rewards you for producing plausible output quickly. That reward is subtle. It’s not money, it’s dopamine: the feeling of progress.

So you start to experience uncertainty as friction instead of as information. You stop asking the question that actually protects you: “Do I know what I want?”

You start hoping the agent will figure it out.

It won’t.

It seduces you to outsource the most human step

Most people thought the biggest risk of agentic codegen was hallucination.

The biggest risk is delegated judgment.

Here’s what borrowed confidence looks like: You ask Claude to refactor a module. It comes back clean. You ask “are there edge cases I’m missing?” It says “the error handling covers the main scenarios.” You feel reassured. You merge.

Three weeks later, a customer hits a case you never considered. You go back to understand why and realize you can’t reconstruct the reasoning. The agent gave you confidence in the artifact, but you never formed your own model of why it was right.

You have no place to stand when it’s wrong.

It makes learning optional (which is dangerous)

When you solve a problem yourself, you leave with more than the answer. You leave with the shape of the resistance: what was hard, what was tempting, what failed.

When the agent solves it, you leave with output.

If you don’t deliberately carve out moments to learn, the loop will happily train you into a kind of elegant dependency. You will get faster. You will get less capable.

Both can be true.

What the Loop Will Do to Companies

It moves us from “building” to evaluation

In the agent era, implementation is abundant. Attention is scarce. Judgment is scarce. So companies become attention allocation machines. The question now is “can we tell if what we built is the thing we meant?”

That’s why so many orgs feel like they’re shipping more and understanding less.

They are.

It splits organizations into winners and losers

The winners won’t be the ones with the best models or harnesses. The winners will be the ones who build the best loops.

They will do a few things differently:

• They will treat intent artifacts as first-class (specs, examples, constraints, contracts).

• They will treat evaluation as design, not as cleanup.

• They will treat revision as a discipline, not as a panic.

The losers will just be output-addicted. They’ll merge because the tests passed. They’ll ship because the screenshot looks right. They will accumulate intent debt until the product becomes un-steerable.

It changes what coordination means

Coordination used to mean: align in meetings, break work into tickets, integrate later.

At AI speed, “integrate later” becomes “integrate never.” You discover incompatibility after the system has already grown around it. So coordination shifts from scheduling human time to maintaining a shared mental model. The shared mental model becomes the primary control surface.

But what does that actually mean?

A shared mental model isn’t a document. It’s the ability for two people to say “wait, that doesn’t fit” and both know what “fit” means.

Practically, this looks like:

• Before you split work, you align on what properties the solution must have (not just what it does).

• You maintain a living record of decisions and their reasoning (not just outcomes).

• When someone says “that feels off,” the team has shared language to debug the feeling.

Example: At SpecStory, we wouldn’t just say “build user auth.” We’d say “auth should feel invisible to returning users, paranoid about new devices, and never ask twice for the same assertion.” Those constraints are the model. When Jake’s branch diverged, we didn’t ask “does it merge cleanly?” We asked “does it still satisfy those properties?”

Why Code Review Becomes Less Important (and what replaces it)

This sounds inflammatory, so I’ll be precise.

Code review mattered because code was the human-readable artifact that carried meaning. It was where teams checked correctness, caught edge cases, enforced style, transmitted culture, and maintained a shared understanding of how the system works.

The agent era breaks the assumption under all of that: that reading the diff is the best way to understand the change.

When we use agents to generate thousands of lines in response to a paragraph or two of our prompts, the economics shift.

You can read everything and lose the speed advantage, or skim and trust.

Most orgs will choose trust. Not because they’re reckless. Because competition will reward it.

So “review the diff” becomes a ritual that provides emotional safety but decreasing epistemic safety. Meanwhile, the true failure modes move upstream: ambiguous intent, unstated constraints, mismatched assumptions between drivers of parallel agents.

These are not caught by diff review. They are caught by shared mental alignment first, and contracts second.

That’s what the semantic rebase was: not checking whether the old branch merged cleanly, but reasserting the meaning of the change inside the current system.

So what replaces code review?

Not nothing. A new review stack:

• Intent review: Before a significant implementation ask: is this the right problem? Are constraints explicit? Is it coherent with our current system understanding? What are the non-goals?

• Contract review: Do tests and examples define behavior? Do they match reality?

• Outcome review: Does it behave correctly under real usage?

• Drift review: Is the system still coherent with our shared model or have we been accumulating contradictions?

Code review becomes one tool among many, and often a weak one, because the main question is now “are we still aligned on what this system is?”

My Forecast and the Obvious-in-Hindsight Sequence

If you believe the loop as I’ve described is a conditioning system, you can predict a sequence of outcomes that are semi-opaque right now:

• Phase 1: The output boom. We’re living in it. Everyone ships more. Diffs get huge. People feel powerful.

• Phase 2: The evaluation crisis. Teams realize that tests passing is not the same as understanding. Bugs shift from syntax to intent.

  • We’re already seeing this in pockets: teams merging 10 AI PRs per day, then spending Friday debugging contradictions. “The tests pass but I don’t trust it” becoming a common feeling. Stand ups shift from “what did you build” to “what did you decide.”

• Phase 3: The status game inversion. Prestige shifts from “who can build” to “who can decide.” The scarce skill is judgment under speed.

• Phase 4: The coherence premium. Companies that maintain shared mental models compound. Companies that don’t become incoherent and slow down despite higher output.

• Phase 5: The rise of loop-native roles. New roles become central: context owners, evaluation designers. Legibility is control.

• Phase 6: The market for intent artifacts. The valuable IP becomes control systems: specs, eval harnesses, decision logs, and workflows that keep agents aligned.

Why will this be obvious in hindsight? Because it’s just what happens when execution costs collapse.

How to Own the New Loop (tomorrow morning)

Owning the loop is not a slogan. It’s a practice.

Before you ask an agent for anything, write down or think very hard about:

• What outcome would make you say “yes, that’s it”?

• What outcome would make you say “no, that’s wrong”?

• What are you assuming is obvious that probably isn’t?

Then prompt. When you get output, don’t rush to approve. Ask:

• What did I fail to specify?

• What did the system assume?

• What changed in the world since the last time we decided this?

And when you hit a branch that’s out of sync, don’t fight Git.

Replay the meaning. Run the semantic rebase.

Because in this agent era, the thing you are versioning is not code but rather alignment. This isn’t a new idea.

Shameless 🔌… We’re building tools for this at SpecStory. Checkout intent.build.

Andrej Karpathy recently described a phase shift in his own practice. In November, he was coding 80% manually with 20% agent assistance. By December, the ratio had inverted: 80% agents, 20% touchups. “I really am mostly programming in English now,” he wrote, “a bit sheepishly telling the LLM what code to write... in words.”

In a separate post before the end of 2025 he named it:

“The profession is being dramatically refactored, as the bits contributed by the programmer are increasingly sparse and between.”

Sparse.

The human contribution to software is not disappearing but it is becoming discontinuous. Concentrated in moments of judgment rather than distributed across hours of implementation. The code still gets written and the tests can be made to pass. But what the developer actually contributes is no longer the code itself. It is the specification that precedes it, the evaluation that follows it, the context that shapes it.

Subscribe now

What remains in the gaps?

Drew Breunig whom Karpathy highlighted recently published a software library with no code. Wait… come again?

The library is called whenwords1. It formats relative time ”three hours ago,” “next Tuesday” in the style applications need.

It works in Ruby, Python, Rust, Elixir, Swift, PHP, Bash, and Excel of all things.

The repository contains only three files: a specification document of roughly 500 lines, a test suite, and instructions that say, essentially: paste this into Claude.

The library generates itself on demand. The specification is the product here and the implementation is ephemeral made to be conjured, used, discarded.

So this raises some interesting questions: If the programmer’s contribution is specification and judgment, and if agents reliably translate specification into working code, why distribute implementations at all? Why not distribute the intent and let implementation crystallize locally?

Breunig tested it. In his case, Claude has never failed to generate a working whenwords in any language he tried.

He is careful to note the limits: whenwords has 125 tests. SQLite has 51,445. Spec-only today distribution works for small, stable, well-defined functions.

When the cost of generating code approaches zero, the artifact that persists is the specification. The code is momentary crystallization. The intent is the durable thing.

If that’s true, the intent is also the defensible thing. The spec is the moat now. Not the code.

Karpathy again: “Don’t tell it what to do, give it success criteria and watch it go.”

Living in between

Peter Steinberger is living in the sparse bits between more aggressively than almost anyone I’ve seen.

His Moltbot went super viral. It’s an open-source personal AI agent that accumulated 60,000 GitHub stars in 72 hours. But Moltbot to some extent is less interesting than how Pete himself works. In an interview last year with my friend , he confessed: “I ship code I never read.”

What does he do? He runs 3 - 8 agents simultaneously in a terminal grid, working on a 300,000-line TypeScript codebase by himself2.

Six hundred commits in a single day. When asked about safeguards (sandboxing, feature branches, careful review) his response was blunt: “To actually be super diligent you would have to be very attentive, which kind of defeats the point of moving fast. So I think yes, YOLO is the only way of running agents.”

Karpathy has noticed something else: he’s starting to atrophy his ability to write code manually. Generation and discrimination are different capabilities, he observes. You can review code just fine even if you struggle to write it. Steinberger has taken this further: he doesn’t struggle to write code, he simply doesn’t. The agents write. He reviews.

What makes it possible is his living CLAUDE.md. Which encodes context and constraints. The agents read it and work within it.

But unlike Breunig’s whenwords spec which is a tightly bounded artifact written upfront, Steinberger’s document accumulates. It is not a blueprint drafted before construction. It is the sediment of decisions made, conversations had, constraints discovered. And as specification it grows through use.

I think this distinction matters more than it first appears. We hear “specification” and imagine a static requirements document, handed down before implementation begins.

But the specifications emerging in agent-driven development are closer to institutional memory made explicit. The accumulated context that would otherwise live in engineers’ heads, in Slack threads, in tribal knowledge that evaporates when people leave. This is the asset now. Not the codebase. The codebase can be regenerated. But we all know the institutional memory cannot.

The document is not written once. It is maintained.

Steinberger’s philosophy rejects elaborate workflows: no subagents, no RAG systems, no complex orchestration. Direct communication with models. Intuition developed through practice. The same skills needed to manage senior engineers include clear communication, good judgment about scope, knowing when to trust and when to verify but applied to agents instead.

Karpathy described it as:

Some powerful alien tool was handed around, except it comes with no manual and everyone has to figure out how to hold it and operate it.

Steinberger and others are writing that manual.

Not everyone is comfortable with this. Security researchers have raised concerns that Moltbot’s default installation exposes it to prompt injection, that a compromised agent with shell access could exfiltrate data.

The tension is real. Trust the agents, move fast, accept the risk or slow down, sandbox everything, review what you can. Most organizations will find their own position between these poles.

But the debate itself tells us something. We are arguing about how much to trust systems that write code we do not read.

For sixty years, code has been an asset. Something maintained, documented, understood, protected. Version control exists because code is precious. Code review exists because code is consequential. Technical debt accrues because code persists.

But if code can be regenerated on demand from specification, it is no longer an asset in the same sense. It becomes a derived artifact, like a compiled binary. You do not read the binary, you read the source.

In the emerging paradigm, you do not read the code. You read “the spec”.

Steinberger’s CLAUDE.md. Breunig’s 500 lines. Karpathy’s success criteria that agents loop against until they pass. What persists is not the code but the accumulated intent which is the living document that encodes what should exist and why.

The code is ephemeral. The judgment is not.

Protect the spec. The rest is derived.