The Flat Curve Society: Why AI Literacy May Matter More Than Model Access

Last updated: August 3, 2026

The obvious way to compare AI development tools is model intelligence. Which model writes better code? Which provider has the larger context window? Which release wins the benchmark?

Steve Yegge's The Flat Curve Society proposes a less comfortable question: what if most teams cannot tell the difference between increasingly capable models because they do not have the workflows, tasks, or verification systems needed to expose that difference?

His answer is a practical one. AI literacy comes before optimization. First teach people how to use an agent. Then teach them how to use fewer tokens and get better outcomes.

A curve that looks flat from the ground#

Yegge's argument is partly about access and partly about discernment. Frontier capabilities may become expensive, restricted, or difficult to verify. Even when a model is objectively better, a team may not have a task that reveals the advantage.

That does not make model progress irrelevant. It means the local bottleneck may be elsewhere. A team with poor task decomposition, weak tests, and no review discipline can waste the benefit of a stronger model. A team with good boundaries may get more from a cheaper model than an unstructured team gets from the frontier.

This connects to model routing: intelligence should be assigned to the task that needs it, not sprayed across every request. It also connects to agent skills, because reusable instructions and project context make capability easier to apply consistently.

Token spend is a training signal, not a success metric#

The most actionable part of Yegge's essay is his distinction between learning to spend tokens and learning to conserve them. Early users need room to explore. They need to ask agents questions, try multi-step tasks, and see where the system succeeds or fails.

After that, raw token volume becomes a poor proxy for productivity. A large conversation can represent useful exploration, or it can represent a team asking an agent to rediscover the same facts repeatedly. At higher maturity, the important measures are outcome quality, cycle time, defect rate, and cost per accepted result.

The curve therefore has two phases:

• Literacy: more agent use can indicate that a person is learning the workflow.
• Craft: less wasted context for the same or better result indicates growing skill.

A useful adoption program#

Teams do not need a grand transformation program to test this idea. Start with a small cohort using real work during paid time. Give everyone the same basic tools, a narrow set of tasks, and a place to share successful prompts, skills, and verification patterns.

Measure whether people move from asking an agent for snippets to delegating a complete, testable slice. Measure whether they can explain the change and recover when the agent goes off track. A useful beginner curriculum includes repository navigation, task decomposition, test-first requests, context management, and review receipts.

Only after that baseline is stable should a team optimize cost. Teach people to start with the cheapest model that can handle the task, escalate when evidence says it is necessary, and avoid carrying irrelevant context across sessions. That is a workflow change, not merely a pricing change.

The model router is a product decision#

Yegge's advanced thesis is that an organization eventually needs a router that assigns work to intelligence tiers. In practice, this does not have to begin as a sophisticated classifier. A simple policy can work:

1. Route mechanical transformations, formatting, and narrow test additions to a low-cost model.
2. Route unfamiliar code, ambiguous requirements, and security-sensitive changes to a stronger model.
3. Require a human decision when the system cannot establish a reliable acceptance test.
4. Record the route, spend, outcome, and rework so the policy can improve.

This is where agent evaluations need baseline receipts. A cheaper route is not better if it creates a review backlog. A more expensive route is not better if the task was already well specified. The right unit is accepted outcome per unit of cost.

Why a plateau could help builders#

Yegge also makes a strategic case for a plateau. If model capability changes slowly enough for a while, teams can build durable workflows instead of constantly rewriting their assumptions. That gives software architecture, training, and product experiments time to compound.

The practical lesson does not depend on whether a literal plateau arrives. Teams should behave as if workflow quality matters even during rapid model progress. Strong boundaries, explicit acceptance tests, and reusable skills survive model changes better than a collection of provider-specific tricks.

FAQ#

What does AI literacy mean for developers?#

It means being able to give an agent a bounded task, provide the right context, verify the result, and recover when the first attempt fails. It is a workflow skill, not a measure of enthusiasm.

Should teams measure token usage?#

Yes, but carefully. Token usage can show early adoption and expose waste. At higher maturity, pair it with accepted outcomes, defects, cycle time, and rework.

How should a team choose between models?#

Start with the least expensive model that has enough capability for the task, then escalate based on ambiguity, risk, and failed evidence. Keep the routing policy measurable.

Continue Reading#

• Model Routing Recipes That Cut AI Spend
• Agent Evals Need Baseline Receipts
• Skills Are How Agents Learn the Job
• AI Code Review Is the New Bottleneck

Sources#

• The Flat Curve Society, Steve Yegge, fetched August 3, 2026.
• Steve Yegge article index, fetched August 3, 2026.
• The Future of Coding Agents, Steve Yegge, fetched August 3, 2026.