The age of token efficiency, the age of libraries

Not so long ago, six months, perhaps, I was seriously convinced that AI would not replace us, the programmers. It would just help us; it would be our assistant. Back then I was mostly firing off one-off prompts in ChatGPT to help me with the odd algorithm, but to my delight, I still hand-crafted nearly all of my code.

Six months later, I’m not sure I can do my daily job without Claude. And I’m not alone: 84% of developers now use or plan to use AI tools, and as far back as February 2023 GitHub was already measuring 46% of the code in Copilot-enabled files as AI-generated, with its CEO predicting 80% “sooner than later”.

I got to test this against real people recently at DevBcn, where we were presenting GolemUI. I made a point of asking every single developer who stopped by our booth how they were using AI.

My deeply unscientific poll, around fifty developers from different companies and different parts of the world, yielded some genuinely scary uniformity. They basically all said the same thing:

This lines up with Gartner’s prediction that by 2028, 90% of enterprise software engineers will use AI code assistants, up from under 14% in early 2024, with the developer’s role shifting from implementation to orchestration.

Not sure about you, but for me, after almost 30 years of writing software (yes, I’m old!), this is a little sad. Though I’m afraid it’s only sad because it means the industry is going through some major changes, and we humans don’t like change. So I, for one, would like to stay positive and believe this might turn out to be good, hopefully in the long run.

Will it? The answer probably depends on your favourite AI YouTuber.

But for you and me, the people working in this industry right now, where does this leave us today, not in five years?

Companies are starting to move on from all-you-can-eat tokens to something far more metered and corporate. Gartner forecasts worldwide AI spending to hit $2.5 trillion in 2026, up 44% in a single year. Most of that is infrastructure rather than your token bill, but it is exactly the kind of number that makes finance departments start asking questions further down the chain. And “all-you-can-eat” quietly becomes:

We are about to enter a world of wild metrics, built around two numbers:

• Token cost per feature.
• Trust % in the code generated.

The first one you can at least put on a dashboard, even if nobody will ever agree on what a “feature” is. The second one is the real trouble: trust is basically unmeasurable from inside your own walls. You can only measure trust in code if you know the area better than the AI does, and nowadays that tends to happen only if you are an industry expert in it.

Trust is, in my opinion, the elephant in the room of modern AI. Let me circle back to something I said at the beginning:

“I’m not sure I can do my daily job without Claude”

That line deserves more nuance. Yes, I depend on Claude to help me, but whether I can trust what it does comes down to one question: am I an industry expert in the area it is working on? That question splits my work in two, based on whether I care HOW something is done versus WHAT it achieves:

• My core purpose: the thing my business actually delivers, the area where I am the expert. There I care about the HOW as much as the WHAT.
• Everywhere else, I am not the expert, and I mostly care about the WHAT.

Basically, when working with GolemUI source code, I know I have the upper hand. I ask Claude to help me, but Claude is mostly a subordinate that reports to me.

Now, when I have to update our website, I care mostly about the WHAT. The website matters, but it is not my core purpose, and nobody is expecting me to be an expert in marketing sites.

The trust problem lives in that second bucket. With AI, you can code areas of the app you would never have been able to touch before, areas where nobody would call you an industry expert, so how are you supposed to trust something you don’t fully understand?

I’m sure you have your own secret sauce, where you spawn a new session, tell it to be “the backend architect,” and have it review such and such. But that ultimately lands in the same spot. And this is how a time bomb gets planted: code you cannot fully judge, shipped because it seems to work, ticking away in a corner of your app you would rather not open.

And the numbers say you’re not imagining it. In the 2025 Stack Overflow Developer Survey, adoption is up and trust is down, in the very same survey:

Hopefully, I’m driving home two key points that I think sit at the core of most senior developers’ anxiety nowadays: how are we going to prove we’re using our tokens efficiently, and how can we prove we can trust what we’re building.

If you agree with the trust premise, this is where it leaves you: unless you are able to verify all the code you ship, you are basically playing the lottery. Maybe nothing ever goes wrong. Or maybe it does.

And bombs are already going off. Days after its January 2026 launch, Moltbook, the vibe-coded social network for AI agents, was found wide open: its database key sat in client-side JavaScript with Row Level Security never switched on, and researchers at the cloud-security firm Wiz could read and write the entire production database, 1.5 million API tokens included.

I think this will resonate with you: nowadays AI has removed the traditional frontiers that shaped what each professional could do. You can develop an app end to end, and the AI will build both what you could build before, but faster, and even what you could not build before.

But who is responsible AND accountable for the bugs now? This used to be a trivial question: the developers who added the bugs were responsible for fixing them, and the company/org that shipped them was accountable.

Andrej Karpathy, the ex-OpenAI and Tesla AI lead who coined the term “vibe coding” in the first place, answers that nothing has changed. He now splits the practice in two, vibe coding raises the floor, agentic engineering raises the ceiling, but on accountability he does not move an inch:

“You are still responsible for your software, just as before.”

Simon Willison, co-creator of Django and one of the most read voices on AI-assisted development, has been wrestling with the same question in public, and he is less categorical. He used to draw a clean line between vibe coding, where you prompt, accept and ship without ever reading the code, and responsible engineering, where you review, test and understand everything you ship. By May 2026 he admits the line is blurring in his own practice: as the agents get more reliable, he isn’t reviewing every line anymore. But one thing still bothers him:

Let me paint a picture, and let’s see if it feels familiar. Aiden is a senior UI developer, building an app end to end for his company: a financial app, where he has to put together a summary of sales and revenue.

Aiden is not that strong in DB/backend, etc. His UI specs are strict; for the non-UI he leans on the well-known AI technique of asking, every so often in the session:

“Are you sure this is the right implementation/spec?”

I’m sure you’ve been there. Now, one of Aiden’s time bombs goes off: there is a critical bug in an area that he has fully vibe coded.

Let’s imagine it’s around grids: the AI has built its own grid from scratch, and it’s kind of spiralling down. There are bugs that are hard to replicate (the grid passes its tests, of course; these are the other kind of bugs), and Aiden hasn’t got a single clue what’s in that code… Most people who have worked with grids will tell him:

“Aiden, working with grids can become quite complicated. I think you should just get rid of all that code and tell Claude to use [insert your favorite grid library here].”

You could object that the grid IS the app, it’s the thing on screen. But look at what Aiden’s business side actually asked for: a correct summary of sales and revenue. That’s the WHAT, and it’s the only thing anyone will hold him accountable for. The grid is pure HOW, and Aiden fell on the AI trap.

So the key question here transcends grids. Should Aiden spend tokens on grids, charts, forms, validations…? I believe there are two schools of thought:

• Yes! With AI you can now build your own bespoke, fully tailored app and have it exactly the way you want it.
• No! Invest heavily in your stack, find the best libraries for your use case, and let THEM spend the tokens.

Our bet is on the second school. After everything we have said, we believe that not considering which libraries you will use from the very beginning, and letting your AI agent just start building from scratch, is a total error. The real cost of those parts is not in writing them, but in maintaining them, in trusting them. That is why you need to delegate your tokens, indirectly, to other industry experts who can build reliable software parts that you can safely reuse.

And this is where the accountability question from the previous section finally gets an answer. When the bug is in a library you bought, there is someone to file the ticket against: a changelog, a support contract, a team whose reputation depends on fixing it.

That is what trust looks like when you can’t build it yourself, and it’s why we said trust is unmeasurable “from inside your own walls”. You can’t measure your trust in code nobody on your team understands. But you can buy trust from a team whose core purpose that code is.

I can hear the objection already: if AI collapsed the cost of writing the code, surely it collapsed the cost of owning it too? Just point Claude at the bug! I’m sure you’ve tried it: you paste the stack trace, the AI apologises beautifully, rewrites half the grid, and the tests go green again.

But go back to the trust question. A fix you cannot judge, in code nobody on your team understands, is not maintenance; it’s another spin of the roulette wheel. And when the bug comes back wearing a different hat, who do you escalate to?

Your vibe-coded grid has no changelog, no support contract, and no team whose reputation depends on it. AI makes touching the code cheap; it does not make answering for it cheap.

And it’s not just my hunch. GitClear, who make a living measuring code quality, analysed 623 million code changes between 2023 and mid-2026 and the trend lines all point the same way: code duplication is at record levels, up 81% since 2023; developers are now about five times more likely to copy-paste a block than to refactor one; and the share of changes that maintain older code has collapsed by 74%. We are writing code faster than ever and looking after it less than ever.

Now, I am not going to pretend we know which school will prevail, and if someone tells you they know, well, ask them for the lottery numbers next.

One side of the coin we have not yet made obvious is what happens to popular libraries now that AI is around. Let me propose an experiment: pick one of the big, professionally maintained ones, say AG Grid, or Highcharts, and have a look at its release history over the last few years… Are you noticing something?

I went and pulled the numbers, my second deeply unscientific poll, though this one straight from the npm registry and GitHub. To be fair, release counts are a rough proxy, cadence is partly a policy choice, and the pattern doesn’t hold everywhere: it shows up in the libraries with dedicated expert teams, much less in community-run ones. But that split is itself the point. Zooming out, Octoverse shows the whole ecosystem shipping faster than ever:

This is the stance we believe library maintainers will have to adopt in the AI environment: fully onboard AI, and at the same time be the gatekeepers of excellence in their areas. In-house experts who care about the HOW detect, remove and prevent the negative multipliers; a feature request that used to wait months now ships in days. And an ecosystem of apps built on such libraries is emerging: you spend most of your tokens on your core purpose, and you ask your AI to lean on these libraries everywhere else, precisely so you do not plant another time bomb.

There’s one more force pushing the same direction: your AI is dangerously good at writing bespoke code, and surprisingly bad at fast-moving APIs. Every LLM has a training cutoff, and it will happily hallucinate a prop that was renamed two majors ago.

Which means the libraries that win this age won’t just be well-maintained; they’ll be legible to agents . Docs shipped as llms.txt, an MCP server that answers API questions against the version you actually installed, typed interfaces strict enough that the generated code fails fast instead of failing in production.

Put together, this is our bet: professionally maintained, agent-legible libraries become the cornerstone of effective token cost per feature (the token money gets delegated) and a shop where you can buy trust (the accountability gets delegated too).

Which finally loops back to our original two metrics, and to how you minimise them: delegate them as much as possible. Only let your AI dictate the shape of the code when that code is your core purpose, and you have in-house experts who care about the HOW and treat AI as an assistant, not as a magic box.

Hopefully our AI vision is clear by now, though note that we are not trying to convince anyone! It is impossible to know what the future of AI holds. But this is our bet, and if you, like us, think this is the way it’s going to be, well, let us present our library, golemui.com. Forms are our core purpose: we spend our tokens on the HOW so that you only have to spend yours on the WHAT.

To be clear about where all of this applies: the software that is the core of your business. Remember our website? With a team of three we do not have the resources to do everything, so we fully rely on AI there, and for parts like that, it is fine. What should never be the case is doing the same with the core parts of your business. Ours is the forms library code, and there, Claude is the subordinate.

And forms are a perfect example of everything we’ve discussed. Every app has them, and they look simple on day one: a few inputs, a submit button. Then come the validations, the fields that depend on other fields, the dynamic options, the multi-step flows…

We also practice what this post preaches about being legible to agents: GolemUI is AI-ready from day zero, grounded through its MCP server so your AI builds against the version you actually installed. In our benchmark, three Claude models matched the mainstream stacks on correctness while writing about a third of the code. A third of the code is a third of the tokens, and a lot less HOW for you to trust.

And behind it there’s a team you can file the ticket against: three of us, with more than 50 years of combined experience building form and component libraries. Gatekeepers of excellence in forms, if you will.