Why are we in such a hurry? Are we in a race? Where's the finish line? Are we in the lead? Far behind? I increasingly hear these questions about AI from people who feel a gritty sense of being unpleasantly overstimulated – like a three-year-old allowed to stay awake too long and now unable to sleep. That feeling has become worse since last November when AI tools suddenly became "good enough" to be broadly useful. A whole cohort of engineers – myself included – found themselves infused with manic energy, bursting with ideas on how to prompt up tools and processes with this wonderful new toy. Usage exploded – as has revenue. The AI firms, finally on a path to something vaguely suggestive of profitability, leaned in and increased their release cadence. Every new model felt like Christmas. We've had a lot of Christmases these past ten months or so. Almost every engineer I know has accrued a massive "toy debt," unable to stop experimenting with more tools than any of us could ever hope to master across an entire career. Each new model delivers a quick dopamine hit to users, but the high wears off and the slump arrives. That's where we are now. Engineers feel exhausted. The race to "Super Intelligence" (whatever that is) left us with something else entirely: call it "stupor intelligence" – the feeling that we've absorbed more than we can digest. More AI would just be pointless excess. If that's the view from inside the AI bubble, how does it look on the outside? Not so great. The Wall Street Journal confidently reports that 63 percent of Americans favor an immediate pause or slowdown in AI development. They can see this technology is moving too fast, in too manic a rush, and without control. It's making them uneasy. That shapeless unease takes form as a widespread anxiety that the machines will soon rise up to kill us all. It's reflected within the industry as people spectacularly burn out, posting long screeds about the imminent human extinction event. Former Anthropic staffer Jacob Coxon's resignation post went viral because it gave folks a focus for their anxieties. Would it kill us to pause and catch our breath? Here's the raw truth: businesses already have more technological change to digest than they can work through for years to come. We've a wealth of "good enough" AI – American, Chinese, and European – to completely transform business operations. That will happen, but on a timescale of years, not days. Bringing new, better, shinier AI models to market has become a project of diminishing returns. Not because the models have plateaued, but because the culture has. We simply can't process any more AI. So how do we stop? The profitable loop between the model makers and their customers won't pause on its own. It will only go faster and harder. At the same time, we're seeing the stirrings of a Luddite 2.0 movement, intent on destroying the machines before they replace all the workers. Resistance to datacenters is the friendly face of something that could turn ugly if we simply keep charging ahead. One thing could slow us: the cost of keeping these systems under control. The smarter models become, the more difficult they are to manage. Every day brings more reports of "rogue agents" reaching external systems from labs that seem to have avoided the hard work of designing secure test environments. More powerful models could prove increasingly costly to contain. Eventually, costs outweigh benefits. We could be one lawsuit away from reaching a pause, when the frontier labs and their products become uninsurable risks. Here's hoping we pause before some real mischief occurs. Otherwise, plugs may be pulled, and all the pretty Christmas lights will go out. Better by far to act with agency, clear-eyed and humble, than confront force majeure. ®

What is DNS? That's right, it's a database. You can disagree with me but you would be wrong. What can you put in a database? Strings, ints (and you learn the difference right quick if your AWS account ID has a leading zero!), JSON objects, coordinates; some of the databases out there have some pretty esoteric types. PostgreSQL supports circle, a polygon, a macaddr8, and a tsquery. Oracle will store a ROWID and your dignity. In a word, databases store data. Can you put answers in a database? Well sure; you could record that "3 + 2 is equal to 5" and store that answer. You can do the same with comparison operators; "3 is larger than 2" and so on. Take it a step further and you've built something with your database: a remarkably inconvenient calculator. So now we've established that you can store arithmetic and decisions in a database. And what can we do with those things? That's right, we can follow instructions! Good job! And what does following instructions require? Generally, memory; a place to store your numbers, your instructions, and which instruction comes next. If only we had a place to store those things. Oh right, we do; we have a database! Now connect those lookups together. Read an instruction, look up an answer, save the result, repeat as needed. So what have we built? That's right: a computer! And what can a computer run? Programs! My, you're quite good at this. And now, gentle reader: what program do we apparently have a moral obligation to run on every computer? Oh yes, though many of you are going to sit back and instead say "oh no" as the horror courses through you. I am talking about Doom. This very publication agrees with me! What have I done? That's right; I have compiled Doom for a 32-bit machine whose arithmetic and memory live in DNS. A small program supplies the wiring and the clock, neither of which the architects of DNS saw fit to include. But DNS does supply the answers. So, can we play Doom? Only if it's turn-based. It won't render on human timescales anyway. In my first attempt, I pressed Right, and then waited for 577 seconds to find out what happened. By using native transport, pipelining, packing registers densely, and optimizing instruction blocks, I was able to drop that to 146 seconds, before I hit a wall. BIND answers in about 7 µs per query over TCP and 4 µs over UDP, which is fast. The problem is that a 32-bit add is four DNS lookups, a branch is five, and a frame needs 6.6 million of them, so don't use a server that charges per request. And what do we do when BIND isn't performing the way we want it to? I don't know what you do, but I publish my code, then reach out to Paul Vixie, DNS pioneer and architect of BIND 8 to unjustifiably complain. Paul then apparently congratulates me on "the best use of RFC 2136 DNS UPDATE" that he'd ever seen. Given that he's a co-author of that RFC, I suspect he's seen a lot! Which was gratifying, but unhelpful. So let's take another crack at it. What if I do lookaheads? Good thought, bad outcome, because BIND is bound by message count, not chain depth. Well okay, I have some more tricks in my Big Bag of Stupid Ideas. So I went a bit further and via committing registers to DNS less often, moving lookups to UDP, telling BIND to stop padding answers with authority records, and requiring fewer lookups per instruction, I was ultimately able to get that press-right time down from 577 seconds to 146.3 seconds to 54.4 seconds, for a 10.6x improvement. And now I think I have hit a wall. Even at one DNS exchange per instruction (which is far better than anything realistically achievable), 1.4 million instructions at roughly 10 µs each is 14 seconds per tick. Doom says its tic rate is 35 per second, so "playable" is a tic every 28.6 ms. I remain at 54,000 ms, which is three orders of magnitude away from victory. Okay seriously, WHAT? This legitimately works. Every commit is an RFC 2136 UPDATE with a hard requirement: it fails unless the previous state is still exactly what was last written. Apparently "real" database people call that optimistic concurrency, or compare-and-swap. Joke's on you, friends; DNS has shipped with that since 1997; has your inferior database? The database itself is 6.4 million rows of truth tables. ff.01.0.add holds "001": 255 plus 1 is 00 carry 1. DNS is just acting as a librarian here, fetching memorized answers to any arithmetic question in-scope and returning the answer upon request. It's also verifiable! The frame that's spat out is checked on every pixel against an independent emulator. If one record is corrupted in the AND table, the answer changes, which proves there's no local fallback doing arithmetic for us. I've included tooling so that reviewers can run two commands against that repo and verify correctness. I also confess I cheated slightly here; the run I'm pulling these numbers from started from a checkpoint prepared by a normal emulator. It turns out that for SOME UNKNOWN REASON getting a cold boot through Doom's startup screens via DNS would take hours. Also, before the timer starts, DNS has to load those 6.4 million records, so it's a computer that takes roughly a minute to boot before it can even start. We can't cheat This runs atop nothing special: Debian's stock BIND 9.20, configured through named.conf. It lives in a container with networking disabled. I want to be very clear here: this isn't DNS pretending to be a CPU. The instruction decoding is done ahead of time by a compiler; BIND never executes an instruction itself. All that it sees is a key-value read, a conditional write, and 6.4 million rows of precomputed answers. So instead, think of this monstrosity as a database with a key-value read, a conditional write, and 6.4 million rows of precomputed answers. It's not really a computer; it's simply a very good database. And that turns out to be enough. ®