The strongest type system just lost to the fastest feedback loop.

In July, Avi Press published a post that made the rounds twice, once on Hacker News and once, more painfully, on the Haskell community forum. After seven years of running Haskell in production, Scarf is migrating to Python. Not because the type system failed them. Not because of hiring, though that never helped. The dominant reason was newer than either: LLM coding agents changed the economics of the language, and Haskell ended up on the wrong side of the trade.

That should surprise you, because on paper the LLM era was Haskell’s moment. A model generating code produces plausible text, not verified behavior, and the scarce resource is verification. Haskell is the language that took verification more seriously than anyone: an entire class of bugs that Python teams catch in unit tests, at runtime, or in production simply does not compile. If you believe generated code needs a strong independent checker, GHC is the strongest independent checker that ever shipped in a mainstream-adjacent language. The pitch writes itself. Reality went the other way, and the reasons are worth taking apart, because they apply to more than Haskell.

Four taxes, one verdict

Start with the data problem. Code models perform measurably worse on low-resource languages; there is a whole research literature on the gap between Python-class languages and everything else. Haskell’s public corpus is a sliver of Python’s or TypeScript’s, and the code that exists is unusually dense with project-specific abstraction. A model with thin priors does not reason its way through a tower of monad transformers or a Template Haskell splice; it pattern-matches, guesses, and iterates against the compiler. The deep abstraction that makes expert Haskell compact is exactly what makes generated Haskell flail. The elegance is real, and it is also a wall the model bounces off, taking extra round trips that a Go function would never need.

Which sets up the loop problem, because in an agent workflow, round trips are the whole cost model. The agent’s cycle is generate, compile, read errors, regenerate. Each cycle in Python or Go costs seconds. GHC is doing far more work per cycle, and that work is the feature, but at Scarf even well-optimized warm builds ran about twenty seconds, and cold builds, the kind every fresh CI box and fresh worktree pays, ran far longer despite years of investment in Nix and remote caching. Press’s framing is the one that stuck with me: once a model can produce a working implementation in minutes, a compile step that takes dramatically longer makes the language itself the bottleneck.

The figure runs both loops for a simulated hour. The generation blocks are identical on purpose: the model does not type faster in Go. Everything that differs is verification economics, the green blocks and the amber cold start. Now flip to four worktrees, because that is how agent development actually looks in 2026: several parallel explorations, each in its own sandbox. In our own agent sandboxes, provisioning a fresh Haskell environment takes on the order of twenty minutes before the first useful compile; a Go worktree is live in about one. The fast stack pays its small tax four times and barely notices. The slow stack spends the first third of every lane’s hour just becoming able to work.

Then there is the toolchain, which multiplies both taxes. Haskell has no one blessed path from empty directory to running CI: the community has been split between cabal and Stack for years, with Nix layered on top or instead, and every combination implies different caching, different lockfile semantics, different CI recipes. Ask three production Haskell teams how they build and you will get three architectures, each defended with feeling. A human team absorbs this once and moves on. An agent fleet re-encounters it on every fresh sandbox, and the team maintaining the agents inherits a permanent side-quest of cache tuning and build engineering that, at Scarf, consumed continuous effort just to keep the loop tolerable.

The calculus flipped

The uncomfortable part of Scarf’s report is not the build times. It is what happened after the migration. The type safety they gave up has not been noticeable in practice, because the thing that replaced it, a much faster loop, let them drive test coverage to new highs and ship fixes while still on the phone with the customer reporting the bug. Compile-time verification lost not to worse verification but to cheaper, faster, good-enough verification applied more often.

Notice what did not change: verification still decides. That is the through-line from the last post. Generation got cheap, so the premium moved to whatever checks the output. Haskell’s tragedy is that it holds the premium asset, the strongest checker, in a form whose cost structure is wrong for the new workload: heavyweight, front-loaded, serialized on every iteration, expensive to spawn. A test suite plus a probe against the running app is a weaker oracle per run, but you can afford to run it every ninety seconds in forty sandboxes at once. Weak checks at high frequency are beating strong checks at low frequency.

An honest elegy

I want to be clear about what I am not saying. Nothing here means Haskell’s ideas failed. GADTs, purity, effects tracked in types: the industry has been quietly strip-mining those ideas into Rust, TypeScript, and even Python’s gradual typing for a decade. And given the choice as a reader of code, I would rather review one Haskell magician’s two hundred tight, lawful lines than a thousand lines of generated TypeScript that all looks the same and says nothing. The Haskell is better code by almost any definition we had before 2023.

But the economics do not care what I would rather read. The bottleneck moved from writing to verifying, and then verification itself split into rigor and throughput, and throughput is winning. The languages that thrive in the agent era will be the ones that made the boring bets: enormous training corpora, one obvious build path, sub-second incremental checks, sandboxes that cost nothing to spawn. That is not a description of the best language. It is a description of the best substrate for a very fast loop, and the loop, not the language, is now the unit of engineering.

If your compiler is no longer the thing standing between generated code and production, something else has to be. Make sure something actually is - a real test suite, a probe against the running system, a check you run every cycle instead of once at the end. The teams getting this right are not the ones with the fanciest type system. They are the ones with the shortest honest path from “the model wrote it” to “we know it works.”