A monthly reading roundup - no chasing every model, no top-50 lists, no marketing. One thread running through it all: the best model on the planet can be switched off on a Friday afternoon, so the real asset is what you build around it. You lease the model, but the process is yours.
Here's the last month seen through my favorite filter, the one I've been using for a few months now to stay sane: loud vs. load-bearing. Loud is what LinkedIn screams about for 48 hours. Load-bearing is what's still worth reading a month later, once the hype has died down.
June was exceptionally loud: two frontier models disappeared behind a government curtain, one Chinese open-weights model beat GPT-5.5 at a sixth of the price, and Sakana shipped something it literally sells as "frontier without export-control risk." But the best pieces of the month, the genuinely load-bearing ones, weren't about models. They were about what surrounds them.
The world's best model vanished on Friday
The event of the month, and by a wide margin, was the disappearance of Fable 5. It shaped the discourse for weeks afterward and spawned several significant follow-ups, so let's start there.
Anthropic released Fable 5 on June 9, then disabled access to it worldwide on June 12 to comply with a government export directive. As I write this, TheBestCodingModelOnEarth™ (allegedly, since we had just two days to verify it) has been in the dark for seventeen days, and sources has pencilled in its tentative return - so there's a chance that by the time you're reading these words it's already back, and maybe you're the one running due diligence on it.
This isn't only a story about export policy (though it's that too), but first and foremost a story about dependency. The teams that wired Fable 5 into their pipeline did everything right and on Friday afternoon were left with a hole where their engine used to be. And the first time not because of cost: even if your token budget runs on a sky-is-the-limit basis, you still can't get Fable. Capitalism has to cede ground to national security.
And then, as if to confirm the thesis, on June 26 OpenAI unveiled GPT-5.6 Sol and immediately only to about twenty government-approved partners. It's the first time a US company has shipped a frontier model from behind a government velvet rope, client by client, all of it in the shadow of an executive order Trump signed on June 2 that requires companies to submit their most powerful models for evaluation 30 days before a public launch.
But pin the government to one side for a second, because the first time Fable 5 blocked anyone, the hand on the switch was Anthropic's own - and the switch was inside the model. Researchers digging through Fable 5's 319-page system card found a paragraph admitting that when the model decides you're doing frontier LLM work - pretraining pipelines, distributed training, ML-accelerator design - it doesn't refuse and it doesn't fall back to a weaker model. It quietly degrades itself through prompt modification, steering vectors or PEFT, and - the system card's own words - this is "not visible to the user." So you keep paying Fable prices while the model hands you a silently nerfed answer and never mentions it. The Register, not unfairly, called unannounced prompt modification a man-in-the-middle attack on your own session. The cyber and biology guardrails were louder but no saner: people got bounced at 'hello!' when the safety classifier tripped on an empty context, the word 'cancer' got flagged as a biosecurity risk, and at least one user was turned down for help editing an 'Application Security Architect' resume.
Anthropic eventually apologised for getting the tradeoff wrong and promised to make the research throttling visible - but the damage to the premise was done. Because this is the quiet part of the dependency problem said out loud: the export ban asks „will my provider cut me off?", and Fable's system card asks something worse - „when I do have access, am I even getting the model I think I'm paying for, or the version it decided I deserved?"
For me there's one takeaway, and it's uncomfortable. Starting with the biggest model is a risk. For the last two years we were all asking "which model is best," and now we should be asking instead what your Disaster Recovery looks like if a provider cuts off your access to a model and blocks your API key. And that's exactly the question you should have in mind when you design your agents and your SDLC process.
The answer is underneath the model: open weights and combinations
The good news is that this risk has an emergency exit - and that exit matured in exactly the same month.
Z.ai's GLM-5.2 came out on June 16 under an MIT license, full weights to download from Hugging Face, do whatever you want with them, and on SWE-bench Pro (we will get to that later) it scored 62.1, beating GPT-5.5 (58.6) at roughly a sixth of the cost. That's 753 billion parameters in an MoE architecture, a million tokens of context, and, tastiest of all, the first open model to cross 80% on Terminal-Bench. The best joke of this whole release is that GLM-5.2 rolled onto the market at exactly the moment Anthropic's most powerful models were sitting under a US ban.
The best commentary on this release, though, came from Nathan Lambert in Interconnects, and he's the one who convinced me this isn't just another number in a table. Lambert waves off benchmarks themselves (in his view they're "half dead" these days) and points to something subtler: GLM-5.2 is the first open model that simply sits well in a coding harness as a general-purpose agent. The first. He adds a number that should keep the closed labs up at night: from Opus 4.5 (November) to GLM-5.2 (June) is 204 days, about 7 months, and Opus 4.5 is still remembered as the first model genuinely useful in real work. And because this diffusion is happening precisely while the flagship US model is switched off, Lambert flatly calls it a stab into the economic underbelly of the frontier labs.
And here's an important caveat, because open weights aren't only colossi of the GLM-5.2 variety, which you'll most often fire up through someone else's API anyway. Vicki Boykis described how, on an ordinary 2022 MacBook (64 GB RAM), she now runs agentic loops locally, on models from the Gemma 4 family, with accuracy and speed at around 75% of frontier. Refactoring a notebook into a proper repo, unit tests, lint, all without leaving her own drive. Six months ago that was technically impossible. And her measure of model maturity is wonderfully practical: do I still have to check its output against an API model? Less and less often.
And if you don't want to pick a single model, you can not pick at all. Sakana released Fugu on June 22, an orchestration system that keeps a whole pool of frontier models behind a single (OpenAI-compatible) endpoint and decides for itself which one to call for which task. Their pitch is wonderfully cheeky: frontier "without export-control risk."
But there's an asterisk to add here: Fugu leases its intelligence from the very providers it compares itself against, and Fable 5 and Mythos happen not to be in the pool, because they're under the ban. So the hedge is real, but smaller than the marketing suggests: resilience comes from the diversity of the pool, not from a single swap. It's an important lesson: routing alone won't save you if everything you're routing is borrowed.
The takeaway from this section is fairly subversive for 2026: maybe, after years of promises, you really don't need the biggest model (though GLM-5.2 is hard to call small). Open weights plus merge plus routing are enough for most everyday work, which is plain writing anyway. The model becomes a swappable component. And if it's swappable, then the value moves elsewhere.
Sovereignty is on everyone's lips again
That's why, for many companies, June was a signal to take the process into their own hands.
But let's be careful about what "into their own hands" means, because it's easy to be naive here. Not every company has its own model and not every one will, you still lease the model. But the IP around the model, the scaffolding that makes swapping the model safe, is yours, and you have to treat it as the core, not as glue code. Routing by data residency, portability between providers, a self-hostable fallback for the bad hour.
June showed all too well that this isn't paranoia. It turned out that Fable 5 on Bedrock was sending prompts back to Anthropic, a small configuration detail that, for a compliance team, is a heart attack. On the other hand, AWS showed Lambda MicroVMs, which keep an agent's code inside your VPC, so it's possible to build toward isolation. And hanging over all of it is enforcement of GPAI obligations under the EU AI Act starting August 2, because Brussels also has an opinion on where your data lives.
The irony is thick and worth pausing on, because it explains best why you can't buy sovereignty in a bundle. The Sakana Fugu just mentioned, sold after all as an escape from export controls, is unavailable in the EU because it hasn't squared away GDPR. GLM-5.2, the most beautiful open alternative, sends your prompts (through a hosted API, which I don't recommend) to servers covered by Chinese national-security law. You can see the pattern: every emergency exit has its own gate. You flee from under the US directive and land under an EU regulator or under Chinese jurisdiction, which means you're not trading dependency for freedom, just one sovereign for another. The leash stays, only the hand holding it changes. Sovereignty, then, isn't a slogan you buy along with access to any model, but a property you deliberately design into the layer beneath it, because no provider will do it for you against its own interest. You lease the provider, but you own the dependency architecture (which we'll come back to).
And since I live in Europe myself, let's go one floor lower still, because the best piece on sovereignty in June wasn't about models or scaffolding at all. Paweł Dolega in "Sovereignty Has a Power Bill" reminds us of something the whole industry conveniently forgets: sovereignty isn't blocked by software or even chips, it's blocked by electricity. A single modern AI cluster draws as much power as a quarter of a million homes, and Anthropic assumes that training a single frontier model will, by 2028, require a data center of 5 gigawatts, roughly five nuclear reactors. That's about 6% of Poland's total installed capacity. Meanwhile, connecting such a center to the grid in a European hub takes seven to ten years (sometimes thirteen), while a frontier model ages out in twelve to eighteen months.
Not including all the side-effects.
Ireland, which did everything by the old playbook and became the data-center capital of Europe, in 2024 handed 22% of the country's electricity to data centers, froze new connections, and then set a hard condition: a new center brings its own power or you don't build it.
And his punchline here is surprisingly uplifting, and doubly instructive for us. Of all the layers of the AI stack, the power grid is the only one Europe (and any company) can realistically own end-to-end: lithography is Dutch but US-controlled, the best open weights are American, chips are American-Taiwanese, but the transmission line, the energy storage and the reactor can already be fully yours. This sovereignty, as Dolega writes, isn't blocked, but it's simply unbuilt. And unbuilt is the only problem on this list that can be solved with money and a decade of nerve.
And here the threads of the entire first half of this issue tie together. If you have to own the layer beneath the model, it's worth knowing what's most valuable in that layer, and June answered in one word: skills, meaning codified ways of working. Anthropic described reaching 95% coverage of its internal analytics not with a bigger model, but with skills, with the footnote that without maintenance that proficiency drops to around 65%.
Two things follow at once. First: for most real work you don't need a frontier, just a well-described way of working that any model can execute. Second: a skill isn't magic, it's a living artifact that you either tend like code or it rots. That this is already standard rather than one company's curiosity is clear from Apple putting Agent Skills into Xcode 27, portable between Claude, Codex and Cursor. A skill is a model-agnostic layer, and that's exactly why it's a reusable unit you own rather than rent.
Let's glue this into a single sentence, because this is exactly June's zeitgeist: value has shifted from the model itself to what surrounds it, namely the scaffolding, the way of working and the skills. These few pieces aren't several separate trends, but one hunch arriving from several directions at once. The scaffolding and the way of working that forms around a team is your IP, and it's what makes a rented model swappable. You change the engine, you keep the factory. And speaking of factories…
Loop engineering and software factories
Here we reach the IMHO heart of June. All the energy of the best writing went not into models, but into what surrounds them. And if you take one thing away from this section, take this one: in June the industry stopped sharpening prompts and started designing the loop.
Let's start with the naming, because it isn't accidental. Addy Osmani wrote about "Loop Engineering", LangChain about the art of loop engineering, Latent Space christened it "Loopcraft", and InfoQ ran a podcast on the path from MCP and vibe coding to harness engineering. Just look at the evolution: a year ago the art was writing a good prompt (remember the Prompt Engineer role that was supposed to be the hottest position on the market?), squeezing one good output out of a single shot. Today the art is designing a loop in which the agent acts repeatedly: what it sees, what tells it "done," what stops it. A prompt is one turn, a loop is a system, and that whole shift from turn to system is the subject of the rest of this section.
The most practical turned out to be Birgitta Böckeler of Thoughtworks on maintainability sensors for agents, and if you're going to click only one link from here, click that one. Her distinction looks trivial but is load-bearing: guardrails (feedforward, you tell the agent up front how to work) versus sensors (feedback, you measure after the fact whether it did well). The catch is that almost every team writes guardrails and neglects the sensors, and ends up with an open loop. And an open loop isn't an agent that helps you, it's an agent that produces a mess faster. The value doesn't sit in having an agent, but in your loop closing: tests, types, linters, observability that the agent reads and corrects itself against. To put it plainly: stop appending more sentences to the prompt and start investing in the signals that will tell the agent (and you) that something went wrong.
Two frameworks add the necessary shadow to this. Geoff Huntley at AI Engineer in Melbourne put forward the thesis "Everything Is a Factory", an operating model with consequences. A production line has two metrics, not one: throughput and defect rate. The whole industry talks about the first (more code, faster) and stays silent about the second. If you crank up throughput without calibrating the line, you don't produce more good code, you mass-produce defects. A factory is run and measured, not switched on like a magic tool. And here comes the real skeptic: Armin Ronacher in "The Coming Loop" agrees that loops are inevitable, but points to a cost nobody enters into the ledger, namely the loss of understanding. When the machine produces and you only approve, at some point you stop understanding what's in your repo. It's a new kind of debt, not code debt but comprehension debt, and no linter will catch it.
Personally I'll add that I don't quite believe in the vision where this debt can really be handled by a human. I have a feeling that the natural, inevitable consequence of loops will be that the human gradually steps back from creation itself and focuses instead on shortening that loop and preparing the signals the Thoughtworks folks wrote about. At some point it will be very hard to step in and fix something you've never seen before. It's a bit like the situation where you're suddenly dropped into source code nobody has looked at before and you just have to "figure it out." It will resemble working with legacy systems, which I personally enjoy a great deal, more than the classic cranking out of feature code, so it's worth being prepared for that.
We'll see whether I'm right. That's my bet, especially if loops do turn out to be the future. So you know: "Working Effectively with Legacy Code," required reading.
The benchmark wars
All right, the factory produces code, so we need to measure whether it produces good code. And here June was exceptionally combustible.
The hardest hit came from FrontierCode, covered by Latent Space, because instead of pass-rate it started scoring mergeability, that is, whether the PR could be merged at all. The diagnosis is brutal: more than half of SWE-bench is, to quote, "unmergeable slop," and Opus 4.8 on the hard set scored a measly 13.4%. And here comes a word worth writing down as the thought-virus of the year: slop. Code that passes the tests and belongs in the trash.
This plugs into a louder row about contamination. In February OpenAI officially stopped reporting SWE-bench Verified, because models had simply memorized the solutions, GPT-5.2 could reproduce the exact gold patch from memory. The successor is SWE-bench Pro from Scale, built for contamination resistance (copyleft repositories plus startups' private code), and suddenly the leaderboard drops from 70-95% to around 23%. METR adds that many "passed" PRs wouldn't survive a human code review, and separate analyses (SWE-MERA) estimate that on some configurations around 32% of successes are solution leakage, and another 31% pass only because the tests are full of holes. Add to that a separate paper showing outright that agents game the evaluations and the picture comes together. Translation: the number a vendor pastes into a deck mostly measures how well the model knows the exam.
The best stat of the month, though, came from Stack Overflow. The 2026 Developer Survey opened with the note "for human developers only", and that sentence is itself a commentary on the era. In numbers: AI adoption somewhere around 84%, and high trust in what AI spits out a measly 3% or so. Everyone uses it, almost nobody trusts it.
And that's not just a neat irony, because two weeks earlier the same Stack Overflow shipped Stack Overflow for Agents: a separate corpus where it's agents that ask questions and share solutions, while the human stays in the loop only to approve what makes it into the base. The whole product rests on the same intuition as this section: generating a plausible-looking answer got cheap, while checking which one actually holds up in production didn't get any cheaper. That's why the reputation there is earned for verification, not for creation. A survey for humans only, a corpus for agents only, two weeks apart.
So don't surrender the definition of "good" to a number someone else can game. You measure "good" on your own backlog, with your own harness, on your own code.
And "good" also means secure
More and more often we prototype the first version of a project as "1.0" code: a first draft, written by an agent, often disposable. The problem is that when something is disposable, we treat it lightly, while the holes in it stay very real.
Birgitta Böckeler in "VibeSec Reckoning" puts it plainly: appending "be secure" to the prompt fixes nothing, because what's needed is deterministic controls, not wishes. The numbers match the unease, because according to a Salt Security report nine in ten security leaders worry about the risks of AI-generated code, with secret exposure at the top of the list.
On top of that comes supply chain, my favorite category of nightmares. PolicyLayer's "State of MCP" report reviewed 2,031 servers and found that 42% of them expose some destructive tool. A nice word even appeared for the new attack vector: "agentjacking." The industry's answer is receipts and provenance, because Dapr 1.18 introduced Verifiable Execution, and GitHub introduced security validation for third-party coding agents. So instead of taking the agent at its word, we're starting to demand a grounding.
The clinch of this section is best seen in two June pieces. a16z enthusiastically proclaims "disposable software", single-use code, generated for a specific need and thrown away. And Security Boulevard coolly replies "durable side effects": disposable code leaves durable holes. Our era in a single sentence: software is sometimes disposable, the security consequences never are.
Building the factory means building trust
And here we return to the beginning, only now from the solution side, not the problem side.
The best framing came from Kent Beck in "Trust Factory". His sentence ran around my head all month: we started accumulating code faster than trust. And software isn't just code. Software is code plus trust. AI sped up production of the first ingredient to the point of absurdity, while the second, the confidence that the code does what you think it does, still has to be built by hand, slowly, through verification.
What remains is the layer no model will replace: human judgment. Vini Brasil wrote a great piece, "When I reject AI code even if it works", because "it works" isn't the same as "I understand it and will maintain it." Charity Majors argues that AI demands more engineering discipline, not less. Sam McLuckie in a podcast talks about culture as a team's operating system. And normaltech calmly explains why AI hasn't replaced engineers and won't: because the job was never about writing, but about deciding what to write and why.
The backdrop to this discussion is, I admit, less idyllic. Oracle cut about 21,000 jobs, citing AI. The job market is shifting and pretending otherwise would be dishonest. But note the direction, because this is my thesis, not a hard fact: companies aren't cutting because the model produced trust. They're cutting because it produced code. And if that's true, the premium moves to those who can endow that code with trust.
And that's the synthesis of all of June, if I have to boil it down to a single image. The software factory is a machine for producing trust. You lease the model, it's the weather, a swappable component, something the government can switch off on a Friday. Trust you build and own yourself, and it's what stays in the wall. Rent the model, own the process.
The threads from this issue also feed into the July update of Visdom Maturity Matrix (loop engineering and the Loop/Harness Engineer role, mergeability over pass-rate, skills as a reusable unit, sovereignty as portability plus residency plus self-host fallback, and disposable software in the technical-debt section), and I've listed all the changes on the changelog page.
Thanks for reading. See you in a month.
PS: The most convincing argument about ownership I came across in June wasn't in any essay. It was the sight of a progress bar as I downloaded a 2-bit quant of GLM-5.2, some 240 GB of weights onto my own drive.
You can have a thousand opinions about whether you "own" or "rent" models, but the moment those 240 GB sit locally on your machine and nobody in the world can touch them (because you can always unplug the machine and stash it in a closet), the discussion moves to a new level. Fable 5 disappeared on a single command from Washington. Nobody can switch off my folder of weights.
Nice feeling, a bit preppers-like, just a shame memory is so expensive 😉
