Stacks of Wheat (End of Summer). Claude Monet, 1890-91

AI agents excel at using programming languages with fast, clear feedback loops, right? Do those languages have to be statically typed, too?

No, but I think they should be anyway.

At Facebook, there was a great internal shitposting group called “Dynamic Safety” (iirc; someone tell me if I’m mis-remembering the name) where examples of failures caught at runtime (normally in production, sometimes causing outages) in dynamic languages were posted. As the company scaled, the need for compile-time guarantees became obvious, and huge amounts of energy were expended in making the dynamic languages that underpinned the company’s biggest projects safer (Hack, which is fully statically-typed, for the main monolith; type-checked Python for Instagram; and both FlowJS and Reason for JavaScript). At scale, static types give guarantees that no amount of unit tests, integration tests, and deploy canaries can (not that those things aren’t still important).

But that was back in the old days, when squishy, fallible humans still wrote all the code. Now that AI is doing all the coding, does it still matter?

Obviously I think it does, for several reasons:

  1. Coding agents might not be squishy, but they are certainly fallible. Even worse, they have terrible memories, and when programming with dynamic languages you need to constantly ask yourself “did I handle that case?” You don’t want to find out at runtime that your agent compacted its context right before it was going to put in all the exception handling.
  2. Types are token efficient. Types are both documentation and tests whose accuracy is enforced by the typechecker. The agent doesn’t have to write them, nor does it have to read or write docblocks about them. Result<Foo, BarException> is both more precise and fewer tokens than “This function will return a Foo on success, or a BarException on failure.”
  3. Type errors are (normally) local. I say normally because we’ve all seen pages-long C++ template error spew, but for the most part a type error will pinpoint not just where the error is, but also the nature of the broken expectation. This saves the agent time and context window figuring out why its code isn’t working.
  4. Types enable other layers of the feedback loop. LSPs are much more useful when you can jump not just to definitions but also the definitions of the types for all of a function’s arguments. The typechecker itself is a layer of the feedback loop, too.

If all this sounds familiar, you’re right: these are essentially the same arguments we made for statically-typed languages when humans were writing all the code. It turns out that they apply even more to AI agents. Humans at least have institutional memory and code review culture. Agents just have a context window and a temperature setting.

Give them a typechecker.

Subscribe to get new posts by email. Follow on Mastodon.

Image: Stacks of Wheat (End of Summer). Claude Monet, 1890-91

Follow on Mastodon

Enter your Mastodon instance: