I was at a conference recently and watched Joel Hooks talk about Effect. Effect homepage h1 advertises that it's the "Reliable TypeScript for the A...
For further actions, you may consider blocking this person and/or reporting abuse
You badly need to checkout Hyperlambda - It takes your idea to the extreme, and instead of replacing libs, it replaces the entire programming language ... ;)
Oh wow I'll check it out!
I’ve found the best agent-friendly libs are the ones that make the wrong thing hard to write. But if I can’t debug the generated code six months later, that tradeoff gets ugly fast.
What do you think? Do you choose libraries because how well your AI Agent works with them? Or not?
The loop in your diagram closes for
describeErrorand stays open everywhere else, and the difference is worth naming because it decides how much the compiler is actually buying you. Exhaustiveness fires because that particular consumer switches on_tagand ends inassertNever. A real program has more consumers of the same error channel — retry policy, log level, HTTP status mapping, whether the thing even pages someone — and the ones written asif (error._tag === 'RateLimitError')type-check perfectly after an agent addsMaintenanceError. The new error just quietly lands in whatever the else branch already did.So the property is narrower than "the type system catches the omission": it is "the type system catches omissions in consumers that were written exhaustively", and nothing in the type system tells you which of yours are. The check is grep-shaped rather than compiler-shaped — find every
_tag ===comparison and everyswitchon_tagthat has nonever-typed default, because each one is a place where adding an error picks a default behavior for you instead of asking.That also sharpens the tradeoff in your table. The cost of Effect is a new programming model, and the benefit is real but it is bounded by a convention you have to keep enforcing by hand, which is the same class of thing you were trying to move out of tribal knowledge in the first place.
Agent legibility is becoming a real selection criterion, but the maintainability question should include failure ownership. A library that makes invalid states unrepresentable gives both humans and agents a correction signal. If only the agent understands the abstraction, the team may gain compile-time safety while losing incident-time comprehension.
the selection criterion shift is real but id add a second pressure point: upgrade risk. when an AI generates Effect code confidently at version X, a major version bump that changes error channel shapes can silently break the agents assumptions before it breaks your runtime. we hit this with another heavily typed library — the agent kept generating patterns from training data that were a full version behind.
the question then is not just "can the agent write it well now" but "can the agent stay current with it." libraries with stable APIs and explicit error contracts score better on both.
did the agent handle Effects error union types cleanly, or is that where it started reaching for older patterns?
This selection pressure is real and it's already showing up in library design, just under friendlier names: typed errors, machine-readable schemas, exhaustive pattern matching. All three are "harder for humans to learn, legible for agents". The metric I'd watch is the error message. A library whose failures produce precise, structured output gets debugged by an agent in one round trip; a library that throws "something went wrong" sends the agent off hallucinating about your config. In a couple of years "how good are the errors" will be a line people check in the README the way "good docs" is now, because the reader of the error is increasingly not a person. The awkward part: those two audiences want opposite things from a quickstart, so docs are going to fork.
What criteria 🤔 should developers prioritize when selecting AI-optimized libraries?