The Bitter Lesson for AI software companies.

If frontier models become twice as capable next year, does your product become more valuable or less necessary?

I learned to ask that after building a long-horizon agent at Blueshift with roughly 90 tools, paged tool access, and executions across millions of tokens. The system worked. It also showed me how dangerous it is to build a company around something a model provider is temporarily bad at.

A company that becomes more valuable is building with the slope. A company whose core feature disappears is renting a temporary limitation.

What is the Bitter Lesson?

In 2019, reinforcement-learning researcher Rich Sutton published The Bitter Lesson. His observation was historical and uncomfortable: across major areas of artificial intelligence, general methods that could absorb more computation through learning and search repeatedly overtook systems built from human-supplied knowledge.

The handcrafted systems were not foolish. They often worked first. They reflected real expertise and could win while computation remained expensive. The problem was the slope. Human-designed features and rules tended to plateau. General methods kept finding new gains as computation, data, and learning machinery improved.

The lesson is bitter because builders like putting their understanding into the machine. It makes the system legible and makes our expertise feel load-bearing. Over a long enough horizon, the more durable contribution is often not the expert answer. It is the environment and method that let the machine discover answers the expert did not encode.

What the Bitter Lesson does not mean

It does not mean that domain knowledge is useless, that brute force solves every problem, or that software engineering disappears. Domain knowledge still matters when people choose objectives, construct environments, define interfaces, measure outcomes, and decide which failures are unacceptable.

It also does not mean every general method wins immediately. The time horizon matters. A specialized method can be the correct product today. The mistake is assuming its current advantage will remain a durable moat after the general system improves.

How I learned the lesson by building an agent harness

The first version used a fleet of specialist agents. Each local decision looked sensible, yet intent quietly evaporated across the handoffs. The system did not crash. It flattened. That experience taught me to distrust architectures that look impressive by component while losing the objective between components.

Building the eventual long-horizon system was useful precisely because it showed me the structural disadvantage of remaining at that layer. My conclusion was that model providers can co-design their models and harnesses, train against their own interfaces, observe the combined system at scale, and control the inference economics underneath the product.

An independent harness can still invent something important. But every feature built around a current model failure lives under the next provider changelog. I do not assume today's gaps in compaction, tool search, context management, delegation, or approval will remain open long enough to support a company.

Bitter Lesson Maxing

Bitter Lesson Maxing is my name for applying Sutton's research lesson to company construction:

Build where improving general agents compound your advantage, not where their next release erases it.

This does not mean refusing to build tools around agents. It means choosing the durable layer carefully. Bitter does not try to own the agent's reasoning loop. A builder can bring Codex, Claude Code, Pi, or another harness. Bitter is betting that agent cognition will become replaceable. The operating environment, accumulated state, authority, and customer history should survive the swap.

The durable layer includes:

• the repository and deployed product;
• credentials, identity, permissions, and authority;
• logs, verification, and operating history;
• payments, support, analytics, and customer relationships;
• the feedback that tells the next release what reality did;
• the interfaces through which any capable agent can act.

A better model should make that system capable of more work without forcing the company to replace its durable substrate. The agent is an increasingly capable worker. The company should own the workplace, the consequences, and the memory.

That is bitter-pilled engineering: let the clever layer stay replaceable, and own the layer that reality keeps making more valuable.

Two common AI startup mistakes

1. Building a moat from a temporary model weakness

The product manually supplies planning, routing, memory, formatting, or domain procedure because the current model struggles without it. That may be useful now. It is dangerous when the whole company's value depends on the struggle continuing.

2. Confusing a wrapper with a durable operating system

A prompt, tool router, or model-specific interface can be copied or absorbed upstream. Durable state, customer access, operating authority, distribution, and accumulated feedback are harder to replace because they are not merely instructions for producing an answer. They are parts of a running company.

A Bitter Lesson checklist for builders

• Which parts of the product exist only because a current model is weak?
• What happens to the value proposition after the next major provider release?
• Can customers replace the model or harness without losing their durable state?
• Does better model capability expand what the product can do?
• Does the system collect real outcomes that improve the next decision?
• Are we encoding an expert answer, or creating an environment in which an agent can find a better one?
• Do we own a customer relationship and operating loop, or only an inference-shaped feature?

Why the Bitter Lesson is one half of the thesis

General agents making more work cheap does not automatically make a company fast. If the rest of the workflow still waits on one person's attention, local intelligence improvements produce a queue. That is the second constraint, and the subject of Amdahl's Law for AI companies and the human attention bottleneck.

The pinned founder's letter explains why these two ideas jointly produced Bitter and Bitter Frontier.

How Bitter Frontier uses the lesson

Frontier asks whether a provider change is a durable general primitive or a workaround for a current model limit. It asks what independent software became less defensible because capability moved upstream. It compares providers because isolated release notes cannot show the direction of commoditization across the field.

The lesson determines the questions, not the conclusion. Specialized systems sometimes remain correct. A provider may ship a general-looking feature that fails in practice. The receipts decide what the publication can say.

See the lesson in the reporting

Our Goal mode report documents the broader launch. The Codex CLI v0.133.0 release enabled goals by default. Objective-bearing work, the kind of primitive I once had to build into a bespoke harness, moved into a provider product. That is exactly the slope this lesson says to expect.

Governance, Sold Separately is the useful brake on the slogan. Pi supplies a deliberately minimal loop while heypi sells approvals, audit, sandboxing, and secrets around it. Specialized software did not disappear; it moved to the durable authority layer. The reporting also found that most heypi approvals require an operator to wire the relevant gates. Choosing the right layer does not excuse weak defaults.

This page is a living interpretation, not an attempt to freeze Sutton's essay into one business slogan. It will change when better evidence exposes a weak analogy, a provider absorbs a layer we thought durable, or operating experience makes the company consequence more precise.