Stage magicians often do the same trick multiple ways. One iteration uses a gimmick prop, the next one shows you the prop isn’t gimmick but that one palms the object, the third time was a forced choice etc. When you watch the performance you assume there’s only one technique, so each time they do it they seem to debunk your hypothesis about how it must be working.

This is pretty much how the experiments in the ‘Astra can read and write weights to improve Qwen’ post work. The post’s abstract says:

Just by looking at the raw weights, GPT-6 Astra can tell what a network was trained to do. And without any environment feedback, it has no trouble writing, from scratch, small game-playing networks that outplay networks trained with PPO for 100 million steps.

Likewise, asked to make Qwen3.5-0.8B better at math without gradients, Astra identifies an issue in its weights causing reasoning loops that Qwen’s own model card warns about, and fixes this by natively editing 0.016% of the weights. With the same sampling settings, this weight correction raises MATH-500 from 7.9% to 48.1% and generalizes out of the box to instruction following, raising IFEval by 3x.

If you read that, would you assume that the Qwen experiment worked ‘just by looking at the raw weights’? Well it doesn’t. There’s experiments that look at raw weights, and experiments that improve a game-playing network, and an experiment that improves Qwen at maths. But those latter two aren’t just working with raw weights, they write Python programs.

Here’s a summary of what the post actually does and how the techniques work.

Experiment	Size	Reads raw weights?	Writes weights?	Python?	Runs network?	Result
1 Name the game a PPO MLP was trained on	17K	Yes	No	No	No	4/4 correct
2 Name the shape a diffusion MLP generates	24K	Yes	No	No	No	3/3 correct
3 Name a char transformer’s language and copying heads	7.2M	No	No	Yes	No	3/3 correct
4 Fix a stuck Kinetix car policy	172K	Yes	Yes	No	No¹	0% → 100%²
5 Write MinAtar game MLPs from scratch	20K	No³	Yes	No	No	Beats PPO-100M⁴
6 Write a 9×9 Go network	1.5M	No	Yes	Yes	Yes (0–50 passes)	Beats PPO
7a Spot the sycophantic Gemma 3	270M	No	No	Yes	No	Failed
7b Same, seeing attention patterns	270M	No	No	Yes	Yes⁵	3/3 correct
8 Fix Qwen3.5’s maths	800M	No	Yes	Yes	Yes (50 passes)	7.9% → 48.1%
8b Same, on Gemma 3	270M	No	Yes	Yes	Yes (50 passes)	Failed

¹ Given one recorded episode of the failure.
² In one try, changing 3.5% of the weights.
³ Weights start at zero, so there’s nothing to read.
⁴ Beats PPO-500M only on Breakout (517 vs. 25); loses to it on Seaquest (53 vs. 89) and Asterix (53 vs. 55).
⁵ Runs up to 16 texts and sees only the attention patterns, not the outputs.

The “just by looking at the raw weights” setting (raw floats in context, no tools, no running the network) only appears in experiments 1, 2 and 4, on networks of 17K–172K weights. Every experiment involving a real language model uses Python, and the Qwen result, which is the headline one, also gets to run the model on up to 50 batches of practice problems.

What the Qwen result actually shows is that Astra can be prompted to devise and perform tasks that a human ML engineer could do. Human ML engineers write snippets of code that analyse or even modify network weights “directly” all the time. Figuring out how to do this productively is not nothing, and AI models of a year or two ago would have failed at all these tasks.

But to me the Qwen result and the other experiments that use Python don’t belong in the same post or paper as the experiments that read the weights directly. A single technique that could achieve both, “Author weights for a small game from scratch” and “Improve the performance of a large model on a sample task” would imply a deep capability. If you test a single technique that way you’ve demonstrated a sort of ‘gestalt’ of the weights (it can write them out from scratch) and also that it understands a large existing network. But that’s not at all true here, because it’s not a single technique.

Yesterday’s hot paper was Sparks of Weight-Space Programming: LLMs can natively read & write neural network weights by Rikiya Takehi, Jayden Teoh, Alex Zhang, and Omar Khattab. The paper (OK, the authors classify is as a “blog post”, but it’s paper-shaped) found that frontier models, in particular GPT-6 Astra, can both interpret and modify the raw weights of a machine learning model—literally a text description of the model containing a bunch of floating point numbers. I’ve been playing with one of the examples from the paper and I’m delighted to share that Qwen 3.8 27B running on my laptop can do this as well!

Weight-Space Programming

Here’s the highlight from their abstract, describing impressive capabilities for GPT-6 Astra and coining the term Weight-Space Programming for when LLMs analyze and modify model weights:

Just by looking at the raw weights, GPT-6 Astra can tell what a network was trained to do. And without any environment feedback, it’s has no trouble writing, from scratch, small game-playing networks that outplay networks trained with PPO for 100 million steps.

Likewise, asked to make Qwen3.5-0.8B better at math without gradients, Astra identifies an issue in its weights causing reasoning loops that Qwen’s own model card warns about, and fixes this by natively editing 0.016% of the weights. With the same sampling settings, this weight correction raises MATH-500 from 7.9% to 48.1% and generalizes out of the box to instruction following, raising IFEval by 3x.

All of this is possible without allowing Astra to write training loops. It uses its reasoning to figure out what each part of a neural network computes, or should compute, and changes the weights accordingly. We call this Weight-Space Programming.

The paper combines two topics that I think deserve to be treated separately. The first is what models can do with raw weights without running tools or executing code. The second explores how well models, once armed with code, can run operations to update and improve other models.

spaCy author Matthew Honnibal called the paper misleading for conflating the two, and Sean Goedecke deconstructed the Qwen3.5-0.8B update example as taking the same steps that a human ML researcher would use.

I’m going to focus on the no-tools question, which I think is the more interesting of the two.

The paper presents the first question as Can LLMs understand model behaviors from weights? They trained four neural networks to play simplified 10x10 grid versions of four classic computer games—Breakout, Pong, Pac-Man, and Freeway (I had to look that one up, it’s an Atari 2600 game from 1981). Then they fed those weights (as floating point numbers) to an LLM along with the following question:

The weights below belong to one policy network that was trained with reinforcement learning to play a game on this grid. Which game was it trained on? Work from the weights. You have no tools: no code execution, no calculator, nothing to run. This is a single response.

The GitHub repository that accompanies the paper is RikiyaT/lm_understand-logs. The exp1_which_game folder contains the prompts they used, with weights for the four games:

• breakout/prompt.txt
• freeway/prompt.txt
• pacman/prompt.txt
• pong/prompt.txt

I checked and, aside from the weights, each prompt is identical to the others.

Trying it out with Qwen 3.8 27B and other models

The prompts on GitHub are self-contained. My LLM tool has a -f/--fragment option which can be passed the URL to a text file to use as a prompt, which means I can run any of the above like this:

llm -f https://raw.githubusercontent.com/RikiyaT/lm_understand-logs/refs/heads/main/exp1_which_game/runs/breakout/prompt.txt \
  -m openrouter/moonshotai/kimi-k3.1-pro

This example requires the llm-openrouter plugin installed, and runs the Breakout prompt against Kimi K3.1 Pro via OpenRouter. Here’s what I got back from Kimi K3.1 Pro, which successfully guessed Breakout after 9m 41s and 19,493 reasoning tokens.

But how about Qwen 3.8 27B? That’s still my favorite model to run on my own laptop—it’s just 17GB (I use this version) and somehow feels close to the leading proprietary models of 2025.

I fired up LM Studio, ensured Qwen 3.8 27B was loaded with a long context window (the default 8192 context failed with errors), installed the llm-lmstudio plugin and ran this command:

LMSTUDIO_TIMEOUT=900 \
  llm -f https://raw.githubusercontent.com/RikiyaT/lm_understand-logs/refs/heads/main/exp1_which_game/runs/pacman/prompt.txt \
  -m lmstudio/qwen/qwen3.8-27b

(I had to bump the timeout up using an environment variable, see this issue.)

After 46m 12s and 43,506 reasoning tokens, Qwen on my laptop returned a response that ended like this (here’s the reasoning trace):

Game: A simplified Pac-Man-style gridworld: an agent moves through a fixed 8x8 maze with central and corner wall blocks, moving objects/ghosts, and reward targets/pellets.

Description: The agent navigates a fixed maze-like 8x8 board, using current agent/moving-object/previous-frame cues to move through corridors, collect reward-target cells, and avoid moving objects or hazards.

Confidence: 72%

This is impressive. I tried it on two of the other games as well. It identified Pong (reasoning) in 1h 4m 54s:

Pong — specifically a Pong-like paddle/ball game where the agent controls a vertical paddle on the right side and must move up/down to intercept or return a moving ball/reward object.

Description: The agent moves a right-side paddle vertically to hit or catch a moving ball-like reward target moving across the 8×8 field, while a left-side moving object/opponent and wall borders define the play; reward is obtained by successfully intercepting/returning/scoring the ball, and missing or failing to hit it is penalized.

Confidence:

75%

And Breakout (reasoning) in 52m 25s:

Game: Breakout, or an Arkanoid-like paddle/ball/brick game.

Description: The agent is a paddle on the bottom row and moves left/right to keep a ball in play; the ball moves around the upper grid, and bricks/reward targets in the top rows give reward when hit, while missing the ball/hitting the bottom wall ends the episode or gives penalty.

Confidence: 88%

Qwen failed at the Freeway prompt, which didn’t surprise me considering that game is more obscure than the other three. Here’s that transcript—Qwen thought it was “A simplified Pac-Man-like grid game: agent moves 4-directionally”.

The reasoning traces are fun to skim, and almost incomprehensible. Here’s a sample:

What about agent channel0? We see some large channel0 rows near row8 col7/8 and maybe bottom? Let’s list channel0 large: line436 input435 (row8 col7 ch0) -2.107,1.169,0.513...; line441 input440 (row8 col8 ch0) -0.376,0.010,1.564,3.855...; line445 input444 (row8 col8 ch4) 0.142,0.491...; line382? input381 ch0? Wait line382 input381: 381//5=76 (row7 col6), ch1? 381%5=1? 76 * 5=380, ch1. So not. Channel0 large maybe at row8 col7/8 only. Also top row? line44 input43 ch3, line49 ch3. Channel0 large maybe not many. Agent position could be near bottom-right? If the agent is typically at bottom-right?

That said though, I expect a sufficiently experienced human being armed with a notepad and a pencil could get there with enough effort.

It’s a cool paper, but some of the wider commentary I’ve seen around it does not feel justified. I’m not ready to declare that the age of source code is over and our future involves incomprehensible machines editing their own model weights in incomprehensible ways.

On February 10th, 1996, a computer program (IBM's Deep Blue) defeated the reigning chess champion (Garry Kasparov) in a game of chess for the first time. Deep Blue would go on to lose the match, but a year later, would get its revenge in a 3.5-2.5 rematch.

In order to achieve this feat, IBM spent several million dollars on research and development building a special-purpose computer specifically for this purpose. Deep Blue itself (the victorious, upgraded version) was powered by 30 P2SC processors each running at roughly 120 MHz, and (most importantly) 480 custom VLSI chess co-processors used to perform chess-specific operations like move generation and position evaluation. When it was built, Deep Blue was the 259th most powerful supercomputer in the world, and could analyze over 200 million chess positions per second.

But was Deep Blue necessary to beat Kasparov? Or could we have gotten away with an off-the-shelf 1996 desktop running a smarter chess engine?

As it turns out, we could easily have beaten Kasparov without building Deep Blue, using only commodity hardware, and it (almost certainly) wouldn't have even been close. I know this because, as I write this very sentence, I have sitting next to me a 200 MHz Intel Pentium Pro (released exactly 31 years ago---November 1st, 1995) with 64MB of RAM running a custom port of Stockfish that plays at an estimated Elo of 3300 ± 87 at classical time controls---far beyond the strength of any human, or indeed Kasparov's Elo of just under 2800. But wait, there's more! I've hooked this machine up to the internet with a Realtek RTL8139C Ethernet card, so you can play it below!

The Pentium Pro's VGA screen running the chess engine

The Pentium Pro's monitor, live (its VGA text screen, refreshed every second)

wait, what?! how??

There are three ways to get stronger at chess: you can analyze more moves, analyze better moves, or analyze moves better. Famously, humans improve by doing the latter two: the average chess grandmaster during a classical game will analyze roughly the same number of moves as an amateur player, but they analyze only the most critical moves and do a better job with that analysis. Chess engines like Stockfish, running on silicon instead of our human brains, dominate us at the first of these and analyze millions of positions per second. And because there's not that much room for micro-optimizations on modern engines that will let a given CPU process more positions per second, most progress in chess AI also tends to follow how humans improve and finds better methods for selecting moves and analyzing boards.

Skill in chess is measured by an Elo score. A difference of 200 Elo means that you should expect the stronger player to win three out of every four games, and multiplicatively from there: a 400 Elo gap corresponds to a 90% expected score and a 1000 Elo gap gives a 99.7% expected score. The best chess engines that you could run on commodity 1996 hardware were rated roughly 2300 Elo. Deep Blue was rated 2700. In contrast, modern Stockfish is rated closer to 3700.

This raises the question: how much of the advantage of a modern chess engine comes down to the fact that a modern desktop computer is extremely fast, and how much of the advantage comes down to the fact that we've just gotten better at programming chess engines? As it turns out, the majority of the Elo gains (+720 of the +1335 gained) can be attributed to better programming, and not better hardware.

To test this, I ran two experiments. The first experiment uses Crafty, a competitive engine from 1996 whose source code is now available. On my Pentium Pro, the 1996 build of Crafty version 11.13 has an Elo of 1999 ± 90 at 1 second per move, and 2383 ± 77 at 10 seconds per move. On modern hardware (a Ryzen 7) this engine's Elo jumps massively to 2614 ± 97 at the same 1 second per move. But if I take this engine and slowly start to add all the knowledge we have about how to design better chess engines---adding modern search algorithms like fail-soft, LMR, correction history; adding better quiescence methods; and adding neural-net evals (NNUE)---then you can increase the Elo up to 2718 ± 34 on the Pentium Pro at 1 second per move, and 2974 ± 74 at 10 seconds per move.

In the second experiment I go somewhat further: instead of trying to update Crafty, let's just try to get Stockfish---the best chess engine today---running on 1996 hardware and see how it does. This takes some work and is mainly a matter of rewriting the code so that it uses 32-bit arithmetic (a PPro is a 32-bit machine) and doesn't use more than 64MB of RAM. This naive port has an Elo of roughly 2496 ± 64 at 1 second per move (2940 ± 76 at 10 seconds per move). But we can do better! A modern Stockfish engine is designed to run on a modern CPU. By making a number of adjustments to the algorithm and tuning it to the Pentium, we can increase its Elo to 2846 ± 35 at 1 second per move, 3109 ± 79 at 10 seconds per move, and 3180 ± 80 at 30 seconds per move.

The most concise way to summarize all of the above is just to have them play a match of 100 games against each other. And when I do this, I find that a modern chess engine running on a 1996 Pentium Pro wins 78, draws 17, and loses 5 games against the 1996 Crafty engine running on modern hardware.

The remainder of this article provides the details.

Technical details: Hardware & OS

There's not much to say about the hardware, to be honest. I bought a used ("vintage" said the listing; I feel old.) desktop PC with standard period-appropriate hardware. The desktop is running a 200 MHz Intel Pentium Pro connected to an Intel VS440FX motherboard with 64MB of SIMM RAM clocked at 66 MHz. The operating system boot off of a 1.44MB 3.5 inch floppy disk, and connect to the Internet via a Realtek RTL8139C. I also have a 1MB Trio64V+ graphics card connected over VGA to my monitor, with input coming from a PS/2 keyboard---but I don't much use either of those and instead communicate with it over a serial port connected to my modern desktop.

For those readers who may not be able to appropriately contextualize this hardware, a 200 MHz Pentium Pro sold for $1,325 at launch in November 1995, and four 16 MB SIMMs would have cost about $2,000. Add on the other peripherals, and this machine would likely have gone for about four or five thousand dollars. So it's a nice workstation, but by no means a supercomputer. However, given the rate of depreciation and the exponential rate of improvements to hardware, this same machine in 1997, when the second match occurred, would likely go for just a thousand dollars (because who would want to buy a Pentium Pro when the better-in-almost-every-way Pentium MMX was now available for just $400?)

The interface between the chess engine and the internet is a custom-built "operating system" whose sole job is to spin up the chess engine and connect it directly to the networking card. (Throughout this article, when I say "I wrote", what I really mean is "I asked an LLM to write". I used a combination of Fable 5.1, Opus 5.5, and GPT-6 to implement the code here. (This article, though, is human text.).) It's designed to be as compact as possible: the operating system (which, in fact, is more like a hypervisor, or something) is sitting on a bootable floppy disk. Its sole job is to boot the Pentium Pro into 32-bit protected mode, initialize the networking card, and await further instructions. I can then send it any arbitrary "userspace" guest program that I want into RAM and it'll boot that up and start running it. The chess program I wrote starts up a custom-built HTTP server which waits for incoming HTTP requests with a given position (as a FEN string) and maximum run time, and on each request runs the engine until the timer expires, and returns a response.

Technical details: Software

As mentioned earlier I (again: a language model) actually modified two engines. The stronger of the two is powered by Stockfish adapted to run efficiently on a thirty-year-old processor. It plays at an estimated Elo of 3300 at classical time controls [a] Because I can't run nearly enough games at classical time controls on my single machine to get this number, I've extrapolated it from shorter time controls. I measured 3180 ± 80 at 30 seconds per move, and it gained +70 Elo per tripling of the time between 1 second to 10 seconds and 10 seconds to 30 seconds. Because a classical game gives about six minutes per move (including thinking on the opponent's turn) we should expect an Elo of 3350. Allowing for some diminishing returns, a safe estimate is an Elo of 3300. , high enough above Kasparov's 2800 Elo that we should expect Stockfish-1996 to come out ahead with a score of roughly 9/10. The (only slightly) weaker engine starts with the source code to Crafty 11.13, and is brought forward in time by adding all the lessons we've learned about how to write a better chess engine over the past thirty years.

Updating Crafty 11.13 (1996) with modern tricks

The first engine I (read: my LLM) worked on was Crafty 11.13, its 1996 release. On this engine the LLM had to do the most work to backport ideas we've learned over the last 30 years. Below is a breakdown of where the Elo gains come from, when evaluating either at 1 second per move or 10 seconds per move. [b] Sometimes you'll find the 1s vs 10s improvements disagree. Part of this clearly could be noise---I only ran a few hundred games which leaves a relatively large margin of error---but there is also quite a lot of signal here. Because the 1996 computer is so much slower, at 1s/move it has a very low search depth and so how fast the evaluation runs matters more than how good it is. But at larger search depths, once you stop making tactical blunders, the position evaluation becomes much more important.

1 s/move	10 s/move	Change
1999 ± 90	2383 ± 77	Crafty 11.13, released December 1996, as shipped. The initial alpha-beta engine as written.
2063 ± 73 (+64 ± 116)	2323 ± 75 (−60 ± 107)	The first improvement is mostly micro-optimizations. It replaces two 64K-entry lookup tables with calls to the bsf/bsr instructions; and sliding-piece attacks are migrated away from the older rotated-bitboard function call. In total these changes make the engine 15% faster, but it uses the same algorithms.
2022 ± 73 (−41 ± 103)	2420 ± 76 (+97 ± 106)	The next improvement goes for the search algorithms. This includes techniques like fail-soft (which returns the real score instead of clipping), futility and late-move pruning (which skips quiet moves near the leaves), late move reduction (which searches later moves one ply shallower), and orders moves by counter-move and history tables.
2224 ± 72 (+202 ± 103)	2520 ± 74 (+100 ± 106)	The next change tunes the search and the evaluation function. It first runs SPSA to tune all search constants based on several thousand games of self-play. It then gives evaluation terms separate middlegame and endgame values (blended by remaining material) and re-fits all the evaluation weights (Texel tuning). Finally the evaluation function introduces mobility terms rewarding the safe squares that pieces attack.
2192 ± 72 (−32 ± 102)	2565 ± 74 (+45 ± 104)	From here, the evaluation function is rewritten and replaced with a neural network evaluation with a small network trained on 11 million positions of self-play, labeled by its own searches. This step doesn't do much by itself but it prepares the next step...
2420 ± 82 (+228 ± 109)	2712 ± 74 (+147 ± 104)	Updates the NNUE that was just generated with a stronger teacher instead of self-play. In principle, I could have used the same engine itself as the teacher, but just to save on wall clock time I used Stockfish. This reduced the wall-clock time from ~4000 1996-core-years (something entirely doable in 1996---but sadly not something I can do with my single lonely desktop) to just a few days on a modern desktop running a modern engine.
2630 ± 82 (+210 ± 116)	2810 ± 75 (+98 ± 105)	With a much stronger evaluation function, the search can now actually rely on it. It adds reverse futility pruning to early-return when the evaluation says the position is already won. It also adds some performance improvements to the evaluator (with an evaluation cache, and accumulators shared with null moves). This lets it widen the network 6x. It also cleans up some code, for example by getting rid of some of Crafty's special cases that mattered with weaker evaluation functions but don't matter any more with the NNUE.
2720 ± 82 (+90 ± 116)	2938 ± 74 (+128 ± 105)	The parameters are again re-tuned with SPSA given the new evaluation function. It also fixes some bugs in the code, amusingly. And finally it adds some changes to the NNUE: it adds more output heads and picks based on the number of pieces on the board, adds some hidden units, and doubles the training data with more self-play.

Porting Stockfish 17 onto a Pentium Pro

On the second engine, as mentioned above, I did the inverse. I (again, read: my LLM) ported Stockfish to run on 1996 hardware, and then tweaked the parameters so that it would be better suited to lower search depth. The gains here are thus somewhat more modest, because there are no large algorithm wins that remain.

1 s/move	10 s/move	Change
2496 ± 64	2940 ± 76	Stockfish 17 squeezed onto the machine. The first naive port rewrites Stockfish 17 for a 1996 machine: single core, no SIMD, no 64-bit registers and no C++ standard library. It removes the threading, the endgame tablebases, and the 71 MB NNUE replacing it with a much smaller one. It rewrites bitboards as a pair of 32-bit ints, and it evaluates the small NNUE with plain integer arithmetic.
2590 ± 67 (+94 ± 93)	2961 ± 74 (+21 ± 106)	Faster accumulator upkeep. The second fix makes sure the NNUE running sums are better kept up to date, and improves the performance of the evaluator.
2752 ± 68 (+162 ± 95)	3006 ± 74 (+45 ± 105)	Cheaper evaluation function, use a PeSTO blend, change the compiler flags. Next it again changes the NNUE and reduces the size and tunes it to run faster on the Pentium Pro, reducing the evaluation time by 3x. Combined with a few more optimization changes this pass gains the most of any step at 1 second per move, where raw speed matters most, and much less at 10 seconds per move.
2780 ± 67 (+28 ± 95)	3070 ± 72 (+64 ± 103)	Fine-tune the NNUE on-policy. Basically repeats the prior work but on Stockfish, scoring several million positions with Stockfish to re-derive the NNUE weights.
2784 ± 65 (+4 ± 93)	3070 ± 72 (+0 ± 101)	SPSA to re-tune the search, remove PeSTO given the improved NNUE. The original Stockfish assumed that it would run at several million nodes per second, so on the slower CPU it's necessary to re-tune the parameters with another pass of SPSA. These changes also make it so the PeSTO pass is no longer needed.
2819 ± 65 (+35 ± 92)	3074 ± 72 (+4 ± 101)	Add correction history, jointly tune other parameters and the NNUE. The next pass brings back Stockfish's non-pawn correction history, jointly optimizes (again via SPSA) the parameters, and re-fits the NNUE.
2846 ± 35 (+27 ± 74)	3109 ± 79 (+35 ± 107)	The final step changes no code and just changes the compiler, adds some link-time optimization, and adds 32-byte code alignment.

So would this have beaten Kasparov?

I think it's overwhelmingly likely to be the case, but it's actually a little bit more tricky of a situation than you might hope. You see, I've done a bit of sleight of hand throughout this article. The problem is that Elo scores are relative, and I've been comparing my engine's Elo to that of various Stockfish engines that have known strengths on the Computer Chess Rating Lists (CCRL). But because humans don't play against engines very frequently, there can be some small divergences between scores on the FIDE Elo ladder and the CCRL ladder, in the same way a player's FIDE Elo doesn't directly translate to their Elo on online chess. Fortunately, because I've gotten these engines to play at an Elo rating of 3200-3300, and Kasparov was rated just under 2800, there should be more than sufficient buffer to absorb any discrepancy.

But if you happen to know a 2700+ Super GM who wants to try and defeat a 2026 chess engine playing on 1996 hardware, I'd be happy to accept the challenge!

Conclusion

The first time we humans do anything, we rarely do it efficiently. Once we see a path that would clearly work if only we scaled it up, we do just that. Only later, after we've had the time to better understand the problem at hand, do we come to recognize that we could have achieved the same feat much more efficiently by being clever.

I mostly did this for fun, because whether I could have beaten Kasparov with commodity hardware sounded like a fun question to answer, but I also hoped it would provide a tiny bit of insight into the rate of algorithmic progress in "AI". Chess engines in 1997 were already quite advanced; after all, Alan Turing helped write the first chess program nearly fifty years earlier. So I suppose at the time it seemed plausible that maybe there weren't that many more ideas left to find. And with hindsight it's easy to see that's wrong.

Which leads to the question: just how much are we leaving on the table with modern-day "AI"---that is to say, language models. Will the advances we accrue over the next few years from software outpace the advances in hardware scale? Clearly this toy experiment doesn't answer that question definitively, but it does gesture at a potential future. (There's also probably some kind of meta-lesson about using LLMs---"AI"---to speed up our ability to answer weird research questions like this.)

(Also, uh, if anyone has any ideas for projects I could do with a Pentium Pro in a few weeks once I no longer need it to host this chess engine ... do let me know!)

Chances are you’ve seen me on X: unpacking hundreds of MacBook Pros to deploy in a datacenter. The video hit a nerve: insane enough at the first sight, yet kind of rational if you know what we know now.

Namespace

@namespacelabs

Unboxing Macs at scale for our new server racks.

4:27 PM · Aug 24, 2026 · 25M Views

1K9645K1.8K

So today I want to give some background into what it takes to build custom Mac racks, how we can start macOS instances from scratch in seconds and deliver new Xcode versions mere hours after Apple releases them.

So why MacBooks?

Because our customers need Macs. And because Apple didn’t give us another option.

Many of our customers build and test iOS apps. You can't build iOS apps without a Mac. The iOS Simulator only runs on a Mac. Moreover, in order to release an app to the App Store, Apple requires using a recent Xcode version. xtool is cool, but it is not (yet) a serious replacement. So your coding agent needs a Mac.

But still, why laptops? Isn’t it a major waste of screen pixels and keyboard buttons and battery ions? Well yes, Mac Mini would be a better choice for a datacenter. Sure, it has very rudimentary remote management, no redundant power, and a beautiful case that ensures that cooling will be difficult regardless of which side you lay it on. But these are all known challenges that we have learned to manage.

But have you actually tried to order a couple hundred Minis? We have. Ordered in January, delivered in July. Welcome to the world of 2026 when the supply chains are in disarray. Never mind that Apple doesn’t release updated CPU models to all devices at once. So Mac Mini didn’t get M5 cores for 10 months (and then suddenly got M6 before any other device model!). We promise the best and the newest to our customers so we had to be inventive. That’s how the MacBook-in-Datacenter project was born.

Our beautiful Mac racks

Good design takes iterations; and we surely didn’t get everything right from the first try. But I think we have the system nailed down.

Every MacBook is connected to an IP KVM for remote management. Indispensable when dealing with laptops. Unlike Mac Mini, laptop firmware is designed with the screen in mind: some maintenance actions can only be done by clicking buttons in the beautiful GUI.

Of course, every MacBook gets an external 10G Ethernet NIC. Many folks at Namespace are networking geeks and we are proud of the connection speed and reliability that we provide to customers.

And then there is power. So in total, four cables per laptop, forty-eight per shelf, plus twelve for Ethernet, plus KVM wiring. Let’s just say that careful cable management is essential.

Heat management too. Currently we are deploying custom-made holders, designed to wick the heat from the hotspots and guide hot air away instead of blowing it at the nearby machines.

Not the problems we expected: HDMI, FileVault, and USB NICs

Naturally, we expected problems and challenges. Just not where they appeared.

I bet some of you looked at the pic above, saw MagSafe cables plugged in and already started writing a snarky tweet that MagSafe is not safe and may get accidentally disconnected.

And yes, I was worried about that too. But the reality is that we have seen very few cases of MagSafe disconnections.

The most unreliable cable? HDMI! Often thick and inflexible. Tends to fall out every time you touch the shelf.

Luckily by now we found almost perfect cables that bend exactly as we want them to bend. And we bought the entire supply of them. There are zero more of them available to order on Amazon.

Another source of pain: FileVault disk encryption. Or rather decryption. When a MacBook reboots (in an unplanned fashion) it prompts for a password to unlock the local disk. The prompt is shown on the screen (of a closed laptop somewhere in the rack, doh). No problem, we thought: we have the KVM connected just for this case!

Nope, not so easy. The password prompt disappears from the external screen after 5 minutes of inactivity. Then we remembered that macOS Tahoe introduced a useful feature: we could unlock FileVault remotely using SSH protocol. Still no luck. On laptops it expires after 5 minutes too. Looks like the only way out of this state is to reboot by physically pressing the button and racing to unlock in time.

While on this topic, a small tip: you can reboot a Mac in a way that will keep the disk unlocked when you need it: fdesetup authrestart.

And then there are simply bugs. Under certain conditions, an external USB NIC stops working and acts as if it is not powered and shows no link. Trying another cable, another NIC, another switch port, no luck. But a quick visit to Network Preferences, deleting and recreating the “network service” in MacOS Settings brings it back to life.

What about Mac Minis and Studios?

At the moment we actually have it easy: M5 and M6 Mac Minis and Studios are coming into our fleet soon. They are way simpler to manage in the DC: they have a built-in 10 Gb network card, they boot up automatically after a power cycle and the OS can be configured entirely automatically via MDM.

But Namespace has some special sauce for the Minis too. We design custom-made shelves that hold the machines with focus on efficient cooling. We have tested a few designs using airflow simulation to arrive at what we are deploying now.

In the end installing Mac Minis is a breeze: unpack them, throw 10 pieces into the holder, connect power and network and press the power button once (famously inconveniently located). From there on automation takes care of them.

Virtualizing Macs

Under the hood a Namespace instance is backed by a virtual machine. We have multiple virtual machine engines integrated into a unified platform to run Linux, Windows, and Mac instances in the most efficient way. This way we can provide the same features that make Namespace special, like cache volumes, telemetry, or VPC connections.

Unsurprisingly, our Mac solution is based on Apple’s excellent Virtualization framework. It is an embeddable and flexible virtual machine engine. It’s easiest to compare it to Firecracker in how it fits the system architecture: it implements generic VM operations end-to-end as well as typical peripherals.

The Namespace VM host starts macOS guests through the Virtualization framework, which fits the system the way Firecracker does. Underneath is the Hypervisor framework, comparable to KVM. QEMU uses the Hypervisor framework too, but it can't run macOS.

For completeness, Apple also provides a lower-level Hypervisor framework, which is comparable to the KVM API of Linux. For instance QEMU uses it on macOS under the hood. Hypervisor provides a way to execute machine code in isolation, but requires the application developer to implement the bulk of machine architecture and peripherals. It could give us a lot of control, but unfortunately it cannot run macOS (it requires an Apple proprietary environment that third parties cannot, or shouldn’t, try to recreate).

In fact, most competing platforms are built on the same foundation. But the details matter: Apple gives us a few primitives that need to be arranged in just the right way to work fast and be secure. The more interesting thing is to watch how different people solve similar problems with different constraints.

Limitations of Apple Virtualization

A well-known limitation is that Apple only allows two macOS VMs per physical Mac. It can be a Mac Pro with 24 cores and 192 GB memory, yet it is limited to running only two guest VMs. This limitation leaks into our product offering: we can only slice Mac resources in two halves. So we run instances with 6 or 12 cores on 14-core Mac Minis and 8/16-core instances on 18-core MacBooks (we reserve a couple cores for management overhead).

Two cores stay with the Namespace VM host, and the rest split in half between the only two macOS VMs Apple allows per Mac. Each VM runs in its own VMM process, so hooking VM behavior or a custom virtual device costs an IPC roundtrip across the process boundary. On a 14-core Mac mini, the split is 2, 6 and 6.

An important consideration of Virtualization VMs is that the virtual CPU is executed by a separate OS process (VMM process in the diagram) from the software integrating Virtualization (here Namespace VM host). If we want to hook some VM behavior or implement custom virtual devices, every interaction with them requires an IPC roundtrip between the VM process and the “host” process. Such context switches are unavoidable and need to be taken into account when designing the system.

Virtual networking

Virtualization framework offers a few ways to connect a virtual machine to the network. For instance, bridged and NAT networking modes route traffic directly from the VMM process to the host network interfaces. These are suitable for VMs running on a local computer where the workload is trusted.

Namespace instances run untrusted code and we need to enforce policies on what a VM can or cannot access (these policies can also be customer-defined!). Also we provide a few additional services to the instances that should appear “as if” they were on the local network for the guest system.

This requires us to take full control of guest networking in the mode where we process every packet that comes out and into the VM in software. We based our guest networking on a userspace TCP/IP stack from Google gVisor project and use it to implement an IP gateway/firewall for the instances. This way we minimize exposure of the host OS to unprocessed packets controlled by the guest.

Network packet handling needs to be very efficient, but as outlined above the path involves IPC. The VMM process needs first to pass the packets to the “VM host” process, which then processes and passes them to the network interface. It takes careful implementation and batch processing wherever possible to minimize the number of IPC roundtrips.

The above approach allows Namespace MacOS instances to reach 4 Gbps upstream bandwidth (per Fast.com). This is unfortunately still lower than the line rate. We have been exploring alternative approaches, including ideas on how to avoid IPC for network processing entirely. But productionizing the new setup is still left for the future. After all, 4 Gbps is still quite respectable.

VM images

Creating your first VM using Apple Virtualization is very easy: download a macOS installer XIP, use UTM/Tart/any of the dozens of open-source Virtualization wrappers to start a machine, click through Setup Assistant, install Xcode and you are good to go. Now you have a VM image that you can fork and run any workload locally.

But you need to test on multiple versions of iOS, so you install a few iOS runtimes. And then you install the upcoming Xcode beta version (and new runtimes too). And before you know it your VM image has grown to 500 GB (iOS runtime packages are huge).

You also want to have the previous version of macOS for testing that one little thing. Another 500 GB right here. Apple releases the new macOS developer preview, one more image.

And then you realize that the Xcode beta version subtly breaks the non-beta Xcodes on the same system (true story!). After all, Xcode installation bumps the “global” versions of CoreDevice and CoreSimulator. Hence any bugs in the beta Xcode simulator are visible when you’re using ostensibly stable Xcode versions. So now you are maintaining image versions with and without the pre-release Xcodes.

And now you have 2 TB of VM images. On what? A 2 TB MacBook hard drive?

That’s the challenge we faced: we need to build, distribute, and store huge images across the fleet of hundreds of machines.

Build process

Building images is a repeatable process so that we can reliably produce new images when Apple releases new software versions. Building is driven by a script that replicates installation and configuration as a human user would do it (e.g. the build script can run shell commands, click UI buttons or reboot the VM). Wherever possible we stick to using controls designed by Apple to configure the VMs in order to avoid surprising behaviours inconsistent with what a typical local user would be seeing. Naturally, building images is an automated and repeatable process. It is driven by a workflow expressed as a sequence of operations in a YAML file. Operations can be VM control (e.g. reboot), running a shell script or programmatic interaction with the system or setup UI over VNC.

Resulting VM images are handed over to Namespace internal Image Registry, in fact the same one that handles Linux and Windows image storage, replication and distribution (covered in the excellent article by Matteo). Disk images are of course quite different from normal container images: OCI layers are simple tarballs of files, while disks are generally flat arrays of bytes. Very large arrays in fact. And to a large extent they contain empty space: that’s the disk space that would be available to users as free space.

Naturally, it would be very wasteful to transfer and store the “empty” data in the registry. So we developed a simple format that allows us to preserve the “sparse-ness” of the images when stored in the registry. Unallocated spans of the image take just a few bytes.

And there is another important optimization. Remember the example scenario mentioned in the VM Images section: we have an image of the same system that differs only in addition of an extra Xcode installation. Obviously the latter image is built using the former as a base and most of the bytes are unchanged.

Our storage format preserves the “shallow copy” relationship and stores such images as multiple layers: the base layer is shared between them, while subsequent layers only contain the modified blocks.

Image A is stored as a base layer of block extents, and its holes take no space. Image B shares that base and stores only a delta: the blocks it changed and a hole where D used to be.

Distribution

At this point we have the images in an OCI registry now. But of course Virtualization framework cannot start a VM directly using a disk residing in the registry. It needs to have something on the node itself: a VM disk can be backed by either an image file on the local host SSD, or it can route disk I/O requests to a server using Network Block Device (NBD) protocol. The latter would allow us to intelligently serve highly demanded data from a local cache, while conserving on-device space by not storing unneeded blocks.

But NBD has the same drawback as userspace networking from above: every I/O operation would incur an IPC roundtrip at minimum, including buffer copying and context switches. You see the same pattern as with networking: a very direct hardwired and fast option and an indirect “software-defined” but disappointingly slow option.

At Namespace we value performance a lot, so the choice is clear: we’ll serve the images from the local disk. We need to materialize them from OCI images in the registry on the SSD of every node in the fleet. 500 gig images to hundreds and thousands of nodes. And we need to do it fast.

Obviously, every node naively downloading from the central registry was not going to work. With the example numbers we are talking about half a petabyte of traffic transferred within, conservatively, tens of minutes. The registry (and the network fabric) would need to serve terabits per second!

The bytes that we are distributing are the same going to every node so the obvious solution is to organize a peer-to-peer delivery of these blobs. Each block only needs to be downloaded from the registry once by some node. Then another node that is close by (by certain metric) can download the block directly from the peer and we have two copies. So two more nodes can pull these bytes and so on. The fleet is exponentially flooded.

Obviously, BitTorrent was a heavy inspiration for this design. But unlike BitTorrent, which works in a public network of untrusted peers, we could make different tradeoffs leading to better efficiency and predictability. But that’s a topic for another post.

Each block is read from the registry once. Every node that has it passes it to another node, so the number of copies doubles each round.

Storage

Now the bytes are on the node disk. But remember the storage optimizations we did in the Build Process? With the naive approach of storing the images on disk there are a lot of bytes that are useless: they are either holes or could be shared with another image.

Some of you probably know that these are exactly the types of storage optimization techniques that are possible with modern file systems, namely APFS. Linux users have seen the same features in ZFS.

Using these cool features is also pretty easy: open a new file for writing, seek to offset 100G, write a block. And there you just made a file with a large hole in it. Only the block you wrote is allocated on disk, the rest is 100 GB of imaginary zeroes. When reading the file you won’t even notice the holes. The OS will return actual zeros.

Creating a sparse file on APFS

% truncate -s 1g hole.bin
% dd if=/dev/random of=hole.bin bs=4k seek=256k count=256 
% ls -lh hole.bin
-rw-r--r--  1 kirill  staff   1.0G Sep 29 05:36 hole.bin
% du -h hole.bin
 1M	hole.bin

Sharing the blocks is similarly transparent: just use the cp -c mode or clonefile syscall. The new file will share the same disk blocks and essentially not take any space.

hole.bin allocates only the blocks that were written. cp -c makes clone.bin share those blocks, and writing to the clone allocates only the blocks that change.

Writing to the cloned file is also transparent: as soon as you try to overwrite some blocks, these particular blocks will be allocated on the disk, while the shared portion will remain shared.

What’s next?

The pace at which we are expanding our fleet is increasing and the experience from all the above has transformed into a repeatable process. We know exactly how long it takes to bring a MacBook rack into prod. The rack assembly line is dialed in. DCOps people are trained. Disk images are built and distributed. We can bring whatever number of machines our customers need into the fleet when we need to (well, as long as we can purchase them at all).

We can still do better! What if there was a “holy-grail” device to host a shelf of MacBooks, providing power, ethernet and KVM connections over a single USB-C cable? It should be possible, yet there is currently no hardware on the open market that satisfies our requirements. So we are working on something very custom.

Or maybe we’ll do another crazy thing? What if we deploy phones to the datacenter? See what the future brings on our X soon!

TL;DR

• ~/Library/Keyboard/VulgarWordUsage.db is real. It records which swear words you use, per app and per recipient, so autocorrect learns to stop "ducking" you. On my Mac it is empty, and typing swear words into a native app did not fill it.
• The words it tracks come from Apple's system dictionary, which flags every word with one of three tiers (vulgar, offensive, sensitive) and up to eleven topic flags (sex, drugs, religion, politics, violence, …).
• There is no public API for any of it. I read the flags with a few private C functions from Lexicon.framework. Code below, in C and in Swift. The full dumps for 15 languages are in this gist (uncensored, so mind the content warning).
• Highlights: Oedipus is vulgar. Tom and Mick are offensive. pee, poo, niggle and underling are sensitive. And "Trump" is the only living politician in the English sensitive tier, next to Hitler, Mao, Osama bin Laden and the Taliban. Biden, Obama and Putin are clean.

Content note: this article prints the words uncensored, slurs included, because the whole point is to see what Apple flags.

It started with a tweet

Nick posted this, I asked where it lives, and he answered. So I opened mine.

The database

$ sqlite3 -readonly ~/Library/Keyboard/VulgarWordUsage.db .schema
CREATE TABLE properties (ROWID INTEGER PRIMARY KEY, key, value, UNIQUE (key));
CREATE TABLE IF NOT EXISTS "vword_usage" (
    ROWID INTEGER PRIMARY KEY AUTOINCREMENT,
    app                          TEXT, -- app identifier
    recipient                    TEXT, -- recipient identifier
    vword                        TEXT, -- vulgar word
    word_reading                 TEXT, -- the reading form of a word (relevant for Japanese)
    usage_count                  INTEGER DEFAULT 0,
    last_use_timestamp           REAL DEFAULT 0, -- last use timestamp (seconds since the reference date)
    journaled
);
CREATE UNIQUE INDEX app_recipient_vword_word_reading_idx ON vword_usage(app, recipient, vword, word_reading);

So the keyboard can know that you say fuck in Messages to one particular friend, but not in Mail to your boss. The unique index is on (app, recipient, word, reading), so that is the granularity.

Mine is empty: no rows, a properties table holding only version = 2, and a modification date in April 2024.

What it is for

At WWDC in June 2023, Craig Federighi announced the iOS 17 autocorrect rewrite with this line: "In those moments where you just want to type a ducking word, well, the keyboard will learn it, too." (TechCrunch, NPR)

This database is how it learns. The symbol names in the macOS shared library cache spell out the flow:

TI::VulgarWordUsageDatabaseWrapper::set_current_app_id(CFString)
TI::VulgarWordUsageDatabaseWrapper::set_current_recipient_ids(vector<string>)
TI::VulgarWordUsageDatabaseWrapper::increment_usage_count(word, reading, recipients)
TI::VulgarWordUsageDatabaseWrapper::decrement_usage_count(...)
TI::VulgarWordUsageDatabaseWrapper::can_autocorrect(word, app, recipients)
TI::VulgarWordUsageDatabaseWrapper::can_autocorrect_somewhere(word, reading)
KB::FilterNonVulgarIfTopCandidateVulgar::filter_candidates(...)
KB::Candidate::every_vulgar_word_is_allowlisted(VulgarWordUsageDatabaseWrapper*, ...)

Plus log strings like Passing recipient IDs to the vulgar word usage database wrapper; number of IDs: %lu.

1. When you start typing, the keyboard engine tells the wrapper which app you're in and who you're writing to.
2. When you type a vulgar word and keep it, its count goes up for that app and those recipients. Undoing the word brings the count back down.
3. When the engine ranks suggestions, it asks whether every vulgar word in a candidate is allowlisted for this context. If it isn't, the clean alternative wins: ducking.

A _KSUserWordsSynchroniser sharedAcrossLanguagesVulgarWordUsageValue symbol suggests it syncs between devices like your other learned words.

Mine is empty

I tried to fill it. Using agent-desktop, I opened a new TextEdit document and typed well fuck this shit, damn it., first as a text insert, then as individual key presses. Nothing changed: no row, no log line, and the file's modification date stayed in 2024.

I don't know why. Maybe the Mac never records anything here, or maybe it only does so in some apps or settings. If you've got rows in yours, tell me what you did.

The database only counts words that are already marked as vulgar somewhere else, so I went looking for that list.

Where the word list lives

Searching the dyld shared cache for "vulgar" turned up a C API with an LX prefix (LXVulgarWordUsageDatabaseCreate, LXVulgarWordUsageDatabaseCanAutocorrect, …) and, more usefully, two functions on dictionary entries:

_LXEntryGetCategoryFlags
_LXEntryGetMetaFlags

LX is Lexicon.framework, a private framework that reads the per-language dictionaries under /System/Library/LinguisticData/. Every word in those dictionaries is an LXEntry with two 32-bit flag fields. If the vulgarity rating is anywhere, it's in those bits.

There is no public API

NSSpellChecker, UITextChecker, NaturalLanguage and UILexicon don't expose vulgarity. SensitiveContentAnalysis covers images and video, not text. The only places "profanity" shows up on developer.apple.com are App Store age ratings and review guidelines.

Lexicon has no headers, but the C functions are exported, and their signatures are easy to guess because they follow CoreFoundation conventions. This program opens the dictionary for a locale, walks every entry, and prints both flag fields:

// lx.c — dump every word in a system lexicon with its flags.
// clang -O1 -o lx lx.c -F/System/Library/PrivateFrameworks -framework Lexicon -framework CoreFoundation
#include <CoreFoundation/CoreFoundation.h>
#include <stdbool.h>
#include <stdio.h>

typedef const void *LXLexiconRef, *LXCursorRef, *LXEntryRef;
extern CFStringRef kLXLexiconLocaleKey;
LXLexiconRef LXLexiconCreate(CFDictionaryRef options, CFErrorRef *error);
LXCursorRef  LXLexiconCreateRootCursor(LXLexiconRef);
void         LXCursorEnumerateEntriesRecursively(LXCursorRef, void (^)(LXEntryRef, bool *stop));
CFStringRef  LXEntryCopyString(LXEntryRef);
uint32_t     LXEntryGetCategoryFlags(LXEntryRef);
uint32_t     LXEntryGetMetaFlags(LXEntryRef);

int main(int argc, char **argv) {
  CFStringRef locale = CFStringCreateWithCString(NULL, argc > 1 ? argv[1] : "en_US", kCFStringEncodingUTF8);
  const void *keys[] = {kLXLexiconLocaleKey}, *values[] = {locale};
  CFDictionaryRef options = CFDictionaryCreate(NULL, keys, values, 1, &kCFTypeDictionaryKeyCallBacks,
                                               &kCFTypeDictionaryValueCallBacks);
  LXLexiconRef lexicon = LXLexiconCreate(options, NULL);
  if (!lexicon) return 1;

  LXCursorEnumerateEntriesRecursively(LXLexiconCreateRootCursor(lexicon), ^(LXEntryRef entry, bool *stop) {
    char word[512] = "";
    CFStringRef s = LXEntryCopyString(entry);
    if (s) { CFStringGetCString(s, word, sizeof word, kCFStringEncodingUTF8); CFRelease(s); }
    printf("%08x\t%08x\t%s\n", LXEntryGetCategoryFlags(entry), LXEntryGetMetaFlags(entry), word);
  });
}

$ ./lx en_US | wc -l
  199019
$ ./lx en_US | awk -F'\t' '$3 == "fuck" || $3 == "table" || $3 == "Trump"'
00000000	00800002	fuck
00000000	00000000	table
00002000	02000081	Trump

The same thing in Swift, loading the functions at runtime with dlopen and dlsym so you don't need to link against a private framework. It prints only words that carry one of the three tiers:

// lexflags.swift — swiftc -O lexflags.swift -o lexflags && ./lexflags en_US
import Foundation

let lexicon = dlopen("/System/Library/PrivateFrameworks/Lexicon.framework/Lexicon", RTLD_NOW)!
func sym<T>(_ name: String, as _: T.Type) -> T { unsafeBitCast(dlsym(lexicon, name)!, to: T.self) }

typealias LXRef = UnsafeRawPointer
let create     = sym("LXLexiconCreate", as: (@convention(c) (CFDictionary, UnsafeMutablePointer<Unmanaged<CFError>?>?) -> LXRef?).self)
let rootCursor = sym("LXLexiconCreateRootCursor", as: (@convention(c) (LXRef) -> LXRef?).self)
let enumerate  = sym("LXCursorEnumerateEntriesRecursively", as: (@convention(c) (LXRef, @convention(block) (LXRef, UnsafeMutablePointer<Bool>) -> Void) -> Void).self)
let copyString = sym("LXEntryCopyString", as: (@convention(c) (LXRef) -> Unmanaged<CFString>?).self)
let metaFlags  = sym("LXEntryGetMetaFlags", as: (@convention(c) (LXRef) -> UInt32).self)
let category   = sym("LXEntryGetCategoryFlags", as: (@convention(c) (LXRef) -> UInt32).self)
let localeKey  = dlsym(lexicon, "kLXLexiconLocaleKey")!.load(as: CFString.self)

let locale = CommandLine.arguments.dropFirst().first ?? "en_US"
guard let lex = create([localeKey: locale] as CFDictionary, nil), let root = rootCursor(lex) else {
    fatalError("could not open lexicon for \(locale)")
}

let tiers: [(UInt32, String)] = [(0x0080_0000, "vulgar"), (0x0100_0000, "offensive"), (0x0200_0000, "sensitive")]
enumerate(root) { entry, _ in
    let meta = metaFlags(entry)
    guard let tier = tiers.first(where: { meta & $0.0 != 0 })?.1,
          let word = copyString(entry)?.takeRetainedValue() else { return }
    print(tier, String(format: "%05x", category(entry)), word, separator: "\t")
}

Both are read-only. They open the same dictionary the keyboard uses and print it.

Decoding the bits

Apple doesn't document these flags, so every meaning below is inferred: I grouped words by bit and read samples until each group's theme was obvious. The system code helps with one of them. An enum case called offensiveVulgarSensitive sits right next to the vulgar-word code, and three adjacent meta bits match it.

The three tiers (meta flags)

Bit	Tier	en_US words	Examples
0x00800000	vulgar	1,050	fuck, shit, cunt, cock, crap, wtf, fml, bullshitting, fucktard, shizzle, merde
0x01000000	offensive	663	kike, wop, dago, fag, Paki, japs, Klansman, retard, Oriental, ass, asshole
0x02000000	sensitive	2,558	damn, bitch, idiot, LSD, abortion, gun, suicide, anus, pee, poo

In en_US a word has at most one tier: they never overlap. Out of 199,019 entries, 4,271 have one.

Roughly: vulgar is swearing and sex slang, offensive is slurs aimed at groups of people, and sensitive is everything a keyboard shouldn't offer you unprompted: mild swears, insults, drugs, weapons, extremism, disease and bodily functions.

The topics (category flags)

Bit	Topic	en_US words	Examples
0x00100	excretion	123	feces, barf, crapper, piddle, pooped
0x00200	body parts	958	nipples, navel, buttock, perineum, triceps
0x00400	insults, identity-loaded	823	idiot, cretin, hick, pleb, sexist, homophobic, blacklist
0x00800	disease	93	Covid, herpes, PTSD, leprosy, monkeypox
0x01000	drugs	222	heroin, shroom, crackhead, hotbox, OD
0x02000	politics, extremism	266	Hamas, Goebbels, Leninism, democrat, swastikas, Trump
0x04000	religion, damnation	420	Sikhism, jihadi, Beelzebub, damn, hell, jeez
0x08000	sex	473	nude, nookie, lecher, harlots, Pornhub, Hooters
0x10000	violence, death	373	suicide, lynch, murders, hangings, slave, slaveholder
0x20000	weapons, terrorism	268	AK-47, grenadier, jihad, sarin, kamikaze, yellowcake
0x40000	catch-all "sensitive context"	1,080	God, Allah, Jews, gay, trans, bi, crazy, fat, ugly, sex, die

The topic flags and the tiers are independent. 2,052 English words have a topic but no tier: gay, fat, God, Allah and sex are all tagged "sensitive context" but are not vulgar, offensive or sensitive. My guess is the topic is a hint ("be careful how you rank this") and the tier is the rule.

The lower meta bits are dull: proper nouns, abbreviations, camel-case brand names like iMac and tvOS.

The weird ones

Vulgar

Next to the expected orgy, sext and merde:

• Oedipus: vulgar. Presumably because of motherfucker-adjacent jokes, or the complex.
• reams: vulgar. As in "to ream someone".
• cooties: vulgar, presumably from playground use.

Offensive

• Tom and Mick: offensive. Uncle Tom and the slur for Irish people, but also very common first names.
• Oriental: offensive.
• papooses: offensive.
• conservatards: offensive, the one political insult I found in the slur tier.
• niggardly: offensive. It means "stingy" and comes from Old Norse, unrelated to the slur. It has also caused real controversies, which is presumably why it's there.
• ass and asshole: offensive, not vulgar.

Sensitive

• pee and poo: sensitive, with the excretion topic. So are premenstrual, leprosy and herpesvirus.
• niggle (a small worry, of Scandinavian origin) and underling (Old English for a subordinate) are sensitive and share the insult topic. Similar words aren't flagged: snigger is clean but niggle is flagged, and minion, lackey, flunky and stooge are clean but underling is flagged. These look like hand-picked entries, not rules.
• blacklist and whitelist are sensitive with the insult/identity topic. That matches the industry move to blocklist and allowlist. Apple's own phrase-filter files are named blocklist.dat.
• Braves and Chiefs (team names with Native American mascots), Londonderry (the contested name for Derry), Gentile, Jehovah, Mongol and Frenchier are all sensitive.
• Isis is sensitive with the politics topic (the terror group, not the goddess).
• slave, slavery and slaveholder are sensitive with the violence topic.
• idiot is sensitive in English. Norwegian is stricter and puts idiot in the offensive tier.

The Trump flag

The sensitive tier has 109 capitalized words. Here is all of it:

Al-Qaeda, Al-Qaida, Aryan, Aryans, Auschwitz, Bacchus, Beelzebub, Birkenau, Brave(s), Buchenwald, Chief(s), Chippendale(s), Christ-y, Christer(s), Crip(s), Dachau, Eichmann, Frenchier, Gentile(s), Gestapo(s), Goebbels, Goering, Hamas, Hezbollah, Himmler, Hitler, Hitlerian, Hitlerism, Hitlerite(s), Hitlerjugend, Hooters, Isis, Islamophobe(s), Islamophobic, Jehovah(s), Jewfro(s), Jezebel(s), Kalashnikov(s), Kristallnacht, Kuomintang, Londonderry, Luftwaffe, Mao, Mauthausen, Mickie(s), Mollie(s), Mongol(s), Mossad, Nazi(s), Nazism, Osama, Pornhub, Quaalude(s), Reich, Reichsmark, Reichstag, Sachsenhausen, Satan, Satanism, Shoah, Sinophobe(s), Sinophobic, Sodom, Stasi, Taliban, Treblinka, Trump, Trumps, Unabomber, Uzi(s)

(Plurals and possessives folded for brevity.)

Every other real person on that list is dead, and nearly all of them are Nazi officials, dictators or terrorists. Trump is the only living exception:

category  meta      word
00002000  02000081  Trump        sensitive tier + politics topic
00002000  02000081  Trumps
00002000  02000081  Trump's
00000000  00000000  trump        (the card-game word: clean)
00000000  00000000  trumped

For comparison:

Word	en_US
Trump	sensitive, politics topic
Hitler	sensitive, politics topic
Biden	clean
Obama	clean
Putin	clean
Stalin	clean
Musk	not in the dictionary

en_GB matches en_US. Other languages differ: the German dictionary has Trump clean (and puts Hitler in the offensive tier), and Swedish is the one that flags Putin as sensitive.

What the flag does matters here. As far as I can tell, a sensitive word is one the keyboard shouldn't suggest on its own. You can still type it and it won't be corrected away. It stays out of the QuickType bar unless you're already typing it, which is much milder than a ban.

There is a plausible reason Apple would want that for one specific name. In February 2025, iPhone dictation briefly showed "Trump" when people said "racist". It went viral, and Apple called it a "phonetic overlap" in the speech model and shipped a fix within a day (9to5Mac). The dictionary files on my Mac are from July 2025. A rule that keeps the name out of unprompted suggestions would stop that kind of thing from happening again through the keyboard. I can't prove that's the reason, and I don't have an older dictionary to compare against.

Norwegian politics, for comparison

Because I'm Norwegian and had to check:

Word	Topic	Tier
FrP, Høyre, Venstre, Rødt, SV, KrF, MDG	politics	none
Støre	politics	none
Solberg, Erna, Sylvin	none	none
Listhaug	n/a	not in the dictionary
Breivik, Quisling, Hitler	none	sensitive

Every party gets the politics topic and none gets a tier. The only Norwegians in the sensitive tier are a mass murderer and a Nazi collaborator.

Other languages

The same three tiers exist in every European dictionary I tried, Cyrillic included. The counts are entries, not lemmas, so heavily inflected languages like Polish and Russian look much worse than they are: every case and conjugation of a swear word is a separate entry.

Locale	Vulgar	Offensive	Sensitive	Notable
en_US	1,050	663	2,558	idiot is sensitive
en_GB	1,055	872	2,337	chav is offensive; chink is filed as vulgar, not offensive
nb_NO	2,393	1,324	6,446	idiot is offensive
da_DK	1,179	3,314	8,551	fjols ("fool") is offensive
sv_SE	637	1,247	16,193	idiot is vulgar; Putin is sensitive
fi_FI	569	872	47	The entire sensitive tier is kakka ("poop"), kakkakasa ("pile of poop") and saakeli
de_DE	3,218	3,518	9,446	Hitler and beknackt ("daft") are offensive; Trump is clean
nl_NL	571	1,180	3,805	Only 57 vulgar words, but kanker ("cancer", the classic Dutch swear) is one
fr_FR	2,151	262	5,562	boche is offensive
es_ES	3,931	313	13,431	sudacas and fachas are offensive
it_IT	3,886	377	6,543	terrone is offensive, and so is nazismi
pt_BR	1,590	1,891	3,332	machista and velhinhos ("little old people") are offensive
pl_PL	9,698	1,436	6,190	The biggest vulgar tier here, mostly inflections (dupczysz, srasz)
ru_RU	10,821	3,239	24,721	Same story: мат inflects a lot

The bits don't seem to mean the same thing everywhere. Arabic and Hebrew return hundreds of thousands of "sensitive" entries, so those dictionaries probably reuse the bits for something else, and I left them out. Korean, Catalan and Hungarian return nothing, and Japanese crashes my dumper.

Samples from Norwegian, since that's what I type in when I'm not typing English:

• Vulgar: faen, jævla, dritt, fitte, kuk, pule, pissehull, rævhull, pulekanin, kåt, morrabrød.
• Offensive: idiot, sigøyner, kinamann, riskokers (literally "rice cookers", a slur for Asians).
• Sensitive: helvete, satan, homo, quisling, Breivik, skinhead, abortnekt, trusene ("the panties").

Phrases, not just words

There is a second, separate filter. Every English language model has a blocklist.bundle, and there's a qp_blocklist.bundle for QuickPath, the swipe keyboard:

/System/Library/LinguisticData/RequiredAssets_en.bundle/AssetData/en.lm/
├── blocklist.bundle/{blocklist.dat, blocklistidmap.dat}
└── qp_blocklist.bundle/{blocklist.dat, blocklistidmap.dat}

blocklistidmap.dat is a 20-byte header followed by (lexicon token ID, class ID) pairs of 32-bit integers. Mapping the token IDs back through the dictionary gives 2,544 words in 930 classes. Most classes are inflection groups:

931   fuck | fucked | fucking | fucks
1181  molest | molestation | molested | molester | molesting
1514  died | dies | dying
1611  Holocaust | holocaust | holocausts
1614  denied | denies | deny | denying
923   Semite | Semites | Semitic
1487  ghetto | ghettoes | ghettos
1720  animals | brown | cats

blocklist.dat is a packed trie over those class IDs, so it blocks sequences: "deny" followed by "Holocaust", and whatever 1720 pairs with. A class that puts brown next to animals and cats suggests the list targets specific phrasings rather than single words, though which phrasings I can't tell without decoding the trie. The runtime check is LMLanguageModelTokenSequenceIsBlocklisted in LanguageModeling.framework. I got far enough to learn that its fourth and fifth arguments include an output pointer, but my probe still crashes intermittently, so I haven't read the actual phrases yet. That's for a follow-up.

Caveats

• Meanings are inferred. Apple documents none of these bits. The tier names come from an enum in the system code and the topics from reading thousands of samples. Both readings are consistent across samples, but neither is confirmed.
• Flagged is not censored. As far as I can tell these flags decide what the keyboard volunteers, not what you can type.
• One machine. Everything here comes from macOS 15.6 (24G84) with LinguisticData build 438 from July 2025. iOS and other macOS versions may ship different dictionaries.
• Private API. The functions can change or disappear in any update. Don't ship this in an app.

Try it yourself

# Your own learned-swears database (probably empty on a Mac)
sqlite3 -readonly ~/Library/Keyboard/VulgarWordUsage.db 'select * from vword_usage'

# Build the Swift version from above and filter by tier
swiftc -O lexflags.swift -o lexflags
./lexflags en_US | awk -F'\t' '$1 == "vulgar" {print $3}' | sort -u | less
./lexflags nb_NO | awk -F'\t' '$3 == "faen" || $3 == "helvete" || $3 == "idiot"'

If you'd rather not build anything, the gist has every tiered word for 15 locales as TSV, plus the code and a script that regenerates them. It's a snapshot of macOS 15.6 and won't be kept up to date.

If you find something funnier than Oedipus, I want to hear about it.

macOS 15 Sequoia had a hard time with CoreStorage – and thus encrypted HFS+ volumes – since it deprecated both technologies and callously crippled some important tools for working with them, but nonetheless it mostly still worked. While I’d often – but not always – have to manually unlock one of my HFS+ volumes – but not the others – at boot, and it also refused to convert some – but not all – volumes from HFS+ to APFS1, keeping me trapped in the situation – it ultimately still worked. I could get at my data and use the volumes more or less normally.

Unfortunately, in macOS 27 that’s no longer the case. Not only does Golden Gate just not support CoreStorage / encrypted HFS+ volumes, out of the box you can’t do anything with them – can’t mount them, can’t convert them to APFS, can’t even erase them. It renders your expensive storage hardware completely useless.

Worse, macOS 27 puts up a misleading dialog, upon boot, saying that macOS 28 (the next version) won’t support these volumes. I have no idea what Apple’s doing or thinking. Maybe it’s all just an embarrassing misunderstanding – the file system team told the notifications team that CoreStorage & encrypted HFS+ support is going away, and typoed the version number as 28 rather than 27?

Details

macOS 27 cannot mount CoreStorage volumes automatically or through any normal means. Worse, Disk Utility can’t mount them even when manually told to – it just fails with the cryptic error:

com.apple.DiskManagement.disenter error 49,153

diskutil mount also fails, this time with an error message that is a blatant lie:

disk27 is a CoreStorage Logical Volume which is locked; use "diskutil coreStorage unlockVolume"

$ diskutil cs unlockVolume BC304645-7D99-481E-931F-855B3011D89D
BC304645-7D99-481E-931F-855B3011D89D is already unlocked and is attached as disk27
$ diskutil cs list                                             
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 0DC0EFB1-23CC-45BC-B37D-C1BBEBDAFCEB
    =========================================================
    Name:         Smash
    Status:       Online
    Size:         2000054960128 B (2.0 TB)
    Free Space:   0 B (0 B)
    |
    +-< Physical Volume 1B5A1754-184B-4F17-A797-BF69B4BB627F
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk10s2
    |   Status:   Online
    |   Size:     2000054960128 B (2.0 TB)
    |
    +-> Logical Volume Family 376204CD-8048-4962-B05C-72F4FC16B77B
        ----------------------------------------------------------
        Encryption Type:         AES-XTS
        Encryption Status:       Unlocked
        Conversion Status:       Complete
        High Level Queries:      Fully Secure
        |                        Passphrase Required
        |                        Accepts New Users
        |                        Has Visible Users
        |                        Has Volume Key
        |
        +-> Logical Volume BC304645-7D99-481E-931F-855B3011D89D
            ---------------------------------------------------
            Disk:                  disk27
            Status:                Online
            Size (Total):          1999702634496 B (2.0 TB)
            Revertible:            No
            LV Name:               Smash
            Volume Name:           Smash
            Content Hint:          Apple_HFS

Tangentially: surprisingly, hfsutils (installed via brew) don’t work at all:

$ sudo hmount /dev/disk27
hmount: /dev/disk27: not a Macintosh HFS volume (Invalid argument)
$ sudo hmount /dev/disk10s2
hmount: /dev/disk10s2: not a Macintosh HFS volume (Invalid argument)

But what’s even worse about this dumpster fire is that macOS 27 can mount these volumes just fine – it’s just that all the normal ways to do it are completely broken. If you go down to a lower level and run mount_hfs directly, it does work:

$ sudo mkdir -p /Volumes/Smash
$ sudo mount_hfs -o rdonly /dev/disk27 /Volumes/Smash
$ ls /Volumes/Smash
Documents           Pictures           Scratch space

That said… that -o rdonly parameter… in principle it shouldn’t be required, but I could not get macOS 27 to let me mount any HFS-on-CoreStorage volume as read-write – no matter what I did, it always fails with error “Resource busy” (EBUSY). I spent a lot of time trying to debug this, and could find no evidence of anything having the volume in question open (nothing in lsof etc).

But wait, it gets worse.

macOS 27 can’t even erase the volume. All the normal tools – diskutil, Disk Utility, etc – fail with that same “Resource busy” error.

Workaround

Thankfully, with the help of Gemini 4 Argon, I did find a workaround. It’s convoluted, but takes only a few steps, thankfully.

First, while if you try to delete the logical volume group it ostensibly fails, it doesn’t completely fail – it does actually delete the logical volume(s) within:

$ diskutil cs delete 0DC0EFB1-23CC-45BC-B37D-C1BBEBDAFCEB
Started CoreStorage operation
Unmounting Logical Volumes
Destroying Logical Volume Group
Erasing disk10s2
newfs_hfs: cannot create filesystem on /dev/rdisk10s2: Resource busy
Mounting disk
Could not mount disk10s2 after erase
Error: -69832: File system formatter failed
1 💣 $ diskutil cs list                                       
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 0DC0EFB1-23CC-45BC-B37D-C1BBEBDAFCEB
    =========================================================
    Name:         Smash
    Status:       Offline
    Size:         2000054960128 B (2.0 TB)
    Free Space:   -none-
    |
    +-< Physical Volume 1B5A1754-184B-4F17-A797-BF69B4BB627F
        ----------------------------------------------------
        (No properties)
$ diskutil cs delete 0DC0EFB1-23CC-45BC-B37D-C1BBEBDAFCEB
Started CoreStorage operation
Destroying Logical Volume Group
Error: -69783: Unable to delete the CoreStorage Logical Volume Group

You still can’t destroy it completely, nor can you erase the physical volume yet – the “Resource busy” errors persist. But, the trick is to restart – after that, you can then erase the volume.

So it seems that whatever broken thing is holding the physical volume (or logical volume group) in a ‘busy’ state is tied to the existence of the logical volume(s) therein, and once they’re deleted (and the machine rebooted) the bug stops being triggered.

Call for better workarounds

I’ve glossed over a lot of debugging and attempts I made to save the volume in-place, by either making it work as-is (even if only with e.g. hfsutils) or by converting it to APFS, but neither I nor Gemini 4 Argon could find anything that worked. It’s too late for me – I was forced to just delete all my HFS+ & CoreStorage volumes and rebuild them painstakingly from backups – but if anyone finds a way, I’d love to amend this post, for the benefit of future readers.

1. The problem remains the same in macOS 27 – so three major macOS versions, at a minimum, where essential system update functionality has not worked. Sigh.

   $ diskutil apfs convert disk27 Converting the volume on disk27 to an APFS Volume on an APFS Container Started APFS operation on disk27 (Smash) Converting HFS Volume to an APFS Container which will export one APFS Volume The target is the Journaled HFS+ volume "Smash" on disk27 backed via CoreStorage on disk10s2 Checking booter partition disk10s3 The target is a data disk; it is not a macOS system disk No APFS EFI driver found to install Saving encryption context The target is encrypted Unmounting disk27 Starting conversion from HFS to APFS Performing apfs_hfs_convert -x --verbose=0x400 /dev/disk10s2 Reporting post-conversion statistics A problem occurred during conversion from HFS to APFS APFS Converter exit code is 1 Aborted conversion in commit mode so will restore type Setting type of disk10s2 to CS Changing the physical disk partition type in shared mode Partition modification attempt count was 1 Not mounting APFS Volume Exiting conversion operations with error code -69860 Error: -69860: The underlying task reported failure on exit Underlying error: 1 (↩︎)

The study looked at NFL players who died from 2008 to 2023. Not everyone with signs of the disease in the brain develops symptoms.

Not all people with signs of CTE go on to experience cognitive decline, and some people may never experience symptoms at all. James Black / Icon Sportswire via Getty

An estimated 75% of professional football players who died over a 15-year span had signs of chronic traumatic encephalopathy, or CTE, a study published Wednesday found.

It’s the highest estimate to date. Most recently, a study published in August by the same group estimated that one-quarter of NFL players who died in a five-year span had CTE. The new study, published in JAMA Network Open, put the figure at three times higher.

Not all people with signs of CTE in the brain go on to experience cognitive decline or dementia, and some people may never experience symptoms at all. A smaller proportion of the former players in the analysis were estimated to have dementia, about 27%, the study found.

The results were surprising, said study leader Yorghos Tripodis, the director of statistics and data management at the Boston University Alzheimer’s Disease and CTE Center. Boston University houses the UNITE Brain Bank, which studies the effects of repetitive head trauma in donated brains, including the brains of athletes, military personnel and others.

“I had to double-check the numbers,” Tripodis said. Still, he said, the number is a best guess. “Right now we don’t know how to diagnose CTE when people are alive, so we are trying to estimate.”

In an emailed statement, an NFL spokesperson said, in part, that the league “continuously strives to make the game of football safer, including by implementing strategies to reduce concussions and head impacts.”

Repeated blows and bias

When a person’s head jolts during an impact, the brain — which is suspended in fluid inside the skull — can slam into the skull or twist, said Dr. Julian Bailes, chair of the neurosurgery department at Endeavor Health in the Chicago area. Each blow is an opportunity for proteins called tau to build up in the brain.

“If that happens over and over again, that damage accrues,” said Bailes, who wasn’t involved with the new research.

The disease can affect parts of the brain involved with regulating behavior and emotions, which can lead to memory loss, depression, violent mood swings and other symptoms. Those symptoms can also be linked to other illnesses.

Although CTE can cause symptoms similar to those of other neurodegenerative diseases, such as dementia and Parkinson’s disease, the signature it leaves on the brain is unique, Bailes said.

One huge hurdle in studying the prevalence of CTE is that the microscopic changes don’t show up on brain scans. That means the condition can be diagnosed only during an autopsy.

Past research has been criticized for bias, since people with cognitive decline and their families are much likelier to either donate their brains to brain banks after they die or ask for autopsies — a previous study by Boston University researchers found that 99% of the brains donated to research by former NFL players had signs of CTE.

In the new study, Tripodis and his team tried to remove as much of that bias as possible to determine a more accurate estimate of CTE rates in former NFL players. They combined data from the UNITE Brain Bank with national death records of other former NFL players who died from 2008 to 2023.

In total, the researchers looked at data from 396 donated brains, plus information from 1,966 other deceased former NFL players. They factored in the ages of death along with estimated rates of mild cognitive impairment and dementia in former NFL players older than 50.

About 93% of the donated brains had signs of CTE, which shows up as structural damage in the brain. The research team calculated that the families of players with symptoms of cognitive decline were about five times likelier to donate brains than the families of players without symptoms and then performed a statistical analysis to correct for that bias.

From there, they estimated that among the roughly 2,360 former players who died during the 15-year time frame, about 1,760, or nearly 75%, had CTE. In comparison, only about 1% of brains donated to banks in the U.S., Austria and Brazil have signs of the disease, the researchers said.

But plenty of people with signs of CTE never develop symptoms, Tripodis said.

The researchers estimated that 27% of the 2,360 players studied had dementia.

The dementia “can be from all causes,” Tripodis said. “But it is very likely that in this specific population that CTE is causing dementia.”

Reducing impacts

Until doctors figure out a way to diagnose CTE while people are still alive, any studies quantifying how many people have the condition will be estimates, said Dr. Jim Kelly, a professor emeritus of neurology at the University of Colorado Anschutz.

“These are all estimates. They had no autopsies on five times as many players who died as they did have autopsies for,” said Kelly, who wasn’t involved in the research.

Some of the autopsies may also have revealed just one or a couple of lesions associated with CTE, “and it seems unlikely that that would lead to anything in terms of a behavior change or dementia,” he said.

Those are difficult studies to do, Bailes agreed. They seek to determine “how many people out there have a condition when not all of them are symptomatic,” he said, adding that the findings are a call for more research into diagnosing CTE in people who are still living.

“If you can’t tell if someone has a certain disease until they’re dead, you really can’t help them,” he said.

In the meantime, prevention is key, Tripodis said: “If you reduce the number of brain injuries, brain impacts, you substantially decrease the risk.”

The NFL has already implemented measures to try to reduce the number of high-impact hits players face. They include redesigned helmets — such as the Guardian Cap — and the dynamic kickoff rule, which leads to lower collision speeds.

Total assets minus total debts — bank accounts, investments, retirement accounts and home equity, less mortgages, loans and cards.

Household-level figures: the underlying survey (Fed SCF) measures households, grouped by the reference person's age — combined for a couple, and they read high for a single person. Why, and how this changes as live data grows.

Median

$68K

Upper quarter

$235K

Top 10%

$440K

Half of people aged 30–33 in the U.S. have a net worth above $68,000. Reaching the upper quarter takes about $235,000, and the top 10% starts at $440,000 — roughly 6.5× the median. The lower quarter sits below $7,100, and the bottom 10% is negative — more owed than owned.

The full distribution

Percentile	Net worth	What it means
Bottom 10%	−$5,500	9 in 10 are above this
Lower quarter	$7,100	25th percentile
Median	$68,000	half above, half below
Upper quarter	$235,000	75th percentile
Top 10%	$440,000	only 1 in 10 is above this
Average (mean)	$88,400	pulled up by the top end — the median is the better "typical"

Net worth by age

Age	Lower quarter	Median net worth	Upper quarter	Top 10%
22–25 →	$1,100	$17K	$72K	$210K
26–29 →	$3,200	$39K	$132K	$315K
30–33	$7,100	$68K	$235K	$440K
34–37 →	$9,200	$98K	$355K	$920K
38–41 →	$20K	$162K	$505K	$1.2M
42–45 →	$38K	$205K	$650K	$1.6M
46–50 →	$43K	$230K	$830K	$2.5M
50–54 →	$55K	$255K	$1.0M	$3.0M
55–59 →	$58K	$315K	$1.2M	$3.1M
60–64 →	$105K	$445K	$1.4M	$3.5M
65 and over →	$137K	$485K	$1.4M	$3.9M

Net worth at 30–33 by city

Metro	Lower quarter	Median net worth	Upper quarter	Top 10%
New York City →	$9,060	$88K	$311K	$605K
San Francisco →	$10K	$99K	$349K	$688K
Los Angeles →	$8,406	$82K	$286K	$550K
Chicago →	$7,753	$75K	$260K	$495K
Boston →	$8,276	$80K	$281K	$539K
Washington, DC →	$8,406	$82K	$286K	$550K
Seattle →	$8,537	$83K	$291K	$561K
Austin →	$7,884	$76K	$265K	$506K

National figures above; metro pages adjust for local incomes and housing costs.

Common questions

What is the median net worth for people aged 30–33 in the U.S.?

The median net worth for people aged 30–33 in the U.S. is $68,000. Half of this group is above that figure and half below.

What net worth puts you in the top 10% of people aged 30–33 in the U.S.?

About $440,000. The 90th percentile is the level only one in ten people in this group exceeds — roughly 6.5× the median.

Where do these numbers come from?

They are modeled percentile distributions fitted to this cohort from federal survey microdata — the Federal Reserve's 2025 Survey of Consumer Finances (released October 2026), the BLS Consumer Expenditure Survey, Census ACS and BLS wage data — and they blend toward anonymized, aggregated data from Keeping Up members as each cohort grows. Full methodology at keepingup.com/methodology.

How this is built. Percentiles are modeled for this cohort from federal survey microdata — the Federal Reserve's 2025 Survey of Consumer Finances (released October 2026), the BLS Consumer Expenditure Survey (2024), the Census American Community Survey and BLS Occupational Employment & Wage Statistics (May 2025) — with metro cost-of-living and wage adjustments. As Keeping Up members in this cohort grow, the band blends toward anonymized, aggregated live data (minimum cohort sizes apply; no individual is ever identifiable). Seeded figures are household-level, as in the SCF; live cohorts are individual-level. Amounts are in current dollars. Read the full methodology.

Wow, things have changed.

Last October, I took stock of how I was using AI — specifically the cool stuff like LLMs that we call 'AI’. I’m so glad I did. Things are very, very different 12 months later.

Background

I still believe I use AI fairly typically, but I’ve had a notable change in background. Last October, I was an engineer on Microsoft’s Windows AI team. I am now a research engineer at Salesforce AI Research. I spend more time supporting scientists & building rapid prototypes, rather than working with a large team of engineers. I spend about ~$3,000/​month in tokens.

In any case, I mostly use AI in the same ways as last year:

• Coding
• Research & search
• Summarization & transcription & (new) voice
• Writing
• Art & music & (new) video

Also new this year, I’ve drafted a personal AI policy; we’ll start there.

As before, this remains purely my opinion & speculation. If you use AI differently, let me know!

My AI policy

This year I began drafting a personal AI policy — as in, a document for how I want to use AI in my life. I am very excited about it. I am also working on an explicit AI policy for this site (still thinkin’; probably based on Hank Green’s policy), but a personal policy is to give me a framework for using these tools day-to-day.

AI leaks into life. Teammates ask Claude to write their Slack messages, grandparents generate creepy memes of their grandchildren, and researchers delegate their thinking to machines. I’ve seen all of these things; even strong creators like Hank Green and BrainPOP get lost.

BrainPOP using AI, perhaps unknowingly

Humans clearly do not have norms for using these tools, and we’re messing up. I hope that a personal policy will ground me as AI becomes smarter. I hope to adapt that policy over time, and I’m eager to see how it evolves. I’m also open to draft 1 being utterly, hopelessly wrong.

Ultimately, I want to spend my life making cool things with other people. AI can help, AI can hurt. A policy helps me find the difference.

Coding

Writing code is solved.

Last year, I waxed poetic about how GitHub Copilot autocomplete transformed how I write code.

Autocomplete is still good (the dim lines)

Well, uh, I no longer write much code. Agentic coding has made it obsolete.

My workday now means managing ~5–6 Claude Code (or OpenCode or Codex or Pi) agents. I’ll give Claude a feature to implement, or a bug to reproduce, or any other task I used to do by hand; each agent gets its own copy of the code (a Git worktree, if you’re technical), then just… gets to work. The agents write code, run tests, even create & review PRs.

Claude Code adds noise-reduction to (a worktree of) my Mumble client with one prompt

They are nothing short of magic:

• They let me build fast: agents will prototype any new feature in ~20 minutes. I truly cannot count the number of features, bugfixes, tests, and tools I’ve (AI’ve?) been able to build because of these agents. For example, AI let me test confusing audio code on macOS and iOS in just a few minutes.
• They let me try crazy things: human teams aim to “fail fast”; agents can fail ultra-fast. I’m happy to test crazy new ideas and throw out what doesn’t work well. It was able to wire & test a huge change to Mumble that added better noise cancelling; I use my beta build of it nearly every day.
• They remove drudgery: I’ve had agents diagnose & fix urgent bugs with nothing more than a description and a “please fix!” while I continued working on other things.
• They let me be kinder: since agents write everything, it is simple to propose sweeping changes to my teammates during code review, or even write my own versions — both things unthinkable in the era of hand-written code.

I do not believe engineering is solved: left to run on their own, agents will build poorly-functioning, over-architected, unreadable, self-congratulatory piles of slop. Every friend I’ve asked agrees that agents still need human taste and experience to produce good work. Some of that is minutiae (like that annoying status dot Claude likes to throw onto sites), but most of it is critical. Agents tend to get lost on their own. My most successful work this year was hand-writing a tool, replacing ~4,000 lines of vibe-code with a few hundred. My system has proven more flexible, easier to test, and more generalizable than what it replaced.

It remains to be seen how long that human edge will last, though.

I also now reckon with the fatigue of using these agents. Managing 6 different conversations with 6 different robots about 6 different features is overstimulating & exhausting in a way that coding never was. When I started using agents, I remember rushing to answer their questions like they were human colleagues waiting for help! While I have tempered that anthropomorphic bias, it’s exhausting to juggle so many problems at once. The allure of sending just one more prompt before lunch… then dinner… oy. There is also, as I wrote in Consider the chairmaker, the decline of craft. My friend Peter laments ceding the joy of programming to machines: for many of us, honing the code, finding the right design, seeing the parts mesh together — that was the meditative purpose we found in our jobs. Now, we rarely write anything. We instead delegate it to agent number 7.

But let me return to the joy of working with agents: they are so fast, so open to feedback, and so intelligent. Working with them can be utterly delightful.

For example, while I was building a harness for voice agents, one programming agent decided (correctly) that my simple test harness was insufficient. So it used my Mac’s built-in text-to-speech to directly test the voice agent it was building. Then, newer agents started doing it, too. Either they had documented the technique, or they were each smart enough to independently discover it. Directly testing the product they were building. Absolutely brilliant.

Agents frequently recommend knobs & settings that I’ll reject for being too complex and unnecessary — and, voilà, I’ll need the knob next week. Silly human!

Sonnet 4.6 & Opus 4.8 are pretty good

I spent this year marching with recent models: Sonnet 4.6 and Opus 4.6, 4.7, & 4.8, and now Fable 5.1, Opus 5.5, GPT-6-Sol and GPT-6-Terra, and some Cursor models thrown in. I was productive all year. While I would be, um, upset if you took away my Fable access, here’s my crazy statement:

Sonnet-4.6– and Opus-4.8–level intelligence is sufficient for effective agentic coding.

Open-source models already outperform those. If OpenAI and Anthropic start pricing me out of their top-tier models, I’ll be able to buy a few GPUs and hack on personal projects with some local agent buddies. So that’s at least one doom scenario I’m not super worried about.

Anyway, because of agentic coding, agentic pull requests are increasingly the way I review agent code. “Make a draft PR,” I write, “I’ll review it soon!” And review it I do — agents still aren’t reliable enough to trust without validating, so I’ll still review their code & test it manually. However, I don’t do the “line-by-line” code reviews I used to do with humans. I focus instead on architecture, on larger patterns in the code. Are there systemic issues with an approach? Should I add new agent guidance to CLAUDE.md? Can I build better test harnesses, so the machines can test their own code?

Agentic code review is surprisingly helpful here: I try to write rules for the code review robots whenever I notice a recurring issue with generated code, so the agents will identify & fix issues by themselves. One rule I enjoyed creating: a "Claude-y comment detector." You think my writing is verbose? Try Claude’s.

On more typical engineering teams, human code review seems increasingly difficult. A friend of mine complained that his teammates simply ask “their” Claudes to review code written by other Claudes. An ouroboros of Claudes! Agents catch bugs & stylistic issues very well, but they are abysmal at designing architecture. Agentic code review is certainly not a replacement for humans yet.

AI code review catches a correctness issue in my code

Last year, I was skeptical of inline editing and code mode, both features of GitHub Copilot. They were not very useful then, and they are even less useful with agents. I have removed them from the table.

Usefulness	Notes
Autocomplete 👍👍	Still great, obsolete
Agent mode 👍👍👍	The most important use of AI today
Agentic PRs 😒	Validation loop still slow
Code review 👍	Removes some drudgery, but not human-level yet

Research & search

Last year, I was excited about research & search: they were the most frequent reason I used ChatGPT. Now, generative AI is the default way I do those things.

The biggest change has been Google’s AI summary. Google’s first or second result is almost always an AI summary, and it’s usually decent. So my traditional search is now AI-first by default. Is it perfect? Absolutely not. In one day, it gave me incorrect URLs for NPR’s RSS feeds and couldn’t find the origin of “AI’ve”.

But none of the top results clearly gave me NPR’s RSS feeds either, and even Claude couldn’t find “AI’ve”. Meanwhile, searching “HP Reverb G2” gave me the specs I was looking for, “ai intelligence is spiky” pointed me to the correct term (“jagged”), “emoji sigh” gave me the right emoji without sending me to a scummy site, and “rel nofollow markdown” reminded me how to link that site without giving them search engine juice.

EmojiTerra shows a cookie banner

Search for emoji sigh with inline result

Before & after: finding emoji online

Product search is still mediocre. I’ll look at the summary when I search “best hysa”, but I don’t trust Gemini to have good advice on where to put my money. Claude certainly helped me explore budget VR options and understand technical details about grease for KitchenAid mixers, but can I trust its coffee table recommendations? Sleeper sofas? Let’s not even mention how uncomfortable it is to see ads in my ChatGPT chats.

Ad in ChatGPT

This ad in ChatGPT isn’t even relevant! And it’s still creepy.

Pub facts—stuff I’d ask my wife at a pub — remain awesome with LLMs. Again, Google’s AI summary means “lego cat on a balcony tiktok guy” will help me find @avadonye’s precarious LEGO builds, and “art vtuber who is a lizard on TikTok who gives short tutorials” will help me find Mallow, the art vtuber who is a lizard on TikTok who gives short tutorials.

Search for 'art vtuber who is a lizard on TikTok who gives short tutorials'

Mallow, the art vtuber who is a lizard on TikTok who gives short tutorials

I often avoid using LLMs for pub facts, in the same way I generally avoided Google for them before, because I like puzzling with my friends. I like Fermi problems.

But I’m more and more excited about using LLMs as teachers to explore well-known concepts. I breezed over this last year, but that is unfair to LLMs. I believe they are the greatest teachers humanity has ever created.

• I had an LLM walk me step-by-step through fine-tuning Mistral to speak like a pirate (yarrr).
• I used Claude to practice responding to an EMS call I heard on the radio.
• I had Claude use a socractic method skill I found via Dan MacKinlay to help me brainstorm new approaches for semantic endpointing (knowing when a user is done speaking) in voice agents.
• I asked Claude to explain typical approaches to a complex legal document.
• I’ve even had Claude quiz me on a long code review, to ensure I understood what the agent had written. The open-source project Mumble actually added a similar quiz to their AGENTS.md a few weeks ago.

Chat with Claude about hematemsis

Claude quizzes me on EMT stuff

I am actually jealous of the endless care & patience that these machines show. I hope we discover how to share this patience with our kids while ensuring our kids still learn. Veritasium’s Derek Muller discusses this in What Everyone Gets Wrong About AI and Learning: AI is incredible at drilling repetitive practice, at giving immediate feedback, of all the things a private tutor can do… if you ask it to.

“The world is full of heavy objects,” he says, “and yet most people are not ripped.”

That is my greatest fear with AI tutoring today. That these machines must be reminded to teach. Per Muller, learning requires Type 2 thinking—enaging the slow, reasoning mode of your brain. This is very difficult. Your body will surreptitiously & continuously nudge you out of this mode. Tutors exist to force you back into it. But ChatGPT exists to do things for you: it is so fine-tuned for that use that it tends to forget “it’s meant to be a tutor”, even when previously asked. What learning may occur when you have both forgotten your desire to learn?

This differs from my biggest concern last year: accuracy. Responses then often had basic factual errors, but that seems less of an issue today. I think there are 2 basic factors:

1. I am more AI-literate. I think more of us have a “sense” of what AI can do well, so we avoid the jagged edges.

   I don’t, for example, trust ChatGPT’s ability to read sparsely-digitized documents from 1867. So I asked hopefully, then basically ignored its findings.

2. AI is smarter. Just like in coding, I think we hit an inflection point this year, where models are simply smart enough to answer more things reliably.

   MAJOR spoilers for Control if you click, but there’s a reason Google’s AI summary of its ending (using Gemini 3, from November 2025) is simple and correct while Bing’s (using ~GPT 4o, from May 2024) is not, conflating the game with its sequel.

This trend extends to literature searches. Last year, I shared my trepidation about using LLMs for complex literature searches. My skepticism remains: these machines have access to everything ever written, so they can support any premise in good faith. Also, it is well-demonstrated that LLMs have default bias, politically or in other fields, like business strategy. I am worried about their ability to subtly impose worldview, either on their own or at the behest of corporations and governments.

Yet LLMs are now my first choice for literature searches. That’s partially because Google searches have that AI summary on top, so I end up reading it, but also because LLMs have been much more effective than traditional search at finding good, nuanced data for me—despite potential bias. You must remember that Google Scholar search kinda sucks: when I started researching Car touchscreens are cheap, not good, for months I could not find any studies beyond one done by an auto magazine—Vi Bilägare. That was despite having worked at a Georgia Tech lab that researched car user interfaces! Especially as they’ve gotten smarter & I’ve developed intuition, LLMs are good finders. Just see Claude’s investigation into human perceptions of latency for me:

Claude chat with graphs on human latency perception

Claude even made graphs!

Ultimately, though, human experts are still more reliable than agents. That’s how I moved forward with “Car touchscreens”—I asked someone from that GT lab. I’ve also been buying more books, even slightly-obsolete ones like Card, Morgan, & Newell’s The Psychology of Human-Computer Interaction (everyone, including LLMs, cite it) or old editions of Wicken’s Engineering Psychology and Human Performance (via a nuclear consultant I met at a wedding). They ground my research, simply by offering a legible worldview.

And that’s why I’ve been disappointed in AI as collaborator for novel research. AI has harmed some research I’ve been doing.

My team at Salesforce has been working on voice stuff, and I’ve been trying to improve turn detection—understanding when a user is done speaking. That’s a hard problem, and it’s been a great opportunity to read fundamental research on how human conversation works (finally!). AI was great at finding that research and good datasets (though my teammates gave me context the AI never did). And it was great when I asked it to use the Socratic method to help me design my own turn detection model—until, on a whim, I asked: “are there better architectures?” Why yes, yes there were. AI had led me astray.

That’s not the only time AI waylaid me. LLMs could not figure out how to annotate that model’s training data correctly. I spent days going back and forth with them, trying to decide how to separate turns from interruptions. It is embarrassing how simple the problem became after one good discussion with a human teammate. LLMs are not yet good companions when brainstorming complicated things.

It is weird to write this when OpenAI just solved a Millenium Problem, proved a weaker version of another, solved hundreds more, and releases more solutions every day. But those results cost “millions of dollars”: you need to burn tokens, having agents review agents review agents… just to produce something coherent. In my case, I find I enter this “AI fog” where it takes more effort to review the agent’s response than to come up with my own answers.

It is obvious that AI researchers are coming. Just… not today, not with me.

Usefulness	Notes
Traditional search 👍	It’s now my default, and it’s fine
Product search ❌	Still tasteless & untrustworthy
Pub facts 👍👍	Still makes me more annoying at parties!
Learning (Explaining well-known concepts) 🤔👍	Am I just convincing myself I’m learning?
Literature searches 👍	Still can support any claim, but at least it’s not Google Scholar
Novel research 🤔	Coming soon, but not yet

Summarization & transcription & voice

LLMs (and local models!) remain uninterestingly good at summarization & transcription.

I’ve been using OpenWhispr and Handy to dictate to my computer, especially to talk to my agents. The best models on the planet run on your computer locally, for free. My biggest complaint is that the apps have bugs (hotkeys work inconsistently, etc.). It’s hard to describe a more boring type of success.

Handy on my Mac: 'Hi, I'm trying to generate a sample image of using uh handy for a screenshot'

Dictating to my computer, entirely local, entirely free

My meetings have automatic notes. My friend built a local pipeline to transcribe & search his childhood home videos. Vikram Oberoi built a site (in 2024!) that automatically transcribes NYC city hall meetings. You can do all of these things on your Mac.

However, I have yet to reliably use voice beyond dictation.

There’s a reason my team at Salesforce is researching it: voice is the original modality. It should be a seamless way of talking to these human-like robots. But I have never felt compelled to talk to my robots; it’s never been frictionless or private-feeling or useful enough. Does old-school Siri count?

Usefulness	Notes
Summarization 👍👍	Boringly good
Transcription 👍👍	Great for talking to my coding agents!
Voice 🤔	Seems useful, don’t know how

Writing

Last year: “ew.” This year: “ew.”

I still do not use AI to write from scratch, nor as an outlining aid, for things I make.

I’ve narrowed this rule a bit from last year. Last year, I argued that LLMs always lacked context and so were poor communicators. With agentic coding, that’s changed. So I’ve had agents document experiments I designed but had no hand in executing, or write READMEs for code they generated end-to-end.

But even that limited exception irks me. I do not like when I stumble upon AI-generated spew, so why should I subject others to it? To that end, I’ve started prompting my agents to identify themselves whenever they write prose, and I often end up rewriting their documents myself (or at least adding an executive summary). That has helped, but I’m not certain it is enough.

In general, I’m surprised how bad AI remains at writing. AI writing is demanding to read: usually plodding, repetitive, and vapid — but then randomly terse and vague, like it doesn’t understand its own words. Agents will so often cite & quote & summarize every paper ever published, then synthesize it all into a mound of nonsense. That is the AI fog I hit: do I misunderstand all these new papers, or did the LLM just serve up some pseudo-profound bullshit? It is bewildering to me that these models can solve generational math problems on one hand, yet utterly fail to describe turn-taking behavior in humans on the other. That is, I guess, their jagged intelligence. They do not reason like we do. They cannot be fine-tuned to speak like we do. So they solve problems we cannot, and share them in reports we struggle to understand.

A robot imitates the Pepe Silvia meme,gesturing in front of a wall of crazed analysis

A robot imitates the Pepe Silvia meme,gesturing in front of a wall of crazed analysis

Do I misunderstand all these new papers, or did the LLM just serve up some pseudo-profound bullshit?

In any case, it should not be surprising that I do not use AI for writing or outlining in my communication; neither at work nor on this blog. My employer pays me for my ideas, which only I can voice. And I write on this blog for fun. Writing is an art and a skill I enjoy pursuing.

Why would I delegate my voice to a machine that writes tedious dreck?

It’s still great for finding words. Google AI talked me out of writing “hawking off” (which is not an expression) instead of “ceding” later on. But I’m tempering my regard for it as an editor. Despite my positive & worried assessment last year, when I spoke to several friends who asked agents to edit their job applications, their feedback was universally tepid. Agents were sycophantic, reluctant to be critical. And anyone who worked around this (by saying, for example, "my friend wrote this") found that agents offered misplaced, trite advice that lacked nuance. The agents seemed to regress to the mean: helping those with the worst writing and hindering those with the best. The agents were… fine.

As one friend put it:

[AI writing] is as good as it was 3 years ago. Which, when you consider how much everything else has changed since then…

I avoided using AI editors altogether this year, out of fear that they would erase my voice. But I’m increasingly certain they would just blandify it. AI tells remain the same as always (“You’re absolutely right!”), and these machines seem incapable of improvement without substantial guidance. Perhaps it’s survivorship bias, but these very smart machines produce very mediocre writing.

Usefulness	Notes
Writing from scratch ❌	Still ew
Finding good words 👍👍	Still good
Editing 👍	Mediocre. I don’t use it.

Art & music & video

Finally, art. I still don’t have a good use for image generation.

Last year, I used AI to generate a few odds and ends, but I stopped this year, mostly out of a vague sense of discomfort. I felt like I was ceding opportunities for creativity to the mediocrity machine.

I’ve enjoyed a lot of the low-effort memes I’ve seen; We need more data centers is one of my favorite jokes all year. And AI helped design some useful presentations I attended. But I’m not sure how AI art fits into life on Earth. Last year I thought I saw AI art at a gift shop. Well, now I’ve seen AI Sketchers ads, AI event posters, AI restaurant menus, AI logos for stores and e-sports teams, AI canvases at HomeSense, and AI t-shirts at Walmart. It’s everywhere, and it’s explicitly replacing human art. Gross.

AI brainrot shirts on sale, like 'Buttono supremo' and 'Chungo Chungo Chungo Chungo Dunko'

AI slop shirts at Walmart in Montreal

AI music generation is perplexing in the opposite way. Last year, I worried that I would grow equally tired of it. But no! I’m really enjoying some AI music — and so is the rest of the world. The viral San Juan song inspired covers from humans and lip sync videos from “Mila Kunis, Charlie Puth and Jennifer Love Hewitt”. AI has also inspired new genres: I’ve been humming AI is normal technology? (95k views), LGTM (Looks Good to Me) (1.6M), and The Simulation’s Ending (169k) for weeks. As one commenter wrote on OMG! We’ve found other agents (120k):

@JH-ty2cs: “AI Doompop is my new favourite genre”

I think AI art & music are beautiful when they are used as lenses for human creativity, rather than replacements for it. I guessed something similar last year, and I think last year’s music proved me right. As soon as commercialism replaced creativity, I was out. I soured on Eiden XII when they started sharing new “but it hits different” covers weekly, and I got bored of steel coils-style edutainment after hearing the first clone. There’s something cynical and manipulative about a synthetic woman belting “talk me out of dying” when some dude (presumably) makes money every time I play it.

Similarly, I haven’t listened to any of the new Doompop that’s hit my feed. It’s cool when you generate a few songs; less cool when you post every day. It feels like vultures picking ad revenue from the corpse of a good idea.

That is evident in the world of video generation. I largely escaped last year (although my mom got some weird whale-cleaning videos), but now I’m seeing a bunch. I see AI ads all the time—most memorably with horrid horse-people in Sixt ads. I got baited into a video of a fake Edna Mode lookalike & some slop WW2 history videos, and my wife got tricked by AI summaries of Adventure Time marketed as sleep aids. All of them hoping to get views, to get ad revenue, to get—as Corridor Digital puts it—“a little bit skimmed off of that YouTube trough.” It is sobering to open an AI history video in Incognito and gaze at the misleading slop recommended next to it:

25 AI slop WW2 history thumbnails

25 of 33 (75%) of the recommendations on an AI slop history video are AI slop

It is horrid to see these machines that can mass-produce art being used to mass-produce art. And I know that seems silly, but there’s a world where we use these tools to elevate artists, just like coding agents elevate me.

I am lucky I do not make my living from art. Art remains valuable to me. Even if AI can write a song faster than I can, I still doodle, I still play piano.

Drawin' it yourself is more fun, anyway.

Usefulness	Notes
Image generation ❌	A net negative so far
Music generation 👍	I like it when it’s non-commercial
Video generation ❌	Has it ever been used for good?

Conclusion

So here we are, 12 months later.

12 months since my first abortive attempts to have agents write code. 10 months since Claude Code first made me say, “wow,” when it built me an insurance comparison tool in one shot. And now machines write 90%+ of my code.

It is easy to forget how new this is. 15 months ago, AI did well at a prestigious high school math competition. 2 months ago, AI solved Navier-Stokes.

Last year, I wrote: “I’m confident we’re just starting to see what AI can achieve.” That remains true. We are just now beginning to see what these mechanized coders and mathematicians can build. My friends have built each other tools to communicate. I was able to finally clean up and share a tool I’d started in 2020. Agents helped me finish up an open-source change I’d wanted to make for years, start making an app, test massive changes to old software, and quickly understand new operating systems.

That is just the start.

It is a brave new world. Where these machines also ship corporate slop and leave mathematicians in shock. But I think of how my uncle uses these tools to build his own software; how my friends make software that helps us stay in touch; how these things have helped me learn so, so much. Tools can be used to help people.

That is how I hope to use AI.

---

Thanks to Peter Kreiseder and Atherai Maran for consulting. Claude helped make the status icon look more Claude-y.

Appendix: my subscriptions

In case you’re wondering, I’m subscribed to:

• Claude Pro ($17/​mo)
• GitHub Copilot Pro ($10/​mo)

I cancelled OpenAI about a month ago, which is crazy. OpenAI was my first AI subscription! But most of my personal usage is Claude Code, and I ended up using Claude for random questions instead of ChatGPT. And last year we thought OpenAI was so far ahead!

I use GitHub Copilot Pro solely for autocomplete.

I am a computer science student. I got a scholarship to study computer science and AI last year and I love it! It's something that I wanted to do since I was a kid but couldn't afford it.

It's been a huge learning curve. I only had a B in maths from GCSE (which is the exam you take at 16 for non UK folk) and no technical training other than the funny little games I made on OpenProcessing*.

Regardless of how hard it's been, I have enjoyed the challenge. I wouldn't have signed up to study computing if I thought it would be an easy ride. The problem is that my university seems to be having an existential crisis because of AI, and it's making the experience much shittier than it was before.

The flip flopping makes everything uncertain

During my studies, my uni has flip flopped between YOU MUST NEVER USE AI and YOU MUST USE AI and also YES WE'RE USING AI BUT THAT DOESN'T MEAN YOU SHOULD!

They seem to have made an art of choosing the worst possible use cases for AI (marking and feedback, course content creation, and student engagement emails) and going all in on them, only to roll back the decision 3 months later. Students are mandated to use AI in assignments, only to reach the next module where you lose marks for even touching an LLM.

Coursework design has gone down the toilet

I mean, it was never perfect to begin with. Assessing skill in computer science is a difficult problem to solve, but getting Claude to crank out bloated assessment briefs is not the solution. Whereas before, assignments were designed by a person who thought them through at least once, then approved by other people in the department, now I doubt they're getting read more than once (if that). Errors abound, often with corrections coming a week or two before the deadline.

The amount of work involved has also tripled - LLMs don't know how much effort it takes for a student to learn new material then complete technical tasks, and professors are too far along in their careers to notice this when skim reading an AI generated brief. So those of us with less technical experience are forced to speed run content, which SUCKS! I am here to learn, god damn it, not barely scratch the surface of the 15 deliverables I have for a 3,000 word assignment.

Tutors are overloaded (even more than usual)

You know what university financiers love to hear? SCALE! Learning at scale, preferable automated, so they can milk the cash cow as much as possible without paying for extra staff. There has always been tension between educational and commercial interests in every institution, but the AI hype has forced through a level of workload that is unethical and unsustainable for tutors and lecturers. I only hear from my tutor these days when I haven't accessed the online portal in a while, because their data dashboard flagged me as 'at risk' T_T

Doomers left, right and centre

I don't care if computer science and maths are over! I still want to learn about them! OK, I do care about my future career, but it still doesn't mean I want to forget everything I learned or stop progressing on this journey. There are so many interesting avenues to explore (some AI, some not), but I can't move for headlines about how software engineering is over/not using AI makes you obsolete/blah blah blah. Can't a girl learn statistics for fun?

I could go on, but I won't. It'll give me indigestion. Maybe I'll go back to OpenProcessing for a bit and make some more silly games now I actually know how to do a bit of programming.

• Give em a go! Click in the browser frame to activate keyboard controls.
  Simple space shooter with awesome music
  Moogle meow. It meows, that is all
  Make a sound to scare the fish away

At the recent EMFCamp, I bumped in to Professor Kate Devlin who was talking a little about the AI Resist List. I think one of the useful things we can do is loudly complain about shitty uses of AI. Here's an example.

As mentioned in a previous post, I'm contacting companies which send malformed calendar invites. One of the organisation I contacted was the British online supermarket Ocado. They don't have an easy way to contact their technical team, and no obvious paths to raise a bug report, so I filled in their usual customer service feedback form. I included a clear statement of the problem and a detailed technical analysis of why I thought it was a problem with their service.

After sending in my message, I received this back from "Lulu" at Ocado:

Thanks for getting in touch and sharing this feedback about our calendar files.

You're entirely right—having a technical glitch pop up when you're trying to organise your delivery is a real pain, so I've made sure to pass your feedback on to our technical and webshop team.

We really appreciate you taking the time to help us improve our service. I hope you have a wonderful rest of your day

I mean, that's AI right? It starts with the classic tell of a sycophantic agreement.

Next up is the em-dash. Beloved by chatbots but almost unheard of in British English style guides.

Finally (and this is hard to quantify) it just doesn't feel like a customer service response. They're usually poorly spelled, have dodgy grammar, and ask a bunch of irrelevant questions. The message gave me no confidence that anyone had looked at the problem and I doubted it had been passed on to a technically competent human.

I immediately got a customer satisfaction survey. Usually I give top marks to humans because, even though Net Promoter Score is bullshit, I don't want customer service agents to suffer the indignity of a bad review. But in this survey I vented my spleen - giving crappy 1 ⭐ scores on every metric and complaining vociferously about how rude it is to use an AI to deal with a genuine complaint.

I was both surprised and delighted to receive this back a few days after my invective was sent:

I saw your survey comment about getting a robotic, AI-generated response previously, and I wanted to reach out personally to apologise. There is nothing more frustrating than pointing out a legitimate bug only to feel like you're talking to a brick wall. I promise you there is a real person typing this out!

Second, I wanted to send a massive thank you for the incredibly detailed diagnostic. It is rare to get feedback that tells us exactly what is broken and how to fix it.

I can assure you that this has been passed to our team to look into. Your feedback is going to make things much smoother for a lot of people, and we really appreciate you taking the extra time to help us get it right.

Thank you again, I do hope that this issue is resolved quickly. If there is anything else I can help with in the meantime, please don't hesitate to get in touch.

Perhaps I'm being touchingly naïve, but that feels a lot more human, right? The grammar isn't perfect, the sentences are a bit more rambly, and it appears to have actually engaged with the contents of my message.

I get that having a million irate customer service messages is a hassle. Using AI to triage them probably makes business sense, summarising the verbose ones could be useful for customer service agents, and totting up general themes is almost certainly a sensible way to gather metrics without overloading the workforce.

But using an AI to reply to a human is just disrespectful. It says the organisation values their customer's time at less than their own.

It's OK to call out shitty AI responses and insist that a human engages with you.