Probably you al­ready saw how it all turned out. On the very same day that Altman of­fered pub­lic sup­port to Amodei, he signed a deal to take away Amodei’s busi­ness, with a deal that was­n’t all that dif­fer­ent. You can’t get more Altman than that.

But here’s the kicker: Per The New York Times,

Let that sink in. Altman had se­cretly been work­ing on the deal since Wednesday.

- be­fore he an­nounced his sup­port for Dario

- but af­ter Brockman had do­nated 25M to Trump’s PAC

It was all the­atre. Dario never had a chance.

It’s one thing for the gov­ern­ment to re­ject Anthropic’s terms—and en­tirely an­other to ban­ish them per­ma­nently and, ab­surdly and puni­tively de­clare them a sup­ply chain risk. Worse, they did it in fa­vor of some­one else who took pretty sim­i­lar terms and hap­pened to have given more cam­paign con­tri­bu­tions.

Anthropic de­serves a chance at EXACTLY the same terms; any­thing else reeks of cor­rup­tion.

I am no fan of Amodei. I think he of­ten over­hy­pes things, many of which I have pub­licly chal­lenged. The com­pany ripped off a lot of writer’s work (per the $1.5B set­tle­ment), and re­cently walked back its core safety pledge.

But I be­lieve in fair play. This was­n’t that.

It sure look like the US is tran­si­tion­ing from the for­mer to the lat­ter.

The en­gi­neer shipped seven fea­tures in a sin­gle sprint. DORA met­rics looked im­mac­u­late. The pro­mo­tion packet prac­ti­cally wrote it­self.

Six months later, an ar­chi­tec­tural change re­quired mod­i­fy­ing those fea­tures. No one on the team could ex­plain why cer­tain com­po­nents ex­isted or how they in­ter­acted. The en­gi­neer who built them stared at her own code like a stranger’s.

Code has be­come cheaper to pro­duce than to per­ceive.

When an en­gi­neer writes code man­u­ally, two par­al­lel processes oc­cur. The first is pro­duc­tion: char­ac­ters ap­pear in files, tests get writ­ten, sys­tems change. The sec­ond is ab­sorp­tion: men­tal mod­els form, edge cases be­come in­tu­itive, ar­chi­tec­tural re­la­tion­ships so­lid­ify into un­der­stand­ing. These processes are cou­pled. The act of typ­ing forces en­gage­ment. The fric­tion of im­ple­men­ta­tion cre­ates space for rea­son­ing.

AI-assisted de­vel­op­ment de­cou­ples these processes. A prompt gen­er­ates hun­dreds of lines in sec­onds. The en­gi­neer re­views, ad­justs, it­er­ates. Output ac­cel­er­ates. But ab­sorp­tion can­not ac­cel­er­ate pro­por­tion­ally. The cog­ni­tive work of truly un­der­stand­ing what was built, why it was built that way, and how it re­lates to every­thing else re­mains bounded by hu­man pro­cess­ing speed.

This gap be­tween out­put ve­loc­ity and com­pre­hen­sion ve­loc­ity is cog­ni­tive debt.

Unlike tech­ni­cal debt, which sur­faces through sys­tem fail­ures or main­te­nance costs, cog­ni­tive debt re­mains in­vis­i­ble to ve­loc­ity met­rics. The code works. The tests pass. The fea­tures ship. The deficit ex­ists only in the minds of the en­gi­neers who built the sys­tem, man­i­fest­ing as un­cer­tainty about their own work.

The debt is not truly in­vis­i­ble. It even­tu­ally ap­pears in re­li­a­bil­ity met­rics: Mean Time to Recovery stretches longer, Change Failure Rate creeps up­ward. But these are lag­ging in­di­ca­tors, sep­a­rated by months from the ve­loc­ity met­rics that drive quar­terly de­ci­sions. By the time MTTR sig­nals a prob­lem, the com­pre­hen­sion deficit has al­ready com­pounded.

Engineering per­for­mance sys­tems evolved to mea­sure ob­serv­able out­puts. Story points com­pleted. Features shipped. Commits merged. Review turn­around time. These met­rics emerged from an era when out­put and com­pre­hen­sion were tightly cou­pled, when ship­ping some­thing im­plied un­der­stand­ing some­thing.

The met­rics never mea­sured com­pre­hen­sion di­rectly be­cause com­pre­hen­sion was as­sumed. An en­gi­neer who shipped a fea­ture was pre­sumed to un­der­stand that fea­ture. The pre­sump­tion held be­cause the pro­duc­tion process it­self forced un­der­stand­ing.

That pre­sump­tion no longer holds. An en­gi­neer can now ship fea­tures while main­tain­ing only sur­face fa­mil­iar­ity with their im­ple­men­ta­tion. The fea­tures work. The met­rics reg­is­ter suc­cess. The or­ga­ni­za­tional knowl­edge that would tra­di­tion­ally ac­cu­mu­late along­side those fea­tures sim­ply does not form at the same rate.

Performance cal­i­bra­tion com­mit­tees see ve­loc­ity im­prove­ments. They do not see com­pre­hen­sion deficits. They can­not, be­cause no ar­ti­fact of the or­ga­ni­za­tional mea­sure­ment sys­tem cap­tures that di­men­sion.

The dis­cus­sion of cog­ni­tive debt typ­i­cally fo­cuses on the en­gi­neer who gen­er­ates code. The more acute prob­lem sits with the en­gi­neer who re­views it.

Code re­view evolved as a qual­ity gate. A se­nior en­gi­neer ex­am­ines a ju­nior en­gi­neer’s work, catch­ing er­rors, sug­gest­ing im­prove­ments, trans­fer­ring knowl­edge. The rate-lim­it­ing fac­tor was al­ways the ju­nior en­gi­neer’s out­put speed. Senior en­gi­neers could re­view faster than ju­niors could pro­duce.

AI-assisted de­vel­op­ment in­verts this re­la­tion­ship. A ju­nior en­gi­neer can now gen­er­ate code faster than a se­nior en­gi­neer can crit­i­cally au­dit it. The vol­ume of gen­er­ated code ex­ceeds the band­width avail­able for deep re­view. Something has to give, and typ­i­cally it is re­view depth.

The re­viewer faces an im­pos­si­ble choice. Maintain pre­vi­ous re­view stan­dards and be­come a bot­tle­neck that negates the ve­loc­ity gains AI pro­vides. Or ap­prove code at the rate it ar­rives and hope the tests catch what the re­view missed. Most choose the lat­ter, of­ten un­con­sciously, be­cause or­ga­ni­za­tional pres­sure fa­vors through­put.

This is where cog­ni­tive debt com­pounds fastest. The au­thor’s com­pre­hen­sion deficit might be re­cov­er­able through later en­gage­ment with the code. The re­view­er’s com­pre­hen­sion deficit prop­a­gates: they ap­proved code they do not fully un­der­stand, which now car­ries im­plicit en­dorse­ment. The or­ga­ni­za­tional as­sump­tion that re­viewed code is un­der­stood code no longer holds.

Engineers work­ing ex­ten­sively with AI tools re­port a spe­cific form of ex­haus­tion that dif­fers from tra­di­tional burnout. Traditional burnout emerges from sus­tained cog­ni­tive load, from hav­ing too much to hold in mind while solv­ing com­plex prob­lems. The new pat­tern emerges from some­thing closer to cog­ni­tive dis­con­nec­tion.

The work hap­pens quickly. Progress is vis­i­ble. But the en­gi­neer ex­pe­ri­ences a per­sis­tent sense of not quite grasp­ing their own out­put. They can ex­e­cute, but ex­pla­na­tion re­quires re­con­struc­tion. They can mod­ify, but pre­dic­tion be­comes un­re­li­able. The sys­tem they built feels slightly for­eign even as it func­tions cor­rectly.

This cre­ates a dis­tinc­tive psy­cho­log­i­cal state: high out­put com­bined with low con­fi­dence. Engineers pro­duce more while feel­ing less cer­tain about what they have pro­duced. In or­ga­ni­za­tions that stack-rank based on vis­i­ble out­put, this cre­ates pres­sure to con­tinue gen­er­at­ing de­spite the grow­ing un­cer­tainty.

The en­gi­neer who pauses to deeply un­der­stand what they built falls be­hind in ve­loc­ity met­rics. The en­gi­neer who pri­or­i­tizes through­put over com­pre­hen­sion meets their quar­terly ob­jec­tives. The in­cen­tive struc­ture se­lects for the be­hav­ior that ac­cel­er­ates cog­ni­tive debt ac­cu­mu­la­tion.

Knowledge in en­gi­neer­ing or­ga­ni­za­tions ex­ists in two forms. The first is ex­plicit: doc­u­men­ta­tion, de­sign doc­u­ments, recorded de­ci­sions. The sec­ond is tacit: un­der­stand­ing held in the minds of peo­ple who built and main­tained sys­tems over time. Tacit knowl­edge can­not be fully ex­ter­nal­ized be­cause much of it ex­ists as in­tu­ition, pat­tern recog­ni­tion, and con­tex­tual judg­ment that formed through di­rect en­gage­ment with the work.

When the peo­ple who built a sys­tem leave or ro­tate to new pro­jects, tacit knowl­edge walks out with them. Organizations tra­di­tion­ally re­plen­ished this knowl­edge through the nor­mal process of en­gi­neer­ing work. New en­gi­neers build­ing on ex­ist­ing sys­tems de­vel­oped their own tacit un­der­stand­ing through the fric­tion of im­ple­men­ta­tion.

AI-assisted de­vel­op­ment po­ten­tially short-cir­cuits this re­plen­ish­ment mech­a­nism. If new en­gi­neers can gen­er­ate work­ing mod­i­fi­ca­tions with­out de­vel­op­ing deep com­pre­hen­sion, they never form the tacit knowl­edge that would tra­di­tion­ally ac­cu­mu­late. The or­ga­ni­za­tion loses knowl­edge not just through at­tri­tion but through in­suf­fi­cient for­ma­tion.

This cre­ates a de­layed fail­ure mode. The sys­tem con­tin­ues to func­tion. New fea­tures con­tinue to ship. But the reser­voir of peo­ple who truly un­der­stand the sys­tem grad­u­ally de­pletes. When cir­cum­stances even­tu­ally re­quire that un­der­stand­ing, when some­thing breaks in an un­ex­pected way or re­quire­ments change in a way that de­mands ar­chi­tec­tural rea­son­ing, the or­ga­ni­za­tion dis­cov­ers the deficit.

The first in­volves the re­ver­sal of a nor­mally re­li­able heuris­tic. Engineers typ­i­cally trust code that has been in pro­duc­tion for years. If it sur­vived that long, it prob­a­bly works. The longer code ex­ists with­out caus­ing prob­lems, the more con­fi­dence it earns. AI-generated code in­verts this pat­tern. The longer it re­mains un­touched, the more dan­ger­ous it be­comes, be­cause the con­text win­dow of the hu­mans around it has closed com­pletely. Code that was barely un­der­stood when writ­ten be­comes en­tirely opaque af­ter the peo­ple who wrote it have moved on.

The sec­ond fail­ure mode sur­faces dur­ing in­ci­dents. An alert fires at 3:00 AM. The on-call en­gi­neer opens a sys­tem they did not build, gen­er­ated by tools they did not su­per­vise, doc­u­mented in ways that as­sume fa­mil­iar­ity they do not pos­sess. They are de­bug­ging a black box writ­ten by a black box. What would have been a ten-minute fix when some­one un­der­stood the sys­tem be­comes a four-hour foren­sic in­ves­ti­ga­tion when no one does. Multiply this across enough in­ci­dents and the ag­gre­gate cost ex­ceeds what­ever ve­loc­ity gains the AI-assisted de­vel­op­ment pro­vided.

The third fail­ure mode op­er­ates on a longer timescale. Junior en­gi­neers who rely pri­mar­ily on AI-assisted de­vel­op­ment never de­velop the in­tu­ition that comes from man­ual im­ple­men­ta­tion. They ship fea­tures with­out form­ing the scar tis­sue that in­forms ar­chi­tec­tural judg­ment. The or­ga­ni­za­tion is ef­fec­tively trad­ing its pipeline of fu­ture Staff Engineers for this quar­ter’s fea­ture de­liv­ery. The cost does not ap­pear in cur­rent head­count mod­els be­cause the peo­ple who would have be­come se­nior ar­chi­tects five years from now are not yet ab­sent. They sim­ply never form.

From the per­spec­tive of en­gi­neer­ing lead­er­ship, AI-assisted de­vel­op­ment pre­sents as pro­duc­tiv­ity gain. Teams ship faster. Roadmaps com­press. Headcount dis­cus­sions be­come more fa­vor­able. These are the ob­serv­able sig­nals that prop­a­gate up­ward through or­ga­ni­za­tional re­port­ing struc­tures.

The cog­ni­tive debt ac­cu­mu­lat­ing in those teams does not pre­sent as a sig­nal. There is no met­ric for “engineers who can ex­plain their own code with­out re-read­ing it.” There is no dash­board for “organizational com­pre­hen­sion depth.” The con­cept does not fit into quar­terly busi­ness re­view for­mats or head­count jus­ti­fi­ca­tion nar­ra­tives.

Directors make de­ci­sions based on ob­serv­able sig­nals. When those sig­nals uni­formly in­di­cate suc­cess, the de­ci­sion to dou­ble down on the ap­proach that pro­duced those sig­nals is ra­tio­nal within the in­for­ma­tion en­vi­ron­ment avail­able to lead­er­ship. The de­ci­sion is not wrong given the data. The data is in­com­plete.

The cog­ni­tive debt fram­ing does not ap­ply uni­formly across all en­gi­neer­ing work. Some tasks gen­uinely are me­chan­i­cal. Some code­bases gen­uinely ben­e­fit from rapid it­er­a­tion with­out deep ar­chi­tec­tural un­der­stand­ing. Some fea­tures gen­uinely do not re­quire the level of com­pre­hen­sion that would tra­di­tion­ally form through man­ual im­ple­men­ta­tion.

The model also as­sumes that com­pre­hen­sion was pre­vi­ously form­ing at ad­e­quate rates. This as­sump­tion may be gen­er­ous. Engineers have al­ways var­ied in how deeply they un­der­stood their own work. The dis­tri­b­u­tion may sim­ply be shift­ing rather than a new phe­nom­e­non emerg­ing.

Additionally, tool­ing and doc­u­men­ta­tion prac­tices may evolve to par­tially close the com­pre­hen­sion gap. If or­ga­ni­za­tions de­velop meth­ods for cap­tur­ing and trans­mit­ting the un­der­stand­ing that AI-assisted de­vel­op­ment fails to form or­gan­i­cally, the debt may prove man­age­able rather than ac­cu­mu­la­tive.

The fun­da­men­tal chal­lenge is that or­ga­ni­za­tions can­not op­ti­mize for what they can­not mea­sure. Velocity is mea­sur­able. Comprehension is not, or at least not through any mech­a­nism that cur­rently feeds into per­for­mance eval­u­a­tion, pro­mo­tion de­ci­sions, or head­count plan­ning.

Until com­pre­hen­sion be­comes leg­i­ble to or­ga­ni­za­tional de­ci­sion-mak­ing sys­tems, the in­cen­tive struc­ture will con­tinue to fa­vor ve­loc­ity. Engineers who pri­or­i­tize un­der­stand­ing over out­put will ap­pear less pro­duc­tive than peers who pri­or­i­tize out­put over un­der­stand­ing. Performance cal­i­bra­tion will re­ward the be­hav­ior that ac­cu­mu­lates debt faster.

This is not a fail­ure of in­di­vid­ual man­agers or en­gi­neers. It is a mea­sure­ment sys­tem de­signed for an era when pro­duc­tion and com­pre­hen­sion were cou­pled, op­er­at­ing in an era when that cou­pling no longer holds. The sys­tem is op­ti­miz­ing cor­rectly for what it mea­sures. What it mea­sures no longer cap­tures what mat­ters.

The gap will even­tu­ally man­i­fest. Whether through main­te­nance costs that ex­ceed pro­jec­tions, through in­ci­dents that re­quire un­der­stand­ing no one pos­sesses, or through new re­quire­ments that ex­pose the brit­tle­ness of sys­tems built with­out deep com­pre­hen­sion. The tim­ing and form of man­i­fes­ta­tion re­main un­cer­tain. The un­der­ly­ing dy­namic does not.

This is a brief guide to my new art pro­ject mi­crogpt, a sin­gle file of 200 lines of pure Python with no de­pen­den­cies that trains and in­fer­ences a GPT. This file con­tains the full al­go­rith­mic con­tent of what is needed: dataset of doc­u­ments, to­k­enizer, au­to­grad en­gine, a GPT-2-like neural net­work ar­chi­tec­ture, the Adam op­ti­mizer, train­ing loop, and in­fer­ence loop. Everything else is just ef­fi­ciency. I can­not sim­plify this any fur­ther. This script is the cul­mi­na­tion of mul­ti­ple pro­jects (micrograd, make­more, nanogpt, etc.) and a decade-long ob­ses­sion to sim­plify LLMs to their bare es­sen­tials, and I think it is beau­ti­ful 🥹. It even breaks per­fectly across 3 columns:

Where to find it:

This GitHub gist has the full source code: mi­crogpt.py

It’s also avail­able on this web page: https://​karpa­thy.ai/​mi­crogpt.html

Also avail­able as a Google Colab note­book

The fol­low­ing is my guide on step­ping an in­ter­ested reader through the code.

The fuel of large lan­guage mod­els is a stream of text data, op­tion­ally sep­a­rated into a set of doc­u­ments. In pro­duc­tion-grade ap­pli­ca­tions, each doc­u­ment would be an in­ter­net web page but for mi­crogpt we use a sim­pler ex­am­ple of 32,000 names, one per line:

# Let there be an in­put dataset `docs`: list[str] of doc­u­ments (e.g. a dataset of names)

if not os.path.ex­ists(‘in­put.txt’):

im­port url­lib.re­quest

names_url = ’https://​raw.githubuser­con­tent.com/​karpa­thy/​make­more/​refs/​heads/​mas­ter/​names.txt’

url­lib.re­quest.url­re­trieve(names_url, ‘input.txt’)

docs = [l.strip() for l in open(‘in­put.txt’).read().strip().split(‘\n’) if l.strip()] # list[str] of doc­u­ments

ran­dom.shuf­fle(docs)

print(f”num docs: {len(docs)}“)

The dataset looks like this. Each name is a doc­u­ment:

The goal of the model is to learn the pat­terns in the data and then gen­er­ate sim­i­lar new doc­u­ments that share the sta­tis­ti­cal pat­terns within. As a pre­view, by the end of the script our model will gen­er­ate (“hallucinate”!) new, plau­si­ble-sound­ing names. Skipping ahead, we’ll get:

It does­n’t look like much, but from the per­spec­tive of a model like ChatGPT, your con­ver­sa­tion with it is just a funny look­ing “document”. When you ini­tial­ize the doc­u­ment with your prompt, the mod­el’s re­sponse from its per­spec­tive is just a sta­tis­ti­cal doc­u­ment com­ple­tion.

Under the hood, neural net­works work with num­bers, not char­ac­ters, so we need a way to con­vert text into a se­quence of in­te­ger to­ken ids and back. Production to­k­eniz­ers like tik­to­ken (used by GPT-4) op­er­ate on chunks of char­ac­ters for ef­fi­ciency, but the sim­plest pos­si­ble to­k­enizer just as­signs one in­te­ger to each unique char­ac­ter in the dataset:

# Let there be a Tokenizer to trans­late strings to dis­crete sym­bols and back

uchars = sorted(set(‘’.join(docs))) # unique char­ac­ters in the dataset be­come to­ken ids 0..n-1

BOS = len(uchars) # to­ken id for the spe­cial Beginning of Sequence (BOS) to­ken

vo­cab_­size = len(uchars) + 1 # to­tal num­ber of unique to­kens, +1 is for BOS

print(f”vo­cab size: {vocab_size}“)

In the code above, we col­lect all unique char­ac­ters across the dataset (which are just all the low­er­case let­ters a-z), sort them, and each let­ter gets an id by its in­dex. Note that the in­te­ger val­ues them­selves have no mean­ing at all; each to­ken is just a sep­a­rate dis­crete sym­bol. Instead of 0, 1, 2 they might as well be dif­fer­ent emoji. In ad­di­tion, we cre­ate one more spe­cial to­ken called BOS (Beginning of Sequence), which acts as a de­lim­iter: it tells the model “a new doc­u­ment starts/​ends here”. Later dur­ing train­ing, each doc­u­ment gets wrapped with BOS on both sides: [BOS, e, m, m, a, BOS]. The model learns that BOS ini­tates a new name, and that an­other BOS ends it. Therefore, we have a fi­nal vo­cavu­lary of 27 (26 pos­si­ble low­er­case char­ac­ters a-z and +1 for the BOS to­ken).

Training a neural net­work re­quires gra­di­ents: for each pa­ra­me­ter in the model, we need to know “if I nudge this num­ber up a lit­tle, does the loss go up or down, and by how much?”. The com­pu­ta­tion graph has many in­puts (the model pa­ra­me­ters and the in­put to­kens) but fun­nels down to a sin­gle scalar out­put: the loss (we’ll de­fine ex­actly what the loss is be­low). Backpropagation starts at that sin­gle out­put and works back­wards through the graph, com­put­ing the gra­di­ent of the loss with re­spect to every in­put. It re­lies on the chain rule from cal­cu­lus. In pro­duc­tion, li­braries like PyTorch han­dle this au­to­mat­i­cally. Here, we im­ple­ment it from scratch in a sin­gle class called Value:

class Value:

__slots__ = (‘data’, ‘grad’, ‘_children’, ‘_local_grads’)

def __init__(self, data, chil­dren=(), lo­cal_­grads=()):

self.data = data # scalar value of this node cal­cu­lated dur­ing for­ward pass

self.grad = 0 # de­riv­a­tive of the loss w.r.t. this node, cal­cu­lated in back­ward pass

self._chil­dren = chil­dren # chil­dren of this node in the com­pu­ta­tion graph

self._lo­cal_­grads = lo­cal_­grads # lo­cal de­riv­a­tive of this node w.r.t. its chil­dren

def __add__(self, other):

other = other if isin­stance(other, Value) else Value(other)

re­turn Value(self.data + other.data, (self, other), (1, 1))

def __mul__(self, other):

other = other if isin­stance(other, Value) else Value(other)

re­turn Value(self.data * other.data, (self, other), (other.data, self.data))

def __pow__(self, other): re­turn Value(self.data**other, (self,), (other * self.data**(other-1),))

def log(self): re­turn Value(math.log(self.data), (self,), (1/self.data,))

def exp(self): re­turn Value(math.exp(self.data), (self,), (math.exp(self.data),))

def relu(self): re­turn Value(max(0, self.data), (self,), (float(self.data > 0),))

def __neg__(self): re­turn self * -1

def __radd__(self, other): re­turn self + other

def __sub__(self, other): re­turn self + (-other)

def __rsub__(self, other): re­turn other + (-self)

def __rmul__(self, other): re­turn self * other

def __truediv__(self, other): re­turn self * other**-1

def __rtruediv__(self, other): re­turn other * self**-1

def back­ward(self):

topo = []

vis­ited = set()

def build_­topo(v):

if v not in vis­ited:

vis­ited.add(v)

for child in v._chil­dren:

build_­topo(child)

topo.ap­pend(v)

build_­topo(self)

self.grad = 1

for v in re­versed(topo):

for child, lo­cal_­grad in zip(v._chil­dren, v._lo­cal_­grads):

child.grad += lo­cal_­grad * v.grad

I re­al­ize that this is the most math­e­mat­i­cally and al­go­rith­mi­cally in­tense part and I have a 2.5 hour video on it: mi­cro­grad video. Briefly, a Value wraps a sin­gle scalar num­ber (.data) and tracks how it was com­puted. Think of each op­er­a­tion as a lit­tle lego block: it takes some in­puts, pro­duces an out­put (the for­ward pass), and it knows how its out­put would change with re­spect to each of its in­puts (the lo­cal gra­di­ent). That’s all the in­for­ma­tion au­to­grad needs from each block. Everything else is just the chain rule, string­ing the blocks to­gether.

Every time you do math with Value ob­jects (add, mul­ti­ply, etc.), the re­sult is a new Value that re­mem­bers its in­puts (_children) and the lo­cal de­riv­a­tive of that op­er­a­tion (_local_grads). For ex­am­ple, __mul__ records that \(\frac{\partial(a \cdot b)}{\par­tial a} = b\) and \(\frac{\partial(a \cdot b)}{\par­tial b} = a\). The full set of lego blocks:

The back­ward() method walks this graph in re­verse topo­log­i­cal or­der (starting from the loss, end­ing at the pa­ra­me­ters), ap­ply­ing the chain rule at each step. If the loss is \(L\) and a node \(v\) has a child \(c\) with lo­cal gra­di­ent \(\frac{\partial v}{\par­tial c}\), then:

\[\frac{\partial L}{\partial c} \mathrel{+}= \frac{\partial v}{\par­tial c} \cdot \frac{\partial L}{\partial v}\]

This looks a bit scary if you’re not com­fort­able with your cal­cu­lus, but this is lit­er­ally just mul­ti­ply­ing two num­bers in an in­tu­itive way. One way to see it looks as fol­lows: “If a car trav­els twice as fast as a bi­cy­cle and the bi­cy­cle is four times as fast as a walk­ing man, then the car trav­els 2 x 4 = 8 times as fast as the man.” The chain rule is the same idea: you mul­ti­ply the rates of change along the path.

We kick things off by set­ting self.grad = 1 at the loss node, be­cause \(\frac{\partial L}{\partial L} = 1\): the loss’s rate of change with re­spect to it­self is triv­ially 1. From there, the chain rule just mul­ti­plies lo­cal gra­di­ents along every path back to the pa­ra­me­ters.

Note the += (accumulation, not as­sign­ment). When a value is used in mul­ti­ple places in the graph (i.e. the graph branches), gra­di­ents flow back along each branch in­de­pen­dently and must be summed. This is a con­se­quence of the mul­ti­vari­able chain rule: if \(c\) con­tributes to \(L\) through mul­ti­ple paths, the to­tal de­riv­a­tive is the sum of con­tri­bu­tions from each path.

After back­ward() com­pletes, every Value in the graph has a .grad con­tain­ing \(\frac{\partial L}{\partial v}\), which tells us how the fi­nal loss would change if we nudged that value.

Here’s a con­crete ex­am­ple. Note that a is used twice (the graph branches), so its gra­di­ent is the sum of both paths:

a = Value(2.0)

b = Value(3.0)

c = a * b # c = 6.0

L = c + a # L = 8.0

L.backward()

print(a.grad) # 4.0 (dL/da = b + 1 = 3 + 1, via both paths)

print(b.grad) # 2.0 (dL/db = a = 2)

This is ex­actly what PyTorch’s .backward() gives you:

This is the same al­go­rithm that PyTorch’s loss.back­ward() runs, just on scalars in­stead of ten­sors (arrays of scalars) - al­go­rith­mi­cally iden­ti­cal, sig­nif­i­cantly smaller and sim­pler, but of course a lot less ef­fi­cient.

Let’s spell what the .backward() gives us above. Autograd cal­cu­lated that if L = a*b + a, and a=2 and b=3, then a.grad = 4.0 is telling us about the lo­cal in­flu­ence of a on L. If you wig­gle the in­m­put a, in what di­rec­tion is L chang­ing? Here, the de­riv­a­tive of L w.r.t. a is 4.0, mean­ing that if we in­crease a by a tiny amount (say 0.001), L would in­crease by about 4x that (0.004). Similarly, b.grad = 2.0 means the same nudge to b would in­crease L by about 2x that (0.002). In other words, these gra­di­ents tell us the di­rec­tion (positive or neg­a­tive de­pend­ing on the sign), and the steep­ness (the mag­ni­tude) of the in­flu­ence of each in­di­vid­ual in­put on the fi­nal out­put (the loss). This then al­lows us to in­ter­ately nudge the pa­ra­me­ters of our neural net­work to lower the loss, and hence im­prove its pre­dic­tions.

The pa­ra­me­ters are the knowl­edge of the model. They are a large col­lec­tion of float­ing point num­bers (wrapped in Value for au­to­grad) that start out ran­dom and are it­er­a­tively op­ti­mized dur­ing train­ing. The ex­act role of each pa­ra­me­ter will make more sense once we de­fine the model ar­chi­tec­ture be­low, but for now we just need to ini­tial­ize them:

n_embd = 16 # em­bed­ding di­men­sion

n_­head = 4 # num­ber of at­ten­tion heads

n_layer = 1 # num­ber of lay­ers

block­_­size = 16 # max­i­mum se­quence length

head­_dim = n_embd // n_­head # di­men­sion of each head

ma­trix = lambda nout, nin, std=0.08: [[Value(random.gauss(0, std)) for _ in range(nin)] for _ in range(nout)]

state_­dict = {‘wte’: ma­trix(vo­cab_­size, n_embd), ‘wpe’: ma­trix(block­_­size, n_embd), ‘lm_head’: ma­trix(vo­cab_­size, n_embd)}

for i in range(n_layer):

state_­dict[f’layer{i}.at­tn_wq’] = ma­trix(n_embd, n_embd)

state_­dict[f’layer{i}.at­tn_wk’] = ma­trix(n_embd, n_embd)

state_­dict[f’layer{i}.at­tn_wv’] = ma­trix(n_embd, n_embd)

state_­dict[f’layer{i}.at­tn_­wo’] = ma­trix(n_embd, n_embd)

state_­dict[f’layer{i}.mlp_fc1′] = ma­trix(4 * n_embd, n_embd)

state_­dict[f’layer{i}.mlp_fc2′] = ma­trix(n_embd, 4 * n_embd)

params = [p for mat in state_­dict.val­ues() for row in mat for p in row]

print(f”num params: {len(params)}“)

It was around January 2020. I be­came the head coach of a youth bas­ket­ball team.

I was a few months into my first job out of col­lege, and I was feel­ing… empty. I could­n’t ex­plain why, so I set out to fill the void. I built side pro­jects, went drink­ing with cowork­ers, and got re­ally into the up­com­ing elec­tion. These all felt like things I should be do­ing as the yuppy I had just be­come, but the empti­ness resided.

Indiana loves its bas­ket­ball, so it was easy for me to find a lo­cal gym to play pickup. I be­came friendly with the reg­u­lars and the staff. One day, the ath­letic di­rec­tor told me they were look­ing for a vol­un­teer as­sis­tant bas­ket­ball coach for the mid­dle school league. Being a for­mer camp coun­selor, the idea in­trigued me. Unexpectedly, the “assistant” po­si­tion be­came the “head” po­si­tion, and I was quickly thrown into a clinic, where I had to draft all my play­ers by the end of the ses­sion.

Team drafted. 6 kids. 1 game per week. 2 prac­tices per week. 14 par­ent emails (somehow). Practice starts to­mor­row.

You know those bull­shit lead­er­ship po­si­tions we all had in high school and col­lege? Like how you were “VP of Operations” for some club, and all you did was or­der pizza? Yeah, this was not that. Getting thrown into an empty gym with six kids and two bas­ket­balls is a thrilling ex­pe­ri­ence! I’m so grate­ful my buddy Clayton joined me as co-coach. I spent the whole day prepar­ing for that 2-hour prac­tice, and I think it showed. We learned each oth­er’s names, had a solid skills as­sess­ment, set some ground rules, and had some fun with a lit­tle knock­out.

Here’s the head­line: I fuck­ing loved be­ing a coach. And, I don’t want to brag, but I was re­ally good at it. We lost one game, our first game, and went un­de­feated af­ter that. But im­prov­ing each kid’s skill and con­fi­dence was the real mis­sion. Instead of my desk job, I’d be ask­ing Clayton how we could make Corey¹ use his body for re­bound­ing. Or how Monte’s soc­cer skills could be best lever­aged. Or how Evan, our best player, could be­come an on-court leader.

David, our self-dep­re­cat­ing goof­ball who in­sisted he’d be benched in the 4th quar­ter, made two game-chang­ing dives for the ball in our last game. At the end of every game, I’d ask if any­one had any shoutouts to give about their team­mates. Evan called David “a beast” for his dives, fol­lowed by rous­ing ap­plause from the whole team. David’s smile is likely some­thing I’ll be tak­ing to my grave.

As the kids’ con­fi­dence grew, mine did too. I walked around the gym with a strut. I greeted their fam­i­lies with con­fi­dent eye con­tact, re­mem­ber­ing every word they said. I felt my­self per­form­ing bet­ter in all parts of life: work, com­mu­nity, re­la­tion­ships… I be­came “that guy” who made shit hap­pen in our friend group.

Heading into March, I was plan­ning a sur­prise for the team. I had a con­tact at the Indiana Pacers, and I was schem­ing to get them to play on the court dur­ing a break in play. But to much ruin, Covid be­came a pan­demic, lead­ing to an abrupt end to the sea­son, and an im­me­di­ate global quar­an­tine…

But that’s an­other story for an­other time. This is a story about hap­pi­ness- and find­ing it at any point in your life.

I was happy when I was a youth bas­ket­ball coach. And I find it no­table to re­call why I was happy:

* I love help­ing kids. I can’t ex­actly ex­plain why… per­haps it’s bi­o­log­i­cal. But I’m pretty darn good at it. I find it much eas­ier to talk to kids than adults.

* I love be­ing in the real world. If I taught those kids on Zoom… it would­n’t have been the same. To travel some­where, break a sweat, and high-five my team was such a gift.

* I love be­ing in con­trol. Coordinating prac­tice, call­ing the plays, mak­ing sub­sti­tu­tions- coach­ing let me steer my own ship. “Loving con­trol” has its draw­backs. But suc­ceed­ing within that con­trol gave me real con­fi­dence and be­lief in my­self.

* I love bas­ket­ball. I can’t think of a bet­ter ac­tiv­ity to learn about your mind, body, and role within a sys­tem. I’m a junk­yard dog. When I get mad, I work ex­tra hard do­ing the stuff no­body else wants to do. But I lose en­ergy faster. I learned this from the game.

If I could give any ad­vice to some­one who needs it, I’d tell them to write down the things that have made them happy, and then ex­plore why.

Why am I writ­ing this now? I have a sense that many peo­ple in tech are feel­ing what I’m feel­ing. For years, you’ve sat in front of a rec­tan­gle, mov­ing tinier rec­tan­gles, only to learn that AI can now move those rec­tan­gles 10x bet­ter. As some­one out­side the eq­uity class, you be­gin to won­der what your role is in this new par­a­digm. And whether rec­tan­gles were ever your ticket to hap­pi­ness in the first place.

When I was the age my bas­ket­ball kids were, The Social Network came out. Like so many, I am a prod­uct of that gen­er­a­tion. I ac­cepted the pro­pa­ganda that my value to this world only went as far as my prod­uct could scale. At 28, I’m fi­nally be­gin­ning to chal­lenge that.

Don’t get me wrong, I love tech. I think it’s mag­i­cal. But I re­ally hope to live in a world where my fu­ture kids find sit­ting in front of a rec­tan­gle all day to be dystopian and cringe. I re­ally re­ally re­ally hope the in­vis­i­ble hand finds its way to get­ting me back into some­thing I love. Maybe this “death of SaaS” talk, re­gard­less of truth, is the wakeup call to so many us need.

¹ Names have been changed to pro­tect their pri­vacy.

When you’re build­ing with AI agents, they should be treated as un­trusted and po­ten­tially ma­li­cious. Whether you’re wor­ried about prompt in­jec­tion, a model try­ing to es­cape its sand­box, or some­thing no­body’s thought of yet, re­gard­less of what your threat model is, you should­n’t be trust­ing the agent. The right ap­proach is­n’t bet­ter per­mis­sion checks or smarter al­lowlists. It’s ar­chi­tec­ture that as­sumes agents will mis­be­have and con­tains the dam­age when they do.

OpenClaw runs di­rectly on the host ma­chine by de­fault. It has an opt-in Docker sand­box mode, but it’s turned off out of the box, and most users never turn it on. Without it, se­cu­rity re­lies en­tirely on ap­pli­ca­tion-level checks: al­lowlists, con­fir­ma­tion prompts, a set of “safe” com­mands. These checks come from a place of im­plicit trust that the agent is­n’t go­ing to try to do some­thing wrong. Once you adopt the mind­set that an agent is po­ten­tially ma­li­cious, it’s ob­vi­ous that ap­pli­ca­tion-level blocks aren’t enough. They don’t pro­vide her­metic se­cu­rity. A de­ter­mined or com­pro­mised agent can find ways around them.

In NanoClaw, con­tainer iso­la­tion is a core part of the ar­chi­tec­ture. Each agent runs in its own con­tainer, on Docker or an Apple Container on ma­cOS. Containers are ephemeral, cre­ated fresh per in­vo­ca­tion and de­stroyed af­ter­ward. The agent runs as an un­priv­i­leged user and can only see di­rec­to­ries that have been ex­plic­itly mounted in. A con­tainer bound­ary is en­forced by the OS.

Even when OpenClaw’s sand­box is en­abled, all agents share the same con­tainer. You might have one agent as a per­sonal as­sis­tant and an­other for work, in dif­fer­ent WhatsApp groups or Telegram chan­nels. They’re all in the same en­vi­ron­ment, which means in­for­ma­tion can leak be­tween agents that are sup­posed to be ac­cess­ing dif­fer­ent data.

Agents should­n’t trust each other any more than you trust them. In NanoClaw, each agent gets its own con­tainer, filesys­tem, and Claude ses­sion his­tory. Your per­sonal as­sis­tant can’t see your work agen­t’s data be­cause they run in com­pletely sep­a­rate sand­boxes.

All agents see every­thing

Agents iso­lated from each other

The con­tainer bound­ary is the hard se­cu­rity layer — the agent can’t es­cape it re­gard­less of con­fig­u­ra­tion. On top of that, a mount al­lowlist at ~/.config/nanoclaw/mount-allowlist.json acts as an ad­di­tional layer of de­fense-in-depth: it ex­ists to pre­vent the user from ac­ci­den­tally mount­ing some­thing that should­n’t be ex­posed, not to pre­vent the agent from break­ing out. Sensitive paths (.ssh, .gnupg, .aws, .env, pri­vate_key, cre­den­tials) are blocked by de­fault. The al­lowlist lives out­side the pro­ject di­rec­tory, so a com­pro­mised agent can’t mod­ify its own per­mis­sions. The host ap­pli­ca­tion code is mounted read-only, so noth­ing an agent does can per­sist af­ter the con­tainer is de­stroyed.

People in your groups should­n’t be trusted ei­ther. Non-main groups are un­trusted by de­fault. Other groups, and the peo­ple in them, can’t mes­sage other chats, sched­ule tasks for other groups, or view other groups’ data. Anyone in a group could send a prompt in­jec­tion, and the se­cu­rity model ac­counts for that.

OpenClaw has nearly half a mil­lion lines of code, 53 con­fig files, and over 70 de­pen­den­cies. This breaks the ba­sic premise of open source se­cu­rity. Chromium has 35+ mil­lion lines, but you trust Google’s re­view processes. Most open source pro­jects work the other way: they stay small enough that many eyes can ac­tu­ally re­view them. Nobody has re­viewed OpenClaw’s 400,000 lines. It was writ­ten in weeks with no proper re­view process. Complexity is where vul­ner­a­bil­i­ties hide, and Microsoft’s analy­sis con­firmed this: OpenClaw’s risks could emerge through nor­mal API calls, be­cause no one per­son could see the full pic­ture.

NanoClaw is one process and a hand­ful of files. We rely heav­ily on Anthropic’s Agent SDK, the wrap­per around Claude Code, for ses­sion man­age­ment, mem­ory com­paction, and a lot more, in­stead of rein­vent­ing the wheel. A com­pe­tent de­vel­oper can re­view the en­tire code­base in an af­ter­noon. This is a de­lib­er­ate con­straint, not a lim­i­ta­tion. Our con­tri­bu­tion guide­lines ac­cept bug fixes, se­cu­rity fixes, and sim­pli­fi­ca­tions only.

New func­tion­al­ity comes through skills: in­struc­tions with a full work­ing ref­er­ence im­ple­men­ta­tion that a cod­ing agent merges into your code­base. You re­view ex­actly what code will be added be­fore it lands. And you only add the in­te­gra­tions you ac­tu­ally need. Every in­stal­la­tion ends up as a few thou­sand lines of code tai­lored to the own­er’s ex­act re­quire­ments.

This is the real dif­fer­ence. With a mono­lithic code­base of 400,000 lines, even if you only en­able two in­te­gra­tions, the rest of the code is still there. It’s still loaded, still part of your at­tack sur­face, still reach­able by prompt in­jec­tions and rogue agents. You can’t dis­en­tan­gle what’s ac­tive from what’s dor­mant. You can’t au­dit it be­cause you can’t even de­fine the bound­ary of what “your code” is. With skills, the bound­ary is ob­vi­ous: it’s a few thou­sand lines, it’s all code you chose to add, and you can read every line of it. The core is ac­tu­ally get­ting smaller over time: WhatsApp sup­port, for ex­am­ple, is be­ing pulled out and pack­aged as a skill.

If a hal­lu­ci­na­tion or a mis­be­hav­ing agent can cause a se­cu­rity is­sue, then the se­cu­rity model is bro­ken. Security has to be en­forced out­side the agen­tic sur­face, not de­pend on the agent be­hav­ing cor­rectly. Containers, mount re­stric­tions, and filesys­tem iso­la­tion all ex­ist so that even when an agent does some­thing un­ex­pected, the blast ra­dius is con­tained.

None of this elim­i­nates risk. An AI agent with ac­cess to your data is in­her­ently a high-risk arrange­ment. But the right re­sponse is to make that trust as nar­row and as ver­i­fi­able as pos­si­ble. Don’t trust the agent. Build walls around it.

You can read NanoClaw’s source code and full se­cu­rity model; they’re short enough to read in an af­ter­noon.

When you’re build­ing with AI agents, they should be treated as un­trusted and po­ten­tially ma­li­cious. Whether you’re wor­ried about prompt in­jec­tion, a model try­ing to es­cape its sand­box, or some­thing no­body’s thought of yet, re­gard­less of what your threat model is, you should­n’t be trust­ing the agent. The right ap­proach is­n’t bet­ter per­mis­sion checks or smarter al­lowlists. It’s ar­chi­tec­ture that as­sumes agents will mis­be­have and con­tains the dam­age when they do.

OpenClaw runs di­rectly on the host ma­chine by de­fault. It has an opt-in Docker sand­box mode, but it’s turned off out of the box, and most users never turn it on. Without it, se­cu­rity re­lies en­tirely on ap­pli­ca­tion-level checks: al­lowlists, con­fir­ma­tion prompts, a set of “safe” com­mands. These checks come from a place of im­plicit trust that the agent is­n’t go­ing to try to do some­thing wrong. Once you adopt the mind­set that an agent is po­ten­tially ma­li­cious, it’s ob­vi­ous that ap­pli­ca­tion-level blocks aren’t enough. They don’t pro­vide her­metic se­cu­rity. A de­ter­mined or com­pro­mised agent can find ways around them.

In NanoClaw, con­tainer iso­la­tion is a core part of the ar­chi­tec­ture. Each agent runs in its own con­tainer, on Docker or an Apple Container on ma­cOS. Containers are ephemeral, cre­ated fresh per in­vo­ca­tion and de­stroyed af­ter­ward. The agent runs as an un­priv­i­leged user and can only see di­rec­to­ries that have been ex­plic­itly mounted in. A con­tainer bound­ary is en­forced by the OS.

Even when OpenClaw’s sand­box is en­abled, all agents share the same con­tainer. You might have one agent as a per­sonal as­sis­tant and an­other for work, in dif­fer­ent WhatsApp groups or Telegram chan­nels. They’re all in the same en­vi­ron­ment, which means in­for­ma­tion can leak be­tween agents that are sup­posed to be ac­cess­ing dif­fer­ent data.

Agents should­n’t trust each other any more than you trust them. In NanoClaw, each agent gets its own con­tainer, filesys­tem, and Claude ses­sion his­tory. Your per­sonal as­sis­tant can’t see your work agen­t’s data be­cause they run in com­pletely sep­a­rate sand­boxes.

All agents see every­thing

Agents iso­lated from each other

The con­tainer bound­ary is the hard se­cu­rity layer — the agent can’t es­cape it re­gard­less of con­fig­u­ra­tion. On top of that, a mount al­lowlist at ~/.config/nanoclaw/mount-allowlist.json acts as an ad­di­tional layer of de­fense-in-depth: it ex­ists to pre­vent the user from ac­ci­den­tally mount­ing some­thing that should­n’t be ex­posed, not to pre­vent the agent from break­ing out. Sensitive paths (.ssh, .gnupg, .aws, .env, pri­vate_key, cre­den­tials) are blocked by de­fault. The al­lowlist lives out­side the pro­ject di­rec­tory, so a com­pro­mised agent can’t mod­ify its own per­mis­sions. The host ap­pli­ca­tion code is mounted read-only, so noth­ing an agent does can per­sist af­ter the con­tainer is de­stroyed.

People in your groups should­n’t be trusted ei­ther. Non-main groups are un­trusted by de­fault. Other groups, and the peo­ple in them, can’t mes­sage other chats, sched­ule tasks for other groups, or view other groups’ data. Anyone in a group could send a prompt in­jec­tion, and the se­cu­rity model ac­counts for that.

OpenClaw has nearly half a mil­lion lines of code, 53 con­fig files, and over 70 de­pen­den­cies. This breaks the ba­sic premise of open source se­cu­rity. Chromium has 35+ mil­lion lines, but you trust Google’s re­view processes. Most open source pro­jects work the other way: they stay small enough that many eyes can ac­tu­ally re­view them. Nobody has re­viewed OpenClaw’s 400,000 lines. It was writ­ten in weeks with no proper re­view process. Complexity is where vul­ner­a­bil­i­ties hide, and Microsoft’s analy­sis con­firmed this: OpenClaw’s risks could emerge through nor­mal API calls, be­cause no one per­son could see the full pic­ture.

NanoClaw is one process and a hand­ful of files. We rely heav­ily on Anthropic’s Agent SDK, the wrap­per around Claude Code, for ses­sion man­age­ment, mem­ory com­paction, and a lot more, in­stead of rein­vent­ing the wheel. A com­pe­tent de­vel­oper can re­view the en­tire code­base in an af­ter­noon. This is a de­lib­er­ate con­straint, not a lim­i­ta­tion. Our con­tri­bu­tion guide­lines ac­cept bug fixes, se­cu­rity fixes, and sim­pli­fi­ca­tions only.

New func­tion­al­ity comes through skills: in­struc­tions with a full work­ing ref­er­ence im­ple­men­ta­tion that a cod­ing agent merges into your code­base. You re­view ex­actly what code will be added be­fore it lands. And you only add the in­te­gra­tions you ac­tu­ally need. Every in­stal­la­tion ends up as a few thou­sand lines of code tai­lored to the own­er’s ex­act re­quire­ments.

This is the real dif­fer­ence. With a mono­lithic code­base of 400,000 lines, even if you only en­able two in­te­gra­tions, the rest of the code is still there. It’s still loaded, still part of your at­tack sur­face, still reach­able by prompt in­jec­tions and rogue agents. You can’t dis­en­tan­gle what’s ac­tive from what’s dor­mant. You can’t au­dit it be­cause you can’t even de­fine the bound­ary of what “your code” is. With skills, the bound­ary is ob­vi­ous: it’s a few thou­sand lines, it’s all code you chose to add, and you can read every line of it. The core is ac­tu­ally get­ting smaller over time: WhatsApp sup­port, for ex­am­ple, is be­ing pulled out and pack­aged as a skill.

If a hal­lu­ci­na­tion or a mis­be­hav­ing agent can cause a se­cu­rity is­sue, then the se­cu­rity model is bro­ken. Security has to be en­forced out­side the agen­tic sur­face, not de­pend on the agent be­hav­ing cor­rectly. Containers, mount re­stric­tions, and filesys­tem iso­la­tion all ex­ist so that even when an agent does some­thing un­ex­pected, the blast ra­dius is con­tained.

None of this elim­i­nates risk. An AI agent with ac­cess to your data is in­her­ently a high-risk arrange­ment. But the right re­sponse is to make that trust as nar­row and as ver­i­fi­able as pos­si­ble. Don’t trust the agent. Build walls around it.

You can read NanoClaw’s source code and full se­cu­rity model; they’re short enough to read in an af­ter­noon.

Every MCP tool call in Claude Code dumps raw data into your 200K con­text win­dow. A Playwright snap­shot costs 56 KB. Twenty GitHub is­sues cost 59 KB. One ac­cess log — 45 KB. After 30 min­utes, 40% of your con­text is gone.

Context Mode is an MCP server that sits be­tween Claude Code and these out­puts. 315 KB be­comes 5.4 KB. 98% re­duc­tion.

MCP be­came the stan­dard way for AI agents to use ex­ter­nal tools. But there’s a ten­sion at its core: every tool in­ter­ac­tion fills the con­text win­dow from both sides — de­f­i­n­i­tions on the way in, raw out­put on the way out.

With 81+ tools ac­tive, 143K to­kens (72%) get con­sumed be­fore your first mes­sage. Then the tools start re­turn­ing data. A sin­gle Playwright snap­shot burns 56 KB. A gh is­sue list dumps 59 KB. Run a test suite, read a log file, fetch doc­u­men­ta­tion — each re­sponse eats into what re­mains.

Cloudflare showed that tool de­f­i­n­i­tions can be com­pressed by 99.9% with Code Mode. We asked: what about the other di­rec­tion?

Each ex­e­cute call spawns an iso­lated sub­process with its own process bound­ary. Scripts can’t ac­cess each oth­er’s mem­ory or state. The sub­process runs your code, cap­tures std­out, and only that std­out en­ters the con­ver­sa­tion con­text. The raw data — log files, API re­sponses, snap­shots — never leaves the sand­box.

Ten lan­guage run­times are avail­able: JavaScript, TypeScript, Python, Shell, Ruby, Go, Rust, PHP, Perl, R. Bun is auto-de­tected for 3-5x faster JS/TS ex­e­cu­tion.

Authenticated CLIs (gh, aws, gcloud, kubectl, docker) work through cre­den­tial passthrough — the sub­process in­her­its en­vi­ron­ment vari­ables and con­fig paths with­out ex­pos­ing them to the con­ver­sa­tion.

The in­dex tool chunks mark­down con­tent by head­ings while keep­ing code blocks in­tact, then stores them in a SQLite FTS5 (Full-Text Search 5) vir­tual table. Search uses BM25 rank­ing — a prob­a­bilis­tic rel­e­vance al­go­rithm that scores doc­u­ments based on term fre­quency, in­verse doc­u­ment fre­quency, and doc­u­ment length nor­mal­iza­tion. Porter stem­ming is ap­plied at in­dex time so “running”, “runs”, and “ran” match the same stem.

When you call search, it re­turns ex­act code blocks with their head­ing hi­er­ar­chy — not sum­maries, not ap­prox­i­ma­tions, the ac­tual in­dexed con­tent. fetch_and_in­dex ex­tends this to URLs: fetch, con­vert HTML to mark­down, chunk, in­dex. The raw page never en­ters con­text.

Validated across 11 real-world sce­nar­ios — test triage, TypeScript er­ror di­ag­no­sis, git diff re­view, de­pen­dency au­dit, API re­sponse pro­cess­ing, CSV an­a­lyt­ics. All un­der 1 KB out­put each.

Over a full ses­sion: 315 KB of raw out­put be­comes 5.4 KB. Session time be­fore slow­down goes from ~30 min­utes to ~3 hours. Context re­main­ing af­ter 45 min­utes: 99% in­stead of 60%.

Two ways. Plugin Marketplace gives you auto-rout­ing hooks and slash com­mands:

Or MCP-only if you just want the tools:

You don’t change how you work. Context Mode in­cludes a PreToolUse hook that au­to­mat­i­cally routes tool out­puts through the sand­box. Subagents learn to use batch_ex­e­cute as their pri­mary tool. Bash sub­agents get up­graded to gen­eral-pur­pose so they can ac­cess MCP tools.

The prac­ti­cal dif­fer­ence: your con­text win­dow stops fill­ing up. Sessions that used to hit the wall at 30 min­utes now run for 3 hours. The same 200K to­kens, used more care­fully.

I run the MCP Directory & Hub. 100K+ daily re­quests. See every MCP server that ships. The pat­tern was clear: every­one builds tools that dump raw data into con­text. Nobody was solv­ing the out­put side.

Cloudflare’s Code Mode blog post crys­tal­lized it. They com­pressed tool de­f­i­n­i­tions. We com­press tool out­puts. Same prin­ci­ple, other di­rec­tion.

Built it for my own Claude Code ses­sions first. Noticed I could work 6x longer be­fore con­text degra­da­tion. Open-sourced it.

Every de­vel­oper I know uses AI for cod­ing now. The pro­duc­tiv­ity gains are real, but there are costs that don’t show up on any dash­board.

Imagine a spec­trum. On the far left are hu­mans typ­ing on the key­board, see­ing the code in the IDE. On the far right: AGI. It im­ple­ments every­thing on its own. Cheaply, flaw­lessly, bet­ter than any hu­man, and no hu­man over­seer is re­quired. Somewhere be­tween those two ex­tremes there’s you, us­ing AI, to­day. That thresh­old moves to the right every week as mod­els im­prove, tools ma­ture, and work­flows get re­fined.

Recently I stum­bled upon this awe­some dax­fohl com­ment on HN:

Which is higher risk, us­ing AI too much, or us­ing AI too lit­tle?

and it made me think about LLMs for cod­ing dif­fer­ently, es­pe­cially af­ter read­ing what other devs share on AI adop­tion in dif­fer­ent work­places. You can be wrong in both di­rec­tions, but is the de­sired amount of AI us­age at work chang­ing as the mod­els im­prove?

Not long ago the first AI cod­ing tools like Cursor (2023) or Copilot (2022) emerged. They were able to quickly in­dex the code­base us­ing RAG, so they had the lo­cal con­text. They had all the knowl­edge of the mod­els pow­er­ing them, so they had an ex­ter­nal knowl­edge of the Internet as well. Googling and brows­ing StackOverflow was­n’t needed any­more. Cursor gave the users a cus­tom IDE with built in AI pow­ered au­to­com­plete and other baked-in AI tools, like chat, to make the ex­pe­ri­ence co­her­ent.

Then came the agent promise. MCPs, au­tonomous work­flows, ar­ti­cles about agents run­ning overnight started to pop up left and right. It was a dif­fer­ent use of AI than Cursor. It was no longer an AI-assisted hu­man cod­ing, but a hu­man-as­sisted AI cod­ing.

Many devs tried it and got burned. Agents made tons of small mis­takes. The AI-first process re­quired a com­plete par­a­digm shift in how devs think about cod­ing, in or­der to achieve great re­sults. Also, agents of­ten got stuck in loops, hal­lu­ci­nate de­pen­den­cies, and pro­duced code that looks al­most right but is­n’t. You needed to learn about a com­pletely new tech, fu­eled by FOMO. And this new shiny tool never got it 100% right on the first try.

Software used to be de­ter­min­is­tic. You con­trolled it with if/​else branches, ex­plicit state ma­chines, clear logic. The new re­al­ity is con­trol­ling the de­vel­op­ment process with prompts, sys­tem in­struc­tions, and CLAUDE.md files, and hope the model pro­duces the out­put you ex­pect.

Then Opus 4.5 came out.

The work­flows every­one were talk­ing about just worked, out of the box (not al­ways, ob­vi­ously, but more of­ten). Engineers tran­si­tioned to Forward Deployed Engineers, be­com­ing re­spon­si­ble for many other things than cod­ing. Sometimes not even cod­ing by hand at all. Recently Spotify’s co-CEO Gustav Söderström said

An en­gi­neer at Spotify on their morn­ing com­mute from Slack on their cell phone can tell Claude to fix a bug or add a new fea­ture to the iOS app. And once Claude fin­ishes that work, the en­gi­neer then gets a new ver­sion of the app, pushed to them on Slack on their phone, so that he can then merge it to pro­duc­tion, all be­fore they even ar­rive at the of­fice.”

I hope they at least re­view the code be­fore merg­ing.

The next stage is an (almost) full au­toma­tion. That’s what many ex­ecs want and try to achieve. It’s a cap­i­tal­is­tic wet dream, a worker that never sleeps, never gets tired, al­ways wants to work, is in­fi­nitely pro­duc­tive. But Geoffrey Hinton pre­dicted in 2016 that deep learn­ing would out­per­form ra­di­ol­o­gists at im­age analy­sis within five years. Anthropic’s CEO pre­dicted AI would write 90% of code within three to six months of March 2025. None of this hap­pened as pre­dicted. The tra­jec­tory is real, but the time­line keeps slip­ping.

In 2012, neu­ro­sci­en­tist Manfred Spitzer pub­lished Digital Dementia, ar­gu­ing that when we out­source men­tal tasks to dig­i­tal de­vices, the brain path­ways re­spon­si­ble for those tasks at­ro­phy. Use it or lose it. Not all of this is proven sci­en­tif­i­cally, but neu­ro­plas­tic­ity re­search shows the brain strength­ens path­ways that get used and weak­ens ones that don’t. The core prin­ci­ple of the book is that the cog­ni­tive skills that you stop prac­tic­ing will de­cline.

Margaret-Anne Storey, a soft­ware en­gi­neer­ing re­searcher, re­cently gave this a more pre­cise name: cog­ni­tive debt. Technical debt lives in the code. Cognitive debt lives in de­vel­op­ers’ heads. It’s the ac­cu­mu­lated loss of un­der­stand­ing that hap­pens when you build fast with­out com­pre­hend­ing what you built. She grounds it in Peter Naur’s 1985 the­ory that a pro­gram is a the­ory ex­ist­ing in de­vel­op­ers’ minds, cap­tur­ing what it does, how in­ten­tions map to im­ple­men­ta­tion, and how it can evolve. When that the­ory frag­ments, the sys­tem be­comes a black box.

Apply this di­rectly to fully agen­tic cod­ing. If you stop writ­ing code and only re­view AI out­put, your abil­ity to rea­son about code at­ro­phies. Slowly, in­vis­i­bly, but in­evitably. You can’t deeply re­view what you can no longer deeply un­der­stand.

This is­n’t just the­ory. A 2026 ran­dom­ized study by Shen and Tamkin tested this di­rectly: 52 pro­fes­sional de­vel­op­ers learn­ing a new async li­brary were split into AI-assisted and unas­sisted groups. The AI group scored 17% lower on con­cep­tual un­der­stand­ing, de­bug­ging, and code read­ing. The largest gap was in de­bug­ging, the ex­act skill you need to catch what AI gets wrong. One hour of pas­sive AI-assisted work pro­duced mea­sur­able skill ero­sion.

The in­sid­i­ous part is that you don’t no­tice the de­cline be­cause the tool com­pen­sates for it. You feel pro­duc­tive. The PRs are ship­ping. Mihaly Csikszentmihalyi’s re­search on flow showed that the state of flow de­pends on a bal­ance be­tween chal­lenge and skill. Your mind needs to be stretched just enough. Real flow pro­duces growth. Rachel Thomas called what AI-assisted work pro­duces “dark flow”, a term bor­rowed from gam­bling re­search, de­scrib­ing the trance-like state slot ma­chines are de­signed to in­duce. You feel ab­sorbed, but the chal­lenge-skill bal­ance is gone be­cause the AI han­dles the chal­lenge. It feels like the flow state of deep work, but the feed­back loop is bro­ken. You’re not get­ting bet­ter, you’re get­ting de­pen­dent.

There’s this ob­ser­va­tion that keeps com­ing up in HN com­ments: if the AI writes all the code and you only re­view it, where does the skill to re­view come from? You can’t have one with­out the other. You don’t learn to rec­og­nize good code by read­ing about it in a text­book, or a PR. You learn by writ­ing bad code, get­ting it torn apart, and build­ing in­tu­ition through years of prac­tice.

This cre­ates what I’d call the re­view para­dox: the more AI writes, the less qual­i­fied hu­mans be­come to re­view what it wrote. The Shen-Tamkin study puts num­bers on this. Developers who fully del­e­gated to AI fin­ished tasks fastest but scored worst on eval­u­a­tions. The novices who ben­e­fit most from AI pro­duc­tiv­ity are ex­actly the ones who need de­bug­ging skills to su­per­vise it, and AI erodes those skills first.

Storey’s pro­posed fix is sim­ple: “require hu­mans to un­der­stand each AI-generated change be­fore de­ploy­ment.” That’s the right an­swer. It’s also the one that gets skipped first when ve­loc­ity is the met­ric.

This goes deeper than in­di­vid­ual skill de­cay. We used to have ju­niors, mids, se­niors, staff en­gi­neers, ar­chi­tects. It was a pipeline where each level built on years of hands-on strug­gle. A ju­nior spends years writ­ing code that is re­jected dur­ing the code re­view not be­cause they were not care­ful, but did­n’t know bet­ter. It’s how you build the judg­ment that sep­a­rates some­one who can write a func­tion from some­one who can ar­chi­tect a sys­tem. You can’t be­come a se­nior overnight.

Unless you use AI, of course. Now, a ju­nior with Claude Code (Opus 4.5+) de­liv­ers PRs that look like se­nior en­gi­neer work. And over­all that’s a good thing, I think. But does it mean that the se­nior hat fits every­one now? From day one? But the head un­der­neath has­n’t changed. That ju­nior does­n’t know why that ar­chi­tec­ture was cho­sen. From my ex­pe­ri­ence, some­times CC misses a new DB trans­ac­tion where it’s needed. Sometimes it cre­ates a lock on a re­source, that should­n’t be locked, due to num­ber of rea­sons. I can de­fend my de­ci­sions and I en­joy when my code is chal­lenged, when re­view­ers dis­agree, and we have a dis­cus­sion. What will a ju­nior do? Ask Claude.

It’s a two-sided col­lapse. Seniors who stop writ­ing code and only re­view AI out­put lose their own depth. Juniors who skip the strug­gle never build it. Organizations are spend­ing se­nior time every day on re­views while si­mul­ta­ne­ously break­ing the mech­a­nisms that cre­ate it. The pipeline that pro­duced se­nior en­gi­neers, writ­ing bad code, get­ting bad code re­viewed, build­ing in­tu­ition through fail­ure, is be­ing by­passed en­tirely. Nobody’s talk­ing about what hap­pens when that pipeline runs dry.

Look at what lands on C-level desks every week. Microsoft’s AI chief Mustafa Suleyman says all white-col­lar work will be au­to­mated within 18 months. Anthropic’s CEO Dario Amodei pre­dicts AI will re­place soft­ware en­gi­neers in 6-12 months and quoted his en­gi­neers say­ing they don’t write any code any­more, just let the model write it and edit the out­put. Sundar Pichai (CEO, Google) re­ported 25% of Google’s new code was AI-generated in late 2024. Months later, Google Research re­ported that num­ber had reached 50% of code char­ac­ters. If you’re a CTO watch­ing that curve, of course you’re go­ing to push your teams.

The prob­lem is that pre­dic­tions come from peo­ple sell­ing AI or try­ing to prop the stock with AI hype. They have every in­cen­tive to ac­cel­er­ate adop­tion and zero ac­count­abil­ity when the time­lines slip, which, his­tor­i­cally, they al­ways do. And “50% of code char­ac­ters” at Google, a com­pany that has built its own mod­els, tool­ing, and in­fra­struc­ture from scratch, says very lit­tle about what your team can achieve with off-the-shelf agents next Monday.

AI adop­tion is not a switch to flip, rather a skill to cal­i­brate. It’s not as sim­ple as man­dat­ing spe­cific tools, set­ting “AI-first” poli­cies, mea­sur­ing de­vel­op­ers on how much AI they use (/r/ExperiencedDevs is full of these sto­ries). A lot of good prac­tices like us­age of de­sign pat­terns, proper test cov­er­age, man­ual test­ing be­fore merg­ing, are of­ten skipped these days be­cause it re­duces the pace. AI broke it? AI will fix it. You need a re­view? AI will do it. Not even Greptile or CodeRabbit. Just del­e­gate the PR to Claude Code re­viewer agent. Or Gemini. Or Codex. Pick your poi­son.

And here’s what ac­tu­ally hap­pens when you force the AI us­age. One de­vel­oper on r/​Ex­pe­ri­enced­Devs de­scribed their com­pany track­ing AI us­age per en­gi­neer: “I just started ask­ing my bots to do ran­dom things I don’t even care about. The other day I told Claude to ex­am­ine ran­dom di­rec­to­ries to ‘find bugs’ or an­swer ques­tions I al­ready knew the an­swer to.” This thread is full of en­gi­neers re­port­ing that AI has made code re­views “infinitely harder due to the AI slop pro­duced by tech leads who have been off the tools long enough to be dan­ger­ous.”

This is sad, be­cause be­ing able to work with the AI tools is a perk for de­vel­op­ers and since it im­proves pace, it’s some­thing man­age­ment wants as well. It’s ob­vi­ous that the peo­ple gam­ing the met­rics (not re­ally us­ing the AI the way the should) would be fired on the spot if the man­age­ment learned how they are gam­ing the met­rics (and it’s fair), but they are gam­ing the met­rics be­cause they don’t want to be fired…

Who should be re­spon­si­ble for set­ting the thresh­old of AI us­age at the com­pany? What if your top per­form­ing en­gi­neer just re­fuses to use AI? What if the newly hired ju­nior uses AI all the time? These are the new ques­tions and man­age­ment is try­ing to find an an­swer to them, but it’s not as sim­ple as mea­sur­ing the AI us­age.

This is Goodhart’s law in ac­tion: “When a mea­sure be­comes a tar­get, it ceases to be a good mea­sure.” Track AI us­age per en­gi­neer and you won’t get bet­ter en­gi­neer­ing, you’ll get com­pli­ance the­ater. Developers game the met­rics, re­sent the tools, and the ac­tual pro­duc­tiv­ity gains that AI could de­liver get buried un­der or­ga­ni­za­tional dys­func­tion.

The fi­nan­cial cost is ob­vi­ous. Agent time for non-triv­ial fea­tures is mea­sured in hours, and those hours aren’t free. But the hu­man cost is po­ten­tially worse, and it’s barely dis­cussed.

Writing code can put you in a flow state, men­tioned be­fore. That deep, fo­cused, cre­ative prob­lem-solv­ing where hours dis­ap­pear and you emerge with some­thing you built and un­der­stand. And you’re proud of it. Someone wrote un­der your PR “Good job!” and gave you an ap­proval. Reviewing AI-generated code does not do this. It’s the op­po­site. It’s a men­tal drain.

Developers need the dopamine hit of cre­ation. That’s not a perk, it’s what keeps good en­gi­neers en­gaged, learn­ing, re­tained, and pre­vents burnout. The joy of cod­ing is prob­a­bly what al­lowed them to be­come ex­pe­ri­enced devs in the first place. Replace cre­ation with over­sight and you get faster burnout, not faster ship­ping. You’ve turned en­gi­neer­ing, the cre­ative work, into the worst form of QA. The AI does all the art, the hu­man folds the laun­dry.

I use AI every day. I use AI heav­ily at work, I use AI in my side­pro­jects, and I don’t want to go back. I love it! That’s why I’m wor­ried. I’m afraid I be­came ad­dicted and de­pen­dent. I’ve im­ple­mented count­less cus­tom com­mands, skills, and agents. I check CC re­lease notes daily. And I know many are in sim­i­lar sit­u­a­tion right now, and we all won­der about what the fu­ture brings. Are we go­ing to re­place our­selves with AI? Or will we be re­spon­si­ble for clean­ing AI slop? What’s the right amount of AI us­age for me?

AI is just a tool. An ex­tra­or­di­nar­ily pow­er­ful one, but a tool nonethe­less. You would­n’t man­date that every en­gi­neer uses a spe­cific IDE, or mea­sure peo­ple on how many lines they write per day (…right?). You’d let them pick the tools that make them most ef­fec­tive and mea­sure what ac­tu­ally mat­ters, the work that ships.

The right amount of AI is not zero. And it’s not max­i­mum.

The Shen-Tamkin study iden­ti­fied six dis­tinct AI in­ter­ac­tion pat­terns among de­vel­op­ers. Three led to poor learn­ing: full del­e­ga­tion, pro­gres­sive re­liance, and out­sourc­ing de­bug­ging to AI. Three pre­served learn­ing even with full AI ac­cess: ask­ing for ex­pla­na­tions, pos­ing con­cep­tual ques­tions, and writ­ing code in­de­pen­dently while us­ing AI for clar­i­fi­ca­tion. The dif­fer­en­tia­tor was­n’t whether de­vel­op­ers used AI, it was whether they stayed cog­ni­tively en­gaged.

Software en­gi­neer­ing was never just about typ­ing code. It’s defin­ing the prob­lem well, un­der­stand­ing the prob­lem, trans­lat­ing the lan­guage from busi­ness to prod­uct to code, clar­i­fy­ing am­bi­gu­ity, mak­ing trade­offs, un­der­stand­ing what breaks when you change some­thing. Someone has to do that be­fore AGI, and AGI is nowhere close (luckily). You’re on call, the phone rings at 3am, can you triage the is­sue with­out an agent? If not, you’ve prob­a­bly taken AI cod­ing too far. If the AI us­age be­comes a new per­for­mance met­ric of de­vel­oper, maybe us­ing AI too of­ten, too much, should be dis­cour­aged as well? Not be­cause these tools are bad, but be­cause the cod­ing skills are worth main­tain­ing.

If you’re us­ing no AI at all in 2026, you are leav­ing real gains on the table:

* Search and con­text. AI is gen­uinely bet­ter than Google for nav­i­gat­ing un­fa­mil­iar code­bases, un­der­stand­ing legacy code, and find­ing rel­e­vant pat­terns. This alone jus­ti­fies hav­ing it in your work­flow (since 2023, Cursor etc)

* Boilerplate and scaf­fold­ing. Writing the hun­dredth CRUD end­point, con­fig file, or test scaf­fold by hand when an agent can pro­duce it in sec­onds is­n’t crafts­man­ship, it’s stub­born­ness. Just use AI. You’re not a CRUD de­vel­oper any­more any­way, be­cause we all wear many hats these days (post 2025 Sonnet)

* The work­flow it­self. The in­ves­ti­gate, plan, im­ple­ment, test, val­i­date cy­cle that works with cus­tomized agents is a real im­prove­ment in how fea­tures get de­liv­ered. Hours in­stead of days for non-triv­ial work. It’s not the 10x that was promised, but 2x or 4x on an es­tab­lished code­bases is low-hang­ing fruit. You must un­der­stand the out­put though and all the de­ci­sions AI made! (post 2025 Opus 4.5)

* Exploration. “What does this mod­ule do? How does this API work? What would break if I changed this?” AI is ex­cel­lent at these ques­tions. It won’t re­place read­ing the code, but it’ll get you to the right file in the right minute. (since 2023)

Refusing to use AI out of prin­ci­ple is as ir­ra­tional as adopt­ing it out of hype.

If you go all-in on au­tonomous AI cod­ing (especially with­out learn­ing how it all ac­tu­ally works), you risk some­thing worse than slow ve­loc­ity, you risk in­vis­i­ble degra­da­tion:

* Bugs that look like fea­tures. AI-generated code passes CI. The types check. The tests are green. And some­where in­side there’s a sub­tle logic er­ror, a hal­lu­ci­nated edge case, a pat­tern that’ll col­lapse un­der load. In do­mains like fi­nance or health­care, a wrong num­ber that does­n’t throw an er­ror is worse than a crash. (less and less rel­e­vant, but still rel­e­vant)

* A code­base no­body un­der­stands. When the agent writes every­thing and hu­mans only re­view, six months later no­body on the team can ex­plain why the sys­tem is ar­chi­tected the way it is. The AI made choices. Nobody ques­tioned them be­cause the tests passed. Storey de­scribes a stu­dent team that hit ex­actly this wall: they could­n’t make sim­ple changes with­out break­ing things, and the prob­lem was­n’t messy code, it was that no one could ex­plain why cer­tain de­sign de­ci­sions had been made. Her con­clu­sion: “velocity with­out un­der­stand­ing is not sus­tain­able.” (will al­ways be a prob­lem, IMO)

* Cognitive at­ro­phy. Everything in the Digital Dementia sec­tion above. Skills you stop prac­tic­ing will de­cline. (will al­ways be a prob­lem, IMO)

* The se­nior­ity pipeline dry­ing up. Also cov­ered above. This one takes years to man­i­fest, which is ex­actly why no­body’s plan­ning for it. (It’s a new prob­lem, I have no idea what it looks like in the fu­ture)

* Burnout. Reviewing AI out­put all day with­out the dopamine of cre­ation is not a sus­tain­able job de­scrip­tion. (Old prob­lem, but po­ten­tially hits faster?)

Here’s what keeps me up at night. By every met­ric on every dash­board, AI-assisted hu­man de­vel­op­ment and hu­man-as­sisted AI de­vel­op­ment is im­prov­ing. More PRs shipped. More fea­tures de­liv­ered. Faster cy­cle times. The charts go up and to the right.

But met­rics don’t cap­ture what’s hap­pen­ing un­der­neath. The men­tal fa­tigue of re­view­ing code you did­n’t write all day. The bore­dom of babysit­ting an agent in­stead of solv­ing prob­lems. The slow, in­vis­i­ble ero­sion of the hard skills that made you good at this job in the first place. You stop hold­ing the ar­chi­tec­ture in your head be­cause the agent han­dles it. You stop think­ing through edge cases be­cause the tests pass. You stop want­ing to dig deep be­cause it’s eas­ier to prompt and ap­prove. There’s no spark in you any­more.

In this meme the de­vel­op­ers are the but­ter ro­bot. The ones with no men­tal ca­pac­ity to re­view the plans and PRs from AI, will only click Accept, in­stead of do­ing the cre­ative, chal­leng­ing work. Oh the irony.

Simon Willison, one of the most am­bi­tious de­vel­oper of our time, ad­mit­ted this is al­ready hap­pen­ing to him. On pro­jects where he prompted en­tire fea­tures with­out re­view­ing im­ple­men­ta­tions, he “no longer has a firm men­tal model of what they can do and how they work.”

And then, one day, the met­rics start slip­ping… Not be­cause the tool got worse, but be­cause you did. Not from lack of ef­fort, but from lack of prac­tice. It’s a feed­back loop that looks like progress right up un­til it does­n’t.

No ex­ec­u­tive wants to mea­sure this. “What is the ef­fect of AI us­age on our en­gi­neers’ cog­ni­tive abil­i­ties over 18 months?” is not an easy KPI. It does­n’t fit in a quar­terly re­view. It does­n’t get tracked, and what does­n’t get tracked does­n’t get man­aged, un­til it shows up as a pro­duc­tion in­ci­dent that no­body on the team can de­bug with­out an agent, and the agent can’t de­bug ei­ther.

I’m not anti-AI, I like it a lot. I’m ad­dicted to prompt­ing, I get high from it. I’m just wor­ried that this new de­pen­dency de­grades us over time, qui­etly, and no­body’s watch­ing for it.

Introduction: Fascism at the End of Industrial Civilization

This es­say ar­gues that the United States is drift­ing to­ward a dis­tinctly twenty‑first‑cen­tury form of fas­cism dri­ven not by mass par­ties in brown­shirts, but by an oli­garchic techno‑feu­dal elite. Neoliberal cap­i­tal­ism has hol­lowed out de­mo­c­ra­tic in­sti­tu­tions and con­cen­trated power in a transna­tional “authoritarian in­ter­na­tional” of bil­lion­aires, se­cu­rity chiefs, and po­lit­i­cal fix­ers who mon­e­tize state power while shield­ing one an­other from ac­count­abil­ity. At the same time, Big Tech plat­forms have be­come neo‑feu­dal es­tates that ex­tract rent from our data and be­hav­ior, weaponize dis­in­for­ma­tion, and pro­vide the sur­veil­lance back­bone of an emerg­ing global po­lice state.

Drawing on the work of Robert Reich, William I. Robinson, Yanis Varoufakis, and oth­ers, along­side his­to­rian Heather Cox Richardson’s de­tailed ac­count of Trump‑era pa­tron­age, whistle­blower sup­pres­sion, and DHS/ICE mega‑de­ten­tion plans, the es­say con­tends that America is rapidly con­struct­ing a sys­tem of con­cen­tra­tion‑camp in­fra­struc­ture and para­mil­i­tary polic­ing de­signed to man­age “surplus” pop­u­la­tions and po­lit­i­cal dis­sent. Elite im­punity, en­trenched through na­tional‑se­cu­rity ex­cep­tion­al­ism, le­gal im­mu­ni­ties, and re­volv­ing‑door ca­reers, means that those di­rect­ing law­less vi­o­lence face vir­tu­ally no con­se­quences. Elections still hap­pen, courts still sit, news­pa­pers still pub­lish, but sub­stan­tive power is in­creas­ingly ex­er­cised by un­elected oli­garchs, tech lords, and se­cu­rity bu­reau­cra­cies.

This au­thor­i­tar­ian drift can­not be sep­a­rated from the broader cri­sis of in­dus­trial civ­i­liza­tion. Ecological over­shoot, cli­mate chaos, re­source con­straints, and struc­tural eco­nomic stag­na­tion have un­der­mined the promise of end­less growth on which lib­eral democ­racy once rested. Rather than us­ing the rem­nants of in­dus­trial wealth to de­moc­ra­tize a just tran­si­tion, rul­ing elites are hard­en­ing bor­ders, ex­pand­ing carceral in­fra­struc­ture, and build­ing a se­cu­rity regime to con­tain “surplus” hu­man­ity in a world of shrink­ing en­ergy and ma­te­r­ial through­put. America’s oli­garchic techno‑feu­dal fas­cism is thus not an anom­aly, but one plau­si­ble endgame of in­dus­trial civ­i­liza­tion: a strat­i­fied or­der of gated en­claves above and camps and pre­car­ity be­low, de­signed to pre­serve elite power as the old in­dus­trial world comes apart.

The American re­pub­lic was founded on a promise that power would be di­vided, con­strained, and an­swer­able: a writ­ten con­sti­tu­tion, sep­a­rated branches, pe­ri­odic elec­tions, and a Bill of Rights that set bright lines even the sov­er­eign could not cross. That promise was al­ways com­pro­mised by slav­ery, set­tler colo­nial­ism, and gen­dered ex­clu­sion, but it re­tained real, if un­even, force as a nor­ma­tive hori­zon. What has shifted over the past half‑cen­tury is not sim­ply the fa­mil­iar gap be­tween creed and prac­tice, but the un­der­ly­ing struc­ture of the sys­tem it­self: the cen­ter of grav­ity has moved from pub­lic in­sti­tu­tions to­ward a pri­vate oli­garchy whose wealth and lever­age al­low it to func­tion as a par­al­lel sov­er­eign.

The ne­olib­eral turn of the 1970s and 1980s marked the de­ci­sive in­flec­tion point. Deregulation, fi­nan­cial lib­er­al­iza­tion, the crush­ing of or­ga­nized la­bor, and the pri­va­ti­za­tion of pub­lic goods re­dis­trib­uted power and in­come up­ward on a his­toric scale. Trade lib­er­al­iza­tion and cap­i­tal mo­bil­ity al­lowed cor­po­ra­tions and in­vestors to pit gov­ern­ments and work­ers against one an­other, ex­tract­ing sub­si­dies and tax con­ces­sions un­der the per­ma­nent threat of cap­i­tal flight. At the same time, Supreme Court de­ci­sions eroded lim­its on po­lit­i­cal spend­ing, re­defin­ing “speech” as some­thing that could be pur­chased in un­lim­ited quan­ti­ties by those with the means.

The re­sult, as Robert Reich notes, has been the con­sol­i­da­tion of an American oli­garchy that “paved the road to fas­cism” by en­sur­ing that pub­lic pol­icy re­flects donor pref­er­ences far more con­sis­tently than pop­u­lar ma­jori­ties. In is­sue af­ter is­sue, such as tax­a­tion, la­bor law, health­care, and en­vi­ron­men­tal reg­u­la­tion, there is a clear skew: the wealthy get what they want more of­ten than not, while broadly pop­u­lar but re­dis­trib­u­tive poli­cies rou­tinely die in com­mit­tee or are gut­ted be­yond recog­ni­tion. This is not a con­spir­acy in the melo­dra­matic sense; it is how the wiring of the sys­tem now works.

William Robinson’s analy­sis of “twenty‑first‑century fas­cism” sharp­ens the point. Global cap­i­tal­ism in its cur­rent form gen­er­ates chronic crises: over­pro­duc­tion, un­der‑con­sump­tion, eco­log­i­cal break­down, and a grow­ing pop­u­la­tion that cap­i­tal can­not prof­itably em­ploy. Under such con­di­tions, de­mo­c­ra­tic pol­i­tics be­comes dan­ger­ous for elites, be­cause elec­torates might choose struc­tural re­forms such as wealth taxes, pub­lic own­er­ship, strong unions, and Green New Deal‑style tran­si­tions that would curb prof­its. Faced with this prospect, seg­ments of transna­tional cap­i­tal be­gin to see au­thor­i­tar­ian so­lu­tions as ra­tio­nal: bet­ter to hol­low out democ­racy, harden bor­ders, and con­struct a global po­lice state than to ac­cept se­ri­ous re­dis­tri­b­u­tion.

American pol­i­tics in the early twenty‑first cen­tury fits this pat­tern with un­set­tling pre­ci­sion. A de­cay­ing in­fra­struc­ture, stag­nant wages, bal­loon­ing per­sonal debt, mil­i­ta­rized polic­ing, and per­ma­nent war have pro­duced wide­spread dis­il­lu­sion­ment. As faith in in­sti­tu­tions erodes, pub­lic life is flooded with re­sent­ment and ni­hilism that can be redi­rected against scape­goats (immigrants, racial mi­nori­ties, fem­i­nists, and queer and trans peo­ple) rather than against the oli­garchic‑power‑com­plex that prof­its from the de­cay. It is in this vac­uum that a fig­ure like Donald Trump thrives: a bil­lion­aire dem­a­gogue able to chan­nel anger away from the class that ac­tu­ally gov­erns and to­ward those even more mar­gin­al­ized.

The de­ci­sive shift from plu­to­cratic dys­func­tion to fas­cist dan­ger oc­curs when oli­garchs cease to see con­sti­tu­tional democ­racy as even in­stru­men­tally use­ful and in­stead in­vest in move­ments openly com­mit­ted to mi­nor­ity rule. Koch‑style net­works, Mercer‑funded op­er­a­tions, and Silicon Valley donors will­ing to un­der­write hard‑right pro­jects are not sup­port­ing democ­racy‑en­hanc­ing re­forms; they are build­ing the in­fra­struc­ture for au­thor­i­tar­i­an­ism, from voter sup­pres­sion to ide­o­log­i­cal me­dia to data‑dri­ven pro­pa­ganda. The sys­tem that emerges is hy­brid: elec­tions still oc­cur, courts still sit, news­pa­pers still pub­lish, but sub­stan­tive power is in­creas­ingly con­cen­trated in un­elected hands.

II. The “authoritarian in­ter­na­tional” and the shadow world of deals

Historian Heather Cox Richardson’s re­cent analy­sis cap­tures a for­ma­tion that much main­stream com­men­tary still strug­gles to name: a transna­tional “authoritarian in­ter­na­tional” in which oli­garchs, po­lit­i­cal op­er­a­tives, royal fam­i­lies, se­cu­rity chiefs, and or­ga­nized crim­i­nals co­op­er­ate to mon­e­tize state power while pro­tect­ing one an­other from scrutiny. This is not a for­mal al­liance; it is an over­lap­ping ecol­ogy of re­la­tion­ships, ex­clu­sive va­ca­tions, in­vest­ment ve­hi­cles, shell com­pa­nies, foun­da­tions, and in­tel­li­gence ties, through which in­for­ma­tion, fa­vors, and money flow.​

The key is that this net­work is struc­turally post‑ide­o­log­i­cal. As Robert Mueller warned in his 2011 de­scrip­tion of an emerg­ing “iron tri­an­gle” of politi­cians, busi­ness­peo­ple, and crim­i­nals, these ac­tors are not pri­mar­ily con­cerned with re­li­gion, na­tion­al­ity, or tra­di­tional ide­ol­ogy. They will work across con­fes­sional and na­tional lines so long as the deals are lu­cra­tive and risk is man­age­ably so­cial­ized onto oth­ers. Saudi roy­als in­vest along­side Western hedge funds; Russian oli­garchs laun­der money through London prop­erty and American pri­vate eq­uity; Israeli and Emirati firms col­lab­o­rate with U. S. tech com­pa­nies on sur­veil­lance prod­ucts that are then sold world­wide.​

Within this mi­lieu, the for­mal dis­tinc­tion be­tween pub­lic of­fice and pri­vate in­ter­est blurs. Richardson’s analy­sis of Donald Trump’s abrupt re­ver­sal on the Gordie Howe International Bridge af­ter a com­plaint by a bil­lion­aire com­peti­tor with ties to Jeffrey Epstein—reads less like the ex­er­cise of pub­lic pol­icy judg­ment and more like feu­dal pa­tron­age: the sov­er­eign in­ter­venes to pro­tect a fa­vored lord’s toll road. Tiny shifts in reg­u­la­tory pos­ture or fed­eral sup­port can move bil­lions of dol­lars; for those ac­cus­tomed to hav­ing the pres­i­den­t’s ear, such in­ter­ven­tions are sim­ply part of do­ing busi­ness.​​

The same logic gov­erns for­eign pol­icy. The Trump‑Kushner axis ex­em­pli­fies this fu­sion of pub­lic and pri­vate. When a whistle­blower al­leges that the Director of National Intelligence sup­pressed an in­ter­cept in­volv­ing for­eign of­fi­cials dis­cussing Jared Kushner and sen­si­tive top­ics like Iran, and when the com­plaint is then choked off with ag­gres­sive redac­tion and ex­ec­u­tive priv­i­lege, we see the ma­chin­ery of se­crecy mis­used not to pro­tect the na­tional in­ter­est but to shield a mem­ber of the fam­ily‑cum‑busi­ness em­pire at the cen­ter of power. It is as if the state has be­come a fam­ily of­fice with nu­clear weapons.​​

Josh Marshall’s phrase “authoritarian in­ter­na­tional” is apt be­cause it names both the class com­po­si­tion and the po­lit­i­cal func­tion of this net­work. The same names re­cur across far‑right pro­jects: donors and strate­gists who back na­tion­al­ist par­ties in Europe, ul­tras in Latin America, Modi’s BJP in India, and the MAGA move­ment in the United States. Their in­ter­ests are not iden­ti­cal, but they over­lap around a shared agenda: weak­en­ing la­bor and en­vi­ron­men­tal pro­tec­tions, un­der­min­ing in­de­pen­dent me­dia and courts, mil­i­ta­riz­ing bor­ders, and se­cur­ing im­mu­nity for them­selves and their peers.​

This world is lu­bri­cated by black­mail and mu­tu­ally as­sured de­struc­tion. As Richardson notes, play­ers of­ten seem to hold com­pro­mis­ing ma­te­r­ial on one an­other, whether in the form of doc­u­mented sex­ual abuse, fi­nan­cial crime, or war crimes. This shared vul­ner­a­bil­ity para­dox­i­cally sta­bi­lizes the net­work: as long as every­one has some­thing on every­one else, de­fec­tion is dan­ger­ous, and a preda­tory equi­lib­rium holds. From the stand­point of de­mo­c­ra­tic publics, how­ever, this sta­bil­ity is cat­a­strophic, be­cause it means that scan­dal—once a mech­a­nism for en­forc­ing norms—loses much of its power. When “everyone is dirty,” no one can be clean enough to pros­e­cute the oth­ers with­out risk­ing ex­po­sure.​​

III. Techno‑feudal aris­toc­racy and the col­o­niza­tion of every­day life

Layered atop this transna­tional oli­garchy is the dig­i­tal or­der that Varoufakis and oth­ers de­scribe as techno‑feu­dal­ism: a regime in which a hand­ful of plat­forms func­tion like neo‑feu­dal es­tates, ex­tract­ing rent from their “serfs” (users, gig work­ers, con­tent cre­ators) rather than com­pet­ing in open mar­kets. This shift is more than metaphor. In clas­si­cal cap­i­tal­ism, firms prof­ited pri­mar­ily by pro­duc­ing goods or ser­vices and sell­ing them on mar­kets where com­peti­tors could, in prin­ci­ple, un­der­cut them. In the plat­form or­der, gate­keep­ers profit by con­trol­ling ac­cess to the mar­ket­place it­self, im­pos­ing opaque terms on those who must use their in­fra­struc­ture to com­mu­ni­cate, work, or even find hous­ing.

This can be seen across sec­tors:

Social me­dia plat­forms own the dig­i­tal pub­lic square. They mon­e­tize at­ten­tion by sell­ing ad­ver­tis­ers ac­cess to finely sliced de­mo­graphic and psy­cho­graphic seg­ments, while their rec­om­men­da­tion al­go­rithms op­ti­mize for en­gage­ment, of­ten by priv­i­leg­ing out­rage and fear.

Ride‑hailing and de­liv­ery apps con­trol the in­ter­face be­tween cus­tomers and la­bor, set­ting prices uni­lat­er­ally and dis­ci­plin­ing work­ers through rat­ings, al­go­rith­mic man­age­ment, and the ever‑pre­sent threat of “deactivation.”​

Cloud providers and app stores gate­keep ac­cess to the ba­sic in­fra­struc­ture upon which count­less smaller firms de­pend, tak­ing a cut of trans­ac­tions and re­serv­ing the right to change terms or re­move com­peti­tors from the ecosys­tem en­tirely.

In each case, the plat­form is less a com­pany among com­pa­nies and more a land­lord among ten­ants, col­lect­ing tolls for the right to ex­ist within its do­main. Users pro­duce the very cap­i­tal stock, data, con­tent, be­hav­ioral pro­files, that plat­forms own and mon­e­tize, yet they have lit­tle say over how this ma­te­r­ial is used or how the dig­i­tal en­vi­ron­ment is struc­tured. The asym­me­try of power is pro­found: the lords can al­ter the code of the world; the serfs can, at best, ad­just their be­hav­ior to avoid al­go­rith­mic in­vis­i­bil­ity or sanc­tion.

For au­thor­i­tar­ian pol­i­tics, this struc­ture is a gift. First, plat­forms have be­come the pri­mary vec­tors of dis­in­for­ma­tion and pro­pa­ganda. Cambridge Analytica’s work for Trump in 2016, funded by bil­lion­aires like the Mercers, was an early pro­to­type: har­vest data, mi­cro‑tar­get in­di­vid­u­als with tai­lored mes­sag­ing, and flood their feeds with nar­ra­tives de­signed to ac­ti­vate fear and re­sent­ment. Since then, the tech­niques have grown more so­phis­ti­cated, and far‑right move­ments world­wide have learned to weaponize meme cul­ture, con­spir­acy the­o­ries, and “shitposting” as re­cruit­ment tools.​

Second, the same in­fra­struc­tures that en­able tar­geted ad­ver­tis­ing en­able gran­u­lar sur­veil­lance. Location data, so­cial graphs, search his­to­ries, and fa­cial‑recog­ni­tion data­bases pro­vide an un­prece­dented toolkit for mon­i­tor­ing and dis­ci­plin­ing pop­u­la­tions. In the hands of a regime slid­ing to­ward fas­cism, these tools can be turned against dis­si­dents with ter­ri­fy­ing ef­fi­ciency: ge­ofenc­ing protests to iden­tify at­ten­dees, scrap­ing so­cial me­dia to build dossiers, us­ing AI to flag “pre‑criminal” be­hav­ior. The emerg­ing “global po­lice state” that Robinson de­scribes de­pends heav­ily on such techno‑feu­dal ca­pac­i­ties.

Third, the dig­i­tal or­der cor­rodes the very pre­con­di­tions for de­mo­c­ra­tic de­lib­er­a­tion. Information over­load, fil­ter bub­bles, and al­go­rith­mic am­pli­fi­ca­tion of sen­sa­tional con­tent pro­duce a pub­lic sphere sat­u­rated with noise. Under these con­di­tions, truth be­comes just an­other aes­thetic, and the dis­tinc­tion be­tween fact and fic­tion col­lapses into vibes. This is the post‑mod­ern ni­hilism you name: a sense that noth­ing is sta­ble enough to be­lieve in, that every­thing is spin. Fascist move­ments do not seek to re­solve this con­di­tion; they weaponize it, in­sist­ing that only the Leader and his trusted me­dia tell the real truth, while every­thing else is a hos­tile lie.

Finally, the techno‑feu­dal aris­toc­ra­cy’s ma­te­r­ial in­ter­ests align with au­thor­i­tar­i­an­ism. Privacy reg­u­la­tions, an­titrust en­force­ment, data lo­cal­iza­tion rules, and strong la­bor rights all threaten plat­form prof­its. Democratic move­ments that de­mand such re­forms are there­fore ad­ver­saries. Conversely, strong­man lead­ers who promise dereg­u­la­tion, tax breaks, and law‑and‑or­der crack­downs, even if they oc­ca­sion­ally threaten spe­cific firms, are of­ten ac­cept­able part­ners. The re­sult is a con­ver­gence: oli­garchs of data and oli­garchs of oil, real es­tate, and fi­nance find­ing com­mon cause in an or­der that dis­ci­plines the many and ex­empts the few.

IV. Elite im­punity and the ma­chin­ery of law­less­ness

Authoritarianism is not only about who holds power; it is about who is an­swer­able for wrong­do­ing. A sys­tem where elites can vi­o­late laws with im­punity while or­di­nary peo­ple are pun­ished harshly for mi­nor in­frac­tions is al­ready halfway to fas­cism, what­ever la­bels it wears. The United States has, over re­cent decades, con­structed pre­cisely such a sys­tem.

The Arab Center’s “Machinery of Impunity” re­port de­tails how, in ar­eas rang­ing from mass sur­veil­lance to for­eign wars to do­mes­tic polic­ing, se­nior of­fi­cials who au­tho­rize il­le­gal acts al­most never face crim­i­nal con­se­quences. Edward Snowden’s rev­e­la­tions ex­posed sys­temic vi­o­la­tions of pri­vacy and civil lib­er­ties, yet it was the whistle­blower who faced pros­e­cu­tion and ex­ile, not the ar­chi­tects of the pro­grams. Torture dur­ing the “war on ter­ror” was ac­knowl­edged, even doc­u­mented in of­fi­cial re­ports, but those who de­signed and ap­proved the tor­ture regime kept their law li­censes, aca­d­e­mic posts, and me­dia gigs. Lethal strikes on small boats in the Caribbean and Pacific, jus­ti­fied by se­cret in­tel­li­gence and shielded by clas­si­fied le­gal opin­ions, have killed dozens with no pub­lic ev­i­dence that the tar­gets posed im­mi­nent threats.

This pat­tern is not an aber­ra­tion but a fea­ture. As a Penn State law re­view ar­ti­cle notes, the U. S. le­gal sys­tem builds in mul­ti­ple lay­ers of pro­tec­tion for high of­fi­cials: sov­er­eign im­mu­nity, state se­crets priv­i­lege, nar­row stand­ing rules, and pros­e­cu­to­r­ial dis­cre­tion all com­bine to make it ex­tra­or­di­nar­ily dif­fi­cult to hold the pow­er­ful to ac­count. Violations of the Hatch Act, cam­paign‑fi­nance laws, or ethics rules are of­ten treated as tech­ni­cal­i­ties, and when re­ports do doc­u­ment un­law­ful be­hav­ior, as in the case of Mike Pompeo’s par­ti­san abuse of his diplo­matic of­fice, there are “no con­se­quences” be­yond mild cen­sure. Jamelle Bouie’s re­cent video es­say for the New York Times dri­ves the point home: America is “bad at ac­count­abil­ity” be­cause in­sti­tu­tions have been de­signed and in­ter­preted to fa­vor elite im­punity.

Richardson shows how this cul­ture func­tions in­side the na­tional‑se­cu­rity state. A whistle­blower com­plaint al­leg­ing that the Director of National Intelligence sup­pressed an in­tel­li­gence in­ter­cept in­volv­ing Jared Kushner and for­eign of­fi­cials was not al­lowed to run its course. Instead, it was bot­tled up, then trans­mit­ted to con­gres­sional over­seers in a highly redacted form, with ex­ec­u­tive priv­i­lege in­voked to shield the pres­i­den­t’s in­volve­ment. The same mech­a­nisms that in­su­late covert op­er­a­tions abroad from de­mo­c­ra­tic over­sight are de­ployed to pro­tect do­mes­tic po­lit­i­cal al­lies from scrutiny.​

Immigration en­force­ment of­fers an­other win­dow. The Arab Center notes that ICE raids, fam­ily sep­a­ra­tion, and other abuses “escalated un­der the cur­rent Trump ad­min­is­tra­tion into highly vis­i­ble kid­nap­pings, abuse, and de­por­ta­tions” with lit­tle ac­count­abil­ity for se­nior of­fi­cials. The National Immigrant Justice Center doc­u­ments a de­ten­tion sys­tem where 90 per­cent of de­tainees are held in for‑profit fa­cil­i­ties, where med­ical ne­glect, puni­tive soli­tary con­fine­ment, and pre­ventable deaths are com­mon, yet con­tracts are re­newed and ex­panded. A cul­ture of im­punity al­lows agents and man­agers to treat rights vi­o­la­tions not as ca­reer‑end­ing scan­dals but as ac­cept­able col­lat­eral dam­age.

Latin American schol­ars of im­punity warn that such se­lec­tive en­force­ment pro­duces a “quiet cri­sis of ac­count­abil­ity” in which the rule of law is hol­lowed out from within. Laws re­main on the books, but their ap­pli­ca­tion is skewed: harsh on the poor and mar­gin­al­ized, per­mis­sive to­ward the pow­er­ful. Over time, this nor­mal­izes the idea that some peo­ple are above the law, while oth­ers ex­ist pri­mar­ily as ob­jects of con­trol. When a polity in­ter­nal­izes this hi­er­ar­chy, fas­cism no longer needs to ar­rive in jack­boots; it is al­ready pre­sent in the daily op­er­a­tions of the jus­tice sys­tem.​

The dan­ger, as the Arab Center em­pha­sizes, is that the costs of im­punity “come home to roost.” Powers orig­i­nally jus­ti­fied as nec­es­sary to fight ter­ror­ism or for­eign en­e­mies mi­grate back into do­mes­tic pol­i­tics. Surveillance tools built for for­eign in­tel­li­gence mon­i­tor­ing are turned on ac­tivists and jour­nal­ists; mil­i­ta­rized po­lice tac­tics per­fected in oc­cu­pied ter­ri­to­ries are im­ported into American streets. A pop­u­la­tion taught to ac­cept law­less vi­o­lence against out­siders (migrants, for­eign­ers, en­emy pop­u­la­tions) is grad­u­ally con­di­tioned to ac­cept sim­i­lar vi­o­lence against in­ter­nal op­po­nents.

In this con­text of oli­garchic cap­ture, techno‑feu­dal con­trol, and elite im­punity, the rapid ex­pan­sion of de­ten­tion in­fra­struc­ture and the de­ploy­ment of para­mil­i­tary “federal agents” across the in­te­rior United States are not aber­ra­tions; they are cen­tral pil­lars of an emer­gent fas­cist or­der.​

Richardson’s in­sis­tence on call­ing these fa­cil­i­ties con­cen­tra­tion camps is an­a­lyt­i­cally ex­act. A con­cen­tra­tion camp, in the his­tor­i­cal sense, is not nec­es­sar­ily a death camp; it is a place where a state con­cen­trates pop­u­la­tions it con­sid­ers threats or bur­dens, sub­ject­ing them to con­fine­ment, dis­ease, abuse, and of­ten death through ne­glect rather than in­dus­tri­al­ized ex­ter­mi­na­tion. By that de­f­i­n­i­tion, the sprawl­ing net­work of ICE and Border Patrol de­ten­tion cen­ters, where peo­ple are ware­housed for months to years, of­ten in hor­rific con­di­tions, qual­i­fies.​

New re­port­ing de­tails how this sys­tem is poised to scale up dra­mat­i­cally. An in­ter­nal ICE memo, re­cently sur­faced, out­lines a $38 bil­lion plan for a “new de­ten­tion cen­ter model” that would, in one year, cre­ate ca­pac­ity for roughly 92,600 peo­ple by pur­chas­ing eight “mega cen­ters,” 16 pro­cess­ing cen­ters, and 10 ad­di­tional fa­cil­i­ties. The largest of these ware­houses would hold be­tween 7,000 and 10,000 peo­ple each for av­er­age stays of about 60 days, more than dou­ble the size of the largest cur­rent fed­eral prison. Separate re­port­ing has mapped at least 23 in­dus­trial ware­houses be­ing sur­veyed for con­ver­sion into mass de­ten­tion camps, with leases al­ready se­cured at sev­eral sites.​

Investigations by Amnesty International and oth­ers into pro­to­type fa­cil­i­ties have found de­tainees shack­led in over­crowded cages, un­der­fed, forced to use open‑air toi­lets that flood, and rou­tinely de­nied med­ical care. Sexual as­sault and ex­tor­tion by guards, neg­li­gent deaths, and at least one homi­cide have been doc­u­mented. These are not ac­ci­dents; they are pre­dictable out­comes of a profit‑dri­ven sys­tem where pri­vate con­trac­tors are paid per bed and over­sight is weak, and of a po­lit­i­cal cul­ture that de­hu­man­izes mi­grants as “invaders” or “animals.”

Richardson high­lights an­other cru­cial di­men­sion: the way DHS has been re­tooled to pro­ject this vi­o­lence into the in­te­rior as a form of po­lit­i­cal ter­ror. Agents from ICE and Border Patrol, sub­di­vi­sions of a rel­a­tively new de­part­ment lack­ing the in­sti­tu­tional re­straints of the mil­i­tary, have been de­ployed in cities far from any bor­der, of­ten in un­marked ve­hi­cles, wear­ing masks and lack­ing vis­i­ble iden­ti­fi­ca­tion. Secret le­gal memos un­der Trump gut­ted the tra­di­tional re­quire­ment of a ju­di­cial war­rant for en­ter­ing homes, re­plac­ing it with in­ter­nal sign‑off by an­other DHS of­fi­cial, a di­rect vi­o­la­tion of the Fourth Amendment’s pro­tec­tion against un­rea­son­able searches and seizures.​

This mat­ters both in­stru­men­tally and sym­bol­i­cally. Instrumentally, it en­ables ef­fi­cient mass raids and “snatch and grab” op­er­a­tions that by­pass lo­cal law‑en­force­ment norms and ju­di­cial over­sight. Symbolically, it com­mu­ni­cates that the state re­serves the right to op­er­ate as a law­less force, un­con­strained by the very con­sti­tu­tion it claims to de­fend. When masked, uniden­ti­fied agents can seize peo­ple off the streets, shove them into un­marked vans, and de­posit them in pro­cess­ing cen­ters with­out due process, the aes­thetic of fas­cism…thugs in the night…be­comes re­al­ity.​

Richardson rightly con­nects this to the post‑Re­con­struc­tion South, where para­mil­i­tary groups like the Ku Klux Klan, of­ten tol­er­ated or qui­etly aided by lo­cal of­fi­cials, used ter­ror to de­stroy a bira­cial democ­racy that had briefly flour­ished. Today’s dif­fer­ence is that com­mu­ni­ca­tions tech­nol­ogy al­lows rapid mo­bi­liza­tion of wit­nesses and counter‑pro­test­ers: peo­ple can rush to the scene when agents ar­rive, doc­u­ment abuses on smart­phones, and co­or­di­nate le­gal sup­port. Yet even this can be folded into the logic of spec­ta­cle. The im­ages of mil­i­ta­rized agents con­fronting crowds un­der the glow of street­lights and po­lice flood­lamps serve as warn­ings: this is what hap­pens when you re­sist.​​

The planned net­work of pro­cess­ing cen­ters and mega‑ware­houses adds an­other layer of men­ace. As Richardson points out, if the stated goal is de­por­ta­tion, there is no clear need for fa­cil­i­ties ca­pa­ble of im­pris­on­ing tens of thou­sands for months. Part of the an­swer is co­er­cive lever­age: de­tained peo­ple are eas­ier to pres­sure into aban­don­ing asy­lum claims and ac­cept­ing re­moval, es­pe­cially when they are told, day af­ter day, that they could walk free if they “just sign.” But the ar­chi­tec­ture also an­tic­i­pates a fu­ture in which new cat­e­gories of in­ter­nal en­e­mies, pro­test­ers, “Antifa,” “domestic ex­trem­ists,” can be fun­neled into the same carceral es­tate once mi­grant flows di­min­ish or po­lit­i­cal needs change.​

Economically, the camps gen­er­ate their own con­stituency. ICE and DHS tout job cre­ation num­bers to lo­cal of­fi­cials, promis­ing hun­dreds of sta­ble, of­ten union‑free po­si­tions in com­mu­ni­ties hol­lowed out by dein­dus­tri­al­iza­tion. Private prison firms and con­struc­tion com­pa­nies see lu­cra­tive con­tracts; in­vestors see se­cure re­turns backed by fed­eral guar­an­tees. A web of stake­hold­ers thus be­comes ma­te­ri­ally in­vested in the con­tin­u­a­tion and ex­pan­sion of mass de­ten­tion. This is techno‑feu­dal­ism in con­crete and ra­zor wire: a carceral es­tate in which bod­ies are the rent‑pro­duc­ing as­set.

Once such an es­tate ex­ists, its logic tends to spread. Border‑style tac­tics mi­grate into or­di­nary polic­ing; sur­veil­lance tools tri­aled on mi­grants are turned on do­mes­tic move­ments; le­gal doc­trines crafted to jus­tify raids and war­rant­less searches in the name of im­mi­gra­tion con­trol seep into other do­mains. The fas­cist gra­di­ent steep­ens: more peo­ple find them­selves at risk of sud­den dis­ap­pear­ance into a sys­tem where rights are the­o­ret­i­cal and vi­o­lence is rou­tine.

Arab Center Washington DC. “The Machinery of Impunity: How Washington’s Elite Stays Above the Law and How to End It.” December 2, 2025. https://​arab­cen­terdc.org/​re­source/​the-ma­chin­ery-of-im­punity-how-wash­ing­tons-elite-stays-above-the-law-and-how-to-end-it/.

Bouie, Jamelle. “Opinion | America Is Bad at Accountability.” New York Times video, January 5, 2026. https://​www.ny­times.com/​video/​opin­ion/​100000010627706/​amer­ica-is-bad-at-ac­count­abil­ity.html.

Courier Newsroom. “MAP: All 23 Industrial Warehouses ICE Wants to Turn into Detention ‘Death Camps’.” February 9, 2026. https://​couri­ernews­room.com/​news/​map-ice-de­ten­tion-ware­house/.

Hampton Institute. “The End of an Empire: Systemic Decay and the Economic Foundation of American Fascism.” June 8, 2025. https://​www.hamp­ton­think.org/​read/​the-end-of-an-em­pire-sys­temic-de­cay-and-the-eco­nomic-foun­da­tion-of-amer­i­can-fas­cism.

“Impunity by Design: Latin America’s Quiet Crisis of Accountability.” Just Security, November 9, 2025. https://​www.just­se­cu­rity.org/​124089/​im­punity-by-de­sign-latin-amer­i­cas-quiet-cri­sis-of-ac­count­abil­ity/.

Penn State Journal of Law & International Affairs. “Caught in the Act but Not Punished: On Elite Rule of Law and Impunity.” 2016. https://​in­sight.dick­in­son­law.psu.edu/​cgi/​view­con­tent.cgi?ar­ti­cle=1144&con­text=jlia.

Reich, Robert. “How America’s Oligarchy Has Paved the Road to Fascism (Why American Democracy Is on the Brink).” Substack, January 4, 2024. https://​robertre­ich.sub­stack.com/​p/​the-amer­i­can-oli­garchy-why-is-amer­i­can.

Robinson, William I. “Global Capitalism and Twenty-First Century Fascism: A U. S. Case Study.” Race & Class 48, no. 2 (2006): 13–30. https://​robin­son.fac­ulty.soc.ucsb.edu/​As­sets/​pdf/​race­and­class.pdf.

Transnational Institute. “Follow the Money: The Business Interests Behind the Far Right.” February 2, 2026. https://​www.tni.org/​en/​ar­ti­cle/​fol­low-the-money-the-busi­ness-in­ter­ests-be­hind-the-far-right.