The Case for Effect
I’m all in on Effect. Here’s why.
It’s not because of the type safety. It’s not because of the composability. It’s not because of the error handling. It’s not because it makes my code look clever, or because I enjoy learning new paradigms, or because functional programming makes me feel intellectually superior.
Those are all nice. But that’s not why I’m here.
The Thesis
I see very few timelines where three things don’t happen:
One: Effect becomes the primary application-level coding language for AI agents and agentic workflows.
Two: Every company goes agentic. (I go deeper on the mathematics of agent proliferation and why this is an arms race you can’t opt out of elsewhere.)
Three: The properties Effect provides by default turn out to be exactly what regulators are demanding from AI and autonomous systems. Same failure modes, different angle.
If this plays out, Effect becomes infrastructure.
But here’s the thing: you won’t be writing it.
The AI agents will.
Because AI agents are absolutely cracked at writing Effect.
Why Effect + AI Works
Effect is the closest thing we have to a NASA-grade runtime that runs full-stack—even in the browser.
It’s opinionated. It’s strict. It tells you immediately when something is wrong. Every error is typed. Every dependency is explicit. Every effect is tracked.
Most people see this as friction. They’re wrong. This is signal.
That constant negative feedback—the compiler yelling at you, the types not lining up, the missing services in your Layer—creates an unbelievably tight iteration loop for agents. They try something, they get instant feedback, they adjust. Try, feedback, adjust. Hundreds of times per minute.
And there’s another reason agents thrive with Effect: it’s the missing standard library. Queues, pub/sub, streams, retries, scheduling, state machines—all the primitives you need to build real systems, already there. An agent that knows Effect has everything it needs to build whatever you throw at it.
Why Build Agents in Effect
Most agent frameworks run on Python. Fine for demos.
TypeScript’s better—runs on the server, runs in the browser, actual type safety. But vanilla TS still has gaps: error handling is an afterthought, async is a minefield, dependencies are implicit. You’re one uncaught promise rejection away from a silent failure.
Effect fills those gaps. And when your agent is making real decisions—billing customers, moving money, triaging patients—those gaps matter.
What happens when an agent crashes mid-operation? What happens when it double-bills someone? What happens when you’re staring at logs at 3am trying to figure out what decision led here?
Effect answers these:
- Interruption. Kill a runaway agent, clean up resources, no zombies.
- Typed errors. Know how your agent can fail before it ships.
- Tracing. See exactly what decisions led where.
- Structured concurrency. Parallel tasks that don’t leak or deadlock.
The difference isn’t academic. It’s whether you sleep through the night.
I go deeper on Effect as an agent runtime—the full comparison with Python frameworks and why the gap widens as stakes increase.
Why Regulators Will Love Effect
The same properties that make Effect great for AI development are exactly what regulators demand from AI systems.
Think about what legislators worry about with autonomous systems:
- Unpredictable failures. Systems that fail in ways no one anticipated.
- Hidden dependencies. Black boxes that nobody can audit.
- Untraceable decisions. “The AI decided” with no explanation of how or why.
- Silent errors. Failures that propagate invisibly until catastrophe.
Now look at what Effect provides by default:
| Regulatory Concern | Effect’s Answer | Example Regulation |
|---|---|---|
| Unpredictable failures | Typed errors—every failure mode in the type signature | NIST AI RMF — “valid and reliable” |
| Hidden dependencies | Explicit requirements—every dependency visible | EU AI Act Art. 12 — “automatic recording of events” |
| Untraceable decisions | Effect tracking—every operation inspectable | GDPR Art. 22 — “not subject to… solely automated processing” |
| Silent errors | Compile-time enforcement—can’t forget to handle | SOC2 CC7.1 — “monitor system components” |
| Uncontrollable behavior | Interruption & scopes—built-in cancellation | HIPAA §164.312 — “access only to authorized persons” |
This isn’t a coincidence. Effect was designed to make software more reliable. Regulators want AI systems to be more reliable. They’re trying to prevent the same failure modes.
I go deeper on Effect as Compliance Infrastructure—how these patterns map across jurisdictions.
Effect isn’t just a productivity choice. It’s becoming a defensive choice for compliance.
The Bet
In five years, every production TypeScript codebase will either be Effect or wish it was.
I could be wrong.
I don’t think I am.