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.

An active seat was the cleanest SaaS lie.

It looks like adoption. When it expands it sure feels like progress. In many cases it has renewed like inevitability. Why was it so clean? Because it has let vendors tell a simple story: more active users equals more value and it lets customers repeat that story back. “We’ve now standardized on the tool.”

But seat consumption has rarely proved that the customer made more money or spent less money.

Subscribe now

The machinery built around this proxy with multi-year contracts, renewal gamesmanship and NRR as religion has trained our entire Tech industry to optimize capturing value rather than creating it.

I repeat: we’ve been trained to capture value more than to create it.

The modern enterprise stack is full of software that is “in use” the way a gym membership is “in use”1. It exists, it’s paid for, it’s occasionally visited, and it provides a comforting sense that something healthy may be happening.

That’s why the question of this particular meditation matters. It isn’t because generating code is suddenly trivial. But rather due to the fact the illusion that usage implies outcomes is becoming harder to maintain. No place more clearly evidenced than by the fact that SaaS multiples have completely disconnected from the rest of the Nasdaq… which some have been calling The Great SaaS Meltdown.

How We Got Here

The original promise of SaaS was boring and honest. Software delivered over the internet would be easier to deploy, easier to update, and less painful to run. It was a delivery model that also happened to collapse distribution and maintenance costs.

Then venture capital (and later private equity) discovered that recurring revenue commanded higher valuation multiples than one-time sales and like that SaaS became a business model2.

This happened under specific economic conditions from 2009 to 2022 (“ZIRP”) when interest rates hovered near zero. Capital was cheaper than it had been in living memory. Growth-at-all-costs was the rational response to this low cost of capital. Reid Hoffman’s blitzscaling doctrine made sense when you could raise endless rounds to cover losses while you captured market share. The companies buying software operated under similar logic: budgets were loose, CFOs were measured on growth initiatives, and shelfware? Well maybe that is an accepted cost of doing business.

And so multi-year contracts priced by the seat became de rigueur: software was relatively scarce and expensive to build, switching could be risky, IT bandwidth was constrained, and standardization was itself a win even if in most cases the tool was mediocre. Under these conditions the difficulty of leaving could look a lot like desire to stay.

A tool that genuinely transforms a business and a tool that sits half-used can generate the same revenue for the vendor. This particular unit of value is detached from value itself.

I’ll Happily Say It: Usage-Based Billing Isn’t the Answer

AI companies have recently made metering fashionable again because the new cost structure forces honesty. We know that every token costs money. But usage-based billing isn’t new. Telecom did it. Cloud did it. Metering aligns vendor revenue with vendor cost. This is not the same as aligning vendor revenue with customer outcomes.

To flip the above statement from the vendor’s perspective, a product can be heavily used and still be wasteful. A product can be lightly used and still be transformative. The difference is whether it’s directly attributable to revenue gained or costs reduced and not whether it generated “time saved” anecdotes in a quarterly business review.

Time saved is only value if it converts to something the business can measure: fewer heads, more throughput, fewer errors, faster cash conversion, higher win rates, lower churn, lower loss ratios, lower downtime. Otherwise it’s a story that makes everyone feel modern and sexy while financial statements do not meaningfully change.

Easier to build, easier to replace

Quoted below is a very common argument in light of the following statement: as software becomes easier to build, enterprises will stop buying it and generate whatever they need on the fly.

Enterprises don’t buy software because code is hard. They buy standardization, shared context, institutional memory. Vendors absorb complexity. A trucking company’s advantage is logistics, not maintaining internal tools. Even if software becomes trivially easy to build, enterprises won’t become perpetual hackathons.

The part that’s right: Enterprises really do buy reliability, governance, auditability, and continuity. They buy a tool that keeps working when the champion leaves. “Shared context and institutional memory” is real. It shows up as fewer local variations, fewer shadow processes, fewer “mission-critical spreadsheets.” Standardization reduces coordination costs across teams and time3.

The part that’s wrong: The leap from “standardization matters” to “per-seat subscriptions represent value” is where the argument collapses.

A vendor can absorb complexity and still be a massive tax. The claim that vendors absorb complexity is true but incomplete since vendors also create complexity. The integration layers, the API rate limits, the permission structures, the upgrade cycles these are very far from natural phenomena.

They’re artifacts of dependency engineering: features and workflows designed to make the product hard to replace, because retention celebrates stickiness without asking whether stickiness comes from love or from pain.

Salesforce has spawned an entire ecosystem of implementation partners precisely because the platform’s complexity exceeds what most organizations can manage internally4. The consultants aren’t absorbing inherent complexity; they’re absorbing Salesforce-specific complexity that exists because it serves Salesforce’s interests.

Enterprises won’t turn core operations into weekly experiments. But they will replace software faster when replacement stops being a multi-quarter migration and becomes a credible option. AI doesn’t need to make all software trivial. It just needs to collapse the switching cost curve enough that vendors must justify themselves in outcomes, not inertia.

What Changes When Building Gets Cheaper

When software becomes cheaper to produce, you don’t get a world without vendors. It’s just you get a reframed world where defensibility moves5.

The vulnerable categories are the ones where the “product” is mostly CRUD, dashboards and templates… things that were sticky because they were annoying to recreate, not because they were uniquely valuable. The first casualties are tools whose differentiation is “we assembled the obvious features and sold it as a product platform”.

The survivors deliver one of these:

• Provable economic impact: revenue lift, cost reduction, risk reduction that can be measured, not asserted.

• Operational reliability at scale: uptime, security, compliance that would be genuinely hard to replicate.

• Network effects: shared data that compounds like context used to power the business, fraud signals, marketplace liquidity.

• Deep integration: real orchestration across messy systems and not just another fragile API connector.

• Accountability: someone is on the hook when it breaks.

In my view, the Software must become something near to a capability you operate and not something you just license.

The Return of Skin in the Game

Before Software ate the world, serious money in enterprise transformation often came from a simple structure: the provider got paid when the client got results. AI makes that model plausible again because delivery can be faster and more adaptable.

We know Palantir and their forward-deployed engineers embed with the customer to solve their specific problem by building exactly what the customer needs (and then arbitraging these insights into Palantir’s core products and their data ontologies). This approach has been derided as “unscalable” by observers who had internalized SaaS economics as natural law. But Palantir’s customers have renewed because the software worked and not because switching was painful.

The product then must not just be software. It’s implementation, integration, change management, and measurement. Compensation that ties to a defined outcome: incremental gross margin, reduced handle time that actually reduces staffing, reduced fraud loss, increased conversion, shortened quote-to-cash cycles or in Palantir’s case… well dare I say6.

Real value-aligned pricing means defining a metric the CFO cares about, measuring it honestly, and letting the vendor’s economics hurt if improvement doesn’t happen. Many SaaS vendors don’t want this because it would reveal that their product doesn’t actually have any true value.

The Human Cost

The SaaS economy has built careers for millions myself included. Customer success managers. Implementation consultants. Sales engineers. Salesforce administrators. Integration specialists. An entire professional class whose expertise is deep knowledge of specific platforms much of which becomes worth a whole lot less if the platform becomes replaceable or is obviated.

But know this! The enterprises buying software are not innocent either. They are willing participants in subscription theater. Often they preferred the comfort of the renewal over the accountability of outcomes. They let “we’re standardized on X” substitute for “X is making us money.” The reckoning is for everyone who found it easier to pay for the illusion of progress than to measure real results. And then do something about it.

So…

Easier to build does mean easier to replace. But not in the way that many breathless predictions suggest.

Enterprises won’t become perpetual hackathons. They won’t generate software on the fly for every need. Standardization, reliability, and institutional memory matter.

What changes is simply that pricing proxies are exposed. When building and modifying software gets cheaper, the burden shifts to proving that what you ship creates measurable economic change. Seats, “adoption,” renewals-as-success these worked when switching was expensive enough that no one tested whether the value was real and is a condition that is ending.

The future is fewer vendors selling access and more vendors selling accountability.

If your product could be rebuilt in a weekend, you need to be selling something beyond the code itself and its one of these three things:

• A system that keeps other systems working

• A capability that integrates across messy reality, or

• An outcome you’re willing to guarantee.

If you can’t claim one of those, what you’re actually selling and trying to retain is the customer’s switching cost: their sunk investment, their migration pain and their fatigue. That’s inertia. And inertia was always a depreciating asset.

The next time you sign a renewal, ask the vendor a simple question: what will you give back if nothing improves?

Their silence will tell you everything.

You’re generating more code than ever and understanding less than ever.

That’s the trade you made. Maybe you didn’t notice. The output kept coming, the files, functions, features and you kept accepting. Somewhere over the last eighteen months you stopped asking whether you understood what was being built and started asking whether it passed muster.

Some tests pass. Your understanding doesn’t.

I know because I’ve done it too. I’ve shipped weeks of work that should have taken weeks in afternoons. I’ve prompted my way through domains I had no business touching. I’ve felt the rush of watching a feature materialize from a paragraph of intent, marveled at the magic, and moved on to the next thing without pausing to ask what I’d actually learned.

Nothing. I’d learned nothing. I’d generated output.

The vibe coding discourse misses this entirely. One camp celebrates Ralph Wiggum loops as AGI. The other warns about security vulnerabilities and hallucinated dependencies. Both are arguing about the code that is created.

Neither is really truly talking about what happens to You.

Vibe Coding. Collins made it Word of the Year. Stanford says junior developer employment dropped 20%. That METR study found developers thought they were 20% faster with AI but measured 19% slower. Everyone has data. Everyone has takes.

Few have really looked in the mirror.

Subscribe now

I. How You Lie to Yourself Now

You open the IDE or Terminal or soon some RTS-game-control center1. You think: Today I’ll be productive.

But productive at what, exactly?

Here’s what you’re actually doing: translating half-formed intentions into prompts, then accepting whatever comes back if it approximately works. You’re not building. You’re approving. You’ve become a Tier 1 quality assurance department for an inference machine that never gets tired but sure can cost a lot.

This felt revolutionary twelve months ago. Now it feels like drowning in choices you don’t fully understand.

The true shift is that you no longer need to know what the code does to ship it. And you’ve quietly accepted this as normal.

It’s a Faustian bargain.

When an agent turns natural language into working software, the craft isn’t writing code. The craft is knowing what to write. Intent is the new source code. Your specification (ya know that once a bureaucratic afterthought you skimmed and forgot) has become the primary artifact of human control.

The sequence of prompts in your sessions and exchanges produce the product. That is the source.

Most people haven’t internalized this. They’re still trying to get better at prompting when they should be getting better at wanting. At specifying and intervening and correcting. At knowing, with crystalline precision, what they’re actually trying to build.

Repeat this and then repeat it again: “Do I know what I want?”

Usually you don’t. Usually you’re hoping the AI will figure it out for you.

It won’t.

II. Context Dies in Transit

Every piece of software you’ve ever cursed at was, at some point, somebody’s clear intention.

Think about that. The spaghetti code, the inexplicable architecture, the feature that does something almost-but-not-quite useful all of it started as a reasonable idea in someone’s head. Then it got translated. Meeting to notes. Notes to tickets. Tickets to to code to commits. Reviews to revisions.

By the time it shipped, the original intent had been compressed, lossy-encoded, and re-interpreted so many times that the final product bears only ancestral resemblance to the initial vision.

This is software’s original sin. The intent gap. AI doesn’t fix this.

Now the translations happen faster. Which means the degradation happens faster. Which means you ship things that can stray further from what you meant if you considered it deeply. But because everyone proclaims to be shipping at light speed, everyone calls it progress.

The teams winning right now have figured something out that I suspect many of the rest are still missing.

They’re not just versioning code. They’re versioning decisions. Reasoning. The why behind every choice. They treat conversations with agents as “commits”. They make everything implicit become explicit.

This is the new discipline. Call it context engineering for now. Most people don’t know it exists let alone how to operationalize it. They think the job is prompt engineering. But prompt engineering is just typing. Context engineering is architecture. It’s building the information environment that makes the AI’s outputs trustworthy that then become useful.

Without it you’re just generating plausible garbage at scale.

III. Stop Treating Iteration Like Failure

The back-and-forth feels wrong.

You prompt. It misses. You clarify. It misses differently. You rephrase. It gets closer. You adjust. It breaks something else. Four rounds later you have something that works, but the whole experience felt like flailing.

So you conclude: I must be bad at this. If I were better, I’d nail it in one shot.

No. You wouldn’t. Nobody does. The one-shot fantasy is a lie sold by bait videos and Twitter threads optimized for engagement.

Iteration isn’t failure. Iteration IS the method.

This is counterintuitive only if you’ve bought into the myth of the perfect prompt. Slash commands and Skills that try to get it right immediately. Questions iterate toward understanding.

When you treat the conversation with an AI as the cognitive process itself and not some broken version of some better, smoother process thats when “everything changes” to quote the threadbois. The dialogue surfaces assumptions you didn’t know you had. This friction reveals specification gaps that would have shipped as bugs.

The most valuable thing you can do is ask a question the agent doesn’t know how to answer. That’s where your judgment lives. That’s where you’re actually needed.

Slow down inside the iteration. Don’t just rephrase and retry. Ask why it missed. Ask what you failed to specify. Ask what you assumed was obvious that wasn’t.

The AI’s confusion is a mirror of your own unclear thinking. Use it.

IV. The Things That Refuse to Compress

When everything can be generated, what remains valuable?

This is the question lurking beneath the junior developer employment numbers, beneath the job market anxiety, beneath the Reddit threads full of engineers wondering in public if they chose the wrong career.

The answer is: everything that won’t compress.

You can’t compress the pause when a senior engineer says, “This works, but here’s why we don’t do it this way.” That pause contains years of shipped products, failed launches, production outages, and hard-won intuition. It can’t be prompted. It can’t be retrieved from training data. It lives in a human being who went through something.

You can’t compress trust. Or the scar tissue from high stakes incident resolution. Or knowing in your bones when something’s wrong before you can articulate why.

You can’t compress suffering. What saddens me is that every shortcut around struggle is a lesson lost.

The models know everything but they’re brilliant amnesiacs who forget the conversation the moment it ends. They have no continuity of experience, no accumulation of judgment, no sense of what it cost to learn something.

What happens when we become the same? Dependent on machines that compress away not just our work, but our need to think?

I don’t have an answer but I do have a practice.

Calculated sabotage: deliberately choosing difficulty to preserve capacity for difficulty. You don’t have to outsource everything. Some problems are worth solving yourself—not because it’s efficient, but because the solving builds you.

When you solve something yourself, you leave with more than the answer. You leave with the shape of the problem, how it resisted you, how you broke through. That stays. That makes you someone who can solve the next thing.

Choose what to keep. Choose what to struggle with. The choice itself is the craft now.

V. The Hierarchy of Trust

Here’s a practical problem that isn’t well solved: you can’t read everything the AI writes.

Because there’s too much. When an agent produces a thousand lines in response to a prompt you have to skim because truly reading takes time. Generating takes minutes.

So you face a choice: read everything and lose the speed advantage, or trust and risk shipping things you don’t understand.

Most people default to trust. They accept. They merge. They deploy. And mostly it works.

Until it doesn’t.

The history of software is littered with bugs that passed every test and fooled every reviewer only to fail catastrophically in production. When humans write those bugs, we conduct postmortems and update practices. But what do we do now?

The solution isn’t “read everything” or “trust everything.” The solution is building hierarchies of trust.

Some outputs demand full review: security-critical code, financial logic, anything touching user data. You pay the time cost because the risk cost is higher.

Some outputs can be verified by proxy: if the tests pass, if the types check, if the linter’s happy, you trust the machinery you’ve built around the output rather than the output itself.

Some outputs can be trusted provisionally: low-stakes code, isolated functions, things you can rip out easily if they break. Ship fast, monitor closely, fix quickly.

The discipline is knowing which category you’re in before you prompt. The failure mode is treating everything the same: either paranoid review that destroys your speed or blanket trust that destroys your codebase.

Build the hierarchy. Know where you are in it. Adjust based on stakes, not comfort.

VI. What You Should Actually Do

The cost of trying has collapsed. What once required months can require minutes. What once required syntax expertise requires English.

This asymmetry has consequences. It means the barrier is no longer knowledge. It’s not skill. It’s not credentials. It’s clarity.

Do you know what you want? Can you specify it precisely? Can you recognize it when you see it?

If yes, you can build almost anything. If no, you’ll generate endless variations of the wrong thing.

Here’s my protocol:

1. Write specifications like you’re writing source code. Version them. Review them. Treat ambiguity as a bug. Every vague adjective is a potential defect. Every assumed bit of context is a future miscommunication. The precision of your intent determines everything downstream.

2. Build the context before you prompt. Gather the examples, constraints, patterns, and anti-patterns your agent needs. Don’t expect it to read your mind. Build the information environment that makes success probable instead of lucky.

3. Iteration as thinking. Stop trying to nail it in one shot. The conversation is the cognitive process. Each miss is information about what you failed to specify. Use it.

4. Preserve shared understanding. Your team’s collective working memory matters more than any individual’s output. Document decisions, not just outcomes. Link prompts to implementations. The context you’re too busy to preserve today becomes the bug you can’t debug tomorrow.

5. Build trust systems. Establish what gets reviewed and what gets trusted. Make it explicit. Revisit it as stakes change.

6. Choose difficulty strategically. Some struggles build capacity. Some don’t. Know the difference. Protect your ability to do hard things by occasionally doing hard things.

7. Start. The question now is “do I know what I want?” If you don’t know, the AI won’t save you. If you do know, the AI you use will multiply you.

VII. The Question To Confront Head On

You’re not supposed to be asking how to create software with AI now. That question is a proxy for a much harder one.

You need to be asking: What kind of builder am I becoming?

The tools will keep improving and capabilities will expand. The discourse will oscillate between ecstasy and doom forever. None of it matters as much as this:

Are you becoming someone who understands what you build? Or someone who ships what you don’t?

Both paths are now available. Both have their own logic. You can generate endlessly, ship constantly, measure productivity by output volume. Or you can generate selectively, understand deeply, measure productivity by clarity of intent.

The first path is faster. The second path is yours.

The industry is sobering up. The wild promises of 2024, somewhat realized in 2025 are meeting the messy realities of 2026. The people who treated AI as a replacement for thinking will drown in code they can’t debug. The people who treat AI as an amplifier for clarity are shipping things they’re proud of.

You get to choose which kind of person you become.

The practice compounds even when the artifacts fade. Every specification you write with precision, every iteration you treat as thinking, every deliberate choice to struggle when you could have delegated leave marks. Not on the codebase. On you.

That’s what lasts. Not the code. You.

The choice is still yours.

What’s the hard thing about operating a tech business? What about one at scale?

Ask a founder and they’ll say fundraising. Ask an engineer and they’ll say technical debt. Ask a sales leader and they’ll say pipeline. Ask a PM and they’ll say prioritization. Ask an exec and they’ll say hiring. They’re all right. They’re all wrong. They’re all describing symptoms.

The hard thing is building the right thing and building it right. And the thing that determines whether you do? Context.

This has always been true. But two very important things have changed: (1) agents make context exponentially more leveraged, their outputs are directly shaped by it, and (2) we have the technology to capture and synthesize context at scale.

Subscribe now

Let me explain what I mean by context, why humans are structurally bad at managing it, and why the shadow cast by coding agents turns this chronic problem into an existential one.

A business, like any living thing, is constantly evolving within the environment it operates. A small startup is trying to find Product Market Fit. A larger business is trying to maintain it. But both are doing the same fundamental work: finding a pain point customers will pay to resolve and delivering a solution that actually resolves it.

To do this well requires the continual never ceasing collection of evidence: talking to customers, gauging the competitive landscape, experimenting with what works, honing intuition through observation.

All of this is context.

And if you’re a product manager, executive, or line-level employee, your job (whether your JD says so or not) is to supply, receive, and act on this context to make better decisions.

The problem is that context degrades every time it moves.

Think about how a feature actually gets built. A customer success manager hears a complaint on a call. Maybe they log it in a CRM, maybe they mention it in Slack, maybe they just remember it. A PM talks to five customers and pattern-matches something. They write a spec that captures maybe 60% of what they actually learned. Engineering interprets that spec through their own lens. By the time code ships, the context has been compressed, lossy-encoded, and re-interpreted three or four times. It’s a game of telephone where the prize is your roadmap.

This is a context fidelity problem. And it gets worse as you scale.

When you’re ten people, everyone’s in the same room. Context flows through osmosis. When you’re a thousand people, the context capture surface area explodes. Your customer base has grown and you can’t talk to all of them. The number of meetings has multiplied and no one can attend all of them. Information lives in a hundred or thousand different Slack channels, docs, and heads.

So what do companies actually do? They talk about the issues that are salient: the ones that happen to surface in the right meeting, get mentioned by the right person, or generate enough volume to become undeniable. They catch some percentage of the signal and use that to prioritize. It’s better than nothing. It’s also how you end up spending six months building a feature because a board member mentioned it in passing while 200 support tickets about a different problem rot in Zendesk because nobody synthesized them into a narrative compelling enough to influence the “decision-makers”.

We’ve tried to solve this before with tooling. Enterprise knowledge management systems have been around for decades. But most of them fail for the same reason: they require humans to do the work of extracting, organizing, and maintaining context. Confluence becomes a graveyard. Notion fragments across fifty workspaces. SharePoint is SharePoint.

These knowledge base becomes an artifact of what someone once knew, not a living representation of what the organization currently understands.

Humans are bad at this. We always have been. In the same way we’re bad at forecasting (see: the entire field of statistics), we’re bad at synthesizing large amounts of unstructured information into coherent, actionable understanding.

But now we’re no longer the only ones who need the context.

The sum total of hours that employees spend talking (to customers, to each other, to themselves in meetings) represents the vast majority of how work actually happens. Decisions get made in conversations. Strategy emerges from dialogue.

The raw material of “what to build” lives in conversations, now transcripts and not documents.

And now we’re starting to talk to agents (a lot).

Software development agents are increasingly capable of doing real work because code’s correctness is verifiable. But their output quality is almost entirely determined by the context they’re given.

• Ask an LLM to “write a PRD for a notifications feature” and you’ll get something generic and plausible-sounding.

• Feed that same LLM transcripts from your last ten customer calls, your competitor’s recent changelog, and the Slack thread where engineering debated technical constraints and you’ll get something that reflects your specific situation. The delta is the difference between a template and a strategy.

This is already playing out in code generation. The teams getting real leverage from tools like Cursor or Claude Code are the ones who’ve figured out how to feed their codebase, their architectural decisions, their past PR reviews into the context window.

Everyone is using the same set of models and getting wildly different results.

LLMs generally don’t have the context problem humans have. They can process everything you give them until their context window is exhausted. The bottleneck is much different. It’s no longer “can we synthesize all this information?” It’s “are we capturing it correctly in the first place?”

The good part: we’ve already culturally adapted to the hardest part. Recording meetings is basically expected now. The ability to harvest the raw inventory exists.

But the vast majority of these recordings vanish into fairy dust. They sit in Gong or Zoom or Teams and are searchable in theory but useless in practice.

Few are systematically extracting the decisions, synthesizing the patterns, feeding them forward into the systems that determine what gets built.

The companies that figure this out and treat conversations with each other, with agents and with their customers as a truly corpus to be mined rather than ephemera to be forgotten will build the right thing and build it right more often than their competitors. They’ll feed their agents better context and get better outputs. They’ll spot patterns earlier. They’ll make fewer telephone-game errors.

In this new world where agents can increasingly do the building, the bottleneck shifts entirely to knowing what to build.

Context is the whole game and the answers are buried in your conversations.

NOTA BENE: This meditation runs longer than most. This last year earned it. As does what will be required from us next.

If 2024 was the year AI became a household word, 2025 was the year we spent instructing agents to write code.

We will spend the years that follow learning to live with code that we do not read.

Part I: What Happened

2025 opened with a shock from a small Chinese lab called DeepSeek who released a reasoning model that matched (at the time) the best American efforts at a fraction of the cost, sending Nvidia’s stock tumbling seventeen percent in a single day and Silicon Valley scrambling. That single release cracked open assumptions about what AI development required and who could participate in it.

Within weeks, the DeepSeek app had dethroned ChatGPT atop the App Store. Within months, every major Chinese tech company had slashed their API prices, and American labs reportedly assembled war rooms to reverse-engineer how DeepSeek had done so much with so little.

The technical shifts led to mixture-of-experts architectures (designs that route each query to specialized subnetworks rather than activating the entire model) with Meta’s Llama 4, Alibaba’s Qwen3, Mistral’s Large 3: all adopting the pattern, training models with hundreds of billions of total parameters while activating only a fraction for any given response.

Context windows exploded past what most had previously considered feasible. Anthropic and Google pushed to one million tokens. And retrieval-augmented generation, once considered absolutely essential for grounding models in large document collections, began to feel like a workaround for a limitation that was fast disappearing. Models could now almost “read everything”.

Reasoning itself also changed character. OpenAI’s o-series models and DeepSeek’s R1, all demonstrated that giving models time to think, to generate chains of reasoning before committing to an answer, produced step-changes in reliability on hard problems. By mid-year, “thinking mode” toggles had become standard across frontier models. Users could choose: fast responses for casual queries, extended deliberation for mathematics, coding, or anything requiring careful logic. The models began to show their work, and in doing so, became easier to trust and easier to correct.

Subscribe now

Multimodality ceased to be a feature and rather became a norm. The new crop of models fused modalities from the start, training on text, images, and video together so that understanding flowed between them. Gemini 3 could “watch a video” and reason about what it saw. Claude could look at a screenshot and click the right button.

What followed through the remainder of 2025 was relentless acceleration. OpenAI unified its scattered model lines into GPT-5 in early August via an internal routing system that could reason through complex problems or respond instantly depending on what the query demanded.

Google’s Gemini 3 briefly claimed the throne on every major benchmark in November, prompting internal “code red” memos at OpenAI and a hastily released GPT-5.2 before the year was out.

Anthropic’s Claude 4.5 learned to use computers the way humans do by clicking, typing, navigating interfaces and achieving scores on real-world computer tasks that would have seemed impossible a year prior. And Moonshot AI’s Kimi K2 earned quiet respect as perhaps the strongest open model available anywhere.

But the most important shift happened in what we built atop them.

If anything, 2025 marked the year of coding agents that could read entire repositories, plan changes across dozens of files, test their work, and submit pull requests for human review.

• Devin which was initially dismissed as overhyped vaporware when it stumbled through early demos, matured into something that by year’s end was writing a quarter of its parent company’s Cognition own code.

• Claude Code brought terminal-first agent development to the masses (leading to many copied efforts by Google, OpenAI, AMP, etc) and,

• Cursor reached a nine-billion-dollar valuation on the promise that the IDE itself was the most important new piece of software.

Underneath it all, the plumbing matured. Orchestration frameworks moved from experimental libraries to production infrastructure, letting companies deploy fleets of specialized agents working in concert.

Anthropic’s Model Context Protocol emerged as a kind of lingua franca for tool integration and they donated it to the Agentic AI foundation.

The economics shifted too. DeepSeek’s efficiency gains early in the year triggered price wars that compressed margins across the industry. API costs began to fall by orders of magnitude. At the time of this writing, DeepSeek was offering inference at three cents per million tokens in output. The question of who could afford to build with frontier models is now quietly dissolving.

What we know is that the frontier has moved so far that the debates of early 2024 as to whether AI could really code, whether reasoning models were a gimmick, whether open-source could compete are beginning to feel like quite distant history.

The questions we carry into 2026 are different and harder.

Part II: What Will Happen

The year ahead will not slow down and we won’t be able to easily catch our breath. The challenges of 2026 will be less about capability and more about comprehension and how we maintain any meaningful relationship with the systems we are building.

After Legibility

For sixty years, software development has rested on an implicit assumption: that code is a text meant to be read.

We write it in languages designed for human comprehension. We’ve reviewed each other’s work line by line. We maintain it by understanding it. The entire craft has been organized around the principle that a sufficiently determined person can sit down, read the source, and know what a program does.

When an agent writes a thousand lines of code in response to a natural language prompt, the human who prompted it faces a choice. They can read every line, understand every function, trace every edge case.

Or they can trust.

They can write and run tests, check that the outputs look right, and move on.

The economics of our current situation will push relentlessly toward trust.

Competitive pressure will reward teams that ship fast and penalize those that insist on understanding everything.

This is not hypothetical. It is already happening.

And this year the tension will become organizational. Companies will discover that their codebases have grown in ways no one fully understands. Engineers will inherit systems where significant portions were written by agents guided by people who have since left, with prompts that were never saved and reasoning that was never recorded. The code will work. The tests will pass. And no human will be able to explain, with confidence, why.

The Specification Becomes the Source

When code review as we know it today becomes impossible, something else must take its place. The most likely candidate is the specification itself: the prompts, constraints, requirements, and architectural decisions that guided the agent behavior.

If we cannot audit the implementation, we can at least audit the intent.

This represents a fundamental inversion. For decades, what most consider “specifications” have been treated as aspirational documents, often abandoned or outdated by the time software ships.

The code was the truth.

But when agents write the code, the specification becomes the primary artifact that humans can meaningfully control. The prompt produces the product. The requirements document is the source code. The architecture diagram is the implementation.

Organizations that thrive in 2026 will be those that recognize this shift and build practices around it. They will version their prompts with the same rigor they version their code. They will review changes to system instructions the way they once reviewed pull requests. They will invest in tools that trace outputs back to the intentions that produced them: not just “what did the agent generate?” but “what were we trying to achieve, and how did we describe it?”

This will require new skills. The ability to write precise, unambiguous specifications: long considered a secondary competency, something adjacent to “real” engineering will become primary. The engineers who advance will be those who can articulate exactly what they want in language that both humans and machines can interpret consistently. Prompt engineering, once dismissed as a transitional skill, will reveal itself as something more enduring: the craft of encoding human intent into machine-actionable form. Context engineering will go entirely mainstream.

Shared Mental Models

Software teams have always relied on shared mental models, that is the collective understanding of how systems work, why decisions were made, and where the bodies are buried.

These models live in documentation, certainly, but more often in the heads of long-tenured engineers, transmitted through code review, pair programming, and hallway conversation.

They are what let a team move fast without constant coordination, because everyone already knows the shape of the system.

Agentic development threatens these models in ways we are only beginning to understand.

When an agent writes code, it does not absorb the team’s culture. It does not know that we never use that library because it caused an outage two years ago, unless someone thinks to tell it. It does not know that this particular naming convention signals that a module is deprecated, or that this function is never called directly because it has subtle concurrency bugs that only manifest under load. The agent operates from its context window and its training, not from the accumulated wisdom of the people who have maintained the system.

The result is a kind of erosion.

Each agent-generated change that violates an unwritten norm is a small crack in the team’s shared understanding. Over time, the codebase drifts from what any human would have written. It becomes something alien: functional, passing tests, but organized according to principles that emerged from the intersection of training data and prompts rather than from deliberate human design.

In 2026, organizations will need to confront this erosion directly.

The most sophisticated teams will develop practices for maintaining alignment between agent behavior and human intent: explicit style guides that agents are instructed to follow, architectural decision records that get included in every prompt, persistent context documents that encode not just what the system does but why it does it that way.

They will treat the agent not as a tool but as a new team member who needs onboarding, who needs to be told things explicitly that the humans take for granted.

This is harder than it sounds. The knowledge that matters most is often tacit: the kind of thing engineers know but cannot easily articulate.

Extracting it, formalizing it, and encoding it in forms that agents can use will be a discipline unto itself.

Some organizations will develop “context curators” whose job is to maintain the living documentation that keeps agents aligned. Others will fail to do so and will watch their systems become unmaintainable as the humans who understood them gradually lose their grip.

The Hierarchy of Trust

When humans write code, we trust them differentially.

• A senior engineer’s changes might be approved with a glance (LGMT, am I right?)

• A junior engineer’s work probably gets scrutinized line by line.

This hierarchy of trust is one of the ways we scale: we don’t have infinite attention, so we allocate it based on track record.

Agents complicate this hierarchy. How much trust should we place in an agent’s output?

The answer is: it depends. It depends on the model, the prompt, the domain and the stakes. An agent generating a marketing page deserves different scrutiny than one modifying authentication logic. But our tools and processes are not yet built to encode these distinctions.

In 2026, I believe we will see the emergence of trust frameworks for agentic development. These will likely include tiered review processes, where agent-generated changes in high-risk areas trigger human review while low-risk changes flow through automatically. They will include automated auditing tools that flag deviations from established patterns or unexpected changes to sensitive code paths. They will include more sandboxing and monitoring that lets agent-generated code prove itself in staging before reaching production.

But the deeper challenge is epistemic. How do we know when we can trust?

The agent’s output might look correct, pass tests, and even seem well-designed… but “seeming” is exactly the problem. The history of software is littered with bugs that passed every test and fooled every reviewer, only to fail catastrophically in production.

When humans write such bugs, we conduct postmortems and update our practices. When agents write them at scale, the failure modes multiply.

The organizations that navigate this successfully will be those that develop a sophisticated understanding of where agent output can be trusted and where it cannot.

They will learn, through painful experience, which domains are amenable to agentic development and which require direct human implementation. They will build institutional knowledge about the failure modes of specific models, the kinds of prompts that produce reliable results, and the warning signs that something has gone wrong. This knowledge will become a competitive advantage and a form of operational expertise that cannot be easily copied.

The Role of the Human

What, then, is the role of the human in software development after 2025?

The honest answer is that we do not yet know. But the outlines are drawn.

Humans will become architects in a more literal sense than before. They will design the structures within which agents operate: the boundaries, the interfaces, the invariants that must be maintained. They will specify what should exist without necessarily specifying how it should be implemented. This is less a demotion than a shift in altitude and many will revel in the shift from writing code to designing systems, from solving problems to defining problems worth solving.

Humans will become judges. When agents produce multiple candidate solutions, humans will evaluate them not by reading every line but by assessing outcomes: Does it work? Does it perform? Does it behave correctly under adversarial conditions?

The skill will be less in writing and more in discernment: knowing what questions to ask, what tests to run, what edge cases to probe.

Humans will become curators of context. They will maintain the documents, examples, and instructions that shape agent behavior. They will decide what the agent should know, what principles it should follow, what constraints it should respect. This curatorial role is more important than it might sound. The agent’s output is only as good as the context it receives, and providing good context requires deep understanding of both the problem domain and the agent’s capabilities.

And humans will remain the locus of responsibility. When an agent-generated system fails, when it causes harm, when it does something its creators did not intend: a human will be held accountable. This is not merely a legal or organizational fact. It is an ethical one. The decision to deploy an agent, to trust its output, to put it in a position where it can affect the world and these are human decisions, and they carry human responsibility. No amount of automation can discharge that burden.

Who Thrives

The organizations that navigate 2026 successfully will not be those that adopt agentic tools fastest or most aggressively. They will be those that adopt them most wisely an that understand the tradeoffs, build the supporting practices, and maintain human judgment where it matters.

These organizations will invest heavily in specification and documentation, recognizing that these artifacts are no longer second-class citizens but the primary means. They will develop new roles and skills: context curators, context engineers, agentic architects, trust auditors. They will build tooling that surfaces the provenance of agent-generated code, that traces decisions back to the intentions and constraints that produced them.

They will also preserve space for human understanding. Not all code will be written by agents, and the code that humans write (the critical paths, the core logic, the places where getting it wrong is unacceptable) will be maintained with precision and craft.

There will be a premium on systems that humans can still reason about, still audit, still trust because they understand rather than because they have tested.

The organizations that maintain legibility, even at the cost of speed, will be the ones that avoid catastrophic surprises. They will ship more slowly and sleep more soundly.

The Shape of What’s Coming

None of this will be resolved in a year. The transition from human-authored to agent-assisted to agent-primary software development is a process that will unfold over the next few years at least.

But 2026 is when many of the hard questions will become unavoidable. It is when the early adopters will hit the limits of naive automation, when the true costs of illegible systems will begin to come due, when organizations will be forced to develop real answers rather than hopeful experiments.

The year ahead will not slow down. But if we are thoughtful, if we attend to context, to alignment, to the irreducible need for human understanding we might just keep pace.

FAFO is a cultural expression that has become a warning. Its a smug little phrase people deploy after someone’s hubris meets an unfortunate reality. Oh, you thought you could do that thing? You fucked around. You found out.

But what really bothers me is how we use this now. This phrase describes something that’s actually, most of the time really good. Fucking around and trying things without permission, without credentials, without certainty is how you learn anything that matters. And finding out? It’s feedback. That’s just reality telling you something you didn’t know before.

The common negative version of FAFO assumes the finding out will be bad. That you’ll be punished for your audacity. But that’s not how it usually works. Most of the time, when you fuck around, what you find out is: oh, this isn’t as hard as I thought. Oh, I’m actually kind of good at this. Oh, this is interesting in ways I didn’t expect.

My view is that tragedy is not contained within the people who fuck around and find out something painful. It’s the people who never fuck around at all.

Over the years I’ve watched a specific pattern play out with smart, successful professionals (especially in tech). They get good at something. They build an identity around being good at that thing. And then, almost without noticing, they stop trying things they might be bad at.

The backend engineer who “isn’t a frontend person.” The designer who “isn’t technical.” The PM who “can’t code.” These aren’t descriptions of reality. They’re descriptions of what someone tried once, found difficult, and then built a wall around.

The problem is the regret math is backwards.

We overweight the downside of trying something new because it might require a few hours spent fumbling, the ego hit of being a beginner, the possibility that we’ll produce something embarrassing. These feel like real costs because they’re immediate and visible.

We underweight the upside: the new capability that compounds over days, months and years, the unexpected obsession that reshapes your career, the connection between domains that only you can see because only you’ve been in both. These don’t feel real because they’re probabilistic and distant.

So we protect our identity as competent people by staying inside the walls we’ve built. We tell ourselves we’re being strategic. Focused. Playing to our strengths. But really we’re just scared to be bad at something in front of ourselves.

The asymmetry is this: the downside of fucking around is capped. A few hours normally. Some confusion. Maybe you feel dumb for a week. The upside is uncapped. You might find a new career. A new way of thinking. A capability that makes everything else you do more valuable.

And yet we act like the reverse is true. We act like trying something new is a cliff we might fall off, when really it’s a pool we’ve been sitting next to for years, dangling our feet in, convinced the water is colder than it is.

In 2025 the biggest thing that made me want to FAFO more and more is that we all know the time between “I wonder if I could build that" and "I have a working version of that" has collapsed.

This isn’t about AI doing the work for you. It’s about AI compressing the feedback loop. The fucking around happens MUCH faster. The finding out happens even faster still. Which means the cost of each experiment trends toward zero.

You used to need months of prerequisites before you could even start. Learn the language. Learn the framework. Learn the tooling. Learn the conventions. By the time you could try the thing you were curious about, you’d often forgotten why you were curious in the first place.

Now you can describe what you want and have a conversation about it. The AI doesn’t replace the learning: no you still have to understand what you’re building. But it changes the sequence. You can start with the interesting part. You can fuck around on day one.

This is especially true for knowledge workers who’ve spent years adjacent to technology without building it themselves. You’ve seen what software can do. You’ve spec’d it, managed it, used it, complained about it. You have taste and judgment and domain knowledge. What you didn’t have was a fast path from “I have an idea” to “I have a thing.”

Now you do.

I’m not arguing for recklessness. Some domains have real consequences for incompetence and you and I should respect that.

But most of the walls we’ve built aren’t about real consequences. They’re about identity. About the story we tell ourselves regarding who we are and what we’re capable of. And those walls have never been easier to climb over.

Its about to be 2026. The water isn’t cold. The jump isn’t far. The only thing you’ll find out is what you’re capable of when you stop waiting for permission to try.

So fuck around. Please. Find out something good.

There is a specific, quiet moment in the life of a high-functioning team when friction disappears. You have likely felt it. A sentence is started by one person and finished by another. A critical decision is made in the negative space between messages. The architecture emerges from a collective knowing that requires little verbalization.

Then, someone leaves. Or three people join. Or the roadmap pivots.

Suddenly you’re rebuilding something you didn’t know you had built.

When Marcus Aurelius wrote that we suffer more in imagination than in reality he was speaking of anxiety, but he might as well have been describing the cognitive physics of a software team at scale.

The suffering is the coordination and not the code.

It is the twenty-three minutes required to rebuild mental context after a single Slack ping. It is the invisible web of 190 communication pathways1 that entangles when a team of eight becomes a team of twenty.

Its not a management problem but rather one of physics and no amount of SAFe can repeal it.

Subscribe now

The Myth of the Beginner’s Mind

We romanticize the “beginner’s mind”. The idea that expertise is a trap and that knowing too much closes us off to possibility. This is beautiful in contemplative practice.

In a high-velocity environment, the opposite of beginner’s mind is shared understanding: the deep, accumulated context that allows a team to move with less explanation.

Recent research by Carraro et al., 20252 confirms what experienced leads know: teams do not just share code repositories, they share a “collective working memory.” This is a parallel internal representation of the system, the domain, and each other. It allows them to predict behavior without asking and to coordinate with less meetings.

The corollary to this is that cognition cannot be transferred. A new hire does not inherit the team’s memory they have to build it from scratch through the expensive, slow work of communication.

The Toggle Tax

We use communication tools to move faster and many make us slower.

Workers switch contexts every 11 minutes3, losing 20% of their cognitive capacity to the toggle tax alone. The platforms we built to reduce friction have become friction.

Technical debt lives in the repository. Cognitive debt lives in the mind and is the accumulated weight of context that must be reconstructed every time someone asks a “quick question.” We treat human attention as infinitely renewable. We piled on scope. We introduce tools that masquerade as help.

John Sweller’s Cognitive Load Theory names this problem. He identified three types of mental burden:

• Intrinsic Load: The irreducible complexity of the problem itself. You cannot reduce this without changing the product.

• Extraneous Load: The friction of the environment: bad docs, unclear ownership, meetings that should be messages.

• Germane Load: The productive energy of actually learning and building. This is where value lives.

The mandate is simple in theory but oh so difficult in practice: eliminate extraneous load to make room for germane load. If a meeting can be a document, the meeting is extraneous. If a tool requires constant context-switching, the tool is a liability.

The AI Bottleneck

This conversation is no longer optional because the constraints of software development in 2025 have clearly shifted.

For the last decade, we built systems knowing that human bandwidth was the bottleneck. Now, we are deploying AI tools that generate code faster than we can specify what to build. The bottleneck has moved from development speed to specification clarity.

Specification clarity is a function of shared mental models.

You cannot clearly specify to an agent what you do not collectively understand as a team. AI does not eliminate the need for alignment but it does amplify the cost of misalignment. Every underspecified prompt with missing assumptions becomes an error generated at scale and speed and will widen the intent gap4.

The teams that thrive in this new era will be the ones with the deepest shared understanding of the problem made explicit.

Aligned Autonomy

So, how do we defend this shared mind against the entropy of growth?

We must rely on thin interfaces. The best teams do not coordinate constantly but they do coordinate intentionally. They create “aligned autonomy” which means freedom within a framework. This requires a North Star clear enough to guide decisions and guardrails sturdy enough to prevent drift.

But mostly, it requires trust. Trust that mistakes are data. Trust that you do not need to be in the room for the room to function. Marcus had a meditation fitting of this moment when he wrote…

He was writing about mortality but read it as a statement on the lifecycle of a team.

We are all burning toward the same deadline, in the same shared space of attention. The incense that falls sooner isn’t better it is just sooner. The only thing that persists is the architecture we build in each other’s minds.

Because we know that shared understanding is the product. Everything else is just an artifact.