XGEN Newsletter vol.3

The new specification of MCP — the standard for attaching tools and data to agents — was finalized on 28 July. The biggest change is that the protocol no longer holds state. Session IDs and the handshake are gone, so servers can run several deep behind an ordinary load balancer. As extensions were promoted to formal features, MCP Apps, where the server draws the UI, and Tasks, for long-running work, came in, and OAuth 2.0 and OpenID Connect compatibility plus a deprecation policy settled into place. It is the first major revision since the standard moved under the Linux Foundation last December and became vendor-neutral.

Dropping sessions is ultimately an operations story. Until now, scaling out MCP servers meant keeping the same user pinned to the same pod; that constraint is gone. This issue talks about attaching external APIs to collections — and this document is where the industry writes down how that act of attaching is being standardized. If you plan to scale out MCP servers, start by checking whether you can drop session affinity.

Spotify published Xirp, its internal AI coding environment. The diagnosis stands out — agents decide fast and confidently, but cause production incidents because they do not know organizational context. Who owns this service, what it depends on, why it was designed that way: none of that is in the code. It is in Slack threads and in people's heads.

Xirp pulls that context from the developer portal into every session, and pushes knowledge that surfaced in a session back out into documentation. Instead of making the agent smarter, it increases what the agent knows.

That return loop is what we do not have. Our documentation automation leaves a record every day, but what it holds goes only as far as why the code changed. What was decided in a meeting, and why we chose that direction, is still written down nowhere.

This is not a story about needing a new system. It is a question of whether to put one more line into a place that already runs every day.

The AI inference cost enterprises pay hit a low for the year. The average price per million tokens fell from $18.40 in Q1 last year to $6.07 in Q1 this year, and sits around $1.16–1.18 in early August. Open models' share of enterprise token usage also grew from 11% to 38% in a year.

And yet what enterprises actually pay did not fall. Over roughly the same period, enterprise AI spending more than doubled, from $3.5bn to $8.4bn. Because cheaper simply means more use. Google said its monthly token throughput grew 330-fold in two years.

The leaks are quite specific. One agent stuck in a loop burned $47,000 over eleven days. Because every step resends the whole conversation, cost accrues with the square of the conversation's length. Sending work a small model could handle to a top-tier model costs up to 50× more; not caching repeated input, up to 90% more.

The ways to cut it are already settled. Filter with cheap models first (classification and scanning on a $0.10-per-million-token model, final judgement only on a model in the $10 range), keep the part that does not change in cache, and stop resending the whole conversation every time. Stack all three and reports show 60–80% cut in production. Cloudflare, which had attached 2,500 tools, folded a tool list of 1.17 million tokens into two, at 1,000 tokens.

For 'it got cheaper' to hold, the unit of counting has to be the same. The price of one token became a third, but the number of tokens it takes to finish one job grew faster than that. To decide which of the three to start with, you first have to see where it leaks. Stanford HAI found that teams measuring tokens per tool call find their savings three times faster than teams looking only at the invoice total. Our admin screen currently goes as far as per-user totals. It looks like it needs one more column beside it, counted per call.

antirez, who built Redis, wrote up how he works these days. Writing code and hunting bugs go to the model; idea design, QA, optimization strategy, and design documents he writes himself. Building LLM inference software that runs locally, he had the model implement DeepSeek and GLM support — but you cannot say 'implement it' and expect the result to work, he says. Instructions only hold if you understand the design and the performance.

His conclusion is this. If you hold the idea of the software, looking at the code itself is mostly pointless. He writes that nobody should read this code — read only the idea the code carries. And he adds that a book from the seventies explains the present better than much of what came out between 2000 and 2020.

The uncomfortable side is not his argument but us. The people who say you must read the code do not actually read it. Try to remember the last time you scrolled a diff to the end before pressing approve. antirez decided not to look, and took hold of the design instead. We say we look, and do not. Of the two, he is the honest one.

Google published a piece titled 'why Go is an ideal language for AI-assisted development', but what stays is the diagnosis before the language argument. How fast a person writes code hardly matters now, it says; what matters is reviewing, verifying, and maintaining code that is already written. The phrase that the bottleneck moved wholesale from generation to verification appears too.

There are numbers. First generation is 95% correct, but repeat the same task and errors accumulate as context is polluted, so accuracy falls while token cost rises. Hence the logic that readable syntax, static types acting as an automatic safety net, and compatibility that compiles 15-year-old code unchanged, hold value.

Two hundred and ninety-three merge requests landed on internal branches alone in the past two weeks. The documentation build automation in this issue's in-development section is aimed exactly here — make the manual change when the code changes, and reduce the share a person has to chase. In the past two weeks alone, more than twenty chapters were updated that way.

It is also a structure that blocks a problem caused by cheap generation with yet more generation, though. Who reads an automatically written document, and what confirms it is right? That question waits at the next stop. The only answer we have right now is that a person opens the chapter.

A post from 4 August with a bold premise. The cost of producing code keeps falling — so what if reimplementing a large codebase wholesale came down to the level of today's SaaS subscription? The author's starting point is that the way software is made would then have to change.

The design goes like this. Keep the requirements specification in the repository instead of the code. When a security policy changes or a performance target moves, edit the spec, press a button, and regenerate everything. Regenerating from new requirements should be as simple as recompiling a program, he writes. Code becomes a disposable by-product of the artifact that actually lasts, the piece says.

He is firm that automatic generation alone will not do. You must be able to verify that the generated code kept to the requirements, and for that you have to write the specification in a language whose meaning does not drift. Requirements written in natural language alone do not make this picture work.

What the design aims at, in the end, is fixing. Much of the time development takes goes not into making something new but into holding on to what is already made and fixing it. If you can pull it out of the spec again, you gain the option of making it anew instead of fixing it.

So we counted how much we are fixing. Of the 293 merge requests raised on internal branches in the past two weeks, 125 — 43% — fixed something. Two of those had [urgent] in the title: the error where uploads failed entirely, and the one where the DB query node died. This number may mean quality is poor, or it may mean we fix things often because we can fix them fast. Which one it is cannot be told from the number alone.

One more thing to note. We are building a system where the manual changes when the code changes. The code is the original and the documentation follows behind. This piece proposes the exact opposite: requirements as the original, code as the result. What ought to be the original has no answer yet, but asking it this way sharpens it a little. What in your repository must never be lost? If all the code is gone but the requirements remain, you can make it again. The other way around is hard.