Because I am known to write us­ing a foun­tain pen on pa­per, a num­ber of peo­ple have pointed me to this post and its un­der­ly­ing re­search. I won’t re­hash what is said in those sources, but the gist of it is that when you write things down by hand you’re re­cruit­ing more of your brain, which is a good thing.

I’m not an ex­pert on how the brain works, but I can say that, when writ­ing by hand, one is con­tin­u­ally solv­ing a se­ries of small prob­lems hav­ing to do with the spac­ing of words, how let­ters are con­nected, the cross­ing of the let­ter t (sometimes more than one in the same word) and the dot­ting of the let­ters i and j, and how to ac­com­plish all of those things through co­or­di­nated move­ments not just of the fin­gers but of the whole arm. All of that has to be in­te­grated in real time with what­ever is hap­pen­ing on a more ab­stract level in the brain’s pro­cess­ing of ideas and im­agery.

Concurrently I have been fol­low­ing dis­course on Reddit and other sources about how wide­spread use of AI has forced ed­u­ca­tors to re­turn to the long-aban­doned prac­tice of hav­ing their stu­dents take ex­ams in per­son by writ­ing things out long­hand in blue books. This has cre­ated new chal­lenges for stu­dents who never re­ally learned how to write by hand, and for teach­ers who can’t make sense of their stu­dents’ ter­ri­ble hand­writ­ing.

About twenty-five years ago I stopped com­pos­ing at the key­board and switched over to foun­tain pen on pa­per. Since then I have writ­ten many thou­sands of pages that way. The man­u­script of The Baroque Cycle was a stack of hand­writ­ten pages 42 inches high, which for a time was on dis­play at the Museum of Science Fiction in Seattle. With the ex­cep­tion of The Rise and Fall of D.O.D.O., which I co-wrote with Nicole Galland by email­ing Word files back and forth, every book I’ve writ­ten since then has been com­posed with foun­tain pen on pa­per.

Every so of­ten, when I’m sign­ing books at a book tour ap­pear­ance, some­one will come up to me and say some­thing like “you must have writer’s cramp!” or “is your hand sore yet?” I never have the time to pro­vide a full an­swer. If I did, how­ever, my an­swer would be that never, at any time dur­ing a quar­ter of a cen­tury dur­ing which I have spent a sub­stan­tial frac­tion of each work­ing day writ­ing by hand, have I ex­pe­ri­enced even the faintest traces of so-called “writer’s cramp” or any other such hob­gob­lins.

Yet I can re­mem­ber get­ting a sore hand when I was a kid writ­ing out as­sign­ments in school. Many peo­ple prob­a­bly re­mem­ber such ex­pe­ri­ences and as­sume, rea­son­ably enough, that it’s a nat­ural con­se­quence of writ­ing by hand for any length of time. This is not the case.

Here are some fairly sim­ple dos and don’ts for peo­ple who want to reap the ben­e­fits of writ­ing by hand.

It’s pretty ob­vi­ous that you’re go­ing to get tired faster if your mus­cles have to ex­ert more force. Writing with a pen­cil re­quires sig­nif­i­cantly more force than writ­ing with a good pen. Old-school ball­points with thick ink are no bet­ter. You can see vi­sual ev­i­dence of this if you flip over a sheet of pa­per on which you’ve been writ­ing with a pen­cil or an old ball­point. The pa­per will bear a vis­i­ble im­print where it was pressed down by the writ­ing in­stru­ment. Often that will con­tinue down into the stack of pa­per be­neath. That’s be­cause you had to push hard. This does­n’t hap­pen with a foun­tain pen. If the nib is work­ing prop­erly you need to ex­ert very lit­tle force. The nib is ba­si­cally skat­ing on the lit­tle lake of ink that it has just laid down.

Pains me to say it, but roller­ball gel pens are about as good as foun­tain pens on this front.

It might then seem rea­son­able to think that writ­ing with a sty­lus on an iPad or sim­i­lar would be best, since no force is needed and fric­tion is min­i­mized. I don’t think this is true. A small amount of fric­tion is ac­tu­ally de­sir­able. You don’t want the tip of the writ­ing in­stru­ment to skid out of con­trol. Your brain and your lit­tle hand mus­cles are re­ly­ing on a lit­tle bit of fric­tion. Since I’m writ­ing this dur­ing the World Cup, I’ll make a soc­cer anal­ogy. Soccer play­ers have spent many hours drib­bling balls across play­ing fields, and they’ve in­ter­nal­ized the physics—they know about how far the ball is go­ing to travel when they kick it a cer­tain way, and how of­ten they need to give it an­other kick to keep it mov­ing. If you put them on a gi­ant, fric­tion­less air hockey table, all of that knowl­edge would be­come use­less. Every touch on the ball would send it out of con­trol. Dribbling the ball down the field would be­come more tir­ing be­cause they’d have to be mak­ing con­tin­ual ef­forts to con­trol the bal­l’s move­ment. Relying on a lit­tle bit of fric­tion re­duces the amount of men­tal and phys­i­cal ef­fort.

The com­bi­na­tion of foun­tain pens and pa­per em­bod­ies a bal­ance that has been worked out over a long span of time by peo­ple who write a lot. This phe­nom­e­non is called “tooth” by afi­ciona­dos. Removing fric­tion by us­ing a hard sty­lus on glass will ac­tu­ally make the process more tir­ing.

Too much fric­tion, and too lit­tle fric­tion, are both more tir­ing than just a lit­tle bit of fric­tion, and that’s the bal­ance that is re­flected in the foun­tain pen/​pa­per tech­nol­ogy.

Rresults vary when you use var­i­ous pens on var­i­ous kinds of pa­per. Generally I get the worst re­sults on cheap printer pa­per, be­cause it wicks ink out of the nib too fast, and so cre­ates fat, blurry lines. Often I have the same prob­lem with yel­low le­gal pads. But al­most any pa­per in a blank note­book, or higher-grade printer pa­per with at least 25% cot­ton con­tent, works fine. I’ve learned over time that some of my foun­tain pens work bet­ter with cer­tain kinds of pa­per than oth­ers, so I match them up with­out hav­ing to think about it too hard.

Here’s a 300 dpi scan of tests I did with three dif­fer­ent pens on var­i­ous types of pa­per. You might have to zoom in to see much dif­fer­ence.

The pen on the left is a Jorg Hysek with a wide nib, and you can see that the cheap printer pa­per soaked up a lot of ink and left a thicker, fuzzier line. The le­gal pad was­n’t much bet­ter. Everything else ba­si­cally worked. The 100% cot­ton pa­per is from a box I pur­chased a long time ago - it was mar­keted for print­ing re­sumes, back in the days when peo­ple printed re­sumes. It is the tooth­iest of all these pa­pers and felt no­tice­ably scratch­ier. I guess it goes with­out say­ing that fancy Italian pa­per is the best, but the comp book and mole­sk­ine work per­fectly well with just about any pen.

(For those scor­ing at home, the mid­dle pen is a Diplomat Aero and the one on the right is a Monteverde Invincia)

If the pa­per is thin, writ­ing on one side can bleed through to the other, so the re­sults can be slightly harder to read if you write on both sides. Which leads me to:

The ecosys­tem is­n’t go­ing to col­lapse if you use more pa­per. It’s cheap. Focus on what’s im­por­tant here: your brain and your time. Write on one side. Trying to cram more words into a sheet will take you out of your nat­ural and com­fort­able writ­ing style and make you tired. Just buy a shit­load of pa­per or note­books or what­ever it is you want to use, and use it.

There’s a rea­son cur­sive was in­vented. Don’t even think about not us­ing it. It is far less tir­ing than print­ing one let­ter at a time. I learned cur­sive as a child. Then I went for many years with­out us­ing it much, and for­got some of it. Later I re-learned it by sit­ting in my kid’s el­e­men­tary school class­room dur­ing a par­ent-teacher con­fer­ence and ex­am­in­ing the forms printed on a long strip above the chalk­board (I still re­mem­bered how to do the lower-case let­ters, but I had for­got­ten some of the cap­i­tals).

Legibility was more im­por­tant back in the day when writ­ten doc­u­ments had to be read by other peo­ple. Hence the need for ex­act­ing pen­man­ship, taught in schools to long-suf­fer­ing chil­dren. This is prob­a­bly the source of a lot of angst around writer’s cramp and ink dis­as­ters. Today, if you’re writ­ing things down with ink on pa­per, you’re prob­a­bly writ­ing just for your­self, or per­haps for fam­ily mem­bers who can learn to rec­og­nize your hand­writ­ing.

To judge from the way peo­ple talk, a lot of them have mem­o­ries of foun­tain pen dis­as­ters where ink got all over the place for some rea­son. Or per­haps it’s just gen­er­a­tional trauma, handed down in an oral tra­di­tion. If the pen is work­ing cor­rectly, ink can only come out of it so fast. A cou­ple of rare ex­cep­tions:

If the pen’s ink reser­voir is partly empty, so that it con­tains an air bub­ble, and if it’s po­si­tioned nib down, then, when you go up in an air­plane, the bub­ble will ex­pand as the am­bi­ent pres­sure drops, forc­ing ink out the nib. Once I fig­ured that out, I got in the habit of mak­ing sure my pens were po­si­tioned nib up when tak­ing off in an air­plane. If I have time I’ll also re­fill the pen be­fore de­par­ture, to min­i­mize the size of the air bub­ble.

Sometimes if a pen gets dirty, or if the nib is some­how dam­aged, the ink will stop com­ing out and you can restart it by giv­ing it a lit­tle shake. If you do it just right, the ink flow restarts with­out in­ci­dent, but if you overdo it, a few drops of ink might shoot out onto the page and be­come blots. This sce­nario hap­pens a few times of year for me, only with one pen that has this prob­lem. I blot it with a piece of scrap pa­per and move on.

Just have note­books ly­ing around, or on your per­son. Write gro­cery lists, doo­dles, notes on meet­ings, to-do lists, or stray ideas. Journal. Copy out good lines from books. Anything that has your men­tal fo­cus will have a more en­dur­ing pres­ence in your brain if you write it down.

I am left handed. I have never had any trou­ble with my hand smear­ing the ink. Yet every con­ver­sa­tion I have about foun­tain pens leads to some­one claim­ing that it can never work for them be­cause they are left handed. I have no idea what they’re talk­ing about. When I was a child, writ­ing at length with pen­cil, the side of my hand some­times be­came gray from graphite picked up as my hand rubbed across the page. And some­times I have got ink on my hand when us­ing a ball­point pen that left an ink glob on the pa­per. But with foun­tain pens it’s easy to find a pen/​pa­per com­bi­na­tion such that the ink soaks into the pa­per and dries quickly enough that it does­n’t smudge when you’re writ­ing the next line. Here’s a sim­ple demon­stra­tion of dry­ing time and how it works with two pens: first a foun­tain pen and then a Pilot G-2 gel pen.

Obviously the Pilot gel pen ink dries faster, and so that might be a bet­ter choice for peo­ple who are re­ally wor­ried about smudg­ing.

Most mod­ern pens al­low you to choose be­tween us­ing pre­loaded plas­tic ink car­tridges and a plunger that en­ables you to draw ink up out of a bot­tle by hand. I use both. Start with the ink car­tridges, es­pe­cially if you travel. There’s no need to com­pli­cate mat­ters by mess­ing around with bot­tles. Since I do a lot of work from one lo­ca­tion, I have a cor­ner of a table­top set up there with ink bot­tles and a folded-up pa­per towel for wip­ing off the nib af­ter it’s filled (I have been us­ing the same pa­per towel for about twenty years). In the­ory this works bet­ter in the long term be­cause it al­lows you to flush the nib by forc­ing ink in and out of it a cou­ple of times when­ever you re­fill. In prac­tice I see no dif­fer­ence at all - pens that I re­fill with car­tridges don’t get clogged.

Even if every­thing works per­fectly you’ll end up with the oc­ca­sional ink-smudged fin­ger. It will wash off quickly - the ink is wa­ter-sol­u­ble. Until then, con­sider it a mark of dis­tinc­tion.

If you’re new to this I think it makes most sense to start by con­sid­er­ing what kind of pa­per is go­ing to work best in your life. Are you writ­ing loose­leaf, or in note­books? Legal pads? Blue books? Remember, it’s okay to use lots of pa­per, so pick some­thing that is­n’t too pre­cious and that is easy to re­plen­ish. I use a lot of mole­sk­ine note­books and Mead comp books, which I can buy in bulk on­line. For com­pos­ing fic­tion I use fancy loose­leaf pa­per.

If you have ac­cess to a store where they sell foun­tain pens, take some of that pa­per there and see what works best. If you’re work­ing with cheaper, thin­ner pa­per, start with finer nibs and work up to fat­ter ones un­til you start to see bleed-through.

Buy cheaper pens un­til you know what you like. I doubt there’s much of a dif­fer­ence be­tween cheaper and more ex­pen­sive foun­tain pens in terms of their ac­tual per­for­mance. What you’re pay­ing for, in an ex­pen­sive pen, is fancy ma­te­ri­als and styling. For ex­am­ple, if you look at the Pilot Vanishing Point line of pens - an in­ge­nious foun­tain pen that you can click, like an old-fash­ioned ball­point, to re­tract the nib in­side the bar­rel - fancier ver­sions cost five times as much as the base model.

In all hon­esty, the Pilot G-2 gel pens are go­ing to give you 80% of what you could ex­pect from a foun­tain pen for min­i­mal cost.

On the other hand, a ten-pack of Pilot G-2 gel pens goes for about twenty bucks. For the same amount you can buy a sim­ple but com­pletely ser­vice­able foun­tain pen that will last longer than you will.

No posts

Sign up to see the fu­ture, to­day

Sign up to see the fu­ture, to­day

Can’t-miss in­no­va­tions from the bleed­ing edge of sci­ence and tech

AI com­pa­nies are pour­ing un­told bil­lions of dol­lars into enor­mous data cen­ters in their ef­forts to sus­tain in­creas­ingly com­plex and re­source-in­ten­sive AI mod­els.

It’s an ex­tremely costly un­der­tak­ing built on seem­ingly bot­tom­less hype — and a moun­tain of debt. As Japanese fi­nan­cial news­pa­per Nikkei Asia found in a re­cent in­ves­ti­ga­tion, just five US tech gi­ants — Alphabet, Microsoft, Amazon, Meta, and Oracle — are hid­ing an es­ti­mated $1.65 tril­lion in debt that does­n’t ap­pear on bal­ance sheets. That’s even more than the $1.35 tril­lion in debt the five com­pa­nies of­fi­cially re­ported in their fi­nan­cial data for the most re­cent quar­ter.

Meta alone has amassed around $420 bil­lion in off-bal­ance-sheet debt, ac­cord­ing to Nikkei, high­light­ing how pre­car­i­ous the AI in­dus­try’s steep in­vest­ment in AI has be­come, and in­spir­ing com­par­isons to en­ergy com­pany Enron, which col­lapsed in spec­tac­u­lar fash­ion in 2001 be­cause of sim­i­lar debts hid­den be­hind shell com­pa­nies. Like Enron, they’re us­ing spe­cial pur­pose ve­hi­cles, or off-bal­ance sheet arrange­ments such as legally dis­tinct sub­sidiaries, as a way to make their fi­nan­cial re­port­ing look health­ier than it ac­tu­ally is — of­ten a glar­ing sign that some­thing is deeply amiss be­hind the scenes.

“The ac­count­ing treat­ment it­self is in fash­ion,” tech­ni­cal ac­count­ing con­sul­tant Tom Selling told Bloomberg. “But what if one of these com­pa­nies was a house of cards and was prop­ping it­self up with this ac­count­ing treat­ment? To me, that’s the risk.”

Experts con­tinue to warn of an AI bub­ble, not­ing the enor­mous and widen­ing gulf be­tween com­pany val­u­a­tions and their com­par­a­tively measly prof­its. The lat­est news will do lit­tle to quiet crit­ics who say the sit­u­a­tion is more dire than the com­pa­nies’ of­fi­cial bal­ance sheets sug­gest.

To keep up with the on­go­ing AI race, tech gi­ants are com­mit­ting vast sums to build out large-scale data cen­ter pro­jects, a long-term bet that may — or may not — pay off. They’re also sell­ing new shares to raise new funds, as Nikkei re­ports, which could lead to eq­uity di­lu­tion and a drop in in­vestor con­fi­dence.

That could make them even more vul­ner­a­ble if the AI bub­ble does pop, or the in­dus­try fails to gen­er­ate enough de­mand to jus­tify the data cen­ter con­struc­tion frenzy.

The pres­sure is on: four of the five com­pa­nies Nikkei an­a­lyzed are set to re­port sec­ond quar­ter earn­ings in the com­ing days and weeks. We’ll be watch­ing.

More on the AI bub­ble: There’s a Gigantic Problem at the Heart of the AI Industry That Could Cause the Whole Thing to Collapse

A de­sign sys­tem for build­ing faith­ful recre­ations of old UIs.

Intro

98.css is a CSS li­brary for build­ing in­ter­faces that look like Windows 98. See more on GitHub.

My First VB4 Program

Hello, world!

This li­brary re­lies on the us­age of se­man­tic HTML. To make a but­ton, you’ll need to use a <button>. Input el­e­ments re­quire la­bels. Icon but­tons rely on aria-la­bel. This page will guide you through that process, but ac­ces­si­bil­ity is a pri­mary goal of this pro­ject.

You can over­ride many of the styles of your el­e­ments while main­tain­ing the ap­pear­ance pro­vided by this li­brary. Need more padding on your but­tons? Go for it. Need to add some color to your in­put la­bels? Be our guest.

This li­brary does not con­tain any JavaScript, it merely styles your HTML with some CSS. This means 98.css is com­pat­i­ble with your fron­tend frame­work of choice.

Here is an ex­am­ple of 98.css used with React, and an ex­am­ple with vanilla JavaScript. The fastest way to use 98.css is to im­port it from unpkg.

<link rel=“stylesheet” href=“https://​unpkg.com/​98.css” >

You can in­stall 98.css from the GitHub re­leases page, or from npm.

npm in­stall 98.css

Components

Button

A com­mand but­ton, also re­ferred to as a push but­ton, is a con­trol that causes the ap­pli­ca­tion to per­form some ac­tion when the user clicks it.

A stan­dard but­ton mea­sures 75px wide and 23px tall, with a raised outer and in­ner bor­der. They are given 12px of hor­i­zon­tal padding by de­fault.

<button>Click me</​but­ton> <input type=“sub­mit” /> <input type=“re­set” />

You can add the class de­fault to any but­ton to ap­ply ad­di­tional styling, use­ful when com­mu­ni­cat­ing to the user what de­fault ac­tion would hap­pen in the ac­tive win­dow if the Enter key was pressed on Windows 98.

<button class=“de­fault”>OK</​but­ton>

When but­tons are clicked, the raised bor­ders be­come sunken. The fol­low­ing but­ton is sim­u­lated to be in the pressed (active) state.

<button>I am be­ing pressed</​but­ton>

Disabled but­tons main­tain the same raised bor­der, but have a “washed out” ap­pear­ance in their la­bel.

<button dis­abled>I can­not be clicked</​but­ton>

Button fo­cus is com­mu­ni­cated with a dot­ted bor­der, set 4px within the con­tents of the but­ton. The fol­low­ing ex­am­ple is sim­u­lated to be fo­cused.

<button>I am fo­cused</​but­ton>

Checkbox

A check box rep­re­sents an in­de­pen­dent or non-ex­clu­sive choice.

Checkboxes are rep­re­sented with a sunken panel, pop­u­lated with a “check” icon when se­lected, next to a la­bel in­di­cat­ing the choice.

Note: You must in­clude a cor­re­spond­ing la­bel af­ter your check­box, us­ing the <label> el­e­ment with a for at­tribute pointed at the id of your in­put. This en­sures the check­box is easy to use with as­sis­tive tech­nolo­gies, on top of en­sur­ing a good user ex­pe­ri­ence for all (navigating with the tab key, be­ing able to click the en­tire la­bel to se­lect the box).

This is a check­box

<input type=“check­box” id=“ex­am­ple1″> <label for=“ex­am­ple1”>This is a check­box</​la­bel>

Checkboxes can be se­lected and dis­abled with the stan­dard checked and dis­abled at­trib­utes.

When group­ing in­puts, wrap each in­put in a con­tainer with the field-row class. This en­sures a con­sis­tent spac­ing be­tween in­puts.

I am checked

I am in­ac­tive

I am in­ac­tive but still checked

<div class=“field-row”> <input checked type=“check­box” id=“ex­am­ple2”> <label for=“ex­am­ple2″>I am checked</​la­bel> </div> <div class=“field-row”> <input dis­abled type=“check­box” id=“ex­am­ple3”> <label for=“ex­am­ple3″>I am in­ac­tive</​la­bel> </div> <div class=“field-row”> <input checked dis­abled type=“check­box” id=“ex­am­ple4”> <label for=“ex­am­ple4″>I am in­ac­tive but still checked</​la­bel> </div>

OptionButton

An op­tion but­ton, also re­ferred to as a ra­dio but­ton, rep­re­sents a sin­gle choice within a lim­ited set of mu­tu­ally ex­clu­sive choices. That is, the user can choose only one set of op­tions.

Option but­tons can be used via the ra­dio type on an in­put el­e­ment.

Option but­tons can be grouped by spec­i­fy­ing a shared name at­tribute on each in­put. Just as be­fore: when group­ing in­puts, wrap each in­put in a con­tainer with the field-row class to en­sure a con­sis­tent spac­ing be­tween in­puts.

Yes

No

<div class=“field-row”> <input id=“ra­dio5″ type=“ra­dio” name=“first-ex­am­ple”> <label for=“ra­dio5”>Yes</​la­bel> </div> <div class=“field-row”> <input id=“ra­dio6” type=“ra­dio” name=“first-ex­am­ple”> <label for=“ra­dio6″>No</​la­bel> </div>

Option but­tons can also be checked and dis­abled with their cor­re­spond­ing HTML at­trib­utes.

Peanut but­ter should be smooth

I un­der­stand why peo­ple like crunchy peanut but­ter

Crunchy peanut but­ter is good

<div class=“field-row”> <input id=“ra­dio7″ type=“ra­dio” name=“sec­ond-ex­am­ple”> <label for=“ra­dio7”>Peanut but­ter should be smooth</​la­bel> </div> <div class=“field-row”> <input checked dis­abled id=“ra­dio8” type=“ra­dio” name=“sec­ond-ex­am­ple”> <label for=“ra­dio8″>I un­der­stand why peo­ple like crunchy peanut but­ter</​la­bel> </div> <div class=“field-row”> <input dis­abled id=“ra­dio9″ type=“ra­dio” name=“sec­ond-ex­am­ple”> <label for=“ra­dio9”>Crunchy peanut but­ter is good</​la­bel> </div>

GroupBox

A group box is a spe­cial con­trol you can use to or­ga­nize a set of con­trols. A group box is a rec­tan­gu­lar frame with an op­tional la­bel that sur­rounds a set of con­trols.

A group box can be used by wrap­ping your el­e­ments with the field­set tag. It con­tains a sunken outer bor­der and a raised in­ner bor­der, re­sem­bling an en­graved box around your con­trols.

<fieldset> <div class=“field-row”>Se­lect one:</​div> <div class=“field-row”> <input id=“ra­dio10” type=“ra­dio” name=“field­set-ex­am­ple”> <label for=“ra­dio10″>Din­ers</​la­bel> </div> <div class=“field-row”> <input id=“ra­dio11″ type=“ra­dio” name=“field­set-ex­am­ple”> <label for=“ra­dio11”>Drive-Ins</​la­bel> </div> <div class=“field-row”> <input id=“ra­dio12” type=“ra­dio” name=“field­set-ex­am­ple”> <label for=“ra­dio12″>Dives</​la­bel> </div> </fieldset>

You can pro­vide your group with a la­bel by plac­ing a leg­end el­e­ment within the field­set.

<fieldset> <legend>Today’s mood</​leg­end> <div class=“field-row”> <input id=“ra­dio13″ type=“ra­dio” name=“field­set-ex­am­ple2″> <label for=“ra­dio13”>Claire Saffitz</label> </div> <div class=“field-row”> <input id=“ra­dio14” type=“ra­dio” name=“field­set-ex­am­ple2”> <label for=“ra­dio14″>Brad Leone</label> </div> <div class=“field-row”> <input id=“ra­dio15″ type=“ra­dio” name=“field­set-ex­am­ple2″> <label for=“ra­dio15”>Chris Morocco</label> </div> <div class=“field-row”> <input id=“ra­dio16” type=“ra­dio” name=“field­set-ex­am­ple2”> <label for=“ra­dio16″>Carla Lalli Music</label> </div> </fieldset>

TextBox

A text box (also re­ferred to as an edit con­trol) is a rec­tan­gu­lar con­trol where the user en­ters or ed­its text. It can be de­fined to sup­port a sin­gle line or mul­ti­ple lines of text.

Text boxes can ren­dered by spec­i­fy­ing a text type on an in­put el­e­ment. As with check­boxes and ra­dio but­tons, you should pro­vide a cor­re­spond­ing la­bel with a prop­erly set for at­tribute, and wrap both in a con­tainer with the field-row class.

Occupation

<div class=“field-row”> <label for=“tex­t17″>Oc­cu­pa­tion</​la­bel> <input id=“tex­t17” type=“text” /> </div>

Additionally, you can make use of the field-row-stacked class to po­si­tion your la­bel above the in­put in­stead of be­side it.

Address (Line 1)

Address (Line 2)

<div class=“field-row-stacked” style=“width: 200px”> <label for=“tex­t18”>Ad­dress (Line 1)</label> <input id=“tex­t18″ type=“text” /> </div> <div class=“field-row-stacked” style=“width: 200px”> <label for=“tex­t19″>Ad­dress (Line 2)</label> <input id=“tex­t19” type=“text” /> </div>

To sup­port mul­ti­ple lines in the user’s in­put, use the textarea el­e­ment in­stead.

Additional notes

<div class=“field-row-stacked” style=“width: 200px”> <label for=“tex­t20”>Ad­di­tional notes</​la­bel> <textarea id=“tex­t20″ rows=“8”></​textarea> </div>

Text boxes can also be dis­abled and have value with their cor­re­spond­ing HTML at­trib­utes.

Favorite color

<div class=“field-row”> <label for=“tex­t21″>Fa­vorite color</​la­bel> <input id=“tex­t21” dis­abled type=“text” value=“Win­dows Green”/> </div>

Slider

A slider, some­times called a track­bar con­trol, con­sists of a bar that de­fines the ex­tent or range of the ad­just­ment and an in­di­ca­tor that shows the cur­rent value for the con­trol…

Sliders can ren­dered by spec­i­fy­ing a range type on an in­put el­e­ment.

Volume: Low

High

<div class=“field-row” style=“width: 300px”> <label for=“range22”>Vol­ume:</​la­bel> <label for=“range23″>Low</​la­bel> <input id=“range23” type=“range” min=“1” max=“11″ value=“5” /> <label for=“range24″>High</​la­bel> </div>

You can make use of the has-box-in­di­ca­tor class re­place the de­fault in­di­ca­tor with a box in­di­ca­tor, fur­ther­more the slider can be wrapped with a div us­ing is-ver­ti­cal to dis­play the in­put ver­ti­cally.

Note: To change the length of a ver­ti­cal slider, the in­put width and div height.

Cowbell

<div class=“field-row”> <label for=“range25″>Cow­bell</​la­bel> <div class=“is-ver­ti­cal”> <input id=“range25″ class=“has-box-in­di­ca­tor” type=“range” min=“1” max=“3″ step=“1” value=“2″ /> </div> </div>

Dropdown

A drop-down list box al­lows the se­lec­tion of only a sin­gle item from a list. In its closed state, the con­trol dis­plays the cur­rent value for the con­trol. The user opens the list to change the value.

Dropdowns can be ren­dered by us­ing the se­lect and op­tion el­e­ments.

<select> <option>5 - Incredible!</option> <option>4 - Great!</option> <option>3 - Pretty good</​op­tion> <option>2 - Not so great</​op­tion> <option>1 - Unfortunate</option> </select>

By de­fault, the first op­tion will be se­lected. You can change this by giv­ing one of your op­tion el­e­ments the se­lected at­tribute.

<select> <option>5 - Incredible!</option> <option>4 - Great!</option> <option se­lected>3 - Pretty good</​op­tion> <option>2 - Not so great</​op­tion> <option>1 - Unfortunate</option> </select>

Window

The fol­low­ing com­po­nents il­lus­trate how to build com­plete win­dows us­ing 98.css.

Title Bar

At the top edge of the win­dow, in­side its bor­der, is the ti­tle bar (also ref­fered to as the cap­tion or cap­tion bar), which ex­tends across the width of the win­dow. The ti­tle bar iden­ti­fies the con­tents of the win­dow.

Include com­mand but­tons as­so­ci­ated with the com­mon com­mands of the pri­mary win­dow in the ti­tle bar. These but­tons act as short­cuts to spe­cific win­dow com­mands.

You can build a com­plete ti­tle bar by mak­ing use of three classes, ti­tle-bar, ti­tle-bar-text, and ti­tle-bar-con­trols.

A Title Bar

<div class=“ti­tle-bar”> <div class=“ti­tle-bar-text”>A Title Bar</div> <div class=“ti­tle-bar-con­trols”> <button aria-la­bel=“Close”></​but­ton> </div> </div>

We make use of aria-la­bel to ren­der the Close but­ton, to let as­sis­tive tech­nolo­gies know the in­tent of this but­ton. You may also use “Minimize”, “Maximize”, “Restore” and “Help” like so:

A Title Bar

A Maximized Title Bar

A Helpful Bar

<div class=“ti­tle-bar”> <div class=“ti­tle-bar-text”>A Title Bar</div> <div class=“ti­tle-bar-con­trols”> <button aria-la­bel=“Min­i­mize”></​but­ton> <button aria-la­bel=“Max­i­mize”></​but­ton> <button aria-la­bel=“Close”></​but­ton> </div> </div>

<br />

Power from Steam in the Industrial Revolution

By Gary Linscott

This is a beam en­gine. It pro­duced about fif­teen horse­power con­tin­u­ously, roughly as much power as 150 peo­ple. Engines like this turned steam into the power that drove the Industrial Revolution. This ar­ti­cle builds the en­gine up from first prin­ci­ples, us­ing in­ter­ac­tive fig­ures to ex­plore each idea (try ro­tat­ing the en­gine above with two fin­gers, or pinch­ing to zoom in­drag­ging the en­gine above, or zoom­ing with ⌘/Ctrl + scroll). Let’s start our jour­ney through the en­gine with steam.

Steam

Below, we have a pot filled with wa­ter and a fire un­der­neath. As the fire heats the wa­ter, some of it be­gins to boil and turns into steam.

Steam un­der­goes an amaz­ing trans­for­ma­tion: it ex­pands to 1,700 times the vol­ume of the orig­i­nal wa­ter. One cup of wa­ter be­comes roughly 400 litres of steam, enough to fill two bath­tubs. If the steam does­n’t have enough room to ex­pand it will push on all the walls of the con­tainer. This push on every wall is pres­sure, and we will mea­sure it in at­mos­pheres, mul­ti­ples of the or­di­nary pres­sure of the air around us. The steam also presses on the sur­face of the wa­ter, which trans­mits the pres­sure evenly to every­where the wa­ter touches.

Now we need a way to har­ness the prop­er­ties of steam.

Pistons and cylin­ders

A pis­ton is a round disc that fits snugly in­side a cylin­der. Steam pushes on one face of the pis­ton and a rod trans­mits the force else­where. The force de­pends on two things: the pres­sure of the steam and the area of the pis­ton. At a pres­sure dif­fer­ence of one at­mos­phere, each square cen­time­tre of pis­ton pro­vides about one kilo­gram of force.

Early boiler builders did­n’t know how to safely har­ness high-pres­sure steam.1 Instead, to get more force they made the pis­ton wider. Because area grows with the square of the di­am­e­ter, dou­bling the width of a pis­ton gives it four times the area and four times the force at the same pres­sure. This is why early steam en­gines had enor­mous cylin­ders, some­times wide enough for a per­son to stand in­side. In the fig­ure be­low, the boiler pres­sure never changes; try in­creas­ing only the bore un­til the pis­ton can lift the car.

With steam push­ing on our pis­ton, we can do real work. But low-pres­sure steam is not very strong. To move heavy ma­chin­ery, en­gi­neers turned to a sur­pris­ing source: the at­mos­phere.

The weight of air

Air feels weight­less, but only be­cause we are sur­rounded by it. Imagine a col­umn of air one cen­time­tre square, ex­tend­ing from your hand all the way to the top of the at­mos­phere. That col­umn weighs about one kilo­gram, so the at­mos­phere presses on every square cen­time­tre with roughly one kilo­gram of force.

We do not feel this enor­mous pres­sure be­cause the air and fluid in­side us push back at the same pres­sure. But if the pres­sure falls on one side of a sur­face, the pres­sure on the other side re­mains. This is what hap­pens when you drink through a straw. Your mouth low­ers the pres­sure in­side the straw, and the at­mos­phere push­ing on the drink in the cup forces it up­ward.

Otto von Guericke gave a spec­tac­u­lar demon­stra­tion of this ef­fect in 1654. He joined two cop­per hemi­spheres into a sphere about half a me­tre across and pumped out the air. To the amaze­ment of the ob­servers, teams of horses could not pull the halves apart. The at­mos­phere was clamp­ing them to­gether with about two tonnes of force! As soon as he opened a valve and let the air back in, they came apart by hand.

Creating a vac­uum was ex­tremely dif­fi­cult at first. Guericke had to la­bo­ri­ously pump the air out of his sphere, but steam gives us a much faster way to make one. If we fill a ves­sel with steam and then cool it with a spray of wa­ter, the steam con­denses back into roughly 1/1,700 of its vol­ume.

Fill a cylin­der with steam, con­dense it un­der­neath a pis­ton, and the at­mos­phere will drive the pis­ton down into the vac­uum. A near-per­fect vac­uum gives us the same pres­sure dif­fer­ence we used ear­lier: about one kilo­gram of force for every square cen­time­tre of pis­ton. A pis­ton half a me­tre across could col­lect al­most two tonnes of force from the at­mos­phere.

Newcomen’s en­gine

In the early 1700s, mines were get­ting deeper, and flood­ing was be­com­ing a huge prob­lem. Once a shaft reached be­low the wa­ter table, wa­ter seeped in con­tin­u­ously and had to be pumped out day and night. The pumps were dri­ven by teams of horses walk­ing in cir­cles. As one team tired, an­other took over, but the deep­est mines still flooded dur­ing wet weather and valu­able coal had to be aban­doned. A new so­lu­tion was needed, and steam would pro­vide the an­swer.

Thomas Newcomen sup­plied tools to the mines and knew that flood­ing was both a huge prob­lem and an op­por­tu­nity. He spent years turn­ing the vac­uum pis­ton stroke into an en­gine that could run all day. He con­nected the pis­ton to one end of a huge rock­ing beam and hung heavy pump rods from the other. The at­mos­phere drove the pis­ton down and lifted the pump rods; their weight then pulled the pis­ton back up while the cylin­der filled with steam again.

Newcomen’s first suc­cess­ful en­gine was in­stalled at a coal mine near Dudley in 1712. It ran at about twelve strokes per minute, lift­ing roughly forty-five litres of wa­ter fifty me­tres on every stroke. Unlike the horses, it could con­tinue around the clock with­out food or rest. Similar en­gines soon ap­peared in mines from Cornwall to Newcastle.3

Newcomen’s en­gine worked! But it used an ex­tra­or­di­nary amount of coal. The cold wa­ter sprayed di­rectly into the cylin­der, chill­ing a huge mass of iron along with the steam. Roughly three quar­ters of the steam was wasted heat­ing the cylin­der back up on every stroke.

The mines were happy with this trade­off be­cause they burned slack, small pieces of coal that were con­sid­ered waste. Anywhere else, the fuel cost was sim­ply too much. This kept the steam en­gine stuck in coal mines for the next fifty years.

The boiler

Why did Newcomen use the at­mos­phere to push the pis­ton in­stead of the steam it­self? His boiler was sim­ply not strong enough. The haystack boiler pro­duced only about a twen­ti­eth of an at­mos­phere above the sur­round­ing air. It was built from thin cop­per or iron plates joined with riv­ets, and the wide walls and weak seams could not safely hold much pres­sure.

James Watt, who we will meet in the next sec­tion, used the wag­gon boiler shown be­low. Water sat in the broad cham­ber above the fur­nace, the hot gases passed un­der­neath, and steam col­lected be­neath the rounded roof.

The broad bot­tom was good at catch­ing heat, but the wag­gon shape was ter­ri­ble at hold­ing pres­sure. Raise the steam pres­sure in the fig­ure be­low and com­pare what hap­pens to the rounded roof, the flat sides and the in­ward-curved bot­tom.

The fig­ure also shows why later builders curved the whole boiler out­ward like the roof. They rolled iron plate into long cylin­ders, re­mov­ing the flat sides and in­ward-curved bot­tom. They kept the boil­ers nar­row be­cause mak­ing a cylin­der wider in­creases the force try­ing to split it open, even when the pres­sure stays the same.4 Better iron and riv­et­ing then made much higher pres­sures pos­si­ble, and around 1800 Richard Trevithick was run­ning en­gines at sev­eral at­mos­pheres.

Now Newcomen’s use of a vac­uum makes sense. His boiler could push with per­haps fifty grams per square cen­time­tre above at­mos­pheric pres­sure. By con­dens­ing the steam and let­ting the at­mos­phere push the pis­ton in­stead, he got close to one kilo­gram per square cen­time­tre, around twenty times as much force from the same boiler.

Watt’s sep­a­rate con­denser

In 1765, Watt was re­pair­ing a model Newcomen en­gine at the University of Glasgow. He was amazed by how much steam it con­sumed and be­gan try­ing to un­der­stand where it all went. He dis­cussed the prob­lem with his col­league Joseph Black, who was study­ing the heat ab­sorbed while wa­ter boils. Black called it la­tent heat. For a kilo­gram of wa­ter, boil­ing it away takes more than five times as much en­ergy as heat­ing it from freez­ing to boil­ing.

With this knowl­edge, Watt cal­cu­lated the ex­act amount of wa­ter needed to con­dense the vol­ume of steam in the cylin­der. He was sur­prised to find that this ex­act amount barely made a vac­uum at all: the con­dens­ing steam dumped its la­tent heat into the spray, warm­ing the wa­ter un­til it stopped con­dens­ing any­thing. Adding in more cold wa­ter just cooled the cylin­der down more, wast­ing steam to heat the cylin­der back up on the next stroke. Watt’s bril­liant in­sight was to add a sec­ond ves­sel that could stay cold while the cylin­der stayed hot.5

At the end of the stroke, a valve opened and the steam rushed into the cold ves­sel, called the con­denser. As the steam turned back into wa­ter, the pres­sure fell in the con­denser and, through the con­nect­ing pipe, in the cylin­der as well. A small air pump dri­ven by the en­gine drew out the con­densed wa­ter, along with any air that had leaked in, on every stroke. Keeping the cylin­der hot and the con­denser cold cut coal con­sump­tion by about two thirds! Watt and his busi­ness part­ner Matthew Boulton turned the sav­ing into a busi­ness model, charg­ing cus­tomers one third of the money they saved on coal.

Better tools for mak­ing pre­cise cylin­ders al­lowed Watt to make an­other im­por­tant change: he closed the top of the cylin­der and used steam on both sides of the pis­ton. Steam pushed down while the con­denser low­ered the pres­sure be­low; on the re­turn stroke, the same thing hap­pened in the op­po­site di­rec­tion. This was the dou­ble-act­ing en­gine. Below, we can com­pare it with the sin­gle-act­ing cylin­der it re­placed.

The same cylin­der now pro­duced power on both strokes, and the steady push-pull made the en­gine much bet­ter suited to dri­ving ma­chin­ery. But get­ting steam in and out of the cylin­der was now more com­pli­cated. One end had to con­nect to the boiler while the other con­nected to the ex­haust, and then the two con­nec­tions had to switch be­fore the pis­ton re­turned.

The slide valve

Early steam en­gines used sev­eral sep­a­rate valves and link­ages to route the steam. Our en­gine does all of this with one slide valve. It moves only a few cen­time­tres, con­nect­ing one end of the cylin­der to fresh steam and the other to the ex­haust. As the pis­ton reaches the end of its stroke, the valve slides across and swaps the two con­nec­tions.

The valve sits in­side the steam chest, an iron box bolted to the side of the cylin­der and kept full of fresh steam. Three ports open into the chest. The two outer ports con­nect to the ends of the cylin­der, while the mid­dle one car­ries away the ex­haust. The valve is shaped like a wide, hol­low D. One edge un­cov­ers a cylin­der port and lets fresh steam en­ter, while the hol­low back joins the other cylin­der port to the ex­haust.

The valve needs to move in per­fect syn­chro­niza­tion with the pis­ton, or the en­gine will not work. This mo­tion comes from an ec­cen­tric on the en­gine’s ro­tat­ing shaft. The ec­cen­tric is a cir­cu­lar disc mounted slightly off-cen­tre, so its cen­tre trav­els in a small cir­cle as the shaft turns. A strap around the disc fol­lows this mo­tion and dri­ves the valve rod back and forth. Its po­si­tion on the shaft is cho­sen so the next steam port be­gins open­ing be­fore the pis­ton reaches the end of its stroke.

Now, we can see how the pis­ton, valve gear and ec­cen­tric work on our beam en­gine.

Using less steam

We can save a sur­pris­ing amount of coal by clos­ing the steam port be­fore the pis­ton reaches the end of its stroke. The trapped steam con­tin­ues to ex­pand and push the pis­ton, al­though its pres­sure falls as the vol­ume grows. Closing the valve at halfway, called cut­off, uses half as much steam while still pro­duc­ing about 85 per­cent of the ideal work.6 Watt patented this idea in 1782. Later com­pound en­gines sent the ex­haust from one cylin­der into a larger cylin­der, then some­times into a third, ex­tract­ing more work as the steam ex­panded.

Measuring the work

Everything we have just dis­cussed hap­pens in­side an opaque cylin­der. In 1796, Watt’s as­sis­tant John Southern built an in­stru­ment that let them see in­side. A small spring-loaded pis­ton moved a pen­cil up and down with the pres­sure, while a card moved side­ways with the main pis­ton. The re­sult­ing in­di­ca­tor di­a­gram showed the pres­sure through the en­tire stroke, and the area in­side the loop mea­sured the work pro­duced.

A leak­ing pis­ton, late cut­off and re­stricted ex­haust each pro­duce a dif­fer­ent shape, al­low­ing an en­gi­neer to di­ag­nose the en­gine from a sin­gle card. Boulton & Watt found the in­stru­ment so valu­able that they kept it se­cret for years.7

We can now con­trol the steam and pro­duce power in both di­rec­tions, but the pis­ton still moves back and forth. This is called rec­i­p­ro­cat­ing mo­tion. Pumps can use it di­rectly, but the mills dri­ving the Industrial Revolution needed ro­ta­tion.

Making ro­ta­tion

To turn the pis­ton’s back-and-forth mo­tion into ro­ta­tion, our beam en­gine uses a crank, al­though Watt’s first ro­tat­ing en­gines could not use one.8 A pin off­set from the cen­tre of the shaft is joined to the pis­ton by a con­nect­ing rod. The push on the pin turns the shaft, but not equally through the rev­o­lu­tion. Twice per turn the crank and con­nect­ing rod line up, at po­si­tions called dead cen­tres, where the pis­ton pushes straight through the shaft and pro­duces no ro­ta­tion at all. With noth­ing to carry it past these points, the en­gine would stop the first time the crank reached one.

The large fly­wheel fixes this prob­lem. It stores en­ergy while the crank has good lever­age, then re­turns that en­ergy to keep the en­gine spin­ning past the dead cen­tres. In the fig­ure be­low, the shaded band in the in­set shows the fly­wheel col­lect­ing and re­pay­ing en­ergy through each rev­o­lu­tion. Try the fly­wheel mass slider: a heav­ier wheel changes speed less, giv­ing the en­gine a smooth and steady ro­ta­tion.

Our en­gine can now turn a shaft with­out stop­ping. But join­ing the pis­ton rod to the crank turns out to be harder than it looks.

The beam and the par­al­lel mo­tion

Now, look closely at the con­nect­ing rod in the fig­ure be­low. As the crank turns, its pin moves side­ways as well as up and down. The pis­ton rod can­not fol­low it be­cause it must travel straight through the seal at the top of the cylin­der. If we con­nect them di­rectly, the rod pushes the pis­ton side­ways and quickly de­stroys the seal.

The beam car­ried the side­ways load into a large round bear­ing, which work­shops could make ac­cu­rately. But its end moved in an arc, and Watt still needed the pis­ton rod to travel in a straight line.

His in­ge­nious so­lu­tion was the par­al­lel mo­tion, patented in 1784. A set of hinged links joins the beam to a fixed point on the en­gine. As the beam pulls the pis­ton rod side­ways in one di­rec­tion, an­other link pulls it al­most ex­actly the same amount in the other. The two curves can­cel, leav­ing a path that is re­mark­ably close to a straight line. Watt was so pleased with the mech­a­nism that he wrote he was “more proud of the par­al­lel mo­tion than of any other me­chan­i­cal in­ven­tion I have ever made.”

Our pis­ton can now turn the crank with­out be­ing pulled side­ways. At the far end of the beam, we also get a con­ve­nient source of back-and-forth mo­tion, which the en­gine uses to keep its boiler filled with wa­ter.

The pump

As the en­gine runs, the boiler turns wa­ter into steam. To keep it go­ing, we need to re­place that wa­ter with­out stop­ping. We can’t sim­ply con­nect a wa­ter tank, be­cause the pres­sure in­side the boiler would push the wa­ter back out. Instead, the far end of the beam dri­ves the small pump be­side the base of the en­gine, forc­ing fresh wa­ter into the boiler.

Inside the pump is a nar­row plunger and two one-way check valves. As the plunger rises, the pres­sure falls, the in­let valve opens and wa­ter en­ters from the tank. On the way down, the pres­sure rises, clos­ing the in­let valve and open­ing the out­let to­wards the boiler. The chang­ing wa­ter pres­sure op­er­ates both valves au­to­mat­i­cally.

The pump must pro­duce slightly more pres­sure than the boiler, but it does not need to move much wa­ter on each stroke. Making the plunger nar­row keeps the re­quired force small, for the same pres­sure-times-area rea­son that made our en­gine pis­ton wide. A small part of the en­gine’s power can now keep the boiler full, while the rest turns the fly­wheel.

Powering the mill

We talked about why mills need ro­ta­tion, but not how they used it. Before steam en­gines, wa­ter-pow­ered mills had to sit be­side a river. The flow­ing wa­ter turned a large wa­ter­wheel, which drove a main shaft, and iron shafts, pul­leys and leather belts car­ried that ro­ta­tion through the build­ing to power the ma­chines. Our ex­am­ple mill here has a saw for cut­ting wood and a power loom which wove cloth. Click ei­ther ma­chine to shift its belt onto the loose pul­ley; that ma­chine will coast to a stop while the shaft and the other ma­chine con­tinue run­ning.

It is not in­tu­itive that a leather belt can trans­mit enough power to drive a ma­chine that ten strong peo­ple could not. With only fric­tion be­tween the iron pul­leys and the leather pro­vid­ing the con­nec­tion, it seems that the belt would slip. The physics un­der­ly­ing fric­tion is fas­ci­nat­ing. Imagine a huge ship tied to an iron bol­lard on the dock with a rope. Tension in the first small part of the rope presses it against the iron, and the re­sult­ing fric­tion re­duces the ten­sion that reaches the next part, and so on around the post.9

Now, let’s re­turn to leather belts and iron pul­leys. A belt is in­stalled un­der ten­sion, so at rest its two sides pull with roughly equal force. Once the ma­chine needs power, fric­tion trans­fers some of that pull from the re­turn­ing side to the dri­ving side.10

The power trans­ferred by a belt is the dif­fer­ence in ten­sion mul­ti­plied by the belt speed. At full mill scale, a six­teen-foot fly­wheel at sixty rev­o­lu­tions per minute has a belt speed of about fif­teen me­tres a sec­ond. If the load makes one side pull with 2,000 new­tons more than the other, a foot-wide leather belt can carry about forty horse­power.

The fight for wa­ter

Richard Arkwright’s wa­ter-pow­ered mill at Cromford opened in 1771, and the fac­tory sys­tem that fol­lowed cre­ated fierce de­mand for the best river sites. Water-powered mills were also de­pen­dent on the weather: a dry sea­son could shut down the fac­tory.

Steam pump­ing en­gines of­fered a so­lu­tion. An en­gine lifted the wa­ter that had passed be­neath the wheel back up the hill, al­low­ing the same wa­ter to fall through the wheel again. This kept the smooth turn of the wa­ter wheel, but wasted coal mov­ing the wa­ter. Watt sold six­teen to twenty horse­power pump­ing en­gines to de­liver ten horse­power to the ma­chines.

Watt’s dou­ble-act­ing en­gine, beam, crank and fly­wheel let the en­gine di­rectly turn the line shaft. This met a huge de­mand from mill own­ers who wanted to build near work­ers and ma­te­ri­als rather than around a par­tic­u­lar stretch of river.11 One prob­lem re­mained, though: every time a ma­chine was turned on or off, the load on the en­gine changed.

The gov­er­nor

The beam en­gine still needed a way to keep its speed con­stant. Imagine it at the be­gin­ning of the day, turn­ing at 30 rpm with no ma­chines con­nected. When the first ma­chine is con­nected, it draws power from the en­gine and slows it down. The en­gine dri­ver could open the throt­tle by hand un­til the shaft re­turned to 30 rpm, but this was tir­ing work, and mis­takes had se­vere con­se­quences. A cast-iron fly­wheel could burst if it spun too quickly.

Instead, Watt adapted a de­vice used on wind­mills to ad­just the steam au­to­mat­i­cally.12 Bevel gears turn a ver­ti­cal spin­dle, and two heavy balls hang from hinged arms at­tached to it. As the en­gine speeds up, the balls swing out­ward and lift a slid­ing col­lar. A fork and long rod carry this mo­tion across the en­gine and turn the steam cock to­wards closed. When the en­gine slows, the balls fall and open the cock again.13

The whole ma­chine

Let’s re­turn to the com­plete en­gine from the be­gin­ning of the ar­ti­cle. Every mech­a­nism we stud­ied on its own is here, run­ning in its place. The fig­ure fol­lows the power once along its whole path, from the boiler steam to the belt that leaves for the mill.14

Epilogue

The beam en­gine was a prod­uct of the tools and sci­ence of its time. Watt used a beam and par­al­lel mo­tion partly be­cause the work­shops of the 1780s could not make long, ac­cu­rate guides for a crosshead. As plan­ing ma­chines im­proved dur­ing the nine­teenth cen­tury, those straight guides be­came prac­ti­cal. The heavy beam was no longer re­quired, and by the 1860s most new mill en­gines drove the fly­wheel di­rectly.15

Line shafts and leather belts out­lived the beam en­gine, re­main­ing above fac­tory floors well into the twen­ti­eth cen­tury. Electric mo­tors fi­nally gave each ma­chine its own source of ro­ta­tion. Wires re­placed the long shafts and belts, and stop­ping one lathe no longer changed the load on a cen­tral en­gine dri­ving the en­tire mill.

The most dra­matic change was how much power newer en­gines ex­tracted from coal. Corliss valves con­trolled steam ex­pan­sion more pre­cisely, com­pound en­gines ex­panded it through sev­eral cylin­ders, and tur­bines even­tu­ally re­placed the pis­ton with a con­tin­u­ously ro­tat­ing wheel. Newcomen con­verted only about half a per­cent of the heat into use­ful work. Watt’s con­denser raised the use­ful share to roughly three per­cent, enough for steam power to move away from the coal mines. By the 1890s, high pres­sure and com­pound ex­pan­sion pushed large ma­rine en­gines such as the Titanic’s be­yond ten per­cent. A mod­ern steam tur­bine plant con­verts more than forty per­cent.

Footnotes

Thomas Savery tried to use higher-pres­sure steam in the 1690s with boil­ers made from sol­dered cop­per. The fire could soften the sol­der, and the leak­ing joints needed fre­quent re­pair. Newcomen took a dif­fer­ent route. Because the steam in his boiler was barely above at­mos­pheric pres­sure, he could use thin lead and wrought-iron plates joined with riv­ets. The seams still leaked and the metal cor­roded, but the boiler did not have to con­tain the pres­sure that Savery’s pump re­quired. ↩

Thomas Savery tried to use higher-pres­sure steam in the 1690s with boil­ers made from sol­dered cop­per. The fire could soften the sol­der, and the leak­ing joints needed fre­quent re­pair. Newcomen took a dif­fer­ent route. Because the steam in his boiler was barely above at­mos­pheric pres­sure, he could use thin lead and wrought-iron plates joined with riv­ets. The seams still leaked and the metal cor­roded, but the boiler did not have to con­tain the pres­sure that Savery’s pump re­quired. ↩

Casting a large iron cylin­der was much eas­ier than mak­ing the in­side straight and round. Newcomen’s cylin­ders were ground by hand, then sealed with a leather flap cov­ered by a layer of wa­ter, which could fol­low the un­even bore. Denis Papin had pro­posed the vac­uum-pis­ton prin­ci­ple in 1690: a small amount of wa­ter boiled be­neath a pis­ton and pushed it up­ward, then con­den­sa­tion al­lowed the at­mos­phere to force it down again. His ap­pa­ra­tus demon­strated a sin­gle stroke but did not be­come a con­tin­u­ously run­ning en­gine. ↩

Casting a large iron cylin­der was much eas­ier than mak­ing the in­side straight and round. Newcomen’s cylin­ders were ground by hand, then sealed with a leather flap cov­ered by a layer of wa­ter, which could fol­low the un­even bore. Denis Papin had pro­posed the vac­uum-pis­ton prin­ci­ple in 1690: a small amount of wa­ter boiled be­neath a pis­ton and pushed it up­ward, then con­den­sa­tion al­lowed the at­mos­phere to force it down again. His ap­pa­ra­tus demon­strated a sin­gle stroke but did not be­come a con­tin­u­ously run­ning en­gine. ↩

A pis­ton 50 centimetres across has about 2,000 square cen­time­tres of area, enough to col­lect two tonnes of force from a per­fect vac­uum. After al­low­ing for leaks and the weight of the pump rods, it might do about four kilo­watts of use­ful work. A horse can sus­tain much less than one horse­power over a work­ing day, so re­plac­ing the en­gine re­quired a re­lay of per­haps fif­teen or twenty an­i­mals. Watt later sold his en­gines by the num­ber of horses they re­placed, and fixed one horse­power at 33,000 foot-pounds per minute. ↩

A pis­ton 50 centimetres across has about 2,000 square cen­time­tres of area, enough to col­lect two tonnes of force from a per­fect vac­uum. After al­low­ing for leaks and the weight of the pump rods, it might do about four kilo­watts of use­ful work. A horse can sus­tain much less than one horse­power over a work­ing day, so re­plac­ing the en­gine re­quired a re­lay of per­haps fif­teen or twenty an­i­mals. Watt later sold his en­gines by the num­ber of horses they re­placed, and fixed one horse­power at 33,000 foot-pounds per minute. ↩

For a bar­rel with ra­dius r and length L, the cut has an area of 2rL, so pres­sure p pushes the halves apart with a force of 2prL. Two edges of length L re­sist that force, leav­ing pr in each me­tre of plate. At two at­mos­pheres and a half-me­tre ra­dius, this is about ten tonnes per me­tre. The stress run­ning length­wise is only half as large, which is why a cylin­dri­cal boiler tends to split along its length like a sausage. A sphere di­vides the load equally and is stronger still, but it was much harder to make from rolled and riv­eted plate. ↩

For a bar­rel with ra­dius r and length L, the cut has an area of 2rL, so pres­sure p pushes the halves apart with a force of 2prL. Two edges of length L re­sist that force, leav­ing pr in each me­tre of plate. At two at­mos­pheres and a half-me­tre ra­dius, this is about ten tonnes per me­tre. The stress run­ning length­wise is only half as large, which is why a cylin­dri­cal boiler tends to split along its length like a sausage. A sphere di­vides the load equally and is stronger still, but it was much harder to make from rolled and riv­eted plate. ↩

Watt’s en­gine needed a much more ac­cu­rate cylin­der than Newcomen’s loose, wa­ter-sealed pis­ton. Around 1775, the iron­mas­ter John Wilkinson built a bor­ing mill with a rigid cut­ting bar sup­ported at both ends, adapt­ing tech­niques he had de­vel­oped for bor­ing can­nons. In 1776, Matthew Boulton re­ported that a 50-inch cylin­der in­stalled at Tipton var­ied by less than the thick­ness of an old shilling. This ac­cu­racy kept the steam from leak­ing around Watt’s pis­ton and made the new en­gine prac­ti­cal. ↩

Watt’s en­gine needed a much more ac­cu­rate cylin­der than Newcomen’s loose, wa­ter-sealed pis­ton. Around 1775, the iron­mas­ter John Wilkinson built a bor­ing mill with a rigid cut­ting bar sup­ported at both ends, adapt­ing tech­niques he had de­vel­oped for bor­ing can­nons. In 1776, Matthew Boulton re­ported that a 50-inch cylin­der in­stalled at Tipton var­ied by less than the thick­ness of an old shilling. This ac­cu­racy kept the steam from leak­ing around Watt’s pis­ton and made the new en­gine prac­ti­cal. ↩

For a cylin­der with vol­ume V and pres­sure p, ad­mit­ting steam for the full stroke pro­duces work pV. With cut­off at half stroke, the ad­mit­ted steam pro­duces pV/​2 dur­ing the first half. As it ex­pands through the rest of the cylin­der, it adds about 0.35 pV more, as­sum­ing it fol­lows Boyle’s law and re­mains hot. This gives 85 per­cent of the full-stroke work from half the steam. Cutting off ear­lier saves still more steam, but even­tu­ally the falling pres­sure be­comes too weak to over­come fric­tion and the poor lever­age near dead cen­tre. ↩

For a cylin­der with vol­ume V and pres­sure p, ad­mit­ting steam for the full stroke pro­duces work pV. With cut­off at half stroke, the ad­mit­ted steam pro­duces pV/​2 dur­ing the first half. As it ex­pands through the rest of the cylin­der, it adds about 0.35 pV more, as­sum­ing it fol­lows Boyle’s law and re­mains hot. This gives 85 per­cent of the full-stroke work from half the steam. Cutting off ear­lier saves still more steam, but even­tu­ally the falling pres­sure be­comes too weak to over­come fric­tion and the poor lever­age near dead cen­tre. ↩

The pres­sure and vol­ume graph out­lived the me­chan­i­cal in­di­ca­tor. In 1834, Émile Clapeyron used the same type of di­a­gram to ex­plain Sadi Carnot’s the­ory of heat en­gines, and ther­mo­dy­nam­ics still plots pres­sure against vol­ume to­day. ↩

The pres­sure and vol­ume graph out­lived the me­chan­i­cal in­di­ca­tor. In 1834, Émile Clapeyron used the same type of di­a­gram to ex­plain Sadi Carnot’s the­ory of heat en­gines, and ther­mo­dy­nam­ics still plots pres­sure against vol­ume to­day. ↩

James Pickard patented the use of a crank on a steam en­gine in 1780, so William Murdoch de­signed the sun-and-planet gear as a way around the patent. A gear at­tached to the con­nect­ing rod trav­elled around a sec­ond gear on the fly­wheel shaft, turn­ing the shaft twice for every cy­cle of the beam. Once Pickard’s patent ex­pired in 1794, builders re­turned to the much sim­pler crank used on our en­gine.

Murdoch’s mech­a­nism be­longs to the epicyclic, or plan­e­tary, fam­ily of gears. Several planet gears can share the load while the in­put and out­put re­main on the same axis, mak­ing the arrange­ment com­pact and strong. Planetary gears ap­pear in cord­less drills, bi­cy­cle hubs, au­to­matic trans­mis­sions and wind tur­bines. Hybrid cars even use them to di­vide power be­tween the en­gine, elec­tric mo­tor and wheels. ↩

James Pickard patented the use of a crank on a steam en­gine in 1780, so William Murdoch de­signed the sun-and-planet gear as a way around the patent. A gear at­tached to the con­nect­ing rod trav­elled around a sec­ond gear on the fly­wheel shaft, turn­ing the shaft twice for every cy­cle of the beam. Once Pickard’s patent ex­pired in 1794, builders re­turned to the much sim­pler crank used on our en­gine.

Murdoch’s mech­a­nism be­longs to the epicyclic, or plan­e­tary, fam­ily of gears. Several planet gears can share the load while the in­put and out­put re­main on the same axis, mak­ing the arrange­ment com­pact and strong. Planetary gears ap­pear in cord­less drills, bi­cy­cle hubs, au­to­matic trans­mis­sions and wind tur­bines. Hybrid cars even use them to di­vide power be­tween the en­gine, elec­tric mo­tor and wheels. ↩

If we slice the wrapped rope into small pieces and add the force vec­tors, each piece has a small in­ward force equal to the lo­cal ten­sion mul­ti­plied by the an­gle it cov­ers. Friction can re­move up to μ times that in­ward force, about 0.3 for rope on cast iron.

Repeating that frac­tional re­duc­tion pro­duces the ex­po­nen­tial e−μθ. With a 2,000-newton pull, about the weight of an up­right pi­ano, one turn around the post leaves 300 new­tons, two leave 46, and three leave seven. ↩

If we slice the wrapped rope into small pieces and add the force vec­tors, each piece has a small in­ward force equal to the lo­cal ten­sion mul­ti­plied by the an­gle it cov­ers. Friction can re­move up to μ times that in­ward force, about 0.3 for rope on cast iron.

Repeating that frac­tional re­duc­tion pro­duces the ex­po­nen­tial e−μθ. With a 2,000-newton pull, about the weight of an up­right pi­ano, one turn around the post leaves 300 new­tons, two leave 46, and three leave seven. ↩

FLUX 3 is now avail­able in Early Access.

FLUX 3 is our new mul­ti­modal foun­da­tion model. It jointly learns from im­ages, videos, and au­dio within a uni­fied ar­chi­tec­ture, be­cause what it needs to learn is not any one of these el­e­ments in iso­la­tion. Instead, a model must learn a rep­re­sen­ta­tion of the world: how ob­jects hold to­gether, how things move, and how events sound.

No sin­gle modal­ity pro­vides a com­plete de­scrip­tion. Each is a pro­jec­tion of the same un­der­ly­ing re­al­ity, cap­tured by dif­fer­ent sen­sors, each of which loses some in­for­ma­tion in the process. Images cap­ture spa­tial struc­tures and re­la­tion­ships at a spe­cific point in time. Videos re­store the di­men­sion of time and re­veal tem­po­ral dy­nam­ics and phys­i­cal laws. Audio re­veals causal re­la­tion­ships be­tween me­chan­i­cal phe­nom­ena and acoustics that vi­sion alone can­not de­tect. Language links these per­cep­tions to goals, ab­strac­tions, and in­struc­tions.

Learn from one and you get a good model of that pro­jec­tion. Learn from all of them at once and their mu­tual con­straints tell you more: the sound has to match the im­pact, the mo­tion has to obey the mass, the fu­ture has to fol­low from the past. The modal­i­ties stop be­ing sep­a­rate and start be­ing ev­i­dence about one un­der­ly­ing re­al­ity.

FLUX 3 is our first model built en­tirely on that prin­ci­ple, and a check­point on our mis­sion to de­velop real-world vi­sual in­tel­li­gence: mod­els that per­ceive, pre­dict, and act across phys­i­cal and dig­i­tal en­vi­ron­ments. Early re­sults in con­tent cre­ation and phys­i­cal AI sug­gest it is the right path.

FLUX 3: One model, mul­ti­ple ca­pa­bil­i­ties.

FLUX 3 builds on Self-Flow, our ap­proach for ef­fi­ciently align­ing mul­ti­modal gen­er­a­tion and un­der­stand­ing within the same un­der­ly­ing ar­chi­tec­ture. Based on this ap­proach, we sig­nif­i­cantly scaled up com­pute and data re­sources to train FLUX 3 across video, im­ages, and au­dio at the same time.

Self-Flow vs. Flow Matching (FM). Left: gen­er­a­tion er­ror (Fréchet dis­tance) per modal­ity, each nor­mal­ized to FM = 100 (lower is bet­ter). Right: suc­cess rate on ma­nip­u­la­tion tasks av­er­aged over four task groups through fine­tun­ing (higher is bet­ter).

Capabilities & Early Evaluations

As a re­sult, FLUX 3 is ca­pa­ble of mix­ing modal­i­ties and gen­er­at­ing im­ages and video+au­dio jointly; both from pure text prompts as well as when pro­vid­ing in­put ref­er­ences such as im­ages and video. We are high­light­ing a few of the mod­el’s key ca­pa­bil­i­ties be­low.

Video

FLUX 3 can cre­ate highly di­verse videos with au­dio up to 20 sec­onds in length in a sin­gle gen­er­a­tion.

Its core ca­pa­bil­i­ties in­clude the fol­low­ing (all out­puts come with na­tive au­dio gen­er­a­tion):

Text-to-video gen­er­a­tion.

Image-to-video gen­er­a­tion, ei­ther con­tin­u­ing from a start­ing frame (“animation”) or us­ing im­ages as vi­sual ref­er­ences.

Video-to-video gen­er­a­tion from a ref­er­ence clip, car­ry­ing cen­tral el­e­ments of a source video - for in­stance the same char­ac­ter - into a new scene or con­text.

Generative video-au­dio con­tin­u­a­tion from in­put video and au­dio.

Keyframe-to-video gen­er­a­tion for con­trolled tran­si­tions be­tween de­fined mo­ments.

Multilingual di­a­logue.

A broad range of vi­sual styles and as­pect ra­tios, ex­tend­ing far be­yond con­ven­tional cin­e­matic out­put.

Agentic chain­ing of in­di­vid­ual clips into longer, multi-shot se­quences.

High style di­ver­sity — FLUX 3 Video eas­ily han­dles ranges of styles from can­did cam­corder footage to an­i­ma­tion and cin­e­mat­ics.

Strong ty­pog­ra­phy gen­er­a­tion and an­i­mated de­signs.

For the pre­lim­i­nary analy­sis be­low, we gen­er­ated 10-second text-to-video clips in 720p with au­dio.

Evaluations are early and we ex­pect fur­ther im­prove­ments

As the model and the har­ness around it are still in de­vel­op­ment, these re­sults are pre­lim­i­nary, and we ex­pect fur­ther im­prove­ments dur­ing the early ac­cess phase. Across early eval­u­a­tions, FLUX 3 was pre­ferred over Grok Imagine Video in up to 69% of com­par­isons, Kling v3 Pro in 60%, Happy Horse v1 in 59%, Happy Horse 1.1 in 57%, Seedance 2.0 and Gemini Omni Flash in 52%. FLUX 3 was pre­ferred over Runway Gen-4.5 in 77% of com­par­isons and over Luma Ray 3.2 in 93% of com­par­isons.

While still in de­vel­op­ment, FLUX 3 Video is al­ready par­tic­u­larly strong in cap­tur­ing hu­man fa­cial ex­pres­sions, as­so­ci­at­ing sounds with phys­i­cal events, and mul­ti­lin­gual ca­pa­bil­i­ties. Furthermore, these ca­pa­bil­i­ties can be com­bined to cre­ate se­quences last­ing sev­eral min­utes, where vi­sual ref­er­ences help en­sure that the char­ac­ters re­main con­sis­tent across all scenes.

FLUX 3 Video is now avail­able in Early Access here

Image

FLUX 3 can syn­the­size and edit im­ages in a wide va­ri­ety of styles, as­pect ra­tios, and res­o­lu­tions. In pre­lim­i­nary eval­u­a­tions con­ducted dur­ing mid­train­ing, FLUX 3 al­ready shows a sig­nif­i­cant im­prove­ment over ear­lier ver­sions of FLUX: its abil­ity to han­dle com­plex prompts and text gen­er­a­tion has im­proved sig­nif­i­cantly. The model pro­duces a wide range of out­put styles (see the fol­low­ing sam­ples), and is able to ren­der high-ac­cu­racy text in mul­ti­ple lan­guages.

As with video eval­u­a­tions, these are pre­lim­i­nary re­sults, and we ex­pect fur­ther im­prove­ments be­fore re­lease. We will open up an early ac­cess phase for FLUX 3 Image in the fol­low­ing weeks.

Action

FLUX 3′s world un­der­stand­ing ex­tends to ac­tion pre­dic­tion. We have taken two routes to it: in­te­grat­ing na­tive ac­tion pre­dic­tion into FLUX 3 di­rectly, scal­ing up our ini­tial work in Self-Flow; and us­ing the pre­trained video back­bone as a dy­nam­ics-aware foun­da­tion that spe­cial­ized ac­tion mod­els can be fine­tuned from with lim­ited task-spe­cific data.

For the sec­ond, mimic ro­bot­ics was one of the first part­ners to gain early ac­cess to FLUX 3. Together we de­vel­oped FLUX-mimic, a video-ac­tion model com­bin­ing the FLUX 3 back­bone with mim­ic’s ex­per­tise in ro­bot learn­ing for dex­ter­ous ma­nip­u­la­tion and pro­duc­tion de­ploy­ment. Read our the­sis on why phys­i­cal AI and con­tent cre­ation run on the same foun­da­tion, and how it’s be­ing tested on real pro­duc­tion tasks at Audi.

Launch Plan

Over the next few weeks and months, we will make the fol­low­ing ca­pa­bil­i­ties avail­able, each af­ter an early ac­cess phase for en­sur­ing smooth roll­out, col­lect­ing feed­back and rig­or­ous safety-test­ing. All ca­pa­bil­i­ties are built from the same un­der­ly­ing mul­ti­modal flow match­ing model. These ca­pa­bil­i­ties and mod­els in­clude:

Video and au­dio gen­er­a­tion and edit­ing through APIs and pri­vate weight ac­cess. (“FLUX 3 Video”)

Action pre­dic­tion through se­lected re­search and com­mer­cial part­ners, be­gin­ning with mimic ro­bot­ics (“FLUX-mimic and FLUX 3 Action”)

Image syn­the­sis and edit­ing through APIs and pri­vate weight ac­cess. (“FLUX 3 Image”)

Open-weight ac­cess to a mul­ti­modal back­bone, for con­tent cre­ation (video, au­dio and im­age) and ac­tion pre­dic­tion. (“FLUX 3 Dev”)

We will also re­lease more tech­ni­cal de­tails on the un­der­ly­ing ap­proach.

Request early ac­cess here

What’s next?

We are only be­gin­ning to scratch the sur­face of ver­sa­tile, ca­pa­ble, uni­fied mul­ti­modal mod­els, and what they will en­able. From in­ter­ac­tive im­age & video edit­ing, sim­u­la­tion to com­puter use and phys­i­cal AI, the fron­tier is wide open. While we grad­u­ally roll out these new ca­pa­bil­i­ties, we are al­ready work­ing on the next gen­er­a­tion mod­els. Our goal is to unify per­cep­tual, ac­tion and lan­guage pre­dic­tion in the same uni­fied model.

If you are in­ter­ested in ex­plor­ing and build­ing with FLUX 3, get in touch here. If you are in­ter­ested in con­tribut­ing to our mis­sion, join us! We are hir­ing in Germany and the US.

A brief com­ment on Codeberg’s new terms, and why a free-soft­ware host de­cid­ing which pro­jects are wel­come wor­ries me more than the bans them­selves.

My pri­mary rea­son for leav­ing GitHub was not about a sin­gle fea­ture or a sin­gle out­age, but about the “enshittification” of the plat­form un­der Microsoft’s own­er­ship. The web in­ter­face got rewrit­ten into a slug­gish pile of JavaScript that ei­ther broke things which used to just work, or made them so hor­ri­bly slow that us­ing them be­came a PITA. Beyond the tech­ni­cal de­cay GitHub had turned into de facto “public in­fra­struc­ture” in much the same way that WhatsApp has, host­ing the source code of a very large share of the world’s soft­ware and, through that, giv­ing Microsoft a de­gree of lever­age and sur­veil­lance over every­one’s pro­jects, and by ex­ten­sion every­one’s dig­i­tal lives, that no sin­gle com­pany should hold. On top of that, sto­ries about le­git­i­mate de­vel­op­ers los­ing their ac­counts due to ar­bi­trary bans by Microsoft only re­in­forced the feel­ing that it would be a good idea to at least have a backup some­where else.

Codeberg looked like a vi­able al­ter­na­tive. It of­fered free and open-source pro­jects a rep­utable home and, more im­por­tantly, an equally free one, run by a non-profit as­so­ci­a­tion rather than a sub­sidiary of the largest soft­ware ven­dor on the planet. Unfortunately, the lat­est up­date to its terms of ser­vice seems to mark a first step in chang­ing one part I moved there for, namely the “freedom” part.

Human stu­pid­ity

Every pro­ject I’ve pub­lished so far was built with 100% hu­man stu­pid­ity rather than “artificial in­tel­li­gence”, or, more ac­cu­rately, LLMs. I don’t hold par­tic­u­larly strong feel­ings about Codeberg ban­ning pro­jects that are pre­dom­i­nantly LLM-driven, at least not feel­ings as strong as the ones I hold about the si­mul­ta­ne­ous ban of le­git­i­mate cryp­tocur­rency pro­jects, which reads as though it got lumped in for no rea­son other than that most peo­ple still re­mem­ber the vil­lain-du-jour that crypto was in the years be­fore LLMs took that ti­tle. The two clauses landed within days of each other, the LLM pro­hi­bi­tion on the 29th of June and the cryp­tocur­rency pro­hi­bi­tion on the 2nd of July, both as Assembly 2026 pro­pos­als, and the terms now file the lat­ter un­der, of all things, “content that harms the rep­u­ta­tion of Codeberg”, which sounds like legalese for “we don’t have a solid rea­son or an ac­tual num­ber of bad prece­dents to cat­e­gor­i­cally ban it”.

The an­nounce­ment blog post, how­ever, reads very poorly, and the sec­tion ti­tled “The de­vel­op­ment team of none” is the worst of it. It states:

Using LLMs to work with your code gives you a kick of adren­a­line. You can de­velop at a rapid pace, build things as if you had a large team. Only that you have none. In fact, you are (often) alone, work­ing with a sta­tis­ti­cal ma­chine that turns en­ergy into code.

Using LLMs to work with your code gives you a kick of adren­a­line. You can de­velop at a rapid pace, build things as if you had a large team. Only that you have none. In fact, you are (often) alone, work­ing with a sta­tis­ti­cal ma­chine that turns en­ergy into code.

And, a lit­tle fur­ther down, it says:

It seems like many ‘vibe coders’ don’t re­al­ize that they don’t ac­tu­ally have a com­mu­nity around them.

It seems like many ‘vibe coders’ don’t re­al­ize that they don’t ac­tu­ally have a com­mu­nity around them.

This is out of touch with how most free soft­ware gets made. The ma­jor­ity of FOSS de­vel­op­ers are one-man-shows, and the only cOm­Mu­NiTy they have around them are the users re­quest­ing fea­tures or re­port­ing bugs while most of the time not con­tribut­ing in any form what­so­ever. I’ve been pub­lish­ing silly lit­tle tools for decades, pre­dat­ing this web­site and even GitHub it­self (remember when SourceForge was the hot sh.t?), and not one of them has ever had an ac­tual “community” around it, at least not in the ro­man­ti­cized sense that Codeberg paints in that post. I’m a lone wolf who codes every­thing by hand and spends an ab­surd amount of time do­ing ex­actly that, and the no­tion that an LLM is the thing sep­a­rat­ing a real pro­ject with a real com­mu­nity from a fake one does not hold up once you look at how the av­er­age use­ful lit­tle tool on any forge comes to ex­ist in the first place.

It’s frankly a bit snotty of Codeberg to make this ar­gu­ment at all, con­sid­er­ing that the plat­form ef­fec­tively lives in­side the Forgejo bub­ble, and Forgejo mu­tinied in­her­ited its com­mu­nity of ac­tive con­trib­u­tors from Gitea, who had spent the bet­ter part of six years build­ing that com­mu­nity be­fore Forgejo even ex­isted. A pro­ject that ac­quired its own com­mu­nity by hard-fork­ing some­one else’s, then turned around to lec­ture solo de­vel­op­ers about not hav­ing one, is a dif­fi­cult po­si­tion to ar­gue from with a straight face.

In ad­di­tion, Codeberg con­flates “having a com­mu­nity” with “being le­git­i­mate soft­ware worth host­ing”, when the bar for a per­sonal pro­ject has al­ways been a work­ing build, ide­ally a li­cense, and maybe a README, and not a chan­nel full of con­trib­u­tors. A good deal of what makes the small, sin­gle-au­thor tool ecosys­tem worth hav­ing is pre­cisely that it does­n’t need a com­mu­nity to jus­tify its ex­is­tence, and a forge whose en­tire sell­ing point is host­ing the code of in­di­vid­u­als is an odd place to ar­gue the op­po­site.

Censorship

The part that both­ers me is­n’t the spe­cific ban on LLM pro­jects, or the spe­cific ban on cryp­tocur­rency pro­jects. It’s that a hub built around “free soft­ware” is now telling its users which kinds of soft­ware are deemed good and which are not, and that is closer to cen­sor­ship than it might seem. Once a plat­form writes into its terms that an en­tire cat­e­gory “harms its rep­u­ta­tion” and can be re­moved on that ba­sis, the de­cid­ing fac­tor stops be­ing whether the code is le­gal, or func­tional, or use­ful, and be­comes whether it aligns with a po­si­tion the plat­form has taken. I would ar­gue that a sig­nif­i­cant share of the pro­jects caught by a blan­ket ban of that kind are le­git­i­mate soft­ware rather than vibe-coded slop or sh.tcoin im­ple­men­ta­tions.

Every plat­form I can think of that took this ap­proach be­came di­vi­sive the mo­ment it started en­forc­ing an ide­ol­ogy on its users, what­ever that ide­ol­ogy hap­pened to be, and how­ever jus­ti­fied it looked at the time. The mech­a­nism is al­ways the same, where a real prob­lem shows up, an un­pop­u­lar cat­e­gory be­comes the ob­vi­ous cul­prit, the plat­form bans the cat­e­gory in­stead of ad­dress­ing the prob­lem, and that ban then be­comes the prece­dent for the next cat­e­gory, and the one af­ter that. The cat­e­gory that is un­con­tro­ver­sial to ban to­day is the rea­son the mech­a­nism ex­ists to­mor­row, and the users who ap­plauded the first ban rarely get asked about the sec­ond one.

I do ac­knowl­edge that both cat­e­gories aren’t free of prob­lems. LLM-driven repos­i­to­ries do strain in­fra­struc­ture, do gen­er­ate un­man­age­able vol­umes of low-qual­ity is­sues and pull re­quests, and do carry real ques­tions about copy­right and code prove­nance, all of which Codeberg names in its post. The cryp­tocur­rency space, in turn, might have pro­duced more out­right scams than al­most any other cor­ner of soft­ware. However, a cat­e­goric ban on the vil­lain-du-jour is not a so­lu­tion to any of that.

We now even have peo­ple like Linus Torvalds mak­ing the fairly rea­son­able ar­gu­ment that an LLM is just a tool, and “clearly a use­ful one”, with a le­git­i­mate place in Linux ker­nel de­vel­op­ment when it’s used care­fully and its out­put is held to the same stan­dard as every­thing else. If the main­tainer of the largest and most con­se­quen­tial open-source pro­ject on the planet can treat LLMs as a tool to be judged on its re­sults rather than a cat­e­gory to be banned on sight, a back­yard code forge can man­age the same.

I, too, am wor­ried about the im­pact of LLMs on tech, and on so­ci­ety in gen­eral, go­ing for­ward, and I’d guess I’m about as wor­ried as who­ever wrote Codeberg’s pol­icy. I just don’t be­lieve that ban­ning con­tent, which is very much what this amounts to, is the way for­ward.

Reasonable so­lu­tion

What I wish Codeberg had reached for is a so­lu­tion that treats the ac­tual prob­lem, which by their own ac­count in that same post is re­source con­sump­tion and the in­fra­struc­ture cost that comes with it, as an ac­tual re­source prob­lem. A change to the terms of ser­vice could have re­quired au­thors to tick a check­box de­clar­ing that a repos­i­tory con­tains LLM-generated code, or is cryp­tocur­rency-re­lated, and those repos­i­to­ries could then be seg­mented onto a sep­a­rate tier of in­fra­struc­ture that does­n’t get the same re­sources as every­one else. A tier that car­ries spe­cific quo­tas, and that might re­quire the au­thor to pay for what they con­sume. Declaring the truth hon­estly would (at least at first) cost noth­ing, and fail­ing to de­clare it, then get­ting caught, could be met with ex­actly the per­ma­nent, im­me­di­ate ban that Codeberg is now ap­ply­ing to en­tire cat­e­gories from the out­set.

Similarly, pro­jects that carry the LLM or Crypto la­bel could carry au­to­mat­i­cally dis­played dis­claimers that ex­plic­itly state that Codeberg is in no way re­spon­si­ble for the qual­ity or cor­rect­ness of this spe­cific repos­i­tory. Heck, they might even go as far as to bla­tantly state that Codeberg does not ap­prove of the use of LLMs or Cryptocurrencies in those warn­ings, to make ex­tra-ex­tra-ex­tra sure that peo­ple get it and that there is no “reputational risk” for Codeberg.

An ap­proach like this puts the cost of re­source-hun­gry pro­jects onto the peo­ple cre­at­ing them, and it keeps the shared re­sources for the pro­jects that were the rea­son the plat­form ex­ists. All of that with­out Codeberg hav­ing to de­cide which cat­e­gories of soft­ware are ide­o­log­i­cally ac­cept­able in the first place. The “we ban every­thing up­front that we don’t agree with” ap­proach is the wrong sig­nal to send, and it is a very slip­pery slope.

Despite not own­ing a sin­gle pro­ject that falls into ei­ther banned cat­e­gory, I’m now go­ing to look into set­ting up my own pub­lic Git host, and I’ll move off Codeberg only a few months af­ter mov­ing there, be­cause of this. Not be­cause of the bans them­selves, but be­cause I don’t want to de­pend on a plat­form that rewrites its terms of ser­vice on a whim, with­out prop­erly an­nounc­ing that the change was even un­der con­sid­er­a­tion, and with­out giv­ing its users a way to weigh in.

The de­ci­sions did go through Codeberg’s own Assembly 2026, which is more process than most plat­forms bother with, and yet as an or­di­nary user I found out about it the way prob­a­bly most peo­ple else did, through a dark blue ban­ner at the top of the site on the day it was al­ready set­tled. While I ap­pre­ci­ate the info about the ToS change, I wish I’d got­ten a ban­ner back when the plat­form was still de­cid­ing whether to go down this road, and I wish it had linked to a dis­cus­sion thread, or at the very least a poll, so that I could have voiced the con­cern I have, which is about the free­dom of the plat­form as a whole, rather than about any sin­gle cat­e­gory that ended up banned.

If you work in or around the film in­dus­try, there is a de­cent chance you have used the work of The Numbers this month, whether you re­alise it or not.

Its hand-re­searched data is the high­est qual­ity, track­ing box of­fice grosses, bud­gets, home video and stream­ing across more than 78,000 films and 236,000 peo­ple. It gets north of eight mil­lion vis­i­tors a year, and is treated as THE de­fin­i­tive au­thor­ity by jour­nal­ists, aca­d­e­mics, film­mak­ers, pre­dic­tion mar­kets, and even Guinness World Records.

And it was this GOAT sta­tus which caused the cat­a­strophic events of March this year.

On the 5th March 2026, TheNumbers.com web­site van­ished.

The site was down for over a week, with­out ex­pla­na­tion. A week later, it resur­faced at a frac­tion of its for­mer size. Gone were the his­tor­i­cal charts, the in­di­vid­ual movie pages, and even the much-loved Report Builder.

With only a generic “we’re re­build­ing, please bear with us” mes­sage to go on, the in­ter­net re­sponded as it al­ways does - with con­fu­sion, anger, and con­spir­acy the­o­ries. One Reddit the­ory even sug­gested it was a de­lib­er­ate rug pull de­signed to crip­ple the free site to push peo­ple to­wards paid prod­ucts.

Three months on, I spoke at length with Bruce Nash, founder and CEO of The Numbers, about what hap­pened. He de­scribes quite an un­pleas­ant and event­ful ex­pe­ri­ence:

We got a lot of an­gry emails from peo­ple who are like, ‘Where’s this page that you used to have and you don’t have any­more?’

We got a lot of an­gry emails from peo­ple who are like, ‘Where’s this page that you used to have and you don’t have any­more?’

Within his tale are a num­ber of things that should worry any­one who runs, re­lies on, or sim­ply ap­pre­ci­ates the in­ter­net.

On Friday 17 October 1997, math­e­mati­cian and for­mer IBM soft­ware de­vel­oper Bruce Nash launched a Geocities site that tracked 300 films.

Bruce de­scribed the launch in a 20th an­niver­sary es­say (which now sur­vives only in the Internet Archive, for rea­sons that will be­come clear):

I hit a but­ton in an Access data­base, up­loaded some HTML pages to Geocities, and made a brief an­nounce­ment on the Hollywood Stock Exchange mes­sage boards to let peo­ple know that I was start­ing to an­a­lyze box of­fice for films to help them pick MovieStocks to trade on HSX.

I hit a but­ton in an Access data­base, up­loaded some HTML pages to Geocities, and made a brief an­nounce­ment on the Hollywood Stock Exchange mes­sage boards to let peo­ple know that I was start­ing to an­a­lyze box of­fice for films to help them pick MovieStocks to trade on HSX.

From those hum­ble be­gin­nings, Bruce and the team he built around the site turned The Numbers into the film in­dus­try’s most re­li­able fi­nan­cial source.

At the start of 2026, the data­base tracked 78,396 movies, 178,375 the­atri­cal re­lease records, and 236,176 peo­ple.

During its life­time, the chal­lenges The Numbers has faced have changed im­mensely. For its first quar­ter cen­tury or so, the traf­fic was man­age­able and mostly po­lite. As Bruce puts it:

Pre-AI, we got hu­man traf­fic, mostly well-be­haved search en­gine crawlers, and a few peo­ple crawl­ing the site for per­sonal pro­jects. If some­one got too greedy, we could spot them and block them.

Pre-AI, we got hu­man traf­fic, mostly well-be­haved search en­gine crawlers, and a few peo­ple crawl­ing the site for per­sonal pro­jects. If some­one got too greedy, we could spot them and block them.

Over the past cou­ple of years, web­site own­ers the world over have seen their web traf­fic change. What was ini­tially only peo­ple brows­ing gave way to an ever-in­creas­ing num­ber of bots. By 2024, au­to­mated traf­fic had sur­passed hu­man traf­fic, and just last month, Cloudflare an­nounced that bots had reached 57.5% of web page re­quests.

The Numbers felt this shift in two dis­tinct waves. The first started around 2024:

We saw a big in­crease in crawls as AI train­ing joined the search en­gine crawlers. The AI crawlers are gen­er­ally less well-be­haved than the search en­gines, which in­creased the man­age­ment tasks for us to keep the site run­ning smoothly.

We saw a big in­crease in crawls as AI train­ing joined the search en­gine crawlers. The AI crawlers are gen­er­ally less well-be­haved than the search en­gines, which in­creased the man­age­ment tasks for us to keep the site run­ning smoothly.

And the sec­ond wave was stronger and more dam­ag­ing:

Around December 2025, we saw an­other big spike in traf­fic which I at­tribute to agen­tic AI: a com­bi­na­tion of AI agents that scrape sites in re­sponse to prompts, and peo­ple be­ing able to write agents that scrape sites.

Around December 2025, we saw an­other big spike in traf­fic which I at­tribute to agen­tic AI: a com­bi­na­tion of AI agents that scrape sites in re­sponse to prompts, and peo­ple be­ing able to write agents that scrape sites.

Like every data-rich site, by early 2026 The Numbers was be­ing ham­mered hard by AI bots scrap­ing its pages over and over at an in­dus­trial scale. Bruce says that only 10% of their traf­fic is from hu­mans brows­ing the site, with the rest com­ing from AI bots and au­to­mated traf­fic.

This put enor­mous strain on the site, but Bruce and his team were able to take mea­sures to mit­i­gate the worst of it. One of the clever­est was talk­ing to the ro­bots in their own lan­guage:

There’s stuff on the site which is de­signed for an LLM to read, so that it can tell some­body ‘here’s how you li­cence the data’ rather than ‘here’s how you scrape the web­site’. It’s had a huge ef­fect. We’re now get­ting prob­a­bly ten times the vol­ume of li­cens­ing en­quiries.

There’s stuff on the site which is de­signed for an LLM to read, so that it can tell some­body ‘here’s how you li­cence the data’ rather than ‘here’s how you scrape the web­site’. It’s had a huge ef­fect. We’re now get­ting prob­a­bly ten times the vol­ume of li­cens­ing en­quiries.

But mit­i­ga­tion is not the same as es­cape. From December through early March, the team strug­gled to keep the site alive un­der the load. Bruce es­ti­mates that:

Around 90% of our time was spent keep­ing the ex­ist­ing site run­ning while we spent our spare mo­ments work­ing on a new and im­proved sys­tem.

Around 90% of our time was spent keep­ing the ex­ist­ing site run­ning while we spent our spare mo­ments work­ing on a new and im­proved sys­tem.

The prob­lem was com­pounded by the site’s age: thirty years old, with ap­prox­i­mately 160,000 source files serv­ing around 2 mil­lion pages.

Then, in the early hours of Thursday 5 March, the servers col­lapsed.

The team scram­bled to un­der­stand what had hap­pened, ini­tially as­sum­ing it was the sheer weight of AI traf­fic. It seems AI was to blame… but pos­si­bly not only in the way they first thought.

Buried in the flood of agen­tic traf­fic, the site’s logs showed some­thing more pointed than scrap­ing. As Bruce de­scribes it:

Some of these used the site us­ing le­git­i­mate URLs, oth­ers were look­ing for back doors, most likely so they could get to the data be­fore it ap­peared on the site, or to ma­nip­u­late the data pre­sented to users.

Some of these used the site us­ing le­git­i­mate URLs, oth­ers were look­ing for back doors, most likely so they could get to the data be­fore it ap­peared on the site, or to ma­nip­u­late the data pre­sented to users.

On the ad­vice of a friend who works in cy­ber­se­cu­rity, the old server stayed off. For good. Restoring the back­ups and nurs­ing the thirty-year-old site back on­line would have meant de­fend­ing 160,000 legacy files against at­tack­ers who had spent months prob­ing them.

The team rushed up a skele­ton ver­sion of the web­site on new in­fra­struc­ture, which could at least keep de­liv­er­ing the lat­est box of­fice fig­ures while they took stock of what had hap­pened and what to do next. It went live on Friday 13 March.

At first glance, The Numbers may not seem like an ob­vi­ous tar­get. It does­n’t col­lect credit card in­for­ma­tion, and there is no juicy cus­tomer data to flip on the dark web. It is a small, in­de­pen­dent com­pany that pub­lishes how much money movies make.

How could some­one ex­pect to make money purely from hav­ing pri­vate ac­cess to their site?

In case you haven’t guessed it yet, it’s linked to pre­dic­tion mar­kets.

Polymarket runs weekly mar­kets on open­ing week­ends, and names The Numbers as the ul­ti­mate source of truth:

The ‘Daily Box Office Performance’ fig­ures found on the ‘Box Office’ tab on this movie’s The Numbers page will be used to re­solve this mar­ket once the val­ues for the 3-day open­ing week­end are fi­nal.

The ‘Daily Box Office Performance’ fig­ures found on the ‘Box Office’ tab on this movie’s The Numbers page will be used to re­solve this mar­ket once the val­ues for the 3-day open­ing week­end are fi­nal.

The sums on any sin­gle week­end mar­ket are mod­est by fi­nan­cial-mar­ket stan­dards, typ­i­cally in the tens to hun­dreds of thou­sands of dol­lars, with a cou­ple of mil­lion dol­lars across live box of­fice mar­kets at any given time.

If you could see The Numbers data be­fore every­one else, every sin­gle week, you would have a sig­nif­i­cant edge over all the other traders - learn­ing the an­swers slightly ahead of pub­li­ca­tion would al­low you to front-run the trades.

In a sit­u­a­tion like this, it is hard to know for cer­tain what hap­pened. We know that the logs showed months of au­to­mated prob­ing and scrap­ing of the site, but what fi­nally brought the site down, and who did it, re­mains an open ques­tion.

But the the­ory that some­one used AI to de­velop an ad­van­tage in a pre­dic­tion mar­ket is en­tirely plau­si­ble. The Numbers ex­pe­ri­ence shows us that:

We now live in a world where a movie sta­tis­tics web­site is worth hack­ing be­cause pre­dic­tion mar­kets em­power any­one to turn al­most any data into money.

We now live in a world where a movie sta­tis­tics web­site is worth hack­ing be­cause pre­dic­tion mar­kets em­power any­one to turn al­most any data into money.

Hacking web­sites is now some­thing any­one can do with a cheap AI sub­scrip­tion.

Hacking web­sites is now some­thing any­one can do with a cheap AI sub­scrip­tion.

The web, as we have it, is in­cred­i­bly frag­ile in the face of large-scale swarms of agen­tic AI bots.

The web, as we have it, is in­cred­i­bly frag­ile in the face of large-scale swarms of agen­tic AI bots.

In November 2025, Anthropic (the AI lab be­hind Claude) pub­lished a re­port on what it called the first doc­u­mented AI-orchestrated cy­ber es­pi­onage cam­paign. A state-spon­sored group had used its cod­ing tool to at­tack roughly 30 or­gan­i­sa­tions, with the AI per­form­ing 80% to 90% of the work and hu­mans step­ping in at only 4 to 6 de­ci­sion points per cam­paign.

Anthropic’s own con­clu­sion was:

The bar­ri­ers to per­form­ing so­phis­ti­cated cy­ber­at­tacks have dropped sub­stan­tially, and we pre­dict that they’ll con­tinue to do so.

The bar­ri­ers to per­form­ing so­phis­ti­cated cy­ber­at­tacks have dropped sub­stan­tially, and we pre­dict that they’ll con­tinue to do so.

In an ear­lier threat re­port, Anthropic were even clearer:

Criminals with few tech­ni­cal skills are us­ing AI to con­duct com­plex op­er­a­tions, such as de­vel­op­ing ran­somware, that would pre­vi­ously have re­quired years of train­ing.

Criminals with few tech­ni­cal skills are us­ing AI to con­duct com­plex op­er­a­tions, such as de­vel­op­ing ran­somware, that would pre­vi­ously have re­quired years of train­ing.

Meanwhile, an au­tonomous AI pen­e­tra­tion tester called XBOW reached num­ber one on HackerOne’s US leader­board, the rank­ing of the peo­ple (formerly all peo­ple) who find se­cu­rity holes in real com­pa­nies for boun­ties, sub­mit­ting nearly 1,060 vul­ner­a­bil­i­ties along the way.

Getting ac­cess to a thirty-year-old web­site with 160,000 legacy files is ex­actly the kind of known-flaw sur­face that AI tools have made cheap to probe. The ex­per­tise bar­rier that once pro­tected small sites from all but the most de­ter­mined at­tack­ers has largely evap­o­rated.

Bruce and his team were rel­a­tively lucky. Despite hav­ing their en­tire site knocked out overnight, they were able to keep go­ing. The Numbers has al­ways been free to use, and the site has­n’t re­lied heav­ily on ad­ver­tis­ing for the past few years, so the out­age did­n’t de­stroy an in­come stream they de­pended on.

Their core busi­ness is tied to sell­ing bulk data through the OpusData ser­vice, pro­duc­ing comp analy­sis re­ports for film­mak­ers and in­vestors, and pub­lish­ing the Business Report - all of which were un­af­fected by the pub­lic site go­ing down.

But they do need to build an en­tirely new web­site, from scratch, to host those 78,396 movies, 178,375 re­lease records and 236,176 peo­ple. Restoring the site from a backup was­n’t an op­tion, as Bruce points out:

It was re­ally clear that we could­n’t just put that server up again, be­cause it would in­evitably be brought down again, pos­si­bly within min­utes.

It was re­ally clear that we could­n’t just put that server up again, be­cause it would in­evitably be brought down again, pos­si­bly within min­utes.

That is why the site came back bare-bones in mid-March, and why fea­tures are re­turn­ing grad­u­ally rather than all at once.

Right now, the team is hav­ing to re­con­sider what a pub­lic web­site even means in 2026. Bruce’s analy­sis is that The Numbers used to serve two au­di­ences (human be­ings and search en­gines) and now serves roughly six: hu­mans, search en­gines, LLM train­ing runs, prompt-based AI traf­fic, agen­tic AI, and pre­dic­tion mar­ket pun­ters. Each has dif­fer­ent needs and a dif­fer­ent traf­fic pro­file. As he puts it:

We’ve gone from a world where run­ning a web site meant fo­cus­ing on three things (content, ads, and SEO) to about eight to ten dif­fer­ent fac­tors that go into every de­sign de­ci­sion.

We’ve gone from a world where run­ning a web site meant fo­cus­ing on three things (content, ads, and SEO) to about eight to ten dif­fer­ent fac­tors that go into every de­sign de­ci­sion.

The goal, he says, is to sup­port all six au­di­ences, with new OpusData ser­vices and on­line fea­tures for Business Report sub­scribers, and, im­por­tantly, to help reg­u­lar hu­man users of the site re­gain the data it has al­ways pro­vided, some of it in new and im­proved form.

Pretty bad, tbh. Enough that site own­ers such as Bruce have to ques­tion the value of some­thing that will take so much time and money to build and de­fend.

Cloudflare, which pro­tects a huge share of the world’s web­sites, pub­lishes data on how many pages each AI plat­form crawls for every one vis­i­tor it sends back to the web­sites it crawled.

Google crawls about five pages for every vis­i­tor it sends you. OpenAI crawls over 1,000. Anthropic crawls over 38,000 pages for every sin­gle vis­i­tor it refers.

Note that the scale is log­a­rith­mic, i.e. each step along the bot­tom is ten times big­ger than the last, be­cause oth­er­wise the dif­fer­ences are quite lit­er­ally too large for me to in­clude on one chart.

For the his­tory of the in­ter­net to date, the prin­ci­ple of the open web was that, in re­turn for let­ting the search en­gine ro­bots read your site, they would send you read­ers. But now, that trade no longer ap­plies. The num­ber of ro­bots has ex­ploded, and they no longer send any­one back.

When this fire­hose is aimed at a small site, it can in­flate the band­width bill and pos­si­bly even take down an en­tire site. Sites which can re­late to Bruce’s ex­pe­ri­ence in­clude:

Read the Docs, a non-profit that hosts doc­u­men­ta­tion for open-source soft­ware, who watched a sin­gle crawler down­load 73 ter­abytes of zipped HTML in one month, cost­ing it over $5,000 in band­width.

Read the Docs, a non-profit that hosts doc­u­men­ta­tion for open-source soft­ware, who watched a sin­gle crawler down­load 73 ter­abytes of zipped HTML in one month, cost­ing it over $5,000 in band­width.

iFixit, the re­pair-guide data­base, logged a mil­lion hits from Anthropic’s crawler in a sin­gle day.

iFixit, the re­pair-guide data­base, logged a mil­lion hits from Anthropic’s crawler in a sin­gle day.

Triplegangers, a seven-per­son com­pany sell­ing 3D scans, was knocked of­fline dur­ing busi­ness hours by OpenAI’s bot, in what its CEO de­scribed as “basically a DDoS at­tack”. The founder of code-host­ing ser­vice SourceHut re­ported spend­ing “anywhere from 20 – 100% of my time in any given week” fight­ing AI crawlers, with “dozens of brief out­ages per week”.

Triplegangers, a seven-per­son com­pany sell­ing 3D scans, was knocked of­fline dur­ing busi­ness hours by OpenAI’s bot, in what its CEO de­scribed as “basically a DDoS at­tack”. The founder of code-host­ing ser­vice SourceHut re­ported spend­ing “anywhere from 20 – 100% of my time in any given week” fight­ing AI crawlers, with “dozens of brief out­ages per week”.

The ed­i­tor of Linux news site LWN de­scribed crawler traf­fic from “literally mil­lions of IP ad­dresses” and con­cluded: “it is a dis­trib­uted de­nial-of-ser­vice at­tack”.

The ed­i­tor of Linux news site LWN de­scribed crawler traf­fic from “literally mil­lions of IP ad­dresses” and con­cluded: “it is a dis­trib­uted de­nial-of-ser­vice at­tack”.

When the GNOME open-source pro­ject mea­sured its traf­fic, roughly 97% turned out to be bots.

When the GNOME open-source pro­ject mea­sured its traf­fic, roughly 97% turned out to be bots.

A uni­ver­sity li­brary banned 16,000 IP ad­dresses in 48 hours to keep its cat­a­logue on­line.

A uni­ver­sity li­brary banned 16,000 IP ad­dresses in 48 hours to keep its cat­a­logue on­line.

The Wikimedia Foundation, which runs Wikipedia, re­ported in April 2025 that bots ac­count for about 35% of its pageviews but at least 65% of its most ex­pen­sive traf­fic, be­cause crawlers bulk-read ob­scure pages that hu­man read­ers rarely touch.

Six months later came the other half of the squeeze, when Wikipedia’s hu­man pageviews fell roughly 8% year on year, as peo­ple in­creas­ingly get Wikipedia’s knowl­edge from AI sum­maries with­out ever vis­it­ing Wikipedia. The ma­chines are tak­ing both the con­tent and the read­ers at an in­dus­trial scale, too.

AI tools are some of the most pow­er­ful and de­struc­tive things hu­mans have ever cre­ated. And they are be­ing ef­fec­tively tested by the pub­lic in real time in the real world. When the Manhattan Project was try­ing to work out the power of their atomic tech, they did not do so by send­ing every­one the specs each morn­ing and see­ing which houses blew up.

The world we have built thus far is so in­cred­i­bly ill-pre­pared for the power and scale of the AI mod­els we all have ac­cess to.

I don’t wish for this to sound like a one-sided anti-AI fear cam­paign. There is a lot to like about AI and what it can do for the hu­man race. But we do need to con­sider the world we’re cur­rently step­ping into.

What breaks first are the things built for the old in­ter­net. The open web was built on as­sump­tions such as that vis­i­tors are mostly hu­man, that traf­fic roughly tracks read­er­ship, and that the cost of serv­ing your site is re­lated to the value you get from serv­ing it. Every one of those as­sump­tions is now out of date.

Why Software Factories Fail

or: har­ness en­gi­neer­ing is not enough

Note

I run a com­pany (HumanLayer) build­ing tools in the hu­man/​agent col­lab­o­ra­tion space, so what I’m gonna say be­low may be a tad bi­ased. Perhaps in spite of that, I hope you find the sub­ject help­ful or at the very least that you find it as in­ter­est­ing as I do. -Dex

i guess we doin loops now

We’re all rac­ing to put AI cod­ing into pro­duc­tion. A lot has been said about loop en­gi­neer­ing, and the pre­vail­ing wis­dom is that we should prob­a­bly write more loops.1

StrongDM wrote about their lights-off soft­ware fac­tory where no hu­man reads code and no hu­man writes code.

The nar­ra­tive goes some­thing like this:

You are the bot­tle­neck.

The mod­els are good enough.

Code is free.

Just ship more stuff.

Ryan Lopopolo of OpenAI wrote about this in February and gave a talk in April about OpenAI’s soft­ware fac­tory, Symphony.

These peo­ple are all re­ally dang smart and I have a ton of re­spect for them. But the most cyn­i­cal take here would be to call this yet an­other ex­cuse to pump more VC money into the slop can­non.

it’s uh…it’s go­ing

Our friend Mario got up at AI Engineer Europe and begged us to slow down — be­cause com­pa­nies that have no busi­ness hav­ing out­ages due to cod­ing-agent mishaps, are, well… hav­ing out­ages due to cod­ing-agent mishaps.

As Matt Pocock put it, code­bases are falling apart faster than they ever have be­fore.

I haven’t been able to dig up any de­fin­i­tive data/​find­ings from StrongDM on how that whole dark fac­tory went. The weather-re­port has a few sparse up­dates be­tween February and June of this year. edit - there is some con­ver­sa­tion with the team on hacker news on July 23 - sounds like we might get a more for­mal up­date soon!

The folks at Faros AI put out a re­port: since we2 all picked up these AI cod­ing tools back in January and February, pull-re­quest re­view qual­ity is way down.

More com­ments, longer com­ments, and tons of PRs get­ting merged with no re­view at all.

Incidents are way up.

Bugs per de­vel­oper are way up.

This re­port is more of a cor­re­la­tion sig­nal than a ver­i­fi­able smok­ing gun3, and the whole point of this post is to be wary of slop data, but it feels di­rec­tion­ally valid based on what I’ve seen.

“You’re hold­ing it wrong” (you’re not)

A lot of peo­ple will tell you that this is a skill is­sue — that if you’re not get­ting good re­sults, that’s your fault.

But how­ever you’re choos­ing to…erhm…hold it, I guar­an­tee you’re be­ing told that if to­ken-maxxing is­n’t work­ing for you, it’s a skill is­sue. You just need to spend more to­kens. Let go of read­ing the code. And if you’re just get­ting there, I promise it’s part of the pro­gres­sion. I thought this way last sum­mer too.

Unfortunately for my ego, some dumb stuff I de­cided to say about “how to hold it bet­ter” got recorded and now has about a mil­lion cu­mu­la­tive views on YouTube. I am not try­ing to brag here, I share this only to es­tab­lish that I’ve been go­ing deep on the best ways to use cod­ing agents for a long time now, and have dis­cov­ered some things that many oth­ers have found gen­uinely use­ful.

Anyhow, The promise of all this on­line “just to­ken harder” yap­ping we’ve been forced to en­dure is, suc­cinctly: with enough har­ness en­gi­neer­ing, we can get the best of both worlds:

10 to 100x faster,

high qual­ity, and

no­body ever has to do that thing we all hate called code re­view

All we have to do is con­fig­ure more lin­ters and sprin­kle some magic words like “adversarial re­view” onto enough PR re­view bots, and our soft­ware will hap­pily build it­self with­out in­ci­dent.

This is not a skill is­sue

What I’m gonna try to con­vince you is that no amount of har­ness en­gi­neer­ing or loops­maxxing can solve what is fun­da­men­tally a model-train­ing is­sue.

To grap­ple with this, I had to dig into how cod­ing mod­els are ac­tu­ally trained and eval­u­ated - with re­spect to both the RLVR and the bench­mark side of things.

In this post I’m gonna run through:

Software fac­to­ries date back to 1968, how have they evolved, and how has AI changed them

Why mod­els can gen­er­ate moun­tains of slop de­spite ace-ing bench­marks (even the brand new “frontier” bench­marks)

In spite of this, you can move pretty fast with­out set­ting your code­base on fire

I’m gonna try to cut through the hype of every daily-emerg­ing skills plu­gin and the ai-psy­chosis-to­ken­maxxing ad­vice pan­demic, and talk in gen­eral terms about the types of things that work with­out ref­er­enc­ing any par­tic­u­lar skill or frame­work.

Video Version: this post is based on (and ex­pands upon) my keynote at AI Engineer World’s Fair 2026.

Thanks to @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins, and @jeffreyhuber for feed­back on this post.

An aside: this has noth­ing to do with vibe cod­ing

Addy Osmani de­tan­gled this thing that is worth high­light­ing:

A de­vel­oper vibe-cod­ing a side pro­ject a dozen peo­ple will ever run, and a team keep­ing a ten-year-old en­ter­prise sys­tem alive for an­other quar­ter, share al­most no con­straints worth nam­ing, and most of the ad­vice in cir­cu­la­tion is re­ally one of those two peo­ple telling the other how to live.

A de­vel­oper vibe-cod­ing a side pro­ject a dozen peo­ple will ever run, and a team keep­ing a ten-year-old en­ter­prise sys­tem alive for an­other quar­ter, share al­most no con­straints worth nam­ing, and most of the ad­vice in cir­cu­la­tion is re­ally one of those two peo­ple telling the other how to live.

If you love vibe cod­ing, please, go on vib­ing. I still vibe code lots of things, I just also main­tain lots of pro­duc­tion soft­ware (and through HumanLayer, help 1000s of other en­gi­neers do the same), so the rest of this is aimed at folks solv­ing hard prob­lems in com­plex code­bases.

I hear the word brown­field a lot to talk about this split. Historically that meant some ten-year-old Java thing, but at the pace we can ship now, it feels like an agent-built code­base starts to strug­gle af­ter maybe three to six months — you start to slow down, and the way you ap­proach adding new things has to change.

A brief his­tory of the soft­ware fac­tory

I’ve been build­ing and study­ing soft­ware fac­to­ries my whole ca­reer, but I only learned this re­cently: the term traces all the way back to a NATO con­fer­ence in 1968 — the same one that gave us “software en­gi­neer­ing.”

The only other bit I find su­per in­ter­est­ing since then is that the US Department of Defense wrote a 31-page pdf about how the DoD needs to start us­ing jenk­ins bet­ter or some­thing.

The 2022 soft­ware fac­tory

Let’s ground our “software fac­tory” de­f­i­n­i­tion around 2022, right be­fore AI. In a typ­i­cal soft­ware fac­tory:

People de­cide what to build — en­gi­neers, PMs, lead­er­ship dri­ving the vi­sion

It goes in a tracker — Linear, Jira, what­ever: a state ma­chine of what needs to hap­pen

Someone grabs a ticket and builds it — prob­a­bly does some man­ual/​au­to­mated test­ing while they’re at it

Pull re­quest — au­to­mated checks, a hu­man re­views the code, maybe some­one pulls it down to test

Anything wrong? Loop back to “someone builds the thing”

Ship to prod — and it makes con­tact with users

Add mon­i­tor­ing — there’s an en­tire in­dus­try built around pag­ing an en­gi­neer at 3am when some­thing breaks

Users com­plain — ask for things, find bugs, file fea­ture re­quests → back to the team to add to the tracker

And on and on. We haven’t even hit AI yet, and there are al­ready sev­eral loops in this pic­ture.

front-load­ing align­ment

The thing teams fig­ured out decades ago: build­ing takes hours or days, and so does re­view.

So we front-load the work — plan­ning, ar­chi­tec­ture pro­pos­als, sprint plan­ning — to­gether, as a team. That means:

less re­work, be­cause we aligned be­fore any­one wrote code

less time re­view­ing every line, if you’ve ever read a long-but-well-done PR, you know how fast the re­view goes when it’s close-to-per­fect

We’ll come back to this later - let’s look at what hap­pens when you bring agen­tic cod­ing into the pic­ture.

The agen­tic soft­ware fac­tory

Now every com­pany and their mother –

Ramp

Stripe

WorkOS

Brex

has spent the bet­ter part of this year ex­plain­ing how they built an agent fac­tory that ships on the or­der of 75% of their code.

The agen­tic fac­tory looks mostly like swap­ping “someone builds the thing” → “an agent builds the thing” — there’s some stuff here like or­ches­tra­tion, a har­ness, a sand­box, a model, com­puter use, etc. I won’t go in depth on those de­tails be­cause quite frankly I’m sick of read­ing about it and I’m sure you are too.

When the agent builds the thing:

Building drops from hours or days to min­utes or hours.

Review still takes hours or days. A hu­man still has to read the code and test the change. So re­view is now the bot­tle­neck.

So you speed re­view up too:

Agentic code re­view, to catch style, bugs, se­cu­rity.

Agentic re­gres­sion test­ing, to poke it from the out­side with browsers and com­puter use and maybe send you a cute lit­tle video when it’s done

Review is faster now, but it’s also prob­a­bly still the bot­tle­neck. But we can do more loops.

Next you might route in­ci­dents into the fac­tory. Instead of pag­ing some­one at 3am, they wake up to a PR that maybe al­ready fixes it.

We can also route user feed­back into the fac­tory. People ask for stuff, it gets built.

At which point the job is two ques­tions: how much can you stuff into the queue, and how fast can you re­view and test what comes out?

Which brings us to the lights-off soft­ware fac­tory.

The lights-off soft­ware fac­tory

Dan Shapiro coined this term and Simon Willison wrote about StrongDM’s im­ple­men­ta­tion of it — where we no longer read the code.

You look at your beau­ti­ful soft­ware fac­tory. It’s ru­ined by that an­noy­ing lit­tle code re­view step and you say: you know what, that thing where a hu­man reads every change? No thanks.

So you drop it, and you put the ef­fort some­where else:

Invest in test­ing and let­ting the agent test its own work

Invest in sand­boxes and or­ches­tra­tion

Invest in au­to­mated re­view

Invest in mon­i­tor­ing

Invest in roll­out

Invest in col­lect­ing feed­back sig­nals from users

And now the job re­ally is just one ques­tion: how much stuff can we ask the agent to build? How much of the ocean do we want to boil?

This is go­ing to go great (its not)

I’m go­ing to posit some­thing po­ten­tially con­tro­ver­sial: the lights off fac­tory does not work.