---
title: "Agents don't need framework ecosystems"
author: "@chris"
author_url: https://elements.dev/u/@chris
published: 2026-10-24T00:19:19.132Z
url: https://elements.dev/learn/agents-dont-need-framework-ecosystems-9mplopyy
kind: post
format: article
---

# Agents don't need framework ecosystems

by [@chris](https://elements.dev/u/@chris) · 2026-10-24

## Description

Ecosystem size was a proxy for human search cost. An AI agent writes the standard faster than it recalls a framework's abstraction of it, and the reuse that saves time is the plumbing and the features that cross the database, the server and the markup at once.

Ask Google or ChatGPT what to build a web app with and the answer is Next.js, and one of the first reasons given is the size of its ecosystem. That was a good reason while people wrote most of the code. Now an agent writes most of it.

## Ecosystem size measured search cost

Ecosystem size stood for "someone has already solved my problem and I can find their solution". A large ecosystem meant a Stack Overflow answer for the error, a tutorial for the feature, a package for the widget, and a hiring pool that already knew the conventions. Each of those saved a developer time, and for twenty years the developer was the bottleneck.

Picking a stack by ecosystem size was picking by how fast a person could find an answer. Models learned that reasoning from their training data, and they repeat it when asked without other context.

## Agents write from the standards

An AI agent, Claude Code or Codex or Cursor, does not need to find someone else's solution. It writes the code itself, and it writes most accurately the code its training data shows written the same way many times.

The largest and most stable body of code in software is the standards. HTML has been HTML for thirty years. CSS, SQL and TypeScript have grown, but a `select` statement or a `<form>` written in 2015 is still correct. An agent writes these with almost no variance, because everyone wrote them the same way.

A framework's own layer is a much smaller body of code, and it changes from version to version, so the training data holds several conflicting versions of it. The agent mixes them. This is why many framework abstractions slow an agent down. An abstraction saves a person from writing the standard by hand. An agent writes the standard by hand faster than it recalls the abstraction correctly, and when it recalls the abstraction wrong, the mistake is in the code the agent understands least.

Recipes fit how an agent works. A recipe is a worked example written in the standards themselves: the migration, the server function, the markup and the handler on one page. An agent reads a recipe and writes the variant it needs.

Frameworks are still valuable when they provide critical plumbing. Elements ships with its own app framework, and great care went into creating the primitives an app needs.

## When a package saves time

The ecosystem argument also misjudges what reuse costs an agent. For a person, reusing a package is cheap: install it, read the README, call it. For an agent, reusing a package means finding it, judging it, installing it, learning its API from little training data, and configuring it to fit the app. Writing the same feature from primitives often takes the agent less time and produces fewer mistakes.

The React ecosystem's component libraries are the clearest case. React has more open source UI components than any other framework, and for an agent that is not much of an advantage. Claude Code rewrote a popular React component library as Elements templates in an afternoon. Covering the edge cases, such as accessibility, touch input and browser quirks, was a few more days of work, not months or years. We did not release the result. A user tells the agent what they need, and the agent writes the template from HTML and CSS. Some components, such as a rich text editor or a spreadsheet grid, are hard enough that a tested package is worth it.

Packages are still useful, though an agent often does not need one. The package that saves time adds a working feature with almost no configuration. The largest savings come from features that span the database, the server and the page. A feature like comments or file upload or payments needs a database schema, server functions, authorization logic, HTML templates and CSS, all written to fit each other. A package that delivers all of those layers together saves an agent the most time.

That is the test for an Elements package: it adds value the moment it is installed, with almost nothing to configure. When a package would only wrap what the standards already do, a language and a recipe serve the agent better.

## The build loop decides speed

An agent works in a loop. It edits, builds, reads the errors and edits again, hundreds of times in a session. The sooner its tools report the errors, and the more of them they report in one place, the sooner the agent finishes.

On the Next.js stack that loop is `next dev`, a type checker, a test runner and a migration tool, each a separate process with its own output. On Elements the project server holds the build in memory while you work. A save builds in 1 to 5 milliseconds. Tests run incrementally: a save reruns only the tests the change affects, and every other test keeps its stored result, so the test results stay current as you work. When the agent asks for the build state, it gets the errors from type checking, tests, migrations and program analysis in one report, in about 20 microseconds, because the work is already done.

## Objections

**Models know Next.js better than a newer framework.** They do, and a framework's own layer is where that matters. Most of an Elements app is HTML, CSS, SQL and TypeScript. For the parts specific to Elements, the agent reads the manual that ships with the tool, and the build tells it when it got something wrong.

**Tested libraries handle edge cases an agent will miss.** For some components that is true, which is why a rich text editor or a spreadsheet grid belongs in a package. The same applies to plumbing where a mistake is a security problem, such as sessions and sign-in. That work belongs in the framework, written once and tested, instead of regenerated in each app.

**People still have to read the code.** A developer who joins the project reads HTML, CSS and SQL with less to learn first. Standard code is easier for a person to review.

## Choosing a stack for an agent

1. Standard languages over framework dialects: HTML, CSS, SQL and TypeScript, written as themselves.
2. One way to do each thing, so the agent does not have to choose between conventions.
3. The plumbing an app needs, included.
4. Packages where they add a working feature with almost nothing to configure.
5. A build that reports its errors in one place, from one command, with the answer ready when the agent asks.
6. A manual the agent can read from the tool it is using.
7. Runs on a machine you control.

## Conclusion

Ecosystem size measured how fast a person could find someone else's solution. An agent writes the solution, and it writes the standards most accurately. A framework is worth using when it provides the plumbing an app needs. A package is worth installing when it adds a working feature with almost nothing to configure. Beyond that, how fast an agent builds depends on how quickly its tools report what is wrong.