Broadsheet

Specifier	Deno	Node	Bun	Val Town
axios	âœ… (with deno.lock)	âœ…	âœ…	â›”ï¸� (no user-provided deno.json/package.json yet)
npm:axios	âœ…	â›”ï¸�	â›”ï¸�	âœ…
https://esm.sh/axios	âœ… (discouraged)	ğŸŸ (in userspace)	â›”ï¸�	âœ…
jsr:axios	âœ…	â›”ï¸�	â›”ï¸�	âœ…
node:fs	âœ…	âœ…	âœ…	âœ…

GDP projections of Federal Reserve Governors and Reserve Bank presidents, Change in Real GDP¹
Projection Date	2025	2026	2027
Sept 2025	1.4 to 1.7	1.7 to 2.1	1.8 to 2.0
Jun 2025	1.2 to 1.5	1.5 to 1.8	1.7 to 2.0

Unemployment projections of Federal Reserve Governors and Reserve Bank presidents, Unemployment Rate²
Projection Date	2025	2026	2027
Sept 2025	4.4 to 4.5	4.4 to 4.5	4.2 to 4.4
Jun 2025	4.4 to 4.5	4.3 to 4.6	4.2 to 4.6

Inflation projections of Federal Reserve Governors and Reserve Bank presidents, PCE Inflation¹
Projection Date	2025	2026	2027
Sept 2025	2.9 to 3.0	2.4-2.7	2.0 to 2.2
Jun 2025	2.8 to 3.2	2.3-2.6	2.0 to 2.2

Core Inflation projections of Federal Reserve Governors and Reserve Bank presidents, Core Inflation¹
Projection Date	2025	2026	2027
Sept 2025	3.0 to 3.2	2.5-2.7	2.0 to 2.2
Jun 2025	2.9 to 3.4	2.3-2.6	2.0 to 2.2

The map above is a depiction of The Deluge, a historical event in which the Polish-Lithuanian Commonwealth — which had been a major European power — was defeated and destroyed under the combined assaults of Russia and Sweden in the 1600s. After having its power broken, Poland was carved up in the 1700s and subjugated by Russia, Prussia, and Austria. It took more than two centuries, until the fall of communism in 1991, for Poland to reemerge as a strong, truly independent country.

The Deluge shows that power and independence are not permanent. If you are surrounded by hostile powers, and if you don’t have the ability to guard yourself against those powers, no amount of historical greatness can save you from being subjugated. This is an important lesson for Europeans to remember right now, as they find their region under siege from Russia, China, and the United States all at once.

The United States no longer cares about the European project

Why would America care about Europe at all? For most of our history, we didn’t. In the 19th century, the U.S. viewed European countries as dangerous rivals. In the early 20th century, Americans prided themselves on not getting involved in European affairs, and were incensed at their government for dragging them into World War 1. Only after World War 2 did Americans start caring about Europe, and we did so for three reasons:

West Europe was a bulwark against Soviet communism.
Europe was a key trading partner.
Many Americans came to value their ancestral ties to Europe.

The first of these reasons vanished in 1991. Europe is still a bulwark against Russia, but Americans no longer feel threatened by Russia. Russian power is far less than what it once was, and Russia’s rightist ideology does not threaten the rightists who now rule America.

As for communism, many (most?) Americans now believe that European countries are socialist. When American conservatives ask where in the world socialism has succeeded, American progressives will always reply “Europe” or “Scandinavia”. Whether Europe or Scandinavia is actually socialist is irrelevant; Americans have come to see it that way.

Europe is still an important trading partner. But Trump and the other people now in charge of the U.S. do not understand trade at all. They think about trade entirely in terms of the net trade balance, rather than in terms of total U.S. exports. Trump & co. don’t care that America sells $650 billion a year to Europe; the fact that Europe sells $800 billion a year to America means that Trump & co. think America is “losing” and would benefit from a cutoff of trade.

Remember that the U.S. is an unusually closed-off, self-sufficient economy, so Americans in general don’t think too hard about trade or try to understand why it’s valuable. Also, the people running now the country are especially ignorant about economic matters.

As for civilizational ties, this is the reason Trump and the MAGA movement have turned so strongly against Europe. The American right values Europe because they think of it as a White Christian homeland — the source and font of Western civilization. Here’s a post I wrote about that earlier this year:

I wrote:

in the American mind, Europe stood across the sea as a place of timeless homogeneity, where the native white population had always been and would always remain…In the mind of many Americans, Europe thus stood as both a refuge and a reservoir. America itself was a rough, contested frontier, but Europe would always be white and Christian. If you ever felt the need to live around a bunch of white people of Christian heritage, you could always go “back”, but for most that wasn’t necessary — just knowing that the Old World was somewhere out there was enough.⁵
I think Europeans may underestimate how much this perception motivated America’s participation in the Transatlantic Alliance during the Cold War…[T]o conservative Americans in the 20th century — the type of people who joined the John Birch Society — the Cold War was about preserving Christendom from the threat of godless communism.
Anyway, in the 2010s, it dawned on those Americans that this hallowed image of Europe was no longer accurate. With their working population dwindling, European countries took in millions of Muslim refugees and other immigrants from the Middle East and Central and South Asia — many of whom didn’t assimilate nearly as well as their peers in the U.S. You’d hear people say things like “Paris isn’t Paris anymore.”⁶…At the same time, Europe had long since abandoned its traditional Christian values…
To Americans who valued the idea of America and Europe as part of a single Western civilization, this realization was catastrophic. Suddenly European countries — and the Anglosphere countries of Canada, Australia, and New Zealand — felt like they had left the club…
America’s rightists…want to know that someone, somewhere, is out there preserving an indigenous homeland for their identity groups. And that “someone” has to be Europe and the Anglosphere.

This isn’t a new attitude, either. Remember that in order to persuade a reluctant America to join World War 1, the U.S. government had to depict Germany as an ape abducting a white woman!

If you understand this, then nothing in America’s new National Security Strategy is mysterious, surprising, or confusing. Here’s how War on the Rocks summarizes the Trump administration’s attitude toward Europe:

[I]mmigration is elevated to the central national security problem. The text declares, bluntly, that “the era of mass migration must end,” and that “border security is the primary element of national security.” It frames mass migration as a driver of crime, social breakdown, and economic distortion, and calls for a world where sovereign states cooperate to “stop rather than facilitate destabilizing population flows” and tightly control whom they admit…
[P]rotecting American culture, “spiritual health,” and “traditional families” are framed as core national security requirements…The document insists that “restoration and reinvigoration of American spiritual and cultural health” are prerequisites for long-term security and links this to an America that “cherishes its past glories and its heroes” and is sustained by “growing numbers of strong, traditional families” raising “healthy children.” America is thus cast as defender of so-called traditional values, while Europe lacks “civilizational self-confidence and Western identity.”…
[T]he strategy elevates the culture wars into a governing logic for national security, and it does so through rhetoric that treats ideological and cultural disputes as matters of strategic consequence…This is clearest in the European section…The text…speculates about demographic and cultural shifts in Europe as a way to question whether future governments will share American views of their alliances. The strategy [implies] that cultural alignment is essential to strategic partnership.

The American right sees the “mad brute” in the ape cartoon as the dark-skinned Muslim immigrants who have entered Europe in large numbers in recent years. And they see themselves as needing to save the woman — representing their view of Europe as the traditional font of White Christian civilization — from that mad brute.

This tweet by Elon Musk pretty much sums up the American right’s attitude toward Europe:

This is why no amount of European shaming or moral persuasion can have any effect on the Trump administration — or on any Republican administration in the decades to come. This kind of appeal to friendship is totally useless:

And this kind of bitter, angry hectoring is worse than useless:

The American right — i.e., the people now in charge of the country — do not care intrinsically about democracy, or about allyship, or about NATO, or about the European project. They care about “Western Civilization”. Unless Europe expels Muslim immigrants en masse and starts talking about its Christian heritage, the Republican Party is unlikely to lift a hand to help Europe with any of its problems. Democrats will want to help Europe, but they will only be in power intermittently, and helping Europe will not be high on their priority list.1

Thus, America is not riding to the rescue this time, or for the foreseeable future. I wish things were different, but my wishes count for nothing; this is the reality with which the Europeans must now deal.

Russia and China together are the real menace to Europe

Europeans do not need me to tell them that Putin’s Russia threatens not just Ukraine, but all of Europe. They are well aware of this fact. Russia now regularly flies its drones into Europe, and is probably behind a wave of sabotage attacks on European infrastructure.

How can Russia, a country of just 144 million people and $7 trillion in GDP (PPP), hope to overcome Europe, which has 520 million people and $33 trillion in GDP (including the UK), especially after Russia has expended so many of its young men and materiel in its war with Ukraine already? There are three answers here. The first is gray-zone warfare, including sabotage and political influence campaigns. But that’s only the beginning.

Russia’s second method for fighting Europe is what I call a “Ponzi empire” strategy. Russia has enslaved vast numbers of Ukrainians from the occupied regions of Ukraine to fight against the rest of their country. If Russia conquers the rest of Ukraine, it will similarly enslave the rest of the country’s population, and send them to fight against Poland, the Baltics, and Moldova. If they then defeat Poland, they will enslave the Poles and send them to fight against the next European target, and so on.

This is a very traditional Russian strategy. Enslaved Ukrainians were used to attack Poland in 1939. Enslaved Poles were forced to fight Russia’s wars in the days of the old Tsarist empire, and would have been forced to do so again as part of the Warsaw Pact. Just like zombies turn humans against their own, each slice of Europe that Russia can chop off ends up being turned against the rest.2

Russia’s final strategy for fighting Europe is to rely on Chinese assistance. Russia’s own industrial base is very weak, and relied heavily on imported European parts and machinery that has now been partially cut off. But Chinese tech has largely plugged that hole, as the Carnegie Endowment reports:

Since mid-2025, Chinese components have been detected in Russian drones and missiles, often shipped via front companies disguised as suppliers of industrial cooling equipment…Chinese machinery, including precision optics, lasers, and dual-use machine tools, now dominates Russia’s defense-related manufacturing. In August 2025 alone, China exported a record 328,000 miles of fiber-optic cable and nearly $50 million worth of lithium-ion batteries to Russia, reinforcing its role as the Kremlin’s primary wartime supplier of dual-use materials. Chinese engineers working at Russian drone facilities are adapting civilian quadcopters, such as the Autel Max 4T, for combat use.

China is a far bigger manufacturer than Europe, and can pour essentially infinite war production into Russia if it wants to. And China is now assisting Russia’s gray-zone warfare against Europe:

Since 2024, Chinese ships have been involved in incidents of targeting subsea infrastructure, particularly cutting subsea cables in the Baltic Sea…The country increasingly deploys ambitious espionage and cyber attacks against government networks and critical infrastructure across Europe. These attacks seem to overlap with—or even be actively coordinated with—Russia’s espionage and influence operations across Europe…Increasingly, Russia and China also cooperate in disinformation operations: Chinese campaigns such as “Spamouflage” are amplified by Russian media outlets and diplomatic channels. Both countries employ what look to be synchronized narratives accusing the West of being responsible for the war in Ukraine.

China even provides the Russians with battlefield intelligence, helping them strike and destroy Ukrainian targets in real time. In sum, China is supporting Russia’s war against Ukraine, and will likely support Russia in any further wars it undertakes against the rest of Europe.

With Chinese technology and production, and slave soldiers from East Europe, and with America withdrawing from the Transatlantic Alliance, Russia could conceivably overmatch Europe.

But that’s not the only threat that China poses. On the economic front, China’s new economic strategy — a combination of shutting out European products, sending out a massive wave of subsidized exports, and putting export controls on rare earths — threatens to forcibly deindustrialize Europe. Here’s what The Economist, normally a staunch defender of free trade, recently wrote:

China is not just dumping exports and subsidising its companies, it is also out-competing and out-innovating big European industries, including carmaking. Last year Germany’s trade deficit with China stood at €66bn ($76bn); this year it could widen to over €85bn, around 2% of GDP. Alarmingly, China is exploiting Europe’s dependence, weaponising embargoes or the threat of them in chips and rare earths.

Germany, traditionally Europe’s strongest manufacturing and exporting nation, is already the hardest hit:

China, many European manufacturers have concluded, is threatening to put them out of business, by both fair means and foul…The wails are loudest in Germany, which is Europe’s biggest exporter to China and its biggest investor in it by far…For the Mittelstand, the small manufacturers that constitute a big slice of German industry, China used to be a source not of angst but of profit. Their precision-engineered machine tools were an exquisite fit for its rapid industrialisation. Chinese consumers raced to buy German cars…
Times have changed…Once-stellar growth inside China has, for many foreign firms, slowed to a crawl as competition with local rivals intensifies. In addition, Germany’s previously small trade deficit with China has ballooned…Last year it reached €66bn ($76bn), or around 1.5% of GDP, driven by a collapse in German exports to China and a rush of imports, notably of cars, chemicals and machinery—hitherto German specialities.
Germany’s trade deficit with China this year is expected to surge again, to around €87bn…German cars command only 17% of the Chinese market, down from a peak of 27% in 2020…Worse, Chinese competition also jeopardises sales in other markets. China’s net exports of cars have risen from zero in 2020 to 5m units last year. Germany’s have halved over the same period, to 1.2m units…Such figures have triggered fears in Germany of a wave of deindustrialisation.

The Financial Times has a good article about this as well, and Brad Setser has a good writeup of that article.

This is all on top of the existing headwinds facing European manufacturing — the energy crisis from the cutoff of Russian gas and self-inflicted “green” policies, Trump’s tariffs, and so on.

So Europe finds itself in an extraordinary perilous position right now. Its main protector has suddenly withdrawn. It has a ravenous, brutal empire attacking its borders, supported by the world’s most powerful nation. Its main export markets are shriveling, and its manufacturing industries are under dire threat from waves of subsidized foreign competition. What can it do to fight back?

How Europe can resist the siege

The most important thing Europeans need is to panic. Europe is facing its own Deluge — a sudden pincer movement by hostile great powers that threatens to reduce it to a collection of small vassal states. This is a true crisis, and it will not be solved by social media rhetoric, or by brave declarations by EU leaders. It cannot be regulated away by eurocrats in Brussels. It will require bold policies that change Europe’s economic, political, and social models. Only a strong sense of urgency and purpose can motivate Europe to do what needs to be done.

What needs to be done? One important step is for Europe to act more as a single whole than as a collection of small countries. In the military realm, this means coordinating European militaries and defense industries much more. Matthew C. Klein writes:

From a properly European pespective, the security interests of each country should be shared across all countries, just as, for example, most Americans in Michigan or Maine would view an attack on California or Florida as an attack on them…The first step is to give the Ukrainians, who are already fighting the Russians, as much material and financial support as they need. From the perspective of European security, French, German, and British weapons are far more valuable in Ukraine than in their home countries. If the Ukrainians were subjugated, defending the rest of Europe would become much harder, with the effective EU-Russia border lengthening dramatically…
Europe’s national militaries have had a tendency to favor their home country’s producers, with the result that the continent is filled with subscale defense companies that are often slow and unproductive. Common defense procurement for a continental army should lead to higher output and lower costs—a few large companies handling large orders should have better unit economics than hundreds of artisanal manufacturers—but it would require Europe’s national defense elites to change their perspective. Philipp Hildebrand, Hélène Rey, and Moritz Schularick recently published a useful proposal for how to make this work.

And economically, Europeans can partially compensate for the loss of Chinese (and American) export markets by selling more to each other. The Economist writes:

A second task is for European countries to make better use of the power they have, by integrating their economies…By failing to integrate, the EU is leaving a vast sum of money on the table. A single market that was designed for goods is failing to help economies dominated by services.

And in his famous report on European competitiveness, Mario Draghi wrote:

We have also left our Single Market fragmented for decades, which has a cascading effect on our competitiveness. It drives high-growth companies overseas, in turn reducing the pool of projects to be financed and hindering the development of Europe’s capital markets…The EU’s new industrial strategy rests on a series of building blocks, the first of which is full implementation of the Single Market. The Single Market is critical for all aspects of the strategy: for enabling scale for young, innovative companies and large industrials that compete on global markets; for creating a deep and diversified common energy market, an integrated multimodal transport market and strong demand for decarbonisation solutions; for negotiating preferential trade deals and building more resilient supply chains; for mobilising greater volumes of private finance; and as a result, for unlocking higher domestic demand and investment. Remaining trade frictions in the EU mean that Europe is leaving around 10% of potential GDP on the table, according to one estimate.

And ideally, Europe should form a fiscal union — the EU itself should be able to borrow and spend, not just the member countries. As Klein writes, this needs to be accompanied by a greater tolerance for fiscal deficits — after all, countries borrow in emergencies.

In other words, Europe’s first step in resisting its siege is to act more like a country and less like a zone. It would also help to find some way to bring the UK back into the fold, especially because polls consistently find that British people regret Brexit.

Europe’s other top priority is to provide for the common defense. That means spending more money on the military, of course, and it also means greatly increasing the size of Europe’s nuclear deterrent. But it also means building a defense industrial base capable of resisting a China-backed Russia.

Europe’s current defense-industrial base was built for the Cold War, when battles were decided by heavy vehicles like tanks and ships and planes. Those are still somewhat important, but drones have risen very quickly to dominate the modern battlefield. Right now, drone manufacturing, as well as almost the entire supply chain for battery-powered drones, is overwhelmingly concentrated in China.

Europe needs to be able to build not just drones, but every single thing that goes into making a drone — batteries, motors, various types of computer chips, and so on. European industrial policy should therefore focus on onshoring these industries. In other words, Europe needs to master the entire Electric Tech Stack. (This will also help Europe get back in the EV race.) And it needs to master the AI software — computer vision, swarming tech, and so on — that will soon be needed in order to make drones a truly modern force.

The question of the proper policy instrument to accomplish this goal — tariffs, subsidies, fiscal borrowing, regulatory changes, and so on — is irrelevant. All of these policies should be done as necessary, and it’s better to do too much than too little. Policy procedure needs to be subordinated to the overriding goal of making Europe capable of defending itself. In fact, every European institution needs to be reformed and reverse-engineered in order to enable this.

Europe is also going to have to change its political mindset. Lavish pensions and other elements of Europe’s social model are going to have to be temporarily curbed to help give Europe the fiscal space and physical resources to fight off its enemies. All nuclear plants need to be restarted, and Europe should build more nuclear, ignoring “green” parties and environmental activists who irrationally hate nuclear power. Europe needs to reform its land-use regulation to require greater construction of solar and wind power. And Europe is going to have to back off of its aggressive regulation of AI software, in order to produce cutting-edge autonomous weaponry.

Finally, Europe needs to look for friends and allies — and export markets — other than America. India is an obvious choice. Although India is friendly with Russia, the country would undoubtedly welcome Germany’s help industrializing — and this would allow German companies to sell machines to India, as they once did to China. The EU should open its markets to Indian goods in exchange for Indians doing the same, recognizing that trade balances are less important than total export demand. Japan, South Korea, and other big developing countries like Indonesia, Vietnam, and Brazil are other good potential trading partners.

If Europe manages to unify more and to build up its military power, it will increase the number of great powers in the world by one. A planet with a strong Europe, America, China, Russia, and India is a better planet than one where only the last four of those are strong. If Europe shows it can act with unity and purpose, and that it has military power to be reckoned with, America and China — both countries whose leaders tend to respect raw power — may lose their disdain for the region, and return to a more diplomatic, conciliatory posture.

Ultimately, European weakness and division are the reasons the region is getting bullied by so many other powers. Reversing that weakness and division would make the bullies go away. But Europe’s people, and especially Europe’s elites, have to want it.

Subscribe now

And of course if Europe does expel the Muslim immigrants and start talking up its Christian heritage, as the MAGA folks want, Democrats will conclude that Europe is fascist and be reluctant to help it out when they get back in power. Essentially, Europe is finding itself caught in America’s internal culture wars, and there’s no good way out; the only solution is to realize that the U.S. will not be a reliable partner for decades to come.

Would Russia actually try to conquer and rule all of Europe directly, as the Nazis tried to do? Unlikely. But would it try to dominate all of Europe the way the USSR dominated the Warsaw Pact? Yes, definitely. And this sort of domination would be very bad for Europeans, as the Poles could tell you.

I’m hanging out in Sydney with my esteemed co-author and co-conspirator Gene Kim today; we flew in to conduct Vibe Coding workshops and talks this week to the Commonwealth Bank of Australia, some of their partner companies, and the general engineering public. Very cool of CBA to sponsor this training, and Gene and I are super excited for it.

We noticed that we’ve pushed into new territory since our Vibe Coding book was published. The book is all about how to work with coding agents, and all the advice and techniques in it are still incredibly relevant; I use it all daily. But there’s even more to learn, and we continue to uncover new tips and strategies.

I thought I’d share some of the new themes we’ve noticed, in no particular order, hot off the presses. Let’s see which ones resonate with you.

1. Software is now throwaway — expect < 1 year shelf life

This is probably the most obvious one. Anthropic has already begun embracing this idea internally, which is how I first heard about it, from friends there.

26 years ago Joel Spolsky wrote one of the most useful pieces of software advice anyone has ever given, in Things You Should Never Do, Part 1, where he says, in a nutshell, DON’T REWRITE YOUR SOFTWARE!

In this classic essay, well worth a read, Joel gives powerful examples of companies and projects that decided their code base was too old and crufty, so they chose to rewrite it all from scratch. And the results were, predictably, awful. Joel says:

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that’s kind of gross if it’s not made out of all new material?

And he was right! Outstanding essay. But unfortunately, not so timeless as we thought. It proved to have a shelf life of only about a quarter century. We are entering a surprising new phase of software development, in which rewriting things is often easier (and smarter) than trying to fix them.

I first noticed this with unit tests. You’ll use agents to make a giant refactoring to your system, and then all the tests will be broken. The agents inevitably struggle to fix them. So one day I said, screw it, delete all the tests and make me new ones. And it got through that exercise SO much faster. The new tests were great, had great coverage, and importantly, the LLM was able to generate them very quickly, compared to trying to reason through the old system behavior vs the new expected behavior. With new tests, it can focus just on the new behavior, which is a much cleaner cognitive problem.

This generalizes beyond tests: generating almost any code is easier (for AIs) than rewriting it. Hence, recreating software stacks from scratch is starting to become the new normal. We’re seeing it more and more, e.g. companies with mainframes who are concluding that a small team of engineers and biz people could recreate the entire experience with the same API, but with modern architecture and maintainable code, in just a few months. And they’re doing it.

The upshot is that for all the code I write, I now expect to throw it away in about a year, to be replaced by something better. Maybe mine, maybe someone else’s. Doesn’t matter. It’s all just stepping-stones to higher velocity.

This spells trouble for third-party SaaS vendors. Companies are also discovering that they can build bespoke business-automation software so easily that they don’t need to re-up their vendor contracts. SaaS vendors are going to have to work harder to provide value that’s too expensive to recreate. It can be done — Graphite is one example; they now have years of learnings into the nuances of AI code review. I don’t think you would necessarily want to retrace those years of steps yourself, on your company dime. Sourcegraph is another example; they have a code search engine with 10 years of enterprise bug fixes, and even with modern agents, you almost certainly wouldn’t want to try to clone that yourself.

But many SaaS vendors who’ve found niches building business automation software are going to be in real trouble. Because businesses are automating their own processes now, with vibe coding!

2. Agent UX matters at least as much as Human UX

One of the interesting themes I heard at the AI Engineering Conference in NYC a couple weeks ago was that although many people are building tools for AIs, they are finding it very hard to get the AIs to use those tools.

It’s tricky to get AI to use a tool it’s not trained on. They have certain ways of thinking and working, and they tend to reach for familiar tools (e.g. grep instead of a fancier search). I’ve talked with many people who wanted to build a tool for their agents to use, and they’d work with the frontier models to design the perfect agent-friendly interface — one the models swore up and down would get them to use it.

And then haha, no, the agents don’t use it. You prompt and prompt, they ignore and ignore. So what do you do? How do you get them to use your tools?

My Beads issue tracker for agents has been an interesting case study here. It’s only maybe 2 months old and it already has 250+ forks and 5000+ stars. It’s a successful project. But I’ve never looked at the code. It’s fully vibe-coded by agents. Despite that, Beads managed to capture lightning in a bottle — it’s a tool that AIs use, and not only that, they like it. Agents use Beads eagerly and enthusiastically with very little prompting. They make smart decisions, such as filing Beads when they are low on context, instead of doing the work directly. Things you would normally have to prompt them to do, they just do!

I’m no magician. I’ve built plenty of tools that the AIs refused to use; I’ll talk about one of them below. And I’ve built plenty of prompts that the AIs choose to ignore or overlook. It’s not like capturing lightning in a bottle is super reproducible at this point. But I can share some of the things I did with Beads that I think helped.

First, I asked Claude to help me design a new lightweight issue tracker backed by git, with a few other constraints, and then Claude came up with about half of the rest of the design: the SQLite database caching layer, the discovered_by graph link that the models feel is very important for gathering context on issues, the hash IDs, deletion tombstoning, etc.

During the Beads design phase, I mostly argued with Claude, telling it I didn’t like certain choices it was making from a Human UX perspective. Eventually we negotiated our way to something we both liked, something that had good agent UX and also good human UX.

For the agent side, once we had the initial structure in place (the issue tracker itself), the primary UX issue became tooling ergonomics. My agents were trying to use Beads, but they kept giving it the wrong arguments. For example, they’d use — body instead of — description when filing an issue, which would fail. Why? Because they were trained on GH Issues, and GHI’s CLI tool uses — body for filing issues. Reaching for the familiar again!

So in that particular case, told it to add — body as an alias for — description, which it did, and that bit of Agent UX friction went away forever. I’ve done this many, many times in Beads. As the agent works, I watch how it’s using the tool, and whenever it encounters an error, I ask it, how did you want it to work there? How can we change it to make the behavior be more easily guessable?

Over the past few months we’ve made dozens of tweaks, adding flags and commands, and the agents now rarely have trouble using Beads fluently.

I can’t claim to have cracked the agent-UX problem, not by a long shot. I think the role of “Agent UX Designer” feels like it’s ready to emerge as a first-class career for humans. As just one example, I’m working on my third agent orchestrator this year. And even though the architecture is sound, I haven’t found the magic UX formula yet, to where any agent automatically just figures out what to do, and does the right thing most of the time. I’ll get there! In fact, as soon as I solve this problem with my orchestrator, I’m launching it. I’m aiming for Christmas Day. We’ll see.

Once you do find that secret incantation that makes your tool truly agent-friendly, you should get it out there as fast as you can, because it will grow like crazy.

And if you try to launch a tool that agents don’t choose to use of their own volition, with minimal prompting, then you need to go back to the drawing board and fix the agent UX.

The best way to do this is to leverage the Optionality from FAAFO, from our Vibe Coding book. Generate a whole bunch of interfaces, and then experiment with each one, to see which one the agents like best. It’s very much a trial-and-error search problem at this point, until either the agents get better at using new tools, or we get better at learning what they like.

3. Spend 40% of your time on code health, or else you’ll wind up spending >60%.

Gene was curious how I could be so confident in Beads if I’ve never looked at the code. My answer to him was one of the easiest I’ve ever given. If you are vibe coding, i.e., having the AI write all your code for you, then you need to spent at least 30–40% of your time, queries, and money on code health. That’s how you make sure your code is OK. You have the AI conduct regular code inspections. Tons of them.

It’s pretty easy in principle: Every now and then, you pause your regular work, and tell your agents: go find code smells of all shapes and sizes. Have them file Beads for anything that needs followup. Tell the agent to look for large files that need refactoring, areas with low test coverage, duplicated/redundant systems, legacy code, dead code, poorly-documented code, etc. etc. etc. I don’t have a good prompt for this step yet; would appreciate it if anyone has crafted one. But you can also just ask your agent to help craft it.

You’ll also want to ask your agent to do cleanups during the code-health passes. Have it look for files that are in the wrong place, or have misleading names, or need better homes. Have it clean up debug cruft, ancient plans, build artifacts, old docs, anything you don’t need. This is all part of the regular hygiene and maintenance of a vibe-coded code base.

It helps to be creative, and also to ask the agent to be creative, thinking outside the box. After the first round or two of regular code reviews, start having it look for over-engineered subsystems (YAGNI), opportunities where your code could have used a third-party library, and other broad, system-level concerns.

Basically the agent will always find problems, often shocking ones, e.g. where you discover you have two or even three completely redundant systems (databases, logging, telemetry, whatever) that need consolidating. And since agents tend to accrete code without automatic refactoring, your vibe-coded source files will tend to grow to thousands of lines, which makes them harder to agents (and humans) to reason about. So you should tell it regularly to break things up, and then run dedicated sessions to implement the refactoring!

During each code review, have your agent file Beads for everything it discovers. Then have it review the epics and issues (up to 5 times; see below) to ensure the implementation will go smoothly.

Then swarm to fix it all! Do all this at least weekly. For me, I’d estimate I spend about 25–30% of my time and money on code health, and I don’t think it’s enough. As long as I continue to find serious problems with reviews, I need to do more reviews. My current guidance is that you should expect nearly half of your work to be code-health related.

What happens if you don’t follow this rule? You gradually (but rapidly) accumulate invisible technical debt that weighs down your agents in various ways — too much code, conflicting code, obsolete docs, etc. Your agents will begin to work more slowly and you’ll see more bugs in their outputs.

Stay on top of code health, and you’ll keep your vibe-coded code base sprightly.

4. You might be too early: Some projects are ahead of their time.

AI cognition takes a hit every time it crosses a boundary in the code. Every RPC, IPC, FFI call, database call, client/server call, every eval, every single time the AI has to reason cognitively across a boundary or threshold… it gets a little dumber.

I noticed this when working on Efrit, my native-elisp coding agent, which lives inside Emacs. Over the summer I was trying to get Claude and other models to build it for me, and they struggled. Hard. Efrit lives in Emacs, which is a separate process from your coding agent, so already there’s one boundary.

For that particular IPC boundary, there are multiple channels for the agent to talk to Efrit, all of them quite unsatisfying. There’s emacs — batch, which has limitations, and the emacs-server client/server mode, which is also limited for the kind of heavy reflective introspection the agent needs to do for this kind of code base.

So what did I do? I spent a week working with Claude to build a better agent-Emacs bridge. Claude built me the “Agent-Efrit bridge”, a simple and elegant system which uses a polling file channel as a message queue to and from Efrit. It’s beautiful. A tool made for agents, by agents! When it does work, it’s amazing.

Naturally, Claude never uses our fuckin’ bridge we built together. I’ve given up even asking. This is an example of a tool I tried to build, but the AI just refuses to use it.

With Efrit, after that initial bridge there are still other RPCs — the API call to the frontier model, the parsing of its response, and the eval of the elisp code to execute the response. All of these were piling up to make the models dumber. And ultimately, the August 2025 crop of frontier models couldn’t solve this problem. Or at any rate, the returns became so diminishing that I gave up.

So I paused the project! There was plenty of other work to do. A few months went by, a few model releases happened (notably Sonnet 4 and Sonnet 4.5). Efrit sat idle. And then about 2 weeks ago, someone asked to be an Efrit maintainer, since people wanted to use it. But wait, Efrit was still crap! So I thought, what the heck, let’s have Claude 4.5 peek at it.

Claude 4.5 took one look and said, “great idea, awful execution, but we can modernize this.” It produced an incredibly detailed plan to take Efrit to the next level, and I’ve spent the past 2 weeks letting it grind through this plan (serially, no swarming, since swarming on elisp sounds like a bad idea today.) And now Efrit is getting to be approximately on par with modern coding agents.

All I had to do, in order to crack this nut, was wait 3 months (i.e., 2 model releases). Claude is finding Efrit quite easy now, compared to this summer. I cite this as one of many examples of how the models and tools are indeed getting exponentially better. I have a set of projects they can’t do today. Efrit is (well, was) one of them. If you keep a menagerie of “too hard for AI” projects, then you will be able to watch and measure their cognitive progress increasing month by month.

I often bake this philosophy into my project planning. I will deliberately build something that’s just slightly too hard for the agents, knowing that in the next model release, they’re almost certainly going to find it straightforward. I plan for the models to get smarter, by building tools that don’t work that well with today’s models. This is how you get that little bit of extra shelf life out of your software — plan for it to be useful when smarter agents arrive.

If you read this section and concluded, “well, obviously AI isn’t ready to handle my project work; I tried it, it was confused, so I’m just going wait for smarter models,” then I wouldn’t blame you. But be careful! You might not need to wait as long as you think. If you’re just using this as an excuse to procrastinate until the models are smarter, then you’re missing out on honing a massive set of skills you need in order to work with models effectively — even as they do get smarter.

In the next section, we’ll talk about a way you can get even more cognition out of today’s models, without needing to wait. You’ll have them solve even harder problems than you thought they were capable of, all because you didn’t give them enough of a chance before. Let’s take a look!

5. The Rule of Five: When in doubt, have the agent review its own work 5 times.

Jeffrey Emanuel discovered this powerful and unintuitive rule. He found that he gets the best designs, the best plans, and the best implementations, all by forcing agents to review their proposals (and then their work) 4–5 times, at which point it “converges”. It typically takes 4 to 5 iterations before the agent declares that it’s as good as it can get.

Jeffrey described a long, complex series of prompts for this process; I’m sure we’d all be appreciative if he publishes them. But the way he described it to me, you first make them do a task, then you do a series of focused reviews. Each review should be slightly broader and more outlandish than the previous one, or you can do it the opposite order. But you need a mixture of in-the-small and in-the-large reviews. You’re having it look for bad code (or designs), but also bad architecture.

To be slightly more concrete, Jeffrey first asks it to do a couple of regular code reviews, which find all the usual stuff. And you’ll notice right away that even on the second review it will often find things it missed in the first review. But I think most of us stop there, if we even ask at all. It definitely feels weird to ask for the 3rd code review, which is the agent’s 4th pass over the code, counting the generation step. But the 3rd review, especially during the Design phase, is where you start asking it existential questions about whether you’re doing the Right Thing throughout the project.

I tried it, and sure enough, it does take 4–5 iterations, just as Jeffrey described, before the agent will say something like, “I think this is about as good as we can make it.” At that point it has converged. And that, folks, is the first point at which you can begin to moderately trust the output the agent has produced. If you always take the first thing it generates, with no review at all, you’re bound to be disappointed.

I asked Claude what it thought of this Rule of Five, and Claude was enthusiastically supportive. Claude claims that this process matches their own cognition model, which is breadth-first: they solve each problem first in very broad strokes. And then they almost always need more passes for proofreading, refining, and polishing — much like humans do.

At first you’re going to want to do this purely with prompting. Maybe Jeffrey Emanuel will share some of his fancy review prompts. But over time, you’re going to want to automate it, since you’re applying the Rule of Five at every single step in the process, which at a bare minimum, for any nontrivial hunk of work, would be:

- 5 passes over the design

- 5 passes over the Beads implementation plan (this results in far better issues and dependencies, and better execution)

- 5 passes over the implementation (code + 4 reviews)

- 5 passes over the tests

- 5 passes for code health (might as well build it into your dev middle loop)

Yes, this is slower. Yes, this is more expensive (though, probably less so than all the rework you’ll be stuck with if you skip these steps.) Yes, it’s awkward to tell an AI to keep reviewing its work that it just reviewed.

But you should make sure you do it. Rule of thumb: demand at least 2–3 passes on small tasks, and 4–5 passes on big tasks. If you’re not super familiar with the language, the stack, or the domain, then you should err on the side of more reviews.

Do this, and it’ll feel like you’re using a model from the future. They will do far better work than they’ve been doing for you. Try it!

6. Swarm where you can, but beware the Merge Wall

I’ve been focused on agent swarming the past few weeks, after several months chasing quality and reliability without much success. I’ve got a new (third!) orchestrator in the works, and wow. Swarming. Next year is going to be extraordinary.

I’ll share a quick example of how powerful swarming can be when it’s working right. I had a disaster the other day where 30 Beads issues went missing. It was three or four major epics, each with a bunch of child issues. I had put a ton of work into their design, following the Rule of Five, and they were all ready to implement.

But I couldn’t find them.

I wasn’t panicked, since it’s hard to truly lose issues in Beads (we do have some bugs here and there but they are getting closed fast). Beads is all backed by Git, so it’s almost always possible (for the AI) to reconstruct what really happened from the git history, and fix it.

But I was concerned, because, where the hell did my 30 issues go? They weren’t deleted. After a couple minutes of increasingly alarmed searching, I finally figured out where they all went: My swarm had implemented them all! WTF?

There was a minor miscommunication, I guess; I asked my orchestrator to start working on the bug backlog, and it assigned all 30 issues to the eight workers I had already spun up. Some of these were quite complex issues. But while I was busy with other stuff, and not watching, the worker agents implemented and closed all 30 issues.

I was equal parts delighted and flabbergasted when I realized what had happened. I went and checked, and sure enough, they’d done all the work. It was pretty decent work and needed very little touchup — likely because I had used the Rule of Five throughout, and the Beads were in very good shape when it came time to implement.

After my 30 issues were magically implemented, I was sold. I would never not swarm again!

And then, of course, I was utterly unable to reproduce that perfect swarm. Subsequent attempts all ran into merge issues and required a ton of hand-holding and infrastructure tweaks. It will be a couple more weeks before I can swarm reliably. But still, I am completely sold.

I’ll know that my swarm orchestrator is ready to launch when I can swarm the web UI, building it from scratch. My system doesn’t have a non-CLI UI yet; well actually it does, in Emacs, but I doubt you want that one, however cool it might be. (It has Efrit inside it, so it’s pretty damn cool.) But I’m going to build a UI with the swarm, and that’s when I’ll know it’s ready for prime time.

The thing you have to be prepared for when swarming, is the Merge Queue problem. It’s like smacking into a wall. To illustrate, let’s say you have a simple swarm of 3 workers. One worker is redoing the logging system, another is changing the database API, and another is changing the client-server protocol. It’s likely that all three of these subsystems have some overlap, and changing one requires changing another. And their work will collide when they try to merge all the work together.

When you swarm a task, a key problem is that the workers all start from the same baseline (e.g. the same starting git commit), and they all do their work off that baseline. But each worker has the ability to change the baseline dramatically. Let’s say workers A, B, and C all complete and merge in their work. The system may now be completely different from the original baseline. When the fourth agent D finishes its work, a rebase may no longer be feasible. The system may have changed so much that D’s work needs to be completely redesigned and reimplemented on the new system baseline, which includes A, B, and C’s changes.

This is why you need the Merge Queue. You need to serialize the rebases, and give each worker enough context, and context-window space, to fully merge their work into the new baseline.

Some work is inherently parallel, and some work is inherently serial — the latter because of irreducible complexity and task overlap. If you think you’re going to be stuck with an awful merge, then you should probably defer some tasks until the earlier ones complete. But it’s not always possible to tell in advance, so sometimes you’ll have tough merges.

I’ve noticed that projects tend to go through a cycle where they are swarmable for a while, but then you’ll suddenly need to pause and serialize all work for a time. This can happen, for instance, if you’re changing the directory layout of your project — e.g., to make it more accessible to AIs who are trying to guess their way around. You might need to experiment with a bunch of different layouts. But each new project source layout changes all your package imports, scripts and other inter-module references, which would totally break any existing workers. So you have to pause all other work while you do the big package restructuring.

You can think of swarming as a MapReduce-type operation. In the mapper phase, you can spin up virtually unlimited workers. But in the reducer phase you need to merge their work all back together. Unfortunately, as Gene observed, this isn’t really a MR because most MRs have a very simple reduce phase — the workstreams have a monoidal shape, and you can merge their work by doing things like summing counts or whatever.

But with agent swarming, the reduce phase is a nightmare; it’s the exact opposite, in fact: it can be arbitrarily complicated to merge the work of two agents. In the limit, what should we do if Worker A deleted an entire subsystem, and Worker B comes along with a bunch of changes to that (now-deleted) subsystem?

So the swarm merge step is often messy and not entirely automatable. Some cases require either human judgment, or else really good context for AIs to make the call.

I don’t know if we’re going to get a tool that hides the mess. I’ve been talking to investors, many of whom are keenly interested in the next generation of developer tools, and there is a prevailing belief that all we need are proper guardrails, and then these kinds of agentic coding and swarming tools will be accessible to “average” developers, which they certainly are NOT today.

And why is that? Well, as Joel Spolsky observed in Things You Should Never Do Part 1, reading code is by far the hardest part of coding. This is a well-known finding in the Dev Productivity world; they’ve done study after study. And with vibe coding, reading code is… pretty much all you do all day. It’s hard for most developers. The average dev probably thinks 5 paragraphs is an essay. Coding agents make you read enormous waterfalls of both text and code. This is absolutely draining and beyond the capabilities of most devs today.

However, I don’t see eye-to-eye with the investors on this one. I personally do NOT think we will get useful guardrails. If you try to build something with heavy guardrails, you’re going to wind up with Bolt or Lovable, and nobody will use it. Sorry! That’s just not the right model. Instead, I think we’re going to get orchestration tools that are every bit as powerful, messy, quirky, and frustrating as Claude Code and the current batch of terminal-based coding agents.

And the people who figure out how to use these tools, despite the lack of guardrails, will become super-engineers. I’ve been kicking around the idea of a new blog post, the Rise of the Superengineer. Dunno if it’s worth a whole post, but what’s going to happen in 2026 is that a new class of 100x (or maybe 1000x) engineer will emerge — people who have figured out how to wield coding agent orchestrators effectively, deal with the merge problem, planning, swarming, code health, etc. — all the stuff I’ve talked about here, and more. And they will be able to run 100 coding agents at once, and get meaningful work done with them.

This will make them as productive as a team of 50+ regular engineers.

I think my own orchestrator will usefully peak at around 50–80 agents. Maybe I can get it up to 100. It’s not aimed at massive swarms; it’s aimed at leveling you up from manually managing a dozen ad-hoc agents in ad-hoc repo clones all around your filesystem, to managing swarms of well-behaved agents working 5–10 at a time on focused tasks. It will still require your full attention, your full engineering background, and every bit of design taste you can muster, to use these tools. In some ways it’s even harder and more dangerous than using a single coding agent, even with tooling support.

But some people are doing it already! By hand, to be sure, or by building their own homegrown orchestrators. Mark my words, though: next year, you’re going to have engineers who can build an (and likely maintain) an entire company’s software on their own. You’ll have solo unicorns, sure, but also a marketplace of solo uber-contractors who can build companies things they would have had to pay someone like Accenture tens of millions of dollars for.

There will also be small teams of people who figure out how to maximize their velocity when multiple humans work with agent teams. And these small teams are going to change the world. Gene and I are actively wondering whether company size is going to decrease on average, because you will be able to get so much more done with so many fewer people.

But no matter what, the tools are going to be messy from now on. Working with AIs is a little messy and nondeterministic. And I think that’s here to stay.

Wrap-Up

Gene and I went through at least a baker’s dozen ideas this morning, and I’ve chosen the half that seemed the most baked. A few others are becoming clearer, but are still so vague that we don’t really have the right vocabulary to talk about them yet.

Change is coming. Agents are way more powerful than they were 3 months ago. I’ve talked with plenty of (good) engineers lately who still believe that agents have plateaued. Ignoring the 30 years of evidence showing that AI is following Moore’s Law, they feel it’s just going to stop getting better today, out of nowhere. And in their opinion, agents are not good enough yet.

But if you’ve been following and using agents since they landed in February, you’ll know just how much more powerful and capable they have become, even since summertime. It’s not plateauing; heck, it’s not even slowing down. And you can prove it using your backlog of projects that are too hard for AI. Every few months, another one will fall, until there are no more left.

If you’re one of the many engineers who still hasn’t made the switch to AI-first coding, now is a good time to try it again. If you haven’t used an agent in a few months, you’re going to be shocked at how smart and capable they have become. They are full concierges now, able to help you with any computing-related problem. People tell me they even use Beads for their personal TODO lists!

My orchestrator is right around the corner. I’m excited for it. It’s going to make a splash. Hopefully this Christmas!

But you’ll only be able to use it if you already use coding agents for literally everything. If you want to be a 100x super-engineer next year, you need to start learning vibe coding basics today, and make it work for you. Keep in mind all the advice I’ve given here, and read our Vibe Coding book, which just came out on Oct 21st. It’s fresh and relevant, and will help you get into the right mindset with the right techniques and practices.

More to come, soon.

This stuff is so fun!

Comments

Comments

Related Stories

Form

Function

TODO

Executing a contract

End of an era

Human Rights and Democracy Replaced by Profit

A Game Only the Wealthy Play

Hitting Europe

Please support my work—by taking out a premium subscription (just $6 per month).

The Virtual Reality Scenario

The Railroad Scenario

The third scenario: The Airline Scenario

Comments

Related Stories

All of the drawings and paintings here are from Old English Country Cottages - Special Winter Number of the Studio - 1906-7. The pen and ink drawings are by Sidney R. Jones.

Comments

Related Stories

Current fuel mix and uses

Energy mix and outlook

Primary production will be mostly solar

Batteries everywhere, the grid will shrink

Democratized battery ownership is good for freedom

Datacenters will be the nexus of electricity production growth

Datacenters will be net power sources for their communities

Solar datacenters will ultimately be pure DC constant voltage systems

Substantial cost improvements are needed to make space AI competitive

Electricity power markets should evolve toward real time and local prices

Seasonal load variation – summer

Seasonal load variation – winter

Synthetic fuel is our path to chemical energy abundance

Hydrocarbon usage patterns will change a lot

The United Kingdom needs wind

Ultracheap solar power will eventually change mining

Coastal deserts will be irrigated with desalinated water

What have I missed?

Comments

Related Stories

Prework: building my intuition

Our AI adoption strategy

Documenting tips & tricks

Centralizing our prompts

Adopting standard platform

Other AI tooling

Metrics

Building internal agents

What has fueled adoption (especially for agents)

Configuring agents

Resolving foreign keys

Formatting

Logging and debugging

Biggest remaining gap: universal platform for accessing user-scope MCP servers

What’s next?

The Growing Value Of Practical Fitness For Daily Life

Nutrition That Supports Energy Instead Of Restricting It

Technology Is Becoming A Quiet Partner In Senior Living

Financial Planning That Protects Lifelong Independence

Support Systems That Strengthen Autonomy Instead Of Replacing It

Looking Ahead With Confidence

Comments

Related Stories

2021: Node.js introduces the node: protocol

2018: Deno introduces https imports

2022: Deno introduces the npm: protocol

2023: Deno introduces package.json support

2024: Deno introduces the jsr: protocol

2024: Deno moves away from HTTP imports

2025: The current messy state of affairs

Taking our turn

Everything about us

Comments

Comments

Related Stories

Comments

Related Stories

Comments

2021: Node.js introduces the `node:` protocol

2022: Deno introduces the `npm:` protocol

2024: Deno introduces the `jsr:` protocol