In 2023, Raytheon’s pres­i­dent stood at the Paris Air Show and de­scribed what it took to restart Stinger mis­sile pro­duc­tion. They brought back en­gi­neers in their 70s to teach younger work­ers how to build a mis­sile from pa­per schemat­ics drawn dur­ing the Carter ad­min­is­tra­tion. Test equip­ment had been sit­ting in ware­houses for years. The nose cone still had to be at­tached by hand, ex­actly as it was forty years ago.

The Pentagon had­n’t bought a new Stinger in twenty years. Then Russia in­vaded Ukraine, and sud­denly every­one needed them. The pro­duc­tion line was shut down. The elec­tron­ics were ob­so­lete. The seeker com­po­nent was out of pro­duc­tion. An or­der placed in May 2022 would­n’t de­liver un­til 2026. Four years. Not be­cause of money. Because the peo­ple who knew how to build them re­tired a decade ear­lier and no­body re­placed them.

I run en­gi­neer­ing teams in Ukraine. My peo­ple lived the other side of this equa­tion. Not the fac­tory floor. The re­ceiv­ing end. While Raytheon was strug­gling to restart pro­duc­tion from forty-year-old blue­prints, the US was ship­ping thou­sands of Stingers to Ukraine. RTX CEO Greg Hayes: ten months of war burned through thir­teen years’ worth of Stinger pro­duc­tion. I’ve seen this pat­tern be­fore. It’s hap­pen­ing in my in­dus­try right now.

In March 2023, the EU promised Ukraine one mil­lion ar­tillery shells within twelve months. European pro­duc­tion ca­pac­ity sat at 230,000 shells per year. Ukraine was con­sum­ing 5,000 to 7,000 rounds per day. Anyone with a cal­cu­la­tor could see this would­n’t work.

By the dead­line, Europe de­liv­ered about half. Macron called the orig­i­nal promise reck­less. An in­ves­ti­ga­tion by eleven me­dia out­lets across nine coun­tries found ac­tual pro­duc­tion ca­pac­ity was roughly one-third of of­fi­cial EU claims. The mil­lion-shell mark was­n’t hit un­til December 2024, nine months late.

It was­n’t one bot­tle­neck. It was all of them. France had halted do­mes­tic pro­pel­lant pro­duc­tion in 2007. Seventeen years of noth­ing. Europe’s sin­gle ma­jor TNT pro­ducer was in Poland. Germany had two days of am­mu­ni­tion stored. A Nammo plant in Denmark was shut down in 2020 and had to be restarted from scratch. The en­tire con­ti­nen­t’s de­fense in­dus­try had been op­ti­mized for mak­ing small batches of ex­pen­sive cus­tom prod­ucts. Nobody planned for vol­ume. Nobody planned for cri­sis.

The U.S. was­n’t much bet­ter. One plant in Scranton, one fa­cil­ity in Iowa for ex­plo­sive fill, no do­mes­tic TNT pro­duc­tion since 1986. Billions of in­vest­ment later, pro­duc­tion still had­n’t hit half the tar­get.

This was­n’t an ac­ci­dent. In 1993, the Pentagon told de­fense CEOs to con­sol­i­date or die. Fifty-one ma­jor de­fense con­trac­tors col­lapsed into five. Tactical mis­sile sup­pli­ers went from thir­teen to three. Shipbuilders from eight to two. The work­force fell from 3.2 mil­lion to 1.1 mil­lion. A 65% cut.

The am­mu­ni­tion sup­ply chain had sin­gle points of fail­ure every­where. One man­u­fac­turer for 155mm shell cas­ings, sit­ting in Coachella, California, on the San Andreas Fault. One fa­cil­ity in Canada for pro­pel­lant charges. Optimized for min­i­mum cost with zero mar­gin for surge. On pa­per, ef­fi­cient. In prac­tice, one bad day away from col­lapse.

Then there’s Fogbank. A clas­si­fied ma­te­r­ial used in nu­clear war­heads. Produced from 1975 to 1989, then the fa­cil­ity was shut down. When the gov­ern­ment needed to re­pro­duce it for a war­head life ex­ten­sion pro­gram in 2000, they dis­cov­ered they could­n’t. A GAO re­port found that al­most all staff with pro­duc­tion ex­per­tise had re­tired, died, or left the agency. Few records ex­isted.

After spend­ing an ad­di­tional $69 mil­lion and years of re­verse en­gi­neer­ing, they fi­nally pro­duced vi­able Fogbank. Then dis­cov­ered the new batch was too pure. The orig­i­nal had con­tained an un­in­ten­tional im­pu­rity that was crit­i­cal to its func­tion. That fact ex­isted nowhere in any doc­u­ment. Only the work­ers who made the orig­i­nal batch knew it, and they had re­tired years ear­lier.

A nu­clear weapons pro­gram lost the abil­ity to make a ma­te­r­ial it in­vented. The knowl­edge ex­isted only in peo­ple, and the peo­ple were gone.

I read the Fogbank story and rec­og­nized it im­me­di­ately. Not the nu­clear ma­te­r­ial. The pat­tern. Build ca­pa­bil­ity over decades. Find a cheaper sub­sti­tute. Let the hu­man pipeline at­ro­phy. Enjoy the sav­ings. Then watch it all col­lapse when a cri­sis de­mands what you op­ti­mized away.

In de­fense, the sub­sti­tute was the peace div­i­dend. In soft­ware, it’s AI.

I wrote about the tal­ent pipeline col­lapse be­fore. The hir­ing num­bers and the ju­nior-to-se­nior prob­lem are doc­u­mented. So is the com­pre­hen­sion cri­sis. What I did­n’t have was the right his­tor­i­cal par­al­lel. Now I do.

And it tells you some­thing the hir­ing data does­n’t: how long re­build­ing ac­tu­ally takes.

Every ma­jor de­fense pro­duc­tion ramp-up took three to five years for sim­ple sys­tems. Five to ten for com­plex ones. Stinger: thirty months min­i­mum from or­der to de­liv­ery. Javelin: four and a half years to less than dou­ble pro­duc­tion. 155mm shells: four years and still not at tar­get de­spite five bil­lion dol­lars in­vested. France only restarted pro­pel­lant pro­duc­tion in 2024, sev­en­teen years af­ter shut­ting it down.

Money was never the con­straint. Knowledge was. RAND found that 10% of tech­ni­cal skills for sub­ma­rine de­sign need ten years of on-the-job ex­pe­ri­ence to de­velop, some­times fol­low­ing a PhD. Apprenticeships in de­fense trades take two to four years, with five to eight years to reach su­per­vi­sory com­pe­tence.

Now map that onto soft­ware. A ju­nior de­vel­oper needs three to five years to be­come a com­pe­tent mid-level en­gi­neer. Five to eight years to be­come se­nior. Ten or more to be­come a prin­ci­pal or ar­chi­tect. That time­line can’t be com­pressed by throw­ing money at it. It can’t be com­pressed by AI ei­ther.

A METR ran­dom­ized con­trolled trial found that ex­pe­ri­enced de­vel­op­ers us­ing AI cod­ing tools ac­tu­ally took 19% longer on real-world open source tasks. Before start­ing, they pre­dicted AI would make them 24% faster. The gap be­tween pre­dic­tion and re­al­ity was 43 per­cent­age points. When re­searchers tried to run a fol­low-up, a sig­nif­i­cant share of de­vel­op­ers re­fused to par­tic­i­pate if it meant work­ing with­out AI. They could­n’t imag­ine go­ing back.

The soft­ware in­dus­try is in year three of the same op­ti­miza­tion. Salesforce said it won’t hire more soft­ware en­gi­neers in 2025. A LeadDev sur­vey found 54% of en­gi­neer­ing lead­ers be­lieve AI copi­lots will re­duce ju­nior hir­ing long-term. A CRA sur­vey of uni­ver­sity com­put­ing de­part­ments found 62% re­ported de­clin­ing en­roll­ment this year.

I see it in code re­view. Review is now the bot­tle­neck. AI gen­er­ates code fast. Humans re­view it slow. The in­dus­try’s an­swer is pre­dictable: let AI re­view AI’s code. I’m not do­ing that. I’ve re­worked our pull re­quest tem­plates in­stead. Every PR now has to ex­plain what changed, why, what type of change it is, screen­shots of be­fore and af­ter. Structured con­text so the re­viewer is­n’t guess­ing. I’m adding ded­i­cated re­view­ers per pro­ject. More eyes, more chances to catch what the model missed.

But even that does­n’t solve the deeper prob­lem. The skills you need to be ef­fec­tive now are dif­fer­ent. Technical ex­per­tise alone is­n’t enough any­more. You need peo­ple who can take own­er­ship, com­mu­ni­cate trade­offs, push back on bad sug­ges­tions from a ma­chine that sounds very con­fi­dent. Leadership qual­i­ties. Our last hir­ing round tells you how rare that is: 2,253 can­di­dates, 2,069 dis­qual­i­fied, 4 hired. A 0.18% con­ver­sion rate. The com­bi­na­tion of tech­ni­cal skill and the judg­ment to know when the AI is wrong barely ex­ists in the mar­ket any­more.

We doc­u­ment every­thing. Site Books, SDDs, RVS re­ports, boil­er­plate mod­ules with full cov­er­age. It works to­day, be­cause the peo­ple read­ing those docs have the en­gi­neer­ing ex­per­tise to act on them. What hap­pens when they don’t? Honestly, I don’t know. Maybe AI in five years is good enough that it won’t mat­ter. Maybe the prob­lem stays man­age­able. I can’t pre­dict the ca­pa­bil­i­ties of mod­els in 2031.

But crises don’t send cal­en­dar in­vites. Nobody ex­pected a full-scale land war in Europe in 2022. The de­fense in­dus­try had thirty years to pre­pare and did­n’t. Even Fogbank had records. They weren’t enough with­out the peo­ple who un­der­stood what they meant.

Five to ten years from now, we’ll need se­nior en­gi­neers. People who un­der­stand sys­tems end to end, who can de­bug dis­trib­uted fail­ures at 2 AM, who carry in­sti­tu­tional knowl­edge that ex­ists nowhere in the code­base. Those en­gi­neers don’t ex­ist yet be­cause we’re not cre­at­ing them. The ju­niors who should be learn­ing right now are ei­ther not be­ing hired or de­vel­op­ing what a DoD-funded work­force study calls “AI-mediated com­pe­tence.” They can prompt an AI. They can’t tell you what the AI got wrong.

It’s Fogbank for code. When ju­niors skip de­bug­ging and skip the for­ma­tive mis­takes, they don’t build the tacit ex­per­tise. And when my gen­er­a­tion of en­gi­neers re­tires, that knowl­edge does­n’t trans­fer to the AI.

It just dis­ap­pears.

The West al­ready made this mis­take once. The bill came due in Ukraine.

I know how this sounds. I know I’ve writ­ten about the tal­ent pipeline be­fore. The de­fense ex­am­ple is­n’t about re­peat­ing the ar­gu­ment. It’s about show­ing what hap­pens if the in­dus­try’s ex­pec­ta­tions don’t work out. Stinger, Javelin, Fogbank, a mil­lion shells no­body could make. That’s the cost of bet­ting wrong on op­ti­miza­tion. We’re mak­ing the same bet with soft­ware en­gi­neer­ing right now.

Maybe AI gets good enough, and the bet pays off. Maybe it does­n’t. The de­fense in­dus­try thought peace would last for­ever, too.

No posts

April 24, 2026

4 min read

Add Us On GoogleAdd SciAm

An am­a­teur just solved a 60-year-old math prob­lem—by ask­ing AI

An am­a­teur just solved a 60-year-old math prob­lem—by ask­ing AI

A ChatGPT AI has proved a con­jec­ture with a method no hu­man had thought of. Experts be­lieve it may have fur­ther uses

By Joseph Howlett edited by Lee Billings

Eugene Mymrin/Getty Images

Liam Price just cracked a 60-year-old prob­lem that world-class math­e­mati­cians have tried and failed to solve. He’s 23 years old and has no ad­vanced math­e­mat­ics train­ing. What he does have is a ChatGPT Pro sub­scrip­tion, which gives him ac­cess to the lat­est large lan­guage mod­els from OpenAI.

Artificial in­tel­li­gence has re­cently made head­lines for solv­ing a num­ber of “Erdős prob­lems,” con­jec­tures left be­hind by the pro­lific math­e­mati­cian Paul Erdős. But ex­perts have warned that these prob­lems are an im­per­fect bench­mark of ar­ti­fi­cial in­tel­li­gence’s math­e­mat­i­cal prowess. They range dra­mat­i­cally in both sig­nif­i­cance and dif­fi­culty, and many AI so­lu­tions have turned out to be less orig­i­nal than they ap­peared.

The new so­lu­tion—which Price got in re­sponse to a sin­gle prompt to GPT-5.4 Pro and posted on www.er­dosprob­lems.com, a web­site de­voted to the Erdős prob­lems, just over a week ago—is dif­fer­ent. The prob­lem it solves has eluded some promi­nent minds, be­stow­ing it some es­teem. And more im­por­tantly, the AI seems to have used a to­tally new method for prob­lems of this kind. It’s too soon to say with cer­tainty, but this LLM-conceived con­nec­tion may be use­ful for broader ap­pli­ca­tions—some­thing hard to find among re­cently touted AI tri­umphs in math.

On sup­port­ing sci­ence jour­nal­ism

If you’re en­joy­ing this ar­ti­cle, con­sider sup­port­ing our award-win­ning jour­nal­ism by sub­scrib­ing. By pur­chas­ing a sub­scrip­tion you are help­ing to en­sure the fu­ture of im­pact­ful sto­ries about the dis­cov­er­ies and ideas shap­ing our world to­day.

“This one is a bit dif­fer­ent be­cause peo­ple did look at it, and the hu­mans that looked at it just col­lec­tively made a slight wrong turn at move one,” says Terence Tao, a math­e­mati­cian at the University of California, Los Angeles, who has be­come a promi­nent score­keeper for AI’s push into his field. “What’s be­gin­ning to emerge is that the prob­lem was maybe eas­ier than ex­pected, and it was like there was some kind of men­tal block.”

The ques­tion Price solved—or prompted ChatGPT to solve—con­cerns spe­cial sets of whole num­bers, where no num­ber in the set can be evenly di­vided by any other. Erdős called these “primitive sets” be­cause of their con­nec­tion to sim­i­larly in­di­vis­i­ble prime num­bers.

“A num­ber is prime if it has no other di­vi­sors, and this is kind of gen­er­al­iz­ing that de­f­i­n­i­tion from an in­di­vid­ual num­ber to a col­lec­tion of num­bers,” says Jared Lichtman, a math­e­mati­cian at Stanford University. Any set of prime num­bers is au­to­mat­i­cally prim­i­tive, be­cause primes have no fac­tors (except them­selves and the num­ber one).

Erdős also came up with the Erdős sum, a “score” you can cal­cu­late for any prim­i­tive set. He showed that the biggest the sum could be was about 1.6—and con­jec­tured that this value must also hold for the (infinite) set of all prime num­bers. Lichtman proved Erdős right as part of his doc­toral the­sis in 2022.

Erdős also no­ticed that the score drops if all of a set’s num­bers are large—the larger the num­bers, the lower the score. He guessed that the low­est this score could be was ex­actly one, a limit that the score would ap­proach as the set’s num­bers ap­proached in­fin­ity. Lichtman tried to prove this, too, but got stuck like every­one else be­fore him.

Price was­n’t aware of this his­tory when he en­tered the prob­lem into ChatGPT on an idle Monday af­ter­noon. “I did­n’t know what the prob­lem was—I was just do­ing Erdős prob­lems as I do some­times, giv­ing them to the AI and see­ing what it can come up with,” he says. “And it came up with what looked like a right so­lu­tion.”

He sent it to his oc­ca­sional col­lab­o­ra­tor Kevin Barreto, a sec­ond-year un­der­grad­u­ate in math­e­mat­ics at the University of Cambridge. The duo had jump-started the AI-for-Erdős craze late last year by prompt­ing a free ver­sion of ChatGPT with open prob­lems cho­sen at ran­dom from the Erdős prob­lems web­site. (An AI re­searcher sub­se­quently gifted them each a ChatGPT Pro sub­scrip­tion to en­cour­age their “vibe math­ing.”)

Reviewing Price’s mes­sage, Barreto re­al­ized what they had was spe­cial, and ex­perts whom he no­ti­fied quickly took no­tice.

“There was kind of a stan­dard se­quence of moves that every­one who worked on the prob­lem pre­vi­ously started by do­ing,” Tao says. The LLM took an en­tirely dif­fer­ent route, us­ing a for­mula that was well known in re­lated parts of math, but which no one had thought to ap­ply to this type of ques­tion.

“The raw out­put of ChatGPT’s proof was ac­tu­ally quite poor. So it re­quired an ex­pert to kind of sift through and ac­tu­ally un­der­stand what it was try­ing to say,” Lichtman says. But now he and Tao have short­ened the proof so that it bet­ter dis­tills the LLM’s key in­sight.

More im­por­tantly, they al­ready see other po­ten­tial ap­pli­ca­tions of the AI’s cog­ni­tive leap. “We have dis­cov­ered a new way to think about large num­bers and their anatomy,” Tao says. “It’s a nice achieve­ment. I think the jury is still out on the long-term sig­nif­i­cance.”

Lichtman is hope­ful be­cause ChatGPT’s dis­cov­ery val­i­dates a sense he’s had since grad­u­ate school. “I had the in­tu­ition that these prob­lems were kind of clus­tered to­gether and they had some kind of uni­fy­ing feel to them,” he says. “And this new method is re­ally con­firm­ing that in­tu­ition.”

It’s Time to Stand Up for Science

If you en­joyed this ar­ti­cle, I’d like to ask for your sup­port. Scientific American has served as an ad­vo­cate for sci­ence and in­dus­try for 180 years, and right now may be the most crit­i­cal mo­ment in that two-cen­tury his­tory.

I’ve been a Scientific American sub­scriber since I was 12 years old, and it helped shape the way I look at the world. SciAm al­ways ed­u­cates and de­lights me, and in­spires a sense of awe for our vast, beau­ti­ful uni­verse. I hope it does that for you, too.

If you sub­scribe to Scientific American, you help en­sure that our cov­er­age is cen­tered on mean­ing­ful re­search and dis­cov­ery; that we have the re­sources to re­port on the de­ci­sions that threaten labs across the U.S.; and that we sup­port both bud­ding and work­ing sci­en­tists at a time when the value of sci­ence it­self too of­ten goes un­rec­og­nized.

In re­turn, you get es­sen­tial news, cap­ti­vat­ing pod­casts, bril­liant in­fo­graph­ics, can’t-miss newslet­ters, must-watch videos, chal­leng­ing games, and the sci­ence world’s best writ­ing and re­port­ing. You can even gift some­one a sub­scrip­tion.

There has never been a more im­por­tant time for us to stand up and show why sci­ence mat­ters. I hope you’ll sup­port us in that mis­sion.

Ever wanted to con­nect your Legos and Tinkertoys to­gether? Now you can — and much more. Announcing the Free Universal Construction Kit: a set of adapters for com­plete in­ter­op­er­abil­ity be­tween 10 pop­u­lar con­struc­tion toys.

Fig. 1. The Free Universal Construction Kit.

Overview

Motivation

Download

Implementation

Legal and Commercial Implications

License and Disclaimers

Credits, Contact and Acknowledgements

Keywords

Overview

Video by Riley Harmon for F.A.T. Lab + Sy-Lab.

F.A.T. Lab and Sy-Lab are pleased to pre­sent the Free Universal Construction Kit: a ma­trix of nearly 80 adapter bricks that en­able com­plete in­ter­op­er­abil­ity be­tween ten* pop­u­lar chil­dren’s con­struc­tion toys. By al­low­ing any piece to join to any other, the Kit en­cour­ages to­tally new forms of in­ter­course be­tween oth­er­wise closed sys­tems—en­abling rad­i­cally hy­brid con­struc­tive play, the cre­ation of pre­vi­ously im­pos­si­ble de­signs, and ul­ti­mately, more cre­ative op­por­tu­ni­ties for kids. As with other grass­roots in­ter­op­er­abil­ity reme­dies, the Free Universal Construction Kit im­ple­ments pro­pri­etary pro­to­cols in or­der to pro­vide a pub­lic ser­vice un­met—or un­meetable—by cor­po­rate in­ter­ests.

The Free Universal Construction Kit of­fers adapters be­tween Lego, Duplo, Fischertechnik, Gears! Gears! Gears!, K’Nex, Krinkles (Bristle Blocks), Lincoln Logs, Tinkertoys, Zome, and Zoob. Our adapters can be down­loaded from Thingiverse.com and other shar­ing sites as a set of 3D mod­els in .STL for­mat, suit­able for re­pro­duc­tion by per­sonal man­u­fac­tur­ing de­vices like the Makerbot (an in­ex­pen­sive, open-source 3D printer).

Motivation

Our kids are al­ready do­ing it! And when we were grow­ing up, our­selves, we did it too—or we tried to, any­way. Connecting our toys to­gether. Because: what if we want to make a con­struc­tion which is half-Tin­ker­toys, half-K’Nex? Why shouldn’t we be able to? We dreamed about this pos­si­bil­ity years ago, when we were small, and we knew then, as we know now, that we’d need some adapters to help. The ad­vent of low-cost 3D print­ing has made such adapters pos­si­ble, and with it, a vast new set of com­bi­na­to­r­ial pos­si­bil­i­ties for chil­dren’s cre­ative con­struc­tion toys.

Opening doors to new cre­ative worlds is one ma­jor rea­son we cre­ated the Free Universal Construction Kit. Another is that we be­lieve ex­per­tise shouldn’t be dis­pos­able — and that chil­drens’ hard-won cre­ative flu­ency with their toys shouldn’t be­come ob­so­lete each Christmas. By al­low­ing dif­fer­ent toy sys­tems to work to­gether, the Free Universal Construction Kit makes pos­si­ble new forms of “for­ward com­pat­i­bil­i­ty”, ex­tend­ing the value of these sys­tems across the life of a child. Thus, with the Kit’s adapters, play­sets like Krinkles (often en­joyed by tod­dlers) can still re­tain their use-value for older chil­dren us­ing Lego, and for even older tweens us­ing Zome.

The Kit of­fers a “best of all worlds” ap­proach to play and learn­ing that com­bines the ad­van­tages of each toy sys­tem. We se­lected con­struc­tion sets for in­clu­sion based on their sig­nif­i­cant level of mar­ket pen­e­tra­tion, as well as for the di­ver­sity of fea­tures they brought to the Kit’s col­lec­tion. Some of the sup­ported con­struc­tion sys­tems, for ex­am­ple, of­fer great me­chan­i­cal strength, or the abil­ity to build at large scales; oth­ers of­fer the means to de­sign ki­netic move­ments; and still oth­ers per­mit the cre­ation of a wide range of crys­tal­lo­graphic geome­tries and sym­me­tries. Using these clas­sic toys as a foun­da­tion, the Free Universal Construction Kit of­fers a “meta-mashup sys­tem” ide­ally pro­vi­sioned for the cre­ation of trans­gres­sive ar­chi­tec­ture and chimeric ready­mades.

Finally, in pro­duc­ing the Free Universal Construction Kit, we hope to demon­strate a model of re­verse en­gi­neer­ing as a civic ac­tiv­ity: a cre­ative process in which any­one can de­velop the nec­es­sary pieces to bridge the lim­i­ta­tions pre­sented by mass-pro­duced com­mer­cial ar­ti­facts. We hope that the Kit will not only prompt peo­ple to cre­ate new de­signs, but more im­por­tantly, to re­flect on our re­la­tion­ship with ma­te­r­ial mass-cul­ture—and the rapidly-evolv­ing ways in which we can bet­ter adapt it to our imag­i­na­tions.

Download

The Free Universal Construction Kit 3D mod­els are freely avail­able in .STL for­mat from three lo­ca­tions:

Individual adapters from the Free Universal Construction Kit may be down­loaded from Thingiverse.com — the world’s fore­most web­site ded­i­cated to the free shar­ing and remix­ing of user-cre­ated dig­i­tal de­sign files.

The com­plete Free Universal Construction Kit can also be down­loaded in its en­tirety*, as a 29MB .zip archive from the F.A.T. Lab web site, here. Note: all units are in inches.

We ex­pect the Kit to be avail­able shortly from The Pirate Bay, as a tor­rent in TPB’s new “physibles” (physical down­load­ables) chan­nel.

In ad­di­tion to the Kit it­self, we also of­fer for down­load this at­trac­tive B1 poster (4.5MB PDF, in two ver­sions: gray back­ground / white back­ground).

Figure 2. The Free Universal Construction Kit adapter ma­trix. (PDFs: Gray, White)

We (F.A.T. Lab and Sy-Lab) nei­ther sell nor dis­trib­ute phys­i­cal copies of the Free Universal Construction Kit. Please do not ask us to do so. Individuals seek­ing their own phys­i­cal copies of the Kit, in whole or in part, are en­cour­aged to down­load our files and re­pro­duce them with open-hard­ware desk­top 3D print­ers like the Makerbot, RepRap, Ultimaker, or Printrbot. Alternatively, copies for pri­vate use may be avail­able from a per­sonal fab­ri­ca­tion ser­vice bu­reau; for awe­some ser­vice, in­ter­na­tional/​any­where ship­ping and quick turn­around, we highly rec­om­mend Ponoko.com for per­son­al­ized 3D print­ing in a wide va­ri­ety of ma­te­ri­als. Shapeways and QuickParts are good, too. You may also find a 3D printer in the ar­chi­tec­ture, in­dus­trial de­sign, and/​or me­chan­i­cal en­gi­neer­ing de­part­ments of your lo­cal uni­ver­sity.

Please note that our li­cense for the Free Universal Construction Kit pro­hibits com­mer­cial use of these de­signs in mass pro­duc­tion; note, how­ever that we en­cour­age in­di­vid­u­als to con­tract with fab­ri­ca­tion ser­vice bu­reaus for the cre­ation of per­sonal copies. For more in­for­ma­tion, see our li­cense and dis­claimers, be­low.

Implementation

The Free Universal Construction Kit com­prises nearly 80 two-way adapters. These al­low each of the dif­fer­ent con­struc­tion toys (Lego, Tinkertoy, Fischertechnik etc.) to in­ter­face with any of the other sup­ported sys­tems. Prior to mod­el­ing, the di­men­sions of the var­i­ous toy con­nec­tors were re­verse-en­gi­neered with an op­ti­cal com­para­tor fit­ted with a dig­i­tal read-out ac­cu­rate to less than one ten-thou­sandth of an inch (0.0001in., or 2.54 mi­crons).

Figure 3. A Bristle Block be­ing mea­sured in the op­ti­cal com­para­tor.

The re­sult­ing pre­ci­sion en­sures that the Free Universal Construction Kit “ac­tu­ally works”, en­abling tight snap-fits be­tween cus­tom and com­mer­cial com­po­nents.

Figure 4. The Kit in use, con­nect­ing four dif­fer­ent sys­tems to­gether.

Below is a par­tial gallery of as­sorted Kit adapters, re­spec­tively com­pat­i­ble with (clockwise from top left): Lego, Zoob, Tinkertoys, and Gears! Gears! Gears!. Click on the im­ages for higher-res­o­lu­tion pho­tographs:

In ad­di­tion to its many one-to-one adapters, the Free Universal Construction Kit also in­cludes a spe­cial fist-sized Universal Adapter Brick which pro­vides con­nec­tiv­ity be­tween all of the sup­ported con­struc­tion sys­tems:

Fig. 9. The Universal Adapter Brick.

Producing phys­i­cal prints from our pro­vided 3D mod­els prompts cer­tain fab­ri­ca­tion con­sid­er­a­tions. According to Wikipedia, the pre­ci­sion of Lego pieces is less than 10 mi­crons. As of early 2012, how­ever, stan­dard Makerbot print­ers have an XY res­o­lu­tion of 100 mi­crons (0.1mm) and a de­fault layer thick­ness of 360 mi­crons (0.36mm). We thus cau­tion that fab­ri­ca­tion of the Free Universal Construction Kit with cur­rent (2012-era) so­lu­tions for DIY 3D print­ing, such as the Makerbot, Printrbot or RepRap, may lack the pre­ci­sion re­quired for re­li­able or sat­is­fac­tory cou­pling with stan­dard com­mer­cial pieces. A great deal de­pends on how well-tuned the printer is; thus, your mileage may vary. In any case, we ex­pect this sit­u­a­tion will im­prove grad­u­ally, but in­ex­orably, in tan­dem with im­prove­ments to these vi­brantly evolv­ing fab­ri­ca­tion plat­forms. The artist’s proof shown here was cre­ated in a UV-cured white resin us­ing a com­mer­cial-grade Objet (“polyjet”) 3D printer, which has a hor­i­zon­tal res­o­lu­tion of 42 mi­crons, and a layer thick­ness of 16 mi­crons. Ponoko.com and other pri­vate fab­ri­ca­tion ser­vices of­fer print­ing from Objet ma­chines and other high-res­o­lu­tion de­vices.

Legal and Commercial Implications

Consider the frus­trat­ing ex­pe­ri­ence of pur­chas­ing a new com­puter (a Mac, say) and dis­cov­er­ing that it will not play your aunt’s Windows Media video of your lit­tle cousins. Likewise, imag­ine your aunt’s cor­re­spond­ing an­noy­ance when she finds that her PC will not play the Apple Quicktime video you sent her of your cats. This hu­mil­i­at­ing lit­tle episode isn’t an ac­ci­dent; it’s just a skir­mish in a never-end­ing bat­tle be­tween gi­ant com­mer­cial en­ti­ties, played out, thou­sands of times every day, in ex­actly such mi­cro-pun­ish­ments to cus­tomers like you. If you’re well-in­formed, you may hap­pen to know about VLC — a free, open-source video player, de­vel­oped by in­de­pen­dent hack­ers as a grass­roots rem­edy for ex­actly this prob­lem. Until the ad­vent of ubiq­ui­tous 3D print­ing, soft­ware reme­dies like VLC weren’t read­ily avail­able for hard­ware prod­ucts, like toys. That’s chang­ing.

Today’s man­u­fac­tur­ers have lit­tle or no in­trin­sic mo­ti­va­tion to make their prod­ucts com­pat­i­ble with any­one else’s. Indeed—despite ob­vi­ous ben­e­fits to users every­where—the im­ple­men­ta­tion of cross-brand in­ter­op­er­abil­ity can be nearly im­pos­si­ble, given the tan­gled re­stric­tions of patents, de­sign rights, and trade­marks in­volved in do­ing so. So we stepped up. The Free Universal Construction Kit is the VLC of chil­dren’s play­sets.

As we can see from the ex­am­ple above, in­ter­op­er­abil­ity is a ques­tion of power and mar­ket dom­i­nance. Most mar­ket lead­ers re­gard in­ter­op­er­abil­ity as an anti-com­pet­i­tive nui­sance, a reg­u­la­tory check on their am­bi­tion, or a con­ces­sion to the whin­ing of lesser play­ers. Quite sim­ply, in­ter­op­er­abil­ity is the re­quest of the dis­en­fran­chised. And which end-user, in so many ways, is less en­fran­chised than a pre­lit­er­ate child?

The sim­ple fact is that no toy com­pany would ever make the Free Universal Construction Kit. Instead, each con­struc­tion toy wants (and in­deed, pre­tends) to be your only play­set. Within this world­view, the other man­u­fac­tur­ers’ con­struc­tion sets are just so many ele­phants in the room, com­pet­ing for your at­ten­tion on the shelves of Toys-R-Us. No longer. The Free Universal Construction Kit pre­sents what no man­u­fac­turer could: a rem­edy pro­vid­ing ex­ten­si­ble, post-facto syn­tac­tic in­ter­op­er­abil­ity for con­struc­tion toys. Let the fun be­gin!

Some may ex­press con­cern that the Free Universal Construction Kit in­fringes such cor­po­rate pre­rog­a­tives as copy­right, de­sign right, trade dress, trade­marks or patents of the sup­ported toy sys­tems. We en­cour­age those ea­ger to en­force these rights to please think of the chil­dren (or per­haps the Streisand ef­fect) — and we as­sert that the home print­ing of the Free Universal Construction Kit con­sti­tutes pro­tected fair use. Simon Bradshaw et al., writ­ing in “The Intellectual Property Implications of Low-Cost 3D Printing”, con­clude that the pub­lic is legally al­lowed to make 3D prints that mate with pro­pri­etary parts, es­pe­cially in cases (the “Must Fit Exception”) where a piece’s shape “is de­ter­mined by the need to con­nect to or fit into or around an­other pro­duct”:

“Even where a reg­is­tered de­sign is copied via a 3D printer this would not be an in­fringe­ment if it were done ‘privately and for pur­poses which are not com­mer­cial’. Both cri­te­ria must be met; it is in­suf­fi­cient that copy­ing is not done for profit. Purely per­sonal use of a 3D printer to make items will thus not in­fringe a reg­is­tered de­sign.”

*In fact, the Free Universal Construction Kit de­lib­er­ately avoids patent in­fringe­ment. Part of our strat­egy for do­ing so is our choice to sup­port older (“classic”) play­sets: of the ten toy sys­tems sup­ported by the Kit, eight are no longer pro­tected by ac­tive (20-year) patents. To take a few ex­am­ples: Lego was patented in 1958; Lincoln Logs, in 1920; and Tinkertoys, in 1932. There are, how­ever, two in­stances in which toy sys­tems nom­i­nally sup­ported by the Kit are still pro­tected (as of this writ­ing) by ac­tive patents: Zoob (patented 1996) and ZomeTool (patented 2002). For the Zoob and Zome sys­tems, please note that we have de­layed the re­lease of per­ti­nent adapter mod­els un­til December 2016 and November 2022, re­spec­tively.

The Free Universal Construction Kit is sim­ply one “toy” il­lus­tra­tion of a com­ing grass­roots rev­o­lu­tion, in which every­day peo­ple can—with desk­top tools—over­come ar­bi­trary re­stric­tions in mass-man­u­fac­tured phys­i­cal cul­ture. The bur­geon­ing pos­si­bil­ity of freely shared down­load­able adapters has sig­nif­i­cant im­pli­ca­tions for in­dus­tries where the at­tempt to cre­ate “tech­no­log­i­cal lock-in” is a com­mon busi­ness prac­tice. For more on this sub­ject, and the le­gal hori­zons of re­pro­duc­ing com­mer­cial prod­ucts with home fab­ri­ca­tion sys­tems, please see:

Bradshaw, Simon; A. Bowyer and P. Haufe, “The Intellectual Property Implications of Low-Cost 3D Printing”, 7:1 SCRIPTed 5, 2010.

de Bruijn, Erik. “Fab It Yourself: Adapters & Consumer Lock-In”. Blog.erikdebruijn.nl, 13 September 2010.

Hanna, Peter. “The next Napster? Copyright ques­tions as 3D print­ing comes of age”. Arstechnica.com, April 2011.

Ross, Valerie. “Can You Patent a Shape? 3D Printing on Collision Course With Intellectual Property Law”. Discover Magazine, 7 April 2011.

Weinberg, Michael. “3D Printing Settlers of Catan is Probably Not Illegal: Is This a Problem?”. PublicKnowledge.org, 28 January 2011.

Weinberg, Michael. “It Will Be Awesome if They Don’t Screw it Up: 3D Printing, Intellectual Property, and the Fight Over the Next Great Disruptive Technology”. PublicKnowledge.org, 10 November 2010.

In ad­di­tion to the writ­ers above, we tip our hats to Thingiverse user Zydac, whose re­lated pro­ject (a Duplo-to-Brio track adapter) led us to these le­gal writ­ings; to Andrew Plumb (Clothbot) who has probed the le­gal and prac­ti­cal im­pli­ca­tions of Lego-compatible bricks for some time; and to Daan van den Berg, who has ex­plored 3D-printed remixes of branded forms as a mode of crit­i­cal artis­tic prac­tice.

License and Disclaimers

The Free Universal Construction Kit and its as­so­ci­ated me­dia are li­censed un­der and sub­ject to the terms of the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License (http://​cre­ativecom­mons.org/​li­censes/​by-nc-sa/​3.0/​legal­code). The of­fi­cial URL for the Free Universal Construction Kit is https://​fffff.at/​free-uni­ver­sal-con­struc­tion-kit. You are free to copy, dis­trib­ute and trans­mit the Kit, and to remix and/​or adapt the Kit; in do­ing so, you must at­tribute the Kit to “F.A.T. Lab and Sy-Lab”, and in­clude a link to the pro­ject us­ing the URL above. We es­pe­cially wel­come ex­ten­sions to the Kit which pro­vide com­pat­i­bil­ity with as-yet-un­sup­ported play sys­tems. Please note that ex­ten­sions to the Kit re­quire the same or sim­i­lar li­cense. You may not use the Kit in com­mer­cial mass pro­duc­tion; how­ever, we per­mit in­di­vid­u­als to con­tract with fab­ri­ca­tion ser­vice bu­reaus (e.g. Ponoko, Shapeways, etc.) for per­sonal copies.

Lego®, Duplo®, Fischertechnik®, Gears! Gears! Gears!®, K’Nex®, Krinkles®, Bristle Blocks®, Lincoln Logs®, Tinkertoys®, Zome®, ZomeTool® and Zoob® are trade­marks of their re­spec­tive own­ers. The Free Universal Construction Kit is not as­so­ci­ated or af­fil­i­ated with, or en­dorsed, spon­sored, cer­ti­fied or ap­proved by, any of the fore­go­ing own­ers or their re­spec­tive prod­ucts.

We are not a com­mer­cial com­pany; we are artists, hack­ers and ac­tivists. The Kit is not a prod­uct; it is a provo­ca­tion. F.A.T. Lab and Sy-Lab, in co­op­er­a­tion with Adapterz LLC, (1) per­form solely the ser­vice of pub­lish­ing the Free Universal Construction Kit, (2) do not par­tic­i­pate in any pro­duc­tion, pub­lic man­u­fac­ture or sale of the items dis­played here, and (3) of­fer no opin­ion, war­ranty or rep­re­sen­ta­tion as to the safety, qual­ity or func­tion­al­ity of the Kit. The F.A.T. Lab, Sy-Lab and Adapterz LLC there­fore of­fer no war­ranty of any kind, ex­press or im­plied.

Please cite the Free Universal Construction Kit, and/​or this ar­ti­cle, as fol­lows:

Free Art and Technology [F.A.T.] Lab and Sy-Lab. “The Free Universal Construction Kit.” Fffff.at, 20 March 2012. <https://​fffff.at/​free-uni­ver­sal-con­struc­tion-kit>.

Free Art and Technology [F.A.T.] Lab and Sy-Lab. “The Free Universal Construction Kit.” Fffff.at, 20 March 2012. <https://​fffff.at/​free-uni­ver­sal-con­struc­tion-kit>.

WARNING: CHOKING HAZARD!

Small parts. Not for chil­dren un­der 3 years.

Credits, Contact and Acknowledgements

For press or other in­quiries about the Free Universal Construction Kit, please con­tact info@adapterz.org. The Kit was con­ceived and de­vel­oped by the F.A.T. (Free Art and Technology) Lab in col­lab­o­ra­tion with Sy-Lab, and is rep­re­sented, for le­gal pur­poses, by Adapterz, LLC. The Kit’s “advertisement” video was cre­ated by Riley Harmon.

The cre­ators ex­press grat­i­tude to: our fam­i­lies; our lawyers; the chil­dren ap­pear­ing in our demon­stra­tion video, and their fam­i­lies; Jean Aw, Eric Brockmeyer, David Familian, Andy Flowers, Michael Joaquin Grey, Mark Gross, Riley Harmon, Marcie and Lawrence Hayhurst, Allie Oswell, Eric Paulos, Bre Pettis, Kent Sheely, Michael Weinberg, and the STUDIO for Creative Inquiry. The Kit files are sport­ingly hosted by Thingiverse.com.

Keywords

Toys, kits, con­struc­tions sets, con­struc­tion toys, con­struc­tion sys­tems, Lego, Duplo, Fischertechnik, Gears! Gears! Gears!, K’Nex, Krinkles, Bristle Blocks, Lincoln Logs, Tinkertoys, Zome, ZomeTool, Zoob, Constructivist learn­ing, play, con­nec­tors, adap­tors, adapter piece, adapter brick, adapters, uni­ver­sal trans­la­tor, gen­der changer, mod­u­lar­ity, in­ter­op­er­abil­ity, in­ter­op­er­abil­ity rem­edy, com­pat­i­bil­ity layer, tech­no­log­i­cal lock-in, post-facto plug-and-play syn­tac­tic in­ter­op­er­abil­ity, shim, com­puter aided de­sign, 3D mod­els, STL files, physi­bles, rapid pro­to­typ­ing, 3D print­ing, Makerbot, RepRap, Printrbot, Thingiverse, Ponoko, F.A.T. Lab, Sy-Lab, fair use, remix, hy­brid, mashup.

The com­mons and the pub­lic good are con­tin­u­ally threat­ened by nar­row in­ter­ests seek­ing pri­vate gain. Please con­tinue to sup­port and pro­tect the free, open, and non-pro­pri­etary ex­change and de­vel­op­ment of ideas and in­for­ma­tion on­line.

Note: I ini­tially drafted this be­fore my last post on how Claude Code is get­ting worse. I’m putting it out now so I can ref­er­ence it in a fu­ture post on OpenCode. As you can imag­ine my opin­ion on Claude Code has shifted since I wrote this.

Long ago I at­tempted a per­sonal pro­ject, but never fin­ished due to life be­ing busy. [1] Sort of like the Japanese word Tsundoku, for the pile of books you in­tend to even­tu­ally read one day. We all have these pro­jects and they are good can­di­dates for test­ing out AI cod­ing as­sis­tance. After all, they were never go­ing to get done any­way.

The POC I put to­gether was a shim be­tween YouTube Music and the OpenSubsonic api. Explaining OpenSubsonic could be its own ar­ti­cle, but for our pur­poses it’s an API con­tract for nicely de­cou­pling mu­sic stream­ing clients and servers. You can pick your own op­tions for both. In my case I like Navidrome for the server, Feishin for desk­top, and as I men­tioned in my post on GrapheneOS, Symfonium for Android.

Anyways, the shim made YouTube Music con­form to the API so I could add it to any of my clients. Under the hood I used yt­mu­s­i­capi for meta­data lookup and pro­gram­mat­i­cally called yt-dlp to stream the mu­sic. Getting ba­sic stream­ing work­ing was pretty sim­ple. However, there was a long tail im­ple­ment­ing all the end­points in a con­for­mant way. Then as al­ways, there were new shiny pro­jects that stole my at­ten­tion away. Like that em­bed­ded rust lo­ca­tion pro­ject I promise I’ll fin­ish at some point. Maybe.

Luckily, noth­ing was re­ally novel in that stream­ing pro­ject, and there is a clear spec to im­ple­ment which is per­fect for as­sisted cod­ing. So a month and a half ago I thought I would test Claude Code with Opus 4.6 and see how it did im­ple­ment­ing the pro­ject from scratch. After all, they gave me a free $50 in credit, so I might as well.

The setup

Since I had al­ready writ­ten a proof of con­cept by hand, I had my own opin­ions about the im­ple­men­ta­tion and lay­ing all of that out be­fore­hand con­strained the tool in a nice way.

I did the fol­low­ing:

Created a uv pro­ject with fastapi, py­dan­tic, yt­mu­s­i­capi and yt-dlp as de­pen­den­cies.

Changed main.py to the ex­am­ple FastAPI main file.

Dropped the ope­napi spec for OpenSubsonic in the folder.

Added a brief de­scrip­tion in a readme file:

This pro­ject acts as a shim, ex­pos­ing YouTube mu­sic as an open­sub­sonic client. It uses fastapi for its server with py­dan­tic, yt­mu­s­i­capi for meta­data and yt-dlp for stream­ing.”

open­sub­sonic docs are avail­able at: https://​ex­am­ple.docsy.dev/​docs/​ref­er­ence/

The ope­napi spec is in ope­napi.json.

Added an empty TODO file.

Generated a CLAUDE.md file us­ing /init.

I also of­ten add a sec­tion like this to the CLAUDE.md file:

## Conventions

- Methods should have type an­no­ta­tions for args and re­turns as well as doc­strings.

- Use Pydantic for data mod­el­ing. Use mod­ern Pydantic V2 con­ven­tions.

- Doc strings should use the Google style for­mat with an args and re­turns sec­tions.

- Write unit tests with mod­ern pytest style, eg top level meth­ods us­ing `assert` and fix­tures.

That’s mostly based on past ex­pe­ri­ence for what I have to re­peat­edly ask Claude Code not to do.

I’ve bun­dled up this start­ing point into a git repos­i­tory in case any­one else wants to try the ex­per­i­ment.

Implementing the MVP

With that setup done, I let Claude kick things off. The work­flow I typ­i­cally use is:

Enter plan mode.

Prompt for the next piece of work.

After get­ting the ini­tial plan, look for gaps / prob­lems and ask fol­low up ques­tions un­til I like the plan.

Provide links to re­sources when Claude is off.

Ask Claude to use the search tool to fig­ure out what is id­iomatic when there are mul­ti­ple op­tions and it is un­clear to me which to take.

Use “Accept and clear con­text”.

Repeat.

The first prompt I used was:

Have a look at the ope­napi.json file. This is a spec for the open­sub­sonic api. Implement an async fastapi server that stubs out all of the meth­ods. There are both older xml end­points and newer style json end­points. You only need to han­dle the newer json end­points.

Have a look at the ope­napi.json file. This is a spec for the open­sub­sonic api. Implement an async fastapi server that stubs out all of the meth­ods. There are both older xml end­points and newer style json end­points. You only need to han­dle the newer json end­points.

For this kind of change I like to clear con­text af­ter im­ple­ment­ing and then ask a fol­low up ques­tion:

I im­ple­mented stubbed ver­sions of all the meth­ods spec­i­fied in ope­napi.json. Double-check they are cor­rect.

I im­ple­mented stubbed ver­sions of all the meth­ods spec­i­fied in ope­napi.json. Double-check they are cor­rect.

Even with a spec, Claude Code makes mis­takes the first time, but then will catch them (mostly) the sec­ond time through.

Also, af­ter im­ple­ment­ing larger changes, I like to re-run /init to up­date the CLAUDE.md file to cover the new pieces.

The next ma­jor prompt was:

The meth­ods for all end­points are stubbed out now. I want to con­nect a sub­sonic client, search for a song, and stream it to the client. What is the min­i­mum amount of func­tion­al­ity needed to im­ple­ment that? Use yt­mu­s­i­capi for search­ing YouTube mu­sic and yt-dlp for stream­ing.

The meth­ods for all end­points are stubbed out now. I want to con­nect a sub­sonic client, search for a song, and stream it to the client. What is the min­i­mum amount of func­tion­al­ity needed to im­ple­ment that? Use yt­mu­s­i­capi for search­ing YouTube mu­sic and yt-dlp for stream­ing.

I got an im­ple­men­ta­tion that looked rea­son­able pretty quickly, but fell over when try­ing to ac­tu­ally con­nect with Feishin. At that point I it­er­ated by test­ing the client and hand­ing the server re­quest logs to Claude Code. Even with a spec there are de­tails that are not spelled out clearly, like how end­points may have a .view suf­fix that needs to be stripped. Every time there was an er­ror I gen­er­ated new unit tests to cover them.

I was shocked to hear the au­dio stream­ing through feishin af­ter only a cou­ple of it­er­a­tions. The main is­sues in­volved stubbed end­points re­turn­ing noth­ing. They mostly had to be up­dated to re­turn empty, but cor­rectly struc­tured re­sponses.

Just get­ting an MVP is the easy part though. Not that far be­yond what I im­ple­mented in my POC.

Working through the long tail.

The rest of the work was the less in­ter­est­ing, more drudgery parts to make the pro­ject ac­tu­ally us­able. From the docs, OpenSubsonic has ~80 end­points spread over 15 dif­fer­ent cat­e­gories.

For the MVP use case I only had to sup­port:

getLi­cense, ge­tUser, get­Gen­res and get­Mu­sicDi­rec­to­ries with empty, but valid col­lec­tions.

get­Song as a pass through that re­turned the ID in the query params and de­fault val­ues.

search3 with a very ba­sic yt­mu­s­i­capi call.

stream with a yt-dlp call wrapped in an asyn­cio.to_thread to ex­tract the URL for the “bestaudio” for­mat.

get­Cov­er­Art with a call to yt-dlp to ex­tract the cover im­age URL.

To sup­port the full func­tion­al­ity of a sub­sonic client I:

Added sim­ple in mem­ory caching for yt­mu­s­i­capi calls to avoid hit­ting us­age lim­its.

Used sqlite for stor­ing mu­sic meta­data and im­ple­mented all the end­points in the brows­ing cat­e­gory. Even get­Top­Songs by query­ing for the top songs list.

Saved the song to disk as it streamed to avoid re­down­load­ing songs. I had to have ad­di­tional han­dling to clean up the in­com­plete file when a client dis­con­nects from the stream end­point be­fore the file was fully down­loaded.

I knew all these things had to be done to make my own POC more us­able, and I could have done them, but never did. At the same time, since I never planned to re­lease any­thing I ab­solutely skipped the hard bits around au­then­ti­ca­tion.

All to­gether I was able to get a work­ing ser­vice that I could con­nect to from a sub­sonic client in a short evening. In the end I dubbed the pro­ject “Sub-standard”.

Is this good?

I don’t want to sound like an AI cod­ing as­sist booster. I still have fears around deskilling from re­ly­ing on these tools too much. That’s why I still bang my head against the wall try­ing to learn Rust.

In my mind there are dif­fer­ent buck­ets for per­sonal pro­jects. One is things I do to learn and grow and the other is things I re­ally wish ex­isted. [2] This kind of pro­ject falls into the sec­ond bucket. Using AI cod­ing as­sist to reify those pro­jects is sort of a form of wish ful­fill­ment. I never would have got­ten to it, but now I can have the pro­ject. One less metaphor­i­cal book sit­ting un­read on book­shelf.

In the end I think the im­por­tant thing is not whether you are do­ing pro­jects in bucket 2, but whether you are also still do­ing the stretch pro­jects in bucket 1.

Or at least that is the ex­cuse I tell my­self. ↩︎

Or at least that is the ex­cuse I tell my­self. ↩︎

Also other buck­ets, I don’t want to im­ply those are the only two. ↩︎

Also other buck­ets, I don’t want to im­ply those are the only two. ↩︎

On April 10, the house of OpenAI CEO Sam Altman was at­tacked

with a Molotov cock­tail by 20-year-old Daniel Moreno-Gama. The sus­pect, who

was ar­rested the same day, had writ­ten a man­i­festo warn­ing of the

ex­is­ten­tial threat of ar­ti­fi­cial in­tel­li­gence. In his mis­sive, he ad­vo­cated for

killing the CEOs of AI com­pa­nies, and he re­ferred to him­self as “butlerian ji­hadist”

on Instagram (a ref­er­ence to a war against ma­chines in Frank Herbert’s Dune

uni­verse).

Three days prior in Indianapolis, an un­known per­pe­tra­tor

fired 13 shots into the home

of lo­cal Democratic coun­cil­man Ron Gibson while his 8-year-old son was

home. Neither were hurt, but a note read­ing “No Data Centers” was left on the

doorstep. Gibson had lent his sup­port for a po­ten­tial data cen­ter pro­ject in

his dis­trict. There have not yet been any ar­rests in the case.

Both in­ci­dents were fright­en­ing ex­am­ples of ab­hor­rent,

po­lit­i­cally mo­ti­vated vi­o­lence. But the re­ac­tion, at least on so­cial me­dia, seemed to revel in

it.

The mood ex­em­pli­fied by in­flamed Instagram com­menters on these in­ci­dents was fur­ther re­in­forced on April 13 when Stanford University

re­leased its an­nual

Artificial Intelligence Index, which pro­vides a yearly snap­shot of where

the in­dus­try stands.

In the re­port, one of the most stand­out con­trasts was the

gulf be­tween what AI ex­perts pre­dict for AI’s fu­ture and the pub­lic’s

re­ac­tion to the in­dus­try’s de­signs. On jobs, 73 per­cent of ex­perts were

pos­i­tive about the long-term ef­fect, with 69 per­cent pos­i­tive about the

long-term ef­fect on the econ­omy. Among the pub­lic, those num­bers were 23 per­cent

and 21 per­cent, re­spec­tively, with nearly two-thirds of Americans think­ing that

AI would lead to fewer jobs over the next 20 years.

A sep­a­rate sur­vey, re­leased in March

2026 by Gallup, also showed a sharp in­crease in neg­a­tive at­ti­tudes to­ward

AI among Gen Z. According to the poll, the per­cent­age of Gen Zers who felt

ex­cited about AI had dropped from 36 per­cent to 22 per­cent, while the num­ber

who felt an­gry about it in­creased from 22 per­cent to 31 per­cent.

These num­bers and ac­tions point in the same di­rec­tion: a

rapidly grow­ing pop­ulist back­lash to­ward AI, which tech jour­nal­ist Jasmine Sun de­fined as “a

world­view in which AI is viewed not only

as a nor­mal tech­nol­ogy, but an elite po­lit­i­cal pro­ject to be re­sisted … a thing

man­u­fac­tured by out-of-touch bil­lion­aires and pushed onto an un­will­ing pub­lic.”

Naturally, vi­o­lence is never an an­swer, nor is it a po­lit­i­cally ef­fec­tive

tac­tic. But you also can­not ig­nore how the tone-deaf pub­lic mes­sag­ing of the AI

in­dus­try has helped to con­tribute to this re­ac­tion.

For years, CEOs like Altman and Anthropic’s Dario Amodei have

very pub­licly os­cil­lated be­tween two sub­op­ti­mal sce­nar­ios. In one, AI ex­ter­mi­nates

hu­man­ity with a bi­o­log­i­cal su­per-weapon. In the other, AI

ei­ther takes your job en­tirely or cre­ates an econ­omy where your only op­tion

is to down­shift

into the gig econ­omy.

These pitches may be per­fect for at­tract­ing at­ten­tion at

tech con­fer­ences or fund­ing rounds, but they ut­terly ig­nore the daily con­cerns

of reg­u­lar Americans, at a time when the job mar­ket (especially for newer

grad­u­ates) is in­cred­i­bly

shaky; eco­nomic gains are con­cen­trated

among the top 0.1 per­cent; and the price

of food, hous­ing, and, now, gaso­line all con­tinue to sky­rocket.

This is the en­vi­ron­ment in which the AI in­dus­try is very

pub­licly ask­ing for hun­dreds

of bil­lions of dol­lars in con­tin­ued in­vest­ment, as well as a mas­sive data cen­ter

build­out that has had sig­nif­i­cant ef­fects on

lo­cal pop­u­la­tions’ elec­tri­cal bills. For ex­am­ple, in Virginia, the epi­cen­ter of the U.S.

data cen­ter boom, res­i­den­tial elec­tri­cal rates have been pro­jected to in­crease

by up to 25 per­cent by 2030.

These costs could be ig­nored, or even ac­cepted, if there was a clear idea of how pre­cisely AI would stream­line and im­prove the work­place—or

of­fer any tan­gi­ble pub­lic ben­e­fit sig­nif­i­cant enough to make these un­der­ly­ing

trade-offs ac­cept­able. But the an­swers to these ques­tions re­main ex­tremely

ten­u­ous. According to a February 2026 pa­per by the National Bureau of Economic

Research, 80

per­cent of com­pa­nies that have be­gun ac­tively us­ing AI have re­ported no

im­pact on com­pany pro­duc­tiv­ity. A sep­a­rate, widely cited 2025 MIT study

re­vealed that 95 per­cent of cor­po­rate AI

pi­lot pro­grams re­ceived zero re­turn.

Even within tech and cod­ing, one of the ar­eas where AI is

re­ported to have the most promise, there’s the ques­tion of whether the

pro­duc­tiv­ity gains re­ported can be trusted. In a provoca­tive GitHub

post, ma­chine-learn­ing en­gi­neer Han-Chung Lee ar­gued that even rosy

in­ter­nal num­bers that do show AI-assisted pro­duc­tiv­ity gains are

sus­pect, as they’re pro­duced to hit adop­tion tar­gets no one can ef­fec­tively

au­dit.

This is­n’t to say that AI does­n’t show im­mense and pos­si­bly

in­cred­i­bly valu­able po­ten­tial, es­pe­cially bear­ing in mind that ChatGPT (which

can be con­sid­ered the first main­stream demon­stra­tion of AI tech­nol­ogy) was only

launched in November 2022. It’s nat­ural for new tech­nol­ogy to have a bumpy

adop­tion pe­riod as both users and de­sign­ers stress-test its strengths and lim­i­ta­tions

in the real world.

But the gap be­tween how AI com­pa­nies talk about them­selves

and how the gen­eral pub­lic has ex­pe­ri­enced the tech­nol­ogy (and its side

ef­fects) has grown into a chasm, and now the re­sults of these di­vi­sions are

start­ing to show; data

cen­ter pro­jects can­celed or de­layed; an in­dus­try that is less

pop­u­lar than ICE or Donald Trump; and now, vi­o­lent acts against AI

lead­ers.

In its de­fense, Big Tech has re­al­ized the ex­tent of the

po­ten­tial prob­lems that AI could pose to reg­u­lar Americans. Earlier in April,

for ex­am­ple, Open AI re­leased an Industrial

Policy White Paper, which in­cluded sug­ges­tions such as the cre­ation of a

Public Wealth Fund for all Americans to share in AI growth, re­vamp­ing so­cial

safety nets, and in­vest­ing in real-time mea­sure­ment of how AI af­fects work. In

January, Microsoft re­leased a Community-First

AI Infrastructure Initiative, promis­ing to sub­si­dize util­ity rates and

min­i­mize wa­ter use in com­mu­ni­ties where it was build­ing data cen­ters.

But it’s one thing for AI com­pa­nies to make lofty promises

in press re­leases, and an­other thing en­tirely for them to fol­low through

Niri is a scrol­lable-tiling Wayland com­pos­i­tor. Windows are arranged in columns on an in­fi­nite strip go­ing to the right. Opening a new win­dow never causes ex­ist­ing win­dows to re­size.

As you may have no­ticed, niri now lives in a GitHub org rather than my (@YaLTeR) per­sonal ac­count.

The pri­mary rea­son was the abil­ity to give out is­sue triage per­mis­sions: I’d like to give a mas­sive thanks to @Sempyos for triag­ing all of our is­sues and pull re­quests, an­swer­ing many, many ques­tions, and help­ing peo­ple di­ag­nose their prob­lems with niri.

We’ve also moved a few niri-ad­ja­cent pro­jects to the GitHub org, like the awe­some-niri list of re­lated pro­jects main­tained by @Vortriz and a new art­work repo by @bluelinden and @HumpityDumpityDumber—two of the cre­ators of our pro­ject logo. In the art­work repo, you can find a badge and sev­eral wall­pa­pers, in­clud­ing two stun­ning 3D works cre­ated by @Duncan-Rose in Blender:

The main niri repo also flew past 20,000 stars in February! 🌟 Thanks every­one for sup­port.

Note

Packagers:

our min­i­mum sup­ported Rust ver­sion is now 1.85.

niri.ser­vice no longer hard­codes /usr/bin/ in the niri bi­nary path (thanks @Axlefublr).

@markK24 re­struc­tured the dinit ser­vice files: 3bfa4a7

Now with in­tro­duc­tions out of the way, here are the im­prove­ments from the last re­lease.

Blur

It’s here. The most re­quested niri fea­ture by far. Our high­est up­voted is­sue on GitHub. After tire­less fork main­te­nance by @visualglitch91 and @Naxdy, blur is in main­line niri for every­one to use!

Windows and layer-shell com­po­nents can re­quest blur through the ext-back­ground-ef­fect Wayland pro­to­col with no ex­tra niri con­fig­u­ra­tion. Many al­ready do:

Dank Material Shell v1.4.5: en­able back­ground blur in set­tings

Noctalia shell: en­able in set­tings and see docs

Vicinae launcher

foot ter­mi­nal v1.26: set blur=true in col­ors con­fig

kitty ter­mi­nal v0.46.2: set back­ground_blur 1

Ghostty ter­mi­nal: will have sup­port in v1.4

Toolkits:

Quickshell: will have sup­port in v0.3

winit: will have sup­port in v0.31

For apps that don’t sup­port ext-back­ground-ef­fect yet, you can en­able blur through the niri con­fig:

// Enable blur be­hind the Alacritty ter­mi­nal.

win­dow-rule {

match app-id=“^Alacritty$”

back­ground-ef­fect {

blur true

}

}

// Enable blur be­hind the fuzzel launcher.

layer-rule {

match name­space=“^launcher$”

back­ground-ef­fect {

blur true

}

}

Keep in mind that niri-con­fig­ured blur needs the right geom­e­try-cor­ner-ra­dius, and it won’t work with com­plex sur­face shapes. See the Window Effects wiki page for de­tails.

Have I seen this screen­shot be­fore?..

We have both nor­mal blur and xray blur that al­ways shows the wall­pa­per. Xray blur is the de­fault be­cause it’s much more ef­fi­cient: niri com­putes the blurred wall­pa­per once, and then reuses it as a sta­tic im­age, which is ex­tremely cheap. Only if the wall­pa­per changes, the blur is re­com­puted (so an an­i­mated back­ground will shrink the ef­fi­ciency gains).

If you pre­fer non-xray (normal) blur, you can en­able it with a win­dow/​layer rule. For ex­am­ple, you can set it on top and over­lay lay­ers (that usu­ally over­lap other con­tent), via the new layer matcher:

// Make top and over­lay lay­ers use the reg­u­lar blur (if en­abled),

// while bot­tom and back­ground lay­ers keep us­ing the ef­fi­cient xray blur.

layer-rule {

match layer=“top”

match layer=“over­lay”

back­ground-ef­fect {

xray false

}

}

So, if blur is so good, where’s blur 2? Err, I mean, why did it take so long to add?

In short, back­ground blur turned out to be a mas­sive un­der­tak­ing. Not be­cause of the blur al­go­rithm it­self (by the way, if you want to learn about dif­fer­ent blurs, in­clud­ing the widely used Dual Kawase, I highly rec­om­mend this blog post), but be­cause win­dow back­ground ef­fects in gen­eral re­quired a lot of think­ing and ad­di­tions to the code, es­pe­cially to make them as ef­fi­cient as pos­si­ble. This is one of the most com­plex niri fea­tures thus far.

Xray and non-xray ef­fects are also pretty much two en­tirely sep­a­rate and very dif­fer­ent beasts, code-wise. Non-xray reads back the just-ren­dered pix­els in the mid­dle of a frame, blurs them, then con­tin­ues draw­ing the frame. This re­quired ex­ten­sive refac­tors of Smithay’s ren­der­ing ar­chi­tec­ture (big thanks to @Drakulix!). Xray on the other hand re­quires thread­ing the win­dow po­si­tions all through­out the ren­der­ing code to draw the right cut-out of the back­ground.

But it gets worse: we have our Overview. It was quite a chal­lenge fig­ur­ing out how to sup­port xray blur in the overview, while main­tain­ing the prop­erty that it is never re-ren­dered.

I also had to get both of them work­ing with all other niri fea­tures, like block­ing out from screen­casts. When the win­dow it­self is blocked out that’s easy, but what if some­thing in the back­ground layer, in­side the blur, is blocked out? An un­usual case for sure, but hardly a good ex­clude if your sen­si­tive data gets ac­ci­den­tally leaked.

By the way, I made it so xray can be used on its own, with­out the blur. As well as the noise and sat­u­ra­tion ef­fects (normally for re­duc­ing blur color band­ing and bump­ing the vivid­ness). For ex­am­ple:

win­dow-rule {

match app-id=“Alacritty”

// Xray with­out the blur!

back­ground-ef­fect {

xray true

}

}

One more thing you can do start­ing from this re­lease is to con­fig­ure niri to ap­ply trans­parency and back­ground ef­fects to pop-up menus, us­ing the new pop­ups block in win­dow or layer rules.

// Blur the back­ground be­hind pop-up menus in Loupe.

win­dow-rule {

match app-id=“Loupe”

pop­ups {

// Matches the de­fault libad­waita pop-up cor­ner ra­dius.

geom­e­try-cor­ner-ra­dius 15

// Note: it’ll look bet­ter to set back­ground opac­ity

// through your GTK theme CSS and not here.

// This is just an ex­am­ple that makes it look ob­vi­ous.

opac­ity 0.5

back­ground-ef­fect {

blur true

}

}

}

Keep in mind that pop-up rules tend to bump even more into prob­lems with ap­pli­ca­tion be­hav­ior and sur­face shapes. For ex­am­ple, web apps or Electron don’t use Wayland pop-ups at all; they’re en­tirely em­u­lated in­side the client—niri can­not do any­thing with them.

Shape-wise, in GTK 4, pop-ups with has-ar­row=true won’t look right be­cause they aren’t rounded rec­tan­gles. Thankfully, clients im­ple­ment­ing ext-back­ground-ef­fect can shape their blur in any sort of elab­o­rate pat­tern.

Well, enough about blur, we’ve got more in­ter­est­ing things to cover!

Credit: Houl Floof

Optional in­cludes

Pretty much right af­ter I added con­fig in­cludes last re­lease (before I merged them even), peo­ple started re­quest­ing op­tional in­cludes—that can be ab­sent with­out fail­ing con­fig load­ing. Some use-cases are be­ing able to change parts of an im­mutable niri con­fig on NixOS, or hav­ing lo­cal/​pri­vate over­rides for parts of the con­fig.

I pushed back for a time be­cause I think some of those prob­lems should be solved else­where, rather than re­quir­ing every pro­gram with in­cludes to sup­port op­tional. However, the added code com­plex­ity was rather low, so I even­tu­ally went ahead and ac­cepted @johnrichardrinehart’s im­ple­men­ta­tion.

Starting from this re­lease, you can make an in­clude op­tional by set­ting op­tional=true:

// Won’t fail if this file does­n’t ex­ist.

in­clude op­tional=true “optional-config.kdl”

// Regular in­clude, will fail if the file does­n’t ex­ist.

in­clude “required-config.kdl”

When an op­tional in­clude file is miss­ing, niri will emit a warn­ing in the logs on every con­fig re­load. This re­minds you that the file is miss­ing while still load­ing the con­fig suc­cess­fully.

The op­tional file is still watched for changes, so if you cre­ate it later, the con­fig will au­to­mat­i­cally re­load and ap­ply the new set­tings. Finally, op­tional=true only af­fects whether a miss­ing file causes an er­ror, so if the file ex­ists but con­tains in­valid syn­tax or other er­rors, those er­rors will still cause a pars­ing fail­ure.

While we’re talk­ing about in­cludes: they now ex­pand paths start­ing with ~ to the home di­rec­tory, so ~/file.kdl will ex­pand to /home/user/file.kdl. Thanks to @HigherOrderLogic and @BennyDeeDev for pro­to­type im­ple­men­ta­tions of this fea­ture.

Pointer warp­ing while scrolling

Last re­lease, I made drag­ging win­dows hor­i­zon­tally by their ti­tle­bars scroll the view left and right. This made mouse-only nav­i­ga­tion much more con­ve­nient, but I still felt that some­thing was miss­ing.

This re­lease makes the pointer warp from one side of the screen to the other dur­ing view scrolling ges­tures, sim­i­larly to Blender. It makes scrolling through sev­eral win­dows nat­ural and con­ve­nient, even when you start right next to the mon­i­tor edge.

Screencasting fea­tures

Earlier in the re­lease cy­cle, I spent some time im­prov­ing var­i­ous as­pects of our screen­cast­ing sup­port. In niri, you can screen­cast through xdg-desk­top-por­tal-gnome via PipeWire (the rec­om­mended ap­proach), or through wlr-screen­copy (mainly in­tended for tools such as wf-recorder). Both of these have seen im­prove­ments.

April 19, 2026

3 minute read

I was chat­ting to a friend about my fold­ing bike and I had the urge to write about it - be­cause this falls in the cat­e­gory of “Things I wish I’d had decades ago”. And maybe I can en­cour­age some oth­ers to try these won­der­ful de­vices.

Note: I’m 3 months into a new job so blog­ging has taken a back seat to drink­ing from a fire­hose of new do­main knowl­edge, new peo­ple, new tech. I’m still play­ing with AI-assisted cod­ing, but at a slower pace - I do hope to blog more about this when things calm down.

12 years ago I started cy­cling in London, com­mut­ing by train, and I used the bi­cy­cle hire scheme mis-named at the time “Boris Bikes”. It was OK but a bit of a has­sle - bikes were heavy, pay­ment was fid­dly, and of­ten the hire racks would be empty in the morn­ing and full in the evening.

So I fol­lowed the ad­vice of other com­muters and got this beau­ti­ful de­vice - it cost £1000 at the time, a fair bit of money, but on a Ride to Work scheme I could pay this weekly over a year, so it was £4 a week, pre-tax, which made it quite af­ford­able.

It’s a Brompton - and they are a mar­vel­lous brand, but I don’t want to just say “Get a Brompton” as I’m sure other brands must be com­pet­ing in this space - and Bromptons are pricey. So do your own re­search.

I also (after a cou­ple of an­noy­ing flats) got punc­ture-proof Schwalbe Marathon Plus tyres - and I haven’t had a sin­gle punc­ture since.

And like I said at the start - I so wish I’d had some­thing like this years and years ago. So many years of com­mut­ing in Melbourne where I’d walk slowly to a sta­tion, or drive to a sta­tion and have to cram into busy park­ing. So many years where my bike would lan­guish in a shed, prob­a­bly with flat tyres be­cause I only got it out on spe­cific “exercise” at­tempts.

The fold­ing bike:

Lives in my study. I have a nicer bike in the shed but al­most never get it out be­cause the bike in my study is so con­ve­nient.

Can be car­ried in one hand - it’s heavy, about 12kg plus bags, but that’s ok for short dis­tances.

Can go on the train - this is the biggest ben­e­fit, com­mut­ing is so much eas­ier when you can go cy­cle -> train -> cy­cle. Most trains, even ones with “no bikes” rules, al­low them - they aren’t any big­ger than a large suit­case.

Never gets punc­tures

Can go in the boot of the car eas­ily - when I get the car ser­viced, I drive to the garage, then cy­cle home, and cy­cle back to the garage at the end of the day.

Can be car­ried in to the of­fice or cafes or shops - no lock­ing it on the street; a big ben­e­fit in London where bike thieves are every­where and tend to carry bolt cut­ters or an­gle grinders!

I do have a lock - a fold­ing ‘silver’ grade Abus Bordo lock that mounts on the bike. But I only re­ally use it in my home town where thieves are much rarer, or on the very rare case where I want to go in a cafe and there is­n’t room for the bike - but only if I can sit with the bike in eye­shot!

I get it ser­viced every year or two. And af­ter 11 years, it’s had noth­ing ma­jor go wrong - a few ca­ble re­place­ments and the like, but it still has the orig­i­nal frame, wheels, and gears. That’s pretty im­pres­sive for 11 years of com­mut­ing, though post-Covid I only tend to com­mute one day a week.

For a lot of peo­ple this should be fairly should be sim­ple eco­nom­ics. Our sta­tion park­ing is £10 a day - cur­rent Brompton prices start at £1400 - so even ig­nor­ing pre-tax schemes and sav­ings in other trans­port like the un­der­ground, a Brompton would pay for it­self in 140 work­ing days, or 28 weeks for the poor folks still com­mut­ing every day.

Plus I just love the free­dom of cy­cling, and the ex­er­cise!

#protip If cy­cling in one of the sup­ported ar­eas the free Cycle Streets app is mar­vel­lous. It uses Open StreetMap data so users can up­date it when roads change, and lets you choose quiet vs fast routes. People ask me if cy­cling in London is safe - it’s fine if you use an app like this to avoid the worst roads, and ride sen­si­bly with a bit of care about pass­ing trucks or busses, and (gasp) ac­tu­ally obey traf­fic sig­nals.