Types with AI

Types with AI

2026-07-26

I’m a big fan of types. Properly implemented, they make a system<br>honest, safe, agile, and delightful to work in and work with. They also<br>have incredible influence over how code gets written. Properly<br>harnessed, they can create a pit of success[1] for engineering orgs.

Unfortunately it’s incredibly hard to directly measure their<br>benefits. It’s almost always an uphill battle to convince teams and orgs<br>to commit to fully utilizing types. So over the past few months as AI<br>agents are straining traditional ways of working and the industry is<br>contorting itself to better leverage LLMs, I’ve been getting more and<br>more excited. Maybe, finally, the need is high enough to justify broader<br>and deeper adoption of types.

Observations from the<br>past couple months

Some observations I’ve had at work and more broadly within the<br>industry:

LLMs are great at code exploration and solving targeted<br>problems . This makes sense after seeing the current benchmarks<br>and techniques used in post training.

It’s very easy to overextend with LLMs and end up<br>unproductive. You’ve been here before if you’ve ever felt lost<br>working with an LLM. It’s a sign that you’ve gone beyond what you know<br>and are no longer able to steer the LLMs out of dead ends.

LLMs are bad at writing maintainable code[2] . The<br>longitudinal aspects of maintaining a system isn’t in its training. It’s<br>hard to encode these nonfunctional requirements as reward signals.

The productivity boost from LLMs has largely not scaled<br>beyond the individual . Team and organization level projects are<br>still measured in the same number of weeks and months.

Many LLM powered projects get to the demo phase but don’t<br>get out . Since the beginning of 2026, I’ve seen a sharp jump in<br>the number of new products, features, and tools developed at work. A few<br>months have passed and almost all of them have either silently died or<br>failed to gain adoption.

Restructuring engineers into AI native pods[3] is not going<br>well . It’s disruptive and contributing to record low<br>morale[4].

Engineers aren’t able to keep up with the volume of code in<br>code review . At work, we’ve experimented with several ways to<br>keep code review alive. Most of them are some flavor of automated checks<br>and summaries that have had the effect of reducing active participation<br>and promoting rubber stamping.

Reviewing LLM generated code feels bad.

How can types help?

Types have several properties that can help address and sidestep<br>these problems.

Code Review

Types are a lean description of the system’s<br>behavior. As the volume of code threatens to overwhelm code review and<br>the provenance of the code submitted threaten to render it a meaningless<br>ritual, types offer a way for the practice to keep up and adapt. They’re<br>much faster to review and they shift the focus onto the structures that<br>bound code. These structures are arguably more important than the<br>implementation since they not only influence the current code, but also<br>future code. As LLMs make code cheap and rote, shifting the focus of the<br>review from the implementation to the types ensures review is focused on<br>human design decisions and intent.

It’s much more fun to review the human aspects of work. Before, code<br>review felt personal and was a way to connect with your coworker. It was<br>an opportunity to learn and a place to share expertise. There was an<br>unwritten contract: the author put in time and effort and by reviewing<br>the code you were upholding your part. Now LLM code reflects nothing<br>about your coworker — there’s nothing to learn from reading it line by<br>line. The effort to wade into the slop to find something interesting to<br>remark on isn’t rewarding. Who’s the feedback for? Your coworker isn’t<br>writing code anymore and your comments aren’t directly driving<br>improvements to the models. And worst of all, it’s no longer certain<br>your coworkers are even reviewing their own code anymore.

Whenever I review code, I jump directly to the types. If they don’t<br>exist, I look at function signatures to understand the interfaces. This<br>offers me a hierarchical map that allows me to jump<br>around and dive in and out of implementation to find anything<br>interesting or critical. I realized that going into the code is slow and<br>doesn’t matter if the original design was flawed. Types offer a quick<br>short circuit check with a fraction of the reading.

Summaries can be another alternative but they’re often misleading,<br>outdated, or omit key details. Increasingly, they’re being written by AI<br>which often misprioritize or highlight nonsensical details that further<br>obfuscates what the purpose of the change is. At one point, we also<br>looked to prompts as an alternative. While they offer exact insight to<br>the author’s intent, they pose a huge privacy issue. Most people are<br>uncomfortable or unwilling to have their prompts inspected. In practice,<br>reviewing prompts is also awkward as most work gets done in multiple<br>turns. Critically, both options contain a fatal flaw....