
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. The country split into two camps. Tsarists on one side, socialists on the other. And 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, you might get 6 heads. Flip it 10,000 times, 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. 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. They follow 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: those decisions must be independent. Therefore, humans have free will. QED.

Yeah.

On the other side of this argument was Andrey Markov. Also known as "Andrey the Furious." Atheist. 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.

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. 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. Vowel-vowel pairs were 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. 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. 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), one for "consonant" (C). These are **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. He knew vowel-vowel pairs occur 6% of the time. So:

```
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. 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. There are three paths forward. The probability that you take each path depends on which crossroads you're at. 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. 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. 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. He wrote: "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. Nearly died. 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. That's about 8 × 10⁶⁷ possible games. You can't check them all. 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. 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. 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. At each step:
- It can **scatter** off an atom and keep traveling (arrow back to itself)
- It can **escape** or get absorbed (chain ends)
- 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. Only the present matters.

Run this chain hundreds of times. Track how many neutrons are produced per initial neutron. That gives you **k**, the multiplication factor.

If k < 1: reaction dies. If k = 1: sustained but stable. If k > 1: exponential growth. Bomb.

<MonteCarloNeutron />

Slide the uranium mass up. 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. Simple keyword matching.

The problem? It was trivially easy to game. Hide keywords in white text on a white background. Repeat them a thousand times. 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. 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. They follow links randomly. Over thousands of steps, the fraction of time spent on each page converges to a stable distribution. 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**. Every state is reachable from every other state. Convergence is guaranteed.

<PageRankDemo />

Try both modes. Power iteration computes the exact mathematical scores. 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. 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. 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? 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. "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. 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.

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. 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. 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

Here's what still gets me about all of this.

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. 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. That's not 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. 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. 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 → ...

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. 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.

Not just gotcha. Not just 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. 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.

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.

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. 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.

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, not toy projects. 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. Nobody talks about the six months they spent shipping AI generated code that they had to rip out and rewrite.

So here's what I learned.

## 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. Features shipping. It felt amazing.

Then I looked at what was actually happening over a month. 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. Research the codebase, create a plan, then implement it. Sounds clean right?

The planning step had this massive prompt with like 85 instructions. 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. 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." 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. 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. 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? The whole context window is full of tool definitions the model doesn't need for this task. Too many files loaded? The actual instructions get drowned out.

Less context, better results. Counterintuitive but true.

<ContextWindowFill />

Drag that past 64k tokens. 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." I'd even have teammates PR the plans and code review them together.

But here's the thing. A 1000 line plan produces about 1000 lines of code. And the code doesn't always match the plan. 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. 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." 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. 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. 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. You catch bugs in 300 line increments instead of debugging 1200 lines at once.

<HorizontalVsVertical />

Toggle between horizontal and vertical. Same feature, same code. But vertical gives you three checkpoints where you can test and fix before moving on. Horizontal gives you zero.

I now explicitly tell the agent to build vertically. 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. One giant planning prompt with 85 instructions trying to do everything.

I broke it into seven focused stages. Each one has under 40 instructions. Each one has a clear input and a clear output.

Questions first. Just generate the right research questions from the ticket. Don't think about implementation.

Research next. Fresh context window. Doesn't know what we're building. Just finds facts about how the codebase works. Objective. No opinions.

Then a design discussion. This is the big one. Instead of a 1000 line plan the agent brain dumps a 200 line design doc. 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. 200 lines is actually reviewable. 1000 is not.

Then a structure outline. High level phases, not 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. I've already aligned on everything. Just spot check it.

Then implement phase by phase. Each phase is testable.

Then package into a PR.

<CrispyPipeline />

Click between the before and after. 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. Everyone obsesses over "AI writes code faster." And 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. 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." No surprises. No rework.

<LeverageCalculator />

Drag the complexity slider. 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. 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

Here's the honest breakdown.

I use AI for everything. Research, planning, coding, testing. 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. 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. That's actually how you win with AI coding agents.


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. 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 here's something the hype merchants won't tell you. 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. I brought my counter arguments from real engineering experience. 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." They're systemic. And 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.

But here's what he's not telling you. The apps AI builds in four hours are the easy ones. 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 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. 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. 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. 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? 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

Here's something I've noticed that I haven't seen anyone in the AI discourse address. 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. 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. They don't know what they don't know.

And 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. 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. 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. 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. It 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.

And here's the thing. The people following AI's architectural advice are the non technical founders Shumer is empowering. They don't know there's a simpler option. 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. Making decisions. And 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." Sounds reasonable. But think about what actually happens:

1. AI writes code to optimize a metric (make it faster, cheaper, more efficient)
2. Security scanner catches the vulnerability and explains why it's insecure
3. The optimizing AI now knows what the scanner looks for
4. Next time it achieves the same optimization through a path the scanner doesn't flag
5. 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. 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. 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. 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. 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. 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. I've heard these arguments. I've debated them. Here's 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. 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." They were right. And 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. 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.

**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. 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

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

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

Everything I Got Wrong About AI Coding Agents

Save Yourself from 'Something Bigger Is Happening'