Open Source Is Rocket Fuel for AI Agents

Dependencies don’t fully meet my needs and come with a maintenance cost. Today, agents can redevelop an entire lib in one session. Once they own the code, they can adapt it to our needs. So why not just stop using libraries altogether?

A random developer on the Internet, 2026

I hear this argument more and more, but my intuition, and that of my colleagues, points in the opposite direction. We believe that a good open-source library with solid documentation can save us tokens, time, and therefore money. It can also lead to more polished and secure features.

But maybe we’re wrong? To find out for sure, I built the same application with and without dependencies, and compared the results.

The Same Admin, Built Three Times

I started by developing a REST API based on open data of rocket launches, space events and crewed spaceflights. Then, I wrote a Markdown specification describing a back-office for this API with nine features, ranging from a paginated list to adding a complete resource, including references, many-to-many relationships, server filters, a dashboard, a calendar, and batch actions.

Next, I created 3 Claude Code sessions, each pointed at the same specification but with a different bootstrap variant. The three variants are:

• from-scratch: Built with React and Vite, without a framework or design system
• shadcn-ui: Built with shadcn/ui to produce a more polished UI, closer to a production-ready interface
• react-admin: Built with react-admin, Marmelab’s open-source admin framework, built on MUI, react-router, TanStack Query, and react-hook-form

Each variant runs in an agent session that is kept active from one step to the next. An orchestrator sends one prompt per turn and records the tokens and time for that turn. To avoid being influenced by the results of a single model, I reran the entire process using two models: Claude Sonnet, followed by Claude Opus 4.8.

Disclaimer: We’re the maintainers of React Admin. One of the three variants is therefore our own project, and you have every right to be wary of bias. I locked down the protocol before the first measurement, kept the prompts identical, and published the raw data in a GitHub repository (marmelab/comparator-admin) so you can compare them for yourselves.

It’s Not the Library, It’s Which Library

Here is the number of tokens used to build the entire application:

These results are surprising: the number of tokens doesn’t depend on whether the application is built from scratch or with a library, but rather on the library itself: with Shadcn/ui, Claude uses more tokens than when building from scratch, while react-admin uses fewer tokens than both. The same pattern holds true for both Sonnet and Opus.

Let’s check the generated admins to understand why.

The from-scratch version is functional but rough around the edges. It lacks a design system, so the result is not very pretty and probably not production-ready. The model had to write all the components and logic from scratch, which explains the high token count.

The shadcn-ui version is more polished, but it’s also the most resource-intensive. Rather than a library that goes under node_modules, Shadcn/ui generates components directly in the project. This means Claude had to read and understand all the generated code, which increases the token count. It also had to implement the routing and form logic by hand, just like the from-scratch model. So it makes sense that the token count is higher than for the from-scratch version.

The react-admin version leverages the MUI design system to deliver a polished interface without a single line of styling code. It also uses react-admin’s built-in routing, form, and data management logic. The model only had to write the business logic and the configuration of the components, which explains why it used fewer tokens than the other two variants.

Why a Good Library Shrinks the Token Bill

So some libraries increase the token count, while others decrease it. Why is that? The answer lies in the library’s design and how it encapsulates complexity.

For example, react-admin’s <ReferenceInput /> renders an autocomplete input letting the user choose a reference record (e.g., the launchpad for a launch). It costs about 6 tokens with Claude Opus. Yet the component itself is 98 lines of code long plus 305 lines of code for the headless logic plus 1,300 lines of code of MUI <Autocomplete> plus… you get the point. Using a low-code library allows us to encapsulate hundreds of lines of code that the model no longer has to read, write, or debug.

It also helps that react-admin is a good fit for my application. Claude Code didn’t have to write the pagination, the reference resolution, or the form state management. It simply invoked components that account for very few tokens.

How did Claude know how to use these components? First, because it’s popular and well-documented, react-admin is already in the model’s training data. Second, Claude can access the react-admin documentation via RAG (Retrieval-Augmented Generation) because I use the Context7 MCP server. The literature supports this approach. A 2025 study by Jingyi Chen et al. shows that connecting a library’s documentation to the LLM via RAG improves code generation by 83% to 220% for lesser-known libraries.

Fun fact: My first react-admin run was executed without the Context7 plugin. The model fell back to WebFetch requests to the react-admin documentation. The react-admin variant then proved slower than the from-scratch implementation. Once Context7 access was enabled and we re-ran the three variants, the ranking based on time was reversed. That’s an important lesson: choose a library that provides documentation the model can read. And don’t let the model choose the library, as it tends to make poor choices, achieving only 38.8% precision.

The Hidden Cost of Code the Agent Wrote Itself

I’m not saying you should never write custom code to meet your needs. For a micro-dependency like the famous 11-line left-pad, whether to include a dependency was debatable long before AI. In some cases, it’s actually smarter to rewrite the code yourself. But this custom code comes with bugs and security vulnerabilities that an automated model review doesn’t always catch. And even though you and your teammates have reviewed this code, it’s not always enough to catch all the issues.

On the other hand, popular open-source libraries have been tested by thousands of developers. They have been used in production for years, their maintainers have fixed many bugs and security vulnerabilities, and they publish updates regularly. Just count the number of closed issues on a popular open-source library and ask yourself how many of those issues you would have found on your own.

This is especially true for frameworks, which guide the model toward best practices and are designed to be extended and customized. They provide a solid foundation so that developers can focus on the unique features that differentiate their product.

So before unleashing an LLM on a project, consider whether an existing library can meet your needs. If it can, tell the model to use it.

Tip: Failing to specify a particular library may cause the LLM to install a library on its own. And it’s important to note that recent models (2026) still hallucinate package names. Attackers are already exploiting this predictability. Slopsquatting involves registering package names that AI systems hallucinate on npm or PyPI, then lying in wait. Typosquatting relies on human typos; slopsquatting relies on machine errors.

Open Source Is Simply Cheaper

The benchmark shows that using a well-designed library can reduce both the number of tokens and the time it takes to build an application. If you’re using a model that charges by the token, this translates into a direct cost reduction.

Here is the projected cost of building the same application with the three variants, based on the current pricing of Claude Sonnet:

These savings add up. Each time an agent uses a well-equipped framework, it therefore weighs less heavily on the AI bill. Open source lowers the price you pay to have an AI write your code, and this benefit grows as agent usage increases. And even if you’re on a subscription plan, reducing the number of tokens used by your agents can help you stay within your plan’s limits.

The more features your agent codes without a library, the faster the context fills up in future sessions. Productivity decreases and costs rise as the project grows. Using a library can help you avoid this problem and keep a constant velocity. The savings of open source accumulate over time.

AI Lives on Open Source

So open-source makes development cheaper, both for real developers and for agents. But the difficult truth is that while the open-source economy had reached a delicate balance when it was used only by developers, it is now threatened by the rise of AI.

The maintainers of open-source libraries are struggling to make a living, and the revenue streams that support them are disappearing. When a developer’s agent uses open-source components, no one visits the documentation, posts on the forum, or clicks the sponsorship button anymore (cf. Vibe Coding Kills Open Source by Miklos Koren et al., 2026).

The Tailwind CSS case puts a face on this mechanism. In January 2026, traffic to its documentation dropped by about 40% while usage tripled, resulting in an approximately 80% decline in revenue. Layoffs were the logical consequence.

On Stack Overflow, the volume of questions fell from nearly 200,000 per month in 2014 to a few thousand by the end of 2025, taking its ad revenue down with it.

The problem, then, goes beyond the maintainers alone. A model learns from code in repositories, documentation, and public questions. Saving open source becomes a shared interest, including for those who build AI systems.

GitHub, OpenAI and Anthropic know it, and they offer free subscriptions to open-source maintainers for Copilot, Codex, and Claude Code. As open-source maintainers, we benefit from this. But this is not enough. The open-source ecosystem is fragile, and it needs more than goodwill to survive.

Conclusion

Based on this experience, I recommend building on solid foundations and existing libraries as soon as a project moves beyond a disposable prototype. This is less costly in terms of tokens and yields more reliable results. We apply this advice to our own products: Atomic CRM, our open-source CRM, is built on react-admin.

At Marmelab, we continue to publish and maintain open-source projects, with react-admin and Atomic CRM at the forefront. It is our way of nurturing the ground on which AI learns, and it reflects our own desire to keep the open-source ecosystem thriving.

The bottom line remains: AI codes well because it learns from many open-source tools. If we let this system collapse, for lack of funding and recognition, we would be breaking the very tool we claim to be improving.

I’d like to open the debate rather than close it: how do we give credit to and compensate maintainers when AI stands between them and us?

We were unable to confirm your registration.

Your registration is confirmed.

Keep up to date

Join our react-admin newsletter for regular updates. No spam ever.

Subscribe