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


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

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


I fell into a neuroscience rabbit hole a few weeks ago, and it started with a simple question: how does a single neuron fire? I don't mean the hand-wavy textbook version where "electrical signals travel along nerves." I mean the actual mechanism, what physically happens, what equations describe it. And I found the answer in a pair of equations from 1952 that I genuinely think might be the most beautiful piece of applied mathematics I've ever encountered.

Alan Hodgkin and Andrew Huxley figured out how neurons generate electrical spikes using nothing but careful experiments on squid axons and differential equations. No electron microscopes. No x-ray crystallography. No molecular biology. Just voltage clamps, math, and an unreasonable amount of patience. And the part that still gets me is this: their equations predicted the molecular structure of ion channels decades before anyone could actually see those molecules. The math came first, and reality confirmed it later. Let me take you through the whole thing from scratch.

## a tiny bag of water

Start with the simplest possible picture of a neuron. It's a bag, a tiny bag filled with salty water, floating in a sea of slightly different salty water. The thin membrane separating inside from outside is where everything interesting happens.

Both the inside and outside are full of dissolved particles called ions: sodium, potassium, chloride, calcium. Some carry positive charge, some negative, and the crucial fact is that the composition of ions on both sides is different. The inside of the cell has more negative charge than the outside.

This charge imbalance creates a voltage across the membrane, same idea as a battery. Separated charges create electrical potential. The voltage across a resting neuron is about -65 millivolts, negative inside relative to outside. That's our state variable, that's what we're tracking, and everything that follows is about understanding how this voltage changes.

## stored energy that wants to escape

Think of the charge imbalance as water held behind a dam. The water wants to flow downhill, but the dam holds it back. As long as the dam is intact, the energy stays stored as potential energy, and the higher the water level, the more energy is stored. This is capacitance.

The neuron's membrane is thin, maybe 5 nanometers thick, and it separates two conducting solutions. That's basically a capacitor. The fundamental equation of a capacitor is:

```
Q = C × V
```

Charge equals capacitance times voltage. Simple enough.

But we care about how things change. Taking the time derivative of both sides:

```
dQ/dt = C × dV/dt
```

The rate of change of charge equals capacitance times the rate of change of voltage. And since current is literally defined as the rate of change of charge (`I = dQ/dt`), this becomes:

```
C × dV/dt = I
```

This is the foundation. The rate of change of membrane voltage is proportional to the current flowing across the membrane.

## but the walls leak

Real membranes aren't perfect insulators, which is where it gets interesting. The membrane is studded with protein channels, molecular machines that can open and close, creating pathways for specific ions to flow through. Some let sodium through. Some let potassium through. Some are always open. Some only open under certain conditions.

When ions flow through these channels, they create electrical current. That current changes the charge distribution, which changes the voltage. So we update our equation:

```
C × dV/dt = -I_Na - I_K - I_leak + I_external
```

The voltage changes based on the sum of all ionic currents flowing through the membrane, plus any external current we inject. The negative signs are there because when positive ions flow into the cell, they increase the voltage (make it less negative), and we define the currents in a way that accounts for this. This is the master equation, and everything else in the Hodgkin-Huxley model is about figuring out what those ionic currents actually are.

## two forces, one ion

What makes ions move through channels? Two forces, and they often fight each other.

**Diffusion.** Particles naturally spread from high concentration to low concentration through random motion. If there are more potassium ions inside the cell than outside, they'll tend to drift outward through any available channel, same reason a drop of food coloring spreads through water.

**Electrical attraction.** Ions carry charge, so positive ions are pulled toward negative charge and repelled by positive charge. Since the inside of the cell is more negative, positive ions are electrically attracted inward.

For potassium, these two forces oppose each other. Diffusion pushes potassium out (lots of it inside, less outside), while electrical force pulls it in (inside is negative, potassium is positive). There's a special voltage where these two forces exactly cancel out, called the equilibrium potential. For potassium, it's about -77 mV. For sodium, it's about +50 mV.

When the membrane voltage is different from the equilibrium potential, there's a net driving force. The further away from equilibrium, the stronger the force. Play with this:

<IonDrivingForce />

The current for each ion follows Ohm's law:

```
I_ion = g_ion × (V - E_ion)
```

Where `V - E_ion` is the driving force and `g_ion` is the conductance (how many channels are open and how easily ions flow through them). Simple, elegant. But that `g` is where the real magic lives.

## the spike

Before diving into the math of conductance, let's get the big picture of what happens when a neuron fires. An action potential takes about 2-3 milliseconds, and in that tiny window:

1. Something pushes the membrane voltage slightly above threshold (around -55 mV)
2. Sodium channels start opening. Positive sodium ions rush into the cell
3. This makes the voltage even more positive, which opens even more sodium channels
4. The voltage rockets up to about +30 mV in less than a millisecond
5. Sodium channels inactivate. They close and stay closed briefly
6. Potassium channels (which are slower to open) are now fully open
7. Positive potassium ions flow out of the cell
8. The voltage drops back down, undershooting to about -80 mV
9. Potassium channels close. Everything resets

Step 3 is the critical one because it's positive feedback. More depolarization opens more sodium channels, which causes more depolarization. This is what makes the spike all-or-nothing: below threshold, nothing happens, but above threshold, the positive feedback loop takes over and the full spike fires regardless of how strong the stimulus was. But the question that bugged me is this: nobody is orchestrating any of this. There's no timer saying "ok sodium channels, you open now, and potassium channels, wait 0.5 milliseconds." There's no conductor, so how does it work?

## the orchestra with no conductor

The answer is voltage-dependent conductance. Remember that `g` in Ohm's law? For some channels, it's not a constant, because it depends on the current membrane voltage.

```
g_ion(V) = g_max × P(V)
```

The conductance at any moment equals the maximum possible conductance (if every channel were open) times P, the fraction of channels that are actually open. `g_max` is fixed because it's determined by how many channels the cell has, and it doesn't change with time. P is the interesting part. It's a number between 0 and 1 representing what fraction of channels are open, and it depends on voltage.

Each ion channel is a protein machine that changes shape in response to the electric field across the membrane. Inside each channel are charged regions, think of them as gates, that can flip between two positions: permissive (open) and non-permissive (closed). A channel only conducts when ALL its gates are in the permissive position, like a lock where multiple pins all need to be aligned for the door to open.

Let's call `n` the probability that a single gate is in its permissive position. How does it change over time?

```
dn/dt = α(V) × (1 - n) - β(V) × n
```

The first term represents gates that are currently non-permissive (there are `1 - n` of them) switching to permissive at rate `α`. The second term represents gates that are currently permissive (there are `n` of them) switching to non-permissive at rate `β`. Both `α` and `β` depend on voltage, which is where the voltage sensitivity enters. When the membrane depolarizes, `α` increases for sodium activation gates, making them more likely to open. It's all encoded in the rates.

Hodgkin and Huxley figured out the exact mathematical forms of `α(V)` and `β(V)` by fitting curves to their experimental data. These are not pretty closed-form expressions derived from first principles but rather empirical formulas, exponentials and linear terms mashed together to fit the squid axon data. But they work.

## gates inside gates

Now the really clever part. For potassium channels, Hodgkin and Huxley found that the conductance was proportional to `n⁴`, not `n` or `n²` but the fourth power.

```
g_K = g_K_max × n⁴
```

If n is the probability of a single gate being permissive, and the channel has four independent gates, then by probability theory the chance that ALL four gates are permissive simultaneously is n × n × n × n = n⁴. This is pure math. They didn't know the molecular structure; they just fit curves to current traces from voltage clamp experiments and found that the fourth power worked best.

Decades later, x-ray crystallography revealed that potassium channels have exactly four identical subunits that all need to be in the correct conformation for the channel to conduct. The math predicted the molecule. I still can't get over this.

For sodium, the story is slightly different. The conductance follows:

```
g_Na = g_Na_max × m³ × h
```

Two types of gates: three `m` gates (activation) and one `h` gate (inactivation). The m gates open fast when voltage rises, letting sodium rush in. The h gate closes slowly when voltage stays high, shutting the channel down.

This is the choreography, and no conductor is needed. The m gates respond fast to voltage. The h gate responds slowly. The n gates for potassium respond at an intermediate speed. The different time constants create the precise sequence of events that produces the action potential, all from voltage-dependent rate constants, all self-organized.

## see the whole system

Here is a live numerical simulation of the full Hodgkin-Huxley equations. This is running a 4th-order Runge-Kutta integrator on all four coupled differential equations in your browser right now. Click stimulate and watch what happens, then try a sub-threshold current and notice that nothing fires. That's the all-or-nothing threshold emerging naturally from the equations.

<HodgkinHuxleySimulator />

Watch the gating variables carefully during a spike. Red (m) shoots up first, because sodium activation gates respond fastest to depolarization, and this is what drives the voltage upward. Yellow (h) drops a moment later, inactivating sodium channels. Blue (n) rises slowly, opening potassium channels that bring the voltage back down.

Nobody told these gates when to open and close. The voltage changed, the rate constants changed, and the gates followed. The dance emerges from the math itself.

## they predicted the molecule

I keep coming back to this because it's genuinely one of the most satisfying results in the history of biology. In 1952, Hodgkin and Huxley published their model and said potassium conductance goes as the fourth power of a gating variable. They didn't know why; it just fit the data best.

In 2003, Roderick MacKinnon won the Nobel Prize for determining the crystal structure of potassium channels. Each channel has four identical subunits arranged symmetrically around a central pore. Four subunits. Four gates. n⁴. Fifty-one years between prediction and confirmation, and the math was right the whole time.

## what this leaves out

Everything I've described treats the neuron as a single point: one voltage, one set of channels. That's called a "point neuron" or "space-clamp" model.

Real neurons have dendrites that receive signals, an axon that transmits them, and complex branching geometry. The voltage can be different at different locations along the cell. To handle this, you chop the neuron into small segments, apply the HH equations to each segment, and add terms describing how current flows between neighbors.

The result is a cable equation, a system of coupled PDEs instead of coupled ODEs. The math gets heavier but the core insight is identical: ions flowing through voltage-dependent channels, just with the added question of how those currents spread through the neuron's elaborate shape.

The HH model also uses four coupled differential equations: one for voltage, three for gating variables. You can't easily visualize four-dimensional dynamics, so in computational neuroscience, people often simplify to two dimensions (voltage plus one combined gating variable) to see the system's behavior in a phase plane. That reduction reveals beautiful geometric structure like limit cycles, bifurcations, and excitability transitions. But that's a story for another post.

## the math for the nerds who stayed

The full system looks like this.

**The voltage equation:**

```
C_m × dV/dt = I_ext - g_Na × m³ × h × (V - E_Na)
                     - g_K  × n⁴ × (V - E_K)
                     - g_L  × (V - E_L)
```

**The gating variable equations:**

```
dm/dt = α_m(V) × (1 - m) - β_m(V) × m
dh/dt = α_h(V) × (1 - h) - β_h(V) × h
dn/dt = α_n(V) × (1 - n) - β_n(V) × n
```

**Rate functions (voltage in mV, shifted convention with V_rest ≈ -65):**

```
α_n(V) = 0.01 × (V + 55) / (1 - exp(-(V + 55)/10))
β_n(V) = 0.125 × exp(-(V + 65)/80)

α_m(V) = 0.1 × (V + 40) / (1 - exp(-(V + 40)/10))
β_m(V) = 4.0 × exp(-(V + 65)/18)

α_h(V) = 0.07 × exp(-(V + 65)/20)
β_h(V) = 1 / (1 + exp(-(V + 35)/10))
```

**Standard parameter values (squid giant axon at 6.3°C):**

| Parameter | Value | Meaning |
|---|---|---|
| C_m | 1 µF/cm² | Membrane capacitance |
| g_Na | 120 mS/cm² | Max sodium conductance |
| g_K | 36 mS/cm² | Max potassium conductance |
| g_L | 0.3 mS/cm² | Leak conductance |
| E_Na | +50 mV | Sodium reversal potential |
| E_K | -77 mV | Potassium reversal potential |
| E_L | -54.4 mV | Leak reversal potential |
| V_rest | -65 mV | Resting membrane potential |

**Steady-state values at rest (V = -65 mV):**

```
n_∞ = α_n / (α_n + β_n) ≈ 0.318
m_∞ = α_m / (α_m + β_m) ≈ 0.053
h_∞ = α_h / (α_h + β_h) ≈ 0.596
```

**Time constants at rest:**

```
τ_n = 1 / (α_n + β_n) ≈ 5.5 ms
τ_m = 1 / (α_m + β_m) ≈ 0.24 ms
τ_h = 1 / (α_h + β_h) ≈ 8.5 ms
```

Notice the time constants. m is 20x faster than n, and 35x faster than h, which is why the spike sequence works. m responds almost instantly to depolarization, creating the fast upstroke. h responds slowly, creating the delayed inactivation. n sits in between, creating the delayed repolarization.

The whole action potential is a race between fast activation and slow inactivation. No conductor. No clock. Just differential equations with different time constants, all driven by the same voltage, all feeding back into that voltage. Four equations. One Nobel Prize. The foundations of computational neuroscience.

~ Ashish Kumar Verma


I went down a neuroscience rabbit hole and rebuilt the Hodgkin-Huxley model from scratch. Four differential equations that describe how neurons fire, predicted molecular structures decades before anyone could see them, and won a Nobel Prize. Here's how they work, with interactive simulations.

The Most Important Equation in Neuroscience Has Four Coupled Differential Equations


I was messing around in the Firefox console when I did something that should make nobody comfortable. I called `Math.random()` a few times, copied three outputs into a script, and the script told me what the next random numbers would be. Then I went back to Firefox, hit enter, and watched those numbers appear exactly as predicted, digit for digit.

This was not a magic trick. I was not editing the page. I was not intercepting anything. I was just using the fact that `Math.random()` is not random in the security sense, and if you are using `Math.random()` to generate OTPs, this should be your sign to stop.

## the moment this stopped feeling random

The whole demo looked stupidly simple. I grabbed three `Math.random()` outputs from Firefox, fed them into a small program using Z3, and that program recovered the internal state of Firefox's pseudorandom number generator and started printing the numbers that would come next. I ran `Math.random()` again in Firefox. It matched. Again. And again.

That is the part people miss about `Math.random()`. If you just stare at a decimal like `0.5466844185052394`, it *looks* random enough because human eyes are very easy to fool here. We see noise and assume unpredictability. But computers do not care about vibes. If the generator is deterministic and leaks enough information through its outputs, an attacker can work backwards, recover state, and predict future values, which is exactly the kind of property you do **not** want anywhere near OTP generation.

So I wanted the post to let people feel that punch in the stomach directly. Run the lab below. It literally uses JavaScript `eval()` with a sandboxed Firefox-style `Math.random()`, and you can leak a few outputs, then watch the panel on the right predict what comes next.

<MathRandomEvalLab />

## why this is bad even before the Firefox trick

A six digit OTP already lives in a tiny space. It is just a number from `000000` to `999999`, which is only a million possibilities. Not a lot.

And the moment you see code like this, alarms should start going off.

```js
function generateOtp() {
  return Math.floor(100000 + Math.random() * 900000).toString();
}
```

This looks normal. It is still the wrong tool. An OTP is not a UI flourish, not a dice roll in a game, not a particle effect. It is a security boundary. If someone can predict it, bias it, replay it, or reduce the search space enough to make guessing practical, that becomes an account takeover problem, not a JavaScript trivia problem.

So before we even get into Firefox internals, there are already two issues here:

1. OTPs have limited entropy by design.
2. `Math.random()` is not meant to protect secrets.

<OtpEntropyExplorer />

## what math.random actually is

`Math.random()` is pseudorandom. That means there is some hidden internal state, some deterministic update rule, and a stream of outputs that only *look* random from the outside. The exact implementation depends on the JavaScript engine, so Firefox, Chrome, and Node do not all have to use the same thing.

In the Firefox case I was looking at, the generator was based on **xorshift128+**. Which sounds fancy but the important part is very simple: it keeps hidden internal state, every call mutates that state in a predictable way, and then JavaScript shows you part of the result as the floating point number you see in the console. So `Math.random()` is not some mystical randomness faucet from the heavens. It is a machine. And machines can be modeled.

## how three outputs become enough

This is the part that broke my brain a little. Firefox's generator had 128 bits of internal state. Each `Math.random()` call leaked about 53 bits of useful information because the returned floating point number is built from a 53 bit mantissa. So after three observed outputs, you are roughly looking at this: first call gives you 53 bits, second call gives you 53 more, third call gives you 53 more. That is 159 bits of visible information. The internal state is 128 bits.

Now obviously this is the intuition, not a formal proof. Some bits are discarded, the constraints are messy, and the exact transition rules matter. But this is why the whole thing becomes solvable with enough samples. You are no longer staring at random looking decimals. You are collecting equations.

<MathRandomRecovery />

Once the solver finds the internal state that satisfies those observed outputs, the rest is boring. You just run the same generator forward. That is why the script could tell me what Firefox would return next, and Firefox, very politely, confirmed it.

## why this should scare anyone generating OTPs in JavaScript

Because a lot of people still treat `Math.random()` like it is "good enough" randomness. It is not. Not for OTPs, password reset tokens, magic links, invite codes, session secrets, CSRF tokens, or anything where predictability becomes compromise.

Also, one more thing. If you are generating the OTP in the browser, the user already controls that environment. They can inspect your code, patch functions, automate requests, and generally behave like a menace. The OTP should usually be generated on the server using a cryptographically secure source of randomness, stored safely, expired aggressively, and verified server side. So even if you replace `Math.random()` with Web Crypto in the browser, that still does not magically make client side OTP generation the right architecture.

## what to use instead

If I am generating an OTP in Node.js, I would use `crypto.randomInt()`.

```js
import { randomInt } from "node:crypto";

function generateOtp() {
  return randomInt(0, 1_000_000).toString().padStart(6, "0");
}
```

If I need secure randomness in the browser, I would use Web Crypto.

```js
function generateOtp() {
  const max = 1_000_000;
  const range = 0x1_0000_0000;
  const limit = range - (range % max);
  const buf = new Uint32Array(1);

  do {
    crypto.getRandomValues(buf);
  } while (buf[0] >= limit);

  return (buf[0] % max).toString().padStart(6, "0");
}
```

That rejection loop is there to avoid modulo bias, which is exactly the kind of sentence you only get to say when you are using the correct primitive in the first place.

## the deep technical dive

<Notice type="info">
This section is optional. The main argument is already done. If you skip everything below, the takeaway stays the same. Do not use <code>Math.random()</code> for OTPs.
</Notice>

The Firefox demo used a generator from the xorshift family, specifically xorshift128+. At a high level, the hidden state is just two 64 bit values. You can think of it like this:

```txt
state = (s0, s1)
s0 = 64 bits
s1 = 64 bits

Total hidden state = 128 bits
```

On each step, the generator mutates that pair with XOR and shift operations. In rough pseudocode, the update looks like this:

```txt
newS0 = s1

t = s0 XOR (s0 << 23)
t = t XOR (t >> 17)
t = t XOR s1
t = t XOR (s1 >> 26)

newS1 = t
x = newS0 + newS1
```

JavaScript does not hand you all of `x` directly. It exposes a floating point output derived from part of it, which is why you see about 53 useful bits per call. So the attack intuition becomes:

```txt
3 outputs × 53 visible bits each ≈ 159 visible bits
hidden internal state = 128 bits
```

Again, that does **not** mean you literally subtract one from the other and call it solved. The constraints are over bit vectors. There are discarded bits. The transition rules have to be modeled correctly. But it does explain why a solver can recover the hidden state once enough outputs are observed.

The mental model I like is basic school algebra, just more cursed. If I give you:

```txt
x + y = 10
x - y = 2
```

you can recover both unknowns. One equation is not enough. Two starts pinning things down. Here, each observed `Math.random()` output gives you another pile of constraints on the unknown state bits, and Z3 just does the ugly part for you.

A stripped down sketch of the recovery idea looks like this:

```js
// observed outputs from Firefox
const outputs = [r1, r2, r3];

// unknown internal state
const s0 = BitVec(64);
const s1 = BitVec(64);

// symbolically run the same PRNG transition
// constrain each generated output to match r1, r2, r3
// ask Z3 for any state that satisfies all constraints

const recovered = solve(outputs, s0, s1);
const next = forward(recovered);
```

That is the whole trick. Not magic. Just a deterministic machine being treated like a deterministic machine.

## one subtle thing people get wrong

When I tried the same Firefox specific recovery logic against Node, it failed. That does **not** mean Node's `Math.random()` is suddenly safe for OTPs. It just means the exact Firefox attack was built around the exact Firefox generator, so different engine, different implementation, same security lesson. If something was not designed to be cryptographically secure, do not promote it into a security primitive just because it is convenient.

## my honest take

`Math.random()` is not evil. It is just being asked to do a job it was never hired for. Use it for quick simulations, for animations, for random colors in a toy app. Do not use it for OTPs.

The Firefox demo is fun because it feels like a party trick. But the real lesson is boring and important. Random looking is not the same as secure, and in security, that difference is the whole game. 🫡


I took three Math.random() outputs from Firefox, recovered the internal PRNG state using Z3, and predicted the next values exactly. This is why OTPs must never use Math.random(). It is not random in any security sense.

I Predicted Firefox's Math.random(). Don't Use It for OTPs.


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.


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.


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


Nothing excites you the way it used to.

You used to get excited about books. You had hobbies that pulled you in. Conversations with friends could stretch for hours because you actually wanted to know what they thought about things. Five years ago, you were more interesting. You went deep on topics. You cared about stuff.

Now? You scroll through hours of content every week, but if someone at dinner asks what you've been up to, your mind goes blank. You've consumed thousands of videos, articles, threads, clips. Not a single one worth mentioning. You sit down to read something important and within 90 seconds your hand is reaching for your phone. You assume this is just who you are now. Lazy. Unmotivated. Boring.

But here's what's actually happening: there's a neurological shift in your brain chemistry that has stolen your curiosity. Not metaphorically. Literally. And understanding how it works is the first step to fixing it.

## Your curiosity isn't gone. It's been redirected.

Think about it. Every time you binge Netflix, doom-scroll TikTok, or fall into a YouTube rabbit hole at 2am, your brain's curiosity system is doing exactly what it's designed to do: hunting for the next interesting piece of information.

That's the same dopamine system that drives scientists, artists, and every genuinely fascinating person you've ever met. The difference isn't that they have more curiosity than you. It's that their curiosity has been aimed at things that compound, while yours has been captured by things that drain.

Scientists call curiosity a "mental hunger." Your brain constantly scans your environment, and when it detects a gap between what it knows and what it wants to know, it gets hungry to close that gap. That's why you physically cannot scroll past a shocking headline. Your brain treats information as essential for survival. It wants to know.

So if your brain is this hungry for information, why does it only want junk? Why does it crave stupid videos but recoil from books? Why can it sustain four hours on Reddit but not twenty minutes with a skill you actually want to learn?

The answer comes down to one chemical.

## The dopamine baseline problem

Dopamine is the neurotransmitter that makes you do things. Not enjoy things, do things. It generates the motivational pull that gets you to stand up, pursue something, and see it through. Without dopamine, you'd have no desire to act on anything at all.

When you have a healthy dopamine baseline, the world feels full of things worth pursuing. Questions feel worth exploring. Books feel worth reading. Conversations feel interesting. Not because the books magically became better, but because you have enough motivational fuel to engage with them.

Here's what happens when you scroll.

Every time your brain detects something novel, a new notification, a new video, a surprising headline, dopamine spikes. It gives you that little push of motivation to click, to find out, to close the information gap. Then it drops. Your brain actually compensates by pushing dopamine slightly below baseline before returning to normal. Spike, dip, recover. Spike, dip, recover.

When you scroll for an hour, you're hitting your dopamine system hundreds of times without letting it recover. Day after day. Week after week. Your brain detects that dopamine is chronically elevated and thinks something is wrong. So it adapts. It reduces the number of dopamine receptors.

This means even when dopamine is present in your system, less of it gets registered. Your effective baseline drops. What used to feel like neutral now feels flat. What used to feel mildly interesting now feels boring.

Normal activities, reading a book, having a conversation, learning something new, no longer generate enough motivational pull to feel worth doing. They can't spike your dopamine high enough from your new, lower baseline. Only the algorithmically-engineered feeds, designed for maximum stimulation, can still register as interesting.

Which is why you keep scrolling even though it leaves you empty. Not because you lack willpower. Because your brain literally doesn't register anything else as worth pursuing.

This is easier to feel than to read about. The thing below is a loose simulation of that exact loop. Hit scroll a few times and watch the trace. Then flip on auto-scroll at 10 spikes per second and let it run for 15 seconds. The baseline drops, the receptor density drops, and suddenly the same "scroll" action barely moves the needle. Then hit rest.

<DopamineBaseline />

It's not a literal model of your brain. But the shape of the curve, spike up, dip below, recover, and the way the baseline quietly erodes with repetition, that part is real. You've been running this loop on yourself for years.

## The symptoms nobody recognizes

People with dopamine overload rarely realize they have it. They assume it's their personality.

**You think you can't focus.** You sit down to work on something and within 90 seconds you're reaching for your phone. Maybe you're even reading this article because you couldn't focus on what you were supposed to be doing.

**You think you have nothing interesting to say.** You scroll through hours of content weekly, but ask yourself what's been on your mind lately and the answer is nothing. You've consumed without processing. Information went in without becoming thought.

**You think you stopped growing.** You remember being more curious, more engaged, more interesting. Something shifted and you don't know when or why. You chalked it up to getting older, getting busier, getting boring.

None of these are personality traits. They're symptoms. And symptoms are fixable.

## How to actually reset your dopamine baseline

The neuroscience here is surprisingly clear, and the fix is simpler than most productivity advice.

### Step one: the dopamine fast

Your brain needs time to recalibrate. Anywhere from one day to seven days of reduced stimulation will help reset your dopamine system. You're not going full monk mode. You're eliminating specifically the high-stimulation behaviors that are spiking your dopamine hundreds of times per hour.

The target list: algorithmic feeds (TikTok, Instagram Reels, Twitter, Reddit), binge-watching, video games designed for compulsive play. Basically anything where an algorithm is selecting what you see next to maximize engagement.

You can still use the internet. You can still read articles. You can still watch a specific video you sought out. The distinction is between active seeking and passive consumption. Active seeking: you decide what you want to know, you go find it, you're done. Passive consumption: an algorithm feeds you an endless stream optimized to keep you hooked.

During the fast, create friction between you and those behaviors. Put your phone in another room while you work. Turn off notifications. Delete apps if you need to. I've developed a habit where as soon as social media starts feeling overstimulating, I delete the apps from my phone for a few weeks. I keep Instagram accessible on my computer's browser so I can reply to friends' messages, but the friction of using Instagram on desktop kills any urge to mindlessly scroll. That kind of structural friction does more than willpower ever could.

### Step two: move your body

If there's one thing neuroscience is unanimous on, it's that exercise is the most powerful tool for restoring your dopamine system. It increases dopamine production. It increases receptor sensitivity. It gives you more dopamine to work with.

People who exercise regularly have more natural motivation and more curiosity. Not because they're inherently more disciplined, but because their neurochemistry supports engagement with the world. Even thirty minutes of walking per day is a meaningful intervention.

### Step three: go deep on something tonight

Tonight, instead of opening a feed, pick one thing that caught your attention recently and spend twenty minutes actually exploring it.

Maybe you're curious about psychology, economics, history, a craft, a person, a place. Go read a full article about it. Watch a long-form video. Ask an AI questions about it and keep asking follow-up questions. Go down a rabbit hole, but a chosen one. A directed one. See how it actually feels to be interested in something again.

You're not doing this to "learn something useful." You're doing this to remember what genuine curiosity feels like when your brain has enough dopamine to sustain it.

## The real point

You do not lack curiosity. You lack the dopamine to act on it.

The books aren't boring. The conversations aren't dull. The world didn't get less interesting. Your brain just stopped generating enough motivational pull to make those things feel worth pursuing. Every ounce of curiosity you have is intact. It's just been captured by systems designed to exploit it.

Reset your dopamine. Move your body. Go deep instead of wide.

Being genuinely interested in things, actually curious about the world and the people in it, is the most attractive, most creative, most life-changing trait you can cultivate. Curious people are interesting people. And you already have the hardware for it.

You just need to take it back.


If nothing feels exciting the way it used to, it isn't your personality. Your dopamine baseline collapsed. Here's the neuroscience and the fix.

Nothing excites me anymore. The neuroscience of why, and how to fix it.

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.

Hmm... So let's start with what are the toolset we will be using to accomplish this task... ! So we are going to be using canvas, That's it and javascript for the interaction part... ! If you just want the code you can just scroll down to find all the code at once...



## 1) First we will be creating a blank template of our web page and place the canvas tag
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2a8o7s9jjjzrlb54nxh4.png)

Then we will access the canvas in our javascript using getElementById and set the height and width of our canvas to window height and width divided by 2.


 ![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u7sia1x00ve0dpuv7und.png)

Which will be looking something like this.. For visibility purposes I have set background color of body to black

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2oc0a28z1ga5d1iek4bm.png)
 

Next is to handle mouse events

## 2) Handling Mouse Events

In javascript we have the access to the mouse events such as mouseup, mousedown, mousemove etc within document or we can apply it on different set of elements individually ! So I am going to apply this to our canvas and we do so by addEventListener to a specific element which accepts to parameters.
```
element.addEventListener("event_name", callback function()");
```

Here the callback function will run whenever this event -> event_name get's triggered.. ! In this case it's the mouse move event

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/twb5umvn2kruemvj6psk.png)


this **e** in the function() is required to get the current position of **x** and **y** of the mouse

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1qh3x660pklogd39nxg2.png)


So now let us create two variables outside of the eventlistener and set our mouseX and mouseY to e.clientX (returns current position of X in x coords ) and e.clientY ( returns current position of mouse in Y coords ) 

**Note: In javascript there is no negative x and y position. (0, 0) in canvas means top left, top right point in the canvas**

Now let's draw a line in canvas using mousemove events. In general you would draw a line in canvas like this

```


ctx.beginPath();
ctx.moveTo(0, 0);
ctx.lineTo(300, 150);
ctx.stroke();

```

But we are going to replace the third and fourth line in two different events. 

Now we need to bring two more events the first is mousedown and mouseup. The working of these events are self explanatory.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rym3nsvwrf4bi7i7lonz.png)
 

 We also need a variable **isDrawing** to keep track whether the user is holding the mouse click.

So in the mouse down event we have,
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3jgpb2jdygjgsxdnwf1d.png)

and here we are not writing lineTo because that's going to changing every second when our mouse is moving.

So in mousemove event we have,
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i40izsxsx5gzrxykfwpl.png)
 
Now you can open up the page in your browser and see that you are drawing 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k3cwjn9yjmfndcikbiai.png)


But here comes are isDrawing variable because in this we can't control when we have to draw, so we do the following
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w1ntjwtf01i3v1b1z9qp.png)
 


First we declared a variable called isDrawing, in mousedown function we set that drawing = true and in mousemove function we are checking if isDrawing is true, if it is so then we are drawing, after we release our mouse, **mouseup** event get's triggered and we are not drawing any more ! 
 


## 3) To save the canvas as png

```
 function downloadCanvas() {
            var imageData = canvas.toDataURL("image/png");
            let anchorTag = document.createElement("a");
            document.body.appendChild(anchorTag);
            anchorTag.href = imageData;
            anchorTag.download = "imageData";
            anchorTag.click();
            document.body.removeChild(anchorTag);
}

```

This is a block of code that just creates a element and set some props and converts the canvas to a image and downloads it !, you can just memorize this because it can be used in any canvas without changing the code !

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qrsdi34f0kkfhhjvfze3.png)

Now we can just create a button to download the picture... !
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g0c0rdlzs7pkwfc98w8d.png)
 
So, *Congratulations* you have just created a web app to write signatures and download it in a png format.. ! 

## 4) Challenge Time

My challenge to you is to modify this code and add feature to sign in different colors etc. ! and comment your modified code so that everyone can see and learnn !! Thank you for reading this... !

Here is the full code !

```
<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
    <style>
        body {
            background-color: black;
        }
    </style>
</head>

<body>
    <canvas id="canvas"></canvas>

    <button onclick="downloadCanvas();">Save</button>

    <script>
        const canvas = document.getElementById("canvas");
        const ctx = canvas.getContext('2d');
        canvas.width = window.innerWidth / 2;
        canvas.height = window.innerHeight / 2;
        canvas.style.background = "white";


        let mouseX = 0;
        let mouseY = 0;


        let isDrawing = false;
        canvas.addEventListener("mousedown", function (e) {
            isDrawing = true;

            ctx.beginPath();
            mouseX = e.clientX;
            mouseY = e.clientY;
            ctx.moveTo(mouseX, mouseY)

        })

        canvas.addEventListener("mousemove", function (e) {
            if (isDrawing) {
                ctx.lineTo(e.clientX, e.clientY);
                ctx.stroke();
            }

        })

        canvas.addEventListener("mouseup", function (e) {
            isDrawing = false;
        })

        function downloadCanvas() {
            var imageData = canvas.toDataURL("image/png");
            let anchorTag = document.createElement("a");
            document.body.appendChild(anchorTag);
            anchorTag.href = imageData;
            anchorTag.download = "imageData";
            anchorTag.click();
            document.body.removeChild(anchorTag);
        }

    </script>

</body>

</html>
```

Hope you like, share it with your friends too !

 






A step-by-step JavaScript and Canvas API tutorial for building a signature drawing app that lets users draw on a canvas and export the result as a PNG.

Create a Signature Painting Drawing App using Javascript


So I was watching the Project Hail Mary movie and thought let me try to code the simulation and the fuel math from the book. Like actually write a program that calculates the relativistic fuel requirements for the Hail Mary's trip to Tau Ceti, because why not, the best way to understand the physics is to plug the numbers in and play. And that's when things got interesting. I ran the simulation and the ship just passed right by Tau Ceti. It didn't stop. I stared at the screen for a second like wait why didn't it stop?

## The setup

Quick context if you haven't read it. In Project Hail Mary, there's this alien organism called Astrophage that's eating our sun. Earth is dying. Humanity's last hope is to send a ship to Tau Ceti, which is 11.9 light years away, because that's the one star that isn't affected.

Here's what Hail Mary gives us:

| What | Value |
|---|---|
| Distance | 11.9 light years |
| Acceleration | 1.5g |
| Ship mass | 100,000 kg |
| Fuel (Astrophage) | 2,000,000 kg |
| **Mass ratio** | **20:1** |

20:1 mass ratio. The Space Shuttle was about 16:1, so this is realistic. Andy Weir clearly did his homework, and the numbers look clean.

## There are no brakes in space

That 2 million kg of Astrophage gets you to Tau Ceti at 99.5% the speed of light, which is insane. That's fast. But you blow past it. No stopping. You just zoom past the entire Tau Ceti system at almost light speed and keep going forever. That's not a mission, that's a flyby.

Think of it like this. You're driving on a highway at 200 km/h and your exit is coming up, but there are no brakes. No exit ramp. Nothing. You just keep going. Great speed, wrong destination.

Except in space it's way worse because there's literally no friction. Nothing slows you down, ever. Once you're going 99.5% c you're going 99.5% c until the end of time. So how do you actually stop?

## You flip the entire ship

This is the part that broke me. In space the only way to slow down is to turn your entire ship around 180 degrees and fire the same engines in the opposite direction. Same fuel, same engine, just pointed backwards now. So you accelerate for the first half of the trip, then at the midpoint you flip the ship, and you burn for the second half to slow down.

Now most people think, ok so you need double the fuel right? No. You need to square the mass ratio. Why? Because the fuel you need to slow down is extra weight during the acceleration phase, so you need more fuel to accelerate that fuel, and then more fuel to accelerate that fuel. It compounds. It's fuel for fuel for fuel all the way down.

I made a quick Manim explainer for this exact moment because this is one of those ideas that clicks way faster when you see the mission profile move.

<Video
  title="Why Hail Mary can accelerate but not stop"
  src="posts/hail-mary-stop-burn-gap.mp4"
  width={780}
  poster="/images/posts/hail-mary-stop-burn-gap-poster.png"
/>

So instead of 20:1 you need:

> **20² = 416:1**

Not 2 million kg. About **42 million kg** of Astrophage. That's a lot more than what the book says. Play with this:

<MassRatioExplainer />

## Ok but how does the crew survive a 12 light year trip?

Before I get to the fix let me explain something that still blows my mind. Time dilation. This isn't sci-fi, this is real measured confirmed physics.

Imagine the simplest clock possible. Two mirrors facing each other with a photon bouncing between them. Every bounce is one tick. If the clock is sitting still the photon goes straight up and down, simple. But if that clock is moving, the photon has to travel a diagonal path because the mirrors moved sideways while the photon was traveling. The path is longer.

The photon still moves at exactly c, not c plus the ship's speed, just c. Every single experiment ever done confirms this. Einstein's second postulate. Same speed, longer path, takes more time. The moving clock literally ticks slower. Drag the slider and see it yourself:

<TimeDilationViz />

At 99.5% c, for every 10 years on Earth only about 1 year passes on the ship. That's how a crew can survive an 11.9 light year trip in under 4 years, because time itself slows down for them.

But there's another thing happening that's even wilder. It's not just time that changes, space itself contracts. From the ship's perspective the 11.9 light year distance to Tau Ceti physically shrinks. At 99.5% c, the ship only "sees" about 1.19 light years of distance. The universe literally compresses in your direction of travel. Tau Ceti gets closer, not metaphorically, physically. Drag the slider and watch the planets come together:

<DistanceContraction />

This is why the crew doesn't experience 12 years of travel. From their frame of reference they're crossing a much shorter distance. Time dilation and length contraction are two sides of the same coin, just Einstein's spacetime bending around you.

## 99.5% is basically the speed of light right? Just one more push?

This is what I thought too. We're so close, half a percent away, just push a little harder? Nope. This is one of the most beautiful traps in physics. Look at what each additional "9" costs you:

<GammaCurve />

Hover over that curve and watch it go vertical. Going from 99.99% to 99.999% costs roughly 3x the total energy of everything it took to reach 99.99% in the first place. Each nine costs 3x more than all previous nines combined.

The speed of light isn't a wall you crash into. It's more like a horizon. The closer you get the further it moves, and you'd need literally infinite energy to close that last gap. That's not a limitation of our rockets or our technology, that's the actual geometry of spacetime.

But because of time dilation, if you just keep accelerating at 1.5g, you can reach Betelgeuse (500 ly) in 8.5 crew years, Andromeda galaxy (2.5 million ly) in 20 crew years, and the edge of the observable universe in 32 crew years. You can reach anywhere in the universe within a human lifetime, not by breaking physics but by using it. No wormholes, no warp drives, just constant acceleration and time dilation.

## So I reached out to Andy Weir

At this point I was too deep in. The numbers were clear. 2 million kg only works for a flyby, and to actually stop you need 42 million. Something in the book doesn't add up. So I reached out to the author.

And he agreed.

![Andy Weir confirming the fuel calculation error](/images/posts/andy-weir-reply.png)

Andy Weir confirmed that the 2 million kg of Astrophage was only enough for a flyby. To actually stop at Tau Ceti you'd need to square that mass ratio, and he acknowledged it was an error. But then he said something interesting.

## The coast phase. This is actually genius.

Weir said his fix was to add a coast phase, and honestly it's so simple it's beautiful. Instead of burning engines for the entire trip you do this: accelerate hard for a short burst, turn off the engines completely and just drift, then fire them again at the end to slow down. That middle part? Zero fuel. Free distance. You're just vibing through interstellar space with the engines off.

The tradeoff is time. You're not accelerating anymore so the trip takes longer, but the fuel savings are massive. I ran every coast percentage from 0 to 95%. Drag the slider:

<CoastPhaseSlider />

At 85% coast something beautiful happens:
- Fuel needed: ~2 million kg ✅ matches the book
- Mass ratio: 20.7:1 ✅ matches the book
- Crew time: 6.6 years (longer than the "4 years" in the movie but survivable)

The book's numbers work perfectly if Grace was coasting for 85% of the trip. Basically accelerate for about 1 light year, drift for 10, decelerate for 1. The movie says "4 years 2 months 11 days" which maps to about 50% coast, and that still needs ~12 million kg of fuel. So the movie didn't fully fix it. But the novel? 85% coast. Everything checks out.

## Why this book is different

Most sci-fi just handwaves the science. Wormholes here, warp drives there, some magic crystals because the plot needs it. Andy Weir actually sat down with the relativistic rocket equations and built a story around real physics. When the numbers were slightly off he had a real physics fix for it, not "oh the aliens have special technology" but just a coast phase. An actual engineering solution.

The fact that this novel survives a spreadsheet is insane. Not perfectly, but close enough that the fix is elegant and makes physical sense. Most stories don't survive a calculator. This one almost does, and honestly that's the highest compliment I know how to give.

## The math for the nerds who stayed

Rapidity (relativistic "distance" in velocity space):
```
φ = acosh(1 + a·d / c²)
```

Peak velocity:
```
v = c · tanh(φ)
```

One way mass ratio (photon drive):
```
R = e^φ
```

Brachistochrone mass ratio (actually stopping):
```
R_total = R²
```

Time dilation factor:
```
γ = 1 / √(1 - v²/c²)
```

For a = 1.5g, d = 11.9 ly, ship = 100,000 kg:
- φ ≈ 3.03
- v ≈ 0.995c
- γ ≈ 10.2
- R (one way) ≈ 20.7
- R² (stop) ≈ 429
- Flyby fuel ≈ 2.0M kg ✅
- Stop fuel ≈ 42.8M kg
- Coast 85% fuel ≈ 2.0M kg ✅

~ Ashish Kumar Verma


I recreated the relativistic fuel math from Project Hail Mary, found a stopping problem in the calculations, reached out to Andy Weir directly, and got confirmation of where the numbers went wrong. The ship doesn't stop, and here's the physics that explains why.

I Contacted the Author of Project Hail Mary About Wrong Fuel Calculations and He Agreed


I was reading something and boom, this lands in my feed. A Polish theoretical physicist just proved you can recreate all of math's elementary functions from JUST one operation.

$$
E(a, b) = e^{a} - \ln(b)
$$

Every single operation you'd find on a scientific calculator: +, −, ×, ÷, √, trig, log, hyperbolics, inverses, even constants like e, π and i, as you can see below. Extremely mathematically elegant.

My first reaction was, ok cool, another reduction paper, those show up every few years, let me skim it. Then I hit the abstract properly and sat up. The claim wasn't "we reduced 36 operations to 6 primitives", which would be a nice optimisation. The claim was that a single two-input function plus the number 1 is enough to reconstruct every constant, every arithmetic operation, every trig function, every hyperbolic function, every inverse, every radical. Everything. The entire scientific calculator collapses into one button and a seed value.

That sounds like one of those "technically true but useless" results until you realize that continuous mathematics has been looking for exactly this for about a hundred years and nobody had found it.

## the comparison that makes this land

In 1913, Henry Sheffer published a paper showing that a single two-input logical operator, NAND, is enough to build every Boolean function. AND, OR, NOT, XOR, everything. Dump a pile of NAND gates on a table and you can literally construct an entire CPU out of them. This is not a trick, it's how digital hardware actually works. Modern chips are, at the lowest level, seas of identical gates wired into patterns that compute. That one fact is responsible for about half of what makes silicon cheap.

Continuous math never had this. A scientific calculator has thirty-plus keys, and the reason is that every new function the designers wanted to support needed its own button and its own internal routine. Logarithms reduced multiplication to addition back when Napier published in 1614. Euler's formula folded trig into complex exponentials in the 1700s. The exp-log representation formalised that further. And then it stopped. For the last couple of centuries the minimal basis for elementary functions has been "a few primitives", never one. It felt like the bottom of the well.

This paper pulls the bucket out of the well. A single binary operator, plus the constant 1, is sufficient. The gap between this result and everything that came before is roughly the gap between "we use the Sheffer stroke because it's convenient" and "wait, it actually reduces to one thing."

## the operator

Here it is in full. No tricks hidden in the corners.

$$
\mathrm{eml}(x, y) = \exp(x) - \ln(y)
$$

EML stands for Exp-Minus-Log. That's the whole definition.

The reason you need a constant paired with it is that ln(1) = 0, so anywhere you want to drop the log side of the operator, you plug in 1 on the right. That single trick lets you peel the operator apart into its components whenever you need them. For example:

$$
\begin{aligned}
e^{x} &= \mathrm{eml}(x, 1) \\
e &= \mathrm{eml}(1, 1) \\
\ln(z) &= \mathrm{eml}\bigl(1, \mathrm{eml}(\mathrm{eml}(1, z), 1)\bigr)
\end{aligned}
$$

Read that last one carefully, because it's the first time you see what a proper EML expression looks like. The natural logarithm of z takes three nested applications of the same operator and four instances of the constant 1. It's simple in the Kolmogorov sense but very nested in practice. Most things you'd expect to be short turn out to be long.

Before we get into how anyone found this in the first place, play with it.

<EMLTreeExplorer />

Try `ln z` with z = 2.718. The EML tree should spit back 1.0, because ln(e) = 1, and you can watch each sub-node compute its partial value. Then try `e^x` at x = 2 and confirm you get e² ≈ 7.389. The point of the interactive is that you can feel how an elementary function, which you normally think of as a named primitive, is actually just a specific arrangement of a single repeating element. The "function" stops being a label and starts being a tree shape.

## how on earth do you find an operator like this

This is the part that broke my brain a little. You can't just stare at exp and ln and derive their difference by inspection. The paper is very honest about this. It was found by systematic ablation, starting from a list of 36 primitives that together form a standard scientific calculator, which is Table 1 in the paper: 8 constants, 20 unary functions, and 8 binary operations. Elements get iteratively removed from that list, and each remaining set is checked to see if it can still reconstruct the original 36.

The verification itself is where the clever bit lives. Direct symbolic verification is computationally intractable. Kolmogorov-style complexity for these formulas tends to sit around 7 to 9 in Reverse Polish Notation length, which sounds small until you realise the search space at depth 9 is already brutal. So instead of symbolic manipulation, the paper uses a hybrid numeric bootstrap. Free variables x and y get substituted with algebraically independent transcendental constants, specifically the Euler-Mascheroni constant γ ≈ 0.577216 and the Glaisher-Kinkelin constant A ≈ 1.28243, the target expression is evaluated numerically, and then compared against a massive sieve of candidate formulas built from the current operator set.

The reason this works is Schanuel's conjecture. Under Schanuel, a coincidental equality between two algebraically independent transcendentals evaluated at the same point is vanishingly unlikely. So if a candidate formula gives you a numeric match to double-precision on γ and A, it's almost certainly an actual equivalence and not a fluke. This turns formula discovery into a high-precision lookup problem. The double-precision result goes through inverse symbolic calculator software, which returns a candidate closed form, and then you verify it symbolically.

That entire pipeline was originally implemented in Mathematica as a package called VerifyBaseSet. Then GPT Codex 5.3 was used to translate it into Rust, which made it three orders of magnitude faster. Mathematica took hours, Rust takes seconds. That's what made it feasible to run the ablation exhaustively on every element of the 36-primitive list and track how the calculator shrinks.

## the reduction chain

Here is the actual shrink, in order. I'm keeping the paper's naming.

| Name | Constants | Unary | Binary | Total |
|---|---|---|---|---|
| Base 36 | 8 | 20 | 8 | 36 |
| Wolfram | π, e, i | ln | +, ×, ^ | 7 |
| Calc 3 | none | exp, ln, −x, 1/x | + | 6 |
| Calc 2 | none | exp, ln | − | 4 |
| Calc 1 | e or π | none | x^y, log_x y | 4 |
| Calc 0 | none | exp | log_x y | 3 |
| **EML** | **1** | **none** | **eml(x, y)** | **3** |

Each row is a complete scientific calculator on its own. Calc 3 sits near the Wolfram Mathematica primitive set, which has been the optimised minimalist basis for about forty years. Calc 2 is stricter: negation and reciprocal fall out, but you need subtraction as the non-commutative backbone, because without a non-commutative operation you lose the ability to invert. Calc 1 is a radically different attack, a top-down approach built from binary exponentiation and binary logarithm, which needs either e or π as its seed constant. Calc 0 absorbs e into the exp function itself, leaving three primitives total.

Calc 0 was the configuration that strongly suggested a single binary operator could exist. Once you have a system with three primitives and one of them is a unary function, it's natural to ask whether you can absorb the unary into the binary. A month of searching later, eml fell out of the search.

EML is also not unique. It has at least two close cousins.

$$
\begin{aligned}
\mathrm{eml}(x, y) &= \exp(x) - \ln(y) && \text{with constant } 1 \\
\mathrm{edl}(x, y) &= \exp(x) / \ln(y) && \text{with constant } e \\
-\mathrm{eml}(y, x) &= \ln(x) - \exp(y) && \text{with constant } -\infty
\end{aligned}
$$

EDL swaps subtraction for division and trades the constant 1 for e. The minus-eml variant flips operand order and requires the terminal symbol to be −∞, which is weird but valid in extended reals.

The paper then speculates, with empty table rows, that a two-primitive or five-primitive system might exist waiting to be discovered. A ternary operator T(x, y, z) = exp(x) · ln(z) / (ln(x) · exp(y)) already has the property that T(x, x, x) = 1, which would let it act as its own constant. That's a separate paper in preparation for Acta Physica Polonica B.

## the complexity tax

This is the part you can't ignore. Reducing to one operator is elegant, but the cost is that simple things become giant. The paper includes a beautiful table showing how many RPN instructions each primitive needs when compiled to pure EML form.

| Symbol | EML compiler | Direct search |
|---|---|---|
| e | 3 | 3 |
| 1 | 1 | 1 |
| 0 | 7 | 7 |
| −1 | 17 | 15 |
| 2 | 27 | 19 |
| √2 | 165 | >47 |
| i | 131 | >55 |
| **π** | **193** | **>53** |
| e^x | 3 | 3 |
| ln x | 7 | 7 |
| x × y | 41 | 17 |
| x^y | 49 | 25 |
| √x | 139 | 43 |

Computing π in pure EML needs 193 instructions. Not 193 nested evaluations, 193 nodes in the expression tree. That is absurd by any reasonable standard. But it's also deeply interesting, because it tells you something about how much of the "complexity" of elementary functions we have been hiding inside named primitives. We built our scientific calculator to look simple by giving individual names to the expensive things. Strip the names away and the real cost becomes visible. Digital hardware is fine with this, incidentally: a modern CPU has billions of transistors, so 193 of anything is a rounding error.

The uniform structure is what the paper is really selling. Because every EML expression is a binary tree of identical nodes, you get a trivial context-free grammar.

```
S → 1 | eml(S, S)
```

That's the whole language. And that grammar is isomorphic to full binary trees, which means EML expressions are in one-to-one correspondence with Catalan structures. You get a clean combinatorial object to search over. You can enumerate EML trees by leaf count and exhaustively check every small tree. You can compile any elementary function into one. You can even build an analog circuit where each identical component is a physical eml gate, with the same status as a NAND gate in digital hardware or an op-amp in analog electronics. The paper actually draws the schematic symbol.

## the part that surprised me

Then the paper does something I wasn't expecting. It treats the EML tree as a differentiable neural network and tries to recover closed-form formulas from numerical data using gradient descent.

The idea is simple once you see it. Build a full binary EML tree of depth n. At every leaf, instead of hardcoding a 1 or a variable, put a soft mixture of the three possible values weighted by trainable parameters.

```
leafᵢ = αᵢ + βᵢ · x + γᵢ · f
```

The α, β, γ at each leaf are logits pushed through a softmax, which means the tree is parameterised by roughly 5·2ⁿ − 6 continuous weights. A level-2 tree has 14 parameters, a level-3 tree has 34 parameters which simplex reparameterisation reduces to 20. Standard Adam optimiser, PyTorch, complex128 to handle the internal complex arithmetic, clamping to deal with exp overflow, and then a hardening phase that snaps each softmax output to a vertex of the simplex, meaning each leaf commits to being either a 1 or an x or the previous sub-expression.

The result is that for simple target functions, the network recovers the exact symbolic formula. Fit ln(x) using a depth-3 tree, reduce 34 free parameters to 20 via simplex reparameterisation, run plain NMinimize on a black-box basis, and at the end the snapped weights give exactly ln(x). Not approximately. The mean squared error at convergence is on the order of 10^−32, which is machine epsilon squared. When you round the softmax weights to the nearest vertex, you get the actual closed-form formula, and it generalises perfectly outside the training range.

The blind-recovery numbers across 1000+ runs are also honest:

- Depth 2: 100% blind recovery from random initialisation
- Depth 3 to 4: about 25% blind recovery
- Depth 5: below 1% blind recovery
- Depth 6: 0 out of 448 attempts

So it's not magic. Finding the correct EML tree from scratch gets harder fast. But there's an important follow-up experiment. When you take a correct EML tree, perturb its weights with Gaussian noise, and re-optimise, the optimiser converges back to the correct solution in 100% of runs, even at depth 5 and 6. Which means the basins of attraction around correct EML formulas are valid and wide. The hard part is getting close enough to one of them in the first place.

This is the piece that feels different from the rest of the paper. It's saying that because EML expressions are a uniform, differentiable, complete family, you can do symbolic regression by gradient descent on a fixed architecture. No heterogeneous grammars, no handcrafted operator sets, no tree-search bookkeeping. Just an EML tree, a softmax over leaves, and an optimiser. When the generating law is elementary, the weights snap to exact symbolic values. The paper calls this a form of interpretability that conventional neural architectures cannot provide: if your training succeeds, the network is literally a closed-form formula.

## the deep technical dive

If you're the kind of person who wants receipts, here they are.

**Three lines of Mathematica reproduce the discovery:**

```
Import["SymbolicRegression.m"]
EML[x_, y_] := Exp[x] - Log[y]
VerifyBaseSet[{1}, {}, {EML}]
```

That's it. Run this and the package re-generates all 36 elementary operations from Table 1 of the paper within about an hour, depending on your machine. The Rust re-implementation, rust_verify, does it in seconds and also handles arbitrary-precision checks across multiple real transcendentals instead of just two.

**The level-2 master formula:**

```
F(x) = eml(
  α₁ + β₁·x + γ₁·eml(α₃ + β₃·x, α₄ + β₄·x),
  α₂ + β₂·x + γ₂·eml(α₅ + β₅·x, α₆ + β₆·x)
)
```

Fourteen parameters in total. Set α₁ = 0, β₁ = 1, γ₁ = 0 on the left child and α₂ = 1, β₂ = γ₂ = 0 on the right, and you recover exp(x). Set α₁ = α₂ = 1 with everything else zero, you recover e. Set α₁ = β₁ = 0, γ₁ = 1, α₂ = 1, β₂ = γ₂ = 0, α₃ = 0, β₃ = 1, γ₃ = 0, α₄ = 1, γ₄ = 0, you recover exp(exp(x)). The point is that every reachable function at depth ≤ 2 is a specific vertex of a 14-dimensional simplex. Training the EML tree is equivalent to searching that simplex with gradient descent.

**Internals are complex.** EML operates over ℂ using the principal branch. You need complex arithmetic internally to generate things like i and π, because π shows up as −1 × i × ln(−1), which means you have to evaluate ln(−1) = iπ. So every EML evaluator, even for real outputs, runs on complex128 under the hood. Real-valued code using `<math.h>` mostly works but has a subtle i-sign flip on ln(z) for z < 0 that you have to fix with a principal-branch redefinition. The paper also points out that Python and Julia traps on signed zeros, NumPy and PyTorch handle it with overflow signals, and Lean 4's total function convention makes ln(0) return a junk value that breaks formalisation. These are edge cases, not showstoppers, but they exist.

**Reproducibility.** Code lives at github.com/VA00/SymbolicRegressionPackage, archival snapshot at Zenodo DOI 10.5281/zenodo.19183008.

**Caveats the paper is careful about.** The existence of an EML-type operator working purely on the real domain seems impossible. Attempts using pairs of trigonometric or hyperbolic functions found nothing. Complex intermediates are not a bug, they appear to be necessary. Also, the identity function x takes leaf count 9 in its shortest non-trivial EML form (though the compiler can return it directly as leaf count 1). The shortest non-trivial EML expression of anything is, somewhat hilariously, longer than you'd guess.

**Still open.** Whether a truly univariate Sheffer-like function exists, one where even the constant falls out of the operator itself, is open. The ternary operator T(x, y, z) = exp(x) · ln(z) / (ln(x) · exp(y)) with T(x, x, x) = 1 is the current best candidate and is the subject of a follow-up paper. Proving general impossibility is non-trivial because of weird examples like B(x, y) = x − y/2 where B(x, x) = x/2 but B(B(x, x), x) = 0, which the paper uses to motivate why you can't hand-wave the proof.

## what this actually changes

You could argue that EML is just a curiosity. It doesn't let you compute anything new, it just re-shuffles what we already compute. Fair. But I think the framing matters more than people might initially notice.

First, elementary functions now have a canonical normal form. Every closed-form expression you can write with sin, cos, exp, ln, and friends has a unique compiled EML tree, which is a unique element of a context-free grammar. That gives you a clean object to hash, search, and deduplicate. Symbolic regression systems have wanted this kind of uniform structure for years.

Second, this is a genuine interpretability handle for machine learning. The paper quietly makes the point that every standard neural network is, in principle, a special case of an EML tree architecture, because ReLU and similar activations are themselves elementary functions. That means an EML-based symbolic-regression network isn't a toy replacement for a transformer, it's a version of a transformer where the weights, when training succeeds, are exact formulas. The circuit is legible as a closed-form expression. That is not something you can currently say about, say, any large language model, and it's a form of interpretability that no conventional deep learning architecture provides.

Third, the analog-computing angle is intriguing. If you can fabricate a physical eml gate the way we fabricate NAND gates, you get a completely uniform substrate for evaluating elementary functions. No lookup tables, no special circuits for different functions, just a sea of identical elements wired differently. Whether anyone actually builds this is a different question, but the paper provides the theoretical ground floor.

## my honest take

I didn't expect a 2026 paper to close a gap that has been open since Sheffer. I especially didn't expect the proof to come out of a systematic ablation search rather than a deep structural argument. The vibe of the paper is "nobody actually tried this exhaustively and the search space was tractable with a Rust rewrite", and I really like that. It's a reminder that foundational discoveries sometimes happen because someone with the right tools decides to actually run the exhaustive search.

The complexity tax is real. No one is going to compute π as a 193-node EML tree in production. But production was never the point. The point is that elementary functions, for a hundred years treated as an irreducible handful of things, are actually members of a single connected family under one generator. That's a structural fact about mathematics, not a performance optimisation. The paper is clean, the code is reproducible, and the harder variants are left on the table for the next person to chase.

The conclusion ends with, in my paraphrase, "the EML operator may be the tip of an iceberg". I believe it. If you want to read the original and check my numbers, it's on arXiv at 2603.21852v2.

~ Ashish Kumar Verma 🫡


A new arXiv paper shows that a single binary operator, eml(x, y) = exp(x) - ln(y), plus the constant 1, can generate every elementary function. It's the continuous-math analogue of NAND, and it took 112 years to find.

You Can Recreate All Math Functions From JUST One Operation


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.

Save Yourself from 'Something Bigger Is Happening'


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.


Give two smart people the same dataset, the same model, the same code. One of them looks at the output and says, "this looks great, ship it." The other looks at the exact same output and says, "hm. What happens in the tails?" I've watched this happen over and over, at university studying mathematics, in finance, now working as a quant developer. And the thing that surprised me is that both people are often equally intelligent. They both understand the math. They can both build the system themselves. But they interpret the same information in completely different ways.

The difference is not intelligence. It is not coding ability. It is definitely not who memorized more formulas. The difference is how they think about the problem.

## you're thinking in dots when you should be thinking in shapes

Ask someone "what's a good salary for a software engineer in Bangalore?" and most people will give you a number. 18 LPA. 25 LPA. 40 LPA. A single dot on a number line. That number feels precise, feels like an answer. But it is not an answer. It is a summary that has thrown away almost everything interesting about the question.

A salary distribution is not a dot. It is a shape. The shape tells you that the median is around 15 LPA but there is a fat right tail where a small number of people earn 80 or 100 LPA, dragging the "average" way above what the typical person actually takes home. It tells you that the 10th percentile earns 6 LPA while the 90th percentile earns 45 LPA. Same job title, wildly different lives. When someone says "the average salary is 25 LPA", they are technically correct, but in a right-skewed distribution, the average is a number that almost nobody actually earns. Most people earn less. A few people earn much more. The average sits somewhere in between, belonging to no one.

This is the first shift that quantitative thinking produces. Single numbers start to feel suspicious. Not wrong exactly, just incomplete, like being told the average depth of a river is 3 feet and deciding it is safe to walk across. Technically accurate. Potentially fatal.

<DistributionExplorer />

Try it. Drag the skew slider to the right. Watch the orange line (the mean) drift away from the green line (the median). Same dataset. Same "average." But the typical outcome and the reported average are now telling completely different stories. This happens everywhere once you start looking. An algorithm with good average-case performance that catastrophically fails on rare inputs. A machine learning model that is 95% accurate overall but dangerous on the specific edge cases that matter. A financial strategy that delivers steady small gains until the one event in the tail distribution wipes it all out.

Two systems can have identical expected values and behave in completely different ways. The average hides the shape. The shape is where the actual information lives. Once you develop this instinct, you never look at a single number the same way again. You always want to know what the rest of the distribution looks like.

## the habit of attacking your own best idea

Once you start thinking in distributions, something uncomfortable happens. You realize your confident opinions are just point estimates wearing a suit.

Say you are deciding whether to leave your stable job and join a promising early-stage startup. You think it through. The founders are smart. The market is growing. You will get meaningful equity. The upside is enormous. Each of those beliefs feels solid. 85% sure about the team. 90% sure about the market. 75% sure the equity means something. 60% sure they survive three years. Each one on its own feels like a strong bet.

But here is what quantitative thinking does to that confidence. It multiplies. If those are genuinely independent assumptions (they are not, but let's start simple), the probability that ALL of them hold simultaneously is 0.85 times 0.90 times 0.75 times 0.60. That is about 34%. Your "pretty confident" position is, in joint probability terms, slightly worse than a coin flip.

This is why quants develop what looks from the outside like pessimism but is actually something different. It is the habit of attacking your own best idea. Not as a performance. Not as devil's advocate at a meeting. Genuinely trying to destroy the argument you just built. The instinct goes like this: you form a view, it feels right, you have good reasons. And then, instead of feeling satisfied, you spend equal effort constructing the strongest possible case against it. You look for the assumption that, if wrong, would make the whole thing collapse. You find the condition that your conclusion is implicitly depending on and ask what happens when that condition changes.

Most people think confidence means certainty. The quant version of confidence is different. It means, "I tried hard to break this and couldn't." That is a fundamentally different kind of confidence, one that is earned through attempted destruction, not through the absence of doubt.

<AssumptionStressTest />

Click through each assumption. Read the counter-argument. Adjust your confidence. Watch the bottom bar. The gap between the blue bar and the orange bar is not pessimism. It is the information that was always there but hidden by the comfortable feeling of each individual assumption being "probably right." The joint probability is the honest answer. The individual confidences are the story you tell yourself.

Ideas that survive this kind of scrutiny are much stronger. By the time they are trusted, they have already been tested against the scenarios that could break them. And the goal is always the same: discover the weaknesses before reality does it for you.

## the feedback loop nobody talks about

There is a popular framing that puts intuition and formal reasoning on opposite sides. Trust your gut versus trust the data. Instinct versus analysis. Fast versus slow. That framing is wrong.

In practice, the people who are best at quantitative reasoning use both, constantly, in a tight loop. It works like this: intuition moves first. You look at a dataset, a model output, a system's behavior, and something feels off. You cannot articulate exactly what. It is just a sense that the result is too clean, or the convergence was too fast, or the distribution looks wrong in a way you cannot immediately name. That feeling is not noise. It is pattern recognition built from hundreds of similar situations, years of seeing systems behave in certain ways. But intuition alone is not enough because it cannot be audited. You cannot explain "it felt wrong" to a colleague. And sometimes it is just bias wearing a lab coat.

So formal reasoning takes over. You check the assumption your gut flagged. You compute the statistical power of the test. You look at the residual distribution. You stress test the edge cases. Sometimes your intuition was exactly right. The result was too clean because there was a data leak. The convergence was too fast because the optimizer was stuck in a local minimum. Your gut caught something your code missed.

Other times your intuition was right for the wrong reasons. The test was underpowered but the effect was also real, just smaller than reported. Your instinct was firing on the variance problem, not the effect size problem. The formal analysis corrected the diagnosis while confirming the symptom. And occasionally your intuition was completely wrong. The thing that felt suspicious was actually fine. You just had not seen that particular pattern before.

What matters in all three cases is that the formal analysis updates the intuition. The next time you see something similar, your pattern recognition is slightly better calibrated. You flag fewer false alarms. You catch real problems faster. Intuition without formalism is superstition. Formalism without intuition is bureaucracy. The loop between them is where actual thinking lives.

Over time, this process builds a deeper understanding than either one could achieve alone. Instead of relying entirely on instinct or entirely on equations, quantitative thinking moves fluidly between the two. And it teaches you that the question is never "should I trust my gut or the data?" The question is "which one should go first right now, and how quickly can I hand it off to the other?"

## the math for the nerds who stayed

If you are still here, let's look at why these instincts have formal backing.

**Why distributions beat point estimates, an information theoretic argument**

A point estimate is a single number. A probability distribution is a function. The information content difference between them is measurable. The Shannon entropy of a continuous distribution with PDF p(x) is:

```
H(X) = -integral of p(x) * log(p(x)) dx
```

For a Gaussian with standard deviation sigma, this works out to:

```
H(X) = 0.5 * log(2 * pi * e * sigma^2)
```

A point estimate has zero entropy. It contains no uncertainty information at all. The distribution encodes exactly how much you know and how much you don't. When you collapse a distribution to a single number, you are literally discarding measurable information. The gap between the entropy of the distribution and zero (the entropy of the point estimate) is the information you threw away by saying "the average is 25 LPA" instead of describing the shape.

**Adversarial questioning as Bayesian updating**

The stress testing instinct has a clean formalism in Bayes' theorem:

```
P(H|E) = P(E|H) * P(H) / P(E)
```

Your initial confidence in an assumption is the prior P(H). The counter-argument is new evidence E. The likelihood P(E|H) measures how compatible the counter-argument is with your assumption being true. When you "stress test" an assumption, you are implicitly evaluating alternative likelihoods. If the counter-evidence is highly likely regardless of whether your assumption holds, it does not update your belief much. But if the counter-evidence is much more likely under the alternative hypothesis (your assumption is wrong), your posterior drops sharply.

The joint probability calculation in the interactive component above is a simplification (it assumes independence), but the core insight holds. Stacking multiple assumptions where each has even a moderate failure probability leads to joint probabilities that feel shockingly low. For n independent assumptions each with probability p:

```
P(all hold) = p^n
```

| Individual confidence | 3 assumptions | 5 assumptions |
|---|---|---|
| 90% | 72.9% | 59.0% |
| 80% | 51.2% | 32.8% |
| 70% | 34.3% | 16.8% |

Even at 90% confidence per assumption, five stacked assumptions leave you below 60%. This is why quants obsess over assumption counting.

**The intuition-formalism loop as approximate Bayesian inference**

There is a growing body of work in computational neuroscience (often called the "Bayesian brain" hypothesis) suggesting that human cognition approximates Bayesian inference. Your prior beliefs about how systems behave get updated by new observations, producing a posterior that becomes your new prior for the next encounter. The loop described in the previous section, intuition generates a hypothesis, formal analysis tests it, the result updates your intuition, is structurally identical to iterative Bayesian updating. Each cycle through the loop refines the posterior. Over time, the prior (your intuition) becomes increasingly well-calibrated to the domain.

This is why experienced quants seem to have almost supernatural instincts. They are not smarter. They have just run more update cycles.

## honest take

I don't think quant thinking makes you smarter. I think it makes you slower to be wrong. Which sounds like the same thing, but it isn't. Smart people are wrong all the time. They just sound confident while being wrong. The quant habit is less glamorous. You spend a lot of time saying "I don't know, but here's my distribution over the possibilities." Nobody has ever looked cool saying that.

But over time, the people who think in distributions instead of dots, who attack their own best ideas, who run the loop between intuition and formalism, they tend to be wrong less often in ways that matter. Not because they avoid mistakes entirely, but because they discover the fragile assumptions before those assumptions become expensive lessons. The world does not get less uncertain when you learn to think quantitatively. It just stops being as scary. Unknown outcomes become part of a structured problem instead of an unsolvable mystery. And numbers stop being answers and start being invitations to understand the system behind them.

That shift, from treating numbers as conclusions to treating them as clues, is the whole thing.


Two people can look at the same dataset and walk away with opposite conclusions. The difference is not intelligence. It is how they think about uncertainty, assumptions, and the structure behind the numbers.