Types Are the Guardrails: Why Strict Languages Are Booming in the AI Era

Table of contents

A funny thing happened on the way to “AI writes everything”

A few years ago, the smart-money bet was that dynamic languages would run away with the industry. Less ceremony, fewer keystrokes, ship faster. Types were the tax you paid for being slow.

Then agents started writing most of the code — and something I didn’t quite expect happened. The languages with the strictest type systems are the ones quietly pulling ahead. TypeScript is now the dominant flavour of JavaScript: roughly 40% of developers reach for it, it sits in the top three most-used languages on Stack Overflow’s developer survey, and it’s the third most popular language on GitHub by repository activity. Go keeps climbing the “most admired” charts year after year. Rust has topped Stack Overflow’s “most loved” list for eight years running.

That’s not nostalgia for compilers. It’s a structural shift. And once you see why, you can’t unsee it.

The constraint moved, and types moved with it

I’ve written before that in an agentic workflow the bottleneck moves from production to verification. When an agent can generate a week’s worth of code in an afternoon, the question stops being “can we write it fast enough” and becomes “can we trust it fast enough.”

Here’s the thing nobody says out loud: a type system is a verification machine that runs for free, on every keystroke, with zero human attention. It is the cheapest reviewer you will ever employ — and in a world where agents produce confidently-wrong code at scale, the cheapest reviewer that never gets tired is worth a fortune.

A dynamically-typed codebase says “looks plausible, ship it.” A strictly-typed one says “no — you passed a string where a UserId was expected, on line 412, and I caught it before a human ever looked.” One of those is a sieve. The other is a guardrail.

Why this is the perfect feedback loop for an agent

The deeper reason strict languages are surging isn’t just defensive — it’s that types are the highest-bandwidth feedback an agent can get.

Think about how an agent actually works. It generates, it observes the result, it corrects. The tighter and more precise that feedback loop, the better the output. A compiler error is the dream signal: it’s instant, it’s deterministic, it points at the exact line, and it’s machine-readable so the agent can act on it without a human in the loop. The agent writes, the type checker pushes back, the agent fixes — and that whole conversation happens in milliseconds, before you even see the diff.

A dynamic language gives the agent almost nothing to push against until runtime — which often means until production. You’ve replaced a millisecond compiler round-trip with a multi-hour incident round-trip. That’s a catastrophic trade when the thing doing the writing has no shame about being confidently wrong.

A type system is the cheapest reviewer you’ll ever employ — instant, tireless, and machine-readable. In the agentic era, that’s not a tax. It’s leverage.

This is also why I’m bullish on Go specifically. Its type system isn’t the most expressive on earth, but it’s strict, simple, and unforgiving in the right ways — and the language deliberately removes the clever escape hatches that let agents (and humans) hide ambiguity. Less surface area to get wrong is exactly what you want when the author is a machine generating thousands of lines.

Types are also context — the kind agents can actually use

There’s a second-order effect that I think is underrated. A well-typed codebase isn’t just safer; it’s self-documenting context.

When an agent opens a strictly-typed file, the types are the spec. The function signature tells it what goes in and what comes out. The interface tells it the contract. The compiler tells it instantly when it’s broken the rules. In a dynamic codebase, the agent has to infer all of that from naming conventions and usage patterns — which is exactly the kind of plausible-guessing that produces subtle bugs.

This connects to something I keep coming back to: context is the moat. Strong types are a form of context that lives in the code itself, always fresh, never out of date with the implementation. You don’t have to maintain it as a separate doc that drifts. The compiler keeps it honest for you.

The objection — and why it’s weaker than it looks

The classic pushback: “But types slow you down. All that ceremony, all that boilerplate.”

That argument was always half-true and is now mostly obsolete. The ceremony was the cost of writing types by hand. But agents write the boilerplate now — annotations included — at no marginal cost to you. The expensive part of types (authoring them) got cheap. The valuable part (enforcing them) stayed exactly as valuable, and got more valuable as the volume of generated code exploded.

So the entire cost-benefit calculation flipped. We adopted dynamic languages to optimize for the speed of writing. We’re returning to strict ones because the new scarce resource is the speed of trusting — and types buy that directly.

What I’d actually do about it

If you’re making language and tooling bets for an AI-heavy team, a few concrete moves:

1. Default to strict. Turn on strict: true in TypeScript. Treat any as a smell. The whole point is the guardrail; don’t disable it for convenience.
2. Make the type checker a first-class gate. Run it in CI, run it in the pre-commit hook, and feed its output straight back to your agents. The compiler should be the first reviewer every agent answers to.
3. Prefer languages that fail loud and early. For new services where you have a free choice, lean toward Go, Rust, or strict TypeScript over their looser cousins. You’re optimizing for machine verifiability now, not human typing speed.
4. Treat your types as documentation. Invest in precise, narrow types — branded IDs, discriminated unions, exhaustive matches. They’re context for both your agents and your future self.

The pattern underneath all of this is the same bet I keep making across my AI Engineering practice: when machines do the producing, the leverage moves to whatever lets you verify at machine speed. Tests do it. Verifiable outcomes do it. And types — the oldest, most boring verification tool we have — turn out to be one of the sharpest tools in the agentic era.

The compiler was never the slow part. It was the part that was right.