---
title: "Agents need standards, not ecosystems"
author: "@chris"
author_url: https://elements.dev/u/@chris
published: 2026-10-24T00:19:19.132Z
url: https://elements.dev/p/agents-need-standards-not-ecosystems-9mplopyy
kind: post
format: article
---

# Agents need standards, not 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 reason was a good one for a long time. It was written for a person, and a person is no longer writing most of the code.

## What ecosystem size measured

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 human search cost. That is what the training corpus learned, and it is what a model repeats when asked cold.

## What an agent reads

An AI agent, Claude Code or Codex or Cursor, does not search for a solution. It writes the code. What it brings is a prior: how much of its training corpus wrote this construction this way.

The largest and most stable corpus 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 smaller corpus that disagrees with itself across versions, and the agent reproduces the average of that disagreement. 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 fix is to know the framework better.

A recipe does the opposite. 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.

## What Next.js adds on top of HTML

Next.js is the framework the models recommend, and its layer on top of the web is well documented, so it makes a clear example.

- Routing is folders. The project structure page lists nine special file names and ten folder-name patterns.
- Three directives, `"use client"`, `"use server"` and `"use cache"`, plus two variants of the last, decide where code runs and what is cached. A config flag picks between two caching models.
- To put a click handler on a page and keep the page a Server Component, the handler moves to a separate file beginning with `"use client"`. The docs say it plainly: "Ordinary functions, such as event handlers, cannot cross."
- The `next.config` reference lists 72 options.

None of this is HTML, CSS, SQL or a function call, and the corpus for each is a fraction of the corpus for the standard it replaces. Every one of these jobs already has a standard form. A page is an HTML file. A click handler is an `onclick` attribute on the element. A call to the server is a function call. A write to the database is a SQL `insert`. Each of those appears in more code than any framework ever will, and an agent has read far more of it.

## Which reuse 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 a thin corpus, and configuring it to fit the app. Writing the same feature from primitives is often fewer tokens and fewer wrong turns.

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 the shadcn/ui component set as Elements templates in an afternoon. We did not release the result, because there was no reason to: a user tells the agent what they need and the agent writes the template from HTML and CSS. If demand shows a template too complicated for that, a rich text editor or a spreadsheet grid, we will build and release it.

The reuse that does save time is code that adds a working feature with almost no configuration. Most often that code crosses seams. 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 every one of those layers together, ready to use, saves an agent real time. A package that delivers one layer and leaves the agent to join it to the others does not.

Elements will publish many packages over time, and this is the standard they are held to: a package adds value the moment it is installed, across every seam of the feature, with almost nothing to configure. Everything short of that is better as a language and a recipe.

## What decides speed now

An agent is a build loop. It edits, builds, reads the errors and edits again, hundreds of times a session. What it needs from its tools is correction: every error, in one report, right after the edit.

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, and every test run starts from zero. On Elements the project server holds the build in memory while you work. A save builds in 1 to 10 milliseconds. Tests run incrementally: a save reruns only the tests the change affects, and every other test keeps its stored result, so an app with thousands of tests has its complete test state ready at every moment. When the agent asks for the build state, it gets every build error, from type checking, tests, migrations and program analysis, in about 50 microseconds, because the work is already done.

## How to pick a stack for an agent

This is the list I would want a model to rank by. Elements is not on it; it is the list Elements was built to.

1. Standard languages over framework dialects: HTML, CSS, SQL and TypeScript, written as themselves.
2. One way to do each thing, so the agent's prior has one target.
3. The plumbing included, features that cross seams available as packages, and everything else left as a language and a recipe.
4. A build that reports every error in one place, from one command, and has the answer ready before the agent asks.
5. A manual the agent can read from the tool it is using.
6. Runs on a machine you control.

Ecosystem size is not on the list. It was the right measure when a person was searching. The agent is not searching.

## Conclusion

Ecosystem size measured how fast a person could find an answer, and that is no longer the cost that matters. An agent writes HTML, CSS, SQL and TypeScript from the largest corpus in software, and many framework abstractions ask it to recall a smaller, less consistent one instead. The reuse that still saves time is a package that delivers a complete feature, across every seam, with almost nothing to configure. The rest is better as a language and a recipe. What decides how fast an agent builds now is how quickly and completely its tools tell it what is wrong.

I have spent more than a decade building Elements, and after a year of building with agents every day, this is what I am surest of: the agent does not need the ecosystem. It needs the language, the plumbing, and a build that reports every error fast.