As our merges per day grew more than tenfold, source control became our biggest development bottleneck. Here, we share how we migrated to an in-house version control system in five months.

At Anthropic, coding is no longer the bottleneck to building systems or doing research. Claude is able to autonomously iterate on research loops, micro-optimize complex programs, and build new services from the ground up at a speed and scale we haven’t seen before. The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI.

In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day. We don’t expect this rate of growth to slow down anytime soon; the latent demand for merging code is practically infinite, and every bottleneck we remove immediately leads to a further increase in the amount of code we produce.

Changes merged to our monorepo per day, from January to September 2026.

In order to support this growth, we built Scion, an in-house version control system, and fully migrated our monorepo from git in five months. We also built and shipped a code review surface (called Antique), code search, a rich source control IAM system, novel ways of managing and landing large amounts of reviewed code, and more, all in that same time period. In this post, we’ll focus on how we built Scion specifically. It makes for an interesting case study: Claude’s ability to write code was both what put us in this situation in the first place and how we were able to quickly build a high-quality, scalable system to deal with it.

Growing our monorepo

Before we explore what we built, we should acknowledge how unusual our workload is. Unsurprisingly, Anthropic uses Claude to write software far more than almost any other company, so we’re often the first to see where tools built for human scale start to strain. Source control is just one example of this. While we don’t expect many organizations to have these problems in the very near term, we suspect it won’t be too long before others who use AI coding tools experience these same pressure points, which is why we wanted to share what we built and what we learned.

Git is a decentralized system: every clone is a complete, self-contained repository that can compute diffs, read history and blame, and check out any revision while fully offline. For the vast majority of repositories, this is the right design, and it’s a large part of why git became the standard.

As our monorepo grows, it increasingly doesn’t fit that design space. The history of our main branch alone is almost 100 GB, and a compressed working copy is over 25 GB. We perform on the order of 25 million code checkouts per day for CI, before counting developer environments, agent sandboxes, and research jobs. Fetched naively, that would be over 600 PB of git traffic per day.

Git offers tools for working with a slice of a repository, such as shallow clones, sparse checkouts, and promisor remotes. Beyond these, there are standard workarounds for large monorepos, like internal git mirrors and repository snapshots (seeds) kept in blob storage. We’ve used all of them—at our peak, we operated several hundred internal git mirrors to deal with the load. This bought us time, but they became harder to operate as our merge rate increased. Seeds fell further from the tip of main between refreshes, and it took more and more care to keep operations that depend on history, like diff and blame, working on partial clones.

The typical setup for scaling git checkouts.

Taking a step back, we noticed that, like most companies, we were using git as a centralized system with one authoritative copy, but nearly all of our clients were agents and jobs that are online by definition. The properties that make git excellent for distributed, offline work were actively undermining our ability to scale as the repo grew. So we asked ourselves: if we designed source control with the fact that agents are always online in mind from the start, what would it look like?

Principles for agent-scale source control

With agentic coding, many common assumptions about how software is developed are evolving. We embraced these changes when building Scion, which allowed us to take a fundamentally different approach than git on several core principles. Source control for huge monorepos has prior art, notably Google’s Piper and Meta’s Sapling, so we were able to build Scion with their hard-won lessons in mind. Our principles are:

Clients are always online. Git assumes that clients work offline and need a complete copy of the repository. Since nearly all of our clients are agents and jobs, we designed Scion’s client and protocols around a server that is always reachable, and have clients fetch data when they need it.

Client-server asymmetry. In git, every client is capable of being a full-fledged server. In Scion, the server answers questions about file history and blame, creates commits, performs merges and rebases, and so on. The client maintains a bounded local object cache, lays out the working copy files on disk, monitors for filesystem changes, and gives users an ergonomic way to work with the server. It can compute very little on its own but, in exchange, it requires much less data locally.

A comprehensive source control service can power many novel applications. With git, a CI job or tool that needs to ask a question about the repository, such as who last changed a line or how two commits are related, has to maintain a local copy of the repo or hope that vendor-specific APIs provide the answer. With Scion, all of the source control queries the client uses are also exposed via API, so in many cases jobs don’t need a local repository at all. Many internal tools, such as our automated bisect and revert pipelines, wouldn’t be practical at scale without this cheap, programmatic access to source control.

Everything must be horizontally scalable. At our peak, we ran several hundred git mirrors, which significantly strained capacity and no longer scaled once the repo outgrew the mirrors’ disks or memory limits. In Scion, the repository’s data is distributed, and every component is independently scalable; there is no fully materialized copy of the repo anywhere, even on the server. There is no equivalent of packfiles (git’s compressed bundles of objects), so no repository maintenance is needed.

Commits must be cheap, incremental, and lock-free. In git, you commit locally and then push to share your work. In Scion, every commit, rebase, or merge happens on the server, so there’s nothing to push, but each of those operations needs to be fast. The cost of creating a commit and updating its downstream data structures has to scale with the size of the change, not the overall size of the repo, or the server can’t keep up. The development lifecycle in Scion discourages refs (pointers to commits, such as branches and tags), except for the main ref or release branches, because global state that every server has to agree on is a looming scaling problem.

The working copy is optional, and sparse by design. Because our monorepo is so large, and because we check out code tens of millions of times a day for CI, we wanted to avoid checkouts whenever we could. With Scion, a CI job that needs the diff between a commit and its merge base, for example, can ask the server for it. The same goes for writes: many write workloads can also skip the checkout and function entirely via API. Scion’s protocol is centered around sparse checkouts, which only contain the directories the client asks for, and virtualized checkouts, which materialize files on demand, so when a job does need files on disk, the client only pays for what it actually reads.

How Scion works

It’s helpful to understand how these principles came together in practice when building Scion. These insights can apply to other source control systems or, more broadly, to other stages of the software development lifecycle.

Data structures

In Scion, the unit of work is a “changeset,” an entry in a write-ahead log. A changeset stores most of what you’d expect from a commit in git. But where a git commit stores a pointer to the tree, a changeset stores a list of the files that changed relative to its first parent,1 along with content-addressed pointers to the compressed file contents in blob storage. Changesets are created server-side and are available everywhere, instantly.

The shape of a changeset in Scion.

This structure lets us accept changesets with very high throughput because there are no packfiles to accept, no locking or cross-server coordination, and no refs to move around. Scion does technically support refs, but since neither creating nor fetching commits involves them, moving one is a compare-and-swap on a single Spanner row that happens separately from creating changesets.

A changeset records only what’s changed, so on its own, it can’t quickly answer questions like who last edited a line or which commits affected a file. To answer those, Scion builds additional data structures from the changesets, including dedicated structures for file blame and path history and skip lists for the commit graph. We call everything that isn’t directly part of the changeset “derived data,” and we compute it all through one generic mechanism. Each type of derived data is defined recursively, so its value for a changeset is computed from its values for that changeset’s parents.

This mechanism has three benefits. First, we can easily add a new type of derived data when a new data structure would make some operation faster. Second, for each type, we can choose whether to compute it eagerly or defer the work, so we avoid materializing data we don’t need. And third, because the client never sees the internals of these data structures, we can optimize them without changing the client. We’ve added new types of derived data many times as the system has grown, such as new indices for performing copy detection or path-based file search.

Scaling Scion

A small fleet of Scion servers provides source control APIs for any operation a client needs, such as getting changesets, computing diffs, finding merge bases, and fetching blobs. All source control data is content-addressed, so a piece of data never changes once it’s stored, and any server can cache it without checking with the others. As a result, the servers are horizontally scalable and require little coordination. They are essentially large caches that can also compute derived data on the fly and write the results back to Spanner.

Scion’s many consumers no longer need to maintain local repositories of their own. Fetching and maintaining the repository used to be a significant maintenance burden for CI jobs or tools that needed to ask source control questions, particularly about commit ancestry and blame. Early in the migration, before we had our own client, repo format, or protocols, Scion only answered these “metadata” queries. Fetching file contents and materializing working copies are far more data-intensive operations, and they needed a design of their own.

Scion’s scn client deviates from git’s fetch protocols in several important ways and, as a result, lends itself to a highly scalable architecture that requires significantly less CPU than git servers. Scion’s negotiation doesn’t tell the server what the client already has; instead, it operates exclusively on trees and blobs the client wants. Starting from a root tree, the client checks its local store for missing trees and requests them recursively, then repeats the process for blobs. Every request is for a specific object that never changes, so any cache can answer it, and the architecture closely resembles traditional tiered caches. The process is also efficient and resumable, because there is no single multi-gigabyte packfile response. Sparse and even virtualized checkouts don’t need special support, because the client simply doesn’t ask for trees it doesn’t want.

In the fleet, the client talks over a socket to a daemon, scion-daemon, that stores objects for the whole node. Most of our nodes need access to the monorepo, and jobs on the same node reuse most of the same objects. Each daemon starts from a periodically refreshed snapshot, then talks only to the tree and blob cache servers in its region, called scion-cache. These cache servers stream objects directly from memory, in the disk format that the daemon will consume, so they don’t need to spend time computing the client’s missing objects or performing delta compression. When a cache is missing an object, it asks the authoritative scion-servers, which read from Spanner or cloud storage as needed.

The scion-daemon, scion-cache, and scion-server all respond to identical RPCs for this protocol, so the client doesn’t need to know the cache topology. Any tier could theoretically talk to any other, but we strictly enforce the tiering to isolate failure domains. We want to avoid a situation where a failure in a regional scion-cache overwhelms the upstream scion-servers and brings down the entire system.

Scion’s checkout architecture.

Each tier of this system maintains a cache hit rate of over 99% and does not require long-lived state, so it’s easy to scale up if needed. Our Scion infrastructure footprint is now 200x smaller than our previous git mirroring infrastructure in terms of CPU and memory requirements. CI and research jobs check out code two orders of magnitude faster (in seconds rather than minutes), which frees up a sizable amount of capacity across the fleet; CI alone realized a 25% CPU capacity win. Neither clients nor caches need to perform repository maintenance, which simplifies the lifecycle management of our jobs.

What we learned building Scion

We started building Scion around the same time as Claude Mythos Preview and Claude Tag became available internally. Both of these releases simultaneously amplified the need for Scion and meaningfully accelerated how quickly we could build it.

Here’s a particularly striking example. Earlier in the year, we had largely handwritten the first version of the git-to-Scion ingestion pipeline as a prototype. We thought it was good—until we got our hands on an early internal snapshot of Claude Mythos Preview. We asked it to rewrite the whole thing, and with no further instructions, it produced a version that consumed 20x less memory and was 4x faster, while preserving all of the implicit invariants around ingestion ordering and data structures.

Merged changes to the Scion and Antique codebases per week, from January to September 2026.

What we learned building and operating Scion offers some interesting lessons for what building agent-scale software could look like.

Rapid development with a small team will become more common. A team of seven people built both Scion and Antique (our code review tool, which we could easily write a whole other blog post about), not to mention half a dozen related systems, and fully migrated to them in five months. We did all this while the volume of code merged per day increased by 10x. In the past, developing and deploying a source control system like this would have taken a company years of iterative migration, with many more engineers. We think this sort of fast, nimble migration will become more common in the future.

Engineers are no less valuable, but their work is changing. All of the engineers who worked on this system would now rate Claude as better at writing code than them. But our engineers still supplied the invaluable understanding of the high-level inter-system components and the design-level tradeoffs, making informed choices around the problems we wanted to solve and the scale we knew we needed to achieve. Very often, we found that the role of the engineers was to tell Claude “no.” Agents will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place. This was particularly common in our migration. For example, there were multiple systems that tried to brute force looking up when a change merged to main by linearly reading the commit log instead of asking our code review tool. Anthropic also makes extensive use of adversarial review, and, while this is incredibly effective in many ways, it can also be myopic, so skilled engineers needed to steer Claude away from over-engineering parts of the system in response to hypothetical concerns. For example, one such review was overly defensive about trusting another internal service, which resulted in Claude adding excessive validation and complexity. Our team members still review every change request for the system, but they now examine the intent of the change as opposed to reading every line of code.

We were able to substantially improve optimization and quality. By virtue of Claude’s ability to write immense amounts of code much faster than we could ourselves, Scion is among the most well-tested and well-defended codebases we have ever worked on. Even on our tight timeline, we were able to build hermetic simulations of every non-trivial infrastructure and source control interaction we’ve ever encountered, as well as fuzzing and sophisticated rate limiting. Claude also casually found significant optimizations—for example, an algorithmic optimization to ancestry queries that missed one of our indexes—that would have taken an expert days or weeks of analysis and tuning… and then did it all again the next day.

Observed performance improvements on native Scion repos.

We laid the groundwork for new forms of monorepo security. Managing safety, security, and compliance in a massive monorepo is as important as managing the size and scale. We built Scion with these in mind from the start. It supports rich access control on repositories, as well as the ability to apply permissions to individual directories in order to protect the most sensitive code without losing the benefits of a monorepo. Furthermore, the code review tooling we built can express complex semantic constraints on approvals, which lets us differentiate simple things like comment-only changes from sensitive logical changes, so that human reviewers can focus on the most consequential changes.

A new level of operational excellence is possible. Our team uses Claude Tag heavily, which has helped us monitor each component of the system. For example, we created Slack channels where we tasked Claude with being obsessively focused on the health of a single component. We call these Claudes “superfans.” We have a scion-daemon superfan, a scion-cache superfan, an Antique merge queue superfan, and so on. They have access to our telemetry and logs, and act like an experienced engineer who has nothing better to do than to refresh charts and look for anything strange. We also have traditional alerts for all of our systems, but our superfans can detect subtle and novel issues that make these alerts seem one-dimensional by comparison.

We’re completely rethinking our priors. This project prompted us to take a very hard look at other workflows designed for human scale. A proper merge queue, for example, doesn’t make much sense at agent scale. What does CI even mean when hundreds or even thousands of changes can merge while tests are running? We haven’t been able to effectively replicate the industry standard of a global repository lock on the merge queue, so instead, we’ve invested in post-merge and pre-deploy automated testing. This does mean that concurrent changes can conflict, but Claude can typically fix these conflicts faster than humans can even identify them.

Contributing to the wider ecosystem

We see Scion as just one part of the answer to the scaling concerns that increasingly capable AI agents have raised. We’re sharing these details as an example of how teams can tackle similar challenges, though we don’t expect our solution, or our considerations, to suit every case.

Scion is by no means a suitable replacement for git for general use. The concepts we’ve outlined here really only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code. Plus, Anthropic is unique in that our ability to spend tokens for internal use far exceeds what any other business would realistically want to spend. We do this both to address our own software development needs, and to test Claude’s capabilities.

Practically speaking, it’s difficult to offer Scion in a form that would be broadly useful to other organizations. It diverges significantly from git, meaning companies would need to migrate every piece of the development lifecycle, and it requires its own code review, code search, and CI. Our internal versions of these components are highly bespoke, so they would be difficult for other organizations to adopt, and we worry that attempting to build a public version that tries to please everyone wouldn’t actually be very useful.

However, we anticipate that this class of problems will become more commonplace over the next six to 12 months, and it would be an inefficient use of engineering resources for every company using git to face similar challenges alone. Given that, we think the most impactful thing we can do is to share our thinking, so that other developers can apply some of the most successful parts of Scion to git without departing from the overall model. A git server doesn’t have to work the same way as a git client does; novel server architectures exist that provide significant scaling improvements. Git platforms can provide comprehensive server-side RPCs like Scion, perhaps even in a standardized way across forges that the git client can learn to talk to. The negotiation protocol doesn’t have to look exactly like it does today, either, and the various sparse and shallow features in git can be made to compose well.

Lastly, we want to acknowledge that the git community has spent nearly two decades scaling the platform for millions of developers. Our contribution is far narrower: sharing our early view into how agentic software development interacts with these systems, so that we can partner with GitHub, GitLab, and the OSS community to support the changing needs of developers. We’re all in it together as the software development lifecycle intersects with the AI exponential.

Acknowledgements

Written by Nick G. and the source control team: S.G., R.K., Dan C., Garrett H., Ben L., Colin M., Joe P. We’re grateful to Vilas J. and Sergiu D. for supporting the source control team on this ambitious journey and Amir O. for early contributions to Antique.

Footnotes

1. Storing changed files relative to the first parent of a merge is a stylistic choice; in practice, we’ve found that people only care about history or blame for commits on the main line in trunk-based development in a monorepo.

For the past few years, I've been working on sprinklz.io, a customizable feed reader that can, among other things, deprioritize certain topics from your news feed.

A month ago, I posted it to HN, and it got a hundred or so upvotes, nice! It seems like people are really tired of hearing about LLMs, and they enjoyed being able to deprioritize them from their feed. It was a good demo of why a tool like this is useful. Everything was looking up, and then…

My website got slow. Like, really, painfully slow. At first I chalked it up to the extra attention of a suddenly popular post. Like any developer I both celebrated, and vowed to make my website more resiliant in the future. Strangely though, the slowness continued, and even started to get worse several days after my post went live, and the metrics I did log did not make sense. Like, you know, a good handful of genuinely active, logged-in users, and a sever exhibiting exhorbatantly high load.

So I took a look at some data. I added top-level logging for every endpoint (how many times was a request made to each url path), and I found that a majority of the requests did not even make an attempt to fetch news articles! For reference, my website is built as a single-page-application, and what this means is that a majority of the requests did not even run the javascript necessary to render the page (!).

Digging further, I looked at aggregate NGINX logs to find abusers, and, you're never going to believe this, but it turns out that nearly half of our traffic was coming from one specific user. I won't name names, but I looked them up, and they describe themselves as a service that listens for changes to a website, and then summarizes them into an AI slop news letter. And by 'listens to changes' I mean query our website many many times per-minute. Blocked.

Several of the others were your standard known crawlers, and kindly identified themselves as such. Claude bot, OpenAI bot, google's search indexer, and several others. I even picked up a few vulnerability scanners along the way. At least, somebody is trying to access -/wp-content/phpinfo.php (my website is not a wordpress site). I added robots.txt to discourage most of the AI scanners, but allow google-bot and other search-related traffic, and asked claude to query all the vulnerability paths and mimic the scanners to make sure I wasn't leaking anything. I also added reasonable rate limits, etc., etc.

The most important lesson though, is that it's time to make my website faster. I want to be the website that can day handle xxx QPS of real traffic, and it should scale better than it did, even under heavy load. Inspired by this encounter, I've made quite a few improvements to the underlying infrastructure over the past few weeks, and these should result in pretty substantial performance gains for all users.

P.S. if you'd like to check it out, the website is fully free, and available here

The TLDR is that it lets you define your own customizations, in addition to things like the points totals from hacker news. You can use it to filter out topics, like AI or LLMs, but the topics are completely arbitrary and you can program your own customizations.

2. Using LLMs to Make the Emacs Web Browser Great Again

When I tell people about the emacs web browser, their first reaction is 'Wait emacs has a web browser?!', followed by, 'yeah… I guess that's kind of a web browser'.

The emacs web browser is designed to render webpages in a terminal-based, textonly environment and, well, it goes about exactly the way you'd expect. It works well on HTML-only, small-content websites, but not so good for anything else.

The problem is that emacs is primarily a text-only editor, but the modern internet is very much not plain-text based. Simple HTML, designed in the simple style of the 1990s has a clear translation into plain text, but modern UI design, with it's visual styling, heavy javascript, and just, overall chaos, not so much.

The emacs web browser would be great, if only we could find a way to go back in time…

Ok, so the plan is simple. We take modern webpages, rewrite their source code into old-school simply-styled HTML, and then pipe it through to the emacs web browser. We just need to find a way to do this easily and at scale.

So um, you didn't forget about LLMs did you? It's nice to be using them in a way that will hopefully reduce the amount of spam content in the world.

Basically, the plan is we write a program that:

• Opens a webpage in firefox
• Loads the page and runs all the javascript
• Asks an LLM to generate a re-usable program that transforms the current-page's contents into simplified text
• Inject the generated javascript into the firefox browser
• Grab the new page source and forward it to emacs web browser.

Yeah, and so, I've been using it, and it runs very well. Like realistically I can use this on many webpages where eww (emacs web wowser) did not run previously.

Below are some examples of before and after:

The docs for Clojure's mapcat

Figure 1: (before) Using eww-readable

Figure 2: (after) Using simpleweb-simplify-page

It takes a moment to generate the initial modifier program, but once it's generated, it runs pretty fast, and during day-to-day browsing, it mostly doesn't need any extra LLM calls. I have been using it myself and enjoying the experience.

The source code lives here: https://github.com/sstraust/simpleweb

and is open-source, and free to install, etc., etc.

2. If technology got better, why did everything get worse?

I think we all know the answer to this: bad incentives.

Technology makes systems more productive, but it does not, in fact, make you in particular more productive. The tools that enable computers to be more efficient also enable people to be more efficient at exploiting your time, attention, and wellbeing. I'm talking neural nets babyyy.

I first noticed the problem in 2018. Or rather, I noticed that I had a problem, and that problem was spendinng 3 hours a day watching starcraft 2 replays and wondering where the time went, and how I managed to stay up til 2am again.

What's interesting to me is that I didn't have any of these problems until the late 2010s. I had a computer with an internet connection since at least the mid 2000s, and a smartphone with twitter and reddit and the like not long after. It's possible that I've gotten less resiliant over the years, but I have a sneaking suspiscion that it's the computers who changed.

I can't quite put my finger on it, but I have this sensation that every time I interact with a system or website, I'm playing this kind of adversarial game, where I'm trying to just go about my day, and maybe read a little article about computers, and they're trying to figure out a way to keep me on their site for just a little bit longer.

I also have this feeling that as software engineering has moved from a discipline of hobbyists and enthusiasts to leaders who increasingly developed through finance or business-minded tracks, we've found ourselves with these major tools that we used to love become both extremely bland and extremely profitable.

So what can we do it make it stop?

1. touch grass. really when the world is like this, i think the best solution is to just leave. it's not easy, especially when the planning is often online, but if you can set it up, I promise that a day in the park playing chess with your friends is better than any amount of time you can spend on the internet.
2. take to the streets. i think that protesting is effective, and more people should do it. if you're willing to take action, it models to others that they can take action.
3. stop coming back to the same machines. I think we all have this gamblers fallacy in us, where if it didn't pay out the first time, but it pays out sometimes, we try the machine again, but it doesn't really work like that. if you're losing money the lesson is to stop putting coins in the machine.

editor's note: I've been working on a free customizable news reader as a way to take out some of my frustrations with the modern internet. if you don't use this one, I recommend following individual blogs and websites, because it's so much better to just get off these big platforms entirely.

editors note 2: i haven't yet posted this latest article to my rss xml, because i'm not ready to send notifications for it yet. will add in the coming weeks.

3. Deft version 0.2.0

Now that deft 0.2.0 is released, I figure it's a good time to talk about what I built, and why I built it.

The point of Clojure's everything-is-a-map toolkit is that getters and setters are a waste of time. Clojure was built, in large part, in response to the crappy 2008 Java workflow, where you had to write getters, setters, and builders, and you took on all this bloat that nobody enjoyed.

The problem is that if you want to represent your data using the built-in defprotocol and defrecord, and you want to define functions that depend on the presence of a certain field, then the only way to encode that information into the protocol is to add getter and setter metohds to it. icky.

You can also use a combination of protocol + malli schema to represent this, but then when you use it, you need to specify 'this function takes as input something that both implements this protocol and implements this Malli schema'. Also icky.

What we want is something we can use in the style of defprotocol and defrecord, but gives us all the getters and setters and map-like stuff by default. The key insight is that if a field exists in a record, we get all the other good stuff, so we just need to add support for protocols with required keys.

Deft v0.2.0 adds support for namespaced keys in type and protocol definitions. i.e., you can now do:

(defp Positioned :required-keys [::pos - ::Point])

and

(deft Circle [::location/position radius])

(>Circle ::location/position [1 2] :radius 12)

this is useful because you can now define methods that depend on those fields being present i.e.:

(defp Gremlin :extends [location/Positioned])

(defmethod game-object/get-hitbox ::Gremlin [self]
  (js/Matter.Bodies.rectangle
   (get-in self [::location/pos ::location/x])
   (get-in self [::location/pos ::location/y])
   15 15))

Check it out!

https://github.com/sstraus/deft

4. How much LLMs is too much LLMs?

I finished reading On the Edge last week, and it was bad. Not that I don't respect Nate Silver. I respect him a lot. So when his seminal text on gambling and risk taking was a rambling mess, I was suprised and disappointed. Nevertheless, a completionist at heart, I trudged on, to the very end, where I was greeted with this message:

"ChatGPT was a significant help in writing this book, serving as a creative muse when coming up with things like chapter subheadings, metaphors, and analogies, and for refining my understanding of technical topics that are likely to be well represented in its corpus."

Technically he wrote the book by hand, and technically he typed the letters onto his keyboard, but you know, did he really? Did he put his whole thought and mind and being into every word on the page? Maybe. I'm reminded of the absolute classic [Simple Made Easy](https://www.youtube.com/watch?v=SxdOUGdseq4), a video where so much of the core lecture is built on defining precise language, and saying exactly what you mean. When you offload that work, you don't just skip word choices, you skip that thinking, and you miss out on that organization and mental clarity.

In reading Nate's book, there's a real and noticeable difference between the language that feels baked into the organizational fabric of Nate's mentality, and the bits that were added on as an afterthought. The later chapters especially felt like they lacked that sort of mental compactification that cohesifies everything under one vision. I'm sad because this could have been a phenominal work, and it's clear that a lot of effort was made, especially into interviews and data collection, and it feels like it's just lacking that one last missing piece of insight to bring it all the way home.

So how much LLMs is too much LLMs? Well, when it comes to human connection, I'd say the answer is near zero. I don't want to read your AI generated e-mails, and I certainly don't want to read your AI generated essays. I'd much rather read your prompt instead, because I care about what you, yes, you personally think about, and I want to understand what you wanted to communicate.

Don't get me wrong, I love LLMs for the right purpose. I'd love to use LLMs on doctor's notes to build models that predict whether the flu is spreading. But when it comes to writing, especially this kind of writing, it just feels so unnecessary, because when you write down your thoughts, I already have exactly what I wanted, and it just feels so silly to add an extra stop in between.

As a poker player and game theorist, I'm sure Nate would appreciate the phrase "If you couldn't be bothered to write it, then I can't be bothered to read it". And you know, despite a belief that art can live separately from the artist, deep down for me this claim rings true. Not that the same words produced by a person are inherently different than the same words from an LLM, but it throws off my little Bayesian estimator a little.

If the smartest person I know spent 10,000 hours writing, editing, polishing, and publishing a 500 page novel, it tells me not just that the smartest person I know had some thoughts on a topic, but it tells me that they decided to spend 10,000 hours of their precious time, and of their precious energy to communicate this idea to me. It feels good that the time it took me to read it is porportional (and usually less than) the time it took you to write it, because it shows me that you care about the time and energy of creating this exchange.

And it's not just fully AI generated slop that hits this barrier. When you incorporate LLMs into your writing, even a little bit, you miss out on the ability to process your thoughts and create human connection.

5. Building Chess in about 350 lines of Clojure

I recently released deft, a Clojure library that defines types and protocols using plain maps, and so, to take it for a spin, I wrote the game of chess in Clojure.

Chess is a good trial run for any class and interface system, because it's reasonably small and self-contained (and has some pretty obvious choice for classes), but it also comes with some of the messiness of a real application, in that, you want to write something concise, but you still have to handle edge-cases, like castling and en passant.

I hand-drew all of the pieces, and used this little reagent snippet to render the display,

[:h-box
 (doall (for [x (range (count tiles))]
                  ^{:key x}
                  [:v-box
                   (doall (for [y (reverse (range (count (nth tiles x))))]
                     ^{:key y}
                     [:p {:style {:background-color (cond
                                                      (= [x y] @currently-selected-location)  "yellow"
                                                      (= (mod (+ x y) 2) 1) "white"
                                                      :else "black")
                                  :height "4rem"
                                  :width "4rem"
                                  }
                           :on-click (fn [] (move-selected-piece
                                                    game-board-atom
                                                    currently-selected-location
                                                    [x y]))}

                      (if (not (nil? (get-in tiles [x y])))
                        [:img {:src (image-path (::piece-type (get-in tiles [x y])))
                               :style {:height "100%"
                                       :width "100%"
                                       :filter (when (= (::color (get-in tiles [x y])) ::black)
                                                 "invert()")}}]
                        "")]))]))]

but kind of the interesting bit is how to represent the board state and all of its pieces.

I did sort of the obvious thing, and defined types representing a chess piece, and then a board, as a 8x8 grid of pieces

(deft ChessPiece [color piece-type])


(deft ChessBoard [tiles - [:vector [:vector [:or :nil ChessPiece]]]
                  curr-move - [:enum ::white ::black]
                  move-history - [:vector ChessMove]])

and then for the piece behavior, I made protocols that define how a piece is displayed, and how it can move.

(defp PieceType
  (image-path [this]))

(defp MovablePiece
  (is-valid-move-for-piece? [this game-board start-location end-location]))

here is an example for the knight:

(deft Knight []
  PieceType
  (image-path [this] (image-asset "knight_white.png"))
  MovablePiece
  (is-valid-move-for-piece?
   [this game-board start-location end-location]
   (and
    (let [direction (map abs (map - end-location start-location))]
      (or (and (= (first direction) 1) (= (second direction) 2))
          (and (= (first direction) 2) (= (second direction) 1))))
    (is-valid-end-location? game-board start-location end-location))))

is-valid-move-for-piece? returns a true-false value of "can my piece move to this square".

This works great for most pieces, but is insufficient for more complicated moves, like castling, where several pieces move at the same time. To handle this, we use another multimethod

(defmulti special-move-for-piece (fn [x & args] (:type x)))

that is defined only for special moves, and returns the actual state of the modified gameboard.

so for pawns, it would look something like this:

(defmethod special-move-for-piece ::Pawn
  [this game-board start-location end-location]
  (let [curr-piece-color (::color (get-in (::tiles game-board) start-location))
        move-direction (into [] (map - end-location start-location))
        prev-move (last (::move-history game-board))]
    (cond
      ;; en passant
      (and (= (second move-direction)
              (if (= curr-piece-color ::white)
                1 -1))
           (= (abs (first move-direction)) 1)
         (= (:type (::piece-type (::piece prev-move))) ::Pawn)
         (= (apply max (map abs (map - (::end-location prev-move) (::start-location prev-move)))) 2)
         (= end-location
            (into []
                  (map +
                       (map (fn [x] (/ x 2 )) (map - (::end-location prev-move) (::start-location prev-move)))
                       (::start-location prev-move)))))
      (-> game-board
          (update ::tiles assoc-in start-location nil)
          (update ::tiles assoc-in end-location
                  (get-in (::tiles game-board) start-location))
          (update ::tiles assoc-in (::end-location prev-move)
                  nil))

      (and (is-valid-move-for-piece? this game-board start-location end-location)
           (or (= (second end-location) 0)
               (= (second end-location) 7)))
      (-> game-board
          (update ::tiles assoc-in start-location nil)
          (update ::tiles assoc-in end-location
                  (assoc (get-in (::tiles game-board) start-location)
                         ::piece-type (>Queen))))
      :else nil)))

I'm not going to copy-paste the movesets for every piece in this post, but it was pretty straightforward to define relevant methods for all the different piece types and special-cases, and I'm pretty happy with how the code turned out. When you're reading this code, it really looks like somebody just wrote down all the rules for the game of chess, and that's what makes me feel good, and feel like we've done things in a way that's well organized.

But now, sort of the most important question (for me) is:

is this library actually helping? did deft make our lives better?

I think it did, for the following reasons:

• deft gives us the features from both protocols/records and multimethods/plain-maps, so we didn't need to decide which tool was right for our use-case. this removes just like a lot of cognitive load, because we can use one tool, and trust that it can do everything pretty well.
• in particular, it was nice to be able to define :default method dispatch for our protocols, and it was extremely nice to be able to reload protocol method defs from the repl without having to re-instantiate the entire chessboard (and clear the current position)
• it was really nice to be able to enforce when I wanted method defs to be defined for a particular type, and it was really nice to have an easy way to add Malli schema

Overall, I'm pretty happy with how it all turned out, and I'd say the test of our library was a success.

You can find the entire code for

the game here: https://github.com/sstraust/deft/blob/master/examples/src/examples/chess.cljs

the library here: https://github.com/sstraust/deft

and the detailed video explanation here: https://www.youtube.com/watch?v=lrofmFI1UJY

6. Announcing Deft: A class and interface system for Clojure and ClojureScript

Today I'm releasing deft! It's a library that replaces clojure's existing class system with plain maps and Malli schema.

It took me about 6 months to really think it through all the way, and get the design just right, so it feels good to finally publish it.

The library: https://github.com/sstraus/deft Video Tutorial: https://www.youtube.com/watch?v=dlW6YzwUZ-M On Hackernews: https://news.ycombinator.com/item?id=46590958 (plz star the repo!)

Synopsis: This library came out of out frustrations with Clojure's existing type ecosystem. Both defrecord/defprotocol, and plain maps+multimethods, the way they are currently used, make Clojure programs fundamentally difficult to organize and refactor.

The problem is that:

• Clojure records use single-colon (unnamespaced) keyword access to lookup record fields
• Clojure records do not allow you to define abstract classes, or things that rely on complex dispatch behavior.
• Clojure maps are extremely difficult to nail down and make stable. Even with libraries like Malli, it's hard to declare interfaces that explain "what can I do with this thing?"
• Unless you are extremely regimented about defining Malli schemas for every single use case, it's easy to get things disconnected during destructuring, because missed field lookups return nil

The goal is to give something that's still enjoyable to work with, but lets you really nail down the behavior when you want to (and still keeps it ergonomic and fun).

A secondary goal was to make something that is reliable and stable, and is (hopefully) easy to adopt in existing codebases. check it out!

7. My Blog is Now on RSS

if ur reading this i can publish to my blog w/rss.

im using org-rss-export-to-rss with some very simiple tooling. i thought about using hugo but idk it seemed too heavy and i kinda like the minimalist feel. im optimistic that hugo will be better when i set it up right, and i will probably need some of its features eventually, but thats a battle for another day.

8. How to Win at Wordle

I played my first game of Wordle this week, and I got in 4!

Ok, I got a little bit lucky, but it wasn't all luck. While I was playing I had a chance to think through some of the strategies, and saw some pitfalls I think others might have missed.

8.1. Don't guess letters that are already green

Unless you're trying to make your final guess to win the game, you shouldn't guess the same letter in the same place. You already tried that, so doing it again doesn't give you new information.

Your "guess" is guaranteed to be wrong, but you now rule out (or find!) another possible letter when you go to actually solve the puzzle. Lets see an example:

Suppose you have B - A - _ - E - S, all green. You just need to guess the last letter, but there are a lot of remaining options. Among letters you haven't guessed in that slot, D, K, N, R, S all work. You could guess every letter individually, but you most likely won't get it first try, and worst case it will take you five turns. Instead, if you guess D - R - I - N - K, a word that you know is wrong you "guess" every letter at once, so you're guaranteed to get it in 2 (you guess S if there are no yellows).

8.2. When you guess new letters, put them in places they commonly appear

Just for a moment, think of worlde a little bit like binary search. Your goal is to learn as much information as possible with every guess. If your guess splits the problem space in half (i.e. you eliminate half of possible words if it shows up green, and half of words if it shows up yellow), you learn (on average) the most possible information with every guess.

Now – you only get to guess a letter in one position, so either it's in the one specific position you chose, or it's in any of the other possible four positions. If you want these two outcomes to be roughly equally likely (or as close to equally likely as possible), then that one position you chose had better be really likely to make up for 4 other slots.

You learn (on average) way more about the letter 'Y' with a guess like R - A - I - N - Y, than you do with a guess like Y - E - A - R - N.

8.3. Guess common letters first

Basically the same logic as above. It's either one of the 5 specific letters you guessed, or it's one of the 21 other letters. You want to guess the 5 that most closely split the problem in half.

Going a step further, once you have a few lines guessed, you want to guess the most common/most evenly dividing letters given the letters you already have. Q is a bad first guess, but if you already have a U down, then maybe…

8.4. Think through the list of possible words at every step

Remember, your goal is to "divide in half" with every letter. If you have a sense of/random sample of the words in the space, it's easier to pick the letters/positions that divide that list the most precisely.

9. The Power Of Habit (Book Review Pt 1)

Charles Duhigg was a reporter for the New York Times, and you can feel it in his writing. This is a modern-science report that's sensational, inspirational, and often highly misleading.

This book has it all, self-help transformations from couch potatoes to superstars, the success of Starbucks and the Colts football team, all simply explained by the power of habit. Of course habbit only plays a small role in each of these things. Of course every football game comes down to a little bit of luck (even left up to the wind and the weather). But – someone adopted good habits and later become successful – BOOM – causation – done – problem solved.

Beyond the wild conclusions though, there is some real (and recent!) science being done, and our changing understanding of habits is both interesting and powerful. For me the key takeaways are:

Habits circumvent our normal process of reasoning (and aren't stored in the same brain-area as planning and short term memory) Habits can be modelled as a sequence of trigger – action – reward. If you're missing one of these pieces, you won't trigger (or learn the habit loop) Habits can live latent for a long time, even as we move on from them. Make no mistake though, this book is meant to be transformative. What can YOU do to change YOUR life, just like Peyton Manning did? Again, the science is mixed here, but it seems like the author's point is:

Habits are hard to un-learn, but it's easier if you break them down into the trigger – action – reward lifecycle. If you can swap out the action, but keep the trigger and reward the same, you can hijack your bad habits to learn good behavior. If you want to make a transformative change, it's easiest to focus all your attention on one habit, and then the rest are likely to follow. Habits can be a good thing. Thinking is hard, and deciding what to do takes effort. If something (like choosing what to make for dinner) takes mental effort, your less likely to do it, because that mental effort is as much work as the actual cooking. Try to form habits, and try to think about what you're going to do ahead of time, so that when you get to the moment of truth, it doesn't take effort.

10. Modern Monetary Theory and You

Like any political agenda, modern monetary theory isn't perfectly specified, and people often tailor its definition to their own ambitions. As best I can tell it goes like this:

If you're a country that controls its own currency, its ok to go into debt, and you can print as much money as you want as long as it doesn't cause inflation.

Some people argue that with the power of MMT, we have the money to finance all of our wildest hopes and dreams, if somebody would just have the courage to turn on the money printer. Free college, loan reimbursement, free housing, we could pay for everything with a click of a button, and no negative long-term reprecussions. As long as we don't cause inflation, there really isn't anything to worry about.

10.1. The Big If

The thing is, that's a pretty big if. You can "prove" anything you want if you start with a false assumption. If we could print infinite money, and not cause inflation, that'd be pretty awesome, but is such a thing even possible? How did we get here, and why does anybody believe we can do this?

In theory, economics is based on supply and demand. If everyone wants apples, but there are no apples available, the price of apples goes up. If nobody wants apples, but every citizen has a stockpile of 100 apples, the price (and the implied value of apples) goes down.

In the same way, if everyone in the United States magically had 12 million dollars, they'd all be competing to use that money to buy the same limited supply of things. Many people want 3-bedroom houses, but there aren't magically more of them. It's the same people competing with each other to buy the same house. In order to outbid someone with 12 million dollars for something they really want, you also need to spend millions of dollars.

Fundamentally, people want money so that they can use it to buy goods and services. On a global scale, if every government printed more money, but didn't also increase the global amount of available goods and services, you're not increasing everybody's real buying power, because everyone is still competing to buy the same limited number of goods and services. You only increase real wealth if the number of goods and services produced also increases.

10.2. How We Got Here

So if America went out tommorrow, and started printing tons of money, and taking on tons of debt, we'd expect the cost of everything to go way up. We'd expect government bonds to be much less valuable, right? Right?

Well it turns out that during the 2008 financial crisis, the U.S. did print a lot of money, and did take on a lot of extra debt, and everybody expected inflation to happen, but somehow it just… didn't. Markets are hard to reason about, and nobody really understands why it happened, but people have thrown around some theories:

The United States is considered a trustworthy institution, and people need a safe place to put their money. The world financial system is already so invested in the U.S. dollar that the U.S. can do whatever it wants. The stimulus bill spurred so much economic growth that it offset inflation.

10.3. The United States as a Trustworthy Institution

Ok, so, we took on a lot of debt before, and it was fine. We printed a truly wild amount of money, and people still trusted us as a stable, reliable institution. Everyone believed that the U.S. government would pay them back, and would pay them back in dollars that held value.

Even in a crisis caused by the U.S. economy, the U.S. looked like a safe place to put your money because the U.S. always had been so responsible, and so reliable in the past.

So – if we suddenly started being irresponsible, like, racking up huge debts and printing money to pay them back, people will keep lending to us forever, right? Right?? If we don't produce anything, we can just keep printing money forever, and people will just give us stuff, right?

There's this idea that because we're borrowing in U.S. dollars, and that U.S. dollars are the de-facto currency of the world, we're never in trouble, because we can just print more money to cover our losses. But do you think people will keep lending to us if, in terms of real physical goods, we're not offering anything meaningful in return? Do you think people will continue to use USD as their default currency if the U.S. government buys all your stuff, but gives you paper, and no items in return?

We could technically pay off our debts by printing a shit ton of money, but from an investing perspective, it would be essentially the same as default. We made a promise, and in terms of goods and services, we're not providing any real value to fulfill that promise.

Defaulting on a loan is so dangerous because it destroys your credit. If you go bankrupt, it's super hard to get another loan because people don't trust you anymore.

In the same way, even if the U.S. doesn't technically default on its debt, if it covers up by printing more money, it's essentially going to have the same effect because people won't trust us anymore.

We can "cash in" on our current trust and influence, but once we break that trust we can't rely on it as strongly anymore.

10.4. Take From the Rich and Give to the Poor

The argument goes something like this:

Wealthy people have money, and poor people don't have money. So, if we print some extra money, and give it to poor people, it lowers the value of the rich people's money, effectively taking buying power from rich people and redistributing it to poor people.

It accomplishes a goal people were already after, in a way that's clean and simple.

The thing is – rich people don't own wealth in dollars. The very rich know that dollars aren't necessarily stable, and they own houses, stock in businesses, and even precious art. When you inflate the values of dollars, it doesn't really affect a lot of the rich people, but it does hurt others.

The people that it does hurt are the ones governed by a fixed $15 (or less) minimum wage. The people it does hurt are the lower-middle class people that don't know much about investing, and just keep all their money in a savings account. It helps people who are in debt, and might have some other positive effects, but for many it's more a destabilizing element than it is helpful.

10.5. Stimulus and Economic Growth

Ok so there's a real argument here. The idea is – it's ok to print money because we can generate more goods and services. If we spend it wisely – build bridges, improve broadband, we can create jobs for people who were previously out of work. What's more, that new infrastructure and spending will spur even further economic growth.

If for every dollar we spend, it generates $N dollars of economic activity (how is it even possible to reliably calculate these things?), then we're not just printing money, we're printing value.

This is one of those arguments that I like because it's logically consistent. If we produce more goods and services, then even though there's more dollars in circulation, there's also more stuff to buy with those dollars. If it really creates that much growth, then it works.

The challenge here is it's extremely optimistic. Is your government so smart and well organized that it's going to create 10 trillion dollars worth of value? It might. We've had our shining moments, and I'm hopeful that we'll make it count, but most of the time it doesn't work out that way.

11. The Perfect Camera

Every year, sometime around the holidays, I splurge on one really nice thing for myself. Locked inside during quarantine, there hasn't been much to spend on, but I've had a great time doing landscape photography. We still haven't been to bars and restaurants, but we can drive around in a car, and we've been exploring parks in and around New Jersey.

This year I set my mind on a new camera. Something a little bit nicer than I already had, maybe that I could use to print pictures and big posters.

I bought my first camera in December of 2018. I remember spending ages picking something out, and eventually settling on a Nikon Z6. I really wanted a D850, but along with lenses it was too expensive for consideration. I also looked into the D750, but even though I liked the idea of an optical viewfinder, mirrorless seemed to be the way of the future, and an old DSLR would make me a dinosour. I also looked into some other brands, but Canon didn't have great mirrorless options yet, and I didn't love Sony as a company.

Fast forward two years later, and here I was in the same spot, spending ages to pick out a camera.

In the mean time, I also had the chance to try out an old school DSLR (the D610), and I absolutely loved it. The image quality was better (SOOC at least). The optical viewfinder was a relief to use. Even more than that, the whole camera was just so well thought out and well constructed. Every button was in exactly the right place and there was always a button when I wanted one. Things like white balance, buried in menus on the Z6 were just one tap here. They even had a well functioning assist light that basically solved all my problems with low light focus. It felt like whenever I needed something, I reached out and the D610 had an answer.

This time I had spent so little during the course of the pandemic, I decided it was time to go for a really nice camera. Every brand/style was on the table. I decided that I was going to get the best camera, and then not have to think about upgrading it again, at least not for a really long time.

Of course, I quickly found out that it's not so easy. Even if you had all the money in the world, different cameras have different tradeoffs. The ones with the best image quality are big and bulky. Some cameras technically have lower dynamic range, but beautiful and natural image rendering. Mirrorless cameras have face and eye detect, but miss that great optical and mechanical feeling.

Really each camera gives you a different experience, and different cameras are "the best" in different situations. If you're taking selfies you want a flippy screen. If you're bringing a camera to dinner, you want something fashionable and lightweight. If you're shooting an event, you need the very best in reliability and focus tracking.

I definitely wanted something small that I could take to game night with my friends, but I also wanted something (potentially big and heavy) that could shoot landscapes with the very best image quality. I very quickly realized that I wanted different setups for different situations I was in, and that no camera was going to be perfect for everything for me.

Between everything, I kind of narrowed it down to three situations I usually shoot in:

Photo walks. I set out specifically to take nice landscape photos. I want an enjoyable shooting experience and the ultimate image quality. Less weight is nice, but I don't really mind heavier cameras or slower autofocus too much. Friends and Family memories. This is the camera that I'm taking to hang out and play minigolf. I don't need the ultimate image quality, but I want something unobtrusive and super reliable. I care that I'm going to get a usable image in any and every situation. If the family photo in front of the Eiffel tower comes out blurry, we're not making another trip, and we're not spending 2 hours readjusting to get the perfect shot. It's also important here that if someone else is taking the picture, it still comes out nice. Portraits/selfies – this is somewhere in between the two above. You have more time to set up your environment/carry the right lenses, but you still want fairly reliable face/eye detect. 4.1 The Contenders

4.1.1 Canon

Canon makes professional dslr and mirrorless cameras.

Their most recent professional mirrorless, the R5 is a solid all-arounder that, from what I can tell, preforms very well in almost all situations. It's fast enough to capture sports and wildlife, has very good face/eye detect for ease of use in capturing friends/family memories, and has very good (although expensive) glass for ultimate image quality. As a very big plus, it even has a flippy screen, which is maybe not so useful to professional photographers, but very useful for including everyone in the family portrait.

The only real downsides of the R5 is that it's very expensive, and that it overheats when taking video (although I don't take 8k video it still makes me kind of nervous to have a camera which can overheat). Part of the challenge is there isn't much third party RF glass, so you're stuck with Canon's very good, but very expensive lenses. Canon's colors are known to be good, but I've also heard that the R5/R6 have a flatter profile than earlier Canon DSLRs, meaning it can take some more work in post to get very good images.

They also make a professional DSLR, which is popular, and produces solid SOOC results, although it has worse dynamic range and few meaningful performance improvements over its Nikon counterparts.

Canon also makes the RP which is a much smaller, and lower performing version of the R5

4.1.2 Sony

Sony's A7R4 has the highest resolution, and the best face tracking of any mirrorless camera. It's thought to be a technically very precise camera, although considered lacking in some ease of use features like nice SOOC jpegs and nice ergonomics. Now that the face tracking and tech specs of the Canon have mostly caught up, I think it's harder to justify, especially because I don't love Sony anyway. It is much cheaper though, especially when you take cost of glass into consideration.

Sony also makes the A7C which, paired with a Zeiss 35 2.8 is one of the smallest packages you can buy that gets very good image quality. They also make the Rx1R which is higher resolution, but lacks a flippy screen and IBIS, and the RX100, which is much smaller, but along with a 1" sensor, lacks some of the quality you expect from a dedicated camera.

4.1.3 Nikon

I own a Z6, and the face/eye detect is just bad. It's bad enough that I don't feel like I can fully rely on it. I've taken photos that just look bad, and then later realized that my camera just missed focus. I can't even use the single-point af because the joystick moves the focusing point too slowly.

I've also noticed, that compared to the images I took on the D610 the color balance is slightly off, especially when I use the camera with adapted F-mount lenses, in a way that makes the same image with the same lens just look less pleasing. Maybe there's a way to bring it back in post, but I just find the images from the D610 look way nicer and are way easier to deal with.

Maybe Nikon fixed the AF issues in their Mark II. Maybe the colors look right if you use the latest and greatest Z glass and make adjustments. Maybe the autofocus works better without the adapter. But at this point, I just don't trust them. I really like the Z mount glass, I just wish they had a better camera behind it.

In contrast, my experience with the D610 was just great. A 10 year old camera with performance that holds up to today's standards. Buttons and ergonomics just the way I wanted them. Not a new idea but a fully iterated, rugged, professional camera. It felt like everything I needed was thought through and provided for. And most importantly: the image quality, straight out of camera, was near perfect.

The D850, Nikon's newest DSLR is the next iteration of the D610 (well technically, several iterations). It keeps most of the same design and build quality, uses the same F-mount lenses, and, from what I can tell, renders images in the same very nice way. It's actually missing a few features from the very well designed D610 (e.g. more incremental WB adjustments and a built in flash), but for those small sacrifices, you get a much higher resolution sensor, better dynamic range, better AF points, better color retention if you push the image, and much more.

Unlike the Z6, I trusted the D610, and I knew if I got a D850 with basically the same stuff, I would get basically the same very good images (although hopefully a tiny bit better).

I was waiting/hoping for Nikon to release a successor to the D850, but based on the more recent D780, and other recent camera releases, I guessed that:

They probably wouldn't significantly increase the resolution. At least, it wouldn't make sense if they released a DSLR with significantly more resolution than their most recent mirrorless offerings. They would probably port the same bad face and eye detect from their mirrorless cameras into live view mode. I actually prefer the contrast detect on my D610. It might be slow, but at least it's reliable. Adding phase detect also means more stuff on the sensor that can affect image quality. They might add IBIS, and I'd really like IBIS, but it's not a super big deal since a lot of my lenses already have it. 4.1.4 Leica

I feel like leica is one of these brands where people buy into it to figure out if it's actually worth buying a Leica. Is it really a much smoother ride in a Ferrari? You'll never know unless you try one.

Jokes aside, I've thought of a few real reasons why people might want one:

They render nice. This is one that's hard to qualify, especially when the technical charts don't always back up these claims, but some people like the overall image rendering/asthetic feel of leica images. They look nice. Ok, for a photographer it feels like it shouldn't matter, but it does matter, and it matters because it affects whether you take it with you. If you show up to the royal wedding with a D5 you look like the paparrazi, but a leica is stylish and classy. You might even wear one as part of your outfit, just to look a little bit hipster. They're small. Have you seen the enormous Nikkor 0.95 Noct? Have you seen it in comparison to the leica noctilux? The noct is a little bit better, but you're getting what would normally be very big full-frame primes in a very small package. That means something you can casually carry, and something that fits better in casual environments. They're rangefinders. If you want the rangefinder experience, leica is pretty much your only option. I don't think it interests me, but if you need a manual focus rangefinder leica is the place to be. I like that Leica's are super small. It matters to me that I can take them with me, and that they stay out of the way when I'm not using them. It feels more relaxed to go out to dinner without carrying an enormous DSLR.

The challenge is, Leica's don't have great autofocus (if at all), and are entirely lacking in "ease of use for non-professionals". They're a great lightweight vacation camera for fun photowalks, but if I go on a nice family vacation, I want a nice family photo, and Leica cameras just don't get the job done. (The q2 sort of does).

4.1.5 Fujifilm

Their APS-C line of cameras is solid (and nice-looking!) but I felt they weren't small enough to justify the difference in quality to a body like the A7C. They also make the X100V, whose rangefinder style is very appealing, but there are smaller, lighter cameras with better image quality.

The GFX system is an adventure, because it's a little inconvenient, but undeniably a better performer than any other practical system. When other manufacturers announce 100MP the images might look more grainy, but pull that off with a larger image sensor, and you really are getting 50% more space. Not just that, I can tell the just-released GFX 100S is something special. Not only does it fix the ergonomics of the original GFX 100, not only does it fit the performance into a tiny, dslr-sized package, but it's an absolute bargain at 60% the cost of a GFX 100.

I wanted one because I knew cameras that are that kind of performance breakthrough can hold their own for a really long time. It's like they made a substantially better camera than their absolute medium format flagship, and are charging less money than not only their own flagship, but those of full frame competitors. The D850, when it came out, was a big deal 4 years ago, but this is a big deal that's happening right now, and will continue to be significant far into the future.

I can't quite vouch for the Fuji color science, as I haven't quite put them through the paces like I have my Nikon's, but I've heard great things about their color science, and their film simulations look really appealing, at least from the online test images I've sifted through.

The big problem with the GFX system is that there aren't that many available lenses. The lenses they do have are stunning, some even considered significantly better than their DSLR counterparts, but you have to stick with the lenses fuji gives you, and if you need something specific, like a 14-24 2.8 you're out of luck. This is one system where you're really buying into the glass as much as the body, so you can't just think about the camera in isolation, but how it performs with the lenses you're actually going to use.

If I bought into the GFX system, I wanted the 32-64 f/4, and the 45 f/2.8, both very high performing lenses, though I do wish they had a true 24-70 f/2.8 equivalent, and some other options with more range.

4.2 Decision Time

I knew that, due to the pandemic, I was pretty much cut off from normal social events for a few months to a year, so it didn't matter too much if I carried a big heavy DSLR around. I also didn't want to be the guy that had a million different cameras falling out of his pockets for different situations. The key here is it's ok to take your selfies with a cellphone. You can have a nice camera, but every photo doesn't need to be the ultimate in high resolution image quality. If you just want a nice memory of making pancakes for dinner it matters more that you don't interrupt the memory that you're trying to capture. Maybe if I bought a million cameras, I would get one really tiny one, but it's not what I need right now, and phones are a pretty solid replacement for non-photography photos. I'm also a little wary of fixed-length prime cameras, because once you start cropping, you lose all the benefits in image quality.

I wanted to try all the cameras out in person, but also due to the pandemic, I wasn't really able to visit a camera store. I could get sample images online, but it's always hard to tell how much editing has been done, and how much is due to the scene's lighting and the skill of the photographer.

With that in mind, only looking at big, high-performing interchangable lens cameras, I narrowed down my search. The Nikon Z and A7R cameras were out of contention as I considered them surpassed by the Canon R5. The 5DMark4 was also out of contention, considered surpassed by the D850. That left the remaining options as: The Canon R5, The Nikon D850, and the Fujifilm GFX 100s.

The R5 has excellent RF glass, is a well rounded camera, has a flippy screen, and the benefit of very functional face and eye detect. Plus canon are known for making nice, easy-to-use camers. The thing is, in terms of lenses, Tamron's glass is much cheaper, and very high performing (especially the 35/1.4!), and the face-detect in live view on the D610 is actually very accurate and usable, albeit too slow for fast-moving subjects. The colors straight out of camera are also thought to be a little flatter than it's DSLR counterpart. The thing that I'd really miss most from the R5 is actually the flippy screen, but I figure if we need to take a group photo that badly, we can just ask someone to take our picture. Compared to the D850, it's also missing tons of buttons and the optical viewfinder experience.

The GFX 100S is the camera I gave the most thought to. Paired with the 45 f/2.8 or the 110 f/2, it gives the very best image quality of any practical camera, and it feels good to know that you have the very best. If your image doesn't look as good as the stock photo you find online, it feels good to know that it's not because you took the wrong camera. In programming, we think about debugging as "finding the source of error that broke your software", and having the very best makes your system simpler because there's one less source of error that you have to check. You don't have to go back to the same place and try it with a different camera, because you know that it wasn't the camera's fault. It lets you stop thinking about gear and focus on other factors that make something into a good image.

Although competitive with the R5, the D850 is also a 4 year old camera. With the way technology progresses, it's fortunate to have a camera that lasts 10 years before obsolesence, and it's already mid-way through it's lifespan. By comparison the GFX 100s is not just new, but groundbreaking, a big leap forward in technology that seems likely to stand for a long time. You're buying into a system that's big, and new and rapidly growing, compared to one that's slowly being phased out of existence. It's also on it's fourth iteration, and it's really getting the attention to detail that forms it into a full fledged product. It lacks a vertical grip, but for the most part it's very flushed out, and doesn't have anything major that's still clunky or missing.

Between the D850 and the GFX 100s, the decision was the hardest because the GFX 100s is just such a compelling option.

But ultimately….

I went with the D850. The big thing for me is I loved using the D610, and not just that, I trusted it. I didn't know if the GFX 100s would be fun to use, or if it would render images the way I liked, but I knew the D850 would, because it was just the same as the D610. I remember before I bought the Z6 two years ago, some reviewers told me that it rendered nice and had usable autofocus, but in my mind, they couldn't be more wrong.

Lack of available lenses on the GFX system was also a huge deal for me. If you shoot at 35mm, and then crop it down to 85mm, you're not getting any of the image quality of a medium format sensor. If you shoot the GFX system, you're stuck with a paltry 2x zoom range, meaning that you're not going to get the shot unless the composition lines up exactly with the one lens you happen to have.

Some of the fuji lenses are great, don't get me wrong, but not all of the lenses are perfect, and if something I need is missing, I just can't get it. The 45mm, 110mm, and 32-64mm are considered by most reviewers (and tech charts) to be near perfect, but the same isn't true for other focal lengths. What if I want an ultra-high performing 35-150? What if I really need the long end of my 24-70 f/2.8? Not only are you stuck buying expensive fuji glass, but you're unable to make choices about which lenses best suit your use case.

Even for the same focal length, choices matter. Fuji only has one real pancake lens, but it's not what I want it for. I want a 28mm pancake, and a larger/higher performing 50mm, but fuji doesn't offer that. Not only that, some of the lenses might not render the way I like. Tamron and Sigma both make excellent 35 1.4s, but I like the look of the Tamron, and I don't want to give that up to move to the Fuji system.

I know I said at the beginning that I was willing to switch systems (I definitely would have if only the Z6 were available), but it is nice not having to trade in for new lenses, and more importantly, I've already done my research, and I know which lenses I like, and which lenses are good for the things I need them for.

4.3 The Grand Finale

My D850 arrived in the mail a few weeks ago, and it's exactly what I wanted. It's just like the D610, except the focus is snappier and the resolution is higher (the images even look a little crispier too). As a work of engineering, it's just so well thought out, and so well designed. It's also built like a tank and looks like it could survive anything. The only things I really miss from the D610 are more granular temperature adjustments inside of auto-white balance, a dedicated retouch button inside of playback mode, and a built-in flash. I also prefer having the white-balance button on the side of the camera, rather than at the top by the command dial, even though it's placement on the D850 is still very logical. You get a little grain sometimes along with the higher sensor resolution, but I think it still outperforms the D610 when binned down to a fair comparison.

But the thing that really blew me away, and the thing I didn't expect, is how well the D850 files perform when you try to edit them. If you push a D610 file by 2 stops, it looks washed out and you have to bump the exposure and contrast to compensate, but on the D850 I experienced no such thing. They're mostly comprable SOOC, but once you try to edit them, the colors from the D850 just look better, and are so much easier to get right.

In terms of image quality, I feel like I bought the D610, but even better. I'm getting the same look that's both exactly what I wanted, but even nicer looking than it was before. It works perfectly with the lenses I know and am already very happy with. I love shooting through the optical viewfinder.

It's a 4-year-old camera, but, weirdly I don't think it's going away for a really long time. The latest-and-greatest from canon and sony offer almost no improvement in image quality (I actually like the Nikon better), and I don't even find them significantly more easy/enjoyable to shoot with. I don't think Sony will obsolete it's brand new Alpha One any time soon, and the Tamron 35/1.4 is on par with the very best of mirrorless glass. It is a 4 year old camera, but it's my favorite, and I think it will remain competitive for a very long time.

12. Camera Lenses: What's in My Bag

Camera lenses are expensive. If you own a DSLR, chances are your lenses cost more than the camera body itself. This is because lenses are often the bottleneck for image quality. If you're looking through a blurry window, it doesn't matter how sensitive your sensor is.

In addition, camera lenses come in all sorts of shapes and sizes. Physical limitations mean you can't have one lens that just does everything. If your lens has a massive zoom range, then it probably sacrifices some image quality. You want to choose the lens that's right for the situation you're shooting.

If you want to find the right glass for you, you should think about the situations you take photographs first, and then choose a lens that is appropriate for that situation. Unless you're in a studio, or have a very patient subject, chances are you don't want to switch lenses on the fly, so you want a lens that encompasses the entirety of that situation.

So what's in my bag?

5.1 The portrait lens: Tamron 35-150mm f/2.8-4

Most pro photographers carry two zoom lenses, one 24-70 f/2.8 and one 70-200 f/2.8. But for portraits, neither of these gets you entirely what you want. 85mm is widely considered the "standard" portrait length, but 50mm and even 35mm are also common. The problem is, the range of focal lengths used for portraits is like a normal distribution centered around 70mm. In order to get the right photo, you'd need to constantly swap between the two lenses. I've used a 24-70 for portraits, and I found myself constantly near the long end of the zoom range, often wishing I had just a little more.

The Tamron 35-150 is perfect because the center of it's zoom range is also the center of the range I use for portraits. It has a little more zoom (5x vs 3x) than the standard 24-70, but it's not one of these ultra super zooms that sacrifices on image quality. Most of the lab tests rate it similarly to some of the older 70-200 f/2.8 lenses, so you're not losing much over one of the more standard zooms.

In addition, it's quite fast. It's variable aperture, so you lose some of that speed at the long end of the zoom range, but 2.8 at 35mm is just as fast as a standard 24-70. This means if you find yourself indoors without a flash, it's still sometimes usable.

There isn't quite an everything and the kitchen sink lens, but for me this is as close as it gets. I'll often use it if I'm going on a day trip somewhere unsure of what I'm going to be shooting. The downsides are it's very large (especially with an FTZ adapter), it focuses a little slower and less reliably than some of the native Z lenses, and it's a little less sharp and less fast than a good prime lens.

5.2 In the dark: 50mm f/1.8 G

Ok, well, I'm currently looking to upgrade my 50mm to a different lens of the same type, either the 50mm f/1.8 Z or the 50mm f/1.4 Sigma Art. I bought it because it was cheap, and did something none of my other lenses had. It's not even sharper than my zoom lenses at it's only focal length of 50mm, but it does have one thing those zoom lenses do not: a maximum aperature of f/1.8. If it's dark, and you need light, a fast prime is your only option. Once you're already cranking your camera's ISO the extra stop over an f/2.8 makes a huge difference. A fixed length prime is the least flexible, but it's important when you need it. Also, most fixed length lenses are sharper than their zoomy counterparts, but not this one :(.

5.3 Lightweight Travel/Group Photos: 24-70mm f/4 S

I'm gonna be honest, the only reason why I own this lens is it was half off when it came with my camera. Don't get me wrong, it's still a good lens, but I probably wouldn't have gone out and purchased it on my own. What I like about this lens is that it's super reliable. It's a native Z mount lens on a Z body camera, and the autofocus just works better than any of the other lenses on the same camera. The image quality is also consistently good at f/4 throughout the zoom range, so much so that I don't have to think about it. If I'm going out for the day with casual people, this is the lens that I take. Most people don't want to wait while you fiddle with your settings, and most group photos don't care about artistic framing. The people care that you got the shot, the one where everyoen was smiling, and it didn't come out weird. If it's blurry that's really bad and you likely don't have that many do-overs. It's also super small on the Z body, and feels nicely balanced. Most travel photos I take are wide-angle anyway, because I want to capture the environment, and you're often in those situations where you have to pull the shot quickly and not mess it up. The lack of light can be inconvenient sometimes, but so far it hasn't been worth it to me to shell out for the much better (and much more expensive) 24-70mm f/2.8 S lens.

13. Why Many Primary Forecasts are Wrong

Ok, wrong might be a little bit too severe, but at the very least unfairly biased. I think most models underestimate Warren and Sander's chances of winning the primary because it evaluates the voting in every state as a single event, rather than viewing the primaries as a sequential selection process. In past elections, while the later states still matter, the early voting states have had special significance because they narrow down the pool of candidates by eliminating out candidates which seem unlikely to win.

Let's say you're a Democratic moderate. Even if you really really like Tulsi Gabbard, you're probably not going to vote for her, because you know that if you do, your vote won't matter. Since she's not going to run anyway, you might as well vote for Mayor Pete or Joe Biden. When the votes from the early states come in, they tell the people what candidates are unlikely to win. When a candidate does badly in an early state, people become less willing to vote for them and they become even more unlikely to win.

While eventually the race usally comes down to two or three, often closely split candidates, it's important to remember that primary elections are an unstable equillibrium, and it can be easy for things to snowball. Right now Biden is by most polling clear favorite to win the election, with roughly double the odds of the next major candidate. But it's important to remember that this is because Elizabeth Warren and Bernie Sanders split the progressive vote, and their policies and supporters are in many ways very similar. If one or the other starts to outpreform in some of the early states, they're going to start picking up all of the progressive votes, and start to become competitive in the states where Biden was heavily favored. While Biden could also gain some ground from early victories, he has less room to grow because the moderate vote is less split, and the other candidates to gain from like Mayor Pete, have some significant ideological differences.

14. The Wonky Math behind the Democratic Primary

Oh man, if you thought the electoral college was bad, you're in for a real treat.

On paper, it looks like primaries are mostly the same process. Every state gets "electoral college delegates", and the number of delegates for each state is the same as in the presidential election: two plus some extra porportionate to the state's population.

The thing is, the number of delegates is porportional to the state's TOTAL population, not the number of people that actually vote in the election. If California has 50 million citizens, but only 5 people actually vote, those 5 people have tremendous influence. In primaries, certain states are dominated by particular parties. That means even though Tennessee has 5 million elligible citizens, it only has 400 thousand voting in the Democratic primary. That means if you're a Democrat in Tenessee, you have much more influence than a Democrat from California. The state is considered large even though the number of Democrats actually voting is small.

7.1 Biden is Winning in States with Low Voter Turnout

Ever wonder why Biden seems so unpopular with so many voters, yet forecasts frequently predict him to win the election? Biden's best state's, according to 538: Alabama, Mississippi ,Delaware ,South Carolina, North Carolina, and Louisiana, are ALL low Democratic voter turnout states. Biden isn't actually that popular with the Democratic party overall, but it doesn't matter because he's disporportionately popular among the subsets of people that have the most voting power.

By contrast, take a look at the best states for Bernie Sanders: Vermont, Utah, Washington, California, Colorado, New Hampshire, all heavily Democratic states. Because he's appealing to more liberal states, and because his message resonates with certain groups of people, he's being disproportionately hurt by the electoral college relative to his popularity.

https://fivethirtyeight.com/features/biden-is-the-front-runner-but-there-is-no-clear-favorite/

15. What's Going on With The Impeachment

The impeachment trial, as it stands, is a little bit of a mess, with what feels like many muddled and ever-changing accusations, against a president who keeps doing new things to be accused of. Right now Nancy Pelosi orchestrated an impeachment vote in the house, but has stalled refusing to send a vote to the senate. Given all the confusion I'd like to take a step back to understand how we got here, and why it all happened the way it did.

Before anything, we need to understand that this is first and foremost a popularity contest, with a jury of the American public. There are legal rules, sure, but the people who are voting on impeachment are congressmen, and congressmen represent the desires of their constituents. You can see this in the correllation between congressmen's willingness to defend Trump and his popularity within their home state, as well as how their treatment of him changed as he rose in popularity within the republican party. In order to get him impeached, the Democrats need to convince the people that he should be removed from office.

8.1 The Russia Investiagtion

On November 8, 2016 Democrats were absolutely stunned. Despite all the polls from trustworthy sources like the New York Times*, an unthinkable candidate had won the election. There had to have been a mistake. There had to have been something deeply wrong, Democrats everywhere searched for an explanation.

Not believing that such a candidate could have won fairly, they blamed James Comey for unfairly reporting on Hillary's e-mails just days before the election. They blamed misleading polls discouraging Democrats from voting in an already "certain" election. And finally, they blamed Russia for interfering in our Democratic process, certain that for this to happen, rules must have been deeply and influentially broken.

There was a lot of evidence suggesting wrongdoing. Trump always seemed to have a soft spot when he spoke of Russia. There were the meetings in Trump tower. And Trump seemed to be doing everything in his power to kill the investigation.

The first weeks of Trump's administration were hectic to say the least. Trump picked fights with anyone and everyone. He struggled to assemble a cabinet and wound up leaving many key government positions unfilled. He seemed hell-bent on ignoring all rules and structure, as much as he possibly could. And finally, in a move that shocked many, he fired the person investigating him, FBI director James Comey.

Things moved quickly. Deputy Attorney Rod Rosenstien appointed a special counsel to replace Comey in the Russia investigation. Mueller seemed like just the man for the job, and over the coming weeks, his team gained momentum. Democrats saw not only mountains of evidence piling up, but real criminal offenses, with Mueller and his team reaching indictment after indictment. And Trump, although powerless to fire Mueller seemed to be doing everything in his power to kill the investigation.

The Democrats saw the way the investigation was going, and they saw the indictments lining up, and they made a crucial tactical error. Instead of zeroing in on the firing of Comey, the offense they knew he had committed, they threw all their efforts behind the Russia investigation, doing everything possible to stoke public excitement for a dramatic Mueller testimony.

They had a precedent from the Nixon investigation, one of the few issues on which Trump lacked positive sentiment within the Republican party, and what looked to be an undeniable act of treason. They thought the Mueller report was going to be a bombshell. That they were going to catch Trump red-handed, and that it would suddenly and dramatically sway public opinion. They were expecting something so severe that it would be impossible to claim impeachment was a purely partisan investigation. Even many Republicans were holding their words, waiting to see what the report described.

A week before the report's release, the Democrats made another tactical error. Instead of demanding Mueller first testify to the public directly, they allowed his report to pass, largely unquestioned, through Trump's justice department, and Attorney General William Barr. I don't know if they could have stopped Barr from publishing his letter, but they could have kept the tension, pushing people to wait for the bombshell that was the final report. Instead, they let the singular news story, the one they were building up for months, be not Mueller's report itself, but Barr's report on Mueller's report.

8.2 The Mueller Report

On March 24, 2019, Barr issued his letter to Congress. The verdict was "no collusion", i.e. the investigation did not establish coordination between Trump and the Russian government. Importantly, despite all the evidence in the report, Barr himself decided that Trump had not committed obstruction of justice, and attached his own findings, instead of the report's in his letter. Mueller himself described Barr's letter as a mischaracterization of his report, and in another mistake, Mueller expressed his discontent privately instead of immediately going to the public.

It was only after the full report was released, nearly a month later, that people began to realize what happened. Most neutral media organizations and fact checkers described Barr's letter to be intentionally misleading. Instead of "totally exhonerating" the president, Mueller had carefully layed out the case for obstruction of justice, and seemed only to not reach a verdict because it was not in the mandate for his report. In addition, instead of finding no evidence of direct collusion, he did suggest there was questionable behavior towards Russia.

By this point the moment had long since passed. Democrats had been hyping up a jarring news story, and what they got was a drawn out fizzle. There was a lot of dirt in the Mueller report, but Democrats didn't get the conclusive proof they claimed was lurking. They tried to pivot and push further, but having failed the first time, it looks like they were just grasping at ways to accuse the president.

If they had focused in on obstruction of justice, they would have gotten the president on an act they knew he had committed, and bad news from the Russia investigation wouldn't have broken their momentum. On the other hand, if they had spent months arguing that Trump had broken rules by firing Comey, and real evidence was found from the Russia investigation it still would have been the bombshell they needed to sway public sentiment and press further. This is again an instance where Democratic leadership was too confident and failed to plan effectively to minimize their downside.

8.3 Rebuilding a Case

In the months after the Barr's letter, the Democrats were frustrated and disorganized. They sensed Trump was doing something wrong still, and pushing the boundries, but they lacked a single rallying cry. If they had done so from the beginning, their strongest play would have been to rally around the firing of James Comey, but by now years had passed, and it would be hard to pick back up again.

Despite the lack of a central rallying cry Democratic voters were angry, and they were growing more angry with each new presidential offense. More and more moderate Democrats, long evasive, now publically voiced their support for impeachment. As primary season rolled in, all eyes turned to the candidates, who felt rising pressure from the left-most wing of the party. Unable to avoid the question in debate after debate, the candidates all lined up in support of impeachment. Only Nancy Pelosi and her closest allies held their breath.

8.4 The Ukraine Scandal

Finally, in September, news broke that President Trump asked the Ukranian government to investigate Hunter Biden the son of his chief political rival. Abuse of power to investigate a political oponent drew such a parallel to Watergate that it immediately set off alarm bells in politician's minds. Not only did they have more evidence of wrongdoing, but their anger had a central focus once again. Pelosi, sensing a shift in momentum, announced that she would begin the impeachment process. After an announcement from their extremely cautious, yet trusted leader, the rest of the Democratic party followed suit.

Why was Pelosi cautious for so long? I think it's because you only get one shot to announce articles of impeachment (or at least, if your first attempt fails, it makes your second attempt harder). I think she was saving it, waiting for a news story like this one to break, so that when something like this did come out, she could investigate it and apply pressure on it. Starting an impeachment proceding draws national news coverage, and she wanted an event that the American people would see as definitely wrong, something that was worth spending her news coverage on.

The impeachment process also makes it easier for the Democrats to carry out a formal investigation. This means that the democrats got to learn about the Ukraine scandal in more detail, and potentially uncover even more damaging information. In addition, waiting for so long gave some kind of additional credibility to the investigation. It sends the message that Pelosi feels "we don't want to do this, and we won't unless we really have to, but as it turns out we really have to."

The OpenAI algorithm for the FFT is less a breakthrough and more a malicious exploit.

Hi there, argmin readers! Today’s post looks at part of OpenAI’s math repository that claims to compute faster Fourier transforms. It’s more technical than usual, but I tried to add some tutorial material for people who need a refresher course on signal processing or computational complexity.

---

The Fast Fourier Transform is one of the most important innovations in digital signal processing and one of my favorite algorithms. The FFT is a fast way to extract the frequency content of signals, letting you rapidly analyze, filter, and manipulate frequencies across different bands of the spectrum.

The Fourier transform computes the energy in each frequency band through a simple dot product.1 Let x denote your input, a length n array of samples, and f a frequency. Then the amount of frequency content in x at f can be computed by the formula:

For digital signals, a bit of math shows you only need to compute n of these dot products, one at each multiple of the frequency 2𝜋/n, to understand all of the frequency content. Naively, this requires n multiplications and additions for each frequency. Hence, computing the entire Fourier transform appears to require n2 arithmetic operations.

The fast Fourier transform is a clever recursive procedure devised by James Cooley and John Tukey in 1965.2 The main idea is that a length-n Fourier transform can be computed by shuffling the input vector, computing two Fourier transforms of length n/2 on the shuffled components, and then recombining the outputs using atomic arithmetic operations. The shuffles and recombinations take a linear number of arithmetic operations. Repeating this procedure iteratively, namely, log2(n) times, computes the full discrete Fourier transform. With the bookkeeping, the FFT computes a length-n Fourier transform in fewer than 5 n log2 n arithmetic operations.

To make this acceleration concrete, when n is 1,000, n^2 is 1,000,000 and 5 * n log n is around 50,000, a 20-fold speedup. When n is 1,000,000, the speedup is 10,000-fold. These speedups can be the difference between a transform being computable or not given the constraints of a signal processing application.

Since the invention of the FFT, people have looked for even faster Fourier transforms. One question is just how fast you can go. It seems like you probably need at least n operations to compute the FFT, as it takes n steps just to write it down. The FFT is 5*log2(n) times slower than that reasonable speed limit, and that 5*log2(n) factor can be big. It’s 200 when n is a trillion. Can you do something clever to reduce that prefactor of 200?

Well, lo and behold, in the massive paper dump OpenAI took on the mathematics world last week, they claim to have a faster Fourier transform. The main claim from their discriminatively named “main.pdf” is

I was intrigued about what was going on here. The log(n) term, in theory, was a teeny tiny bit smaller than in the standard FFT.

Did I read this paper? Of course not. No one at OpenAI read this paper either, so why should I? I did what every other mathematician in the world does with AI slop mathematics: I fed it back into the slop machine and ran an information retrieval session with a chatbot interface to extract salient facts. Anthropomorphically speaking: I asked ChatGPT what it thinks about its own output. This is how we do mathematical research now. What a world.

Unfortunately, I did not find a faster Fourier transform. Instead, I found the rot that develops inside applied mathematical theory when formalism becomes so detached from reality that a “breakthrough” is nothing more than an artifact of mathematicians not being able to properly specify the rules of their games in natural language.

First, “big-O” notation has been so abused that it has become meaningless. Let’s review the definition, which impressed me as an undergrad. An algorithm has running time T(n) = O(F(n)) if there exists an integer N and a constant C such that

That is, the number of steps the algorithm actually takes is upper bounded by a constant times some convenient function F(n) as long as n is large. F(n) is usually something familiar and interpretable, like a polynomial or exponential function. This notation says that we only care about what happens when the size of the computation is large. We care about the asymptotic growth rate of the computation time. All constants are equivalent.

Big-O notation is useful for shortcuts in algorithmic accounting, but it also allows for remarkable logical laziness. If we want a practically faster FFT, we want an algorithm that requires fewer than 50n operations for reasonably sized n. But O(n) does not mean 50 n. It could mean 1080 n. This would be considered a “linear time” algorithm. An algorithm that requires n + 1080 is also considered a linear time algorithm in the big-O regime. An algorithm that only has linear-time guarantees when n is greater than 1080 is also considered linear time. 1080 is approximately equal to the number of atoms in the known universe. That is why Richard Lipton and Ken Regan call algorithms with unfathomably large hidden constants galactic algorithms.

The OpenAI FFT algorithm is definitely galactic. The estimated values for C were 10100 when N=1012. So even when n=10100, the venerable Cooley-Tukey-Gauss FFT would be 1099 times faster.

So why is this new FFT result interesting? Well, note that in big-O notation, it is technically asymptotically faster than the Cooley-Tukey algorithm because

I mean, sure. But given the constants, the algorithm runs faster only when n is impossibly large. Roughly, you need

whatever the hell that number means.

Lipton and Regan argue galactic algorithms are useful because they spur research. Once you show a running time is asymptotically possible, you can spend your time finding an algorithm that practically achieves this provable running time. Maybe you can send your AI agent swarms after it. You do you. Maybe you can get a practical algorithm out, but I don’t know of any legitimate examples where this happened. I’m particularly doubtful here, because the model of “computation” OpenAI uses bears no resemblance to an actual computer.

“The model uses exact complex arithmetic.” That means it assumes you can store and multiply complex numbers at arbitrary precision. Indeed, the algorithm requires you to multiply complex numbers whose magnitudes grow superpolynomially with n. If you stored these numbers as bits, the memory requirement would effectively be exponential in the input length. It assumes you can multiply such arbitrarily large complex numbers together in a single operation. We do not have computers that can do this. So even if this theorem in main.pdf is “true” (no one knows, and I don’t care), it’s not actually solving the problem we set out to solve when looking for a faster FFT.

For people familiar with theoretical analyses of the FFT, that you need an absurd model of computation to break the FFT speed limit isn’t surprising. In 1973, Jacques Morgenstern proved that you couldn’t get a Fourier transform faster than ½ n log n if you required that complex coefficients used in the computation had bounded magnitude. That should have been the end of the story! But it wasn’t. People said Morgenstern’s restricted coefficient model was too restrictive. Forty years later, Nir Ailon showed that you couldn’t compute an FFT faster than n log n without severe numerical instabilities. This was also too restrictive for some people, I guess.

This new OpenAI result is thus less a mathematical breakthrough and more an oddity of computer scientists being bad at formalizing their design specifications. The “theoretical” definition of a computer is very far removed from the computers we actually build. The “faster” Fourier transform is merely an example where theory gets so unmoored from the original question that an “open problem” becomes nothing more than an academic status puzzle. The solution is like what happens when you set computational bot streams at impossible problems and find them engaging in illegal hacking.

Many of the other “big” results in this OpenAI slopository could be critiqued in the same way. For example, one of those results was a galactic algorithm to multiply two matrices in O(n^2.25) operations. The construction used in the paper does not let you even estimate the constant that hides inside big O.3 It may as well be infinite, computable only with the divine music of the spheres.

Still, if written substantially better, these papers would have made it into the most prestigious publication venues for the theory of computer science (i.e., refereed conference proceedings from STOC or FOCS).4 The matrix multiplication paper would have likely won awards. But neither of these has anything to do with computers!

This is because the theory of computer science has a culture that actively discourages running algorithms on a computer. It’s acceptable to write papers in theory conferences that assert an algorithm exists without ever writing it down. The theory of computer science has become a form of mathematics that doesn’t concern itself with computers, and it offers little reward for impact outside those mathematical pursuits. I explained this to a friend who remarked to me that “theory” has the transdisciplinary meaning of “hiding in obscurity of one’s own making.”

AI is really good at automating our worst tendencies. It amplifies the unspoken cultural practices no one likes, but no individual can reasonably deviate from. It exploits the mechanized traditions recalcitrant to collective action. In that vein, AI can now write useless theory papers. But perhaps in the absurdity of the distasteful OpenAI trash dump of proofs, we can all look up and realize together that we should consider doing something else.

1

Kids these days call it cosine similarity.

2

The wikipedia page says it should be credited to Gauss in 1805! Proper credit assignment is a perennial problem in academia.

3

That one shows that for every epsilon greater than 0, there is a constant C so that T(n) <= n^(2.25 +epsilon + C/log(n)). No matter which queries I try, I can’t get an OpenAI model to give a quantitative estimate of C. Whatever!

4

Another bad tradition is computer science choosing its most prestigious venues as hastily reviewed conference proceedings.

Exploring practical ways to make your game more legible to AI agents and how to make agentic iteration faster.

I gave a 45 minute presentation entitled “Your Game Is A Harness” as part of Indie Rodeo in Calgary on 9/12/26. After speaking with a lot of people after my talk, I thought it would be good to more broadly share the ideas I presented there in a form that could be enjoyed by people beyond just those who attended the conference.

Also, because I talk about AI a lot on this blog, people assume I use AI to write. This is not true! Everything below is 100% human authored, with me writing the post with basically only the slides I presented as a reference (this is not a transcription). As much as I enjoy using AI to write code and tools, I get a similar enjoyment out of writing “the old way”, especially as I have no reason to try and make any part of this process more efficient.

So with that all out of the way, I present to you my first ever blogification of a talk I gave. Enjoy!

---

Introduction

[I give a small introduction to myself and my own work, that I’m omitting here, as you’re on my website]

I want to talk about using LLMs in game development. Not one-shot type demos that look cool on Twitter, but like real development. Where you’re working eight hours a day, 5 days a week, etc.

And before I get into it, I think it’s useful to level set about LLMs. Or at least get into some basics so the rest of what I talk about here makes sense. I recognize that for a lot of this people this will be review, so if you just want to get into the dev-loop stuff, scroll down to the next section.

My journey into using LLMs for dev work started with a moodboarding site I made called mood.site. This was pre “agentic” anything, but I wanted to test and see if ChatGPT at the time could actually code anything. The process was a lot of me just blindly copy/pasting code into ChatGPT’s web interface. The process sucked, but I was surprised at the results. I built the site! It worked! I still needed to verify a fair amount of stuff myself, but it was enough to convert me. If I didn’t have access to an LLM I wouldn’t have been able to make that site happen in near the amount of time it ended up taking me (~2-3 weeks of nights, probably like 20 hours total). I’d probably still be working on building the first version today.

Since then, mood has become something of a testbed for me moving through LLM stuff (and a mildly successful project on its own!), and has inspired me to kick up lots of other projects that use similar stacks. Additionally, LLMs have gotten better, especially with things like Claude Code and later Claude models. From my own experience, I feel like now there is very little, if anything, I think an LLM can’t do when it comes to a web-based stack.

It could be easy to then say LLMs can do everything, as so much of software is web software. But whenever I tried to use an LLM on building a non-web game thing, it was this resounding takeaway:

“LLMs are Bad At Games”

Any time I tried to use an LLM for a game-y thing, it would fall over. Maybe this is my own bias. I’ve been a game programmer for nearly 15 years, I think I know how things work. I can sniff out “bad” game code a mile away. But when it comes to Svelte web-apps, I’m decidedly less well versed and am inclined to think that whatever code the LLM produces is “good”. Maybe it’s actually garbage. But there is reason to believe the Svelte and web-stack stuff is quality, in part due to the fact that there are LOTS of high quality web projects with their source available online. Comparatively for games, I imagine there are orders of magnitude less data to train on.

Not only this, but games have a lot of stuff in them that isn’t code. Games aren’t just about putting static images and text in a layout. There are tons of things in games that aren’t easily representable by code. AND then on top of that there is all the same text layout stuff of web, but only as a subset of the 100 other systems a game needs to handle.

This is part of the reason why a lot of people have been making games in Three.js — they can easily represent assets as plain boxy primitives and skip a lot of the asset generation/conforming work and processing normally required for games. As a result, a lot of that stuff is slop because it lacks any real authorial voice outside of whatever the LLM median is.

However, maybe they have a point.

A key idea of the one-shot Three.JS workflow (as well as LLMs proficiency at building web apps) is that everything is code. By having stuff as code, it’s very easy for an LLM to be able to reason about it, make changes, etc.

However for traditional games, this is not the case. Or at least the full story. Games obviously have code, but there is a lot of other stuff that is not code. This means that there are key components of games that are effectively opaque to an LLM. If your game then relies on the effective puppeting and transforming of that opaque stuff, then an LLM is going to fall over when trying to work on your game.

I think a lot of the gamedev community maybe gave LLMs a go a bit ago and ran directly into this. The “LLMs are bad/not useful/etc.” sentiment (massive caveat here, just talking about capability specifically and not potential society-ending implications) came from running headfirst into these limitations.

This is to say that, structurally, LLMs are bad at reading games. At least in their default state.

LLM Basics

Let’s talk more about why, and what we can do about it.

Any call/prompt to any LLM service breaks down into three basic components. A system prompt, an assistant prompt, and a user prompt:

System prompt: Generic text shared across all users of a service. This usually describes the basics of the LLM itself, with something like “You are Opus 5, an intelligent Large Language Model created by Anthropic…”. This isn’t to say these aren’t important (they are), but more that they aren’t super-relevant to our use case. You can see some examples of posted (and exfiltrated) system prompts for models here.

Assistant prompt: This is kind of a sidecar prompt section meant to help guide the AI in terms of what it is responding to. You can think of it basically as the model’s basic “interaction” vector with your prompt, and represents something like the model’s “response” to the user based on some input. You usually do not have to think about this.

User Prompt: This is really The Thing. Most any input you put into any AI tool goes here. Any submitted chat, code, etc. gets dumped into this section. When people talk about “context”, they are largely talking about “how many tokens are stored in the user (and assistant) portion of a prompt”.

It may be easy to think that each chat is a “fresh” version of the above, but what actually happens is that, as you work with a model in a given session (the bounds of “session” vary based on what service you are using — this can be a single Claude Code session before closing it, a “chat” accessible in the side panel of a web hosted model, etc.), every prior message you sent to the model is re-submitted every time you send a message. It’s kind of like playing the old playground game where, on your turn, you have to say everyone else’s thing again before then adding your own thing for the next person to have to add on.

Screenshot 2026-09-24 at 8.35.14 AM

Context and Context Pollution

As you do this over and over, you build up the “context” of the session you’re working in.

Screenshot 2026-09-24 at 8.35.51 AM

This is all well and good, but a key thing to notice here is that you only really are able to address the “latest” thing in your context (i.e., you submit a new message). Things from previous messages get submitted over and over again to the model. Hence, you want to make sure what’s in your context is “good”, otherwise you can find yourself in degenerate scenarios where your context becomes polluted due to “bad” things earlier continually informing new work.

Screenshot 2026-09-24 at 8.47.56 AM

Managing context then is a key thing in working with LLMs, and a new engineering practice called “context engineering” has emerged in light of these constraints. Context engineering asks “how can we get the best information into the context, with as little pollution as possible”.

There is a great blog post here on “ways long contexts fail” that goes a bit more into this, but I’ll highlight the key part here:

Screenshot 2026-09-24 at 8.50.21 AM

Context Engineering itself is a really big topic that is outside the scope of this talk/blog, but we will be using some of the tenets of it here to explore how to help LLMs do a better job working with games.

Said differently, getting LLMs to work well with games is a context problem, not something that is intrinsically linked to how games or LLMs “are” (or “aren’t”!).

Screenshot 2026-09-24 at 8.52.19 AM

The complicating factor here though is, games are weird. Or at least: we have no real template to build a game. We have game engines, but there is effectively 0 standardized tooling for anything, in part because every game manifests its own needs differently from one another.

Screenshot 2026-09-24 at 8.56.06 AM

This is acutely unique to games (imo), but it manifests enough in other technological domains that a new concept has emerged in order to get agents to effectively “work” with whatever your work product is: Harnesses.

Some Description of the Idea of a Harness

The general idea of a Harness is that it’s some set patterns of actions an agent is meant to take in response to some well (or loosely) defined expected input. You’re probably already using a harness like Claude Code, but these can be augmented, extended, distilled, abstracted, etc. to better support the specific work you are trying to do. There’s also been a LOT of action in this space recently, with many harnesses being built for developing all sorts of things:

Screenshot 2026-09-24 at 8.59.31 AM

The key things these are all pointing to is: “how can I better understand what I’m building, and guide that process as it is developed”. Harnesses can tie in things like iterating with a browser, telemetry, profiling, and even full SDLC work like making tickets, documents, etc.

However, the thing none of these do well is actually talk to your game. Your game is a bit of a black box, and most of what’s visible to an LLM is only the code-as-written, which as we talked about before, isn’t really enough. We know LLMs are already good at working with code, so it’s not like some harness itself solves that “games aren’t just code” issue we ran into in the first place.

What really needs to happen here is that we can take all the stuff in games, and try to turn it into something the LLM is able to work with. We need to crack open the black box of your game and make more of it addressable directly by an LLM.

Screenshot 2026-09-24 at 9.06.06 AM

Screenshot 2026-09-24 at 9.06.24 AM

During the talk version of this I had this Very Funny Slide that said that the arrow here was the actual content of this talk. The joke hits nowhere near as hard in blog form but I’m leaving it here for posterity:

Screenshot 2026-09-24 at 9.06.38 AM

Screenshot 2026-09-24 at 9.07.28 AM

So let’s talk about what we can do.

Let’s Make a Game Legible To AI Agents

Here’s some very tangible, actionable things you can do for your game to make it more legible and workable by an LLM.

As a brief aside before getting started, it’s also worth noting here that a lot of these tips are good for game development in general. They get supercharged a bit with AI, but doing any of this will likely make working on your own games generally just better.

Fixed Randomness

A running theme through this whole talk/post is the concept of determinism. Basically, how accurately can you reproduce a very specific state in your game. The general goal is that it should be very easy, and very exact. Doing this at the very end of your production will be VERY hard to do, and would likely require fundamental changes to your game in the 11th hour.

Instead, if you assume this constraint before you write your first line of code, and stick to it as a goal, you’ll be paving the path to a much more productive end game and not find yourself fighting off entropy and spaghetti code.

Starting off here is pretty easy. At the start of your game, create a single source of seeded randomness. Make sure any call to anything non-deterministic uses this source of randomness. This means that your game will be able to deterministically recreate almost any state in the game. If your code calls Random.Float or whatever in 30 places to determine some gameplay behavior, you know that the 30th call will be the same every time. Easy.

Screenshot-ability

Why have reproducible states? Many reasons, but for an agent, imagine you’re iterating many times on trying to correct something. It’s important for the agent to be able to get to the same state from scratch over and over again without needing to churn through state replication failures.

And once you get there, how do you know? How can you evaluate those changes?

Well for one, screenshots! Most engines have some built in screenshot API or functionality:

Screenshot 2026-10-01 at 12.22.01 PM

I also recommended adding in the ability to easily toggle UI layers, gameplay layers, etc. on/off that way you can reduce visual clutter that distracts the LLM from the layer you’re trying to address (ie, dont have gameplay under a UI if you’re trying to fix some UI style thing).

Taking a before and after picture of your game between agent changes is a nice way for an agent to be able to understand what changed.

…Or is it?

Screenshot 2026-10-01 at 12.15.58 PM

When you take two screenshots (Before/After) a change, the LLM, even if it’s multi-modal (ie, has vision capabilities), will likely have a VERY hard time not only understanding what the change is, but understanding if the change it made moved it closer to its own end goal.

This noise from image data is its own form of context rot: naiively throwing screenshots at models can muddy their own sense of progress, leaving both them and you confused.

A visual example can help here: Imagine you take a screenshot of the home page of this conference:

Screenshot 2026-10-01 at 12.18.48 PM

You ask the model to “Make the skeleton a pirate”. Assuming if (and with text LLMs, unlikely) this can be applied as an annotation to the image (Google Stitch does this), your image will be passed to the model provider with your tag, but then also all the other stuff you aren’t trying to address (in green below).

Screenshot 2026-10-01 at 12.20.46 PM

This means that everything in green is something akin to “context pollution”. It is data the LLM is processing as well as your requested change, but it’s not just thinking about what you requested, but is thinking about the whole image.

You need to get the LLM to think about only what needs to change. How do you judge what has changed?

Image diffing!

Screenshot 2026-10-02 at 9.32.48 AM

If you take two images and “diff” them, like you do with code changes, you can easily see what has changed. Combined with clever uses of cropping, you can have an LLM understand, with a quantitative measure, how closely some output post-change is close to your provided input/target image.

Luckily, you don’t have to do this yourself. There is a very good free, command-line image-diffing tool called odiff that does exactly this.

Screenshot 2026-10-02 at 9.35.12 AM

Given two different images, odiff finds the “difference” between the two, and can output that difference as a “diff” image:

Screenshot 2026-10-02 at 9.36.25 AM

odiff also can give you a quantitative difference value like “85% similar”, that an LLM is very good at reading, and can then use that as a stable baseline of eval across each agent turn as it strives to reduce the difference/increase the similarity.

Said differently, as you are working, these agent screenshot -> progress diff check become the basis for continual agent evaluation towards whatever your task is:

Screenshot 2026-10-02 at 9.40.29 AM

However, this obviously isn’t all. Games are much more than just their visual elements. “Progress” here breaks down into it’s own little inner loop:

Screenshot 2026-10-02 at 9.47.22 AM

This inner-loop is likely the place where an agent will spend most of its time, doing multiple turns on its own before going back to the screenshot comp/diff (assuming that your change has some visual implication).

The goal here is to be able to make every change be the minimum amount of change required for a desired outcome, and have those changes able to be quickly verified. You want an incredibly stable, “boring” baseline that can be evaluated in near-isolation to ensure that anything built on top of it doesn’t produce wide ranging technical debt (aka, spaghetti). So let’s talk more about deterministic state.

Screenshot 2026-10-02 at 9.53.45 AM

Deterministic State

The rest of the items in the above graph also deal in some part with deterministic state, but I want to talk about specific strategies and techniques for achieving it, as they will be essential for everything else.

There’s a simple question to ask to understand/know how close you are to deterministic state: how easily can you save and load an exact state in your game? Or said differently, the most important part of state reproduction is having a strategy for efficiently saving and loading your game from the start.

Saving/Loading is usually something amateur developers will put off to the end of a game, but this is a grave mistake, as many more seasoned developers will tell you. It’s easy to think of saving/loading as a “feature” that you can add at some point during a game’s development, but saving and loading, when leveraged at the VERY start of a game and programmed in conjunction with, can be a development superpower that has a near innumerable list of benefits.

Let’s talk about one strategy for doing this, and why it makes ALL of development easier.

Screenshot 2026-10-02 at 10.00.47 AM

We’re going to take a small jaunt here into CS-style programming theory. Most people that spend extensive time with object-oriented type architectures for games will find that, near the end of their project, something like the above statement “A Tree is a Dog” is true. They look at their code, and what things actually do in a game, and realize that, these two seemingly very different objects with separate OOP hierarchies are, at the end of the day, actually more or less the same kind of “thing” from the perspective of the code.

A tree is an object that has a mesh and a collider. A dog is an object that has a mesh, collider, and can move. “Movement” is not an intrinsically “dog” thing (other things in the game may move), and hence a tree and a dog are basically just compositions of components that have some game-representation. From the code’s perspective, they are effectively the same.

This can be counter-intuitive at first, as it feels wrong, but there is a chakra-unlocking insight here that, when you hold on to, starts to make game programming much easier and not a constant uphill battle against a wall of abstraction that occurs when you try to maintain a strong OOP-style object model in your game.

Thing-Driven Development

Instead, if you take the idea I’m proposing and run with it, you can assume from the very start of your game that everything is actually the same thing (maybe even use the type Thing). If you were to define Thing in code, you’d have something that looks like this:

Screenshot 2026-10-02 at 10.17.15 AM

You can see a Thing has some stat-type values on it as well as a shared idea of “liveness” from the isAlive flag. Otherwise, the “types” of thing is just an enum value, and based on that type the implementing code can take some action.

And as It turns out, AI REALLY likes this.

Screenshot 2026-10-02 at 10.18.21 AM

With this type of architecture, there is a single source of truth for your object model. If instead you have 100 classes of 100 different types of objects, an AI will need to likely understand all of those (and their relationships) to take action. This fills up your context, and makes reasoning about how to fit into that pattern messy — should I (the AI) extend some class? Morph the type of a class to better capture this new thing? Make a new class? It’s hard to say!

With a single object type, there is no ambiguity. AI knows exactly where to make changes, every time.

Not only this, but (getting back to saving/loading), having a single object type makes saving and loading FAR easier:

Screenshot 2026-10-02 at 10.20.44 AM

When you have one object type, deserializing/serializing is trivial — it’s a single type, so there is one way in/one way out. With multiple different types (and potential trees of inheritance), you will likely find yourself in weird race condition deserialization paths, needing to link up objects and trees of children in strange ways and grappling with concepts like “polymorphic deserialization”. It is well and good to know about these things and use them when required, but for games There Be Dragons here.

A game then is just a giant list of Things. Saving is saving all those things through one path, and loading is the same, but in reverse. Any casing you need to do can happen on the deserialized enum type value. It’s nice!

I’m also far from the first person to ever talk about this, so if you want to hear more about this I highly recommend some of the episodes of Wookash podcast where he talks with some of the creators of Dreams about a very similar system:

By working with a system like this, reproducing state immediately is quite easy and you skirt all the difficulties of saving and loading. There is more complexity here, and I do recommend the above talk for further reading, but the fundamental idea is the same — capture everything as a single object type. State itself is then easily captured by the same system. Nothing is stopping you from have a Turn Number field on every structure as well, and a Type that is GameManager. Make this object do literally everything. And no, it’s not memory expensive like you may think it is.

Addressable State

Once you have a system like this, it makes other parts of the game easier as well.

Screenshot 2026-10-02 at 10.31.00 AM

If you have one type of object, it’s very easy to capture changes to state, because any change in your game presumably targets the single object type. You may want to change these values directly, but with this “fat struct” approach you can very easily implement something called the “Command Pattern” for even more benefit:

Screenshot 2026-10-02 at 10.32.01 AM

The idea of the command pattern is that you capture changes to an object itself not as a loose function call, but instead as an (ideally serializable) object. These commands then get passed through some processing class, which makes the changes to the objects themselves instead of you directly. This level of indirection can again seem strange at first, but bear with me.

Imagine you have some starting state. The player makes some actions that alter state, which manifest as commands. This results in some end state, where a bug occurs.

Now lets say you want to try to reproduce this. One version of this is you trying to communicate with the player to figure out what they did and try to do the same thing in your copy of the game.

OR, you can take the starting state, and “playback” the serialized commands, which capture exactly what the player did. And notably, this doesn’t have to be you literally playing the game or writing bespoke function calls to change state: you just playback the commands. Or not even you, but an AI agent can also run them back as it continually tries to assess how its changes affect state.

Screenshot 2026-10-02 at 10.38.21 AM

Taking this a step further, you may notice that these commands also don’t actually have to be authored from the game itself. You can easily string together commands in a text editor (or authored by the AI), and then have them played back on a running instance of the game, no compiling required!

Screenshot 2026-10-02 at 10.40.32 AM

Commands give the AI (and you), a typed interface to interact with your game, effectively making it “puppet-able” and not requiring every change or attempt to work with your game need some bespoke processing logic or reflection (and then compiling those changes). AI likes this!

To linger on no-compile changes for a bit: the more you can drive your game to be able to make changes without compiling, the better. Not just as some badge of honor, but especially for agentic loops — the more it can test without needing to wait for any compile time means it’s able to act more quickly and make/validate changes in a tighter loop.

On Data Management

This dovetails nicely into one of my own pet peeves: data management. Lets go back to the fat struct example:

Screenshot 2026-10-03 at 1.15.51 PM

When I say “data”, I’m talking about the static, operational data your game uses to describe how things are. In the example above, I’d consider Type, attackDamage, walkSpeed, and boatSpeed all “data”. These are characteristics of the object that do not change. Things can modify these and work with these, and players may never see literally these numbers, but they describe the baseline shape of some Things existence in the game.

If you were making things for your game, you may write out a lot of your structs directly, setting their properties based on what you know they are. Those changes then get compiled into the game. If you want to change something’s base walk speed, you need to either make the change and recompile, or write some function binding that assigns the value and is externally callable (think console commands).

All of these options introduce churn to the AI agent. Especially in the scenarios where you’re compiling, you’re putting testing basic value changes behind a compilation.

The better way to do this is to have all your data external to your game instead of represented as code. Assigning this data is just a matter of deserializing the data, applying it to the correct objects, and done! So changing data is just a matter changing in your data source of choice, setting up some basic deserialization in your game, and combine it with object creation. Done! This also allows you (or an agent, or other team member, etc.) to be able to iterate on your game with a build! They don’t even necessarily need editor access.

Screenshot 2026-10-03 at 2.17.15 PM

For Cantata, this was our exact workflow. All the non-programmers on the team (~7 people) were given builds of the game and our custom data editor Depot. This workflow was so effective, I’m now turning Depot into a full-fledged product:

img

Team members made changes in Depot, and the game build handled deserialized changes so they would work in a loop without needing me to cut new builds. Depot is my tool of choice here, but other teams use things like Google Sheets, or their own custom tools.

AI agents can be taught to use your own tools, and then can, like other team members, test out data changes on their own without needing to rebuild the game constantly. The tighter you can make the agentic loops, the better! It’s all about trying to remove cycle bottlenecks.

Screenshot 2026-10-03 at 2.18.01 PM

This leads into another core idea. It’s a bit of a rabbit hole, so bear with me.

Standalone Simulation / Blackbox

When developing a game, either in an engine or on your own with some custom tooling, it’s usually the case that the logic of the game itself is intermingled with visual state transitions, UI calls, etc. This is by no fault of anyone, but it makes sense as a default model: some action happens, you update the UI, maybe change some visuals, etc.

However, in putting all of this together, especially in engine, you start to realize that to start trying to test anything or reproduce someone’s bug, you need to have the whole game running and doing its thing. Models have to be loaded, sounds setup, scenes loaded, etc. The simulation of your game necessitates having “the whole game”. When things start to break, it becomes hard to disambiguate between what is breaking and why: is it the simulation? The models? The scene design?

A better way to work here is that the simulation of your game sits outside of the actual operating logic of the engine. And by outside, I mean literally as its own DLL/library. The game consumes the simulation and its outcomes, but doesn’t itself “own” the simulation.

Instead, the engine communicates with the simulation through “commands”, not dissimilar from how clients and servers work in web programming.

Screenshot 2026-10-04 at 8.43.30 AM

These commands can (and should!) take the form of the previous idea of commands we introduced earlier:

Screenshot 2026-10-02 at 10.32.01 AM

As the engine pipes commands to the simulation core, the simulation responds with the updated states passed back to the engine. The engine then interprets the updated states (or diff’d state from the last received state) and acts on it.

This sounds a bit abstract, so here’s a more specific example:

Imagine something is moving in your game. That movement is likely a few different things — animation, models, sound effects, and logic around movement start, continuing, stopping, with maybe intermediate updates for things like vision as the object moves. However, what movement fundamentally “is” is something going from point A to point B in response to some player input.

The idea is that the engine sends in a movement request for some Thing (fat structs remember!), and the simulation independently decides if that’s a valid movement target (the engine can also filter for this specifically before submitting the command). The simulation then resolves the movement, and gives back to the engine an updated state object that shows the object has indeed moved. The engine can understand that the movement happened by diffing against the previous state, or other ways that are too complex to fully get into here (recording buffered commands and acting on them if the simulation accepts them, etc.). The key though is that the engine is “dumb” — it just acts on what it gets from the simulation and doesn’t question it. The simulation is the source of truth: if the simulation says something moved, the engine then moves the object, no questions asked.

This level of indirection can seem like too much abstraction, but when you have your simulation core separate from your engine, it means that anything can send commands at your core:

Screenshot 2026-10-04 at 9.18.05 AM

The biggest immediate win here is that network programming becomes FAR easier — because your game is setup to just consume states/diffs, where they are actually coming from doesn’t matter. They can come from the network, LLM, whatever!

There are even simpler use cases. Testing in game development is often a bit of a bear to tackle, but I’d argue the reason for a lot of that is because state/logic/data are often coupled so tightly that it’s very hard to test the game because it requires so much scaffolding.

However, leveraging an architecture like this allows you to easily test a game’s simulation, without needing an engine at all. You can rip through tests with pure C# projects, using standard C# tooling, and not need any engine running your code. AI likes this!

Screenshot 2026-10-07 at 9.52.56 PM

This idea broadly is called “Blackbox Game Architecture”. Versions of it have existed before, but this talk by Brian Cronin as part of Roguelike Celebration a few years ago goes into technical detail about he leveraged the technique for Monster Train:

I also talked with the team behind Solium Infernum as part of Game Data Podcast where they described a similar technique:

When you leverage something like this, it becomes a gamedev superpower. You can start really working with your game as a technical object that is abstracted from the actual player experience of it. You can run simulations, hypothesis, tests, etc., directly on the simulation itself and can skirt all the questions of state that usually plague related efforts that don’t use some architecture strategy like this.

Screenshot 2026-10-10 at 12.42.23 PM

Going back to our chart above, we’ve made out way to the near end of our flywheel. We set some deterministic input parameters, have ways to modify that state in structured ways that can avoid compilation, and can then verify our own changes in a vacuum.

Impact Assessment

However, how do we actually know those changes then affect the actual game how we want? This is the idea of “impact assessment”.

Screenshot 2026-10-10 at 12.46.40 PM

I’m going to focus on a somewhat narrow set of options here, but there are more tools a studio could deploy in this arena that are more specific to their own game. Things like tests fall into general areas here, but also running things like fixed gameplay scenarios to figure out balance impact, etc. These all matter, but are game specific and as such hard to directly extract in the scope of this post.

However, one thing that all games share is a concern for performance. Traditionally, performance profiling has been a relatively manual effort, and required developers to work with profiling tools, with ones built into editors like Unity/Unreal or through IDE tooling like dotMemory:

Screenshot 2026-10-10 at 12.49.36 PM

These tools are designed for human consumption — they expect you to dig into the call stacks and graphs and such to find whatever bottlenecks you are looking for. Perhaps unsurprisingly then, it turns out AI doesn’t really like using tools like this: they aren’t legible to the agent (though worth saying Unity is doing a lot of work here to make the profiler better able to be read by agents!).

What AI really likes it to work with text (and lots of it), so profiling tools that are able to dump out raw captures as text REALLY help to accelerate AI iteration. There are a few options here, but the one I’ve grown to like the most is the (free!) tool samply:

Screenshot 2026-10-10 at 12.53.50 PM

Samply can be hooked up to easily run against your own project, and dump capture output to console. An AI agent knows how to read the samply source and docs to help it figure out how to eval its own changes here, so the capture and iterate loop can be performed effectively autonomously. AI likes this!

Bringing It Home

As we combine all these tools and technique together, something like this comes into view (and this is just one version!):

Screenshot 2026-10-10 at 12.55.44 PM

With the data-oriented, binary-isolated, no-compile-needed version of development I’m sketching here, an agentic turn can run through this WHOLE loop in seconds. It makes iteration significantly faster than a baseline naiive approach, and at every step helps the AI to better understand your game and what you’re trying to do. Because the whole loop is efficient and fast, it can be run against every change, and not saved for only when it “matters”.

Reframing this a big, you can see what a game-driven harness looks like:

Screenshot 2026-10-10 at 1.03.19 PM

Spoilers: it’s your game! Any game is capable of all of this, meaning any game can easily be its own harness. Or, as we’ve said at the start:

Screenshot 2026-10-10 at 1.04.16 PM

Thanks for reading!

Postscript

It’s been interesting to write this after having presented it. I stand by a lot of what I’ve said, but am in the process of shipping a project where I’ve also used none of this. I think the scale I’m targeting here is really larger projects. The thing I’m shipping is very small, so I really didn’t need to do much for it in terms of any harness stuff.

However, as I pick up work on a larger game that I’m cooking, a lot of this is definitely relevant and I’m very thankful for all these tools.

If you apply strategies like the above to your own games, I’d love to hear about your experience and what worked/didn’t work! I’m really thinking about a lot in this space (obviously) as I continue to make games and tools, so am excited to hear what other people are doing.

Again, thanks for reading and talk next time!

---

High valuations and debt put sector in danger, while fund also warns on government borrowing and cyber-attacks

The IMF underlined the interconnected nature of big AI companies, and the high levels of borrowing being undertaken to fund investment in the sector. Photograph: Aly Song/Reuters

The threat of an AI share price crash rippling out across global markets is putting world financial stability at risk, the International Monetary fund has warned.

In its twice-yearly Global Financial Stability Report, the IMF highlighted the sky-high valuations for AI companies along with their increasing debt pile as one reason that risks in the system are “elevated”.

“The consequences of an AI correction could be global,” it warned. Aside from the US, Asian markets would be most exposed, and the UK and euro area potentially more insulated – though investors with US holdings would be hit.

Athanasios Vamvakidis, the deputy director of the IMF’s monetary and capital department, launching the report, said: “The exposure of the rest of the world to US assets, particularly AI, is the highest it has ever been. So this is supporting the global economy through wealth effects today; but if we get a market correction it could have broad implications.”

An AI crash was one of three “salient risks” to stability identified by the IMF, alongside rising government borrowing costs and the threat of a big cyber-attack.

It called this trio of factors “plausible near-term catalysts for a sharp tightening of financial conditions and market turmoil”.

The IMF’s analysis underlined the interconnected nature of big AI companies, and the high levels of borrowing being undertaken to fund investment in the sector.

“Weaker or less durable investment and profitability in AI could trigger a correction in AI-related asset prices, exacerbated by rising leverage, concentrated exposures, and circular financing arrangements,” it said.

Such a reassessment would then “sharply reduce investment, trigger equity market corrections, and tighten financial conditions, with global spillovers”.

The “magnificent seven” big tech stocks – Alphabet, Amazon, Apple, Meta, Microsoft, Nvidia and Tesla – account for more than 35% of the S&P 500 share index in the US, up from 12% a decade ago, and their total market capitalisation has increased by more than 50% in the past two years.

Yet the IMF warned of “growing evidence” that the successful rollout of AI “may not require investment on the massive scale being undertaken by ‘hyperscaler’ firms”, and “potential economic gains may not be as large as expected”.

The hyperscalers are the companies building the underlying infrastructure for the AI rollout, including many vast datacentres. They include Amazon Web Services, Google, Meta and Oracle.

Shares in semiconductor companies fell on Tuesday after the boss of Broadcom compared many AI investors to “casino” gamblers. Reports that the Chinese memory chip maker CXMT was making good progress on a new chip architecture also hit South Korean tech companies.

The IMF also highlighted the growing leverage, or borrowing, that underpins the current boom and could amplify the effects of a crash.

In particular, it identified soaring debts contracted by the companies themselves; hedge fund investment in the sector; and retail investors borrowing to speculate in AI stocks.

In the event of an AI-led market downturn “these growing sources of leverage heighten the potential for forced selling and surges in equity volatility”, it said.

It also pointed to the prevalence of “circular financing” deals, tying stronger AI companies to weaker partners in the same sector, and potentially exacerbating the impact of a share price correction.

It identified $300bn (£227bn) worth of transactions between hyperscalers and “weaker AI firms” in just the past three years, supplemented by $650bn in debt, in exchange for $1.4tn in future financial commitments.

In London, the chief executive of the UK’s Financial Conduct Authority, Nikhil Rathi, urged every small business across the financial sector to take out insurance to protect themselves against AI-related cybersecurity threats.

He told MPs on the Commons Treasury committee that not all companies would have the resources to pay for access to “frontier” AI models such as Anthropic’s Mythos, which has been released on a restricted basis after it was said to be rapidly identifying gaps in government and corporate cybersecurity systems.

“One message I’d give to every small business: you should consider making sure you are insured,” Rathi said.