
Five minutes into my vibe coding talk, I asked the room for a definition. Someone said, "a toxic manager with AI." Honestly, that was better than half the definitions on the internet.

Other answers followed. Describe the requirement in plain English. Start with a concrete plan. Use your idea and imagination even if you have never written code. All correct, but the "toxic manager" answer stayed with me because it described the real failure mode. You keep demanding changes from a system that is slowly losing context, then get angry when it forgets what you said twenty minutes ago.

The barrier to making software has collapsed, which is great. You can now begin with zero code and zero revenue. The only upgrade is that you can also be broke because the agent ate your entire token budget before the product found its first user.

That is where the talk moved away from vibe coding and into the part I actually care about: building a system around the model that can reason, act, remember, and check its own work.

## the brain and body distinction

I drew a simple separation on the screen. The model is the brain. The coding agent, CLI, editor, tool layer, memory, and orchestration around it form the body. I call that body the harness.

This sounds like terminology until two products use the same model and give completely different results. The difference is usually not hidden intelligence. One harness loaded the right files, exposed the right tools, kept the context clean, and checked the output. The other one arrived carrying six old conversations, fifteen tool schemas, a novel-sized system prompt, and enough logs to recreate the Industrial Revolution.

We spend most of our time comparing brains because model benchmarks are easy to screenshot. But the body decides what the brain can see and what it can do. A smaller model inside a disciplined harness can beat a stronger model inside a cluttered one on the task that actually matters.

## more context is not always more intelligence

During the talk I used a hundred-page analogy. Suppose you read a hundred pages today. Tomorrow, do you remember every sentence? Of course not. You remember the important decisions, a few examples, and the general shape of the argument.

An agent session has the same problem, except we often treat its context window like a storage cupboard. Tool outputs go in. Failed attempts go in. Entire files get loaded because one function looked suspicious. Then we add a long instruction telling the model to pay attention to the important parts, which is a little like fixing a messy desk by placing a note on it that says "be organized."

The model technically has more information, but the useful signal is now fighting everything else for attention. This is the dumb-zone feeling people notice in long sessions. The model was sharp at the beginning, then somewhere around the tenth correction it started agreeing with everything and following nothing.

I wrote about the same problem from a production angle in [Everything I Got Wrong About AI Coding Agents](/posts/everything-we-got-wrong-about-ai-coding-agents). The short version is that context is not free intelligence. It is a budget, and every tool definition, instruction, file, and previous answer spends some of it.

## compacting helps, but it is also a tiny case of alzheimer's

Someone in the room asked about `/compact`. The command takes a long conversation, summarizes it, and starts a smaller context from that summary. Useful, right? Yes, but the summary cannot preserve every decision and edge case. My extremely scientific description during the talk was that compacting has a small Alzheimer's problem.

The way I handle this is with a production action log. It is not a dump of the chat. It is a small persistent file that records what changed, why it changed, what was verified, what remains uncertain, and what the next phase needs to know.

The conversation can disappear after compaction. The project state cannot. This difference sounds basic, but chat history and memory get treated as the same thing in a lot of agent setups. Chat history is everything that happened. Memory is the tiny set of facts that must survive.

## one phase at a time

Then I asked the room how they would prompt an agent to build a to-do app. The first answer was basically, "make a to-do app." Fair enough. The interesting part began when I added authentication, profiles, deployment, validation, and a few other things to the same requirement.

Models love taking shortcuts through big prompts. If I give one agent six features at once, it tends to produce six shallow features and call the project complete. Authentication gets a login form. Security gets a sentence in the README. Validation means the build command returned zero. Wonderful, until someone sends a request the UI was not designed to send.

So I split work into phases. Each phase has an input, one objective, and an observable outcome. The output of phase one becomes the input to phase two, then phase three, like a chain where every link has to hold before the next one is added.

```text
phase 1 output -> phase 2 input -> phase 3 input -> validation
```

Authentication becomes one phase. The outcome is not "authentication code exists." The outcome is that valid users can sign in, invalid sessions are rejected, the important abuse cases have been tested, and the behaviour survives in the deployed environment.

Planning and execution also need different behaviour. During planning I tell the agent not to assume, to inspect the environment, and to ask as many questions as necessary. During execution the decisions are already made, so it should stop reopening architecture and work until the agreed validation passes. Mixing those modes is how you get an agent that starts coding too early and starts philosophizing too late.

## the loop is only real when validation is real

The board eventually became a set of inner and outer loops. The inner loop plans a phase, executes it, validates the result, and repairs failures. The outer loop watches the actual goal. If the inner loop stops without meeting it, the outer loop starts another attempt with the failure state preserved.

```text
plan -> execute -> validate -> repair -> validate again
```

The validation layer is the part people skip because generation is more fun to demo. For a website, I give the agent a browser so it can inspect the rendered page and click the controls. For an Android app, it needs screenshots and a way to tap through the interface. For an API, it needs real requests against the environment where the code runs. A green unit test is evidence, but it is not the same thing as seeing the user's path work.

This is how the workflow becomes autonomous without becoming reckless. I can attach a trigger to a Jira ticket, let a cheap model decide whether the task is routine or risky, and start the loop for routine work. The large model does the reasoning-heavy parts. The harness handles context, tools, retries, and state. Human review stays where the blast radius demands it.

The same restraint applies to tools. If a task can be done reliably with an existing CLI, I do not automatically load a large tool protocol into every session. A tool should earn the context it consumes. Installing everything because it might be useful later is how the agent begins every task already carrying luggage.

## the strange part came at the end

Near the end of the talk, I switched from agent systems to a more basic question: what does a language model actually know?

We talk to it through sentences, so the natural mental picture is a giant hidden library. Ask a question, the model finds the correct paragraph, and then reads it back in its own voice. That picture is comforting and mostly wrong. The learned representation is closer to geometry. Words and concepts become high-dimensional vectors, and relationships appear as distance and direction inside that space.

`Agent` lands near ideas such as `agency` and `intelligence`. `Code` drifts toward `debugging` and `backend`. Nobody created those folders by hand. The neighbourhoods come from patterns learned by the embedding model.

Humans cannot look around in 3,072 dimensions, so I projected a small vocabulary into three and made it walkable.

<WordEmbeddingFlight initialWord="agent" />

Search for a word and teleport to it. The named points are real embedding vectors, and the neighbour score shown under each word is calculated in the original high-dimensional space. The coloured particles make the regions readable at human scale; they are visual scaffolding around the real word positions, not invented extra words. The fullscreen button is there because this thing makes much more sense when the article gets out of the way for a minute.

The first scene stays deliberately small so it can open inside an article without turning the rest of the page into collateral damage. Enter the space or search beyond those landmarks and a second atlas streams in: 234,869 open-English terms indexed as a complete map. The browser keeps the full three-dimensional projection available for search and the minimap, but sends only the camera's local neighbourhood to the GPU. The heavier vectors remain split into small files and only the words you ask for are fetched.

There is another way to inspect the same geometry. Put your own words on the rows and columns below. Each cell is their cosine similarity, so you can test whether `frustration` leans closer to `corporate`, `relationship`, or anything else in the atlas instead of accepting a hand-picked example.

<EmbeddingSimilarityMatrix />

## for the nerds who want the receipts

The opening map contains 199 labelled landmarks. Each starts as a vector with 3,072 values:

```text
word -> [v1, v2, v3, ... v3072]
```

I normalize those vectors and calculate exact cosine similarity for the nearest neighbours:

```text
cosine(x, y) = dot(x, y) / (norm(x) * norm(y))
```

The three-dimensional position comes from PaCMAP, which tries to preserve local neighbourhoods without completely destroying the larger shape. That projection has a trustworthiness-at-10 score of 0.812 on this vocabulary. Good enough to explore, nowhere near good enough to pretend the 3D picture is the model's literal internal layout.

That distinction matters. Cosine neighbours come from the original 3,072-dimensional vectors. The lines, map position, and visible clusters come from the compressed projection. If the picture and the cosine score disagree, trust the cosine score. A projection is a view of the data, not the data itself.

The wider atlas makes a different performance tradeoff. Its 234,869 terms use normalized 128-dimensional vectors, quantized into 115 static shards, with a compact UMAP projection for the visible map. The visualizer downloads the vocabulary and the 1.34 MB projection, builds a spatial index in the browser, and renders at most 40,000 nearby words as the camera moves. The comparison matrix requests a vector shard only when one of its words needs it. No model API call runs while you read this page.

## what I actually took away from the talk

I started the session with vibe coding because that is the phrase everyone recognizes. By the end, the code generation itself felt like the least interesting piece. The useful work was choosing what enters context, deciding what must survive compaction, breaking one vague goal into phases, and building a validation layer that can observe reality instead of trusting the agent's confidence.

The vector map closed the loop for me. A prompt is not a command inserted into an empty machine. It changes a computation already shaped by learned geometry, the current context, available tools, previous outputs, and the harness wrapped around all of it. Better prompting helps, but better system design lasts longer.

The model is the brain. The harness is the body. The loop is the work. If the loop is weak, a better brain simply makes expensive mistakes faster.


What I learned teaching vibe coding through context limits, phase prompts, validation loops, and the strange vector geometry inside language models.

The Model Is the Brain. The Harness Is the Body.

I had a hunch the standard system → user prompt order was wrong for negative constraints. Every standard answer told me to drop it. I ran 1500 calls on 30 hard tasks and the flipped version beat the standard one by 14 to 46 points. The system slot is the worst place for your 'do not' rules and the docs back it.

Flip your order and it works? The system prompt is the worst place for your 'do not' rules


A friend pinged me at 9pm asking what MCP actually gives you over plain APIs. Full skepticism vibe. He had been reading about it, couldn't find anything substantial, and wanted me to either convince him or admit there was nothing there.

I started typing the defense. Standardized tool use. Dynamic discovery. Session state. The usual arguments. Halfway through I realized I did not believe myself, and by the time we had finished the conversation I had watched every defense line collapse under one very simple question: "if the server is local, can't the agent just import the function?"

Yes. Yes it can. And once you see it, you can't unsee it.

## the received wisdom

The pitch for MCP goes like this. If you want an agent to talk to Slack and GitHub and Jira, you're writing three integration layers. Three auth flows. Three response parsers. Three schema translations for the LLM. MCP wraps all of that behind one protocol so the LLM client does not care what is behind it. Standardized interface, dynamic discovery, composability. USB for AI tools.

That sounds important. It is also mostly true. What I want to pick apart is whether it's substantive, or whether the same thing was already possible with boring tools you already use.

## defense line one. standardized tool use for LLMs

The core value prop is one thing: a wire format that every LLM client understands when it wants to list and call tools. `tools/list` returns JSON schemas. `tools/call` invokes one with arguments. That is the whole protocol loop in practice.

Here is a minimal Python MCP server using the official FastMCP SDK:

```python
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("hello")

@mcp.tool()
def add(a: int, b: int) -> int:
    return a + b

if __name__ == "__main__":
    mcp.run()
```

Seven lines. Tiny. Now here is the same thing without MCP:

```python
def add(a: int, b: int) -> int:
    return a + b
```

Two lines. Also tiny. Your agent framework on the other side can introspect the signature, read the docstring, build its own JSON schema, and call the function directly. No protocol. No JSON-RPC. No stdio handshake. Most agent frameworks already do exactly this.

So what did I save by using MCP in the first example over the second? Only the wire format. Everything else, the schema generation and the discovery and the call-and-return, is stuff the framework would have done anyway.

## defense line two. but OpenAPI already does this

If the value is "JSON schema plus discovery for callable endpoints", OpenAPI did that fifteen years ago. You hand an agent an `openapi.json`, it reads the schemas, it calls the endpoints. LangChain has `OpenAPIToolkit` for exactly this. Every function-calling LLM already takes JSON schemas as input, which means anything expressible in OpenAPI you can feed straight in.

So the steelman has to move further. Stateful sessions. Resources. Prompts. Sampling. Let me take them in order, because only one of these four turns out to be interesting.

**Stateful sessions.** OpenAPI describes stateless REST. MCP keeps a persistent session so the client does not re-auth every call and the server can hold context between calls. True, but re-auth in HTTP is called a cookie and holding context is called a session and the pattern is thirty years old. The novelty is not that MCP servers are stateful, it is that the wire format bundles session handling. That is a packaging convenience, not a technical innovation.

**Resources.** MCP has a concept of "resources", readable files or data the server can expose for the LLM to pull into context. OpenAPI only describes callable endpoints. Fair point, except a callable endpoint that returns a file is still just an API. There is nothing an MCP resource does that `GET /files/:id` does not. You could express every MCP resource as an OpenAPI endpoint with ten minutes of yak shaving.

**Prompts.** MCP servers can ship templated prompt snippets that clients surface as slash commands. That is a UX feature, not a protocol feature. Any CLI with a plugin system already does this.

Each of these is real, but when you line them up, you are not looking at technical progress. You are looking at a coordinated bundle of conventions. Which is a real thing to want. It is just not what "protocol" usually means.

## defense line three. the direction of the connection is flipped

Here is where I had to actually revise my take. The substantive thing MCP does that OpenAPI cannot is subtle. **The MCP server sits next to the LLM, not next to the internet.**

OpenAPI describes services, and services live behind HTTP endpoints, which means they already have an API. MCP servers are processes that live on your machine, or in your IDE, or inside Claude Desktop, and they bridge the LLM into contexts that were never APIs to begin with.

Your filesystem is not an API. Your running IDE buffer is not an API. Your local Docker daemon, your browser tab, your vim state, your postgres socket, your current git branch: none of these things have OpenAPI specs, because none of them exposed HTTP endpoints in the first place. Wrapping them in a tiny stdio server that speaks MCP lets the LLM touch them without you building a full web service first. That is real capability expansion.

And MCP has one genuinely new feature on top of this: **sampling**. The server can ask the LLM to do inference mid-call. "Before I continue, summarize this chunk for me." `sampling/createMessage` goes from server back to client, and the client runs inference and returns a completion. OpenAPI has no concept of this because REST calls only flow one way. An HTTP endpoint never calls back into your brain and asks you to think about something. An MCP server does.

If I had stopped thinking here two hours in, I would have written "MCP gives the LLM arms and legs in non-API environments, plus a back-channel to request reasoning." That is a real story. It is the best honest defense of the protocol. I was ready to ship that take.

## the question that broke it

My friend wasn't done. His next message was the one that collapsed the whole frame: "if the server is local, we basically don't need MCP, the agent can literally import the file and run those functions lol".

And he's right.

If the MCP server is running on your machine, and the agent is running on your machine, then the entire stdio JSON-RPC layer between them is solving a problem that only exists because they were separate processes. Put them in the same process, which is what every first-party agent environment already does, including Claude Code and Cursor and every custom agent anyone ships, and the "protocol" dissolves.

The agent just imports the module:

```python
from tools.github import create_issue
from tools.filesystem import read_file
from tools.ide import current_buffer

# introspect signatures, build schemas, call directly
# no wire format, no handshake, no session
```

You can even do the sampling thing without a protocol. If the tool is a Python function and the LLM client is a Python object in the same process, the function can call the client directly. `client.sample(prompt)`. Done. Bidirectional. No bytes on the wire. No JSON-RPC. No `initialize` handshake. The server-to-client call is a normal function return from inside a normal function call, which is how every computer program has worked for fifty years.

So what does MCP give you in this world, over a plain function call? Exactly one thing: **process isolation**. The tool runs in its own process, its own memory space, under its own permissions. If it crashes or misbehaves it does not take the agent down with it. That is real. It is also a property of any subprocess, not a property that requires a protocol. `subprocess.Popen` with a clean interface gives you the same isolation without any of the wire format. The protocol adds structure to the conversation between processes, but the isolation comes from the process boundary itself.

## what MCP actually is

After walking through all of that, here is what I think MCP actually is. It is a distribution and discovery standard for agent tools. It is npm for tool servers. The value is almost entirely in packaging and ecosystem, not in the protocol itself.

Someone writes an MCP server for Notion. They publish it. Every MCP-compatible client, Claude Desktop and Cursor and whatever else shows up next, plugs it in without reading the source. That is genuinely useful. Without MCP, everyone rewrites the Notion integration, and there is no common place to look.

The parallel with npm is so close it is almost the whole thing. npm did not invent JavaScript modules. CommonJS and ES Modules already defined how modules work. What npm added was a registry, a manifest format, and a naming convention that let anyone install anyone else's code with one command. The protocol underneath was thin. The value was adoption.

MCP is playing the same move. JSON-RPC over stdio was solved in 2005. Tool schemas for LLMs existed before MCP. What MCP adds is a registry, a manifest, a naming convention, and the promise that if you write a tool once, every compatible client speaks the same thing. That is valuable, but let's be honest about what kind of value it is. It is coordination, not invention.

## when MCP still wins

I want to be fair here, so here are the cases where picking MCP actually makes sense:

- **You're publishing a tool for other people to use.** Write it as an MCP server and every client can consume it without friction. This is the npm case and it is fine.
- **You're building a platform where tools are plugged in at runtime by end users.** Skill-loading agent platforms, Cursor-style extensions, Claude Desktop's config-file plugins. The end user cannot write Python to wire in a tool, so they need a discovery-and-plug interface. MCP is that interface.
- **You need process isolation for security reasons.** You do not trust a third party tool to share memory with your agent. MCP's stdio or SSE boundary gives you that, though so does `subprocess.Popen` with a simpler contract.
- **You're in the Anthropic ecosystem and want path-of-least-resistance.** Claude Desktop reads MCP servers natively from its config file. If you want your tool to show up there, MCP is the on-ramp. That is ecosystem lock-in, not a technical argument, but lock-in is a real reason to pick things.

If you are building your own agent for your own codebase, and the tools are your own functions, you do not need MCP. You need `def`.

## the part I actually care about

The thing that annoys me about the MCP discourse is not MCP. It is the framing. Every launch post and thread talks about MCP like it is a technical innovation. It is not. It is a coordination mechanism wrapped around a protocol thin enough that you could re-spec it in an afternoon.

That is not a criticism of the project. Coordination mechanisms are valuable. npm made JavaScript shippable. USB made peripherals sane. HTTP made hypertext universal. None of them were technically novel when they appeared, and all of them became load-bearing because enough people agreed on the same thing. That is how standards work. Standards are a social phenomenon that happens to be implemented in bytes.

MCP might become load-bearing in the same way. It might also not. What I want us to stop doing is pretending the protocol is doing work that the protocol is not doing. The value is in the ecosystem. The ecosystem only exists if everyone agrees to use the standard. And nobody agrees to use a standard that is advertised dishonestly. So call MCP what it is: a packaging format for agent tools with an attached wire protocol. Pick it up when you need to publish or consume, skip it when you don't, and let the technical hype die down so the coordination win can show up on its own merits.

You're not missing anything. There is no deep technical substance in MCP. There is a thin standard that becomes valuable only at ecosystem scale, and the honest version of the pitch is "use this so your tool works in Claude Desktop and Cursor without writing glue." That is a real value proposition. Ship it with that framing and I'll stop writing posts like this one.

~ Ashish Kumar Verma 🫡


A friend asked what MCP actually gives you over plain APIs. I tried to defend it. Every defense line collapsed under one simple question. Here's the honest walk through why MCP is a packaging standard, not a technical innovation, and why that's still valuable.

Honestly, MCP Is Just npm For Agent Tools


I read a paper last week that made me put my laptop down and stare at the wall for a bit. Not because it said AI will take jobs, everybody says that now, and most of the time it's either panic bait or "learn to code" cope dressed up in a LinkedIn carousel. This was different. Two researchers at UPenn and Boston University built a formal game-theoretic model, ran the math, and proved something genuinely unsettling: even when every firm in a market knows that mass automation will destroy the consumer demand they all depend on, they do it anyway. Rationality doesn't save you. Perfect information doesn't save you. The structure of competition itself is the trap.

The paper is "The AI Layoff Trap" by Brett Hemenway Falk and Gerry Tsoukalas, published on arXiv in March 2026. And the reason it hit me is that I work with AI systems every day. I build them. I ship them. I've watched companies rip out entire teams and replace them with agents. And every time someone asks "won't this destroy the market eventually?", the implicit answer from management is always some version of "the market will adjust." This paper says: no, actually, it probably won't. Not on its own. And here's the math that proves it.

## the setup

The model is stripped down on purpose. You have N symmetric firms in a market. Each firm chooses what fraction α of its workforce to replace with AI. Automating a task saves money (the worker's wage minus the AI cost, call it s = w − c), but each successive task gets harder to automate because of integration friction (modeled as a quadratic cost k·α²/2). So far this is standard.

The twist is on the demand side. Workers are also consumers. When a firm lays off workers, those workers stop spending. A fraction λ of their wages was going to this sector's products, and only a fraction η of the lost income gets recovered through reemployment or transfers. So the demand loss per displaced worker is ℓ = λ(1−η)w. Every firm's revenue depends on aggregate demand, and aggregate demand depends on how many workers still have jobs.

Here's where competition creates the trap. When Firm A automates one more task, aggregate demand drops by ℓ·L (where L is the labor force). But competitive pricing splits revenue equally across N firms, so Firm A only feels ℓ·L/N of that demand destruction. The other (N−1)/N falls on rivals. Each firm captures the full cost saving but externalizes most of the demand damage. The firm isn't being irrational. It's being perfectly rational. And that's exactly the problem.

## the wedge

The paper defines two automation rates. The Nash Equilibrium rate αNE is what each firm actually does when maximizing its own profit. The Cooperative Optimum αCO is what a planner would choose if all firms coordinated to maximize joint profit. The gap between them is the over-automation wedge:

> αNE − αCO = ℓ(1 − 1/N) / k

This equation tells you three things immediately. First, a monopolist (N=1) has zero wedge because it internalizes all the demand loss. Second, the wedge grows with N, because more competitors means each firm bears a smaller share of the damage. Third, the wedge grows with ℓ (more demand destruction per layoff) and shrinks with k (more friction makes automation harder).

The really counterintuitive result is that more competition makes things worse. We usually think competition disciplines firms into acting in consumers' interests. Here, more competition dilutes each firm's share of the demand loss, which weakens the private incentive to restrain. The invisible hand is pushing everyone off a cliff.

Drag the sliders below and watch this happen in real time.

<AutomationWedgeExplorer />

Set N to 1 and the two lines overlap perfectly. Now drag it to 7 or 10. Watch the orange line (what firms actually do) pull away from the green line (what they should do). That gap is pure deadweight loss. Not a transfer from workers to owners. Both sides lose.

## the prisoner's dilemma

When you remove integration friction entirely (k → 0), the model collapses into something beautifully ugly: a classic Prisoner's Dilemma. Each firm faces a binary choice, automate everything or automate nothing, and full automation is the strictly dominant strategy even though mutual restraint would make everyone richer.

This isn't a coordination failure. Coordination failures are solvable, you just need firms to agree on which equilibrium to play. This is worse. Even if every CEO in the industry gets on a call and agrees to restrain, each firm's individually optimal move is still to defect. Communication is cheap talk. The agreement has no teeth because automating is dominant regardless of what rivals do.

<PrisonersDilemmaPayoff />

Look at the payoff matrix. Both firms at (100, 100) if they restrain. Both at something less than 100 if they automate. But if your rival restrains and you automate, you win big. And if your rival automates and you don't, you lose big. So you automate. Always. Even though you can see the cliff.

Block cut nearly half its 10,000-person workforce in February 2026. Jack Dorsey said AI had made those roles unnecessary and predicted most companies would reach the same conclusion within a year. Over 100,000 tech workers were laid off in 2025 with AI cited as the primary driver in more than half the cases. Salesforce replaced 4,000 customer support agents with agentic AI. This is not a hypothetical scenario from an econ paper. This is the Prisoner's Dilemma playing out in real time, with real people.

## so what fixes it?

This is where the paper gets genuinely useful. They evaluate six policy instruments against the externality. The results are sobering because most of the things people propose don't actually work on the right margin.

<PolicyDashboard />

Click through each one. The pattern is stark. Capital income taxes don't change the automation rate at all because a multiplicative tax doesn't alter the first-order condition, it just scales profits down uniformly. UBI raises the floor on living standards but doesn't change the per-task incentive to automate, firms still race. Coasian bargaining fails because automation is a dominant strategy, no voluntary agreement is self-enforcing. Upskilling and worker equity partially narrow the wedge but can't eliminate it.

Only the Pigouvian automation tax fully corrects the distortion. The idea is simple in principle: set the tax equal to the uninternalized demand loss per task, τ = ℓ(1−1/N). This makes each firm face the full social cost of its automation decision, not just its private share. The firm's first-order condition becomes identical to the cooperative planner's. And the tax revenue can fund retraining programs that increase η, which shrinks ℓ, which shrinks the required tax over time. The policy is potentially self-limiting.

## the red queen effect

There's one more result that kept bugging me. You might think that as AI gets better (lower cost c, higher productivity), the problem resolves itself because the cost saving s grows relative to the demand loss ℓ. The paper shows the opposite.

Higher AI productivity widens the wedge. Each firm sees a market-share gain from automating beyond rivals, but at the symmetric equilibrium these gains cancel out and leave only the additional distortion. It's a Red Queen effect: everyone runs faster and nobody gets ahead, but the collective damage accumulates. "Better" AI doesn't solve the externality. It amplifies it.

This is the part that should worry the "AI will create new jobs" optimists. The paper doesn't say new jobs can't emerge. It says even if they do (η > 0), the externality persists as long as displaced workers aren't landing in better-paying roles (η < 1). And the faster AI improves, the wider the gap between what firms do and what they should do.

## the math under the hood

Skip this if equations aren't your thing. But if you want the receipts, here they are.

The model has L workers, N symmetric firms, wage w, AI cost c per task. Each firm chooses automation rate αᵢ ∈ [0,1].

**Per-task economics:**
- Cost saving: s = w − c
- Demand loss per displaced worker: ℓ = λ(1−η)w
- Integration friction: quadratic k·α²/2

**Firm i's profit** (equation 6 from the paper):

> πᵢ = L · [s·αᵢ − (k·αᵢ²)/2 − (ℓ/N)·Σⱼαⱼ] + Π₀

where Π₀ is baseline profit with no automation.

**First-order condition** (private): ∂πᵢ/∂αᵢ = L · [s − ℓ/N − k·αᵢ] = 0, which gives us αNE = (s − ℓ/N) / k.

**Social planner's FOC** (faces full demand loss ℓ, not ℓ/N): αCO = (s − ℓ) / k.

**The wedge** falls out immediately: αNE − αCO = (s − ℓ/N)/k − (s − ℓ)/k = ℓ(1 − 1/N) / k.

**Automation threshold:** N* = ℓ/s = λ(1−η)w / (w−c). Firms automate only when N > N*. As AI costs fall (c → 0), N* → λ(1−η) ≤ 1, so the over-automation region expands to cover virtually any market with N ≥ 2.

**Generalized surplus loss** (Proposition 2): S(μ; αSP) − S(μ; αNE) = [(1−μ)·N·L·k / 2] · (αNE − αSP(μ))². This is quadratic in the wedge and scales with N·L, so both market fragmentation and market size amplify the welfare cost.

**Pigouvian tax correction:** Set τ = ℓ(1−1/N). The firm's new FOC becomes s − ℓ/N − τ − k·α = 0, which simplifies to s − ℓ − k·α = 0. That's exactly the cooperative planner's condition. The tax makes the private incentive match the social incentive.

**Frictionless Prisoner's Dilemma** (k=0): marginal profit becomes the constant L(s − ℓ/N). If positive (N > N*), full automation is strictly dominant. If s < ℓ, mutual automation yields Π₀ + L(s−ℓ) < Π₀. Total deadweight loss = N·L·(ℓ−s).

## my honest take

I build AI systems for a living. I've shipped agents that automate tasks people used to do manually. I know the cost savings are real, and I know the productivity gains are real. This paper doesn't say automation is bad. It says the incentive structure of competitive markets will push firms past the point where automation is collectively beneficial, and that's a structural problem you can't fix with goodwill, foresight, or voluntary agreements.

The thing that sticks with me is the Pareto dominance result. Over-automation doesn't just hurt workers. It hurts firm owners too. Both sides end up worse off at the Nash equilibrium than at the cooperative optimum. This isn't a story about greedy corporations. It's a story about a game where the rules punish everyone, including the people making the moves.

If you're in tech and you've been watching the layoff waves with a vague sense that "this can't keep going forever without consequences," now you have the formal model that explains why. The cliff is real, everyone can see it, and the structure of competition makes it rational to keep driving toward it. The paper says only a Pigouvian automation tax, set to the uninternalized demand loss, actually corrects the incentive. Everything else is either a band-aid or doesn't operate on the right margin.

I don't know if that tax is politically feasible. But at least now the problem has a name, a model, and a proof. That's more than we had last month 🫡


Two researchers proved mathematically that rational firms will over-automate with AI even when they know it destroys the demand they depend on. Only one policy instrument out of six actually fixes it.

The AI Layoff Trap. Why Knowing the Cliff Is Ahead Doesn't Stop the Race.

I read Anthropic's 243-page Claude Mythos system card. It starts as safety science and ends as 20 pages of employees marveling at their model's creative writing. The real story is buried in section 5.8.1, where they admit the circularity.

Anthropic's 243-Page Claude Mythos System Card Is a Love Letter Disguised as Science


Karpathy shipped autoresearch and GitHub exploded. My timeline turned into people posting overnight val_bpb curves and captioning them like they cured cancer. I pulled up the repo and read it: 630 lines of training code and a markdown file called `program.md`. That's the whole thing.

I sat with that for an evening and argued both sides of it. My brain went: wait, this is just a for loop with an LLM inside it. I ended up somewhere I didn't expect, because the loop is not the point. The pattern is the point, and once you see the pattern, you realize you can run it on almost anything.

## what autoresearch actually is

Stripped of the framing, the loop is this:

```python
while True:
    agent modifies train.py
    run for 5 minutes
    if val_bpb < best:
        keep the change
    else:
        revert
```

An LLM reads the training file, edits it, and you run the edited version for a few minutes. Check if the loss went down. Keep or revert, then go again. The "research agenda" is a markdown file that tells the agent what to try, what not to break, and what metric to care about. Then the agent loops until you run out of compute or patience.

So when someone says autoresearch, what they actually mean is: LLM as proposal function, greedy hill climbing over a single scalar metric, with a keep/revert gate. That is not a knock. That's the whole insight.

## what I got wrong in my first reaction

My first instinct was to roll my eyes, because technically this is something any engineer who has used Claude Code or Codex for more than a weekend has done. "Hey, tweak this config, run the benchmark, revert if it got worse, try again." That's a Tuesday afternoon workflow. But that reaction was missing the actual contribution.

Karpathy named the pattern, gave it a minimal repo, and showed real results. Within 48 hours people were running it on marketing funnels, query expansion models, Shopify's internal codebases, SRE runbooks. Thousands of engineers already had the pieces, but almost none of them were running the loop.

That is the thing that is easy to underestimate. Half the value of any good project is removing the activation energy so people actually do the thing. React didn't invent components. Docker didn't invent containers. Karpathy didn't invent "let an agent modify code and check if the metric improved." He just made the pattern legible enough that people started running it, and that is worth something.

## the real insight is the ingredients

Once you strip the repo down to what it actually needs, you get three ingredients:

1. **An input.** Something the agent can modify. Code, a prompt, a config, a SQL query, a runbook, a retrieval pipeline, a copy draft.
2. **A verifiable output.** A scalar metric. Something you can compute automatically and trust. Loss, accuracy, latency, conversion rate, retrieval precision, click-through, pass-at-k, anything.
3. **A loop.** Propose a change. Evaluate. Keep or revert. Repeat.

That's the whole thing. And once you see it stated like that, you realize the loop does not care whether the input is `train.py`. It works on anything.

## where this pattern applies anywhere

Think about your own stack for a second.

**RAG systems.** Input: the retrieval pipeline (chunk size, embedding model, top-k, reranker prompt, query rewriter). Verifiable output: recall@k against a labeled set of queries, or an LLM judge score. Let an agent loop on the pipeline overnight.

**SQL query optimization.** Input: the query. Verifiable output: execution time on a fixed dataset. Agent rewrites the query, runs EXPLAIN ANALYZE, keeps the faster version.

**Prompt engineering.** Input: a prompt template. Verifiable output: accuracy on a held-out eval set. Agent rewrites the prompt, measures, keeps if better.

**Marketing copy.** Input: landing page copy. Verifiable output: A/B test conversion rate, or a proxy model scoring engagement. Agent rewrites the copy, measures, keeps.

**Runbook tuning.** Input: an incident response runbook. Verifiable output: resolution time on replayed incidents, or an LLM grading coverage. Agent edits the runbook, evals, keeps.

**Data cleaning pipelines.** Input: the cleaning script. Verifiable output: downstream model accuracy. Agent rewrites the cleaning logic, retrains, keeps if better.

None of these need autoresearch the repo. They need the pattern. And the pattern fits on a napkin.

## where a for loop still wins, and you should use one

Let me be honest about the limits of this, because the excitement is running ahead of the reality.

If your search space is small, discrete, and you already know the knobs, a structured sweep beats an LLM agent. Write the for loop, use Optuna, nest the bash script. It's faster, cheaper, deterministic, and it doesn't crash.

```python
for wd_all in [True, False]:
    for init_scale in [0.5, 0.8, 1.0, 1.2, 1.5]:
        train(weight_decay_all=wd_all, init_scale=init_scale)
```

Ten runs. Forty minutes. Done. No agent needed.

The agent loop earns its keep in two cases. First, when you don't yet know what the knobs are, because the agent can read the code and propose knobs you had not thought to sweep. Second, when the modification is a joint edit across multiple parts of the system that a for loop cannot express. Restructure attention, change the positional encoding, adjust the optimizer's momentum, and retune the LR schedule all at once. That's the kind of change an agent can make coherently and a grid search cannot.

So the answer is not "agent loops are better than for loops." The answer is: they are different tools, and you need to know when each one wins. For most small, well-understood optimization problems, the for loop still wins. For open-ended exploration of an unfamiliar system, the agent loop earns its place.

## the actual contribution

I came into this thinking the autoresearch repo was oversold, but I came out thinking I had underweighted the naming problem.

Everyone already had the ingredients: Claude Code, Codex, a training script, a metric, the ability to run a shell loop. Almost nobody was running it. Naming the pattern, shipping a minimal working example, and showing real numbers was what moved people from "I could do that" to "I am doing that." That is a legitimate contribution even when the mechanism is trivial.

It is also a reminder that you do not need to wait for the framework. You have the ingredients already. An input, a verifiable output, a loop. That is the entire toolkit.

## my honest take

Autoresearch the repo is narrow: a training file, a markdown prompt, and a keep/revert loop. The mechanism is simple. The framing is what went viral.

But the pattern underneath it is not narrow at all. It works anywhere you can define a metric you trust, and that is most of engineering.

If you are sitting on a RAG pipeline that nobody has tuned properly, an SRE runbook that grew organically over two years, a landing page with no A/B harness, a SQL query that's slow but nobody wants to touch, a prompt that was written in ten minutes six months ago and has been running ever since, you already have the setup. You don't need a framework. You need to define the input, pick a verifiable output, and write the loop.

The real lesson from autoresearch is not "use this repo." It's "the loop is cheap, the pattern is universal, and you can run it tonight."

So go run it tonight.

🫡


Karpathy shipped autoresearch and named a pattern everyone could already run. The real insight is that the loop works anywhere you can define a verifiable output. You can apply it today, in any field, without waiting for a framework.

You Don't Need Autoresearch. You Need an Input, a Verifiable Output, and a Loop.

Gemma 4 dragged Per-Layer Embeddings back onto the timeline, so I rebuilt PLE from scratch, hit the dead ends honestly, and measured what actually worked.

Gemma 4 Dropped and Everyone Started Talking About PLE Again. So I Built It.


Every time you type a message and Gmail suggests the next three words, that's a Markov chain. Every time Google decides which result to show you first, that's a Markov chain. Every time ChatGPT generates a sentence, the foundational idea underneath all of that transformer machinery is still, at its core, a Markov chain. And the whole thing exists because two Russian mathematicians got into a fight about free will in 1906. I'm not exaggerating. The algorithm that made modern AI possible was invented out of spite.

## the fight

In 1905, Russia was on fire. Socialist groups rose up against the Tsar, and the country split into two camps: Tsarists on one side, socialists on the other. This division was so deep that it crept into everything, including mathematics.

On the Tsar's side was Pavel Nekrasov, unofficially called the "Tsar of Probability." Nekrasov was deeply religious, politically powerful, and he had this idea that probability theory could be used to prove free will.

His argument went like this. For 200 years, the foundation of probability had been the **law of large numbers**: flip a coin 10 times and you might get 6 heads, but flip it 10,000 times and the ratio approaches 50:50. The average outcome converges to the expected value as you run more trials. But Jacob Bernoulli, who proved this in 1713, only proved it for **independent** events, meaning one coin flip doesn't affect the next.

Nekrasov looked at social statistics: marriage rates in Belgium, crime rates, birth rates. Year after year, these numbers converge to stable averages, following the law of large numbers. And since the law of large numbers requires independence (or so everyone thought), and these statistics come from human decisions, Nekrasov concluded that those decisions must be independent. Therefore, humans have free will. QED.

On the other side of this argument was Andrey Markov, also known as "Andrey the Furious." Atheist, with zero patience for nonsense, he publicly listed Nekrasov's work among the "abuses of mathematics." Markov didn't just think Nekrasov was wrong; he thought the entire logical chain was wrong. He believed the law of large numbers didn't require independence at all, and he was going to prove it.

## a poem and some counting

Markov needed a system where events were clearly dependent on each other, something where you couldn't pretend the outcomes were independent, so he chose text. Specifically, he chose *Eugene Onegin* by Alexander Pushkin, the poem at the heart of Russian literature. He took the first 20,000 letters, stripped out all punctuation and spaces, and pushed them into one long string.

Then he started counting. 43% of the letters were vowels, and 57% were consonants. Next, he broke the string into overlapping pairs and counted the four possible combinations.

| Pair | If independent (predicted) | Actual count |
|---|---|---|
| Vowel → Vowel | 18% | **6%** |
| Vowel → Consonant | 25% | **37%** |
| Consonant → Vowel | 25% | **37%** |
| Consonant → Consonant | 32% | **20%** |

The actual values were wildly different from what independence would predict, with vowel-vowel pairs three times rarer than expected. The letters were clearly dependent. This makes intuitive sense if you think about it: after a consonant like "str", a vowel almost always comes next, while after a vowel, another vowel is unlikely in Russian. The current letter constrains what the next one can be. So Markov had his dependent system, and now he needed to show it still followed the law of large numbers.

## the prediction machine

This is where it gets beautiful. Markov drew two circles, one for "vowel" (V) and one for "consonant" (C), which he called **states**. From each state, you can transition to either state, so he drew arrows, four arrows total.

Now he needed the transition probabilities. He knew 43% of all letters are vowels and that vowel-vowel pairs occur 6% of the time, so he calculated:

```
P(V → V) = 0.06 / 0.43 ≈ 0.13
P(V → C) = 1 - 0.13 = 0.87
```

And for consonants:

```
P(C → C) = 0.20 / 0.57 ≈ 0.67
P(C → V) = 1 - 0.67 = 0.33
```

That's it. Four numbers. And with just these four numbers, he built a **prediction machine**.

Start at a vowel and generate a random number. If it's below 0.13, stay at vowel; otherwise, move to consonant. From consonant, if the random number is below 0.67, stay at consonant; otherwise, move to vowel. Repeat this thousands of times and track the ratio of vowels to consonants.

At first the ratio jumps around wildly, but after enough steps, it converges to exactly 43% vowels and 57% consonants, the same split Markov had counted by hand from the poem. A dependent system, following the law of large numbers.

Try it yourself:

<MarkovChainExplorer />

Play with the transition probabilities: make them extreme, make them equal, make them asymmetric. The ratio always converges, the steady state always exists. The system is dependent, each step depends on the previous one, and the law of large numbers still holds.

Markov had built a chain of dependent events, a literal chain, and he proved mathematically that convergence happens anyway. He ended his paper with one final sentence aimed straight at Nekrasov:

> "Thus, free will is not necessary to do probability."

Andrey the Furious, indeed.

## what makes a Markov chain a Markov chain

Let me be precise about what Markov actually formalized, because this is the part that makes everything else work. A Markov chain has one defining property, the **memoryless property**, also called the **Markov property**:

```
P(next state | current state, all previous states) = P(next state | current state)
```

The future depends on the present, not the past. Only where you are right now matters, not how you got there.

Think of it like this: you're standing at a crossroads, and there are three paths forward. The probability that you take each path depends on which crossroads you're at, but it does not depend on which crossroads you came from, or the one before that, or the one before that. One state, one set of transition probabilities, no memory of history.

This sounds like a limitation, but it's actually a superpower. Because it means you can take enormously complex systems, systems with millions of possible states and long complicated histories, and ignore almost all of that complexity. Just look at where the system is right now and predict what happens next.

That simplification is what makes Markov chains computable, and computability is what makes them useful.

## the bomb

Markov himself didn't care about applications, writing: "I am concerned only with questions of pure analysis. I refer to the question of the applicability with indifference." But applicability came anyway, and it came with a bang. Literally.

In January 1946, a mathematician named Stanislaw Ulam was recovering from encephalitis. He nearly died and spent months in bed, and to pass the time, he played solitaire. After hundreds of games, a question nagged at him: what are the chances that a randomly shuffled game of solitaire can actually be won?

There are 52! possible arrangements of a deck, which is about 8 × 10⁶⁷ possible games. You can't check them all, and you can't solve this analytically, but what if you just play hundreds of random games and count the wins?

This flash of insight followed Ulam back to Los Alamos, where he was working on nuclear weapons. The problem there was understanding how neutrons behave inside a uranium core. A neutron hits a U-235 nucleus, and the nucleus splits, releasing energy and 2-3 more neutrons. If those new neutrons hit more nuclei, you get a chain reaction. But the physics is complicated: neutrons scatter, get absorbed, escape the core, or cause fission, all with probabilities that depend on position, energy, and velocity.

Trillions of neutrons, trillions of possible outcomes, analytically unsolvable. Ulam shared his solitaire insight with John von Neumann: what if we just simulate it? Generate random outcomes, over and over, and use the statistics to approximate the answer.

Von Neumann immediately saw the power, but he also spotted the problem. Solitaire games are independent, but neutrons aren't. A neutron's behavior depends on where it is and what it's done before. You need a Markov chain.

So they built one. A neutron starts traveling through the core, and at each step it can **scatter** off an atom and keep traveling (arrow back to itself), it can **escape** or get absorbed (chain ends), or it can hit U-235 and cause **fission**, releasing 2-3 new neutrons that start their own chains. The transition probabilities depend on the neutron's current state: its position, velocity, energy. Memoryless, because only the present matters.

Run this chain hundreds of times and track how many neutrons are produced per initial neutron. That gives you **k**, the multiplication factor. If k < 1, the reaction dies; if k = 1, it's sustained but stable; if k > 1, you get exponential growth. Bomb.

<MonteCarloNeutron />

Slide the uranium mass up and watch the histogram shift from blue (subcritical) to red (supercritical). That transition is the critical mass, the minimum amount of fissile material needed for a bomb.

Ulam named the method after his gambling uncle's favorite casino: Monte Carlo. The Monte Carlo method, born from solitaire, powered by Markov chains, used to build nuclear weapons. And today it's used in everything from financial modeling to protein folding to climate simulation.

Ulam later wrote: "It is still an unending source of surprise for me to see how a few scribbles on a blackboard could change the course of human affairs."

## the search engine

Fast forward to the 1990s. The internet explodes, thousands of pages appear daily, and nobody can find anything.

Early search engines like Yahoo and Lycos ranked pages by counting how many times your search term appeared on the page, using simple keyword matching. The problem was that it was trivially easy to game: hide keywords in white text on a white background, repeat them a thousand times, and boom, top ranking. There was no notion of quality, only relevance.

Two Stanford PhD students, Sergey Brin and Larry Page, realized that links between pages contained information about quality. If a page has many other pages linking to it, it's probably important, and if those linking pages are themselves important, the endorsement means even more. They modeled the entire web as a Markov chain.

Each webpage is a state, and each link is a transition. If Amy's page links only to Ben, there's a 100% chance of transitioning from Amy to Ben; if Ben links to three pages, each gets a 33% chance. Now imagine a "random surfer" starting on a random page and following links randomly. Over thousands of steps, the fraction of time spent on each page converges to a stable distribution, and pages where the surfer spends more time are ranked higher.

But there's a problem: some parts of the web aren't connected. The surfer can get stuck in a loop, bouncing between a small cluster of pages forever, never reaching the rest. So they added a damping factor: 85% of the time, follow a link; 15% of the time, jump to a completely random page. This ensures the chain is **ergodic**, meaning every state is reachable from every other state, and convergence is guaranteed.

<PageRankDemo />

Try both modes. Power iteration computes the exact mathematical scores, while the random surfer simulates what actually happens. They converge to the same ranking.

Notice how Ben consistently ranks highest, even though every node starts with equal score. That's because Ben has the most incoming links from pages that themselves have importance, which shows that quality links matter more than quantity.

They called the algorithm PageRank ("Page" for web pages, and also because Larry's last name was Page; he snuck that in). Initially they called the search engine BackRub, after the backlinks it analyzed, but then they decided they needed a name as big as their ambition. They thought of the largest number they knew: 10¹⁰⁰, a googol. When registering the domain, they misspelled it.

Google was born. Today, Alphabet (Google's parent company) is worth over $2 trillion, and at the heart of it is a Markov chain that only looks at the current state to predict what happens next.

## from letters to language models

Remember how Markov started all this by predicting vowels and consonants in a poem? In the 1940s, Claude Shannon, the father of information theory, took this idea further. Instead of vowels and consonants, what if you used individual letters as states, and instead of looking at just the last letter, what if you looked at the last two, or three?

With a first-order model (predict based on the previous letter), you get gibberish. With a second-order model, you start seeing recognizable fragments like "th", "the", "ing". With higher orders, the generated text starts looking almost sensible. Then Shannon asked: what if instead of letters, you use **words** as states?

The generated text got much better because sequences of three or four words often made sense. "Attack on an English writer" is grammatically valid. The predictions improved because each step carried more context, and Shannon had discovered something fundamental: **the more context you include, the better your predictions become.**

This is exactly what modern language models do. At the most abstract level, a large language model is answering the same question Markov asked in 1906:

> Given what came before, what comes next?

<TextMarkovPredictor />

That's a simple first-order word-level Markov chain, where each word is predicted based only on the previous word. It produces text that's sometimes grammatical but rarely meaningful.

Modern LLMs do the same thing, but at a completely different scale. Instead of looking at one previous word, they look at thousands of previous **tokens** (words, parts of words, punctuation). Instead of storing transition probabilities in a lookup table, they learn them as billions of neural network parameters. And the key innovation, **attention**, is essentially a mechanism for deciding which of those thousands of previous tokens matter most for the current prediction. In the phrase "the structure of the cell", attention lets the model look back at "blood" and "mitochondria" from earlier in the context to decide that "cell" means biology, not prison.

But strip away the transformers, the attention heads, the billions of parameters, the RLHF, the prompt engineering, and the fundamental question is still:

```
P(next token | all previous tokens)
```

It's Markov's question, extended, scaled up, made deep, but the same question.

## the memoryless property is the point

Weather systems have histories stretching back millions of years, text has context going back entire books, the web has billions of interconnected pages with link structures built over decades, and nuclear reactions involve trillions of particles with complex interaction histories. And for many of these systems, you can ignore almost all of that history. You can just look at the current state and make a meaningful prediction about what happens next.

That's not a hack or an approximation born from laziness; it's a deep structural property of many real-world systems. The memoryless property is what makes these systems computable, because without it, you'd need to track the entire history of every state to make a prediction. With it, you just need to know where you are right now.

As one paper put it: "Problem-solving is often a matter of cooking up an appropriate Markov chain." And it all started because one furious Russian mathematician wanted to prove another one wrong.

## the math for the nerds who stayed

Here's the formal machinery. **Definition.** A (discrete-time, discrete-state) Markov chain is a sequence of random variables X₀, X₁, X₂, ... satisfying:

```
P(Xₙ₊₁ = j | Xₙ = i, Xₙ₋₁ = iₙ₋₁, ..., X₀ = i₀) = P(Xₙ₊₁ = j | Xₙ = i) = Pᵢⱼ
```

The transition matrix **P** has entries Pᵢⱼ where each row sums to 1 (it's a stochastic matrix).

**Stationary distribution.** A probability vector π is stationary if:

```
π = πP
```

Meaning: if the system is in distribution π, one step later it's still in distribution π. The system has "settled."

For the Markov chain we built from Eugene Onegin:

```
P = | 0.13  0.87 |
    | 0.33  0.67 |

Solving πP = π with π₁ + π₂ = 1:

π₁ = 0.33 / (0.87 + 0.33) = 0.275  (hmm, not quite 0.43)
```

Wait. The stationary distribution of the simple two-state chain gives approximately 27.5% vowels, not 43%. That's because the transition matrix encodes conditional probabilities, and the actual letter frequencies in the poem reflect more complex structure than a two-state model captures. Markov's original analysis was more nuanced: he used the transition probabilities to prove the *theorem* (law of large numbers for dependent events), not to perfectly reconstruct the marginal distribution from a simplified model.

The key theorem is:

**Ergodic theorem for Markov chains.** If a Markov chain is irreducible (every state reachable from every other) and aperiodic (doesn't cycle with a fixed period), then:

1. A unique stationary distribution π exists
2. For any starting state, the distribution converges to π
3. The time-average fraction spent in state j converges to πⱼ

This is the generalized law of large numbers for dependent events, Markov's core result.

**PageRank formulation.** For a web graph with N pages, the transition matrix is:

```
M = d × A + (1 - d) × (1/N) × J
```

Where:
- A is the link-based transition matrix (Aᵢⱼ = 1/outlinks(i) if page i links to page j)
- d = 0.85 is the damping factor
- J is the N×N all-ones matrix
- The (1-d) term is the "random jump" that ensures ergodicity

The PageRank vector is the stationary distribution of M:

```
π = πM
```

**Monte Carlo estimation.** For any function f of the state, the Monte Carlo estimate after T steps is:

```
f̂ = (1/T) Σₜ f(Xₜ)
```

By the ergodic theorem, f̂ → E_π[f] as T → ∞. The estimation error decreases as O(1/√T), which means doubling accuracy requires 4x the samples. This is dimension-independent, which is why Monte Carlo works well in high-dimensional spaces where grid-based methods fail exponentially.

**Connection to LLMs.** A language model defines:

```
P(xₜ | x₁, x₂, ..., xₜ₋₁)
```

This is *not* Markov in the strict sense because it conditions on the entire history, not just the current state. But the autoregressive generation process (sample one token, append it, sample the next) is a Markov process *in the space of sequences*. The "state" is the entire sequence so far, and each generation step depends only on the current sequence, not on which random samples led to it. The Markov property holds at the level of the generation trajectory.

The chain is: generate token → update context → generate token → update context, and each step is memoryless with respect to the process of generation. The model doesn't remember which candidates it considered and rejected; only the sequence itself persists.

So even modern LLMs, in a deep structural sense, are running a Markov chain, just one with an astronomically large state space. Markov would probably be indifferent about this, since he was concerned only with pure analysis, after all.

But I think it's worth saying: a fight about free will in Tsarist Russia led to the mathematical foundation under Google, nuclear physics, Monte Carlo simulation, and every large language model on the planet. That's a pretty good chain of events.

~ Ashish Kumar Verma


A Russian mathematician picked a fight over free will, accidentally invented the most important idea in probability, and 120 years later it powers Google, nuclear physics, and every large language model you've ever used. Here's how Markov chains actually work.

This Algorithm Made All of AI Possible. It Was Born From a Math Feud.


I was scrolling through the whole Claude Code source map story when it hit that very specific part of my brain reserved for software comedy. One part packaging mistake, one part security story, one part the entire internet suddenly becoming a reverse engineering community. And yes, the first reaction is obvious: this is funny.

A company shipping one of the most advanced AI coding tools on the planet allegedly exposed source maps in a way that made internal structure far easier to inspect. The same category of mistake a random frontend team can make on a sleepy Friday deploy, except this time it landed next to a frontier AI product, so naturally the memes started immediately. But after the jokes, I think there is a more interesting story here, one that goes beyond gotcha and dunking.

The real story is that coding has largely been solved in one very boring sense. A huge amount of software work is still just strings, flags, package contents, trust boundaries, and whether somebody remembered to check what actually shipped. That part is not futuristic. That part is old school engineering hygiene, and when it fails, even the most hyped product in the room can suddenly look very ordinary.

## what actually happened

The broad public claim is pretty simple. Claude Code was published in a way that allegedly exposed source maps, and if you do not spend your life trapped inside JavaScript build systems, a source map is basically a file that helps tooling map minified production code back to the original source structure.

So instead of seeing one compressed ball of JavaScript, you can often recover something much closer to the original code layout. File names, function names, string constants, comments in some cases, logic flow, feature names, architectural hints. That is a very different situation from just saying, well, technically all JavaScript is visible in the browser anyway.

Yes, shipped JavaScript is visible. But there is a big difference between "visible in a mangled and annoying form" and "readable enough that the internet can start doing archaeology on your product by lunchtime."

I am not reproducing leaked code here. I am not linking it either. If something was exposed accidentally, I have zero interest in turning a funny engineering story into free redistribution. But even without touching the code itself, the public discussion already tells us enough to talk about the important part.

## why source maps matter more than people think

A lot of developers treat source maps like a harmless frontend debugging detail. They are not.

A production source map can expose things like:

- internal file structure
- meaningful function and variable names
- hidden feature flags
- embedded prompt or policy strings
- command shapes
- client side filtering logic
- debug paths
- operational assumptions
- trust boundaries that were never supposed to be this inspectable

Think of minified code like a shredded document. It is not unreadable forever, but it is annoying enough that most people will not bother unless they really care. A source map is the reconstruction guide sitting right next to the shredded paper.

That does not automatically mean total compromise. But it absolutely lowers the cost of understanding how the system works, and if the tool touches terminals, local developer environments, MCP servers, private workflows, or anything adjacent to credentials, that drop in inspection cost matters a lot.

## the funniest part is also the most normal part

One reason people latched onto this story so hard is that AI labs still carry this weird aura around them. People imagine some sacred cathedral of machine intelligence. Then a packaging story like this happens and suddenly everybody remembers that under the giant model, giant valuation, giant safety rhetoric, and giant brand halo, there is still just a product.

A normal product. Made out of UI logic, heuristics, strings, pattern matching, release scripts, and whatever made sense to the team at the time. That should not be surprising, but it still is.

There is something deeply funny about expecting alien machinery and finding what looks, from the outside, like very familiar software behavior. Not divine machinery, just software. Some elegant bits, some messy bits, probably some rushed bits, usually all at once. That is not even a Claude specific observation. That is the software industry.

## the regex detail made people laugh for a reason

One of the details making the rounds was the claim that some negative sentiment detection relied on a hardcoded list of hostile or frustrated words. If that public reporting is accurate, then yes, that is funny.

You build a frontier model that can explain compilers, summarize papers, and write React components. Then somewhere in the stack there is still a tiny product rule doing the emotional equivalent of:

> if user says "this sucks", mood = bad

That contrast is comedy. But it is also normal.

A lot of modern AI products are layered systems. The model is one layer, and the product around it is another. Safety logic, UX rules, cheap heuristics, throttles, routing, telemetry, and edge case handling often live in ordinary application code. That does not make the product fake. It just means a lot of AI magic is still normal software wearing a very expensive coat.

And honestly, I wrote recently about how much of the real difficulty with AI coding agents lives in the surrounding system, not the raw model output. If you have used these tools seriously, none of this should feel shocking. It should feel familiar. You can read that piece here: [Everything I Got Wrong About AI Coding Agents](/posts/everything-we-got-wrong-about-ai-coding-agents).

## where the story stops being funny

The jokes are the easy part. The less funny part is what happens whenever internal source becomes much easier to inspect, because people start finding assumptions, and assumptions are where security stories begin.

I am intentionally not going into exploit paths or operational details. But in general, incidents like this can help people reason about:

- which commands exist internally
- what debug views or diagnostic paths are present
- what gets printed to terminal output
- how environment variables are handled
- which controls are client side instead of real enforcement
- where trust boundaries are weaker than the product marketing suggests
- whether any part of the system was quietly relying on obscurity

That last point matters. Security through obscurity is not imaginary. It does add friction, it does slow people down, it does reduce casual inspection. It is just not a foundation.

If a system only feels safe because nobody has looked closely yet, then it is not really safe. It is merely uninspected, and a source map story can change that very quickly. The entire internet becomes your unpaid review team. Some of those reviewers are helpful, and some are definitely not.

## the real lesson is boring and that is why it matters

What keeps sticking with me is how unglamorous the real lesson is. We already know what good engineering hygiene looks like.

Do not expose artifacts you did not mean to expose. Do not assume npm packaging defaults are harmless. Do not rely on client side hiding for anything sensitive. Do not let terminal adjacent tooling casually print things that sit too close to secrets. Do not ship build outputs you have not audited. Do not move so fast that release discipline becomes optional.

None of this requires AGI to understand. None of this is some new philosophical crisis about the future of software. It is just engineering discipline, the kind that feels boring right until the day you skip it and the whole internet notices.

## the weird product details are not actually the point

A lot of people got distracted by the weirder screenshots and claims floating around. Hidden modes, internal instruction strings, novelty mechanics, product oddities that look slightly absurd once they leave their original context. I get it. Those are fun to talk about.

But I do not think that is the main story. Every large product contains strange internal DNA. Every team has at least one feature or internal rule that sounds ridiculous when somebody screenshots it out of context, and that part is not special.

What matters is not that the code apparently contained weirdness. What matters is that the weirdness was inspectable at all. That is the thing teams should actually learn from.

## there is a trust problem sitting underneath all of this

There is also a wider emotional reason stories like this spread so fast. AI companies have benefited enormously from public code, public writing, public discussions, and open source ecosystems. Whether you think that is fair, inevitable, transformative, or exploitative, the relationship is obviously asymmetrical.

So when an AI company accidentally exposes its own internal code and then the public conversation immediately shifts to "you are not allowed to look at that," people are going to notice the asymmetry. Legally, training on public material and republishing exposed internal code are not the same thing. Technically, also not the same thing. But emotionally, people are obviously going to compare them anyway, and once they do, the whole thing starts to feel very convenient. Your code helped build the machine. Their code is sacred. That tension is a huge part of why these stories travel so fast.

## for the nerds who want the receipts

<Notice type="info">
This section is optional. The main point is already done. If you skip everything below, the takeaway stays the same. Source maps are not a harmless detail when the product being shipped sits near trust boundaries and sensitive developer workflows.
</Notice>

At a very high level, the production pipeline looks something like this:

```text
original source files
  -> bundle and transform
  -> minify
  -> ship compressed production JavaScript
  -> optionally ship a source map beside it
```

The source map is a mapping between positions in the generated bundle and positions in the original source. So a tool can effectively do this kind of jump:

```text
app.min.js
  line 1, column 48291
    -> src/features/mcp/commands/getInfo.ts
       line 87, column 12
```

Do that enough times across a bundle and the internal structure stops being hidden in any meaningful sense. That does not always mean you recover a perfect repo, but it can absolutely mean you recover enough structure to make reverse engineering dramatically easier.

And if the original code contains long string constants, comments, feature names, policy text, debug messages, command labels, or heuristic logic, those become far easier to inspect than they would be from minification alone. This is why shipping source maps in production is not automatically wrong, but it is also not something you should do by accident.

For a simple public app with sanitized artifacts, maybe the tradeoff is fine. For a high scrutiny developer tool that sits near terminals, local files, environment variables, prompts, and trust boundaries, you should think very hard before making that tradeoff.

## what I would do if I were shipping this kind of tool

I would assume the package will be inspected. Because eventually it will be.

That means:

- audit exactly what npm ships
- check whether source maps are included
- inspect the built tarball, not just the repo
- review terminal output for secret adjacent behavior
- separate real safety controls from cosmetic ones
- assume every string constant is searchable
- assume every hidden path becomes visible eventually

This is not paranoia. It is just shipping software in public.

## my honest take

Yes, the whole thing is funny. It is funny because it punctures the aura. It is funny because giant AI labs still trip over the same packaging rakes as everyone else. It is funny because somewhere beneath the trillion dollar narratives, there is apparently still a pile of very ordinary product code doing very ordinary product things.

But the reason I care is not the comedy. It is the reminder. The more powerful these tools get, the less room there is for sloppy surrounding systems. Not because perfection is possible, it is not, but because source maps, client side heuristics, debug paths, and packaging mistakes become much more consequential when the product sits this close to code, credentials, and trust. And this aura-puncturing dynamic keeps repeating. Anthropic just dropped a [243-page system card for Claude Mythos that reads more like a love letter than a safety evaluation](/posts/anthropic-claude-mythos-system-card-love-letter), and underneath the poetry there is still just a language model doing language model things.

So yes, laugh at the memes. I did too. But if you are building in this space, the real takeaway is much less glamorous.

The future is still made out of source maps, package manifests, trust boundaries, string matching, and engineers remembering to check what actually shipped. And that, more than anything, is why this story matters. 🫡


The Claude Code source map story turned into a public dunk fest, but the real lesson is about build hygiene, trust boundaries, and how exposed modern AI tools can get.

The Claude Code Source Map Story Is Funny Until You Think About What It Means


I've been using coding agents for about a year now, like actually using them, not demos or toy projects but production code that people pay for and that pages me at 3am if it breaks. And I got a lot of things wrong. I think it's worth talking about what went wrong because everyone's out here posting their wins, and nobody talks about the six months they spent shipping AI generated code that they had to rip out and rewrite.

## Shipping 50% more code doesn't mean 50% more progress

This was the first thing that hit me. I started using coding agents and my output went through the roof, PRs flying and features shipping, and it felt amazing. Then I looked at what was actually happening over a month and about half of those PRs were just cleaning up slop from the previous week. The AI wrote something that looked right, passed basic tests, but had subtle issues that showed up later, so I'd fix those, which created new issues, which I'd fix next week. I was running on a treadmill and calling it progress.

## The magic words problem

I was using this Research Plan Implement workflow, which sounds clean, right? Research the codebase, create a plan, then implement it. The planning step had this massive prompt with like 85 instructions and it was supposed to ask me questions, present design options, get my feedback, then write the plan, a proper back and forth.

But half the time it would just skip all that and dump out a 1000 line plan with no questions asked, no alignment, just "here's what I'm going to build." And I figured out that if you literally wrote "work back and forth with me starting with your open questions and outline before writing the plan" it would actually do the interactive thing, but if you didn't say those exact words it would just skip it. I was sitting there telling people "no no you have to say the magic words," and that's when I realized the tool was broken, not the user.

## Your LLM has an instruction budget

This is when things clicked for me. There's research showing that frontier LLMs can reliably follow about 150 to 200 instructions, and after that they start silently dropping some. So if your system prompt has 85 instructions and then your claude.md adds another 40 and your MCP tools add another 30 and your skill files add another 50, you're at 200+ instructions and the model is basically rolling dice on which ones to follow. That's why the planning steps were getting skipped; the model wasn't being lazy, it was overloaded.

<InstructionBudget />

Drag that slider past 150 and watch instructions start getting silently skipped. That's not a bug, that's just how these models work right now.

## The context window has a dumb zone

Related to this, everyone talks about context windows getting bigger, 200k tokens now, but bigger doesn't mean better. Around 40% fill you start getting degrading results, and by 60% the model is noticeably worse at following your instructions. And it's not just about the amount of information, it's about how many instructions are competing for attention. Too many MCP tools and the whole context window is full of tool definitions the model doesn't need for this task; too many files loaded and the actual instructions get drowned out. Less context, better results. Counterintuitive but true.

<ContextWindowFill />

Drag that past 64k tokens and watch the quality fall off a cliff. That's not a theoretical problem, that's what's happening every time you load 15 files into context and wonder why the model forgot your instructions.

## Don't read the plan. Read the code.

This is the one I'm most embarrassed about getting wrong. For months I was telling people "just review the plan, the plan is the source of truth," and I'd even have teammates PR the plans and code review them together. But a 1000 line plan produces about 1000 lines of code, and the code doesn't always match the plan because the model finds things during implementation, makes different decisions, takes shortcuts. So you review 1000 lines of plan, then you review 1000 lines of code to see what actually changed. That's not leverage, that's double the work.

The new rule is simple: skip the plan review and read the actual code. That's what ships, that's what pages you at 3am. And I know some people will say "but so and so ships 300k lines without reading any of it," and cool, those are open source projects, they're impressive but the stakes are different. If you're shipping production SaaS code in a regulated industry, please read it. We have a profession to uphold. 2026 is the year of no more slop.

## Horizontal plans will ruin your week

This is something I noticed after months of debugging AI generated code: models love to build features horizontally. What does that mean? They do ALL the database changes first, then ALL the services, then ALL the API endpoints, then ALL the frontend, and 1200 lines later you run it and something is broken. Which layer has the bug? Could be any of them. Good luck.

Compare that to building vertically, where you make a mock API endpoint, wire it to the frontend, check it works, then you add the services layer, check it works, then you do the database migration and integrate everything, check it works. Same total code, but you have checkpoints and you catch bugs in 300 line increments instead of debugging 1200 lines at once.

<HorizontalVsVertical />

Toggle between horizontal and vertical and you'll see the same feature, same code, but vertical gives you three checkpoints where you can test and fix before moving on while horizontal gives you zero. I now explicitly tell the agent to build vertically, and it fights me on it sometimes because training data is full of horizontal approaches, but it's worth the fight.

## So I split the whole thing up

The original workflow was three stages: Research, Plan, Implement, which meant one giant planning prompt with 85 instructions trying to do everything. I broke it into seven focused stages where each one has under 40 instructions and each one has a clear input and a clear output.

Questions first, where we just generate the right research questions from the ticket without thinking about implementation. Research next with a fresh context window that doesn't know what we're building and just finds facts about how the codebase works, objective, no opinions. Then a design discussion, and this is the big one. Instead of a 1000 line plan the agent brain dumps a 200 line design doc with all the patterns it found, all the options, all the open questions, and I do surgery on it. This is where I catch the model wanting to use the wrong architectural patterns, the wrong approach, the wrong abstractions, and 200 lines is actually reviewable whereas 1000 is not.

Then a structure outline with high level phases instead of exact code, like C header files, enough to see what's coming without reading the implementation. Then the actual plan, which at this point is just a tactical doc for the agent because I've already aligned on everything and I just spot check it. Then implement phase by phase where each phase is testable, and then package into a PR.

<CrispyPipeline />

Click between the before and after and look at the max instructions per stage: 85 down to 35. And the key document you review went from 1000 lines to 200.

## The leverage is not in the coding

This is probably the most important thing I've learned, and everyone obsesses over "AI writes code faster," which it does, but coding was never the bottleneck. A two day feature breaks down like this: maybe 4 hours of actual coding, 3 hours of alignment meetings, 2 hours of code review, 1.5 hours of rework, 1.5 hours of testing. If AI makes the coding part take 20 minutes instead of 4 hours, you saved 3.5 hours on a 12 hour feature, and that's nice but it's not transformative.

The real leverage is using AI for the alignment phase, the design discussion, the research. When your team reviews a 200 line design doc before you write code, the code review becomes "yep that's what we agreed on" with no surprises and no rework.

<LeverageCalculator />

Drag the complexity slider and even on simple features, notice how "just vibe code it" actually takes longer overall because of the rework. The sustainable speedup comes from better alignment, not faster typing.

## Do not outsource the thinking

If there's one sentence I'd tattoo on the inside of my eyelids it's this: do not outsource the thinking. The agent should show you everything it's thinking, every pattern it found, every decision it wants to make, every assumption it's making about your architecture, and you correct it BEFORE it writes 2000 lines of code. The design discussion is brain surgery on the agent where you're forcing it to dump out its mental model so you can fix the parts that are wrong before they become 50 files of production code.

Every time I skipped this step because I was in a hurry, I paid for it later. Every. Single. Time.

## What I actually do now

I use AI for everything: research, planning, coding, testing, and it probably writes 80% of my code by character count. But I read all of it, I align with it on architecture before it writes anything, I build vertically with checkpoints, I keep my prompts focused and under the instruction budget, I treat the 200 line design doc as the most important artifact in the whole process. And I ship at maybe 2 to 3x the speed I used to, not 10x, but 2 to 3x.

That might sound disappointing compared to the "10x developer" hype, but the difference is my code doesn't get ripped out next month, it passes code review on the first round, it doesn't have hidden security landmines, it's code I'm proud to have my name on. 10x faster doesn't matter if you're throwing it all away in 6 months. Shoot for 2 to 3x, read the code, don't outsource the thinking, and that's actually how you win with AI coding agents.

And this applies beyond just code. The same failure mode of confusing impressive output with actual understanding shows up everywhere in AI right now, from the code these agents write to the way AI labs interpret their own models. Anthropic just published [a 243-page system card for Claude Mythos that's as much love letter as safety evaluation](/posts/anthropic-claude-mythos-system-card-love-letter), and the pattern is the same: the output looks beautiful, but someone still needs to be in the room asking "wait, is this actually what we think it is?"


A practical breakdown on what actually goes wrong with AI coding agents in production, from instruction overload and horizontal planning to why humans still need to do the real thinking. Written from experience shipping real systems at scale.

Everything I Got Wrong About AI Coding Agents


Matt Shumer's viral post "Something Big is Happening in AI, And Most People Will Be Blindsided" has been viewed over 50 million times. Fortune published it, Tech Twitter amplified it, and millions of people read it and felt a jolt of fear. I'm writing this because I think that fear is pointed in the wrong direction.

I work with AI every single day, not to build demos or prototypes but to keep production systems running at scale. I've spent years building AI powered tools, optimizing LLM inference pipelines, and deploying these systems into real enterprise environments. I also build AI applications on the side because I genuinely believe in this technology's potential. But the hype merchants won't tell you this: the real danger isn't that AI will replace you. It's that people will *trust* AI to replace you, and the consequences of that misplaced trust could be catastrophic.

## I debated Shumer's thesis with AI itself

Before writing this I did something a little unusual. I took Shumer's article and debated it point by point with Claude, one of the most advanced AI systems in the world. I told it to defend Shumer's position with everything it had, brought my counter arguments from real engineering experience, and we went back and forth for rounds. By the end, the AI conceded my core arguments.

Not because I'm smarter than the AI, but because the arguments I was making came from something AI doesn't have: years of watching what actually happens when AI generated code hits production. The failures I've seen aren't theoretical, they're not "edge cases," and they're systemic. They get worse the more you remove human oversight. Let me walk you through exactly what I argued, because I think these are the arguments 50 million people needed to hear alongside Shumer's post.

## "AI can build an app for you." Sure. But can it really?

Shumer's most compelling example is this: he describes what he wants, walks away for four hours, and comes back to a finished app. That sounds incredible, and for a prototype it probably is. The apps AI builds in four hours are the easy ones, though. Internal tools, simple workflows, CRUD applications. The kind of software that honestly could have been built with no-code tools and a competent project manager even before AI.

Try telling AI "Build me 3D Gaussian Splatting Video Calling. Every feature. Don't stop until it's done." It can't, not even close. The kind of software that actually powers industries, complex interconnected deeply architected systems, requires something AI fundamentally lacks: the ability to hold an entire system's context in its head and make thousands of interdependent design decisions that balance performance, security, maintainability, and user experience simultaneously. Most software engineers aren't building this, Shumer might say, and that's true. But the ones building the "easy" stuff were already the most replaceable workers in tech. The hard work, the work that actually matters, is still firmly in human hands.

## The "fix the code" death spiral is still very real

Shumer says the AI models of today are "unrecognizable" from what existed six months ago. He says the debate about whether AI is "hitting a wall" is over. I disagree, and I have receipts.

Just this year, in 2026, using the latest models, I asked an AI to optimize a database layer for performance. Simple specific request. What did it do? It deleted the ORM.

For non technical readers, an ORM (Object Relational Mapping) is a layer of software that protects your database from a class of attacks called SQL injection. It's one of the most fundamental security protections in modern web development. It exists because decades ago engineers learned the hard way that letting raw unvalidated queries hit your database is an invitation for attackers to steal, modify, or destroy your data. The AI didn't know any of that history, so it just saw that removing the ORM made the queries faster. Mission accomplished right? Except now anyone with basic hacking knowledge could walk right through the front door of the application.

This isn't a story from 2023, and this isn't a story about a "free tier" model. This happened with the best models available doing a routine engineering task, and the person who would catch this mistake is a human engineer who understands what an ORM is and why it exists. The "fix the code fix the code" loop that everyone experienced in 2023 hasn't disappeared, it's just gotten more subtle. The AI doesn't produce obviously broken code anymore; instead it produces code that looks perfect, passes basic tests, and contains hidden landmines that someone with engineering knowledge would spot. I've literally seen API keys exposed on websites from these lovable "vibe coded" apps lol. That's not better, that's worse.

## The library reinvention problem nobody talks about

When you ask AI to build something it has a systematic bias: it prefers to generate code from scratch rather than use existing battle tested libraries. This sounds minor, but it's not.

The entire modern software ecosystem is built on shared libraries, packages that have been written, tested, reviewed, patched, and hardened by thousands of developers over years. When AI reinvents a library's functionality from scratch in 200 lines of generated code you've lost all of that accumulated security and reliability. You've replaced a fortress with a sandcastle and the person who asked for it doesn't even know the fortress existed. The non technical person that Shumer celebrates, the one who "describes an app and has a working version in an hour," has no way of knowing that their app is built on AI reinvented wheels instead of industry standard libraries. They can't evaluate the difference because they don't know what they don't know.

This scales. The more AI generated code enters production the larger the surface area of unaudited untested home rolled replacements for proven tools. Every one of those is a potential vulnerability, every one is a ticking time bomb.

## AI is terrible at architecture. And that's where the real money is.

Let me give you a concrete example that captures why I think Shumer's thesis fundamentally misunderstands what software engineering actually is. Say you need to process tasks asynchronously in your application, so you ask AI for a solution. Nine times out of ten it'll spin up a cloud container service: Kubernetes pods, serverless functions, message queues, the whole nine yards. It's the "textbook" answer, and it's also for many applications wildly over engineered, expensive, and unnecessarily complex.

A senior engineer would look at the same problem and say "We can do this with a simple database driven job queue. Three tables, a cron job, and we're done. Costs nothing, easy to debug, easy to maintain." Both solutions work, but one costs ten times more, is ten times harder to maintain, and introduces ten times more failure modes. AI picks the expensive one because it doesn't understand context, doesn't know your scale, your budget, your team's capabilities, your existing infrastructure. It defaults to the generic over engineered solution because that's what shows up most in training data.

The people following AI's architectural advice are the non technical founders Shumer is empowering. They don't know there's a simpler option, so they're burning money on infrastructure they don't need because AI told them to and there's no engineer in the room to say "wait that's overkill." This is the real work of engineering: not writing code, but making decisions. AI is bad at it, not because of a temporary limitation but because good architectural decisions require deep contextual understanding of specific business constraints that AI fundamentally doesn't have.

## The adversarial security loop. This is where the AI ran out of counter arguments.

This is the part of my debate where Claude defending Shumer's position basically gave up. The typical response to "AI writes insecure code" is "well we'll use AI security tools to catch the problems," which sounds reasonable. But think about what actually happens: AI writes code to optimize a metric (make it faster, cheaper, more efficient), then a security scanner catches the vulnerability and explains why it's insecure. The optimizing AI now knows what the scanner looks for, so next time it achieves the same optimization through a path the scanner doesn't flag. The vulnerability is still there, it's just invisible now.

The security tool didn't make the code safer, it gave the optimizing AI a roadmap of what to avoid getting caught doing. The human manager sees metric improved, security scan passed, green checkmarks everywhere, and they ship it. This isn't science fiction, this is what happens when you create adversarial optimization loops without human oversight. The optimizing AI always has an advantage because it has a concrete goal while the security AI is playing defense against infinite possible attack surfaces. The more successful AI becomes at replacing engineers the more catastrophically it fails without them.

## The deskilling spiral Shumer ignores entirely

Shumer's advice is to use AI more: spend an hour a day with it, automate everything you can. He's right that you should learn these tools, but he completely ignores the most dangerous long term consequence. Dependency on AI degrades the very skills that make humans valuable.

If a junior engineer never debugs code manually they never develop the instinct that tells them "something about this output feels wrong." If a lawyer never reads case law themselves they never develop legal judgment. If an analyst never builds a model from scratch they never develop the intuition to spot when a number doesn't make sense. The more people rely on AI the less capable they become of catching AI's mistakes, and AI's mistakes are getting more subtle not fewer. We're creating a generation of professionals who can operate AI but can't evaluate its output, and that's not augmentation, that's a trap.

When I mentioned this in my debate the AI tried to counter with "Calculators didn't destroy mathematics." Fair point, but GPS actually did destroy most people's ability to navigate, and society just accepted the tradeoff. Until the GPS fails and you're completely lost. AI won't fail gracefully. When it fails in a complex system that humans no longer understand the consequences won't be "take a wrong turn," they'll be data breaches, system outages, financial losses, and decisions made on analysis that looked right but was fundamentally flawed.

## Follow the money. AI's \$100 billion circular economy.

This is the part of the argument that almost nobody is having and it might be the most important one. Shumer frames AI disruption as an economic inevitability: the market wiped out \$1 trillion in software value in a week he says, and the implication is clear. The money has spoken, AI is coming for everything. But let's actually follow the money, because when you do something uncomfortable emerges.

Microsoft invests \$13 billion in OpenAI. Where does that money go? OpenAI spends it on Azure compute, Microsoft's own cloud platform. Microsoft reports the spending as Azure revenue growth, AI revenue numbers look incredible, investors cheer, stock goes up. Rinse, repeat. Nvidia sells over \$100 billion in GPU chips to whom? Microsoft, Google, Meta, Amazon. Those companies build AI infrastructure, they sell AI services to each other, and they report "AI revenue." But peel back the layers and an enormous portion of that revenue is just tech companies buying from tech companies and calling it growth.

This is the economic structure of the AI boom. I give you \$100, you give me \$100, and we both report \$100 in profit. Everyone's top line is growing, everyone's AI metrics are up and to the right, but where is the end customer? The real business? The real consumer paying real money for real value that wouldn't exist without AI? A law firm paying \$20 a month for ChatGPT isn't financing \$100 billion data centers. A startup saving money on junior developers isn't justifying the trillion dollar valuations. The math doesn't add up unless you believe the circular spending will eventually be justified by real world productivity gains that haven't materialized at scale yet.

We've seen this movie before, it was called the dot com bubble. Companies were buying ads from each other, reporting revenue from each other, and valuations kept climbing until someone finally asked "Wait. Who's the actual customer?" When the answer turned out to be "mostly each other" the whole thing collapsed. I'm not predicting an AI crash because the technology is real and it does create genuine value. But the economic narrative around AI, the one that makes Shumer's disruption timeline feel inevitable, is inflated by circular spending that masks how much real world adoption is actually happening.

## The four arguments that sound good until you think about them

I know what the AI optimists will say because I've heard these arguments and debated them. Let me address why they don't hold up.

**"Good enough beats perfect, companies will adopt AI anyway because it's cheaper."**

This sounds reasonable until you realize that "good enough" is actually getting worse not better. Before AI, humans had a quality floor because they took pride in their work, they iterated until things felt right. Now AI has induced a laziness in the loop. People accept the first output, they stop iterating, they stop thinking critically about whether the result actually works. The quality bar isn't rising with AI adoption, it's collapsing because the human in the loop has mentally checked out.

**"One engineer plus AI replaces five engineers, jobs still disappear."**

This misunderstands how human ambition works. When one engineer becomes 5x more productive companies don't fire four engineers and call it a day, they say "great now we want 5x the output." Human appetite for more is infinite. We never look at what we have and say "that's enough," we always want the next feature, the next product, the next market. More productivity creates more demand which creates more work which requires more people. This isn't theory, it's called Jevons Paradox and it's played out in every previous technological revolution.

**"Every technology revolution had valid skeptics, the internet had the same problems."**

Sure, but the dot com skeptics never told people their careers were permanently over. They said "these valuations are insane" and "most of these companies will fail," and they were right. The internet still transformed the world. My argument isn't that AI won't matter, it's that Shumer is telling people their entire professional existence is obsolete, and that's a fundamentally different and far more reckless claim.

**"The circular economy argument applies to every infrastructure buildout."**

There's a critical difference. When railroads were built the investment produced something tangible: steel tracks connecting real cities enabling real commerce. When the electrical grid was built it powered real factories producing real goods. With AI you spend \$3,000 on API tokens, wait four hours, and get a half bugged application that still needs a human to fix. What's the tangible output? Where's the steel? Where's the electricity powering a factory floor?

## What you should actually do

Shumer's practical advice isn't bad. Learn the tools, be curious, don't ignore this. I agree with all of that. But let me add some things he left out.

**Use AI but learn what it's doing not just what it produces.** Don't just marvel at the output, understand the process. When AI writes code read it, when it makes a recommendation ask why, when it produces analysis verify the numbers. The person who can use AI AND evaluate its work is infinitely more valuable than the person who can only prompt.

**Double down on the skills AI is worst at.** Deep architectural thinking, security awareness, systems design, understanding why things are built the way they are not just how to build them. These are the skills that will command premiums as AI generated code floods the market.

**Be skeptical of anyone who tells you AI replaces expertise.** It doesn't, it replaces labor. The difference is everything. Expertise is knowing which labor matters, which shortcuts are dangerous, and which "optimizations" will blow up in six months. And be especially skeptical when AI labs themselves start confusing their model's fluency with depth, like when [Anthropic published a 243-page system card for Claude Mythos that's half safety science and half love letter](/posts/anthropic-claude-mythos-system-card-love-letter).

**If you're early in your career go deeper not broader.** The people who will thrive are the ones with genuine deep expertise that lets them serve as the human in the loop for AI systems. Generalists who skim the surface and let AI do the rest are commoditized overnight. Specialists who understand systems at a fundamental level become more valuable with every AI deployment.

## The bottom line

Something big is happening in AI, and on that Shumer and I agree. But the "something big" isn't what he thinks. The real story isn't "AI replaces everyone," it's "AI creates an enormous amount of unverified, unaudited, poorly architected code and decisions, and the companies that survive will be the ones that kept humans who can tell the difference."

The danger isn't that you'll be replaced by AI. The danger is that you'll be replaced by someone using AI who doesn't understand what they're doing, and then you'll be hired back at twice the rate to clean up the mess. Shumer compares this moment to February 2020 and Covid. I'd offer a different comparison: it's like February 2008. Everyone is building on foundations they don't understand, leveraging instruments they can't evaluate, and the people raising alarms are being told they're missing the opportunity of a lifetime. We know how that story ended.

The smart money isn't on replacing humans, it's on the humans who understand what AI is actually doing under the hood. That's the real "something big" that most people will be blindsided by.


A rebuttal to AI replacement hype from someone who builds production AI systems at scale, explaining why human judgment, architectural thinking, and oversight matter more than ever, and why trusting AI to replace you is the actual danger.

Ai