I read two things this week that I can't stop thinking about together.
The first was a post mortem on Haskell at H-E-B — the Texas grocery chain. Eight years ago, a team there began replacing a COBOL mainframe with Haskell. Today they have nearly a million lines of it running supply-chain systems across 435 stores. That alone is interesting — functional programming in the enterprise is usually the stuff of conference talks that end with "and then we rewrote it in Java." But this one stuck.
The second thing was Gabriella Gonzalez writing about why agentic coding tools don't actually make developers more productive. She cited a Becker study where idle time roughly doubled when developers used agentic coding. People weren't writing better code — they were waiting for the agent to finish, then spending more time reviewing what it produced.
These two threads meet at a point I hadn't thought about before: when AI writes more of the code, the bottleneck shifts from writing to verification. And strong type systems are a force multiplier at exactly that bottleneck.
The production test that matters
The H-E-B story matters because it's not a toy. A million lines of Haskell running the supply chain of a company that moves actual groceries to actual shelves. The argument the team made to leadership was specific: Haskell eliminates whole categories of runtime errors by default. No null pointer exceptions. No type confusion. The bugs that remain tend to be in the interesting part — the business logic.
That's a good pitch for any project. But it becomes a better pitch when a growing share of your code is written by an AI agent that has never seen your business domain, doesn't know your conventions, and will happily hallucinate an API call that looks plausible but doesn't exist.
A compiler that rejects incorrect code before it runs is the fastest code review you'll ever get. It's instant. It's exhaustive. It doesn't get tired. And when the code in question was generated by an agent that lacks genuine understanding, that fast feedback loop isn't a nice-to-have — it's the difference between catching a bug in CI and catching it in production.
The calm after the agent
Gonzalez's essay frames the problem differently. She argues that agentic coding breaks flow — you hand off a task, wait, review, and the waiting keeps you in an interruptible holding pattern. The Becker study's doubled idle time backs this up with data.
What she calls for instead is "calm technology": tools that stay on the periphery of your attention, that inform without demanding it. Inlay hints. Next-edit suggestions. Things that augment your understanding rather than replacing your interaction with the code.
This is where the type system does something that no agent can. A good type system doesn't interrupt you to ask for clarification. It sits quietly, doing its job, and only speaks when something is definitively wrong. When you hover over a value, the type tells you what shape the data has. When you refactor, the compiler tells you everywhere that broke. These are calm interactions — they inform without demanding your full attention.
An agent, by contrast, demands your full attention to review its output. Every AI-generated block is a question: did it get this right? For a 20-line function that's fine. For a 200-line PR where every line was generated, the cognitive load adds up fast.
Where it breaks down
I don't want to overstate the case. Strong type systems come with real costs that the H-E-B story makes plain.
Complexity creep is the big one. Haskell makes it easy to use sophisticated language features — GADTs, type families, template Haskell — and every team has to police its own "complexity budget." H-E-B's rule of thumb was "boring Haskell" for most code, with advanced features confined to small libraries maintained by experts. That discipline is itself a cost. Not every team has the experience to know what to forbid.
Then there's the team problem. H-E-B saw Haskell fail to stick on two separate projects. In one case a space leak brought the whole system down — a team of experienced developers who'd never written Haskell before, using a template from a sibling team, with no Haskell expert to guide them. In the other, the engineers who championed Haskell left, and the replacements drifted back to what they already knew.
The escape hatch is wider than ever now. LLMs can mechanically translate whole codebases. If your team doesn't want to write Haskell, they won't — and no type system can enforce passion.
So what should teams do?
I think the lesson isn't "use Haskell." It's that the properties Haskell champions — fast compiler feedback, fearless refactoring, elimination of entire bug categories — become more valuable, not less, as AI writes more of our code.
The practical question for a team choosing a language today is: when your AI agent generates a block of code, how quickly will you know if it's wrong? If the answer is "when I run the tests" or "when it deploys," that's a verification bottleneck that will only get worse as agents generate more code. If the answer is "the compiler caught it before I even ran it," that bottleneck shrinks.
A language that gives you a tight feedback loop on machine-generated code isn't a luxury. It's the difference between reviewing everything with your full attention and trusting the compiler to catch the noise so you can focus on what matters.
The grocery chain figured this out eight years ago, before AI coding was even on the radar. The rest of us are catching up to the implications.