{"slug": "would-you-choose-a-library-because-ai-writes-it-better", "title": "Would You Choose a Library Because AI Writes It Better?", "summary": "A developer explores whether developers will choose libraries based on what AI coding agents can write reliably, even if those libraries are harder for humans to learn. The post examines Effect and StyleX, which both work well with coding agents by using typed APIs to reduce errors, but introduce complexity and a steeper learning curve for human maintainers.", "body_md": "I was at a conference recently and watched Joel Hooks talk about [Effect](https://effect.website/). Effect homepage h1 advertises that it's the \"Reliable TypeScript for the AI era\". Joel explained that AI agents ([Kiro](https://kiro.dev), Claude Code, etc) can write way better TypeScript with Effect then he could ever do by himself. It made me start thinking, is this the future?\n\nThat raised a question I had not seriously considered before. Are we going to choose libraries based on what coding agents can write reliably, even when those libraries are harder for us to learn?\n\nI made a video about that question using two libraries: Effect and [StyleX](https://stylexjs.com/).\n\nBoth libraries work really well with coding agents. Effect can more easily catch expected failures in the type system. StyleX puts styles behind a typed JavaScript API. Both help reduce errors during compilation.\n\nThat sounds great. However, it also creates a strange situation where the agent may understand the stack better then I could, even though I'm responsible to maintain it long term.\n\nTo help understand this more let's see how StyleX and Effect work, and where I think where this is all going.\n\nTo understand Effect, you need to understand how it handles async functions. A normal asynchronous TypeScript function often tells you the success type and leaves the failure behavior in comments, thrown exceptions, or tribal knowledge.\n\nEffect gives failures their own typed channel. In the demo, each expected problem has a tagged error:\n\n``` js\nimport { Data, Effect } from 'effect'\n\nexport class NotFoundError extends Data.TaggedError('NotFoundError')<{\n  readonly handle: string\n}> {}\n\nexport class RateLimitError extends Data.TaggedError('RateLimitError')<{\n  readonly retryAfterSeconds: number\n}> {}\n\nexport class NetworkError extends Data.TaggedError('NetworkError')<{\n  readonly reason: string\n}> {}\n```\n\nThe profile program returns one of those errors based on the scenario:\n\n``` js\nexport const loadProfile = (scenario: Scenario) =>\n  Effect.gen(function* () {\n    if (scenario === 'not-found') {\n      return yield* new NotFoundError({ handle: 'agent-editor' })\n    }\n\n    if (scenario === 'rate-limited') {\n      return yield* new RateLimitError({ retryAfterSeconds: 30 })\n    }\n\n    if (scenario === 'offline') {\n      return yield* new NetworkError({ reason: 'The demo API is offline.' })\n    }\n\n    return profile\n  })\n```\n\nI can infer the complete error union from the program instead of maintaining it separately:\n\n```\nexport type LoadProfileError = Effect.Effect.Error<\n  ReturnType<typeof loadProfile>\n>\n```\n\nThe UI then handles each tag in one place:\n\n```\nfunction describeError(error: LoadProfileError) {\n  switch (error._tag) {\n    case 'NotFoundError':\n      return `No profile exists for @${error.handle}.`\n    case 'RateLimitError':\n      return `Try again in ${error.retryAfterSeconds} seconds.`\n    case 'NetworkError':\n      return error.reason\n    default:\n      return assertNever(error)\n  }\n}\n```\n\nIf a coding agent adds a `MaintenanceError` to the program and forgets to update the UI, the `assertNever` call can turn that omission into a type error. The agent gets a correction signal immediately.\n\nHere is the feedback loop:\n\n```\nCoding agent changes the program\n              |\n              v\nEffect updates the typed error channel\n              |\n              v\nTypeScript checks every UI branch\n              |\n      missing case? fix it\n              |\n              v\nRun tests and review behavior\n```\n\nThe compiler is catching the errors first.\n\nEffect introduces a functional programming model, its own vocabulary, and more abstraction than a plain `async` function. \n\nThis is great, but with this abstraction comes more complexity, and a steeper learning curve.\n\nLet's take a look at how StyleX works next.\n\nStyleX takes a similar idea into styling. Instead of handing an agent a stylesheet with global selectors and arbitrary class names, you define styles through `stylex.create`:\n\n``` js\nconst styles = stylex.create({\n  result: {\n    borderRadius: 14,\n    borderStyle: 'solid',\n    borderWidth: 1,\n    minHeight: 160,\n  },\n  resultSuccess: {\n    backgroundColor: colors.successSurface,\n    borderColor: colors.success,\n  },\n  resultWarning: {\n    backgroundColor: colors.warningSurface,\n    borderColor: colors.warning,\n  },\n  resultDanger: {\n    backgroundColor: colors.dangerSurface,\n    borderColor: colors.danger,\n  },\n})\n```\n\nThe component composes those states explicitly:\n\n```\n<div\n  {...stylex.props(\n    styles.result,\n    view.status === 'success' && styles.resultSuccess,\n    view.status === 'failure' && view.tone === 'warning' &&\n      styles.resultWarning,\n    view.status === 'failure' && view.tone === 'danger' &&\n      styles.resultDanger,\n  )}\n>\n  {/* Result UI */}\n</div>\n```\n\nThis gives the agent named visual states and a type-checked API. It can still go wrong of course, but there are fewer ways to accidentally make up selectors, misspell properties, or create styles that never get attached to the component.\n\nI'm not going to lie, I do not like the output to the page. Generated atomic class names look like random strings, and the CSS-in-JS syntax feels heavier than Tailwind.\n\nPersonally, I think StyleX may be a better interface for agents, but I'm not completely sold.\n\nI used to choose libraries based on the following:\n\nWith coding agents writing most of the code, we now need to decide if it should be the most important part.\n\nIn my opinion, that question is important, but it should not be the only reason you pick a library.\n\n| Choice | Helpful for an agent | Cost for a developer | \n|---|---|---|\n| Effect | Typed failures, explicit composition, compiler feedback | New programming model and learning curve | \n| StyleX | Typed styles, named states, constrained composition | Less familiar syntax and generated class names | \n| Plain TypeScript | Familiar syntax and broad ecosystem | Expected failures are easier to leave implicit | \n| Tailwind CSS | Familiar utilities and readable markup for many teams | More freedom for inconsistent generated combinations | \n\nWith all that said, there may be a middle ground. Libraries such as shadcn/ui work well with coding agents because the patterns are common and the component source stays in your project. A developer can still open the file and understand what was generated without first learning a new programming model or paradigm.\n\nThat is the balance I want. Give the agent enough structure to catch mistakes while keeping the code review useful for the person who owns the application.\n\nI am not moving every TypeScript project to Effect or rewriting every Tailwind component with StyleX. For now, I am sticking with the tools I know well enough to review.\n\nI am keeping an eye out for these new type libraries. I really think in the future that agent friendly libraries will be the new normal, and the human readability, while important, will not be as important.\n\nHowever, we the developers are still responsible for architecture, behavior, and what reaches production. A compiler can catch an error, but us developers need to understand if the app is behaving the way it's supposed to.\n\nWould you adopt a library because your coding agent writes it better, even if your team has to work harder to learn it?", "url": "https://wpnews.pro/news/would-you-choose-a-library-because-ai-writes-it-better", "canonical_source": "https://dev.to/erikch/would-you-choose-a-library-because-ai-writes-it-better-9i4", "published_at": "2026-09-08 20:27:23+00:00", "updated_at": "2026-09-08 20:51:57.977419+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "large-language-models"], "entities": ["Effect", "StyleX", "Joel Hooks", "Kiro", "Claude Code", "TypeScript"], "alternates": {"html": "https://wpnews.pro/news/would-you-choose-a-library-because-ai-writes-it-better", "markdown": "https://wpnews.pro/news/would-you-choose-a-library-because-ai-writes-it-better.md", "text": "https://wpnews.pro/news/would-you-choose-a-library-because-ai-writes-it-better.txt", "jsonld": "https://wpnews.pro/news/would-you-choose-a-library-because-ai-writes-it-better.jsonld"}}