
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.

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.


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

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.

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


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.

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


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.

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

The Quant Mindset Is Not About Math. It's About How You See Numbers.

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

Save Yourself from 'Something Bigger Is Happening'

Create a Signature Painting Drawing App using Javascript