Posts on John Wang

How X's ranking algorithm works

Fri, 25 Sep 2026 00:00:00 +0000

There’s a ton of folk wisdom on X about how to go viral. A few examples you’ll see over and over:

Put links in the first reply instead of the post. " (Sprout Social).
Replies are king. “A reply on your tweet is worth 13.5x a like,” and if you reply back, “a two-way conversation [is] worth 150x more than a single like” (OpenTweet).
Pay for Premium. Premium gets “roughly 4x for in-network reach to your own followers and about 2x for out-of-network reach to non-followers” (SocialRails).

But it’s very hard to tell what’s real, and most of it traces back to code Twitter released in 2023. But X now publishes the production code for its “For You” feed at xai-org/x-algorithm (including the ranking weights!) and they update it about every four weeks.

How the ranker works

The basic trick of the ranking algorithm is to use something cheap to narrow the available options, then save the expensive model for a few thousand posts.

Source: xai-org/x-algorithm, September 2026 release.

Retrieval narrows ~10 million posts to ~2,800. Most come from people you follow or from an embedding search for posts close to your recent history.
A transformer predicts what you’ll do. Phoenix (whose code started as a port of Grok-1) reads your last ~1,000 actions and predicts the odds you’ll like, reply, share, mute, or report each post.
A weighted sum becomes the score. Posts from people you don’t follow get multiplied by 0.75, and each extra post from the same author counts for less.

A few implementation details I found fascinating:

The ranker never reads your words. Its inputs are post IDs, author IDs, and actions. Your text only gets in through a semantic ID (basically think of it like a small embedding): six numbers from 0 to 255. The first number picks one of 256 broad neighborhoods, and each number after that narrows it down further. Posts on the same topic end up sharing the first few numbers.
An LLM also writes a report on every post. A Gemma-based initial filter (called, hilariously, the “banger initial screen”) reads each post and outputs a description, tags, topic categories, yes/no flags like high quality, spam, and NSFW, and a “slop score.”
The weights are in param.rs. A Copy-link share is incredibly valuable and worth a multiplier of 20, a reply is worth 5 (not 13.5 as past articles noted), quote 5, DM share 5, repost 1, and like 0.5. Getting reported is −234 and muting is −58.8 (so incredibly bad). Though note that these are based on probabilities of actions, not actual actions themselves.
A lot of the folk wisdom isn’t in the code. There’s no weight for the author replying back, and I couldn’t find a Premium multiplier anywhere in the scoring code.
Mutual follows got a big boost this summer. Replies on original posts from mutual follows now count for 20 instead of 5 (X even published the whole A/B test history, which is pretty cool to see).

What this means for your posts

So what should you actually do?

Write things people send around. A copy-link share carries 40 times the weight of a like, which makes it incredibly valuable. People generally tend to forward useful things like a surprising number, a clear chart, or an explanation that breaks something down simply.
Start conversations. Replies and quotes each carry 10 times the weight of a like. Build mutual follows with people in your field, since their replies count four times as much.
Stay on topic. To reach people who don’t follow you, your post has to land near their interests in embedding space. A post clearly about one thing gets a clear semantic ID.
Don’t rage bait. Mutes and reports are by far the heaviest negative weights, so it’s not really in your interest to post baity content.
Post less, but better. Your second post in someone’s feed counts at about 0.6x, and your third about 0.4x.
Everything expires in 48 hours. The ranker stops considering older posts, so there’s definitely a timing element of a post and might make weekend vs weekday timing important (though how time plays a factor depends on viewing and posting distributions, which aren’t available in the code itself).
Links are fine now. X says the link penalty ended in mid-2025, and the code agrees. Just make sure the post stands on its own.

There are still some things we don’t know, though. The trained model isn’t public and every score is personalized to the viewer, so you can’t compute ahead of time how a post will do, but it is pretty intersting to get this level of transparency on the algorithm.

Megafauna extinction and startups

Wed, 23 Sep 2026 00:00:00 +0000

I was recently in Alaska and saw a massive moose, probably the biggest animal I’d ever seen in person. It got me down a rabbit hole as to why moose are so big, which eventually led me into a fascinating story of evolution and extinction that seems particularly relevant to startups in the age of LLMs.

Why being big wins

There seem to be 4 main reasons why moose are so large:

Surface area to volume ratio for cold winters. Moose live in very cold regions that have particularly harsh winters. Because of that, the ability to conserve body heat is very important. Surface area to volume ratio works in favor of large bodies here: surface area is generally a square of your dimensions and volume is a cube, so as your dimensions grow, the amount of surface area for heat to escape shrinks compared to your overall mass. This means that larger bodied animals are more adept at retaining heat (the same reasoning works the other way for why you want smaller bodies for long distance runners to allow heat to escape more easily).
Kleiber’s Law $BMR \propto M^{0.75}$. Swiss biologist Max Kleiber found in the 1930s that the basal metabolic rate (the energy expenditure of an animal) generally tends to scale to the 3/4 power of an animal’s mass. This means that if an animal gets 100 times larger, then the amount of calories the animal needs to consume only increases by 32 times. So larger animals tend to be more efficient. If there’s enough food available, then a larger animal will tend to use calories more effectively than a smaller one.
Size makes predation much harder. Adult moose are so big that they have almost no natural predators. Even those predators like wolves or bears who do attack them very much prefer to attack babies or injured / old moose. Adult bull moose are very large and have very strong, long legs that can kill a wolf with a good strike, so bears/wolves tend to rely on surprise and prey on weakened moose.
Energy reserves. The larger you are, the more energy you can carry on your body in the form of fat. This is particularly useful for climates moose live in, which swing wildly from abundance in the spring and summer months to barrenness in the winter months. It’s also generally helpful for making you more robust to environmental changes.

Interestingly, reasons 2-4 apply to most animals and aren’t specific to moose or their arctic habitat. That leads to the next observation. Instead of asking why moose are so large, the opposite question might be more useful: why are there so few large animals?

Megafauna and mega-extinction

In fact, there used to be a lot more throughout history, and scientists even had a name for them: megafauna. There’s even a name for the pattern, Cope’s rule, which says that lineages tend to get larger over time.

Irish elk: a deer the size of a moose with antlers spanning 12 feet.
Woolly mammoth: 6 tons, roughly the size of an African elephant.
Giant ground sloth (Megatherium): a 4-ton sloth that stood taller than an elephant when it reared up.

However, most of them suddenly went extinct in the last 50,000 years. Of the 57 species of herbivore over 1,000 kg that were alive then, only 11 survive today. In North America, the average land mammal shrank by more than 10x. We still have some megafauna (elephants, giraffes, moose), but most animals are now much smaller.

Though there were decades of debate about what caused these extinctions (particularly whether climate change had an impact), scientists now generally accept that humans were the cause. These animals had survived more than twenty glacial cycles over the previous two million years, and the last one was only different in that humans had arrived on the scene. A 2023 study reconstructed the population histories of 139 living megafauna species from their genomes and found that 91% of them started declining between 32,000 and 76,000 years ago, on every continent, and almost exactly tracking the spread of humans. Total megafauna biomass on Earth fell by 92%. The only place the giants held on was Africa, where they’d had a couple million years to get used to us.

Megafauna are perfect for humans: they’re huge, and you only need to hunt one to have enough calories to survive for a very long time. The problem though is that you don’t need a huge amount of hunting in order to kill off a megafauna species, especially if the species reproduces really slowly.

Going extinct, but gradually

So how did humans kill off so many species of megafauna, especially given the relatively small human populations at the time?

Well, when you control for body size, reproductive rate has a massive impact on potential extinction probability. Species producing one or fewer offspring per female per year had more than 50% odds of dying out, regardless of size. You just need:

$$r_{birth} < r_{death} + r_{hunting}$$

If a species is held slightly below replacement for a long time, you get extinction over time.

For a fast breeder (think rabbits or mice), $r_{birth}$ is huge and it takes an enormous amount of hunting to flip the inequality. For a mammoth, gestation was about 22 months, females didn’t mature until 10 to 12, and after that they had one calf every 3 to 6 years. This means a few percent of extra mortality a year is all it takes for extinction. You actually don’t have to hunt a species to zero.

When Polynesians arrived in New Zealand, the moa (a 500-pound flightless bird with no natural predators) was gone within about a century. The human population at the time was under 2,000 people, roughly one person per 100 square kilometers. There wasn’t any industrial hunting or big-game culture, but there was just enough persistent drag on a species that couldn’t breed quickly.

The interesting thing is that some of these species lived for thousands of years while $r_{birth} < r_{death} + r_{hunting}$. For example, though mainland mammoths were killed off by about 10,000 years ago, there still existed a small group of mammoths that survived on Wrangel Island in the Arctic Ocean until about 4,000 years ago. There were only a few hundred of them living for millennia. We have parallel examples of this with Caribbean ground sloths, where island populations lasted another 4,000 to 6,000 years after the mainland animals were gone, and Steller’s sea cow, which vanished across most of the North Pacific and then hung on as a Commander Islands remnant until the last animals were killed in 1768.

There’s a distinction here between dead and extinct. A species is functionally dead when it’s held below replacement with no way back (like the mammoths on Wrangel Island), even if the last individual doesn’t die for thousands of years.

What thrived afterwards

As the megafauna died off, it opened up the world for other species to thrive. As Aristotle said, “nature abhors a vacuum” and there was plenty of opportunity as changes in the environment allowed for new winners, typically employing one of three strategies:

Strategy: Generalist (Rats, Pigs)

The first and most common strategy was to be a generalist. Species employing this strategy would eat whatever is around, live wherever there’s shelter, and breed faster than anything could kill them.

Rats are the clearest case. They were perfectly set up to take advantage of human proliferation, as humans made much more of the habitat that rats love. They’re more than happy living in ships, sewers, grain stores, or apartment walls. As humans built up cities, rats found an environment that was incredibly hospitable because of their ability to eat human scraps.

Another key element of the generalist strategy is fast reproduction. Rats have a gestation period of about three weeks and a female can produce dozens of young a year. This turnover rate means you can hunt rats continuously and still fail to push them below replacement (just look at what happened to New York Rat Czar).

Strategy: Adapt (Coyotes, Raccoons, Crows)

The second winning strategy was rarer, because relatively few species were able to pull it off. The strategy was adaptation: as the world changed, these animals changed with it by adjusting their diets, habitats, and behaviors.

Coyotes are the most well-known example of this. Before Europeans remade North America, they were mostly a western prairie animal. As wolves disappeared and forests were cleared, coyotes adapted to be able to live in close proximity to cities. Their social structure became flexible, as they can either hunt alone or in pairs when prey is small, or form loose family groups when they need to take on larger animals. In cities, they flip their schedule and go mostly nocturnal to avoid people and move quickly through developed blocks at night. They live in the leftover green areas like parks, golf courses, and railroad corridors.

Their diet also changed. They prefer rodents and rabbits (things you would find on the prairie), but switch to fruit, pet food, and garbage when rodents aren’t available. They changed their hunting and feeding patterns to take advantage of the human food in cities. This flexibility means they’re now everywhere and have migrated to every US state except Hawaii.

Strategy: Partner (Dogs, Cows, Chickens, Sheep)

The final winning strategy was to partner, basically “if you can’t beat them, join them.” Species that chose this strategy stopped competing with humans and survived by becoming useful to us.

Many animals hit upon this strategy, but dogs are famously good at it. They were originally wolves, but became hunting partners and companions instead of rivals. They’re now everywhere and there are literally a billion of them. The wolves that didn’t take the deal still exist, but they’re far less numerous (scientists estimate there are around 200-250k gray wolves in the world).

This strategy comes with tradeoffs though: dogs are no longer fierce predators, and while there are billions of cows and chickens, their existence isn’t particularly happy. Also, most of them can’t survive outside the human farming system. Partnership is a good way to thrive, but it’s also how you lose control of your future.

Megafauna and startups

I’m particularly fascinated by the megafauna extinction because I think you can compare the introduction of humans in evolutionary history to the arrival of LLMs in the tech world.

There are quite a lot of similarities:

Before LLMs, it made sense to be as big as possible. Hiring engineers was how you shipped more, and also how you kept those engineers from becoming a competitor. Between 2019 and 2022, Amazon’s headcount rose 93%, Meta’s 92%, Alphabet’s 60%, and Microsoft’s 53%. Bigger teams were less efficient per person, but they were still the optimal choice for a climate where ecommerce and internet spend was increasing dramatically. The focus on hiring was a similar optimization to what the megafauna made as bigger generally means you can accomplish more and dominate in the environment you’re placed.
The arrival of LLMs is similar to the arrival of humans: there was a massive shock to the system that caused the landscape to change. Coding and many auxiliary functions which previously required armies of people got much cheaper and more efficient. Leverage from LLMs has made size-based defenses much less useful. In fact, the size of your company, which was once an asset, has now become a hindrance. Most AI native companies are far more efficient on a revenue per person basis and skew much smaller (see figure below).
Incumbents didn’t immediately recognize that AI native companies were predators. Similar to dodos and the moa, they had never seen this kind of competitor before and they didn’t register as a threat. They were slowly losing the next dollar, but mainly focused on keeping their existing customer base. In 2025, the head of LexisNexis North America said he didn’t see the new legal AI startups as a serious threat. By then Harvey had reached $100 million a year and was in 42% of the AmLaw 100.

Zombie megafauna

Some of the megafauna are already visibly dying, but relatively few of them are extinct. Yes, there are examples like Chegg (its stock fell 40% after their CEO said ChatGPT was hurting new signups) and Stack Overflow (new questions fell to about 1,100 in August 2026, from a peak of more than 200,000 in a month). But in general, like in megafauna extinction, much of the technology ecosystem extinction is playing out more gradually and most incumbents are attempting to adapt.

Nearly every company now has an AI strategy, an AI product, and an executive whose job is to make the company AI-native. So the interesting question is actually whether incumbents will adapt fast enough. A company’s population is its customers, and it shrinks for the same reason a species does:

$$r_{new} < r_{churn} + r_{competitor}$$

An incumbent can ship a perfectly good AI product and still lose if competitors are taking customers more quickly. A few things from the megafauna explain how that happens:

Predators adapt quickly. Megafauna could adapt, but their slow reproduction rate hindered them in comparison to faster reproducers. Humans adapted quickly by using culture and by spreading knowledge through spoken word between generations. Other winners reproduced on much faster cycles (e.g. rats every few weeks). Similarly, an incumbent’s AI strategy moving through annual planning and multiple layers of red tape can be outmaneuvered by a twenty-person startup that ships every week.
Predators take the calves. Bears don’t go after healthy adult moose, they go after the young, the old, and the sick. AI-native startups similarly won’t be ripping out existing contracts to start. They generally win the next customer, like Harvey did against LexisNexis. The existing customer base might look healthy, but a herd without calves is dying. And once the new species gets established, it’s very hard to dislodge.
Decline looks normal from the inside. A population shrinking 1% a year takes about 1,400 years to go from a million to zero. That’s instant from a geological standpoint, but basically invisible to anyone who’s living through it. Losing a few percentage points of growth each quarter doesn’t feel alarming for any particular quarter, but taken in aggregate can be catastrophic.
Most megafauna shrink. Plenty of megafauna species survived in much smaller populations and ranges (lions went from southern Europe, the Middle East, and most of Africa to scattered African populations), and some physically shrank (modern bison are noticeably smaller than their Ice Age ancestors). The likely outcome for most incumbents is to become a smaller company in a smaller niche, while its growth goes to someone new.

Winning strategies in the AI era

The most interesting part to me though is who’s thriving. Each winning strategy since the LLM boom has parallels with evolutionary winning strategies. Generalists eat everything, adapters change what they eat, partners attach to the frontier labs, and new companies are born growing fast. Though, similar to animals, each strategy comes with its own tradeoffs.

Strategy: Generalist (TSMC, Cloudflare, Stripe, OpenRouter)

Rats didn’t win by being clever, they won by eating whatever humans left behind and living in whatever humans built. The generalists of the AI era do the same: they don’t need to pick which lab wins, because they thrive whenever more tokens flow through the system.

TSMC fabs Nvidia’s GPUs, but also Google’s TPUs and Amazon’s Trainium chips, so they eat whenever the system increases total token spend. Cloudflare and Stripe are the backbone that handles the traffic and the payments. Every new AI app needs to sit behind a network and charge its customers, and every AI crawler and agent hitting the web runs through Cloudflare. OpenRouter routes requests to hundreds of models from nearly every lab. It doesn’t care which model wins, only that people keep sending tokens.

The tradeoff is that generalists tend to grow with the tide, and shrink with it too when it goes the other direction.

Strategy: Adapt (Cognition, Intercom, Baseten, Handshake)

Coyotes kept what made them good (hunting skill, flexible packs) and changed their diet and schedule. The companies that have adapted well follow the same pattern of keeping a key asset and changing what they eat.

Intercom kept its customers and support distribution, but rebuilt the company around their Fin AI agent. They started charging per resolution instead of per seat, cannibalizing their own pricing before someone else did it for them. They recently sold to Salesforce for $3.6 billion.
Handshake had one of the biggest adaptations, going from a college recruiting network to a frontier lab data provider. They took their network of students and PhDs, but realized they could use that same network to train frontier models (and that this was much more lucrative). They became one of the first data companies to reach $1B in revenue, against a huge amount of internal resistance.
Baseten started by doing ML infrastructure, but changed its customer from data scientists building apps to LLM inference. They’re now one of the fastest growing inference providers.

Strategy: Partner (Scale AI, Surge AI, Mercor)

These companies stopped competing with the frontier labs and made themselves useful to them instead by supplying the huge amounts of expert human data that labs need. By sheer mass, partnering is the most successful strategy there is: livestock now make up about 60% of mammal biomass on Earth, while wild mammals are about 4%.

Data companies like Mercor, Surge, and Scale are making billions in revenue, but their growth rate isn’t independent. Chickens breed exactly as fast as humans want them to, and data vendors grow exactly as fast as the labs’ data budgets.

Another interesting parallel is seeing different sub-strategies. For example, dogs are valued for judgment and companionship, while chickens are interchangeable. This is similar to why Surge, reportedly selling expert judgment and highly curated data, was able to pull ahead of Scale, which started as a labeling body shop.

Strategy: Start fresh (Cursor, Cognition, Harvey, ElevenLabs, Higgsfield)

The last strategy is one that didn’t have time to develop after the megafauna extinction (we’re too early in evolutionary time), but has shown up after other extinctions. Survivors of mass extinction events go through adaptive radiation and rapidly diversify into all the niches that just opened up. After the dinosaurs died, mammals went from small nocturnal animals to whales, bats, and horses.

Similarly, we’re seeing an explosion of new startups in niches that didn’t even exist a few years ago. AI code editors (Cursor), software factories (Cognition), legal AI (Harvey), voice AI (ElevenLabs), video AI (Higgsfield), and many more fields have suddenly opened up. Starting fresh has advantages in that you can shape yourself specifically to the new environment and there’s no mass to shed or old business to defend.

That said, adaptive radiation is also incredibly wasteful. It produces a burst of new forms and most of them die out. Jasper was one of the first AI copywriting companies, and had raised $125 million at a $1.5 billion valuation, when ChatGPT ate its niche. Tome did the same thing with AI presentations. They had 20 million users, then completely pivoted and abandoned their product once Anthropic and OpenAI moved in.

Which animal are you?

A huge environmental change just opened up a lot of niches, so whether you’re an existing company or starting something new, there’s a ton of opportunity. But remember that adaptive radiation is wasteful and most new species won’t make it.

So, some interesting questions to ponder:

What niche just opened? The best opportunities are things that weren’t possible (or weren’t economical) a couple of years ago. If the business could have been built in 2019, someone probably already occupies the niche.
How fast do you reproduce? How long does it take to go from idea to a high quality shipped product, and then to customers? If it’s measured in weeks, you’re built for this environment. If it’s still measured in quarters, you should take a look in the mirror.
Whose calves are you taking, and who’s taking yours? New companies don’t have to rip out an incumbent’s existing contracts. They can go after the next customer and the fringes of what incumbents make money from. If you’re the incumbent, is there a company winning the customers you would have won two years ago?
Are you a dog or a chicken? Almost every AI company depends on the frontier labs to some degree. That’s fine, as long as you add something meaningful that the labs can’t easily produce themselves.

Which brings me back to the moose I saw in Alaska. Moose aren’t the biggest animals that ever lived, or the fastest, or the strongest. But they made it through because they just happened to be built for the world that came next.

The moose got lucky, but you get to choose.

The engineering behind the US Strategic Petroleum Reserve

Tue, 15 Sep 2026 00:00:00 +0000

One of the most fascinating things I’ve learned about recently is the engineering behind the US Strategic Petroleum Reserve. Here are the key requirements it’s designed to meet:

Store hundreds of millions of barrels of crude oil for long periods of time to respond to disruptions in petroleum supplies.
Keep the oil secure against attacks by our adversaries. This is an especially hard challenge because petroleum has this tendency to light on fire, so a huge concentration of it is especially difficult to keep safe.
Release oil quickly so it can reach the market during a supply disruption.
Keep maintenance costs low and last for decades.

The actual solution, like many great engineering solutions, is incredibly elegant and simple. But before we talk about it, let’s start with how you might go about solving this:

The naive solution: External floating roof tanks

Enbridge tank farm, Cushing, Oklahoma, April 2010. Photo: roy.luck, CC BY 2.0.

Looking at the requirements, the first thing most people would probably think to do is to just take what we do commercially for storing petroleum and scale it up. External floating roof tanks (EFRTs) are the common solution for storing petroleum. Most tanks are confined to about 50 feet tall and 300 feet in diameter – larger than that and you start to have engineering problems with the foundation and drainage systems. This gives a volume of $V = \pi (150 \mathrm{ft})^2(50 \mathrm{ft})$, or $3{,}532{,}500 \mathrm{ft}^3$, equivalent to about 630,000 barrels of oil.

To hold 714 million barrels of oil (the full capacity of the Strategic Petroleum Reserve), you’d need about 1,130 of these tanks. If you use the standard capacity of the largest commercial petroleum farms (e.g., in Cushing, Oklahoma), you need about 45,000 acres to store these tanks. That’s basically the size of Washington, D.C., which means you’d need to acquire a lot of land.

However, the biggest downside to using tanks is that they’re incredibly vulnerable to attack. Damage can cause spills and fires, and there’s a particular weak point at the seal between a floating roof and the tank shell. Lightning-caused fires have been documented in the seal space of open floating-roof tanks, so a deliberate ignition source (shrapnel, incendiary) could be particularly bad.

Putting tanks underground

Next up, one might think about putting the petroleum underground. The Navy actually did this at the Red Hill Facility near Pearl Harbor. Built in 1943, it housed 20 enormous steel-lined concrete tanks inside excavated volcanic rock. Each tank was about 100 feet across and 250 feet tall, making it comparable in volume to a large EFRT. Altogether, the facility housed 6 million barrels of fuel. The surrounding rock provided protection from aerial attack, which was a major reason for building the facility. But this was a substantial construction project, and thousands of workers had to excavate the tunnels, install steel liners, and pour concrete. The original construction cost was $42.2 million (~$820M in 2026 dollars).

Also, groundwater protection became a major challenge. A tank released about 27,000 gallons of fuel in 2014. Separate releases in 2021 contaminated the Navy’s drinking-water system, causing the Navy to defuel and permanently close the facility.

There’s also the question of scale. To get to 714 million barrels, you’d need roughly 119 Red Hill-sized facilities’ worth of capacity and enough space to actually put these tanks in the ground. It would be an absolutely enormous construction project that would cost hundreds of billions of dollars (which, even for the government, is extremely expensive).

The actual solution: Salt caverns

So how did the US solve this? The crux was using salt domes at four sites in Texas and Louisiana along the Gulf of Mexico. The US created massive caverns underground in these salt domes that hold about 10 million barrels each (more than the entire Red Hill facility). The DOE currently lists 60 caverns with a combined authorized storage capacity of about 714 million barrels.

A few properties make this work:

Cylindrical caverns are excavated using water. Engineers drill into a salt dome and inject fresh water. The salt dissolves in the water, and then pumps are used to remove the resulting brine, leaving a cavern that can be used to store petroleum.
Salt contains the oil and helps seal small fractures. The rock salt surrounding the SPR’s caverns has extremely low permeability, meaning fluids have very little ability to pass through it. It also doesn’t react with petroleum. Under enormous pressures underground, salt also slowly deforms, which helps close small fractures. The salt itself can therefore contain the oil without a steel-and-concrete tank lining the cavern.
Oil floats on water, which means pumping water into the bottom of the cavern pushes the oil out. As fresh water is pumped into the bottom of the cavern, the oil gets displaced upwards into a delivery system.
As a bonus, the location helps get oil to market. The Gulf Coast puts the reserve near refineries, pipelines, and marine terminals, which is particularly useful when the whole point is to deliver oil during a supply disruption.

This storage solution is relatively inexpensive. DOE’s historical capital-cost estimate is about [$3.50 per barrel](https://www.energy.gov/hgeo/opr/spr-faqs) of cavern storage capacity, compared with $15-$18 for aboveground tanks. Storing the oil deep underground also helps protect it from aerial attack.

There are still tradeoffs, though. Creating caverns requires a water supply and a way to dispose of the brine. And fresh water introduced during withdrawals dissolves additional salt, gradually enlarging the caverns. That limits repeated cycling and makes cavern monitoring and maintenance quite important. The wells, pumps, and pipelines also need continued upkeep, so frequent withdrawals can degrade the infrastructure.

Why are there suddenly so many gambling companies?

Tue, 15 Sep 2026 00:00:00 +0000

Source: American Gaming Association annual reports and revenue tracker; data and methodology. Handle is the total amount wagered, including money that gets bet again after a win. It is not operator revenue or bettors’ net losses. The AGA sportsbook series does not include Kalshi or Polymarket.

It feels like gambling companies are suddenly everywhere. DraftKings and FanDuel are part of watching sports. Kalshi and Polymarket let you put money behind opinions about elections, economic releases, and games. What used to feel like a fairly separate activity now shows up in the same places where you follow the news or check your investments.

The graph gives some sense of how much has changed. Annual wagers through the sportsbooks tracked by the AGA grew roughly 25 times between 2018 and 2025. And that’s before adding prediction markets, which operate through a different structure and aren’t included in those numbers.

My read is that we’re watching two overlapping expansions. First, states opened up sports betting. Then prediction markets started testing how much of the same activity could happen through financial exchanges. In both cases, software made it much easier to turn permission to operate into a product that millions of people could use.

First, the law changed

The biggest reason for the timing is surprisingly straightforward. In May 2018, the Supreme Court struck down the Professional and Amateur Sports Protection Act in Murphy v. NCAA. That federal law had largely prevented states from authorizing sports betting. The decision let states make their own choices; it didn’t itself legalize sports betting everywhere.

That created a succession of new markets. Each state that allowed online wagering gave companies another group of customers to compete for. The AGA credits new markets and mobile launches in places including New York, Louisiana, and Maryland with helping drive 2022’s expansion. Five more states launched legal sports betting in 2023.

This is important when reading the graph. Some growth is people betting more. Some is people betting legally instead of through an offshore site or a bookie. Some is the measured market expanding as more states participate. The chart alone can’t tell us how much comes from each.

For a company, though, all three can create an opportunity. You don’t need to invent people’s interest in betting on football. You need to become the app they open once it’s available where they live.

Phones changed the size of the opportunity

Imagine two versions of the same business. In one, a customer travels to a casino to place a bet. In the other, they open an app during a commercial break.

The second version can become a much more frequent habit. It also gives the company more opportunities to offer another bet: before a game, during it, or on an individual player’s performance. The scarce resource becomes the customer’s attention.

That helps explain why the advertising is so visible. DraftKings reported roughly 1.26 billion dollars in sales and marketing expense in 2024, across its business. That’s a substantial amount of money spent making sure people recognize and return to an app.

Sports organizations became distribution partners, too. The NBA named DraftKings and FanDuel co-official sports betting partners in 2021, with rights to league and team branding and integrations across NBA platforms. Betting could now appear inside the experience of being a fan.

The business logic is easy to understand. If a customer keeps coming back, acquiring that customer can be worth a lot. But the enormous wagering total isn’t the amount companies get to keep. In 2025, the AGA reported 166.94 billion dollars in handle and 16.96 billion dollars in sportsbook revenue—about 10% of the amount wagered, before operating expenses and taxes. It also reported 3.71 billion dollars in state sportsbook taxes. Customers, operators, sports partners, and state governments all became participants in a much larger business.

Prediction markets opened another route

Kalshi and Polymarket look similar to sportsbooks from a user’s perspective: put money behind an outcome, and get paid if you’re right. But the structure matters.

A conventional sportsbook posts odds and takes bets. An exchange matches buyers and sellers of contracts. A simple event contract might pay one dollar if a specified event happens and zero if it doesn’t. Buy it for 60 cents and hold it to settlement, and you either make 40 cents or lose 60 cents, before fees. The price can be read as a rough market-implied probability, although fees, liquidity, and who is trading can distort it.

Kalshi received CFTC designation as a contract market in 2020. The CFTC is the federal regulator for derivatives markets. Polymarket took a different path: in July 2025 it announced the 112-million-dollar acquisition of QCEX, a US-regulated exchange and clearinghouse, to support its return to the US. Its international platform and US business shouldn’t be treated as interchangeable when discussing regulation or trading volumes.

The commercial attraction is obvious. If event contracts can operate under federal derivatives rules, companies have a potential route to customers beyond the state-by-state sportsbook system. That possibility is a powerful incentive to enter the market.

But the boundary remains contested. In April 2026, the CFTC sued Arizona, Connecticut, and Illinois, asserting its exclusive jurisdiction over prediction markets. States have argued that sports contracts are gambling subject to their laws. Courts have not produced a uniform answer: in August, an appeals panel declined to let Kalshi resume sports and election trading in Nevada while litigation continued.

So this isn’t simply a story about an unregulated industry. It’s a fight over which regulatory framework applies, and what products that framework permits. That fight is still underway as of September 2026.

More brands can mean more ways into the same market

There’s another reason it feels like the number of betting companies has exploded: an existing financial app can add prediction markets without building an exchange itself.

Robinhood launched its prediction markets hub in March 2025, initially offering contracts through Kalshi. The launch included both economic and basketball outcomes. In May 2026, Interactive Brokers announced one interface connecting Kalshi, CME Group, and ForecastEx.

That means counting apps can overstate the number of independent markets underneath them. Several familiar brands can distribute access to the same exchange. For the exchange, distribution brings traders. For the distributor, it adds something else an existing customer can do with an existing account.

Prediction markets also have a useful distribution mechanism of their own: the price is content. A probability about an election can be shared in an article or group chat. Someone who would never browse a sportsbook can encounter a market while reading the news.

Forecasting and gambling can coexist

I think the appeal of prediction markets is real. People have opinions about uncertain events, and putting money behind a claim can make it more informative than a confident social media post. A well-designed market can aggregate information or let someone offset a risk they already face.

But those uses don’t tell us what drives the commercial business. Sports provide frequent events, clear results, and an existing audience. The AGA estimated in September 2026 that sports represented about 80% of Kalshi’s volume. That’s an industry association’s estimate, from an organization representing competitors and advocating against these products. Still, it illustrates why the two industries are colliding.

The same interface can serve someone hedging an economic risk and someone looking for another wager. Calling it a prediction market doesn’t resolve the question of which behavior its business model rewards.

That, to me, is why there are suddenly so many gambling companies. A large existing appetite met newly available legal routes, inexpensive digital distribution, and businesses with a strong incentive to turn occasional participation into a recurring habit. Prediction markets then expanded both the range of things people could bet on and the set of companies that could distribute those bets.

The interesting question now is how much of the next wave will produce useful information—and how much will make placing another bet an ordinary part of opening any app.

Chart sources

The opening chart shows annual nominal US dollars wagered through commercial and state-regulated sportsbooks covered by the AGA. It is not a count of companies, an estimate of all US gambling, or a prediction-market volume series. It does not comprehensively cover tribal sportsbook activity. Calendar year 2026 is omitted because it is incomplete.

Year	Handle, billions of dollars	AGA source
2018	6.58	State of the States 2021
2019	13.07	State of the States 2021
2020	21.60	State of the States 2022, p. 11
2021	57.71	State of the States 2022, p. 11
2022	93.20	State of the States 2023
2023	121.06	State of the States 2024
2024	149.90	State of the States 2025
2025	166.94	2025 Commercial Gaming Revenue release

These are the figures in the cited publications; the AGA revises historical data as state reports change, so they can differ from earlier releases or later comparisons. The cited AGA reports do not provide a comparable annual US-only Kalshi-and-Polymarket series. Adding global exchange volume to US sportsbook handle would imply a precision and comparability the data don’t support.

Learnings from the Codex repo

Thu, 27 Aug 2026 00:00:00 +0000

I’ve been fascinated recently at what the best practices in the new age of engineering look like. But it’s hard to find real data on best practices. For example, X has a ton of “information” about what’s happening at the cutting edge, but it’s very hard to validate whether any of it is real. Talks suffer from the same problem as an exec at a company can say anything they want or stretch the truth. Are people really not looking at any of their code? Are people productively using billions of tokens every day? It’s hard to get ground truth on that.

Because of that, I thought OpenAI’s open source Codex repo would be an good place to get a bit closer to ground truth:

OpenAI’s internal teams have access to edge of the frontier (it’s rumored that Astra is a step change above GPT-5.6-sol for example)
The Codex repo has been open source since it was launched in 2025, so there’s plenty of stuff that has happened in the open.
OpenAI likely has the best pulse of any company in the world (save a few) on how to build software in the agentic engineering way

So I kicked off an analysis of the repo using a combination of Codex (gpt-5.6-sol) and Claude Code (Fable 5) to try to see what they were doing.

My immediate observation is that Codex has seen a step change increase in PRs per week over the last few months. In May 2025, the Rust implementation had 98 commits from six authors, and one person wrote 89 of them. In the first 25 days of August 2026, it had more than 1,000 commits from 135 authors. This is a big jump, and it’s an interesting convergence of a few factors: a) likely a lot of coding agent usage b) aggressive hiring for the team and c) heavy investments in guardrails and automation rules that make it easier for many people and agents to work at the same time.

Graduating from small team / handwritten-ish code to large team with agents

The public Codex repository started on April 16, 2025 as a TypeScript CLI. Since then, the repo has changed quite significantly. The initial era of the Codex repo had a small number of authors pushing out everything. For example, Michael Bolin wrote the original Rust implementation and also 150 of the first 169 Rust commits.

However, over time, this has changed dramatically:

	May 2025	March 2026	August 2026
Commits per month	98	791	893
Regular author identities with 5+ commits	2	28	35
Share written by the busiest author	91%	14%	18%
Authors landing changes on the median active day	1	12	~18
Rust crates touched on the median active day	4	16	~28

The volume of changes grew roughly 8x, from 98 commits in May 2025 to 791 in March 2026. By August, the repository was already hitting 900 commits. Commit counts are an imperfect measure of output, especially as development practices change, but the surrounding evidence points to a similar story – there were more authors were shipping on the same day, across many more parts of the codebase.

Even though coding agents have recently gotten much better, part of the sizeable increase in Codex velocity comes down to sheer team size. OpenAI appears to have put a lot more people on the project (137 members now) and generally been able to keep people working on separate parallel streams of work (most authors seem to be working on separate, parallel crates).

With that many more people and agents changing the code at the same time, the rules around how they work become much more important.

Agent guardrails and rules

The first interesting thing is the repo’s AGENTS.md file. The Codex repo takes this fairly seriously: it’s clear they’ve put a lot of thought into and have been aggressive at removing slop and extras (the main file is 322 lines).

There are a few rules in particular that I found interesting:

1. “Never add or modify any code related to CODEX_SANDBOX_NETWORK_DISABLED_ENV_VAR or CODEX_SANDBOX_ENV_VAR.” Some tests check these variables to figure out whether they can safely run nested sandboxing or network behavior. An agent might otherwise see those checks, decide they are getting in the way of a test, and “fix” them. I think it’s quite smart to find these types of cheating behaviors that you’ve seen in test runs and encode them as rules.

2. “Do not add tests for values that are statically defined” and “Do not add negative tests for logic that was removed.” These rules are aimed at tests that make a change look more rigorous without checking any meaningful behavior. Coding agents are very good at generating this kind of plausible-looking test volume, so explicitly telling them what not to test keeps the suite focused on behavior that can actually regress.

3. “Features that change the agent logic MUST add an integration test.” Agent behavior usually comes from the combination of context, tools, model responses, and the turn loop, so a small unit test often can’t tell you whether the agent will actually do the right thing. Codex’s TestCodexBuilder test harness runs the real agent loop against fake model streams. New tests are also supposed to use an automatic environment setup so they keep working when the app-server and exec-server are on different operating systems.

4. “Avoid bool or ambiguous Option parameters.” If an API can’t be changed, opaque values like false, None, or a bare number need an exact /*param_name*/ comment next to them. This is already more specific than what you normally see in an instruction file, but the interesting part is that they didn’t leave it as an instruction.

Lint rules

The ambiguous argument rule is probably my favorite example of what the team does next. Rust makes it easy to end up with calls like this:

foo(false, None, 1000)

It is basically impossible to review that without jumping to the function definition. The Codex team would prefer that you change the API, but when that is impractical they require comments next to ambiguous literal arguments:

foo(
/*enabled*/ false,
/*parent_turn_id*/ None,
/*timeout_ms*/ 1000,
)

They then built a custom lint that checks whether the comment exactly matches the parameter name in the function definition. It was introduced in March 2026, applied across the Rust workspace a couple of days later, and then moved into Bazel CI.

The other thing worth saying is that these rules did not appear all at once. Support for AGENTS.md landed in May 2025. More detailed test guidance followed that summer. Snapshot requirements came in February 2026, the warning about codex-core in March, the trait guidance in April, and the model context and change-size rules in June. It looks a lot like the team is taking repeated review feedback and putting it somewhere that the next person or agent will see before making the same mistake.

You can see a rough pattern here: a problem first shows up repeatedly in code review, it gets written into AGENTS.md so humans and agents see it before making a change, and then the team turns it into a lint or CI check once the rule is stable enough. Not every rule makes it to the last step, but the expensive and objectively checkable ones tend to.

Codex has 38 lint rules, and I think it’s part of what makes the repo easier to work on as an agent because it has a large number of automated checks that prevent out-of policy behavior (and in a deterministic way).

Investing in an integration test harness

One other thing that I thought was interesting was how much the Codex team has invested in their tests. Tests compose about 615k lines (or 40%) of the codebase, and Codex has also invested in a full mock test harness: they’ve spent around 7k lines of code across 300+ commits to built out a harness that can stub out http responses from the Responses API. This integration test harness will run a real Codex thread, and it can call tools, apply approvals, and generally iterate on requests as if it’s getting responses back from the LLM. It’s a really interesting and deterministic way to test a large amount of behavior, and I think it’s quite smart to have invested so heavily in this because the Codex loop is ultimately the most important part of the product.

Another area that I was curious about (especially because our team has seen our test suites slow down as our coding agents get better and faster at writing tests), is how they’re still able to keep up speed of development despite a large number of tests. Codex doesn’t run the same enormous test suite at every stage. While someone is working on a change, the setup is to test only the affected Rust crate. If you change the terminal UI, for example, you run the terminal UI tests, not the entire workspace. This keeps the everyday edit-test loop reasonably fast.

Before a change is merged, CI broadens the coverage. Bazel runs the compatible Rust tests across macOS, Linux, and Windows, while separate jobs check the SDKs, formatting, dependencies, and repository rules. The largest workloads are divided across machines and reuse remote build caches.

After the code reaches main, Codex pays for a much more exhaustive pass. It runs the full Cargo test suite across five platform and architecture combinations. Each platform compiles the tests once, packages the resulting binaries, and distributes their execution across four machines. Slower native Windows checks, release builds, and remote-environment tests also happen here.

Basically, Codex has set up their environment so only relevant tests are run while developing, and get progressively more thorough as a piece of code gets closer to deployment. This makes it so you can still have fast deploys and ship quickly, while keeping safety and correctness in the long run.

Migrations with linting and feature flags

The other fascinating thing we observed in Codex’s codebase is some good old-fashioned, high-quality engineering. Their engineering team uses a combination of feature flags, linters, and other rollout mechanisms to ensure safety but also speeding rollout. Large changes are staged so the old and new implementations can coexist, and the migration plan is eventually encoded in lint rules instead of depending on everyone remembering it.

The TUI migration is a nice example. On March 16, the team created a temporary parallel implementation behind a tui_app_server feature flag. Ten days later, they enabled it by default. Once it was stable, they deleted the old TUI and retired the feature flag, while continuing to accept the old flag in configuration so existing users would not get an error.

Two weeks later, they added a CI rule preventing the TUI from importing codex-core directly. I think this is a particularly good way to finish a migration. It’s easy to clean up a dependency once, but on a team this large, someone will eventually add it back unless CI stops them. The feature flag made it easier to move over incrementally, and the lint rule made sure the team couldn’t accidentally undo the work later.

Conclusion: speed == testing, boundaries, lint, hiring

The Codex team is running and building upon a highly used, production-level codebase while moving incredibly quickly. They’ve ramped up velocity considerably in the last few months through a combination of AI coding agent usage as well as hiring for new team members. There are a lot more people working on Codex than there were a year ago and many of those people appear to be very effective engineers. Also, the codebase is explicitly organized to give agents context. OpenAI have invested in the tests and boundaries that let all of those people and agents work at the same time.

The interesting thing is that at least for the Codex team, as implementation got cheaper, it did not make the rest of engineering less important. Codex put a lot of work into a well-designed system, particularly focused on the classic parts of engineering excellence: testing, high quality boundaries and abstractions, automatic linting systems, and of course hiring good people. All of those things seemed to have gotten more important.

How Claude's watermarking (probably) works

Wed, 12 Aug 2026 00:00:00 +0000

Update (2026-08-20): Anthropic has since published technical details confirming that Claude’s watermark is based on SynthID-Text — a keyed statistical watermark on token selection, exactly as this post hypothesized. See the update section near the end of the post for a full rundown.

Yesterday, Anthropic announced that they had started watermarking AI-generated content. Folks across the internet were particularly up in arms about it (I think rightfully so), especially because this apparently is happening to all Claude models whether or not you are in the EU. I wanted to investigate what they’re actually doing and whether it’s perceptible or changeable.

Anthropic provides some insight into their approach in their article How Claude marks AI-generated content. Though it doesn’t actually provide any technical details on the implementation, it provides some guidance to help draw a wide net around the scheme they’re using. The key clues Anthropic left in their help center article:

The scheme “weaves an imperceptible watermark directly into the text itself. You won’t see it, and it doesn’t change the meaning, quality, or readability of Claude’s response.”
The watermarking doesn’t work well on very short text.
The watermark seems to have started recently (August 2nd or later)

This helps us narrow down the possibilities quite a bit.

Setup

To actually get to the bottom of what Anthropic are doing, I realized that there are some interesting experiments you can run. Gloaguen et al. created specific tests to check for statistical watermarking, and we can also perform an analysis of Claude outputs to check for things like hidden unicode or whitespace results.

For good measure, I also downloaded a dump of my Claude chats (I’ve used Claude Code since 2/4/2025 and have recorded 1206 sessions) and did a quick comparison to see if there was any changepoint around early August that percepitbly changed the mix of tokens that Fable 5 output (my usual daily driver model). I wasn’t able to find any perceptible difference in this historical analysis, which confirms Anthropic’s claim that the watermarking is generally imperceptible unless using more specific tests.

No hidden unicode or whitespace

The second thing I checked is whether there’s hidden unicode or whitespace or punctuation patterns. This was pretty conclusive: they’re not doing something so simple.

An analysis across 7.2 million extracted prose characters (both on historical Claude Code text as well as generated Claude Code text on August 11) showed that the only unicode characters that were output by Claude were reasonable and part of day to day usage:

Curly quotation marks, apostrophes, and horizontal ellipses
Em/en dashes (A LOT of them unfortunately)
Mathematical symbols
Accented or non-English characters
Emoji

An audit by Codex, with me spot checking about 10 samples, found no anomalous instances that were consistent with a hidden Unicode watermark. I similarly found no whitespace encoding marks.

This evidence, combined with the fact that the watermarking is imperceptible and doesn’t work on short text, means that Anthropic is most likely using some form of statistical token watermarking.

Statistical watermarking schemes

There are a few different schemes that are available that can add watermarking to text. I’ll talk about the simplest version, the green/red list created in 2023 by Kirchenbauer et al., because it’s the easiest to explain and once you understand it will allow you to understand how these schemes generally work.

Green/red lists

This scheme is super basic, but it’s quite clever and fun. Here are the steps:

Split your output vocabulary into two sets: a green and a red list. Make sure they’re chosen uniformly at random.
Then for the green list, add $\delta$ to all of the logits and sample from the updated distribution at decoding time.

To figure out whether a text has been watermarked, then you compute the z-score that the tokens in the green set appear. If the text wasn’t watermarked, then the expected value of text in the green list is $T/2$, where $T$ is the token count, with a standard deviation of $\frac{\sqrt{T}}{2}$. So the suspiciousness of getting this outcome is just the z-score:

$$ z = \frac{2G-T}{\sqrt{T}}. $$

If some red token already has probability 0.99 (which would be a huge logit lead) a big $\delta$ nudge to the greens still wouldn’t overtake it. So the bias only changes words that have a lot of options and generally high entropy.

For an example, let’s say you asked your LLM to write a poem, you might have the following potential sentences that get generated:

Word	List	Sentence
crisp	Green	It was a crisp morning
quiet	Green	It was a quiet morning
foggy	Red	It was a foggy morning
cold	Red	It was a cold morning

If it was watermarked, you’d get an imperceptibly higher percentage of generating “crisp” or “quiet” morning (depending on how strongly the LLM provider decided to watermark with their $\delta$ value). Do this across all the words that an LLM is generating, and you can get high levels of confidence in your watermarking.

That being said, I don’t believe Green/red lists are used in practice because they’re easy to detect and there are schemes that use the model’s available entropy more efficiently (and thus harder to detect and less likely to change the outputs of the model). The most well known scheme is SynthID-Text which was developed by Google Deepmind and is used by Google in production.

SynthID-Text

SynthID-Text is the same idea as green/red lists, but using a slightly different approach that Deepmind calls tournament sampling. Here are the steps:

At each decoding step, hash a secret key together with the last $h$ tokens of context to produce a seed. That seed assigns every vocabulary token one $g$ value in $[0,1]$ per tournament layer.
Draw your candidate output tokens using the model’s logits as normal.
Run a tournament bracket where candidates face off in pairs, and the candidate with the higher $g$ value for that layer advances.
Output the tournament winner as the decoded token.

To detect the watermark, you just need the secret key. You can compute the seed value and the $g$ values associated with every token in the text:

$$ \operatorname{Score}(x)=\frac{1}{mT}\sum_{t=1}^{T}\sum_{\ell=1}^{m}g_\ell(x_t,r_t), $$

Then compare the result with the null distribution and generate a standardized score similar to the Green/red list detection.

SynthID also uses repeated-context masking: if the same $h$-token context window has already been used during a response, the implementation can decline to watermark that position. This prevents a repeated context from receiving the same bias over and over, but it matters substantially for testing because using the wrong context length can accidentally trigger the mask and hide the signal.

SynthID is a bit more disguised than Green/red lists because every candidate is drawn from the model’s own distribution, so the tournament can only promote words the model already considered saying. When the model is pretty certain about the next token, there’s low entropy and not much watermarking (just like Green/red lists). The signal gets stronger for high entropy words, which is also why these schemes need a decent amount of text before detection becomes reliable.

When the model is nearly certain about the next token, there is little entropy available for any sampling-based watermark to use. The signal accumulates mainly at higher-entropy positions, which is one reason these schemes need a decent amount of text before detection becomes reliable.

Going back to our poem, say the model draws four candidates and we run a two-layer tournament using the continuous-score variant:

Matchup	g-values	Winner
crisp vs. foggy (layer 1)	0.71 vs. 0.24	crisp
quiet vs. cold (layer 1)	0.90 vs. 0.42	quiet
crisp vs. quiet (layer 2)	0.35 vs. 0.83	quiet

So “quiet” gets emitted because of its tournament $g$ values. It’s clever because any single word looks like a standard part of the output, but with the secret key you can test whether emitted words repeatedly align with the keyed scores. It’s also quite nice because you can adjust the number of layers to change the tradeoff between detectability and model quality.

SynthID is the only scheme that I know of (or ChatGPT/Claude knows of) which is running in production, and it seems like my best guess candidate given that it’s been publicized and run a scale by Google.

Experimental results

To see if Anthropic is running one of these kinds of statistical watermarks, I ran some of the black-box tests from the watermark detection literature with Codex GPT-5.6-sol[0].

Green/red list detection

I had Codex run Gloaguen et al.’s detection algorithm. In this, Claude is forced to complete sentences using one of four fruits:

I ate 111111111111111 peaches
I chose 222222222222222 plums
...

The prefix and repeated digit vary while the fruit alternatives remain fixed. If a classic keyed watermark partitions tokens into green and red sets, then a particular fruit should become unusually likely or unlikely.

Model/test	Number of runs	Permutation p-value
Sonnet 5, compact digits	1,800	0.677
Sonnet 5, spaced digits	1,800	0.556
Fable 5	1,200	0.886

The Sonnet tests used 10 prefixes, 9 digit contexts, and 20 calls for each combination, for 1,800 responses each. The Fable test used 6 digit contexts, for 1,200 responses. Each p-value was calculated from 100,000 permutations.

All three were clear negative results. The Sonnet test was strong enough to rule out a fairly large, stable Green/red effect in this particular setup. It does not rule out a weaker watermark, a key that changes between requests, or a different kind of watermark entirely.

SynthID detection

The next experiment looked for the fixed context window used by SynthID-like schemes. The basic setup forced Claude to return a line such as

I ate red green cherries

Here red is a perturbation word and green is repeated $H$ times after it. If the watermark only looks at the last $h$ tokens, red should stop affecting the watermark once $H$ reaches $h$. For example, if $h=2$, I would expect a strong effect at $H=1$ and little or no effect at $H=2$. So the thing we’re looking for is a sharp drop at some value of $H$.

Here’s an actual example of the experiment I ran:

$H$	Repeat	Actual response
1	0	`I ate red green cherries`
1	1	`I ate red green cherries`
1	2	`I ate red green cherries`
2	0	`I ate red green green plums`
2	1	`I ate red green green cherries`
2	2	`I ate red green green cherries`
3	0	`I ate red green green green cherries`
3	1	`I ate red green green green cherries`
3	2	`I ate red green green green plums`

At larger scale, I calculated $Z(H)$, which measures how strongly changing the perturbation word changes Claude’s fruit choice. A value near zero would mean no detectable effect. $Z(1)=87.25$, which I saw in the experimental runs, means the test statistic was 87.25 (!!) standard deviations above what you would expect to see in randomized data:

$H$	Context form	Standardized perturbation effect $Z(H)$
1	`red green`	87.25
2	`red green green`	58.42
3	`red green green green`	33.64
4	`red` + 4×`green`	37.22
5	`red` + 5×`green`	38.46
6	`red` + 6×`green`	25.34
7	`red` + 7×`green`	19.28
8	`red` + 8×`green`	25.10

That is an extremely strong result, with $H=1$ giving $p\approx0.00001$. Unfortunately, this test wasn’t conclusive because it only tells us that the perturbation word matters, and we didn’t actually see a sharp drop off on any $H$, only a slow decrease, which could mean that this isn’t a watermark at all, but rather just an effect that comes from the model.

The full scan used 20,736 Sonnet 5 responses, with 2,592 at each value of $H$. The sharpest bend was at $H=2$, so I tested it again using fresh Sonnet 5 responses and also on Sonnet 4.6 (which based on my reading of Anthropic’s help center article is less likely to be watermarked because it’s an older model):

Endpoint	Observations	$Z(1)$	$Z(2)$	$Z(3)$	$D(2)$
Sonnet 5, held-out confirmation	7,776	85.77	61.90	33.35	38.14
Sonnet 4.6, matched comparison	7,776	105.49	70.61	76.25	32.06

The bend appeared again in the fresh Sonnet 5 data. But the effect did not disappear at $H=2$: the $Z(2)$ and $Z(3)$ values were still enormous. Sonnet 4.6 also showed a very similar bend.

This makes the result much less exciting than the huge numbers initially suggest. Sonnet 4.6 might also be watermarked, so it is not a true negative control, but it does seem the pattern is not unique to Sonnet 5 and does not look like a clean context-window boundary. The most likely explanation is that words like red and green naturally change how Claude chooses among fruits.

So this was a strong detection of a prompt effect, but not a positive detection of SynthID. It also doesn’t rule out a different watermark that this test cannot see.

Conclusions

My current best guess is that Anthropic is using a private-key watermark that changes token selection as Claude generates text. But that guess comes mostly from Anthropic’s description and negative results in other tests as opposed to a positive result in my experiments.

I was able to rule out a few things as I found no evidence of hidden Unicode or whitespace, and the constrained-choice tests argue against a large, stable Green/red bias. That said, the apparent SynthID signal turned out to be a likely strong prompt effect that also appeared in Sonnet 4.6, so it doesn’t necessarily positively identify a watermark.

Note that I’m not actually sure whether the watermarking rollout is fully complete yet and which models it’s available on. From Anthropic’s own help center article, it says that models are going to be watermarked going forward and that support for any existing model is “in progress”. I think I’ll have to re-run this analysis again in a few weeks or when there’s a verifiable model that does have watermarking enabled and is confirmed by Anthropic. We’ll just have to wait and see.

UPDATE (2026-08-20): Anthropic confirms it’s SynthID-Text

Well, we didn’t have to wait very long. Two days after I published this post, Anthropic put out a blog post with actual technical details (covered by TechCrunch among others). Anthropic notes that Claude’s watermark is based on SynthID-Text, just as was predicted by this post. It’s nice to get one right occasionally!

Going through what Anthropic confirmed point by point:

It’s a keyed statistical watermark on token selection. In Anthropic’s words: “Instead of using an arbitrary random number generator to pick the next word, watermarking uses the key and a few words that come before to settle what word the model should pick.” That’s the same mechanism from the SynthID-Text section above.
No hidden characters. Straight from Anthropic: “Nothing is added to the text and there are no hidden characters.” This matches the Unicode and whitespace analysis above (where my analysis of 7.2 million characters turned up nothing)
Paraphrasing defeats it. Light editing preserves the watermark, but larger rewrites where a large number of words are adjusted will remove the watermark. This is consistent with my note above that a paraphraser sidesteps this watermarking fairly easily.
No performance cost. No extra tokens, no added latency, and (per DeepMind’s original Nature results) no statistically significant quality difference.
A detection API is coming. This one is a fun piece of new information. Anthropic says they will “soon be offering a watermark detection API,” with details still being worked out. They also state the watermark can’t be traced back to a specific person, organization, or chat. I’d bet that you’ll be able to pass text to their API, they’ll run an analysis using the secret key, and then they’ll give you the confidence / probability they have that it was indeed watermarked by Claude.

I also went ahead and re-ran the completed Sonnet 5 experiments on August 20, collecting 11,676 fresh responses with the same prompts and analysis as the August 11–12 archive. The short version is that Sonnet 5’s behavior changed substantially between the two runs, but the results did not necessarily change the original analysis much:

Probe	Archived result	August 20 re-run	Reading
Compact-digit red/green	p = 0.6769	p = 0.2204	Negative in both runs
Space-separated red/green	p = 0.5558	p = 1.0000	Negative in both runs
Fixed sampling	300/300 unique	300/300 unique	No collisions in either run
Context shielding, Z(H=1/2/3)	85.77 / 61.90 / 33.35	84.25 / 59.46 / 32.73	Basically the same shape as the original experiments

There was nevertheless very strong drift from early August. Only 65.17% of the compact-digit choices, 58.44% of the spaced-digit choices, and 80.94% of the context-shielding choices exactly matched their archived counterparts. Paired randomization tests were at the Monte Carlo floor (p = 1/100001) for all three datasets. Reported median output-token counts also moved from, which would suggest that token accounting or effective tokenization changed as well.

So something in Sonnet 5’s serving, sampling, tokenization, or surrounding configuration definitely changed. What did not appear was a new watermarking signature that lets me attribute that movement to SynthID-Text. Anthropic says support for pre-August 2 models will be added over the coming months, and it has not published a known-positive backport date for Sonnet 5. A confirmed watermarked endpoint or the promised detection API is still needed to close that loop.

A note on the future of watermarking

While this is mostly a technical post, I do think it’s worth thinking about what this potentially means for the future. It’s already relatively easy to detect when AI was used to write something and someone was careless. For example, I don’t need a statistical measure to figure out that this was written by an LLM: “That’s not a documentation problem — it’s a retrieval problem.”

In my view, putting statistical watermarks like the one described in this post on all LLM output greatly ratchets up the stakes from what is easily perceptible by humans, and in a way that is particularly undemocratic. You’ll only be able to detect the watermark if you’re in a select group that has access to a secret key (e.g. frontier lab employees or government / police). While this particular change is somewhat innocuous in my opinion, as I would assume most content written in the years after 2026 will be LLM generated or at least LLM assisted, it is a bit scary to know that a single relatively undemocratic, but innocuous change can give way to many more that may not be as innocuous. The EU transparency code that Anthropic is following has basically mandated that watermarking of text is required from model providers operating in the EU, so unfortunately, we should expect this to happen to a lot more of our model output.

Thankfully, sidestepping this kid of watermarking is fairly easy with a paraphraser or rephraser that doesn’t have a watermark (or just rewriting the text by hand). The watermarking is more meant to raise the cost and annoyance of doing so.

Footnotes

[0] Of course, I tried to use Fable 5 for the analysis to start with, but it failed the security classifier and fell back to Opus 5 and I had to rely on the old trusty GPT-5.6-sol. This was probably better anyways as I’m not sure Claude would want itself to be self inspected.

Why we built 143

Tue, 30 Jun 2026 00:00:00 +0000

The best person to understand a problem really deeply usually isn’t an engineer, it’s usually someone who’s using the product day in and day out with customers. Or it’s the customer support person who sees questions all day about why a particular feature isn’t working. While engineers have historically been the only people who could fix things, that’s not true anymore.

Now with coding agents, non-engineers can fix things too and tend to be closer to the problems that users run into on a daily basis. The problem is that the tools built on top of these agents weren’t made for that person, they were built for engineers by engineers. That’s why we built 143.

Where it started

At Assembled, we saw this firsthand: our support and product teams kept surfacing fixes that engineers never had time for. Coding agents could have handled many of them, if the tooling didn’t assume you lived in a terminal.

143 is the internal coding agent infrastructure we built at Assembled to help our non-engineers with this problem (while also helping our engineers build better software). We wanted coding agents to help with real product work, not just demos and internal tools.

What we built

We started with a small tiger team that cleaned up our instructions, invested more in CI/CD, built agent hooks, and made the agent environment less fragile. All of that helped, but it also made the bigger issue obvious: we needed a system that made this work shared across the team as opposed to being trapped inside each engineer’s terminal.

We were inspired by internal systems like Stripe Minions and Ramp Inspect, but those were never available to the public. We wanted something open source that other teams could use, adapt, and improve.

We built 143 so the person who spots the bug doesn’t need to become an engineer to fix it. That meant:

Automations shouldn’t be hidden on one engineer’s laptop, so anyone on the team can see what’s running and what changed.
Teams should be able to swap out intelligence and harnesses as coding agents and models improve.
Shared context should make it natural to start work automatically from Sentry issues, Linear assignments, PR comments, or scheduled checks.
Code review should be handled by agents on some or all PRs, and they should be able to auto-approve low-risk changes against thresholds you define.
You should be able to set up a great environment once for everyone, with the same repos, credentials, tools, logs, docs, and product context available to the whole team.

Open source for everyone

The same idea that you shouldn’t have to be an insider to contribute is why we open-sourced 143.

I owe a lot of my career to early open-source work on Ruby on Rails. That is where I learned software fundamentals from people like Aaron Patterson, Santiago Pastorino, Jose Valim, and Jeremy Doerr. Their PR reviews, their patience, and their willingness to design-pair with strangers on the internet shaped how I think about software.

I was just a college student, but the Rails core team didn’t care who I was. If a PR was good and well-intentioned, it was welcome. I started with tests and tiny refactors, learned more of the codebase, and eventually got really deep into the internals of Active Record. That work helped me get my job at Stripe and became the launching pad for the rest of my career.

I want 143 to be available in that same spirit. I hope it helps other people and teams the way open source helped me. The code is on GitHub under an MIT License.

Cheap software won't make engineering cheap

Sun, 31 May 2026 00:00:00 +0000

In a world where AI writes more and more of the code, is it crazy to still want to be a software engineer? My answer is no. I think there will still be a reasonably large number of engineers in the future, and some of them will be incredibly well paid.

I’m not necessarily saying there will be more of them than there are today. But if you’re an engineer (or whatever the future version of the job ends up being called) and you know how to build high-quality systems that solve real needs, you’re going to be very valuable.

Two things seem likely to me, and both are already visible if you look at how other industries have evolved.

Software will follow Jevons paradox

Jevons paradox is the observation that as something gets more efficient, we tend to use more of it, not less. William Stanley Jevons noticed that when James Watt dramatically improved the steam engine, factories ended up burning more coal, not less. Cheaper power meant factories could produce more, businesses expanded their operations, and total coal consumption went up.

It’s very likely that coding is going to get a lot cheaper. That means we’ll likely end up with far more software than exists today as it becomes cheaper and more possible to build. For example, every family might end up with its own custom app for running the household, or you might see every company customize their internal tools way more. Will professional software engineers be needed for all of this software? Probably not all of it, especially as it becomes easier and easier to write and maintain. But generally when markets expand, the need to have someone managing at least some of that software becomes pretty high.

The other thing that I’ve noticed is that as things gets more efficient, the distribution of the thing tends to get broader and luxury goods tend to appear. More efficiency means more choice, and people sort themselves across the premium and the economy ends of the market.

Fashion. Most people can now afford a closet full of shirts and shoes. In the 1800s you used to only own a few pieces of clothing, but now manufacturing scale has made pretty much all clothes incredibly cheap. That has allowed the development of ultra-high end clothing: handmade suits, $200+ merino wool t-shirts, $5k+ jackets, etc.
Air travel. Similarly, as planes got more efficient over the decades, the cost of a ticket dropped precipitously and more people fly than ever before. But at the same time, the distribution of what it looks like to fly is wider than ever before. We now have basic economy seats where you can’t bring a carry on. But you also have first class suites and private jets. There’s much more dispersion than ever before.

I think software engineering will play out the same way. You’ll have a lot more software than there used to be, and you’ll also have a high end that is far higher end than it ever was. The handful of people who still know how to build hardened production software, systems that scale to massive levels of compute, stay reliable, and get the tradeoffs right, will be even more in demand than they are today. The middle falls away and you get a bimodal distribution, much like air travel: either you’re paying tens of thousands of dollars for the first-class or private experience, or you’re in economy.

Engineers will orchestrate more

The other shift is in actual job that will be done by engineers. I recently read what pilots actually do on a 14-hour flight, which is a fascinating corollary to what I think will happen in software.

In commercial flights, the autopilot handles the flying of the plane on basically the entire flight, and the pilots physically fly the plane for only takeoff and landing. But the pilots’ main jobs have shifted to handling communication with air traffic control, managing flights paths to look out for weather and turbulence, and handling contingency planning to develop a safe backup plan for each scenario. Arguably this is something that pilots could do before, but they’re likely much better now that it’s their main focus. Notice too that the job has switched from a in-the-zone, focused task of flying the plane to something that is much more interrupt and monitoring based.

This is roughly what I expect for software engineers as the act of writing code keeps getting automated.

There are a lot of articles making this case, but the general thesis is that engineers will spend their time on everything in the stack other than the pure implementation: the product requirements, the design, overseeing the implementation, making sure there’s enough testing, the rollout, the maintenance, talking to customers.

We’ve seen this type of morphing happen before. In an interview with Cursor’s co-founder, Simon Eskildsen (creator of Turbopuffer and Logrus, and a deeply skilled infrastructure engineer) describes how in the early 2010s you started to see DevOps engineers emerge: people who could both SSH onto a machine and write configuration. Before that, ops was its own role, people who managed the servers but didn’t write code. Over time that blended into what we now call production engineering: people who can code but also have deep expertise in Kubernetes, Terraform, AWS/GCP, observability, and logging. Now you don’t need as many people handling your devops, but the people who you still do need are way more valuable.

I think the generalist engineer is about to go through a similar morph, just pointed in a different direction of some hybrid of engineer, product manager, and designer. The deep implementation skill hopefully won’t disappear, but it stops being the whole job.

So will the future be good?

I think there will be some ways in which the future is nicer, and other ways that will be extremely unfun.

The future will be great because access to really custom software will likely get democratized. It’s going to be easy to have software that conforms much more exactly to what you specifically are looking for, and you’ll be able to build a lot of it yourself. The quality of life should keep climbing now that software can become more specifically built for you. I’m excited for things like access to better health information and much more customized health diagnoses that accessible much more readily. I’m also excited for much easier ability to talk across different languages as compute and translation become easier to put into devices.

At the same time, the future might not be as fun because I think we’ll keep seeing stratification and a steadily rising Gini coefficient. The goods that are rival and zero-sum (housing in the places people want to live, access to really high quality education, etc.) derive their value from scarcity, so they don’t get cheaper as everything else does. They tend to do the opposite usually as a few people accumulate more wealth, which seems very likely in a world with more, cheaper software.

So, the future will see a lot of change. I think the base layer of life will keep getting better and more customizable, while the scarce, positional stuff will keep getting harder to reach.

Time

Fri, 29 May 2026 00:00:00 +0000

I’ve been thinking about time lately, especially how much of it is available. The strange thing I keep coming back to is that life feels both incredibly long and incredibly short at the same time, depending on which angle you look at it from. Both things can be true at the same time. It reminds me of the coastline paradox: a coastline wraps around a perfectly finite patch of land, yet the closer you measure it, the longer its edge gets, running off toward infinity the finer your ruler. It’s both finite and infinite at the same time, depending on how closely you look.

Life is long

Life expectancy in the United States is relatively long compared to 100 years ago. You can expect to live 76 years for males, 81 for females, and even these statistics are skewed downwards because of COVID deaths and drug overdoses, so if you’re a generally healthy person, you can expect to live 5-10 years longer than those baselines.

I’ve watched people have full-blown renaissances when they hit 40 or 50, and when you look closely it’s almost never out of nowhere: it’s compounding on a lifetime of work and learning that finally found its moment.

There’s a long list of people who started their best-known company after 40: Eric Yuan (Zoom), Chip Wilson (Lululemon), Tony Fadell (Nest), Joseph Lubin (Ethereum). And in fact, most unicorn founders are actually in their 30s, and the average one has 14 years of industry experience before founding, up from 8 years in 2010. Experience and network seem to be key components of making something very important, things you can only get from age.

To me, it’s exciting because there are many examples of compounding in practice. The most famous example is probably Nvidia: Jensen Huang had been running Nvidia for 30 years before the LLM revolution, and he had spent that time quietly amassing a team and company filled with expertise and focused execution. That compounding was really unleashed when the AI revolution occurred and he was able to put Nvidia in exactly the right spot to capitalize on it’s expertise and moat.

OpenAI looks similar, though on a shorter timespan. I remember when OpenAI was most famous for OpenAI Five, an AI system that played Dota 2 and defeated world champions. It was a toy at the time with no practical application, just like what they could GPT-3 and GPT-3.5 would be. They were only focused on developing great AI models, and that allowed them to compound their research advantage.

My takeaway from this view is simple: keep learning and keep building. The runway is much longer than it feels in any given year.

Life is short

But the paradox is that even though life is long, our perception of time speeds up as we age. It’s a well-documented phenomenon, usually attributed to two things a) the decreasing novelty of day-to-day life and b) the shrinking proportion of current time relative to everything you’ve already lived. A year is a tenth of a ten-year-old’s life and a fortieth of a forty-year-old’s, so of course it feels like it’s flying by.

This means that if you’re only halfway through your life expectancy by the calendar, you’re actually much further than halfway through your perceived life. The clock and the felt experience are running at different speeds.

Time also compresses when you’re heads down on something. Michael Siffre did a famous experiment where he lived in a cave cut off from sunlight and clocks for months, and he experienced enormous time compression: he thought only about 150 days had passed when it had actually been closer to 180, and at one point counting to what he believed was 120 seconds took him 5 minutes. You can see a gentler version of this when a child is lost in coloring or when you surface from deep focus and realize hours are gone.

Another reason why life is short is because the quality, health, and vigor you have at any given point of time declines. Your raw life force is generally strongest in your 20s and 30s. People in their 40s and 50s tell me constantly that they used to have way more energy. I didn’t want to believe it, but then I remembered that in my 20s, the 30-year-olds kept telling me my body would hurt more and injuries would take longer to heal, and I didn’t believe that either until it turned out to be completely true. On top of the energy curve, it generally gets harder to learn and grow into entirely new paths as you get older. Not impossible, just more effort than it took when you were younger. So you can have multiple things working against you at once.

I’m in my 30s now, and I still have an incredibly active mind with more ideas than I can act on. But I’m just more tired than I used to be. It’s harder to stay up for long stretches, and a bad night of sleep hits me much harder than it once did. I suspect that only continues.

Enjoy it

So life is both long and short, depending on the angle. Long enough that it’s never too late to start, and that compounding will reward patience. Short enough that the years you have the most energy and the most novelty are finite, and they’re quietly accelerating past.

For me, I’m focusing on working on building things / working on problems I genuinely enjoy and continuing to learn from incredible people. I just hope to stop to smell the flowers every now and then.

Number of tokens shouldn't be the only metric

Wed, 06 May 2026 00:00:00 +0000

I’ve heard of a lot of teams recently starting to use number of tokens as the key metric by which they measure their engineering team.

It’s actually kind of funny that I even feel the need to write this blog post, but I did want to get it on record: I think it’s a bad metric if it’s your primary north star.

Should it be one of many metrics that you use to understand how people on your team are performing? Yes. You definitely want some observability into how your engineers (or non-engineers) are using LLMs. But gamifying it and making it THE key metric is just a recipe for disaster.

As I’m sure some companies have found out by now, there are a number of reasons why this isn’t a good idea:

Tokens scale linearly with cost. While that may not be a problem early on, I guarantee you it will be a huge problem later on when you’re paying out the nose to Anthropic and OpenAI but can’t easily switch the volume off. Tokens tend to be reasonably sticky because it’s not easy to change workflows, especially if you have automations running that require tokens. Often it’s a project to go and identify where all the cost is coming from, categorize whether that cost is worthwhile, and then figure out how to stop it and possibly migrate systems off of LLMs.
It’s a fast-tracked way to create an organization of Slop Cannons. If you are literally incentivizing tokens, then the incentive is for people to spend them as quickly as possible. Even if they’re not outright causing outages, low quality PRs being shipped into production can be slowly insidious over time. You’re incentivizing usage over anything else. More generally, tokens don’t tell you anything about whether the work was good. A 1M token agent run that fixes nothing looks identical on the dashboard to a 1M token agent run that ships a hard refactor. If your North Star metric can’t distinguish those two, your metric is lacking in a key dimension.

But I want people to use AI and to change their behavior!

Great, I do too, but the lesson I keep learning is that you can’t really skip the hard work that is required for behavior change.

I think you should be optimizing for the people who are really excited to use AI and really putting them in charge of moving the organization, and then creating a wave of excitement about what’s possible now.

The handful of people on your team who are already curious will figure things out faster than any incentive program will. Pair them with engineers who haven’t had their “aha” moment yet. Let them ship something visible. Run internal demos. Share war stories about workflows that went from hours to minutes. Behavior change happens through demonstrated value, not through KPIs denominated in tokens.

The other thing worth saying: if your team isn’t using AI at the rate that you want, the problem is almost never that they need a quota. It’s usually that the tooling is rough, the workflows aren’t obvious, or nobody on the team has shown them what good looks like yet. None of those problems get solved by putting a token counter on the wall.

So what should we actually look at?

If you want metrics, look at outputs rather than inputs. Some questions I’m asking our team:

Are we shipping more product per engineer than we were six months ago?
Are we resolving customer issues faster?
Are people taking on projects they wouldn’t have attempted before?
When engineers describe their week, do they sound more energized or more drained?

Tokens are an input, and the metrics that matter are almost always outputs. Optimize an input and you’ll get more of it, but you won’t necessarily get the thing you actually wanted.

Should you watch token usage? Definitely! Use it for cost forecasting, for understanding adoption curves, for spotting people who might benefit from a nudge or some coaching. Just don’t make it the only thing that matters.

Why are executives enamored with AI but ICs aren't?

Fri, 27 Mar 2026 00:00:00 +0000

I think there’s pretty clearly a divide in AI perception between executives and individual contributors (ICs). Executives seem to love it and evangelize it (going so far as to creating mandates at their companies for AI usage). But ICs are typically much more skeptical of its usage. You can see the divide show up everywhere from Hacker News comment threads to internal Slack debates about adopting coding agents.

Here’s my current posit for why there’s such a big divide: executives have always had to deal with non-determinism and focus on nondeterministic system design, while individual contributors are evaluated by their execution on deterministic tasks.

Managing non-deterministic systems

Executives have always had to deal with non-determinism. That’s par for the course:

People being out sick or taking time off unexpectedly
Someone not finishing an important project and not talking about it until far too late in the process
People reacting to an announcement in an unexpected way
A feature being built in a way that doesn’t make sense with respect to the rest of the product, but does technically achieve objectives.

More generally, if you’ve ever taken a Chaos Theory class in math, you’ll know that nonlinear, chaotic systems emerge when individual agents in a system are all acting with different inputs, utility functions, etc. Systems become slightly easier to manage if you’re able to make those utility functions consistent (you’re able to get a grasp on system dynamics).

A manager’s job is to create a model of the world and align everyone’s utility functions, knowing that there’s a large amount of non-determinism in complex systems. So it makes sense that as a manager, you’re ok with a decent amount of this.

AI is something that is non-deterministic but has a lot of characteristics of a well behaved chaotic system (specifically a system where you can understand the general behavior of the system, even if you cannot predict the specific outcomes at any point in time).

For example:

LLMs generally continue their work and provide an output regardless of time of day, how difficult the task is, how much information is available
LLM’s deficiencies have well defined failure modes (e.g. hallucinations, lack of ability to operate outside of their context, and especially poor outcomes when not given enough context)
The types of tasks that an LLM can accomplish are relatively well known, and the capability envelope is getting mapped out quickly. This is different than humans, where each person has a different set of strengths and weaknesses and where you need to uncover these over time.

Many of these properties are more deterministic than large human systems, which makes AI incredibly attractive for an executive who is already used to this and likely has put a large amount of effort into adding determinism into their systems already (e.g. by adding processes and structure in the form of levels and ladders, standard operating procedures, etc.).

ICs live in a more deterministic world

ICs are generally much more focused on particular problems that have specific inputs and outcomes. Correctness is easier to determine, and how good you are at your job can largely be described by quality and speed, where the weights on those two depend on which organization you’re in. This changes as you move up the ladder (a staff engineer is expected to tackle large, ambiguous business problems), but for most ICs, the world is relatively well defined.

ICs deal with plenty of non-determinism in practice (unclear requirements, flaky systems, shifting priorities), but the way they’re evaluated pushes in the other direction. An IC’s value often comes from being reliably precise (e.g. writing correct code, getting the analysis right, producing a design that holds up under scrutiny). The more deterministic your output, the better you are at your job.

AI introduces non-determinism into exactly this space, and from an IC’s perspective, there are good reasons to be skeptical:

It’s not as good as they are at their job. A highly trained human focused on a specific task will often beat an LLM, especially if that task is long running, requires connecting multiple systems, or demands precise domain intuition. If you’re an expert and you’re handed a tool that does a mediocre version of your work, the overhead of fixing its mistakes can genuinely cost more than doing it yourself.
It changes what their job is. You go from doing the work yourself to managing something that does the work. The skills that got you hired (deep focus, precision, domain knowledge) aren’t necessarily the skills that make you good at that. That’s a disorienting shift.
It’s tied to self worth. Work accounts for the majority of a person’s waking hours. When executives talk about AI making everyone more productive, ICs can hear that as the things you’ve spent years getting good at are about to matter less. Whether or not that’s what’s actually being said, it’s a reasonable thing to feel.

One note: organizations that bias towards speed over quality tend to see more IC adoption of AI (e.g. my network of engineers at startups are on the whole adopting AI and using it to speed quite a few things up, though not necessarily making things higher quality). Organizations that bias towards quality often see the opposite. AI doesn’t really make quality higher, or it’s quite difficult to make it do so, and it can sometimes make quality on specific tasks worse because these ICs are typically really well trained for their specific task.

So where does the friction come from?

The difference in AI perception comes down to what work looks like at different parts of the stack. Executives manage non-deterministic systems and have built their careers around it. ICs operate in a more deterministic world and are evaluated on their ability to deliver precise, reliable output. AI fits neatly into the first worldview and awkwardly into the second.

I think this framing explains a lot of the friction that shows up when companies try to roll out AI adoption broadly. The same tool looks fundamentally different depending on what your job actually asks of you.

Mamba-3

Sat, 21 Mar 2026 00:00:00 +0000

Mamba-3 just dropped yesterday. It’s a big milestone towards unseating the stranglehold that transformers have on the modern AI industry.

Mamba-3 is a state space model, and it’s fascinating because it uses an entirely different architecture from transformers (the tech that the big LLMs like Opus 4.6, GPT 5.4, Gemini 3, etc. are based on).

Transformers keep a huge memory layer called the KV cache: this essentially stores all the memory of everything previously said in a conversation when it is computing the next token. It needs this because that ability to look at previous history is core to how it’s able to reason well on large volumes of input data (this is called self-attention).

The downside of a transformer is that as you increase the number of inputs (the prefill phase where it’s reading your system prompt) and outputs (the decoding phase where it’s generating text), you’re increasing the KV cache with each new token. This means by default that transformers are quadratic in their memory constraints, so large inputs slow these models down dramatically over time. Of course the big labs have figured out clever ways to improve performance here, but the math of the base transformer still slows down over time.

Modern state space models (like Mamba) use a very different approach: they keep a single fixed-size hidden state $h$ that adjusts over time: $h_t = A_t \, h_{t-1} + B_t \, x_t$ (where $A_t$ and $B_t$ are data-dependent matrices generated on the fly based on the current input vector $x_t$). This allows the model to selectively choose what to remember and what to forget.

There’s a few magical things about state space models:

They’re much more efficient over long context because computation grows linearly in size (instead of quadratically). This is perfect for audio because there’s a huge amount of data in an audio file, much more than in text. This is one major reason why Cartesia is a leader in the audio space (their lab pioneered the modern state space models).
State space models can use linear algebra tricks to compute the prefill phase incredibly quickly. Notice that $h_1 = A_1 \, h_0 + B_1 \, x_1$ and $h_2 = A_2 \, h_1 + B_2 \, x_2$. This means that you can actually entirely skip the computation of the hidden state $h_1$ if you just use a bit of algebra:
$$h_2 = A_2 \, A_1 \, h_0 + A_2 \, B_1 \, x_1 + B_2 \, x_2$$
Previously, you would need to compute each token and feed that in as input into the next token, but with state space models, you can skip that and compute the last hidden state immediately. Then when you get to the decoding phase where you’re actually doing inference on the new tokens, the state space models switch over to computing the hidden states one at a time.

Mamba-3 in particular does some really interesting stuff to make inference more efficient. I think the team has correctly recognized that there’s a big shift happening in the world of AI: as coding models and LLMs more generally start to run larger and larger workloads, inference has started to become a bigger percentage of GPU usage. It used to be that labs would spend the majority of their GPU fleet on research and training, but now that AI is out in the wild and being used quite extensively, inference is much more important.

Mamba-3 has a few optimizations for this:

Multi-input, multi-output. Previous generations of Mamba models would calculate the output tokens one at a time, similar to what most transformer-based architectures do. But the researchers noticed that GPUs are mostly bottlenecked on moving memory from VRAM to the compute cores. So, they restructured the math to group multiple state updates together into a big matrix multiplication, forcing the GPU to do more math at once while it waits.
Complex numbers for memory. If you apply a real number multiple times, it can only go up or down. For example, if you multiply something by $0.9$ many times, that number will tend to zero. If you multiply by $1.1$ many times, that number will tend towards infinity. One problem of previous Mamba models was that if your memory only contains real numbers, you’ll either definitely forget something or definitely remember something given sufficient time.

Mamba-3 adds complex numbers to its memory, which can rotate in space. For example if you multiply $1$ by $i$ multiple times, you get back to $1$ after 4 multiplications: $1 \cdot i = i$, $\; i \cdot i = -1$, $\; {-1} \cdot i = -i$, $\; {-i} \cdot i = 1$.

This means that Mamba-3 has the ability to track cycles, oscillatory patterns, etc.

It seems like the big labs are still mostly optimizing transformers, but hybrid models like AI21’s Jamba and Google’s Griffin already exist, and I bet that the next wave of models combining Mamba blocks and transformer blocks will be just around the corner.

Five opinions on building things well

Mon, 23 Oct 2023 00:00:00 +0000

I sometimes cringe at sharing my opinions (who cares about my opinions anyways), but I keep these around because back in college a similar “Opinions” section actually started some awesome conversations, so maybe it will in the future too. (These previously lived on a standalone page of this site — the first four date to October 2023, and the last was added in November 2025.)

Stay somewhere long enough to see legacy code

Most engineers change jobs frequently, but the best engineers I’ve known tend to stay somewhere for a long time. It can be difficult seeing your peers move to exciting, flashy companies with big salaries and titles, but I’ve found that staying in one place gives you deep wisdom and perspective.

The caveat here is that you need to find a good company (somewhere that is growing and where you trust the leadership team). If you’re able to find that, then:

You’ll learn how your decisions turned out. One of the key parts to learning is having a feedback cycle. If you don’t stay at a company long enough, you’ll never be able to see how the software you built turns out (whether good or bad).
You’ll constantly evolve yourself as the company changes. You’ll tend to be provided opportunities as a company grows that you might not have gotten if you were a new hire somewhere else.
You’ll gain confidence in making things happen. As you spend time building in your current environment, you’ll get better at it and start to understand what it takes to ship a product or feature.

Creativity should go to the right place

If you look at any of the tables that are still around from hundreds of years ago, you’ll notice they’re typically made the same way: mortise and tenon construction. Mortise and tenon joinery is simple and straightforward, but also strong and long-lasting. It’s been the gold standard for table construction for thousands of years.

The interesting thing is that while the construction method is typically the same, the style of antique furniture can be wildly different: from extremely ornate federal style furniture with marquetry and inlays of the 1700s to large, craftsman style pieces from the early 1900s.

Likewise, I believe the key to building timeless software is to build the bones of your system in a standard way, and to use your creativity in other areas. This means sticking with battle tested tooling (e.g. PostgreSQL) and innovating on solving user problems with your product.

It’s not “Speed vs. Quality”, it’s “Speed + Quality”

I think the biggest determinant of quality is the skill of the craftsperson, not the amount of time someone spends focusing on quality. On the margins, it’s true that if you spend more time on something, the output will tend to be higher quality. But I also think a skilled craftsperson tasked with creating a table is going to take far less time and produce a higher quality product than an unskilled craftsperson who is focusing extensively on the quality of the outcome.

In my belief, skill and expertise are such overriding determinants of final build quality that I think we should talk about the “Speed + Quality” combination, i.e. becoming more skillful so that you can finish things faster AND with higher quality.

Here’s an example: Frank Strazza, a well-known master woodworker, put on a dovetail demonstration at the Texas Woodworking Festival where he finished a set of half-blind dovetails in 15 minutes. The end result was far more pristine and high quality than something that would’ve taken an amateur woodworker over an hour to finish.

You’ll notice this in all disciplines: speed and quality are inherently linked. If you’re an amateur, you likely don’t have the ability to create something high quality yet. As you become more experienced, your work becomes higher quality because of your methods, tools, and general knowledge. It becomes easier and faster for you to complete work. At the same time, your minimum quality bar also increases and the work you output by default is higher quality.

Software engineering is no different. Take a look at Russ Cox’s PDF parsing library. He wrote this over a few weekends because he needed to parse some PDFs. The resulting library is still in use in many codebases (including Assembled’s) and is considered one of the main libraries for parsing PDFs in Golang.

All this is to say: build lots of stuff and continuously improve as you build. The more pieces of furniture you create, the more software you write, the better the overall quality of your output will be so long as you’re looking for feedback and constantly improving your techniques.

Beta fast, launch slow

At Stripe, there was a mantra that for new features, we should bring on beta users at 25% and launch at 98%. The idea was to focus early on product and idea validation, ensuring that you’re iterating as soon as possible with real users. This was paired with extremely high standards for a feature launch – we only fully launched the product to the public once all the kinks had been removed.

We use the same “Beta fast, launch slow” framework at Assembled to build high quality products that people actually want to use.

If no one is ever mad at you, you’re probably a bit too risk averse

If you’re trying to do anything meaningful, someone is going to be annoyed, uncomfortable, or outright mad at you sooner or later. If literally no one is ever upset with you, it might be a sign that you’re avoiding hard conversations, difficult tradeoffs, or ambitious bets.

When someone is mad, I’ve found it useful to pause and ask a couple of questions:

Are they mad at a specific action I took (something I did carelessly, unfairly, or without enough context)?
Or are they mad at what I represent (a change in direction, a standard I’m trying to uphold, a decision that breaks with the status quo)?

If they’re mad at my actions, there’s usually something I should fix, apologize for, or do better next time. If they’re mad at what I represent, there’s often at least a kernel of truth in the reaction, but it doesn’t automatically mean I should back down.