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 t