Every task I hand to Claude must be something a human could finish in 2-4 hours. Less than 2 hours, and I waste a lot of time delegating small tasks. More than 4 hours, and Claude makes too many mistakes. I came up with this rule somewhat arbitrarily, based on anecdotal observations from my engineering work. But surprisingly, I think it’s explainable by recent research from METR.

METR is a nonprofit that tracks how capable AI agents are getting over time, and they publish the chart below. I came across it on a recent Odd Lots episode where they were discussing the exponential growth of AI agents. I keep returning to it for a far more mundane reason — it is one of the best ticket-planning heuristics I have found.

Reading the Chart

The vertical axis is human time. A point at four hours means the model can complete a task that would take a skilled human about 4 hours, working autonomously, without further input. The headline trend is that this horizon has been doubling roughly every 7 months since 2019. As of early 2026 the frontier has crossed 4 hours at a 50% success rate.

The detail I care about most is that 50% success rate. Claude now correctly finishes most well-scoped, 4-hour tasks without further input from me. That is the threshold that matters to me: once an agent clears it, I can hand off work of that size and expect to leave most of it alone. I can write a ticket, hand it off, and then go do something else while the agent runs.

In practice, I believe my own success rate is higher than the chart’s baseline, because I have invested heavily in the scaffolding around the agent. All of my projects have a comprehensive CLAUDE.md, a mapping of the project layout, implementation playbooks for common tasks, and multiple skill files. Most of the time, the agent runs to completion without me.

The Cost of Delegation

For several months my rule has been to scope every ticket I hand to a coding agent to between two and four human hours. Not the wall-clock time the agent takes, which is usually minutes, but the time the task would have cost a competent human doing it by hand. The specific numbers are arbitrary. The shape of the rule is not. There is a floor and a ceiling, and they come from completely different places.

Below ~2 hours per ticket, I become the bottleneck. Every handoff takes more of my time.

• writing a crisp ticket with success criteria

• pulling my attention out of whatever I was doing

• waiting on the run

• reviewing what comes back

I pay that tax whether the underlying task was 20 minutes or 3 hours. But a frontier model dispatches a 20-minute task almost trivially.

Past about four hours of scope, tasks start failing too often. I have to come back in, intervene, or split the ticket into multiple parts and start over. The reliability decay the METR curve shows from a distance is the same decay I feel up close. Longer tasks accumulate more places to drift, and drift compounds on itself.

The cost of delegation is the sum of two things:

1. the coordination overhead, which is the fixed cost I pay every time I hand off a ticket

2. the expected cost of failure and rework, which grows as the task gets larger and more complex

Add them together and you get a U-shaped cost curve. On the left, with small tickets, coordination overhead dominates. On the right, with large tickets, failure and rework dominate. In between is the local minimum, and “two to four hours” is simply where it falls for me today, with current models.

The left wall likely will not change over time, because my coordination overhead is manual and roughly constant. The right wall is the agent’s reliability ceiling, which is exactly what the METR chart captures. As the METR time horizon doubles, the right wall slides outward, and the bottom of the U slides out with it. Every ~7 months, the largest task I can safely hand off grows by a factor of 2.

Which means my heuristic is not really “2-4 hours.” It is “find the local minimum.” The number is a snapshot in time, and we need to keep re-reading the curve as the wall moves.

(Near-) Perfect Information

I have argued before, in On Imperfect Information, that LLMs are a near-perfect replacement for action under near-perfect information. The hard part is turning a messy problem (e.g. feature request) into something close to perfect information, which I could hand off to Claude. Every time I hand off a ticket, I attach explicit success criteria:

• commands that must pass

• behavior that must hold

• the edge cases that must be handled

The agent can then check its own work, and catch a meaningful fraction of its own mistakes before handing anything back.

You are not making the LLM smarter. You are effectively shrinking the space it can drift into, and giving it a way to notice when it has drifted. A 4-hour task with a vague goal lives down near 50% success rate. The same task with a crisp specification and verifiable success criteria lives much closer to 80%.

This is why I front-load so much planning work before any code gets written. It comes in two forms:

The first is repository setup. A thorough project guide with a map of the codebase, plus short playbooks for the common moves like database migrations, new API endpoints, and new frontend components, means a large share of the information already sits in CLAUDE.md before I write any tickets.

The second is planning the tickets themselves. I like to plan interactively with Claude. I talk through the user flows, and as we go Claude proposes tickets that I review and refine before any of them get uploaded to Linear. I now spend more time planning tickets than implementing them, because the planning is what makes the implementation run smoothly.

The Babysitter

Most product and project management work is now, functionally, software work. I use the Linear CLI for tickets and the GitHub CLI for branches and pull requests, which means Claude can handle most project management work directly from the command line. Once individual tickets are available, the obvious next step is to stack them into sprints, and have Claude oversee the sprint end-to-end.

I’ve built a skill I call /speedrun. The main agent acts as a babysitter for a sequence of pre-scoped tickets. For each ticket it:

• cuts a fresh branch

• hands the ticket to a brand-new non-interactive sub-session

• creates a pull request

• waits on continuous integration

• patches any small bugs

• merges the PR into a feature branch

• moves to the next ticket

Then I review all of the changes on a feature branch, before any of it reaches main.

Here’s a basic version of the /speedrun skill I use in my actual projects, which you can also find in GitHub. (It can be more complicated for established projects, where I typically also integrate with testing/linting tools, add custom agent hooks, etc.)

---
name: speedrun
description: Run a sequence of pre-scoped tickets back-to-back, each in its own
  non-interactive Claude sub-session. Triggers on “/speedrun 41-46”.
allowed-tools: Bash, Read, Edit
---

# Speedrun

Drive a sequence of pre-scoped, execution-ready tickets to completion, one after
the next. You (the main agent) are the babysitter: set up branches, hand each
ticket to a fresh non-interactive sub-session, wait for CI, and merge the result.
Core assumption: these tickets are already scoped and reviewed. This is an
execution run, not design. If a ticket turns out to need real exploration, STOP
and hand it back to the human.

## 1. Set up one feature branch for the whole run

```bash
git checkout -b feature/<slug> && git push -u origin feature/<slug>
```

## 2. For each ticket, in order

Fetch the ticket and read its acceptance criteria:

```bash
linear issue view <id>
```

Branch off the latest feature branch:

```bash
git checkout feature/<slug> && git pull
git checkout -b ticket/<id>
```

Hand the ticket to a non-interactive sub-session. There are no special hooks here,
so the prompt itself tells the sub-session to commit and open its own PR:

```bash
claude -p --dangerously-skip-permissions “$(cat <<PROMPT
Implement exactly this ticket, no more and no less:
<title, description, and acceptance criteria from Linear>
When the work is done and the project’s typecheck and tests pass, commit your
changes, push branch ticket/<id>, and open a PR into feature/<slug>.
Follow CLAUDE.md conventions throughout.
PROMPT
)”
```

Watch CI, then merge into the feature branch:

```bash
gh pr checks <pr> --watch
gh pr merge <pr> --merge
```

If CI fails on something trivial (a missed import, a lint nit), fix it yourself on
the branch and re-push. If it needs real debugging, STOP and hand back to the human.

## 3. Wrap up

Report which tickets merged and which are blocked. Do NOT merge the feature branch
into main. That is the human’s review gate.

Using Opus 4.8, this babysitter works well for sequences of up to 5-6 tickets. For longer sequences, performance starts to degrade and /speedrun becomes less reliable.

This lines up neatly with the cost curve from earlier. I think it’s fair to say that 5-6 tickets is roughly 4 man-hours of project management time. Each ticket might reasonably take a human ~45 minutes to write, hand off, review, patch, and merge. On the other hand, a human manager’s span of control tops out around 5-7 direct reports, and human working memory holds about 7 items at once. Agents degrade for a structurally similar reason. Whether the binding constraint is the orchestrator’s context window or my own review attention, there is a ceiling on how much delegated state a single supervisor can hold before things start slipping through.

Guardrails make a big difference here. Notice this one line from the skill file:

If CI fails on something trivial (a missed import, a lint nit), fix it yourself on
the branch and re-push. If it needs real debugging, STOP and hand back to the human.

When a ticket stops being pure execution and starts needing exploration or design, the babysitter stops and hands the work back to me. Without that instruction, I’m not sure the end-to-end /speedrun workflow would be sustainable.

Shifting Responsibilities

None of this is an autonomous system, and I would not want it to be. I do the product and ticket definitions myself, including the interactive back-and-forth, user workflows, decisions about what a feature should and should not do, and the occasional insistence on a specific framework or implementation trick. I rarely write the full tickets by hand, since I offload that to Claude. But I own the creative direction, and I spot-check every ticket before uploading to Linear or kicking off the /speedrun.

This planning/creative/strategic phase of software development is becoming more demanding rather than less. I have written, in The Finite Work Fallacy, about why automating your most valuable work produces more human work instead of less. There is no fixed pile of tasks, so compressing the top of the queue only promotes the next item into the empty slot. Agents are taking more of the code implementation and execution. The highest-leverage work now requires more strategic judgment: deciding what to build, turning the mess into a specification, and recognizing when a task has deviated from your intended plan. The entire apparatus above is just a machine for routing as much work as possible into the part the agents are good at, so that I can spend my own attention on the part they are not.

The N-Hour Agent

Don’t get too attached to the “2-4 hour” heuristic. It is already going stale as I write this — assuming the US government re-allows Fable and future models for the general public. Claude Fable 5 sits in roughly the position that Mythos preview holds on that chart, and it comfortably handles 6+ hour chunks. If the 7-month doubling holds, by early next year I should be scoping 12-hour tickets and babysitting ~15 of them in a single `/speedrun` before quality breaks down.

The real heuristic is about trade-offs relative to the latest-generation agent capabilities. That trade-off is captured surprisingly well by a single chart from METR.

There is not a fixed amount of work. Automating the most important thing only promotes the second-most-important thing.

AI is automating more and more of our work, and yet the people closest to it report working more than ever. Dan Shipper said it clearly on Lenny’s Podcast recently, describing the strange feeling of having “so much automation, so much AI” while also working harder than before. He called it a paradox.

I don’t think it’s a paradox. I think it’s perfectly logical. The only reason it looks paradoxical is that it rests on an unspoken assumption: that there is a fixed amount of work to be done, so automating part of it should leave a smaller remainder and hand the rest of the day back to you. Drop that assumption and the “paradox” evaporates.

The Finite Work Fallacy

The premise is that work is a fixed quantity. You have a pile of tasks, the pile has a bottom, and any efficiency gain shrinks the pile and converts directly into free time. If that were true, then automating half your work really would give you half your time back, and the people most aggressively automating would be the most idle. I call this the “finite work fallacy,” because the premise is wrong.

Work is not finite. At any given moment there is a practically unbounded list of things that would be valuable to do, and the binding constraint is never the supply of valuable work. The constraint is your time and attention. Because the list is effectively infinite and your capacity is finite, you don’t work through the list. You only do the things that seem most important.

When the most important thing on the list becomes cheap, or fast, or fully automatable, you don’t stop working. If you compress the single most important thing you do, there is always a second-most-important thing that will now consume your time, and a third after that. The marginal value of each successive item may decline, but it does not hit zero, so you keep going. The queue never empties, because the queue was never finite.

The reason it feels like more work is that people still equate “work” with the technical output (the artifact they used to produce by hand), and they keep pouring mental and emotional energy into that layer even after the agent took over most of it. So the planning and prioritization that now fills their day registers as something extra, piled on top of a job they believe they are still doing in full. In reality, the focus just shifted. The execution stopped costing what it used to, the freed attention moved to the next constraint, and the brain quietly double-counts the part it no longer has to do.

Improving a Weakness Makes You Use It Less

There is another, less obvious explanation for this “fallacy” that comes from game theory. (Discussed nicely in The Art of Strategy, the same book I referenced in Burn the Ships.), It produces a result that sounds wrong the first time you hear it: getting better at a skill can cause you to use it less, not more.

Take tennis for example. Suppose your backhand is much weaker than your forehand. Your opponents are not stupid, so they play to your backhand relentlessly. You spend match after match hitting backhands under pressure, and over time, from all that forced practice, your backhand improves. Now the two strokes are roughly equal. Your opponents can no longer exploit the backhand, so they stop targeting it and start distributing their shots evenly. The result is that you get to use your better forehand more often than you did before. Improving the weakness was really a way of unlocking the strength.

“If your backhand is much weaker than your forehand, your opponents will learn to play to your backhand. Eventually, as a result of all this backhand practice, your backhand will improve. As your two strokes become more equal, opponents can no longer exploit your weak backhand... You get to use your better forehand more often; this could be the real advantage of improving your backhand.”

—Avinash Dixit and Barry Nalebuff, The Art of Strategy

The same logic shows up in basketball. LeBron James is right-handed, and defenses know it, so they might concentrate on stopping his right hand. The reason they can’t do so exclusively is that his left hand, while weaker, is still good enough to punish them if they overcommit. If he spends an off-season improving his left hand, the defense responds by honoring both, which frees his dominant right hand more often than before. The stronger his weak hand gets, the less he has to rely on it, because the threat of it does the work.

The tennis backhand and the basketball left hand are effectively constraints on production. They are the bottlenecks that limit how much you can do with your forehand or right hand, and they are the things that the opposing defense can reliably exploit. When you improve those weaknesses, you dissolve the bottleneck. The result is that you get to use your strength more often, not less.

Now map this onto software. For a long time, for a lot of founders and operators and even many engineers, the production of software was the weak hand. It was the bottleneck, the thing that had to be delegated to a small and expensive group of technical people, the stroke the opposing defense could reliably exploit. The naive expectation, now that AI has made that weak hand strong, is that we will all spend our days happily coding because coding finally got easy.

Game theory predicts the opposite. When the bottleneck dissolves, you don’t pour more of your time into the thing that is no longer scarce. Your attention reallocates to whatever is now the binding constraint. In practice that constraint is planning, prioritization, and judgment, which is to say the strategic layer that decides what the cheap execution should be aimed at. This reallocation is the engine underneath the “more work, not less” observation.

Execution Is Becoming Cheap

I’ve written before, in On Imperfect Information, about how I think LLMs are a near-perfect replacement for action under near-perfect information. Software is commoditized to the precise extent that you can hand an agent perfect operating instructions: clear goals, crisp constraints, complete context, and an unambiguous definition of success. The hard part is turning a messy, partially observable problem into something close to perfect information.

A junior-to-mid engineer used to spend the majority of the workday writing code, with planning and prioritization as a thin layer on top, often supplied by someone more senior. I expect that ratio to invert. A growing share of that engineer’s time (potentially an outright majority) goes to planning, sequencing, and defining constraints. This is not management overhead bolted onto an engineering job. It becomes the core of the technical job, and not only for engineers. Product managers and designers are converging on the same shape, because the same shift is happening underneath all of them at once.

This is yet another possible explanation for the “paradox.” Why would automating work produce more work rather than less? Because the work that survives automation is the judgment-dense work, which is harder per unit of time and exists in effectively infinite supply.

The “Burstiness” of Technical Work

I’ve argued elsewhere that the best work in a startup is “bursty” and phasic. The target is usually unclear at first, so you spend time talking to customers, brainstorming, and probing assumptions. But once the target comes into focus, you sprint at it with everything you have.

AI sharpens the “burstiness” of this cycle. If execution is cheap and getting cheaper, then “building something” largely reduces to a series of planning exercises, followed by intense periods of technical execution. The question becomes how clearly, precisely, and consistently you can define the order of tasks and the components that have to go into the system. Work that we used to file under management, technical leadership, or executive function is now a core part of what every individual contributor does.

The Second-Most-Important Thing

So there is no paradox. There is a fallacy, and once you name it the rest follows. Work is not finite — your time and attention is. Automating the top of the queue does not shrink the queue, it promotes the next item into that slot.

The people who feel busier with all of this automation are not victims of some cruel irony. They are the ones who correctly reached for the second-most-important thing the moment the first one got cheap.

In 1519, Hernán Cortés landed on the Mexican coast with about 500 men and eleven ships. Before marching inland to take on the Aztec Empire, he scuttled all but one of them. The story is usually told as motivational theater, a man with the spine to bet everything on a single roll. By eliminating retreat as an option, he changed the payoff matrix that every soldier under his command was solving. Cowardice and desertion were no longer strategies for his soldiers. The only rational move was to fight as hard as possible.

Avinash Dixit makes a version of this point in The Art of Strategy, and he traces the same pattern through Xenophon fighting with his back to an impassable ravine, William the Conqueror burning his fleet at Pevensey, and the Roman army making it a capital offense to fall behind in an attack. The mechanism is identical in every case. An advancing line is a coordination problem. A single soldier who hangs back slightly improves his personal odds of survival without meaningfully reducing the chance that his side wins. If everyone reasons that way, the attack collapses into a retreat. Commanders who can credibly remove the retreat option remove the bad equilibrium along with it.

The same mechanism describes, almost perfectly, what investors are actually looking for when they talk about a “missionary” founder.

The Cortés Founder

When external conditions are good, the math is easy for everyone involved in a startup. Demand is strong, the team is capable, capital is available, no competitor is breathing down the neck. The dominant strategy for the founder, the cofounders, and the early employees is to work hard and ride the upside. This is the equivalent of the army that is already winning. Every soldier wants to charge.

These ideal conditions can quickly fall apart for most startups.

• a pipeline stalls

• a competitor raises a war chest

• a key hire quits

• the macro environment turns

When these conditions compound, every individual at the company has an alternative that is rationalizable. The founder can wind the company down and take a senior role at a larger one. Cofounders can negotiate a soft landing. Senior engineers can interview anywhere. The expected value of “give up now” can quickly become competitive with the expected value of “keep pushing,” and the army is at risk of becoming a retreat.

A missionary founder is one for whom this second calculation does not work, because the alternatives have been removed from the matrix. Either the founder genuinely cannot imagine doing something else, or the consequences of stopping are so personally unacceptable that stopping is not on the table. The structural result is the same as Cortés on the beach: Quitting is a dominated strategy, the team reads this and updates its own expectations, and investors read this and write the check.

This is the part that gets lost in the standard pitch about “passion” and “drive.” The premium is not for the personality. It is for the structural property of having no exit. Two founders with identical résumés and identical products are not equally good bets if one of them has a credible alternative and the other does not. The one without an alternative will outwork the other on the marginal Tuesday at 11 p.m. when the demo is broken, and over a five-year company-building cycle, those marginal Tuesdays compound into the entire delta.

Conviction vs Desperation

Most founders arrive at this property from one of two directions, or a linear combination of them.

1. Conviction. The founder is so deeply committed to a particular technical or commercial worldview that abandoning it would feel worse than failing at it. Elon Musk and SpaceX is the canonical example. Several times during the 2008 era, the rational play was to let SpaceX die quietly and walk away with the PayPal money. Musk slept on the factory floor and put the last of his liquid net worth into the next launch. The framing inside his head was not “this venture has positive expected value.” It was “humanity needs to be multiplanetary, and I happen to be the person doing this.” That is a worldview, not a strategy, and it is not subject to revision when the bank account gets thin.

2. Desperation. The cost of failure is severe enough that the founder will not let it happen. For most first-time founders, this looks like some mix of personal financial exposure, public embarrassment in front of former colleagues, the prospect of laying off people they recruited and care about, and the reputational hit of carrying a visible failure into the next decade of their career. None of these are existential. In aggregate, they are bad enough that “fail and move on” is psychologically not a real option. The founder is, in effect, buying their own version of Cortés’s burned ship through a credible commitment to social and financial stakes.

These are not the same mechanism. They produce different micro-level behavior, especially under stress. A conviction-driven founder will spend a hard quarter doubling down on the original vision. A desperation-driven founder will spend the same quarter scrambling to protect the downside. The day-to-day instincts are not interchangeable, and any halfway competent investor or operator will read them differently in board meetings. But at the macro level, the effect is the same. Both keep the founder in the game past the point where the rational expected-value calculation says to stop. Cortés himself was acting from conviction. His soldiers, by his design, were acting from desperation. The game-theoretic output was identical: nobody on the beach was going to defect.

The harder question is what happens to founders who have already “won” by exiting a previous company, or raising a huge fund. The naive expectation is that money and reputation soften the structure. Once you have several hundred million dollars in the bank, a comfortable reputation, and a portfolio of other interests, the obvious defection penalties shrink. The missionary mindset should, in principle, weaken with success.

In practice, it usually does not, largely because of selection bias. Founders who succeed once and choose to do it again are not a random sample of wealthy people. They are the ones who found the experience compelling enough, or unfinished enough, to opt back in. Repeat founders are a positively selected pool. They are, on average, more risk-tolerant, more mission-driven, and more committed than the median first-timer.

To be clear -- missionary structure does not necessarily imply success. Most startups fail, including most startups led by deeply convicted founders. Plenty of obviously missionary founders have driven companies into walls, and plenty of measured founders have built generational businesses. Conviction is not a sufficient condition, and in cases like Theranos it can actively accelerate the failure. But holding the rest of the inputs roughly constant, the founder with no real path to defection has a narrow edge over a competitor working on something similar. That edge compounds, and over a long enough cycle it can be the difference between the company that survives a bad year and the one that does not.

Thrive Capital

The recent Colossus profile of Joshua Kushner and Thrive Capital is a long read on exactly this question. I should be upfront that what follows is third-hand. The Colossus piece is itself an interpretation of Kushner and the people around him by a journalist with his own framing, and I am layering my own reading on top of his. I have never met Kushner. I am not claiming this is the definitive account of what is going on inside his head. I am saying that from the outside, this is a coherent psychological profile to extract, and that the profile happens to map cleanly onto the game theory I was already trying to describe.

By any reasonable measure, Kushner is done. Thrive’s eighth fund put nearly two billion dollars into Stripe at a fifty-billion-dollar valuation, and Stripe is now valued at over one hundred billion. Thrive’s early position in OpenAI, taken at twenty-nine billion when no other firm was willing to anchor the round, is now anchored to a five-hundred-billion-dollar company. The firm holds stakes in Instagram, GitHub, Wiz, Anduril, Databricks, Cursor, and Isomorphic Labs, among others. Kushner is thirty-nine, married, has three children, and has more than enough capital to never work again. He could close the fund tomorrow and pass generational wealth to his descendants without a meaningful change in his lifestyle.

He has not stopped, and the reporting is not subtle about why.

Kushner’s grandparents were survivors of the Novogrudok Ghetto massacres. His grandmother Rae watched her mother be murdered through a window, watched her older sister machine-gunned into a pit with five thousand other Jews, and escaped through a six-hundred-foot tunnel her family dug at night with spoons. His grandfather spent three winters living in a dirt hole in the Naliboki Forest after watching the Nazis execute his mother and several sisters. They arrived in the United States in 1949 with no money. By the time Joseph Kushner died in 1985, he had built a real estate empire in New Jersey. Two decades after that, Joshua’s father went to federal prison. The family the Kushners had built spent the first half of Joshua’s life being inducted into the American establishment, and the second half being publicly rejected by parts of it.

Read against this background, Kushner is not a counterexample to the missionary pattern. The Colossus piece argues, and I largely agree, that the structure in his case is generational rather than personal. The reason he keeps building is not that he has run out of money or status to acquire. It is that the alternative, for someone with his lineage, is not really an alternative. To stop is to accept that the world’s verdict on his family is allowed to settle, and he has direct, intimate, video-recorded evidence of what “settling” can look like for people like him. The wealth, marriage, children, and access to political power do not relax the structure. The ships were burned two generations ago, and he cannot un-burn them.

Kushner himself describes the mechanism in less abstract terms:

“When you live with someone as resilient as she was and persevered through so much tragedy, you feel determined to make something of yourself. I am not first generation, but I grew up in a first-generation home. As a child, I was surrounded by the impossible.”

—Joshua Kushner

The same caveat applies to the rest of the firm, but Thrive looks unusually full of people for whom a similar story can be told. Kareem Zaki, one of the firm’s lead partners, is the son of Coptic Christians who fled Egyptian religious persecution and watched his father repeat his entire medical training from scratch in Cleveland. Nabil Mallick, the COO, is the son of a Pakistani immigrant who washed dishes at a Mexican restaurant while getting his masters and eventually built a civil engineering firm out of New Jersey. Vince Hankes grew up in Mount Clemens, Michigan, watching the Great Recession dismantle the auto industry and most of the families around him. Nitin Nohria, the executive chairman, fled the Naxalite insurgency in Calcutta as a child. The piece reads like a roster of people who came to a similar conclusion through different paths. Idleness is not available, because the world that produced their parents and grandparents is the world that is always one decade away from returning.

This is what investors are actually asking when they ask a founder about their “why.” They are not asking for a marketing slogan. They are asking whether the founder has a structural reason for not being able to stop, and whether that reason is durable enough to survive the year when nothing is working.

The Diagnostic Questions

The standard probing questions in a founder meeting collapse into the same test.

• Why do you want this?

• How badly do you want it?

• How much are you willing to suffer for it?

• What would you do if it failed?

• What would you do if you couldn’t do this?

The questions sound like motivational filler, and most of the time they get answered like motivational filler. The answer that should make an investor sit up is the one that reveals the founder has not seriously considered the alternatives, because the alternatives are not real to them. “I don’t know what I’d do if it failed” sounds like a weakness in a job interview. In a fundraising meeting, it is the closest thing to a structural guarantee that the founder will not defect at the first sign of trouble.

A polished, well-reasoned answer is harder to read. Some founders have thought carefully about exit ramps because they are good strategic thinkers, not because they intend to use them. The signal an investor is actually trying to extract is not “have you considered alternatives” but “are the alternatives real to you.” Those are different questions. A founder can have a clean answer for what they would do if the company failed and still treat that scenario as functionally outside the decision tree. The diagnostic value of the question is in the texture of the answer, not in whether the answer exists.

This is also the part of the founder profile that is essentially impossible to coach. Conviction can be cultivated to some degree, but a worldview deep enough to override personal interest is not something a founder decides to acquire on a Tuesday. Desperation can be manufactured, but the kind that lasts through a five-year company-building cycle has to be backed by real stakes. The honest version of the missionary founder filter is not “we are looking for people with grit.” It is “we are looking for people whose lives have already done the hard work of removing their alternatives, because we know we cannot do that work for them.”

What the investor is paying for is not the founder’s grit. It is the structural fact that, somewhere upstream of the pitch meeting, the ships were already burned.

For that reason, my goal isn’t to find a single “best” agent framework, but to identify a flexible, portable agent stack whose lessons transfer across projects. The ideal stack should make it easy to move between Python and TypeScript, swap model providers, preserve observability, avoid unnecessary cloud setup, translate between local/dev/prod environments, and prevent every company from being locked into one vendor’s end-to-end agent platform.

Cloud agnosticism matters to me more than it does to most projects. If the recommended stack requires a company to adopt Bedrock, Vertex, Kubernetes, or a large AWS/GCP/Azure setup, it won’t be usable by many of the companies I work with. They may already be on AWS, where a GCP-centric stack doesn’t translate. By contrast, more focused providers like Modal, Logfire, OpenRouter, Langfuse, and similar tools can usually be adopted regardless of whether the company’s main app runs on Vercel, AWS, GCP, Azure, Fly, Render, Kubernetes, or something else. The goal is to keep the agent infrastructure portable enough that it fits into the company’s existing deployment stack instead of forcing a major cloud decision.

The core recommendation is to standardize around portable model access, language-native agent code, OpenTelemetry-compatible observability, durable execution, and lightweight compute.

Agent Stack

The agent stack has six separable layers:

The preferred stack changes by use case:

This is more pragmatic than treating Temporal, LangGraph, or any other durable runtime as the default for every production agent.

For most agents, the ergonomic default is the OpenAI Agents SDK. Add E2B or Vercel Sandbox when the agent needs a place to execute code, install packages, manipulate files, or hold per-session state — Vercel Sandbox is the natural fit for Vercel/Next.js teams, E2B is the more provider-neutral default. Reach for Modal when the workload actually needs GPUs, beefier hardware, gVisor isolation, or Python-heavy ML compute. Add Vercel Workflows (Vercel/Next.js teams) or Temporal (selectively) when durable execution matters.

E2B, Vercel Sandbox, and Modal all integrate cleanly with the OpenAI Agents SDK, so the framework choice doesn’t lock you into any single compute layer.

Tier 1: Non-Production / Local / Exploratory Agents

For one-off scripts, internal tools, local experiments, and non-production-facing workflows, use:

OpenAI-compatible gateway + OpenAI Agents SDK + Logfire

This is the right stack when the agent is mostly request/response, has limited side effects, and doesn’t need durable retries or long-running state.

OpenAI Agents SDK is especially attractive here because it includes built-in tracing for LLM generations, tool calls, handoffs, guardrails, and custom events out of the box.

Useful references:

• OpenAI Agents SDK: https://developers.openai.com/api/docs/guides/agents

• OpenAI Agents SDK quickstart: https://developers.openai.com/api/docs/guides/agents/quickstart

• OpenAI Agents SDK tracing: https://openai.github.io/openai-agents-python/tracing/

• Logfire OpenAI integration: https://pydantic.dev/docs/logfire/integrations/llms/openai/

Tier 2: Lightweight Production Agents

My definition of “lightweight” is: agents that run for up to several minutes, have manageable retry and state management needs, and don’t have critical business impact if they fail occasionally. For these use cases, default to the same stack as Tier 1, but add a sandbox layer (E2B or Vercel Sandbox) for code execution, tool use, and per-session state:

OpenAI-compatible gateway + OpenAI Agents SDK + Logfire + E2B or Vercel Sandbox

For very lightweight TypeScript/web workloads, a secondary option is:

OpenAI-compatible gateway + OpenAI Agents SDK or Vercel AI SDK + Logfire + Vercel serverless + Vercel Sandbox

Most agent sandboxes have modest hardware needs (a few vCPUs and a few GB of RAM); the properties that matter are startup time, ergonomics, and per-session state. Both E2B and Vercel Sandbox fit that shape — see the Layer-by-Layer compute section for a deeper comparison and the heavier-compute escalation to Modal.

In this tier, it usually isn’t necessary to add a durable execution framework. Vercel Functions cap out at 300 seconds (Hobby) / 800 seconds (Pro/Enterprise) per invocation, which is fine for most short agent loops but a problem for longer-running ones — that’s where Tier 3’s durable layer (Vercel Workflows or Temporal) comes in.

Tier 3: Durable Long-Running / High-Stakes Agents

Use a durable execution layer when parts of the workflow are long-running, fragile, business-critical, or stateful enough that homegrown retry and checkpointing logic becomes risky. There are two solid defaults here: Vercel Workflows for Vercel/Next.js teams, and Temporal for platform-agnostic or deeply mission-critical workflows.

The stack becomes:

OpenAI-compatible gateway + OpenAI Agents SDK + Vercel/Temporal Workflows + Logfire/OTLP + E2B or Vercel Sandbox (with Modal for GPU/heavy compute)

Vercel Workflows as a hybrid orchestrator

Vercel Workflows (GA April 2026) sits between a generic compute layer and a durable execution framework. It gives you durable agent loops via use workflow / use step directives, sleeps and hooks that pause for minutes/days/months without consuming compute, resumable streams that survive a client reconnect, and deployment pinning so workflows keep running on the deployment they started on.

The key thing is that Vercel Workflows is the agent runtime, not the agent body. Workflow steps run on Vercel Functions / Fluid Compute and inherit those limits — no GPUs, modest CPU/RAM, and per-step caps (~300s Hobby, ~800s Pro/Enterprise). Heavy work still belongs in Modal, and code-execution/tool-use sandboxes still belong in E2B or Vercel Sandbox.

For a Next.js app, that produces a coherent stack:

For teams not on Vercel — or for workflows that need a language-agnostic, mission-critical engine with mature worker control, heartbeats, and explicit activity modeling — Temporal remains the right choice.

Temporal as a durable boundary

Temporal doesn’t need to replace the whole agent framework. A better, more incremental migration path is to use OpenAI Agents SDK for the main agent loop, then wrap with Temporal as needed.

For example:

This lets the team apply Temporal only where its durability semantics matter, while sandbox and heavy-compute concerns continue to live in E2B/Vercel Sandbox and Modal respectively.

Temporal makes sense when a workflow has one or more of these properties:

The goal isn’t to make every agent step a Temporal workflow — it’s to identify the parts of the agent graph where durability actually matters and put Temporal boundaries there. Sometimes the entire agent workflow is durable; more often, only one or two critical steps need Temporal while the rest stays in the more ergonomic OpenAI Agents SDK.

Temporal’s local dev experience is reasonable for teams already using Docker Compose. A local Temporal service can sit alongside Postgres, Redis, or S3-compatible storage:

This gives teams a local Temporal service and Web UI without requiring Temporal Cloud or running production infrastructure for small experiments.

Rule of thumb:

Use OpenAI Agents SDK for the agent loop. Use Vercel Workflows (Vercel/Next.js teams) or Temporal (selectively) for durable orchestration. Use E2B or Vercel Sandbox for the agent’s sandbox. Use Modal for compute-heavy execution and GPUs.

Useful references:

• Temporal local development server: https://docs.temporal.io/develop/run-a-development-server

• Temporal CLI server docs: https://docs.temporal.io/cli/server

• Temporal Docker image: https://hub.docker.com/r/temporalio/temporal

• Temporal OpenAI Agents SDK integration: https://docs.temporal.io/ai-cookbook/openai-agents-sdk-python

• Temporal agentic loop example: https://docs.temporal.io/ai-cookbook/agentic-loop-tool-call-openai-python

• Temporal Python integrations: https://docs.temporal.io/develop/python/integrations

• Temporal TypeScript integrations: https://docs.temporal.io/develop/typescript/integrations

Why Not Default to Temporal?

As powerful as Temporal is, it adds complexity, latency, and one more layer of abstraction between the agent and the user/developer. Its local development story is workable, but still less ergonomic than running a pure SDK-based agent locally. Its integrations are useful, but not uniformly mature across Python and TypeScript — the TypeScript AI SDK integration in particular should be treated with caution while it’s still in preview.

The latency cost is real. Every Temporal-backed step crosses the boundary between application code and the Temporal worker/server: workflow tasks, activity tasks, and event-history persistence all add round trips that a pure in-process agent loop doesn’t pay. For short, latency-sensitive agent steps, that overhead can be larger than the work being durable-wrapped in the first place.

Temporal’s abstractions also shift how the developer reasons about the agent: code splits into workflows and activities, side effects must be pushed to activity boundaries, retries and timeouts move into Temporal config, and debugging often means reading event histories rather than stack traces. That’s a worthwhile trade for genuinely durable workflows, but it’s a meaningful tax on the day-to-day developer and user experience when the workflow doesn’t actually need durability.

For lightweight production agents, it isn’t a huge lift to build basic retry, state hints, checkpointing, and error recovery directly in Python or TypeScript. If the workflow only runs for a few minutes and occasional failures are acceptable or easily recoverable, Temporal is more overhead than value.

The better escalation path is:

Each layer earns its place by solving a specific problem: OpenAI Agents SDK for building the agent, E2B/Vercel Sandbox for a sandbox to act inside, Modal for heavy compute or GPUs, Vercel Workflows or Temporal for durable execution. Don’t pull in any of them before the corresponding problem actually shows up.

The LangChain Stack

The most common/popular alternative to my preferred stack is:

LangGraph + LangSmith + LangSmith Deployment

This is popular because it’s the closest thing to a one-stop-shop for agent development, tracing, evals, and deployment.

This stack is attractive if a team wants an integrated agent platform and is already comfortable with LangChain abstractions.

Personally, I wouldn’t treat it as the generic default. LangSmith can trace non-LangChain frameworks, but deploying those frameworks through LangSmith generally means wrapping them in LangGraph-style entrypoints. That’s useful, but it’s still a form of lock-in -- everything eventually becomes LangGraph-shaped.

LangSmith Evals are a real advantage. Logfire doesn’t give you a full eval platform out of the box. But generic traces plus separate scoring jobs can cover most eval workflows while keeping the stack more portable.

Langfuse is also worth mentioning here, but it isn’t part of the LangChain stack. It’s an independent open-source LLM observability/evals platform, and a good alternative to Logfire or LangSmith when self-hosting or OSS posture matters.

Useful references:

• LangSmith Deployment: https://docs.langchain.com/langsmith/deployment

• Deploying other frameworks to LangSmith: https://docs.langchain.com/langsmith/deploy-other-frameworks

• Langfuse observability: https://langfuse.com/docs/observability/overview

The Claude / Anthropic Stack

Anthropic deserves its own category. The Claude stack is more specialized than the LangChain stack, but it’s significant because it’s very strong for coding agents and file-based workflows.

The relevant stack is roughly:

Claude API + Claude Agent SDK + Claude Managed Agents

The biggest advantage of the Claude stack is that Claude Agent SDK exposes the same core tools, agent loop, and context management that power Claude Code. It can read files, run commands, search the web, edit code, use hooks, subagents, MCP, permissions, sessions, and more. That makes it especially attractive for coding agents, repository agents, local-file workflows, CI agents, migration agents, and internal developer tooling.

The biggest downside is lock-in. Claude Agent SDK is built around Anthropic’s API and Claude Code-style execution model. Anthropic does offer an OpenAI SDK compatibility layer, but its own docs describe that layer as intended for testing and comparison, not as the long-term production path for most use cases. Several Claude-native features require the native Claude API.

Claude Managed Agents takes this further by offering a managed harness and infrastructure for running Claude as an autonomous agent. It can run long-running sessions in managed containers, persist event history, read and write files, run shell commands, browse the web, and execute code securely. This is powerful, but it couples the application to Anthropic’s model API, agent harness, managed runtime, and deployment environment.

This LLM provider lock-in makes me especially nervous. A lot of developers have already switched from Claude Code to other coding agents (either local or another provider), because of Anthropic’s (1) restrictive rate limits and (2) high costs for models like Opus 4.7. The LLM is a critical, low-level dependency for agentic products, and I’d hesitate to lock my company into a single provider’s models and API.

Recommendation: treat Claude Agent SDK as a strong specialized choice for coding agents, not the default generic agent framework.

Useful references:

• Claude Agent SDK overview: https://code.claude.com/docs/en/agent-sdk/overview

• Claude Agent SDK observability: https://code.claude.com/docs/en/agent-sdk/observability

• Claude Managed Agents overview: https://platform.claude.com/docs/en/managed-agents/overview

• Anthropic OpenAI SDK compatibility: https://platform.claude.com/docs/en/api/openai-sdk

• Anthropic Managed Agents engineering writeup: https://www.anthropic.com/engineering/managed-agents

Layer-by-Layer Recommendations

1. LLM / AI Gateway

Recommended default: preserve an OpenAI-compatible boundary wherever possible.

The gateway should be boring. Route requests, manage keys, track spend, support fallbacks, and avoid trapping the app behind one provider-specific interface.

Useful references:

• Vercel AI Gateway: https://vercel.com/docs/ai-gateway

• Pydantic AI Gateway: https://pydantic.dev/docs/ai/overview/gateway/

• OpenRouter API docs: https://openrouter.ai/docs/api/reference/overview

• OpenRouter FAQ: https://openrouter.ai/docs/faq

• Anthropic OpenAI SDK compatibility: https://platform.claude.com/docs/en/api/openai-sdk

2. Agent Framework

Recommended default: OpenAI Agents SDK.

Use PydanticAI for Python-heavy Pydantic shops, Vercel AI SDK for TypeScript-heavy product teams, and LangGraph when the team has already chosen LangChain.

Use Claude Agent SDK when the agent is meaningfully Claude Code-like: codebase navigation, file edits, shell commands, repo repair, migration agents, test-writing agents, or local developer automation.

Useful references:

• OpenAI Agents SDK: https://developers.openai.com/api/docs/guides/agents

• PydanticAI overview: https://pydantic.dev/docs/ai/overview/

• Vercel AI SDK agents: https://ai-sdk.dev/docs/agents/overview

• Claude Agent SDK overview: https://code.claude.com/docs/en/agent-sdk/overview

3. Observability

Recommended default: Logfire.

Use LangSmith when eval UX and LangGraph-native workflows matter more than portability. Use Langfuse when open-source/self-hosted observability is important. Use Claude Agent SDK’s OTLP export when the agent is intentionally Claude-native.

Useful references:

• Logfire OpenAI integration: https://pydantic.dev/docs/logfire/integrations/llms/openai/

• Logfire general observability: https://pydantic.dev/logfire

• PydanticAI Logfire integration: https://pydantic.dev/docs/ai/integrations/logfire/

• Vercel AI SDK + Logfire / OTEL: https://pydantic.dev/articles/vercel-ai-sdk-logfire-otel

• Langfuse observability: https://langfuse.com/docs/observability/overview

• Claude Agent SDK observability: https://code.claude.com/docs/en/agent-sdk/observability

4. Raw Compute

Recommended default: Vercel Workflows (Vercel/Next.js teams) as the durable orchestrator and lightweight host for the agent loop; E2B or Vercel Sandbox for the agent’s sandbox; Modal for GPU and heavy compute.

Note: Vercel Workflows is my only recommended framework that is not language-agnostic. The Workflows SDK only exists for TypeScript, but the developer experience is so good that I think it’s worth it. It actually does not lock you into the Vercel ecosystem either, because the Workflows SDK can run locally or anywhere with a Node.js runtime.

Vercel Workflows is the agent runtime, not the agent body — it handles durable steps, sleeps, hooks, retries, and resumable streams, but its steps run on Vercel Functions / Fluid Compute and inherit those limits (no GPU, modest CPU/RAM, ~300s Hobby / ~800s Pro per step). Heavy work and code-execution sandboxes still belong in dedicated layers. Outside the Vercel ecosystem, the equivalent role is filled by Temporal (selectively) plus whatever web/runtime compute the rest of the app uses.

Most agentic workloads have modest hardware needs but care a lot about sandbox startup time, ergonomics, and per-session state — which is exactly the shape E2B and Vercel Sandbox are built for. Pick Vercel Sandbox when the rest of the app already lives on Vercel/Next.js; pick E2B when provider neutrality, longer session limits, or memory-preserving pause/resume matter more.

Reach for Modal only when the workload actually needs GPUs, beefier hardware, gVisor isolation, or Python-heavy ML compute (model serving, embeddings, batch inference, fine-tuning, image generation). A common production pattern is Vercel Workflows orchestrating the agent loop, E2B or Vercel Sandbox for the agent’s sandbox, and Modal-hosted endpoints for the heavy bits.

A useful split:

Useful references:

• OpenAI Agents SDK sandbox providers: https://developers.openai.com/api/docs/guides/agents/sandboxes#sandbox-providers

• E2B documentation: https://e2b.dev/docs

• Vercel Sandbox: https://vercel.com/docs/vercel-sandbox

• Building an agent with OpenAI Agents SDK and Vercel Sandbox: https://vercel.com/kb/guide/building-an-agent-with-openai-agents-sdk-and-vercel-sandbox

• Modal GPUs: https://modal.com/docs/guide/gpu

• Modal sandboxes: https://modal.com/docs/guide/sandbox

• Vast.ai docs: https://docs.vast.ai/

• Vercel Workflows: https://vercel.com/docs/workflows

• Bedrock AgentCore: https://docs.aws.amazon.com/bedrock-agentcore/

• Google Agent Runtime: https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/runtime

• Claude Managed Agents: https://platform.claude.com/docs/en/managed-agents/overview

5. Durable Execution

Recommended default: application-level retries/checkpoints for lightweight agents; Vercel Workflows when the team is on Vercel/Next.js; Temporal when the workflow is platform-agnostic or mission-critical enough to justify its depth.

Don’t reach for any durable runtime just because the agent is production-facing. Reach for one when a workflow or sub-workflow is long-running, failure-prone, high-stakes, or stateful enough that simple retry and checkpointing logic becomes a liability.

Useful references:

• Vercel Workflows: https://vercel.com/docs/workflows

• Vercel Workflow SDK: https://github.com/vercel/workflow

• Temporal OpenAI Agents SDK integration: https://docs.temporal.io/ai-cookbook/openai-agents-sdk-python

• Temporal OpenAI Agents SDK Python integration repo: https://github.com/temporalio/sdk-python/blob/main/temporalio/contrib/openai_agents/README.md

• Temporal local development server: https://docs.temporal.io/develop/run-a-development-server

• Claude Managed Agents: https://platform.claude.com/docs/en/managed-agents/overview

• LangSmith Deployment: https://docs.langchain.com/langsmith/deployment

TL;DR

General advice:

1. Start simple, but don’t build accidental infrastructure.

2. Pick the frameworks based on language and use case.

3. Avoid vendor lock-in where possible.

4. Standardize on layers, not platforms.

Implementation advice:

• Start with OpenAI Agents SDK.

• Add Logfire or another OTLP-compatible observability platform.

• Add E2B (provider-neutral) or Vercel Sandbox (Vercel/Next.js-native) when agents need a sandbox to act inside.

• Add Modal when agents need GPUs, beefy hardware, or Python-heavy ML compute.

• Add Vercel Workflows when a Vercel/Next.js app needs durable agent loops, retries, sleeps, hooks, or resumable streams.

• Add Temporal when the workflow is mission-critical enough to justify it.

Does the venture capital funding schedule create the power law, or does the power law necessitate the venture capital funding schedule?

Every venture capitalist I have ever spoken with treats the power law as received wisdom. A small number of investments generate the vast majority of returns, while most return little or nothing. The numbers are stark: roughly 4% of venture investments produce the bulk of a fund’s gains, and about 65% return less than the invested capital. Y Combinator is a famous case. In Paul Graham’s 2012 essay Black Swan Farming, he noted that just two of YC’s investments -- Airbnb and Dropbox -- accounted for about three-quarters of the portfolio’s total value. Horsley Bridge, a major LP, found that just 5% of capital deployed between 1985 and 2014 generated half of all returns.

The entire industry is structured around this fact. Fund strategy, portfolio construction, deal terms, follow-on reserves -- all of it assumes the power law as a given. But I have never heard a satisfying explanation for why venture returns follow a power law in the first place. Is the funding structure merely capitalizing on a naturally occurring distribution? Or is it actively producing the distribution it claims to exploit? To answer that, we need to look at the mathematics of power laws and then map those mathematics onto the mechanics of venture fundraising.

How Venture Fundraising Works

Venture capital fundraising is broken into stages designed to reduce risk for each investor and size investments appropriately. The standard schedule starts with a pre-seed round, then seed, then Series A, B, C, D, and so on, for however many rounds the company needs before it either gets acquired or goes public. In each round, the company issues new shares and gives equity to investors in return for capital. A typical round dilutes existing shareholders by around 20%.

Each successive stage assumes a certain level of maturity for the company, whether that is measured in employees, revenue, or product traction, as well as a certain amount of risk for the investor. The amount of capital invested typically increases with each round, and some percentage of companies that raised the previous round fail to survive long enough to raise the next one.

To ground this in recent data: median round sizes range from about $500K-$1M at pre-seed, to $2-4M at seed, $10-12M at Series A, ~$30M at Series B, ~$50M at Series C, and $100M or more at Series D and beyond. Post-money valuations follow a similar exponential curve: $5-6M at pre-seed, $12-15M at seed, $40-45M at Series A, $50-105M at Series B, $100-250M at Series C, and $500M or more at Series D.1

Meanwhile, the graduation rates tell the other half of the story. About 67% of pre-seed-funded startups raise a seed round, but only about 33% of seed-funded startups make it to Series A. That seed-to-A chokepoint is the narrowest bottleneck in the venture funnel. After Series A, the odds improve: roughly 65% of Series A companies raise a Series B, about 75% of Series B companies reach Series C, and 80% or more of Series C companies raise a Series D. The funnel is widest at the top and tightest at the seed-to-A transition, then gradually relaxes as the surviving companies prove themselves.2

It’s not immediately obvious from this description alone why venture outcomes should follow a power law. To see why, we need to understand what a power law actually is, mathematically, and what kinds of processes generate one.

Three Coin-Flip Games

To build some intuition for power laws, let’s compare three different games involving coin flips, which produce three fundamentally different probability distributions.

Game 1: Additive payoffs. You flip a fair coin 100 times. For every heads, you earn $1.

By the central limit theorem, your expected earnings are $50, and the distribution of outcomes across many players approximates a normal distribution centered around $50. The fair price to play this game is anything below $50.

This is the distribution most people intuitively expect. Outcomes cluster around the mean, and extreme results are rare.

Game 2: Multiplicative payoffs with symmetric risk. You start with $1. For each of 100 flips, if you get heads, your current amount is multiplied by 1.1. If tails, it is multiplied by 0.9.

The expected value after any single flip is unchanged, because

So the overall expected value of the game is $1.

But the distribution of outcomes is not normal. Because the payoffs are multiplicative rather than additive, the logarithm of the outcome is what accumulates additively. By the central limit theorem applied to log⁡(X), the distribution of final values follows a log-normal distribution. The majority of players end up with less than $1 (the median is below the mean), and there is a long right tail of players who end up with significantly more. The game is fair in expectation but deeply asymmetric in practice.

Game 3: Multiplicative payoffs with elimination. You start with $1. Each round, I double your money. You keep playing until you flip tails, at which point the game ends.

The probability of surviving exactly n rounds is (1 / 2^n), and the payout after n rounds is (2^n). If we try to compute the expected value of this game, each term in the series contributes equally:

The expected value is infinite. This is the St. Petersburg paradox, famously analyzed by Daniel Bernoulli in 1738. More importantly for our purposes, we can directly derive the probability distribution for a payout x:

This is a power law, specifically a Pareto distribution with exponent α=1. The probability of an outcome x is inversely proportional to x itself.

A pareto distribution:

can also arise whenever the round-by-round multiplier is roughly inversely proportional to the probability of continuing the game. The third game used a fair coin and a doubling multiplier, but it generalizes easily. Consider a weighted coin where the probability of tails (elimination) is 2/3 and each surviving round triples your money. The probability of surviving n rounds is (1 / 3^n), and the payout is (3^n). Substituting, we get the same power law:

In fact, I could derive a power law from a far more convoluted set of rules. Round one might use a fair coin with a 2x multiplier, round two a weighted coin with a 3x multiplier, round three a differently weighted coin with a 1.5x multiplier, and so on. The specific numbers don’t matter. What matters is the structural relationship: the multiplier in each round is roughly inversely proportional to the probability of surviving that round. When that condition holds, the resulting distribution of outcomes is a power law.

The Venture Capital Coin Flip

Now consider the venture fundraising schedule through this lens. Each funding round is a “round” of the game. The company either survives to raise the next round or it does not. If it survives, its valuation increases by some multiplier. If it doesn’t, the game is over.

To make the comparison concrete, here is the coin-flip game with a fair coin and 2x multiplier:

And here is the approximate venture capital equivalent:

The coin-flip game has a uniform 50% survival rate and a uniform 2x multiplier. Venture capital is messier, but the qualitative pattern is the same. Multiplicative payoffs, compounded across multiple rounds, with elimination at each stage. The seed-to-Series-A transition has the lowest survival rate (~33%) and the largest valuation jump (~3x). Later stages have progressively higher survival rates (65%, 75%, 80%) but smaller relative valuation increases. The relationship between survival probability and valuation multiplier is roughly inverse: where the odds of advancing are worst, the payoff for surviving is greatest. That is Game 3, not Game 1 or 2.

I should be honest about what this comparison glosses over. The fundraise round size does not exactly equate to the company’s market value. A company might raise $20M at a $100M valuation, but that does not mean someone would pay $100M to acquire it. It just means that is the prospective valuation the founders and the venture firm agreed to. By the same logic, it’s not quite right to say that every company can “cash out” at its last valuation when it fails to raise the next round, the way a player in the coin-flip game walks away with their current payout when they flip tails. Valuation is not the same as market value.

This simplified model also ignores deal mechanics that matter in practice: pro rata rights, preferred stock, SAFEs, convertible notes, down rounds, bridge rounds, angel investors, and secondary markets. These are real and consequential features of the venture landscape, and I won’t pretend to account for all of them here.

But our simplified model of venture capital appears to correctly predict the key empirical phenomenon, the power law distribution of returns, via analogy with an even simpler model of coin-flip games. That is worth something, even if the model is imperfect.

Causation, Correlation, and the Chicken-or-Egg Problem

Is it possible that the venture fundraising schedule actually causes the power law distribution that it is supposedly built to capitalize on? It would be a mistake to conclude that because our simple model predicts the power law, the funding schedule must be the root cause. So let me take the opposing viewpoint and ask what other mechanisms could produce a power law in startup outcomes, independent of the funding structure.

One argument is that businesses themselves self-organize into a Pareto distribution through direct and indirect competition. Some companies are run more efficiently than others. Some founders are more resourceful. The quality of early employees can shape a company’s trajectory. Could this produce a power law on its own?

Recall the three coin-flip games. In order for a process to produce a power law rather than a normal or log-normal distribution, each successive stage needs to have a multiplicative, strictly positive effect on the company’s overall value.

If injecting capital leads only to an additive increase in company value (Game 1), venture investment is unlikely to be profitable.

• An aimless startup with no clear product-market fit, where more money simply buys more time without compounding value.

• A company that uses each round to fund an unrelated product line rather than building on its current traction — the returns add up, but they don’t compound.

• A services business that scales by adding headcount, where revenue grows linearly with bodies and capital buys capacity, not growth rate.

If capital injection is multiplicative but carries a meaningful chance of decreasing the company’s value (Game 2), the distribution of outcomes is log-normal at best, not a power law.

• A company with unclear leadership, where scaling up could multiply value or could turn the whole operation into a disorganized mess.

• A company whose customer acquisition cost exceeds lifetime value, where every dollar spent on growth actively destroys value.

• A company that scales headcount faster than its organization can absorb, where new hires multiply coordination overhead instead of output.

The expected outcome is still non-negative, but individual outcomes are often mediocre.

It’s only the companies where capital injection is a multiplicative, strictly positive force that generate power-law outcomes (Game 3). These are the companies with the strongest compositions, the most defensible competitive advantages, and the clearest leadership. When isolated from the rest, these companies could plausibly constitute a power law regardless of the specific funding schedule. Whether the rounds increase by 2x or 5x is beside the point. What matters is the underlying growth mechanics.

But the venture fundraising schedule preferentially eliminates the non-power-law companies. With each round, as investors learn more about a company’s product, leadership, and market dynamics, it becomes easier to identify which startups will not exhibit positive, multiplicative returns on invested capital. By the time a company reaches late-stage funding (Series C or beyond), theoretically only companies with power-law mechanics remain. Much of the remaining “survival rate” at that point comes down to external market factors and whose growth rate is the largest and most stable. In a sense, the venture fundraising schedule necessitates that the surviving companies follow a Pareto distribution.

Now consider the reverse. Suppose that in the early days of modern venture investing, many firms did not use the staged funding structure that exists today. Suppose firms wrote smaller, more conservative checks in exchange for less equity, with less pressure on companies to demonstrate rapid growth between rounds. Startup survival rates would have been higher (though formation rates would likely be lower), leading to a flatter, more log-normal distribution of outcomes.

In that world, the few investors who did recognize the power law of elite companies, and structured their investments accordingly, would have seen outsized returns. Their LPs would have noticed. Capital would have flowed toward those successful funds and away from the conservative ones. The investor ecosystem itself would self-correct, converging on the funding structure that maximizes for power-law outcomes.

The Uncomfortable Answer

Neither the funding schedule alone nor the startups alone produce the power law. It is the combination of the two.

The staged funding structure applies selective pressure, pruning companies that do not demonstrate multiplicative growth. The companies that survive apply pressure back, forcing investors to adapt their strategies or lose out on the best returns. The relationship between startups and investors is simultaneously collaborative and competitive. Each side shapes the other’s behavior, and a power law emerges from the tension between them.

That may be unsatisfying. We want clean causation, A causes B. But the honest answer is a feedback loop, and the power law is what falls out of it.

If coding is solved, why are the people who solved it paying half a million dollars for coders?

Over the past year, Dario Amodei has made increasingly bold claims about the state of software engineering. At the Council on Foreign Relations in March 2025, he said AI would be “writing 90% of code” within three to six months. At Davos in January 2026, he told The Economist that “most, maybe all” of what software engineers do would be handled by AI within the year. He has repeatedly stated that engineers at Anthropic no longer write code themselves, instead letting Claude produce first drafts while they edit and supervise.

Meanwhile, people say that Anthropic’s job postings tell a different story. Software engineers with five or more years of experience are listed at $315,000 to $560,000 in base salary alone. Total compensation packages, including equity in a company valued north of $60 billion, push well past $500,000 and reportedly reach as high as $880,000. Anthropic is not quietly winding down its engineering organization. It is aggressively hiring some of the most expensive talent in the industry.

The reaction is predictable: “Hypocritical.” “Contradictory.” “They don’t actually believe their own claims.” I think this reading is wrong, and not just slightly wrong. The $500,000 salary and the “coding is solved” claim are not in tension. They are two expressions of the same underlying shift.

The Automation Bar

Suppose that coding really is 80-90% solved, or getting close to it. What does that actually imply?

It implies that a large share of the tasks historically performed by software engineers can now be completed by AI agents at a fraction of the cost and time. Bug fixes, boilerplate, straightforward feature implementation, standard CRUD operations, routine refactoring. The work that filled the calendars of mid-level engineers for the past two decades is increasingly automatable.

But “90% of coding tasks” is not the same as “90% of engineering value.” The remaining 10% is where the hard problems live: system architecture with long-term consequences, novel problem formulation, defining what to build and why, and making judgment calls under imperfect information. These tasks require deep expertise, taste, and contextual understanding that current AI systems cannot replicate.

This is what I think of as the automation bar. Below it, the work can be done cheaper and faster by an AI agent. Above it, the work still requires a human with genuine expertise. As the bar rises, the humans who operate above it become more valuable, not less, because their leverage has increased dramatically. A single engineer who can define problems clearly, set up the right guardrails, and direct AI agents effectively can now produce the output that previously required a team of five or ten.

This is not a new dynamic. It is the Steve Jobs principle taken to its logical extreme. Jobs famously observed that in many industries the “best” is ~30% better than average, but the best software engineers were ~50x better than the average engineer. The Mac team was built on the premise that a small group of A-level players could outperform a much larger team of mediocre ones. AI has made that multiplier even more extreme. A truly elite engineer with AI tools is now >100x more productive than average, because the average engineer’s core output is increasingly achievable by the tools themselves.

The Economics of Scarcity

If you accept the automation bar framing, the compensation picture becomes straightforward supply and demand.

The demand for high-quality software output has not decreased. It has increased, and in two distinct ways. Total venture funding in AI surged in 2025, with U.S. startup funding up over 75% in the first half of the year alone. That capital is heavily concentrated in a small number of very large companies, and it represents a growing pie of potential compensation for the engineers building those platforms. But the more interesting signal is company formation. The number of newly formed startups, particularly small, AI-native ventures, has sharply accelerated. Many of these are founded by software engineers and adjacent skill sets moving into entrepreneurial roles as demand for traditional enterprise engineering work declines. The most telling data point is the divergence: software engineer job postings are up 11% year-over-year according to Indeed, even as Bureau of Labor Statistics data shows “computer programmer” employment has fallen 27% since 2023. Companies are hiring more engineers and fewer coders. They want people who can think, not just people who can type.

The effective supply of engineers who operate above the automation bar has not kept pace. It may have shrunk in relative terms, because the bar itself keeps rising. The pool of people who can define complex systems, make architectural decisions with incomplete information, and direct AI agents productively is small. It was always small. Companies used to need those people plus a large supporting cast. Now they mostly just need those people.

So the price goes up. The value an elite engineer creates at Anthropic’s scale massively outweighs their cost. Paying $500,000 for someone who generates $5 million in value is not a contradiction. It is a bargain.

Professional sports illustrate where this leads. In Major League Baseball, the average salary in 2025 was $5.16 million, but the median was just $1.35 million. The top 50 players earned 29% of all salary dollars. Shohei Ohtani’s contract with the Dodgers is worth $700 million over ten years. The gap between a replacement-level player earning the league minimum and an MVP-caliber player earning $40 million a year is not a 50x difference in raw athletic ability. It reflects the economics of a winner-take-most market, where elite performance has no substitute and commands disproportionate compensation.

Software engineering is becoming that kind of market. The median engineer’s core output is increasingly reproducible by AI, the same way a replacement-level outfielder’s production can be approximated by any number of available alternatives. The engineer who can architect a system that scales, define the right product to build, and multiply their output through AI tools has no cheap substitute. The compensation reflects the scarcity, not the contradiction.

Where This Goes

I expect this dynamic to accelerate. There is an economic principle called the Jevons Paradox: when technology makes a resource cheaper to use, people don’t use less of it. They use more. If AI makes building software 10x cheaper, we will not build the same amount of software with 90% fewer engineers. We will build 100x more software. The sharp increase in new company formation, driven largely by engineers and technical founders who can now build products that previously required entire teams, points in exactly this direction.

The practical result is a sharper Pareto distribution of engineering compensation. Engineers whose primary skill is translating well-defined requirements into working code will see their market value hold steady or decline. Engineers who operate above the automation bar will see their compensation continue to climb.

We have already seen early signals. Meta’s Superintelligence lab offered packages reaching $200 to $300 million over four years to recruit top AI researchers. These numbers are anomalies today, but I think they are directional for where elite engineering compensation is headed.

The career pipeline will also change. The traditional path from junior engineer to senior at a large company, spending years on increasingly complex tickets, is eroding. Not because junior engineers are worthless, but because companies have less economic incentive to invest in multi-year talent development when the intermediate-skill work those juniors would grow into is being automated. The path to elite engineering looks less like a promotion track and more like an entrepreneurial apprenticeship: building things constantly, taking on ambiguous problems, developing judgment through practice.

This connects to something I have been watching for a while: the convergence of the engineer, the product manager, and the entrepreneur into a single role. When building software is cheap, the bottleneck shifts to knowing what to build and why. The most valuable person at an early-stage company is not the one who writes the best code. It is the one who can talk to users, define the product, architect the system, and build it, all in the same afternoon. That person commands $500,000 or more, not because coding is hard, but because everything around coding is hard.

The real contradiction would be if Anthropic claimed coding was solved and then offered $100,000 a year for engineers. That would suggest they believe the remaining work is routine. Instead, they are paying premium prices for the work that remains after automation, which tells you exactly how they value it. The $500,000 salary is not evidence against their thesis. It is the thesis, expressed in dollars.

If an application of existing technology is physically possible, it is inevitable. The only rational response is engagement, not withdrawal.

In April 2018, more than 3,000 Google employees signed an open letter to CEO Sundar Pichai demanding the company withdraw from Project Maven — a Pentagon contract that used TensorFlow-based image recognition to analyze drone surveillance footage. “We believe that Google should not be in the business of war,” the letter stated. About a dozen engineers resigned. Prominent researchers like Meredith Whittaker organized internally. By June, Google announced it would not renew the contract when it expired in March 2019, and published a set of AI Principles committing not to build AI for weapons.

When I read about the walkout, I remember thinking that it was borderline, if not fully, hypocritical.

Google’s parent company, Alphabet, was simultaneously pouring over a billion dollars a year into Waymo — its autonomous vehicle subsidiary, valued around $100B at that time. The core technology powering Waymo is functionally identical to what Project Maven required: object detection, classification, tracking, planning, and real-time decision-making from sensor data. Waymo identifies pedestrians, cyclists, and vehicles, then makes split-second navigation decisions. Project Maven aimed to identify objects of interest in aerial footage, which also informed navigation and targeting decisions.

If you had given 100 random Waymo engineers (just 15% of the Waymo team) the right datasets and clearances, they would have built an autonomous military drone system as a matter of routine engineering. The ML architectures were the same. The sensor fusion pipelines and control systems differed in parameters, not in kind. The only meaningful difference was the label on the training data and the vehicle it was mounted on.

The protest was not about technical capability. It was about moral comfort. And moral comfort is not a strategy.

The Physics of Inevitability

There is a principle in high-energy physics, which I think about often in analogy to technology:

If a particle is not explicitly forbidden by a conservation law or symmetry, it necessarily exists. You just have to look in the right places.

This has been validated repeatedly. The positron, neutrino, Higgs boson, etc — each was predicted because the mathematics allowed it, and each was eventually observed. The only particles we fail to find are those that are strictly forbidden by physical law. Everything else is a matter of (1) our understanding of the laws of physics and (2) knowing when and where you look.

I believe that technology follows the same pattern. In fact, the analogy is surprisingly clear:

Waymo exists because the algorithms, hardware, and infrastructure for autonomous driving became sufficient. Project Maven existed because the same stack made military image analysis possible.

The implication is straightforward: if you support the development of a general-purpose technology — computer vision, large language models, robotic control systems — you are implicitly supporting every application that technology makes possible. Opposing a specific application while championing the underlying capability is like celebrating the Standard Model while insisting the Higgs boson shouldn’t exist. The math doesn’t care about your preferences.

Anthropic and the Pentagon

The same principle is playing out right now between AI labs and the Pentagon. In January 2024, OpenAI quietly removed its blanket prohibition on military use from its usage policies. Throughout 2024 and into 2025, OpenAI moved aggressively into the defense and intelligence space, partnering with Palantir and Scale AI to deploy LLMs in classified environments and signaling willingness to customize its models for government applications.

Anthropic took the opposite approach. They updated their acceptable use policy to permit certain national security use cases but refused to weaken or remove the safety guardrails on Claude for military applications, even when doing so might have secured large defense contracts.

I think highly of Anthropic. I use their models daily, I respect their research, and I believe their safety work is among the most important in the industry. But on this specific question, I think their position is largely irrational.

Military applications of large language models are technically possible with current capabilities. Therefore, they will be built. If Anthropic refuses to engage, the gap will be filled by OpenAI, by open-source models fine-tuned without guardrails, or by DeepSeek or another Chinese lab with no interest in Anthropic’s safety philosophy. The application is not forbidden by the laws of physics — it is permitted by the current tech stack — and so it will be observed.

Given that inevitability, Anthropic faces a binary choice: shape the application or cede it to others. Withdrawal does not prevent the outcome. It only removes Anthropic’s influence over how the outcome unfolds. A safety-focused lab with deep expertise in alignment is exactly the organization you want at the table when the Pentagon is deciding how to integrate AI into its operations. Their absence does not make the deployment safer. It makes it less safe.

This is the same error the Google engineers made in 2018. They succeeded in removing Google from Project Maven, but they did not succeed in preventing the Pentagon from using AI for drone surveillance. The DoD simply moved the contract to other vendors. And the technology didn’t just survive the protest — it proliferated far beyond anything Project Maven originally proposed. Today, AI-powered drone surveillance and autonomous targeting systems are operational across essentially every advanced military in the world. The Ukraine-Russia conflict alone has demonstrated the technology at massive scale on both sides. Turkey’s Bayraktar drones use computer vision for targeting in multiple theaters. China, Israel, and Iran all have operational programs. The walkout may have delayed one contract by a few months. The particle was observed anyway.

The Rational Response

There is a persistent temptation to treat opposition as a meaningful intervention — to believe that if enough talented people refuse to participate, the application won’t happen. This is a comforting fiction. It confuses moral signaling with material impact.

The history of technology repeatedly confirms this. Nuclear energy, genetic engineering, surveillance technology, encryption — in every case, the technology that could be built was built. Protest and regulation sometimes delayed specific implementations, but the underlying capability always found its way to deployment. The meaningful differences in outcomes came not from who refused to participate, but from who chose to engage and on what terms.

If you are an engineer, a researcher, or a company with genuine expertise in building these systems safely, your withdrawal from a controversial application does not make that application less likely. It makes it less safe. You are not preventing the particle from existing. You are choosing not to be in the room when it’s observed.

My view is not that every application of technology is morally equivalent, or that there are no legitimate reasons to be cautious about military AI. It is that caution and engagement are compatible, while caution and withdrawal are not. If an application is technically possible, it will be built. The rational response is to ensure it is built well.

The future of all intellectual work is: operating under imperfect information.

Lately, I’ve noticed two theories on the future of AI/LLMs that are gaining popularity.

• Artificial intelligence will become a sufficiently good replacement for (most) human intelligence

• Software will become a commodity as the effective cost of producing code trends toward zero.

My view is narrower and subtly different. LLMs are a near-perfect replacement for action under (near-) perfect information. Software is only commoditized to the extent that you can provide an LLM with perfect operating instructions. That means clear goals, crisp constraints, complete context, and unambiguous success criteria. Cloning the Apple website is already easy because it’s fully observable and has relatively little complex logic behind the scenes. Cloning the Spotify personalization engine is hard unless you can clearly and completely articulate what it is, how it works, what it should optimize for, and how you’ll know it’s correct.

That distinction matters because most real work is not fully observable. Most real work is partially observable, expensive to validate, and full of uncertainty that can’t be eliminated. It can only be mitigated.

You can already see this in the canonical SWE workflow today. Engineers guide Claude Code to implement a new ticket or feature. The more perfect the engineer’s description, the more perfect the output. When the prompt is vague, the agent fills in gaps, makes assumptions, and drifts. The best engineers already realize this, and they spend a disproportionate amount of up-front time building guardrails for the agent. The agent isn’t magically developing judgment. It’s being handed a tighter operating environment.

That’s the split I keep coming back to. Execution under perfect information is getting cheap. Turning the real world into something close to perfect information was always the hard part.

“Imperfect information” includes both obvious cases and more subtle ones.

• you don’t have access to the data

• you could get the data, but it’s expensive (either in money or time)

• you have a data point, but you don’t trust its precision

For example, suppose that someone quotes an odds estimate at ~40%, but if you’re honest, you think the real odds swing anywhere between 20% and 60%. The number exists, but confidence doesn’t. You still have to act.

I think the core human job shifts toward judgment under uncertainty. It means operating under partial information, dealing with expensive information, and deciding what to trust, what to verify, and what to do next.

Another way to describe being “good” at something is that you have better or more complete information than someone else, and you know how to act on it. For years, being good at coding often looked exactly like that. A lot of the differentiation came from informational advantage. It included patterns, tooling, library behavior, conventions, debugging instincts, system constraints, “how this codebase really works,” and which shortcuts are safe versus dangerous. LLMs dissolve a big chunk of that by making missing information cheap and fast to retrieve.

But dissolving informational advantage doesn’t dissolve performance differences. It shifts where those differences come from. If execution is cheap, the bottleneck becomes definition. If you can’t turn a messy problem into crisp criteria, the agent can’t save you. If you can, the agent amplifies you.

This suggests that, as a result of AI, the already-massive talent gap in software engineering will continue to widen.

There’s a persistent fiction that “mid-level” is a narrow band. In practice, mid-level covers a huge spread of capability. Even in the old world, you were handed a specific ticket and the information was relatively complete. Some people still did a worse job than others. They missed edge cases, implemented the wrong interpretation, and introduced unnecessary fragility. They shipped something that technically passed but didn’t actually match the real intent. Perfect information wasn’t enough to guarantee good outcomes.

Now imagine the new world where you’re expected to act optimally when perfect information is available, and most of your performance is evaluated under imperfect information because real projects are not fully spec’d, not fully observable, and not fully predictable. Truly elite engineers will distinguish themselves further. The differentiator becomes whether you can create near-perfect information from partial observability. Can you define what success is, constrain the problem correctly, and make good decisions when the inputs are incomplete?

This is the point that often gets missed in public discourse about AI and software engineering. People suppose the value of software trends to zero. I think that’s true only up to the extent that you can act perfectly upon perfect information, or manufacture near-perfect information out of the messy real world. The moment the task depends on judgment under uncertainty, software stops looking like a simple commodity and starts looking like an applied decision-making problem again.

This imperfect-information framing also explains why venture investor types tend to be comfortable with this world. They essentially always operate under imperfect or flawed information, and there is rarely a notion of perfect execution. There is only making marginally or moderately better decisions under uncertainty. That’s the whole job. Better calibration, better sizing of risk, better recognition of potential upside, better interpretation of weak signals, and better decisions with incomplete data.

It also lines up with the “engineers become managers of AIs” idea that has recently become mainstream. Managers operate at higher abstraction levels with greater uncertainty and more tradeoffs. They don’t get perfect inputs or perfect feedback. If engineers spend more of their day directing agents, specifying constraints, choosing tradeoffs, and defining success criteria, the job shifts toward that same shape. Higher abstraction, higher uncertainty, and more judgment.

If you can’t be trusted to make meaningful decisions under a moderate amount of uncertainty and risk, you’re at increased risk of replacement over time. Not necessarily because you’re less intelligent, but because your value is concentrated in the part of the workflow that can be reduced to perfect-information execution.

It’s useful to separate the LLM Era from the Information Era, where the advent of computers and technologies like Google changed how information was accessed and utilized. In the 80s, 90s, and earlier, it was highly valuable to know a lot of facts and be able to recall them on-demand. But as Google and other search engines became ubiquitous, they made recall cheap. It didn’t eliminate expertise, but it replaced a big chunk of “trivia advantage” -- a specific form of the information advantage I described earlier. Many are now portraying LLMs as an eventual replacement for the human intelligence layer, but my interpretation is that LLMs will replace human _execution_ more than they replace human intelligence.

With this in mind, the execution playbook becomes straightforward: hand off the perfect-information work to LLMs. All of the most valuable work will involve turning uncertainty into clarity and operating instructions. Get good at defining constraints, deciding what needs verification, and looking at every problem from multiple angles.

Execution is getting cheap. Judgment is still best left to humans.

The AI Bubble Froth

There is indeed a “bubble” in the AI industry, but it is not as exaggerated as many online personalities would have you believe. The reality is more nuanced.

There are certainly companies that are massively overvalued, but they aren’t the ones you might expect. OpenAI, Anthropic, and NVIDIA (among others) remain fundamentally sound, because they create tangible, immediate value in the marketplace. Critics often point to the high burn rates of OpenAI and Anthropic, or the complex web of big tech investments sustaining them, as signs of instability. However, this view ignores the massive floor for demand. If major LLM providers were to disappear tomorrow, the impact on the US marketplace would be catastrophic—a majority of the current startup landscape (AI-native or otherwise) would likely be decimated. The demand for these intelligence layers is massive, structural, and will continue to grow, not shrink.

Disclaimer: I am not claiming that OpenAI or Anthropic will be *profitable* in the near future. In fact, it’s likely that they continue hemorrhaging money for several more years. But the demand for their services is real, and the market is nowhere close to saturation.

I’ve heard the counter-argument that the model of massive capital expenditure for American AI labs is unsustainable, destined to be undercut by more efficient, open-source, Chinese models. This argument fails to account for the genealogy of those efficient models: they are typically distilled from the outputs of leading-edge American models. Without the existence of a bleeding-edge frontier model to distill from, those economical alternatives cannot exist in their current form. Frontier labs are more than capable of producing their own economical, distilled models, but leaders like OpenAI, Anthropic, and Google choose instead to focus on bleeding-edge intelligence.

The full “commoditization” of LLMs has not happened yet. If it had, we wouldn’t see expensive, closed-source models like Opus-4.5 gaining significant traction among developers. We wouldn’t see Meta pivoting away from an open-source AI strategy toward large, closed-source models. Because no single AI lab has secured a permanent foothold atop the intelligence leaderboards, it would be irresponsible and short-sighted to cut spending and focus on productization. The intelligence race is still very much alive. True commoditization will only occur once a model like “GPT-X.Y” becomes impossible to dethrone. Only then will it make strategic sense to shift focus from capability research to cost reduction and profit harvesting.

The companies that are truly overvalued are the pre-product startups commanding multi-billion-dollar valuations—labs like Thinking Machines or Safe Superintelligence that have yet to prove their business models. Over-valuations are not new to venture capital, but we have already seen

The Inflection AI Case Study: Despite raising approximately $1.5 billion, outstanding founder pedigree (Mustafa Suleyman, Reid Hoffman, Karén Simonyan), and developing a consumer product (”Pi”), Inflection never established a viable business model. In March 2024, the company effectively collapsed as a standalone entity when Microsoft hired its co-founders and key staff.

As the froth settles, we will see more stories like this. Investors in the major labs may face volatility, but their capital is backing real infrastructure. The same cannot be said for every multi-billion-dollar, pre-product lab.

Agentic Trough of Disillusionment

The novelty of “agents” is rapidly wearing off. For the past year, “agentic” has been the magic word in pitch decks and marketing copy, promising software that doesn’t just advise, but acts. However, most tech-savvy users have now test-driven enough “agentic” workflows to know the reality: they are often fragile, slow, or prone to getting stuck in loops.

We are entering the classic “Trough of Disillusionment” for AI agents. In 2026, simply claiming your product is “agentic” will no longer be a value proposition; in fact, it should be a red flag.

• The “Show, Don’t Tell” Era: If you have to explicitly tell me that your product is “agentic,” or features an “AI assistant,” I already suspect that it’s bad. Users don’t care about the underlying architecture —whether it’s a chain-of-thought loop or a single API call. They only care if their work gets done reliably. Explicitly marketing “agency” signals that the product is experimental rather than production-ready.

• From Feature to Baseline: Just as we stopped calling companies “internet companies” or “mobile-first” once those technologies became ubiquitous, “agentic” capabilities will fade into the background. We expect our calendar apps to handle scheduling conflicts and our code editors to refactor files. We don’t need to be told they are “agents.” We just expect them to work.

• The Reliability Gap: The biggest hurdle clearing this trough is reliability. The early wave of agentic demos — impressive on social media but brittle in practice — has made buyers skeptical. The winners in 2026 won’t be the ones with the most autonomous agents, but the ones with the most reliable workflows that actually finish a task without human intervention.

The most successful agentic products of 2026 will be the ones that never mention the word “agent” at all.

Rise of the Product Engineer

For years now, generalist engineers have been the under-hyped, under-valued utility players of the software industry — essential for plugging gaps and collaborating across teams. AI has inverted that dynamic, turning versatility into tremendous leverage. The most valuable employee at your company is now the "T-Shaped Engineer" — someone with broad software skills across multiple stacks, who is also very good at your company’s core competency. This is the person with enough technical depth to build a moat for your business, and enough breadth to efficiently handle dozens of other, tangential engineering tasks that are required for early-stage ventures.

But 2025 introduced a new, non-negotiable skill to the generalist toolkit: product-mindedness. Being a highly productive, task-oriented engineer is no longer sufficient. You must be able to think about the product you’re building, ask important questions, probe underlying assumptions, and even speak to current/prospective users. You must ask the *why* behind everything you do, and without anyone reminding you to do so.

The Convergence of Roles This shift is forcing a collision between the Product Manager and the Lead Engineer. The current “vibe coding” debate effectively centers around one question:

Which is more valuable: a PM with AI coding tools, or a product-minded engineer?

Currently, I’d argue that the product-minded engineer wins. But I’m tremendously biased, and I think the gap has closed considerably. In 2026, the lines will blur significantly. The best PMs can code and build prototypes, and the best engineers understand that “product thinking” dramatically increases their impact on the team. The “Product Engineer” is the inevitable result of this merger.

Scariest Chart in the World

Recently, my feed has been flooded with different versions of “the scariest chart in the world.” The implication is clear and terrifying: AI is generating massive corporate profits while systematically eliminating human jobs.

Fortunately, this is a correlation-causation fallacy.

• The Macro Reality: The chart actually illustrates a post-COVID correction. The “Great Resignation” of 2020-2021 created an artificial spike in job openings as turnover peaked. Combined with near-zero interest rates and VC largesse, hiring exploded. What we are seeing now is not an AI-induced collapse, but a regression to the mean as interest rates rose and “growth at all costs” ended.

• The Adoption Lag: The chart implies that ChatGPT instantly impacted the labor market upon release in late 2022. In reality, enterprise adoption lagged by a year-plus. For the first year, ChatGPT was primarily a productivity tool for existing engineers (writing snippets, drafting emails), not powering advanced or agentic systems capable of replacing real employees. The timeline simply doesn’t fit the narrative.

Finally, we must acknowledge that 'AI replacement' has become a convenient narrative shield for executives. When big players like Amazon rolled back headcount in late 2025, the external communication was that AI offered such large productivity gains that fewer employees were needed. However, it’s important to note that Amazon was under intense Q3/Q4 pressure to protect margins, and this could equivalently be explained as a financial decision.

Return of the Junior Engineer

Unfortunately, many software leaders have bought into this fallacy: that while tech-savvy companies become more profitable, the “junior engineer” is being rendered obsolete by AI. This belief has had an outsized and unfair impact on recent graduates, restricting their access to opportunities in a way that feels undue. Yes, AI can complete many of the low-level coding tasks that used to be the training ground for new hires. But this view is short-sighted.

• The Closing Gap: Young professionals are entering the workforce equipped with AI tools that allow them to absorb new concepts, frameworks, and technologies at an unprecedented speed. Having interviewed many engineers over the past year, I am confident that the gap between a good junior and a middle-of-the-road senior has closed significantly. Today’s juniors possess a skill set and velocity that I didn’t achieve until years into my own career as an ML engineer.

• Conviction: These engineers show a higher level of determination than previous generations. They have chosen to wade into the software landscape at the exact moment the industry is predicting their demise. Contrast that against the previous generation, when junior-to-mid-level jobs were plentiful, and many people (myself included) wandered into the industry on a whim.

It’s only a matter of time before companies remember that junior engineers, if hired and mentored in the correct context, can still bring tremendous values to companies in the year 2026. They are not one-to-one replaceable by AI, because they are capable of critical thinking, reasoning, and continuous improvement. That, along with their increased preparedness, makes them a dangerous asset in the next five years.

Decline of 996 Culture

The “996” work model—9 am to 9 pm, six days a week—is rapidly becoming an artifact of a bygone era. Modeled after the brute-force growth tactics of the early mobile internet boom, this culture treats engineers as consumable, renewable resources. The result is a churn-and-burn cycle where talent evaporates within 12–18 months. But beyond the human toll, this model is failing for a more pragmatic reason: it relies on a fundamental misunderstanding of how software is built in 2026.

Direction Over Velocity: There is a pervasive belief among certain founders that “more hours equals more output.” This creates a culture of motion rather than progress.

“It doesn’t matter how fast you move if it’s in a worthless direction.”
-Sam Altman

I don’t often quote Altman, but he is spot-on here. In my experience, leadership often overestimates the value of raw engineering hours while underestimating the value of critical thinking. This has always been true — seasoned developers know that engineering is 80% reading, planning, and communicating, and only 20% actually writing code — but AI has amplified this reality.

The Efficiency Paradox: In 2026, the barrier to entry isn’t writing code; it’s deciding what code is worth writing. It is possible to build a highly successful, scalable software company with only ~10,000 total lines of code, but that level of efficiency requires extreme intentionality. You cannot achieve this by battering-ramming your way through tickets for 72 hours a week. An effective technical leader dedicates at least 10% of their time to observing, continuously re-evaluating the approach, and adjusting the roadmap.

The Talent Correction: The best engineers know that “grind” culture is often a warning sign for lack of strategy. They will avoid these environments, leaving 996 companies with a talent deficit that is difficult to overcome. In the software / tech industry, there is often no replacement for engineering talent.

For most things in life, the range between best and average is 30% or so. The best airplane flight, the best meal, they may be 30% better than your average one. What I saw with Steve Wozniak was somebody who was 50 times better than your average engineer. The Mac team was an attempt to build a whole team like that of A players. People said they wouldn’t get along, they’d hate working for each other. But I realized A players like to work with A players, they just didn’t like working with C players… When I got back to Apple, that’s what I decided to do.
-Steve Jobs

World Models Won’t Take Off... Yet

World models are my favorite AI advancement of 2025. While LLMs predict the next word in a sentence, World Models predict the next frame in a video, based on the current state and inputs from the user(s). By feeding an AI millions of hours of data, it learns the underlying physics, causal relationships, and object permanence. It creates an internal simulation (a “world”) that it can manipulate. The potential applications are wide-reaching:

• Entertainment — Generating infinite, fully interactive video games on the fly.

• Robotics — Training robots in a realistic simulation or “dream” state to learn before real-world interaction.

• Autonomous Vehicles — Logging billions of hours of driving in simulated environments to safely train self-driving cars.

• Design — Prototyping and designing objects such as cars or buildings.

Despite the hype, I am bearish on their commercial viability for the next 1-2 years months. World models are much more expensive to serve than LLMs. With ChatGPT, one high-end GPU cluster can serve dozens of concurrent users. With world models, you typically need a cluster of H100s just to serve a single user in real-time. Until we see a 10x improvement in inference efficiency or a massive drop in compute costs, this technology does not scale to consumers.

Update: The main article with better image / equation formatting is published on my personal site at fkodom.com.

Update: I created this GitHub repo containing all of the code from this article, plus basic unit tests: fkodom/transformer-from-scratch

Why Another Transformer Tutorial?

Since they were first introduced in Attention Is All You Need (2017), Transformers have been the state-of-the-art for natural language processing. Recently, we have also seen Transformers applied to computer vision tasks with very promising results (see DETR, ViT). Vision Transformers, for example, now outperform all CNN-based models for image classification! Many people in the deep learning community (myself included) believe that an attention revolution is imminent — that is, that attention-based models will soon replace most of the existing state-of-the-art methods.

All deep learning practitioners should familiarize themselves with Transformers in the near future. Plenty of other Transformer articles exist, both on Medium and across the web. But I learn best by doing, so I set out to build my own PyTorch implementation. In this article, I hope to bring a new perspective and encourage others to join the revolution.

Attention Mechanisms

As the title “Attention Is All You Need” suggests, Transformers are centered around attention mechanisms. Attention is described in the paper’s abstract:

“Attention mechanisms have become an integral part of compelling sequence modeling and transduction models in various tasks, allowing modeling of dependencies without regard to their distance in the input or output sequences.”

In plain English, attention mechanisms relate data points within sequences. And they are very good at doing that.

Transformers use a specific type of attention mechanism, referred to as multi-head attention. This is the most important part of the model! Once you understand multi-head attention, it is pretty easy to understand Transformers as a whole. An illustration from the paper is shown below.

Let’s start with scaled dot-product attention, since we also need it to build the multi-head attention layer. Mathematically, it is expressed as:

What exactly is happening here? Q, K, and V are batches of matrices, each with shape (batch_size, seq_length, num_features). Multiplying the query (Q) and key (K) arrays results in a (batch_size, seq_length, seq_length) array, which tells us roughly how important each element in the sequence is. This is the attention of this layer — it determines which elements we “pay attention” to. The attention array is normalized using softmax, so that all of the weights sum to one. (Because we can’t pay more than 100% attention, right?) Finally, the attention is applied to the value (V) array using matrix multiplication.

Coding the scaled dot-product attention is pretty straightforward — just a few matrix multiplications, plus a softmax function. For added simplicity, we omit the optional Mask operation.

Note that MatMul operations are translated to torch.bmm in PyTorch. That’s because Q, K, and V (query, key, and value arrays) are batches of matrices, each with shape (batch_size, sequence_length, num_features). Batch matrix multiplication is only performed over the last two dimensions.

From the diagram above, we see that multi-head attention is composed of several identical attention heads. Each attention head contains 3 linear layers, followed by scaled dot-product attention. Let’s encapsulate this in an AttentionHead layer:

Now, it’s very easy to build the multi-head attention layer. Just combine num_heads different attention heads and a Linear layer for the output.

Let’s pause again to examine what’s going on in the MultiHeadAttention layer. Each attention head computes its own query, key, and value arrays, and then applies scaled dot-product attention. Conceptually, this means each head can attend to a different part of the input sequence, independent of the others. Increasing the number of attention heads allows us to “pay attention” to more parts of the sequence at once, which makes the model more powerful.

Positional Encoding

We need one more component before building the complete transformer: positional encoding. Notice that MultiHeadAttention has no trainable components that operate over the sequence dimension (axis 1). Everything operates over the feature dimension (axis 2), and so it is independent of sequence length. We have to provide positional information to the model, so that it knows about the relative position of data points in the input sequences.

Vaswani et. al. encode positional information using trigonometric functions, according to the equation:

We can implement this in just a few lines of code:

Note: I’ve gotten several questions about this code. In the equation above, there is a factor of two in the phase exponent. But it is applied at index 2i (+1) in the positional encoding. These factors of two should offset one another, and so I do not include it in my code. I believe this is correct, but it’s possible that I’ve missed something. Please leave me a comment if you see anything that needs fixing. ☺

Now, you may be thinking, “Why use such an unusual encoding? Surely, there are simpler choices!” You’re not wrong, and this was my first thought as well. According to the authors,

We also experimented with using learned positional embeddings instead, and found that the two versions produced nearly identical results. We chose the sinusoidal version because it may allow the model to extrapolate to sequence lengths longer than the ones encountered during training.

Why should sinusoidal encodings extrapolate to longer sequence lengths? Because sine/cosine functions are periodic, and they cover a range of [0, 1]. Most other choices of encoding would not be periodic or restricted to the range [0, 1]. Suppose that, during inference, you provide an input sequence longer than any used during training. Positional encoding for the last elements in the sequence could be different than anything the model has seen before. For those reasons, and despite the fact that learned embeddings appeared to perform equally as well, the authors still chose to use sinusoidal encoding. (I personally prefer learned embeddings, because they’re easier to implement and debug. But we’ll follow the authors for this article.)

The Transformer

Finally, we’re ready to build the Transformer! Let’s take a look at the complete network diagram:

Notice that the transformer uses an encoder-decoder architecture. The encoder (left) processes the input sequence and returns a feature vector (or memory vector). The decoder processes the target sequence, and incorporates information from the encoder memory. The output from the decoder is our model’s prediction!

We can code the encoder/decoder modules independently of one another, and then combine them at the end. But first we need a few more pieces of information, which aren’t included in the figure above. For example, how should we choose to build the feed forward networks?

Each of the layers in our encoder and decoder contains a fully connected feed-forward network, which … consists of two linear transformations with a ReLU activation in between. The dimensionality of input and output is 512, and the inner-layer has dimensionality 2048.

This gives a simple implementation for the Feed Forward modules above:

What kind of normalization should be used? Do we need any regularization, such as dropout layers?

The output of each sub-layer is LayerNorm(x + Sublayer(x)), where Sublayer(x) is the function implemented by the sub-layer itself. … We apply dropout to the output of each sub-layer, before it is added to the sub-layer input and normalized.

We can encapsulate all of this in a Module:

Time to dive in and create the encoder. Using the utility methods we just built, this is pretty easy.

The decoder module is extremely similar. Just a few small differences:

• The decoder accepts two arguments (target and memory), rather than one.

• There are two multi-head attention modules per layer, instead of one.

• The second multi-head attention accepts memory for two of its inputs.

Lastly, we need to wrap everything up into a single Transformer class. This requires minimal work, because it’s nothing new — just throw an encoder and decoder together, and pass data through them in the correct order.

And we’re done! Let’s create a simple test, as a sanity check for our implementation. We can construct random tensors for src and tgt, check that our model executes without errors, and confirm that the output tensor has the correct shape.

Conclusions

I hope this helps to shed some light on Transformers, how they’re built, and how they work. Computer vision folks (like myself) may not have encountered these models before, but I expect to see much more of them in the next couple of years. DETR and ViT have already shown ground-breaking results. It’s only a matter of time before other SOTA models fall to Transformers as well. In particular, I’ll be waiting expectantly on end-to-end attention-based models for object detection, image segmentation, and image generation.