Skip to main con­tent

🚨 The Conservatives (EPP) are at­tempt­ing to force a new vote on Thursday (26th), seek­ing to re­verse Parliament’s NO on in­dis­crim­i­nate scan­ning. This is a di­rect at­tack on democ­racy and bla­tant dis­re­gard for your right to pri­vacy. No means no. Take ac­tion now!

After a team mem­ber sum­moned Copilot to cor­rect a typo in a PR of mine, Copilot edited my PR de­scrip­tion to in­clude and ad for it­self and Raycast.

This is hor­rific. I knew this kind of bull­shit would hap­pen even­tu­ally, but I did­n’t ex­pect it so soon.

Here is how plat­forms die: first, they are good to their users; then they abuse their users to make things bet­ter for their busi­ness cus­tomers; fi­nally, they abuse those busi­ness cus­tomers to claw back all the value for them­selves. Then, they die.

I’ve taken agency in the treat­ment of my bone can­cer (osteosarcoma in the T5 ver­te­brae of the up­per spine). After I’ve ran out of stan­dard of care treat­ment op­tions and there were no tri­als avail­able for me I’ve started do­ing: max­i­mum di­ag­nos­tics, cre­ated new treat­ments, started do­ing treat­ments in par­al­lel, and scal­ing this for oth­ers.

Elliot Hershberg wrote a great and ex­ten­sive ar­ti­cle about my can­cer jour­ney.

My can­cer jour­ney deck is em­bed­ded be­low, there also is a record­ing of an OpenAI Forum pre­sen­ta­tion. The com­pa­nies we are build­ing to scale this ap­proach for oth­ers can be found at evenone.ven­tures. Please scroll fur­ther on this page for my data and other in­for­ma­tion.

I think the med­ical in­dus­try can be more pa­tient first, see this great ar­ti­cle by Ruxandra https://​www.writ­in­gruxan­dra­bio.com/​p/​the-bu­reau­cracy-block­ing-the-chance

For my data please see https://​os­teosarc.com/ that in­cludes my treat­ment time­line and a data overview doc with 25TB of pub­licly read­able Google Cloud buck­ets.

Please sub­scribe to my mail­ing list

Linux gam­ing has come a long way. When Valve launched Proton back in 2018, it felt like a turn­ing point, turn­ing the Linux gam­ing ex­pe­ri­ence from “technically pos­si­ble if you’re okay with a lot of pain” to some­thing that more or less worked. Since then, we’ve seen in­cre­men­tal Wine re­leases, each one chip­ping away at com­pat­i­bil­ity is­sues and im­prov­ing per­for­mance bit by bit. Wine 10, Wine 9, and so on; each one a col­lec­tion of bug fixes and small im­prove­ments that kept the ecosys­tem mov­ing for­ward.

Wine 11 is dif­fer­ent. This is­n’t just an­other yearly re­lease with a few hun­dred bug fixes and some com­pat­i­bil­ity tweaks. It rep­re­sents a huge num­ber of changes and bug fixes. However, it also ships with NTSYNC sup­port, which is a fea­ture that has been years in the mak­ing and rewrites how Wine han­dles one of the most per­for­mance-sen­si­tive op­er­a­tions in mod­ern gam­ing. On top of that, the WoW64 ar­chi­tec­ture over­haul is fi­nally com­plete, the Wayland dri­ver has grown up a lot, and there’s a big list of smaller im­prove­ments that col­lec­tively make this feel like an all-new pro­ject.

I should be clear: not every game is go­ing to see a night-and-day dif­fer­ence. Some ti­tles will run iden­ti­cally to be­fore. But for the games that do ben­e­fit from these changes, the im­prove­ments range from no­tice­able to ab­surd. And be­cause Proton, SteamOS, and every down­stream pro­ject builds on top of Wine, those gains trickle down to every­one.

Everything up un­til now was a workaround

Esync and fsync worked, but they weren’t ideal

If you’ve spent any time tweak­ing Wine or Proton set­tings, you’ve prob­a­bly en­coun­tered the terms “esync” and “fsync” be­fore. Maybe you tog­gled them on in Lutris, or no­ticed them in Proton launch op­tions, with­out fully un­der­stand­ing what they do. To un­der­stand why NTSYNC mat­ters, you need to un­der­stand the prob­lem these so­lu­tions were all try­ing to solve.

Windows games, es­pe­cially mod­ern ones, are heav­ily multi-threaded. Your CPU is­n’t just run­ning one thing at a time, and in­stead, it’s jug­gling ren­der­ing, physics cal­cu­la­tions, as­set stream­ing, au­dio pro­cess­ing, AI rou­tines, and more, all in par­al­lel across mul­ti­ple threads. These threads need to co­or­di­nate with each other con­stantly. One thread might need to wait for an­other to fin­ish load­ing a tex­ture be­fore it can ren­der a frame. Another might need ex­clu­sive ac­cess to a shared re­source so two threads don’t try to mod­ify it si­mul­ta­ne­ously.

Windows han­dles this co­or­di­na­tion through what are called NT syn­chro­niza­tion prim­i­tives… mu­texes, sem­a­phores, events, and the like. They’re baked deep into the Windows ker­nel, and games rely on them heav­ily. The prob­lem is that Linux does­n’t have na­tive equiv­a­lents that be­have ex­actly the same way. Wine has his­tor­i­cally had to em­u­late these syn­chro­niza­tion mech­a­nisms, and the way it did so was, to put it sim­ply, not ideal.

The orig­i­nal ap­proach in­volved mak­ing a round-trip RPC call to a ded­i­cated “kernel” process called wine­server every sin­gle time a game needed to syn­chro­nize be­tween threads. For a game mak­ing thou­sands of these calls per sec­ond, that over­head added up fast and served to be a bot­tle­neck. And it was a bot­tle­neck that man­i­fested as sub­tle frame stut­ters, in­con­sis­tent frame pac­ing, and games that just felt a lit­tle bit off even when the raw FPS num­bers looked fine.

Esync was the first at­tempt at a workaround. Developed by Elizabeth Figura at CodeWeavers, it used Linux’s eventfd sys­tem call to han­dle syn­chro­niza­tion with­out bounc­ing through the wine­server. It worked, and it helped, but it had quirks. Some dis­tros ran into is­sues with file de­scrip­tor lim­its, since every syn­chro­niza­tion ob­ject needed its own file de­scrip­tor, and games that opened a lot of them could hit the sys­tem’s ceil­ing quite quickly.

Fsync came next, us­ing Linux fu­texes for even bet­ter per­for­mance. It was faster than esync in most cases, but it re­quired out-of-tree ker­nel patches that never made it into the main­line Linux ker­nel or to up­stream Wine out of the box. That meant you needed a cus­tom or patched ker­nel to use it, which is fine for en­thu­si­asts run­ning CachyOS or Proton-GE, but not ex­actly ac­ces­si­ble for the av­er­age user on Ubuntu or Fedora. Futex2, of­ten re­ferred to in­ter­change­ably with fsync, did make it to Linux ker­nel 5.16 as fu­tex_waitv, but the orig­i­nal im­ple­men­ta­tion of fsync is­n’t that. Fsync used fu­tex_wait­_­mul­ti­ple, and Futex2 used fu­tex_waitv. Applications such as Lutris still re­fer to it as Fsync, though. It’s still kind of fsync, but it’s not the orig­i­nal fsync.

Here’s the thing about both esync and fsync: they were workarounds. Clever ones, but workarounds nonethe­less. They ap­prox­i­mated NT syn­chro­niza­tion be­hav­ior us­ing Linux prim­i­tives that weren’t de­signed for the job, and cer­tain edge cases sim­ply could­n’t be han­dled cor­rectly. Operations like NtPulseEvent() and the “wait-for-all” mode in NtWaitForMultipleObjects() re­quire di­rect con­trol over the un­der­ly­ing wait queues in ways that user-space im­ple­men­ta­tions just can’t re­li­ably pro­vide.

Synchronization at the ker­nel-level, rather than in user-space

NTSYNC takes a com­pletely dif­fer­ent ap­proach. Instead of try­ing to shoe­horn Windows syn­chro­niza­tion be­hav­ior into ex­ist­ing Linux prim­i­tives, it adds a new ker­nel dri­ver that di­rectly mod­els the Windows NT syn­chro­niza­tion ob­ject API. It ex­poses a /dev/ntsync de­vice that Wine can talk to, and the ker­nel it­self han­dles the co­or­di­na­tion. No more round trips to wine­server, no more ap­prox­i­ma­tions, and the syn­chro­niza­tion hap­pens in the ker­nel, which is where it should be. And it has proper queue man­age­ment, proper event se­man­tics, and proper atomic op­er­a­tions.

What makes this even bet­ter is that NTSYNC was de­vel­oped by the same per­son who cre­ated esync and fsync in the first place. Elizabeth Figura has been work­ing on this prob­lem for years, it­er­at­ing through mul­ti­ple ker­nel patch re­vi­sions, pre­sent­ing the work at the Linux Plumbers Conference in 2023, and push­ing through mul­ti­ple ver­sions of the patch set be­fore it was fi­nally merged into the main­line Linux ker­nel with ver­sion 6.14.

The num­bers are wild. In de­vel­oper bench­marks, Dirt 3 went from 110.6 FPS to 860.7 FPS, which is an im­pres­sive 678% im­prove­ment. Resident Evil 2 jumped from 26 FPS to 77 FPS. Call of Juarez went from 99.8 FPS to 224.1 FPS. Tiny Tina’s Wonderlands saw gains from 130 FPS to 360 FPS. As well, Call of Duty: Black Ops I is now ac­tu­ally playable on Linux, too. Those bench­marks com­pare Wine NTSYNC against up­stream vanilla Wine, which means there’s no fsync or esync ei­ther. Gamers who use fsync are not go­ing to see such a leap in per­for­mance in most games.

The games that ben­e­fit most from NTSYNC are the ones that were strug­gling be­fore, such as ti­tles with heavy multi-threaded work­loads where the syn­chro­niza­tion over­head was a gen­uine bot­tle­neck. For those games, the dif­fer­ence is night and day. And un­like fsync, NTSYNC is in the main­line ker­nel, mean­ing you don’t need any cus­tom patches or out-of-tree mod­ules for it work. Any dis­tro ship­ping ker­nel 6.14 or later, which at this point in­cludes Fedora 42, Ubuntu 25.04, and more re­cent re­leases, will sup­port it. Valve has al­ready added the NTSYNC ker­nel dri­ver to SteamOS 3.7.20 beta, load­ing the mod­ule by de­fault, and an un­of­fi­cial Proton fork, Proton GE, al­ready has it en­abled. When Valve’s of­fi­cial Proton re­bases on Wine 11, every Steam Deck owner gets this for free.

All of this is what makes NTSYNC such a big deal, as it’s not sim­ply a run-of-the-mill per­for­mance patch. Instead, it’s some­thing much big­ger: this is the first time Wine’s syn­chro­niza­tion has been cor­rect at the ker­nel level, im­ple­mented in the main­line Linux ker­nel, and avail­able to every­one with­out jump­ing through hoops.

If NTSYNC is the head­line fea­ture, the com­ple­tion of Wine’s WoW64 ar­chi­tec­ture is the change that will qui­etly im­prove every­one’s life go­ing for­ward. On Windows, WoW64 (Windows 32-bit on Windows 64-bit) is the sub­sys­tem that lets 32-bit ap­pli­ca­tions run on 64-bit sys­tems. Wine has been work­ing to­ward its own im­ple­men­ta­tion of this for years, and Wine 11 marks the point where it’s of­fi­cially done.

What this means in prac­tice is that you no longer need 32-bit sys­tem li­braries in­stalled on your 64-bit Linux sys­tem to run 32-bit Windows ap­pli­ca­tions. Wine han­dles the trans­la­tion in­ter­nally, us­ing a sin­gle uni­fied bi­nary that au­to­mat­i­cally de­tects whether it’s deal­ing with a 32-bit or 64-bit ex­e­cutable. The old days of in­stalling mul­ti­lib pack­ages, con­fig­ur­ing ia32-libs, or fight­ing with 32-bit de­pen­den­cies on your 64-bit dis­tro thank­fully over.

This might sound like a small qual­ity-of-life im­prove­ment, but it’s a mas­sive piece of en­gi­neer­ing work. The WoW64 mode now han­dles OpenGL mem­ory map­pings, SCSI pass-through, and even 16-bit ap­pli­ca­tion sup­port. Yes, 16-bit! If you’ve got an­cient Windows soft­ware from the ’90s that you need to run for what­ever rea­son, Wine 11 has you cov­ered.

For gam­ing specif­i­cally, this mat­ters be­cause a sur­pris­ing num­ber of games, es­pe­cially older ones, are 32-bit ex­e­cuta­bles. Previously, get­ting these to work of­ten meant wrestling with your dis­tro’s mul­ti­lib setup, which var­ied in qual­ity and ease de­pend­ing on whether you were on Ubuntu, Arch, Fedora, or some­thing else en­tirely. Now, Wine just han­dles it for you.

The rest of Wine 11 is­n’t just filler

There are more fixes, too

It’s easy to let NTSYNC and WoW64 steal the spot­light, but Wine 11 is packed to the gills with other stuff worth talk­ing about.

The Wayland dri­ver has come a long way. Clipboard sup­port now works bidi­rec­tion­ally be­tween Wine and na­tive Wayland ap­pli­ca­tions, which is one of those things you don’t think about un­til it does­n’t work and it dri­ves you mad. Drag-and-drop from Wayland apps into Wine win­dows is sup­ported. Display mode changes are now em­u­lated through com­pos­i­tor scal­ing, which means older games that try to switch to lower res­o­lu­tions like 640x480 ac­tu­ally be­have prop­erly in­stead of leav­ing you with a bro­ken desk­top. If you’ve been hold­ing off on switch­ing from X11 to Wayland be­cause of Wine com­pat­i­bil­ity con­cerns, Wine 11 re­moves a lot of those bar­ri­ers.

On the graph­ics front, EGL is now the de­fault back­end for OpenGL ren­der­ing on X11, re­plac­ing the older GLX path. Vulkan sup­port has been bumped to API ver­sion 1.4, and there’s ini­tial sup­port for hard­ware-ac­cel­er­ated H.264 de­cod­ing through Direct3D 11 video APIs us­ing Vulkan Video. That last one is par­tic­u­larly in­ter­est­ing for games and ap­pli­ca­tions that use video play­back for things like cutscenes or in-game stream­ing.

Force feed­back sup­port has been im­proved for rac­ing wheels and flight sticks, which is great news if you’re run­ning a sim setup on Linux. As well, Bluetooth has re­ceived a new dri­ver with BLE ser­vices and proper pair­ing sup­port, MIDI sound­font han­dling has been im­proved for legacy game mu­sic, and there are a cou­ple of mi­nor ex­tras like Zip64 com­pres­sion sup­port, Unicode 17.0.0 sup­port, TWAIN 2.0 scan­ning for 64-bit apps, and IPv6 ping func­tion­al­ity.

Thread pri­or­ity man­age­ment has been im­proved on both Linux and ma­cOS, which helps with multi-threaded ap­pli­ca­tion per­for­mance be­yond just the NTSYNC gains. ARM64 de­vices can now sim­u­late 4K page sizes on sys­tems with larger na­tive pages, which keeps the door open for Wine on Arm hard­ware. And with more Arm-based Linux de­vices show­ing up every year, that mat­ters more than it used to.

Plus, there are a ton of bug fixes. Games like Nioh 2, StarCraft 2, The Witcher 2, Call of Duty: Black Ops II, Final Fantasy XI, and Battle.net all re­ceived spe­cific com­pat­i­bil­ity fixes, which is ad­di­tional to the broader im­prove­ments made across the board that will im­prove per­for­mance and com­pat­i­bil­ity across sig­nif­i­cantly more ti­tles.

Wine 11 is a big re­lease, and it’s not just NTSYNC that makes it the case. Sure, NTSYNC alone would have made it worth pay­ing at­ten­tion to, but com­bined with the WoW64 com­ple­tion, the Wayland im­prove­ments, and the sheer vol­ume of fixes, it’s the most im­por­tant Wine re­lease since Proton made Linux gam­ing vi­able. Everything built on top of Wine, from Proton to Lutris to Bottles, gets bet­ter be­cause of it. If you play games on Linux at all, Wine 11 is worth your time try­ing out.

It’s been about a year since cod­ing agents ap­peared on the scene that could ac­tu­ally build you full pro­jects. There were pre­cur­sors like Aider and early Cursor, but they were more as­sis­tant than agent. The new gen­er­a­tion is en­tic­ing, and a lot of us have spent a lot of free time build­ing all the pro­jects we al­ways wanted to build but never had time to.

And I think that’s fine. Spending your free time build­ing things is su­per en­joy­able, and most of the time you don’t re­ally have to care about code qual­ity and main­tain­abil­ity. It also gives you a way to learn a new tech stack if you so want.

During the Christmas break, both Anthropic and OpenAI handed out some free­bies to hook peo­ple to their ad­dic­tive slot ma­chines. For many, it was the first time they ex­pe­ri­enced the magic of agen­tic cod­ing. The fold’s get­ting big­ger.

Coding agents are now also in­tro­duced to pro­duc­tion code­bases. After 12 months, we are now be­gin­ning to see the ef­fects of all that “progress”. Here’s my cur­rent view.

While all of this is anec­do­tal, it sure feels like soft­ware has be­come a brit­tle mess, with 98% up­time be­com­ing the norm in­stead of the ex­cep­tion, in­clud­ing for big ser­vices. And user in­ter­faces have the weird­est fuck­ing bugs that you’d think a QA team would catch. I give you that that’s been the case for longer than agents ex­ist. But we seem to be ac­cel­er­at­ing.

We don’t have ac­cess to the in­ter­nals of com­pa­nies. But every now and then some­thing slips through to some news re­porter. Like this sup­posed AI caused out­age at AWS. Which AWS im­me­di­ately “corrected”. Only to then fol­low up in­ter­nally with a 90-day re­set.

Satya Nadella, the CEO of Microsoft, has been go­ing on about how much code is now be­ing writ­ten by AI at Microsoft. While we don’t have di­rect ev­i­dence, there sure is a feel­ing that Windows is go­ing down the shit­ter. Microsoft it­self seems to agree, based on this fine blog post.

Companies claim­ing 100% of their pro­duc­t’s code is now writ­ten by AI con­sis­tently put out the worst garbage you can imag­ine. Not point­ing fin­gers, but mem­ory leaks in the gi­ga­bytes, UI glitches, bro­ken-ass fea­tures, crashes: that is not the seal of qual­ity they think it is. And it’s def­i­nitely not good ad­ver­tis­ing for the fever dream of hav­ing your agents do all the work for you.

Through the grapevine you hear more and more peo­ple, from soft­ware com­pa­nies small and large, say­ing they have agen­ti­cally coded them­selves into a cor­ner. No code re­view, de­sign de­ci­sions del­e­gated to the agent, a gazil­lion fea­tures no­body asked for. That’ll do it.

We have ba­si­cally given up all dis­ci­pline and agency for a sort of ad­dic­tion, where your high­est goal is to pro­duce the largest amount of code in the short­est amount of time. Consequences be damned.

You’re build­ing an or­ches­tra­tion layer to com­mand an army of au­tonomous agents. You in­stalled Beads, com­pletely obliv­i­ous to the fact that it’s ba­si­cally unin­stal­lable mal­ware. The in­ter­net told you to. That’s how you should work or you’re ngmi. You’re ral­ph­ing the loop. Look, Anthropic built a C com­piler with an agent swarm. It’s kind of bro­ken, but surely the next gen­er­a­tion of LLMs can fix it. Oh my god, Cursor built a browser with a bat­tal­ion of agents. Yes, of course, it’s not re­ally work­ing and it needed a hu­man to spin the wheel a lit­tle bit every now and then. But surely the next gen­er­a­tion of LLMs will fix it. Pinky promise! Distribute, di­vide and con­quer, au­ton­omy, dark fac­to­ries, soft­ware is solved in the next 6 months. SaaS is dead, my grandma just had her Claw build her own Shopify!

Now again, this can work for your side pro­ject barely any­one is us­ing, in­clud­ing your­self. And hey, maybe there’s some­body out there who can ac­tu­ally make this work for a soft­ware prod­uct that’s not a steam­ing pile of garbage and is used by ac­tual hu­mans in anger.

If that’s you, more power to you. But at least among my cir­cle of peers I have yet to find ev­i­dence that this kind of shit works. Maybe we all have skill is­sues.

The prob­lem with agents is that they make er­rors. Which is fine, hu­mans also make er­rors. Maybe they are just cor­rect­ness er­rors. Easy to iden­tify and fix. Add a re­gres­sion test on top for bonus points. Or maybe it’s a code smell your lin­ter does­n’t catch. A use­less method here, a type that does­n’t make sense, du­pli­cated code over there. On their own, these are harm­less. A hu­man will also do such boo­boos.

But clankers aren’t hu­mans. A hu­man makes the same er­ror a few times. Eventually they learn not to make it again. Either be­cause some­one starts scream­ing at them or be­cause they’re on a gen­uine learn­ing path.

An agent has no such learn­ing abil­ity. At least not out of the box. It will con­tinue mak­ing the same er­rors over and over again. Depending on the train­ing data it might also come up with glo­ri­ous new in­ter­po­la­tions of dif­fer­ent er­rors.

Now you can try to teach your agent. Tell it to not make that boo­boo again in your AGENTS.md. Concoct the most com­plex mem­ory sys­tem and have it look up pre­vi­ous er­rors and best prac­tices. And that can be ef­fec­tive for a spe­cific cat­e­gory of er­rors. But it also re­quires you to ac­tu­ally ob­serve the agent mak­ing that er­ror.

There’s a much more im­por­tant dif­fer­ence be­tween clanker and hu­man. A hu­man is a bot­tle­neck. A hu­man can­not shit out 20,000 lines of code in a few hours. Even if the hu­man cre­ates such boo­boos at high fre­quency, there’s only so many boo­boos the hu­man can in­tro­duce in a code­base per day. The boo­boos will com­pound at a very slow rate. Usually, if the boo­boo pain gets too big, the hu­man, who hates pain, will spend some time fix­ing up the boo­boos. Or the hu­man gets fired and some­one else fixes up the boo­boos. So the pain goes away.

With an or­ches­trated army of agents, there is no bot­tle­neck, no hu­man pain. These tiny lit­tle harm­less boo­boos sud­denly com­pound at a rate that’s un­sus­tain­able. You have re­moved your­self from the loop, so you don’t even know that all the in­no­cent boo­boos have formed a mon­ster of a code­base. You only feel the pain when it’s too late.

Then one day you turn around and want to add a new fea­ture. But the ar­chi­tec­ture, which is largely boo­boos at this point, does­n’t al­low your army of agents to make the change in a func­tion­ing way. Or your users are scream­ing at you be­cause some­thing in the lat­est re­lease broke and deleted some user data.

You re­al­ize you can no longer trust the code­base. Worse, you re­al­ize that the gazil­lions of unit, snap­shot, and e2e tests you had your clankers write are equally un­trust­wor­thy. The only thing that’s still a re­li­able mea­sure of “does this work” is man­u­ally test­ing the prod­uct. Congrats, you fucked your­self (and your com­pany).

You have zero fuck­ing idea what’s go­ing on be­cause you del­e­gated all your agency to your agents. You let them run free, and they are mer­chants of com­plex­ity. They have seen many bad ar­chi­tec­tural de­ci­sions in their train­ing data and through­out their RL train­ing. You have told them to ar­chi­tect your ap­pli­ca­tion. Guess what the re­sult is?

An im­mense amount of com­plex­ity, an amal­gam of ter­ri­ble cargo cult “industry best prac­tices”, that you did­n’t rein in be­fore it was too late. But it’s worse than that.

Your agents never see each oth­er’s runs, never get to see all of your code­base, never get to see all the de­ci­sions that were made by you or other agents be­fore they make a change. As such, an agen­t’s de­ci­sions are al­ways lo­cal, which leads to the ex­act boo­boos de­scribed above. Immense amounts of code du­pli­ca­tion, ab­strac­tions for ab­strac­tions’ sake.

All of this com­pounds into an un­re­cov­er­able mess of com­plex­ity. The ex­act same mess you find in hu­man-made en­ter­prise code­bases. Those ar­rive at that state be­cause the pain is dis­trib­uted over a mas­sive amount of peo­ple. The in­di­vid­ual suf­fer­ing does­n’t pass the thresh­old of “I need to fix this”. The in­di­vid­ual might not even have the means to fix things. And or­ga­ni­za­tions have su­per high pain tol­er­ance. But hu­man-made en­ter­prise code­bases take years to get there. The or­ga­ni­za­tion slowly evolves along with the com­plex­ity in a de­mented kind of syn­ergy and learns how to deal with it.

With agents and a team of 2 hu­mans, you can get to that com­plex­ity within weeks.

So now you hope your agents can fix the mess, refac­tor it, make it pris­tine. But your agents can also no longer deal with it. Because the code­base and com­plex­ity are too big, and they only ever have a lo­cal view of the mess.

And I’m not just talk­ing about con­text win­dow size or long con­text at­ten­tion mech­a­nisms fail­ing at the sight of a 1 mil­lion lines of code mon­ster. Those are ob­vi­ous tech­ni­cal lim­i­ta­tions. It’s more de­vi­ous than that.

Before your agent can try and help fix the mess, it needs to find all the code that needs chang­ing and all ex­ist­ing code it can reuse. We call that agen­tic search. How the agent does that de­pends on the tools it has. You can give it a Bash tool so it can rip­grep its way through the code­base. You can give it some queryable code­base in­dex, an LSP server, a vec­tor data­base. In the end it does­n’t mat­ter much. The big­ger the code­base, the lower the re­call. Low re­call means that your agent will, in fact, not find all the code it needs to do a good job.

This is also why those code smell boo­boos hap­pen in the first place. The agent misses ex­ist­ing code, du­pli­cates things, in­tro­duces in­con­sis­ten­cies. And then they blos­som into a beau­ti­ful shit flower of com­plex­ity.

How do we avoid all of this?

Coding agents are sirens, lur­ing you in with their speed of code gen­er­a­tion and jagged in­tel­li­gence, of­ten com­plet­ing a sim­ple task with high qual­ity at break­neck ve­loc­ity. Things start falling apart when you think: “Oh golly, this thing is great. Computer, do my work!”.

There’s noth­ing wrong with del­e­gat­ing tasks to agents, ob­vi­ously. Good agent tasks share a few prop­er­ties: they can be scoped so the agent does­n’t need to un­der­stand the full sys­tem. The loop can be closed, that is, the agent has a way to eval­u­ate its own work. The out­put is­n’t mis­sion crit­i­cal, just some ad hoc tool or in­ter­nal piece of soft­ware no­body’s life or rev­enue de­pends on. Or you just need a rub­ber duck to bounce ideas against, which ba­si­cally means bounc­ing your idea against the com­pressed wis­dom of the in­ter­net and syn­thetic train­ing data. If any of that ap­plies, you found the per­fect task for the agent, pro­vided that you as the hu­man are the fi­nal qual­ity gate.

Karpathy’s auto-re­search ap­plied to speed­ing up startup time of your app? Great! As long as you un­der­stand that the code it spits out is not pro­duc­tion-ready at all. Auto-research works be­cause you give it an eval­u­a­tion func­tion that lets the agent mea­sure its work against some met­ric, like startup time or loss. But that eval­u­a­tion func­tion only cap­tures a very nar­row met­ric. The agent will hap­pily ig­nore any met­rics not cap­tured by the eval­u­a­tion func­tion, such as code qual­ity, com­plex­ity, or even cor­rect­ness, if your eval­u­a­tion func­tion is foo­bar.

The point is: let the agent do the bor­ing stuff, the stuff that won’t teach you any­thing new, or try out dif­fer­ent things you’d oth­er­wise not have time for. Then you eval­u­ate what it came up with, take the ideas that are ac­tu­ally rea­son­able and cor­rect, and fi­nal­ize the im­ple­men­ta­tion. Yes, sure, you can also use an agent for that fi­nal step.

And I would like to sug­gest that slow­ing the fuck down is the way to go. Give your­self time to think about what you’re ac­tu­ally build­ing and why. Give your­self an op­por­tu­nity to say, fuck no, we don’t need this. Set your­self lim­its on how much code you let the clanker gen­er­ate per day, in line with your abil­ity to ac­tu­ally re­view the code.

Anything that de­fines the gestalt of your sys­tem, that is ar­chi­tec­ture, API, and so on, write it by hand. Maybe use tab com­ple­tion for some nos­tal­gic feels. Or do some pair pro­gram­ming with your agent. Be in the code. Because the sim­ple act of hav­ing to write the thing or see­ing it be­ing built up step by step in­tro­duces fric­tion that al­lows you to bet­ter un­der­stand what you want to build and how the sys­tem “feels”. This is where your ex­pe­ri­ence and taste come in, some­thing the cur­rent SOTA mod­els sim­ply can­not yet re­place. And slow­ing the fuck down and suf­fer­ing some fric­tion is what al­lows you to learn and grow.

The end re­sult will be sys­tems and code­bases that con­tinue to be main­tain­able, at least as main­tain­able as our old sys­tems be­fore agents. Yes, those were not per­fect ei­ther. Your users will thank you, as your prod­uct now sparks joy in­stead of slop. You’ll build fewer fea­tures, but the right ones. Learning to say no is a fea­ture in it­self.

You can sleep well know­ing that you still have an idea what the fuck is go­ing on, and that you have agency. Your un­der­stand­ing al­lows you to fix the re­call prob­lem of agen­tic search, lead­ing to bet­ter clanker out­puts that need less mas­sag­ing. And if shit hits the fan, you are able to go in and fix it. Or if your ini­tial de­sign has been sub­op­ti­mal, you un­der­stand why it’s sub­op­ti­mal, and how to refac­tor it into some­thing bet­ter. With or with­out an agent, don’t fuck­ing care.

All of this re­quires dis­ci­pline and agency.

All of this re­quires hu­mans.

Microsoft just an­nounced a 7-point plan to fix Windows 11, and the tech press is treat­ing it like a re­demp­tion arc. Pavan Davuluri, the Windows pres­i­dent, ad­mit­ted in January 2026 that “Windows 11 had gone off track” and said Microsoft was en­ter­ing a mode called “swarming” where en­gi­neers would be pulled off new fea­tures to fix ex­ist­ing prob­lems.

I saw this head­line and my first thought was: it’s like be­ing in an abu­sive re­la­tion­ship. They beat you, then show up with flow­ers say­ing they’ve changed. And every­one around you says “see, they’re get­ting bet­ter.” But the bruises are still there and the apol­ogy only cov­ers the hits peo­ple no­ticed.

I want to walk through what Microsoft ac­tu­ally did to Windows 11 over the past four years, be­cause this “fix” an­nounce­ment only makes sense when you see the full dam­age list and re­al­ize that the worst of­fenses aren’t even part of the re­pair plan.

The Copilot in­va­sion started September 26, 2023, when Microsoft pushed their AI chat­bot into Windows 11 ahead of the for­mal 23H2 re­lease. The icon ap­peared be­tween your Start menu and sys­tem tray, you could­n’t move it, you could­n’t re­move it through nor­mal set­tings, and it hi­jacked the Win+C key­board short­cut. Over the next two years, Copilot but­tons metas­ta­sized into Snipping Tool, Photos, Notepad, Widgets, File Explorer con­text menus, Start menu search, and sys­tem Settings. Microsoft even planned to force-in­stall the Microsoft 365 Copilot app di­rectly onto Start menus of “eligible PCs.” The new plan promises to re­move all of that. They want credit for pulling their hand out of your pocket.

On April 24, 2024, Microsoft shipped up­date KB5036980, which in­jected ad­ver­tise­ments into the Windows 11 Start menu’s “Recommended” sec­tion. These showed up la­beled “Promoted” and pushed apps like Opera browser and some pass­word man­ager no­body asked for. And the Start menu was just one sur­face, they also placed ads on the lock screen, in the Settings home­page hawk­ing Game Pass sub­scrip­tions, in­side File Explorer push­ing OneDrive, and through “tip” no­ti­fi­ca­tions that were thinly veiled prod­uct pitches. The “fix” promises “fewer ads.” Fewer. The op­er­at­ing sys­tem you paid $139 for at re­tail should have ex­actly zero ads, and the fact that “fewer” is sup­posed to im­press any­one shows how thor­oughly Microsoft has low­ered the bar.

The pri­vacy an­gle is where this gets dan­ger­ous. When Windows 11 launched in October 2021, Home edi­tion re­quired a Microsoft ac­count dur­ing setup. By October 2025, Microsoft had sys­tem­at­i­cally hunted down and killed every sin­gle workaround for cre­at­ing a lo­cal ac­count, the `oobe\bypassnro` com­mand, the BypassNRO reg­istry tog­gle, the `ms-cxh:localonly` trick, even the old fake email method. Amanda Langowski from Microsoft stated it plainly: they were “removing known mech­a­nisms for cre­at­ing a lo­cal ac­count in the Windows Setup ex­pe­ri­ence.”

A Microsoft ac­count means your iden­tity is tied to your OS from first boot. Your ac­tiv­ity, your app us­age, your brows­ing through Edge, your files through OneDrive, all fun­neled into a pro­file Microsoft con­trols. And this par­tic­u­lar abuse is nowhere in the 7-point fix plan.

OneDrive got the same treat­ment. Microsoft silently changed Windows 11 setup in 2024 so that OneDrive folder backup en­ables au­to­mat­i­cally with no con­sent di­a­log, sync­ing your Desktop, Documents, Pictures, Music, and Videos to Microsoft’s cloud. When peo­ple dis­cov­ered this and tried to turn it off, their files dis­ap­peared from their lo­cal ma­chine be­cause OneDrive had moved them, trans­ferred own­er­ship of your per­sonal files to their cloud ser­vice with­out ask­ing. Author Jason Pargin went vi­ral de­scrib­ing how OneDrive ac­ti­vated it­self, moved his files, then started delet­ing them when he hit the free 5GB stor­age limit. Microsoft’s re­sponse to this was si­lence. Also not in the fix plan.

Windows Recall is worth lin­ger­ing on. Announced May 2024, it’s an AI fea­ture that screen­shots every­thing on your screen every few sec­onds and makes it search­able. Security re­searcher Kevin Beaumont demon­strated that the en­tire Recall data­base was stored in plain­text in an AppData folder where any mal­ware could ex­tract it. Bank num­bers, Social Security num­bers, pass­words, all sit­ting in an un­en­crypted SQLite data­base.

The UK’s Information Commissioner’s Office got in­volved. Microsoft de­layed it, made it opt-in, added en­cryp­tion, and qui­etly re­launched it for Insiders in November 2024. They built a sur­veil­lance fea­ture, shipped it bro­ken, got caught, and called the patch “responding to feed­back.”

But the abuse pat­tern goes back way fur­ther than Windows 11. In 2015 and 2016, Microsoft ran the GWX (Get Windows 10) cam­paign, full-screen nag di­alogs that pushed Windows 10 up­grades on Windows 7 and 8 users. In May 2016, they changed the be­hav­ior of the red X but­ton so that click­ing it, which for decades had meant “close” or “cancel”, in­stead sched­uled the Windows 10 up­grade. Microsoft’s own se­cu­rity ad­vice told users to close sus­pi­cious di­alogs us­ing the X but­ton, and they weaponized that trained be­hav­ior against their own cus­tomers. A woman named Teri Goldstein sued af­ter the forced up­grade bricked her travel agency PC and won $10,000. Microsoft ap­pealed, then dropped the ap­peal and paid. They even­tu­ally ad­mit­ted they “went too far.”

And right now, Microsoft is about to force 240 mil­lion PCs into the land­fill. Windows 10 hit end of life on October 14, 2025, and Windows 11 re­quires TPM 2.0, spe­cific CPU gen­er­a­tions, UEFI Secure Boot, hard­ware re­quire­ments that ex­cluded roughly 20% of all PCs world­wide. Perfectly func­tional ma­chines, ren­dered “obsolete” by ar­bi­trary soft­ware re­stric­tions. If you want to keep get­ting se­cu­rity patches on Windows 10, Microsoft will charge you $30 per year, pay­ing for patches to an op­er­at­ing sys­tem you al­ready bought a li­cense for. Enterprise cus­tomers pay $61 per de­vice for Year 1, $122 for Year 2, and $244 for Year 3, with the price dou­bling each year.

Edge is its own dis­as­ter. Mozilla com­mis­sioned an in­de­pen­dent re­port ti­tled “Over the Edge” that doc­u­mented spe­cific dark pat­terns in­clud­ing con­firmsham­ing (pop-ups im­ply­ing you’re “shopping in a dumb way” if you don’t use Edge), dis­guised ads in­jected into Google.com and the Chrome Web Store, and de­fault browser set­tings that hi­jack back to Edge with­out no­ti­fi­ca­tion. Certain Windows web links still force-open in Edge re­gard­less of your de­fault browser set­ting. Despite all this ma­nip­u­la­tion, Edge holds just 5.35% global mar­ket share. Even with the full weight of an op­er­at­ing sys­tem mo­nop­oly forc­ing their browser on peo­ple, al­most no­body chooses to use it.

And the teleme­try ques­tion. On Windows 11 Home and Pro, you can­not fully dis­able teleme­try. Setting `AllowTelemetry` to 0 in the reg­istry on non-En­ter­prise edi­tions gets silently over­rid­den back to 1. Only Enterprise and Education edi­tions can ac­tu­ally turn it off. The op­er­at­ing sys­tem you paid for re­ports data about you to Microsoft, and the set­ting to stop it is a lie on con­sumer edi­tions. Also not in the fix plan.

I haven’t even men­tioned the EU fin­ing Microsoft over 2.2 bil­lion eu­ros across mul­ti­ple an­titrust rul­ings, in­clud­ing 561 mil­lion eu­ros specif­i­cally for break­ing a browser bal­lot promise, a Windows 7 up­date silently re­moved the choice screen for 14 months, af­fect­ing 15 mil­lion users, and it was the first time the EU fined a com­pany for vi­o­lat­ing a “commitment de­ci­sion.” Or the _NSAKEY con­tro­versy from 1999 where a sec­ond crypto key la­beled lit­er­ally `_NSAKEY` was found em­bed­ded in Windows NT. Or the time in August 2024 when a Microsoft up­date bricked Linux dual-boot sys­tems across Ubuntu, Mint, and other dis­tros, and it took 9 months to fully fix.

Ok so here’s the table that tells the whole story:

The bot­tom four rows are the ones that mat­ter. The pri­vacy-hos­tile changes, the forced Microsoft ac­counts, the teleme­try that lies about be­ing dis­abled, OneDrive hi­jack­ing your files, the pre-in­stalled garbage, none of that is part of the fix plan. Microsoft’s “swarming” ef­fort tar­gets the most vis­i­ble UI an­noy­ances, the ones that gen­er­ate bad head­lines. Data col­lec­tion, ven­dor lock-in, forced ac­counts, those stay be­cause those are the rev­enue model.

Microsoft spent four years de­lib­er­ately de­grad­ing an op­er­at­ing sys­tem that peo­ple paid $139 or more for, and now they’re an­nounc­ing the re­moval of their own dam­age as if it’s a gift. The “fix” is them tak­ing their foot off your neck and ex­pect­ing ap­plause. The ads should have never been there, the Copilot but­tons should have never been forced, and the taskbar should have never been crip­pled in the first place. And the things they’re choos­ing to keep, the teleme­try, the forced ac­counts, the data har­vest­ing, those are the real prod­uct, be­cause at this point, you are.

Hello! This is a long, hope­fully fun one! If you’re read­ing this in your email, you may need to click “expand” to read all the way to the end of this post. Thank you!

When I lived in Nashville, my girl­friends and I would take our­selves on “field trips” across the state. We once went on a tour to spot bald ea­gles in West Tennessee, and upon ar­rival, a woman with fluffy hair in the state park bath­room told us she had seen 113 bald ea­gles the day be­fore. We ended up see­ing (counts on one hand)…2.

In the sum­mer of 2017, we went on an­other field trip to the National Park’s Manhattan Project Site in Oak Ridge, TN. In 1942, Oak Ridge, TN, was cho­sen as the site for a plu­to­nium and ura­nium en­rich­ment plant as part of the Manhattan Project, a top-se­cret WWII ef­fort to de­velop the first atomic bomb. Once a small and rural farm­ing com­mu­nity set­tled in the val­ley of East Tennessee, the swift task to cre­ate a nu­clear bomb grew the se­cret set­tle­ment ti­tled “Site X” from 3,000 peo­ple in 1942 to 75,000 by 1945. Alongside the pop­u­la­tion growth, enor­mously com­plex build­ings were built.

A Note: The Manhattan Project cre­ated the nu­clear bomb that caused ex­treme dev­as­ta­tion in Japan and ended the war. There’s a lot of U. S. his­tory that’s aw­ful and in­de­fen­si­ble. Today, though, I’d like to talk about the in­dus­trial de­sign and color the­ory from that era.

Our first stop on the tour was the X-10 Graphite Reactor room and its con­trol panel room. The X-10 Graphite Reactor, a 24-foot-square block of graphite, was the world’s sec­ond full-scale nu­clear re­ac­tor. The plu­to­nium pro­duced from ura­nium there was shipped to Los Alamos, New Mexico, for re­search into the atomic bomb Fat Man.

What caught my eye as a de­signer, as with most in­dus­trial plants and con­trol rooms of that time, be­sides the knobs, levers, and but­tons, was the use of a very spe­cific seafoam green, seen here on the re­ac­tor’s walls and in the con­trol panel room.

Thus be­gan my day-long search, traips­ing through the in­ter­net for his­tor­i­cal in­for­ma­tion about this spe­cific shade of seafoam green.

Thankfully, this path led me to the work of color the­o­rist Faber Birren.

In the fall of 1919, Faber Birren en­tered the Art Institute at the University of Chicago, only to drop out in the spring of 1921 to com­mit him­self to self-ed­u­ca­tion in color, as such a pro­gram did­n’t ex­ist. He spent his days in­ter­view­ing psy­chol­o­gists and physi­cists and con­ducted his own color stud­ies, which were con­sid­ered un­con­ven­tional at the time. He painted his bed­room walls red ver­mil­lion to test if it would make him go mad.

In 1933, he moved to New York City and be­came a self-ap­pointed color con­sul­tant, ap­proach­ing ma­jor cor­po­ra­tions to sell the idea that ap­pro­pri­ate use of color could boost sales. He con­vinced a Chicago whole­sale meat com­pany that the com­pa­ny’s white walls made the meat un­ap­peal­ing. He stud­ied the steaks on var­i­ous col­ored back­grounds and de­ter­mined that a blue/​green back­ground would make the beef ap­pear red­der. Sales went up, and soon a num­ber of in­dus­tries hired Faber to bring color the­ory into their work, in­clud­ing the lead­ing chem­i­cal and wartime con­tract com­pany, as well as the Manhattan Project build­ing de­signer, DuPont.

With the in­crease in wartime pro­duc­tion in the US dur­ing WWII, Birren and DuPont cre­ated a mas­ter color safety code for the in­dus­trial plant in­dus­try, with the aim of re­duc­ing ac­ci­dents and in­creas­ing ef­fi­ciency within plants. These color codes were ap­proved by the National Safety Council in 1944 and are now in­ter­na­tion­ally rec­og­nized, hav­ing been manda­tory prac­tice since 1948. The color cod­ing went as such:

* Fire Red: All fire pro­tec­tion, emer­gency stop but­tons, and flam­ma­ble liq­uids should be red

* Solar Yellow: Signifies cau­tion and phys­i­cal haz­ards such as falling

* Safety Green: Indicates safety fea­tures such as first-aid equip­ment, emer­gency ex­its, and eye­wash sta­tions.

* Light Green: Used on walls to re­duce vi­sual fa­tigue

My in­dus­trial “seafoam” light green mys­tery has fi­nally been solved thanks to this ar­ti­cle from UChicago Magazine.

Keeping in theme with “control rooms”, I re­searched the sec­ond Manhattan Project plant, the Hanford Site, home to the B Reactor, the first full-scale plu­to­nium pro­duc­tion re­ac­tor in the world. To my sur­prise, this site looked like an ode to Birren’s light green and color codes, which makes sense, since his client, DuPont, was also re­spon­si­ble for the de­sign and con­struc­tion of Hanford.

In Birren’s 1963 book Color for Interiors: Historical and Modern, he writes about re­search un­der­taken to mea­sure eye fa­tigue in the in­dus­trial work­place and the ef­fects of in­te­rior color on hu­man ef­fi­ciency and well-be­ing. Using the color chart above, he states that the proper use of color hues can re­duce ac­ci­dents, raise stan­dards of ma­chine main­te­nance, and im­prove la­bor morale.

“The im­por­tance of color in fac­to­ries is first to con­trol bright­ness in the gen­eral field of view for an ef­fi­cient see­ing con­di­tion. Interiors can then be con­di­tioned for emo­tional plea­sure and in­ter­est, us­ing warm, cool, or lu­mi­nois hues as work­ing con­di­tions sug­gest. Color should be func­tional and not merely dec­o­ra­tive.” - Faber Birren

Now, look­ing at the in­te­ri­ors of the Manhattan Project con­trol rooms and plants, the broad use of Light and Medium Green makes sense. One mis­take and mass dev­as­ta­tion could have oc­curred within these towns. Birren writes, “Note that most of the stan­dards are soft in tone. This is de­lib­er­ate and in­tended to es­tab­lish a non-dis­tract­ing en­vi­ron­ment. Green is a rest­ful and nat­ural-look­ing color for av­er­age fac­tory in­te­ri­ors. Light Green with Medium Green is sug­gested.”

Let’s put these the­o­ries to work with this photo of the B-Reactor room found at the Hanford Site of the Manhattan Project. In Birren’s book, he di­rected the fol­low­ing color ap­pli­ca­tions for small in­dus­trial ar­eas:

* ✔️ Medium Gray is pro­posed for ma­chin­ery, equip­ment, and racks

* ✔️ Beige walls may be ap­plied to in­te­ri­ors de­prived of nat­ural light

As we can see, his color the­ory was fol­lowed to a T.

Other US Industrial Plants that Used these Color Methods

This color the­ory re­search just opened a whole can of de­sign worms for me, and I’m ex­cited to dive into them more. For ex­am­ple, Germany de­vel­oped its own seafoam green, specif­i­cally de­signed for bridges, called Cologne Bridge Green. That’s a post for an­other day.

And fi­nally, if you en­joy this sort of de­sign, I de­signed a font called “Parts List” that is meant to evoke the feel­ing of sit­ting in an oil change wait­ing room, with the smell of burnt cof­fee. I cre­ated this font out of old auto parts lists, and it’s a per­fectly wob­bly type­face that will give you that ‘Is it a type­writer or hand­writ­ing?’ feel­ing. It’s now avail­able on my web­site.

PS: I have an old friend whose dad still works at the Uranium plant in Oak Ridge. I told him that I was sur­prised that al­most all of the fa­cil­i­ties had been torn down, and he just looked at me straight in the face and said, “Who said it’s ac­tu­ally gone?” Noted. ✌️

Thanks for be­ing here!

Every ChatGPT mes­sage trig­gers a Cloudflare Turnstile pro­gram that runs silently in your browser. I de­crypted 377 of these pro­grams from net­work traf­fic and found some­thing that goes be­yond stan­dard browser fin­ger­print­ing.

The pro­gram checks 55 prop­er­ties span­ning three lay­ers: your browser (GPU, screen, fonts), the Cloudflare net­work (your city, your IP, your re­gion from edge head­ers), and the ChatGPT React ap­pli­ca­tion it­self (__reactRouterContext, load­er­Data, client­Boot­strap). Turnstile does­n’t just ver­ify that you’re run­ning a real browser. It ver­i­fies that you’re run­ning a real browser that has fully booted a spe­cific React ap­pli­ca­tion.

A bot that spoofs browser fin­ger­prints but does­n’t ren­der the ac­tual ChatGPT SPA will fail.

The Turnstile byte­code ar­rives en­crypted. The server sends a field called turn­stile.dx in the pre­pare re­sponse: 28,000 char­ac­ters of base64 that change on every re­quest.

The outer layer is XOR’d with the p to­ken from the pre­pare re­quest. Both travel in the same HTTP ex­change, so de­crypt­ing it is straight­for­ward:

outer = json.loads(bytes(

base64de­code(dx)[i] ^ p_­to­ken[i % len(p_­to­ken)]

for i in range(len(base64de­code(dx)))

# → 89 VM in­struc­tions

Inside those 89 in­struc­tions, there is a 19KB en­crypted blob con­tain­ing the ac­tual fin­ger­print­ing pro­gram. This in­ner blob uses a dif­fer­ent XOR key that is not the p to­ken.

Initially I as­sumed this key was de­rived from per­for­mance.now() and was truly ephemeral. Then I looked at the byte­code more care­fully and found the key sit­ting in the in­struc­tions:

[41.02, 0.3, 22.58, 12.96, 97.35]

The last ar­gu­ment, 97.35, is the XOR key. A float lit­eral, gen­er­ated by the server, em­bed­ded in the byte­code it sent to the browser. I ver­i­fied this across 50 re­quests. Every time, the float from the in­struc­tion de­crypts the in­ner blob to valid JSON. 50 out of 50.

The full de­cryp­tion chain re­quires noth­ing be­yond the HTTP re­quest and re­sponse:

1. Read p from pre­pare re­quest

2. Read turn­stile.dx from pre­pare re­sponse

3. XOR(base64decode(dx), p) → outer byte­code

4. Find the 5-arg in­struc­tion af­ter the 19KB blob → last arg is the key

5. XOR(base64decode(blob), str(key)) → in­ner pro­gram (417-580 VM in­struc­tions)

The key is in the pay­load.

Each in­ner pro­gram uses a cus­tom VM with 28 op­codes (ADD, XOR, CALL, BTOA, RESOLVE, BIND_METHOD, JSON_STRINGIFY, etc.) and ran­dom­ized float reg­is­ter ad­dresses that change per re­quest. I mapped the op­codes from the SDK source (sdk.js, 1,411 lines, de­ob­fus­cated).

The pro­gram col­lects 55 prop­er­ties. No vari­a­tion across 377 sam­ples. All 55, every time, or­ga­nized into three lay­ers:

Storage (5): stor­age, quota, es­ti­mate, setItem, us­age. Also writes the fin­ger­print to lo­cal­Stor­age un­der key 6f376b6560133c2c for per­sis­tence across page loads.

These are in­jected server-side by Cloudflare’s edge. They ex­ist only if the re­quest passed through Cloudflare’s net­work. A bot mak­ing di­rect re­quests to the ori­gin server or run­ning be­hind a non-Cloud­flare proxy will pro­duce miss­ing or in­con­sis­tent val­ues.

This is the part that mat­ters. __reactRouterContext is an in­ter­nal data struc­ture that React Router v6+ at­taches to the DOM. load­er­Data con­tains the route loader re­sults. client­Boot­strap is spe­cific to ChatGPT’s SSR hy­dra­tion.

These prop­er­ties only ex­ist if the ChatGPT React ap­pli­ca­tion has fully ren­dered and hy­drated. A head­less browser that loads the HTML but does­n’t ex­e­cute the JavaScript bun­dle won’t have them. A bot frame­work that stubs out browser APIs but does­n’t ac­tu­ally run React won’t have them.

This is bot de­tec­tion at the ap­pli­ca­tion layer, not the browser layer.

After col­lect­ing all 55 prop­er­ties, the pro­gram hits a 116-byte en­crypted blob that de­crypts to 4 fi­nal in­struc­tions:

[96.05, 3.99, 3.99], // JSON.stringify(fingerprint)

[22.58, 46.15, 57.34], // store

[33.34, 3.99, 74.43], // XOR(json, key)

[1.51, 56.88, 3.99] // RESOLVE → be­comes the to­ken

The fin­ger­print is JSON.stringify’d, XOR’d, and re­solved back to the par­ent. The re­sult is the OpenAI-Sentinel-Turnstile-Token header sent with every con­ver­sa­tion re­quest.

Turnstile is one of three chal­lenges. The other two:

Signal Orchestrator (271 in­struc­tions): Installs event lis­ten­ers for key­down, point­er­move, click, scroll, paste, and wheel. Monitors 36 win­dow.__oai_­so_* prop­er­ties track­ing key­stroke tim­ing, mouse ve­loc­ity, scroll pat­terns, idle time, and paste events. A be­hav­ioral bio­met­ric layer run­ning un­der­neath the fin­ger­print.

Proof of Work (25-field fin­ger­print + SHA-256 hash­cash): Difficulty is uni­form ran­dom (400K-500K), 72% solve un­der 5ms. Includes 7 bi­nary de­tec­tion flags (ai, cre­atePRNG, cache, solana, dump, InstallTrigger, data), all zero across 100% of 100 sam­ples. The PoW adds com­pute cost but is not the real de­fense.

The XOR key for the in­ner pro­gram is a server-gen­er­ated float em­bed­ded in the byte­code. Whoever gen­er­ated the turn­stile.dx knows the key. The pri­vacy bound­ary be­tween the user and the sys­tem op­er­a­tor is a pol­icy de­ci­sion, not a cryp­to­graphic one.

The ob­fus­ca­tion serves real op­er­a­tional pur­poses: it hides the fin­ger­print check­list from sta­tic analy­sis, pre­vents the web­site op­er­a­tor (OpenAI) from read­ing raw fin­ger­print val­ues with­out re­verse-en­gi­neer­ing the byte­code, makes each to­ken unique to pre­vent re­play, and al­lows Cloudflare to change what the pro­gram checks with­out any­one notic­ing.

But the “encryption” is XOR with a key that’s in the same data stream. It pre­vents ca­sual in­spec­tion. It does not pre­vent analy­sis.

No sys­tems were ac­cessed with­out au­tho­riza­tion. No in­di­vid­ual user data is dis­closed. All traf­fic was ob­served from con­sented par­tic­i­pants. The Sentinel SDK was beau­ti­fied and man­u­ally de­ob­fus­cated. All de­cryp­tion was per­formed of­fline us­ing Python.

Here are three sto­ries about the state of gam­bling in America.

In November 2025, two pitch­ers for the Cleveland Guardians, Emmanuel Clase and Luis Ortiz, were charged in a con­spir­acy for “rigging pitches.” Frankly, I had never heard of rigged pitches be­fore, but the fed­eral in­dict­ment de­scribes a scheme so sim­ple that it’s a mir­a­cle that this sort of thing does­n’t hap­pen all the time. Three years ago, a few cor­rupt bet­tors ap­proached the pitch­ers with a tan­ta­liz­ing deal: (1) We’ll bet that cer­tain pitches will be balls; (2) you throw those pitches into the dirt; (3) we’ll win the bets and give you some money.

The plan worked. Why would­n’t it? There are hun­dreds of pitches thrown in a base­ball game, and no­body cares about one bad pitch. The bets were so de­vi­ously clever be­cause they of­fered enor­mous re­wards for bet­tors and only in­ci­den­tal in­con­ve­nience for play­ers and view­ers. Before their plan was snuffed out, the fraud­sters won $450,000 from pitches that not even the most ar­dent Cleveland base­ball fan would ever re­mem­ber the next day. Nobody watch­ing America’s pas­time could have guessed that they were wit­ness­ing a six-fig­ure fraud.

On the morn­ing of February 28th, some­one logged onto the pre­dic­tion mar­ket web­site Polymarket and made an un­usu­ally large bet. This bet was­n’t placed on a base­ball game. It was­n’t placed on any sport. This was a bet that the United States would bomb Iran on a spe­cific day, de­spite ex­tremely low odds of such a thing hap­pen­ing.

A few hours later, bombs landed in Iran. This one bet was part of a $553,000 pay­day for a user named “Magamyman.” And it was just one of dozens of sus­pi­cious, per­fectly-timed wa­gers, to­tal­ing mil­lions of dol­lars, placed in the hours be­fore a war be­gan.

It is al­most im­pos­si­ble to be­lieve that, who­ever Magamyman is, he did­n’t have in­side in­for­ma­tion from mem­bers of the ad­min­is­tra­tion. The term war prof­i­teer­ing typ­i­cally refers to arms deal­ers who get rich from war. But we now live in a world not only where on­line bet­tors stand to profit from war, but also where key de­ci­sion mak­ers in gov­ern­ment have the tan­ta­liz­ing op­tions to make hun­dreds of thou­sands of dol­lars by syn­chro­niz­ing mil­i­tary en­gage­ments with their gam­bling po­si­tion.

On March 10, sev­eral days into the Iran War, the jour­nal­ist Emanuel Fabian re­ported that a war­head launched from Iran struck a site out­side Jerusalem.

Meanwhile on Polymarket, users had placed bets on the pre­cise lo­ca­tion of mis­sile strikes on March 10. Fabian’s ar­ti­cle was there­fore poised to de­ter­mine pay­outs of $14 mil­lion in bet­ting. As The Atlantic’s Charlie Warzel re­ported, bet­tors en­cour­aged him to rewrite his story to pro­duce the out­come that they’d bet on. Others threat­ened to make his life “miserable.”

A clever dystopian nov­el­ist might con­ceive of a fu­ture where poorly paid jour­nal­ists for news wires are of­fered six-fig­ure deals to re­port fic­tions that cash out bets from on­line pre­dic­tion mar­kets. But just how fan­ci­ful is that sce­nario when we have good rea­son to be­lieve that jour­nal­ists are al­ready be­ing pres­sured, bul­lied, and threat­ened to pub­lish spe­cific sto­ries that align with multi-thou­sand dol­lar bets about the fu­ture?

Put it all to­gether: rigged pitches, rigged war bets, and at­tempts to rig wartime jour­nal­ism. Without con­text, each story would sound like a wacky con­spir­acy the­ory. But these are not con­spir­acy the­o­ries. These are things that have hap­pened. These are con­spir­a­cies—full stop.

“If you’re not para­noid, you’re not pay­ing at­ten­tion” has his­tor­i­cally been one of those bumper­stick­ers you find on the back of a car with so many other bumper­stick­ers that you worry for the san­ity of its oc­cu­pants. But in this weird new re­al­ity where every event on the planet has a price, and be­hind every price is a shad­owy coun­ter­party, the jit­tery gam­bler’s para­noia—is what I’m watch­ing hap­pen­ing be­cause some­body more pow­er­ful than me bet on it?—is start­ing to seem, eerily, like a kind of per­verse com­mon sense.

What’s re­mark­able is not just the fact that on­line sports books have taken over sports, or that bet­ting mar­kets have metas­ta­sized in pol­i­tics and cul­ture, but the speed with which both have taken place.

For most of the last cen­tury, the ma­jor sports leagues were ve­he­mently against gam­bling, as the Atlantic staff writer McKay Coppins ex­plained in his re­cent fea­ture. In 1992, NFL com­mis­sioner Paul Tagliabue told Congress that “nothing has done more to de­spoil the games Americans play and watch than wide­spread gam­bling on them.” In 2012, NBA com­mis­sioner David Stern loudly threat­ened New Jersey Gov. Chris Christie for sign­ing a bill to le­gal­ize sports bet­ting in the Garden State, re­port­edly scream­ing, “we’re go­ing to come af­ter you with every­thing we’ve got.”

So much for that. Following the 2018 Supreme Court de­ci­sion Murphy vs. NCAA, sports gam­bling was un­leashed into the world, and the leagues haven’t looked back. Last year, the NFL saw $30 bil­lion gam­bled on foot­ball games, and the league it­self made half a bil­lion dol­lars in ad­ver­tis­ing, li­cens­ing, and data deals.

Nine years ago, Americans bet less than $5 bil­lion on sports. Last year, that num­ber rose to at least $160 bil­lion. Big num­bers mean noth­ing to me, so let me put that sta­tis­tic an­other way: $5 bil­lion is roughly the amount Americans spend an­nu­ally at coin-op­er­ated laun­dro­mats and $160 bil­lion is nearly what Americans spent last year on do­mes­tic air­line tick­ets. So, in a decade, the on­line sports gam­bling in­dus­try will have risen from the level of coin laun­dro­mats to ri­val the en­tire air­line in­dus­try.

And now here come the pre­dic­tion mar­kets, such as Polymarket and Kalshi, whose com­bined 2025 rev­enue came in around $50 bil­lion. “These pre­dic­tive mar­kets are the log­i­cal end­point of the on­line gam­bling boom,” Coppins told me on my pod­cast Plain English. “We have taught the en­tire American pop­u­la­tion how to gam­ble with sports. We’ve made it fric­tion­less and easy and put it on every­body’s phone. Why not ex­tend the logic and cul­ture of gam­bling to other seg­ments of American life?” He con­tin­ued:

Why not let peo­ple gam­ble on who’s go­ing to win the Oscar, when Taylor Swift’s wed­ding will be, how many peo­ple will be de­ported from the United States next year, when the Iranian regime will fall, whether a nu­clear weapon will be det­o­nated in the year 2026, or whether there will be a famine in Gaza? These are not things that I’m mak­ing up. These are all bets that you can make on these pre­dic­tive mar­kets.

Indeed, why not let peo­ple gam­ble on whether there will be a famine in Gaza? The mar­ket logic is cold and sim­ple: More bets means more in­for­ma­tion, and more in­for­ma­tional vol­ume is more ef­fi­ciency in the mar­ket­place of all fu­ture hap­pen­ings. But from an­other per­spec­tive—let’s call it, base­line moral­ity?—the trans­for­ma­tion of a famine into a wind­fall event for pre­scient bet­tors seems so grotesque as to re­quire no elab­o­ra­tion. One imag­ines a young man send­ing his 1099 doc­u­ments to a tax ac­coun­tant the fol­low­ing spring: “right, so here are my div­i­dends, these are the cap gains, and, oh yeah, here’s my $9,000 pay­out for to­tally nail­ing when all those kids would die.”

It is a com­fort­ing myth that dystopias hap­pen when ob­vi­ously bad ideas go too far. Comforting, be­cause it plays to our naive hope that the world can be di­vided into sta­tic cat­e­gories of good ver­sus evil and that once we stig­ma­tize all the bad peo­ple and ghet­toize all the bad ideas, some utopia will spring into view. But I think dystopias more likely hap­pen be­cause seem­ingly good ideas go too far. “Pleasure is bet­ter than pain” is a sen­si­ble no­tion, and a so­ci­ety de­voted to its im­pli­ca­tions cre­ated Brave New World. “Order is bet­ter than dis­or­der” sounds al­right to me, but a so­ci­ety de­voted to the most grotesque vi­sion of that prin­ci­ple takes us to 1984. Sports gam­bling is fun, and pre­dic­tion mar­kets can fore­cast fu­ture events. But ex­tended with­out guardrails or lim­i­ta­tions, those prin­ci­ples lead to a world where ubiq­ui­tous gam­bling leads to cheat­ing, cheat­ing leads to dis­trust, and dis­trust leads ul­ti­mately to cyn­i­cism or out­right dis­en­gage­ment.

“The cri­sis of au­thor­ity that has kind of al­ready vis­ited every other American in­sti­tu­tion in the last cou­ple of decades has ar­rived at pro­fes­sional sports,” Coppins said. Two-thirds of Americans now be­lieve that pro­fes­sional ath­letes some­times change their per­for­mance to in­flu­ence gam­bling out­comes. “Not to over­state it, but that’s a dis­as­ter,” he said. And not just for sports.

There are four rea­sons to worry about the ef­fect of gam­bling in sports and cul­ture.

The first is the risk to in­di­vid­ual bet­tors. Every time we cre­ate 1,000 new gam­blers, we cre­ate dozens of new ad­dicts and a hand­ful of new bank­rupt­cies. As I’ve re­ported, there is ev­i­dence that about one in five men un­der 25 is on the spec­trum of hav­ing a gam­bling prob­lem, and calls to the National Problem Gambling Helpline have roughly tripled since sports gam­bling was broadly le­gal­ized in 2018. Research from UCLA and USC found that bank­rupt­cies in­creased by 10 per­cent in states that le­gal­ized on­line sports bet­ting be­tween 2018 and 2023. People will some­times ask me what busi­ness I have wor­ry­ing about on­line gam­bling when peo­ple should be free to spend their money how­ever they like. My re­sponse is that wise rules place guardrails around eco­nomic ac­tiv­ity with a cer­tain rate of per­sonal harm. For al­co­hol, we have li­cens­ing re­quire­ments, min­i­mum drink­ing ages, bound­aries around hours of sale, and rules about pub­lic con­sump­tion. As al­co­hol con­sump­tion is de­clin­ing among young peo­ple, gam­bling is surg­ing; Gen Z has re­placed one (often fun) vice with a mean­ing­ful chance of ad­dic­tion with an­other (often fun) vice with a mean­ing­ful chance of ad­dic­tion. But whereas we have cen­turies of ex­pe­ri­ence cur­tail­ing ex­ces­sive drink­ing with rules and cus­toms, we are cur­rently in a free-for-all era of gam­bling.

The sec­ond risk is to in­di­vid­ual play­ers and prac­ti­tion­ers. One rea­son why sports com­mis­sion­ers might have wanted to keep gam­bling out of their busi­ness is that gam­blers turns some peo­ple into com­plete psy­chopaths, and that’s not a very nice ex­pe­ri­ence for folks on the re­ceiv­ing end of gam­bling-af­flicted psy­chopaths. In his fea­ture, McKay Coppins re­ports on the ex­pe­ri­ence of Caroline Garcia, a top-ranked ten­nis player, who said she re­ceived tor­rents of abu­sive mes­sages from gam­blers both for los­ing games and for win­ning games. “This has be­come a very com­mon ex­pe­ri­ence for ath­letes at the pro­fes­sional level, even at the col­lege level too,” Coppins said. As the ex­pe­ri­ence of jour­nal­ist Emanuel Fabian shows, gam­bling can turn or­di­nary peo­ple into mini mob bosses, who go around threat­en­ing play­ers and prac­ti­tion­ers who they be­lieve are cost­ing them thou­sands of dol­lars.

The third risk is to the in­tegrity of sports—or any other in­sti­tu­tion. At the end of 2025, in ad­di­tion to its in­dict­ment of the Cleveland Guardians pitch­ers, the FBI an­nounced 30 ar­rests in­volv­ing gam­bling schemes in the NBA. This cav­al­cade of ar­rests has dra­mat­i­cally re­duced trust in sports. Two-thirds of Americans now be­lieve that pro­fes­sional ath­letes change their per­for­mance to in­flu­ence gam­bling out­comes. It does not re­quire ex­tra­or­di­nary cre­ativ­ity to imag­ine how this prin­ci­ple could ex­tend to other do­mains and in­sti­tu­tions. If more peo­ple start to be­lieve that things only hap­pen in the world as a di­rect re­sult of shad­owy in­ter­ests in vast bet­ting mar­kets, it’s go­ing to be a per­ma­nent open sea­son for con­spir­acy the­o­ries.

The ul­ti­mate risk is al­most too dark to con­tem­plate in much de­tail. As the logic and cul­ture of casi­nos moves from sports to pol­i­tics, the scan­dals that have vis­ited base­ball and bas­ket­ball might soon ar­rive in pol­i­tics. Is it re­ally so un­be­liev­able that a politi­cian might tip off a friend, or as­suage an en­emy, by giv­ing them in­side in­for­ma­tion that would al­low them to profit on bet­ting mar­kets? Is it re­ally so in­cred­i­ble to be­lieve that a gov­ern­ment of­fi­cial would try to align pol­icy with a bet­ting po­si­tion that stood to earn them, or an al­lied group, hun­dreds of thou­sands of dol­lars? That is what a “rigged pitch” in pol­i­tics would look like. It’s not just wa­ger­ing on a pol­icy out­come that you sus­pect will hap­pen. It’s chang­ing pol­icy out­comes based on what can be wa­gered.

Gambling is flour­ish­ing be­cause it meets the needs of our mo­ment: a low-trust world, where lonely young peo­ple are seek­ing high-risk op­por­tu­ni­ties to launch them into wealth and com­fort. In such an en­vi­ron­ment, fi­nan­cial­iza­tion might seem to be the last form of civic par­tic­i­pa­tion that feels hon­est to a large por­tion of the coun­try. Voting is com­pro­mised, and polling is ma­nip­u­lated, and news is al­go­rith­mi­cally cu­rated. But a bet set­tles. A game ends. There is com­fort in that. In an un­cer­tain and il­leg­i­ble world, it does­n’t get much more cer­tain and leg­i­ble than this: You won, or you lost.

A 2023 Wall Street Journal poll found that Americans are pulling away from prac­ti­cally every value that once de­fined na­tional life—pa­tri­o­tism, re­li­gion, com­mu­nity, fam­ily. Young peo­ple care less than their par­ents about mar­riage, chil­dren, or faith. But na­ture, ab­hor­ring a vac­uum, is fill­ing the moral void left by re­treat­ing in­sti­tu­tions with the mar­ket. Money has be­come our fi­nal virtue.

I of­ten find my­self think­ing about the philoso­pher Alasdair MacIntyre, who ar­gued in the in­tro­duc­tion of After Virtue that moder­nity had de­stroyed the shared moral lan­guage once sup­plied by tra­di­tions and re­li­gion, leav­ing us with only the lan­guage of in­di­vid­ual pref­er­ence. Virtue did not dis­ap­pear, I think, so much as it died and was rein­car­nated as the mar­ket. It is now the mar­ket that tells us what things are worth, what events mat­ter, whose pre­dic­tions are cor­rect, who is win­ning, who counts. Money has, in a strange way, be­come the last moral ar­biter stand­ing—the fi­nal uni­ver­sal lan­guage that a plu­ral­is­tic, dis­trust­ful, post-in­sti­tu­tional so­ci­ety can use to com­mu­ni­cate with it­self.

As this moral vo­cab­u­lary scales across cul­ture, it also cor­rodes cul­ture. In sports, when you have money on a game, you’re not root­ing for a team. You’re root­ing for a propo­si­tion. The so­cial func­tion of fan­dom—shared iden­tity, in­her­ited loy­alty, some­thing larger than your­self—dis­solves into in­di­vid­ual risk. In pol­i­tics, I fear the con­se­quences will be worse. Prediction mar­kets can be use­ful for those who want to know the fu­ture, but their util­ity re­cruits par­tic­i­pants into a re­la­tion­ship with the news cy­cle that is ad­ver­sar­ial, and even mis­an­thropic. A young man bet­ting on a ter­ror­ist at­tack or a famine is not act­ing as a mere con­cerned cit­i­zen whose par­tic­i­pa­tion im­proves the ef­fi­ciency of global pre­dic­tion mar­kets. He’s just a dude, on his phone, alone in a room, choos­ing to root for death.

If that does­n’t bother you, I don’t know how to make it bother you. Based on eco­nomic and mar­ket ef­fi­ciency prin­ci­ples alone, this young man’s be­hav­ior is de­fen­si­ble. But there is moral­ity out­side of mar­kets. There is more to life than the ef­fi­ciency of in­for­ma­tion net­works. But will we re­dis­cover it, any time soon? Don’t bet on it.