Apple has filed a law­suit against OpenAI to­day, ac­cus­ing the com­pany of trade se­cret theft. Specifically, Apple al­leges that its for­mer em­ploy­ees have stolen trade se­crets “for the ben­e­fit of OpenAI.”

“This case is about Apple’s for­mer em­ploy­ees steal­ing Apple’s trade se­crets for the ben­e­fit of OpenAI. Apple brings this suit to put a stop to it,” the law­suit says.

Apple state­ment

In a state­ment to 9to5Mac, an Apple spokesper­son said:

“At Apple, our teams are con­stantly de­vel­op­ing break­through tech­nolo­gies to cre­ate the best prod­ucts and ser­vices in the world, and pro­tect­ing their work and in­tel­lec­tual prop­erty is some­thing we take very se­ri­ously. Recently, sig­nif­i­cant ev­i­dence has emerged sug­gest­ing in­di­vid­u­als em­ployed by OpenAI wrong­fully took Apple’s se­cret and con­fi­den­tial in­for­ma­tion re­gard­ing our un­re­leased tech­nolo­gies, processes, and prod­ucts. We will al­ways de­fend our teams’ hard work and in­no­va­tions, and we are tak­ing all ap­pro­pri­ate steps to do so.”

“At Apple, our teams are con­stantly de­vel­op­ing break­through tech­nolo­gies to cre­ate the best prod­ucts and ser­vices in the world, and pro­tect­ing their work and in­tel­lec­tual prop­erty is some­thing we take very se­ri­ously. Recently, sig­nif­i­cant ev­i­dence has emerged sug­gest­ing in­di­vid­u­als em­ployed by OpenAI wrong­fully took Apple’s se­cret and con­fi­den­tial in­for­ma­tion re­gard­ing our un­re­leased tech­nolo­gies, processes, and prod­ucts. We will al­ways de­fend our teams’ hard work and in­no­va­tions, and we are tak­ing all ap­pro­pri­ate steps to do so.”

Update: Read OpenAI’s re­sponse here.

Apple ac­cuses OpenAI of trade se­cret theft

The law­suit names Chang Liu and Tang Tan as two of the de­fen­dants. Tang Tan served as VP of prod­uct de­sign at Apple, lead­ing iPhone and Apple Watch prod­uct de­sign. He de­parted the com­pany in February 2024 to work with Jony Ive. Chang Liu, mean­while, worked at Apple for eight years and was a se­nior sys­tem elec­tri­cal en­gi­neer be­fore de­part­ing to join OpenAI in January 2026.

Apple’s law­suit also names OpenAI and io Products as de­fen­dants.

OpenAI’s hard­ware ef­forts are be­ing led by Jony Ive, Apple’s for­mer chief de­sign of­fi­cer. OpenAI ac­quired Ive’s startup io as part of a $6.5 bil­lion deal last year. OpenAI’s takeover of the com­pany in­cluded more than 50 en­gi­neers, de­vel­op­ers, and other em­ploy­ees. In its orig­i­nal an­nounce­ment, OpenAI touted that Ive founded io in col­lab­o­ra­tion with Scott Cannon, Evans Hankey, and Tan.

Hankey led Apple’s de­sign team for sev­eral years af­ter Ive de­parted the com­pany. She de­parted in 2022 be­fore re­unit­ing with Ive as part of io. Cannon also pre­vi­ously worked at Apple.

Ive, Hankey, and Cannon are not per­son­ally men­tioned any­where in Apple’s ini­tial fil­ing to­day.

The com­plaint

Apple says it first raised con­cerns with OpenAI di­rectly in February, ask­ing the com­pany to in­ves­ti­gate and ad­dress the is­sue. OpenAI, how­ever, never re­sponded. Apple says the con­duct de­tailed in the fil­ing is “the tip of the ice­berg.”

This is the tip of the ice­berg. Apple lacks vis­i­bil­ity into what’s been hap­pen­ing be­hind closed doors at OpenAI, where such mis­con­duct is nor­mal­ized and ex­em­pli­fied by lead­er­ship. This much is clear, how­ever: at every level, from mem­bers of its Technical Staff to its Chief Hardware Officer, and in co­or­di­na­tion with busi­ness part­ners, OpenAI has been steal­ing Apple’s trade se­crets and con­fi­den­tial in­for­ma­tion. As a nat­ural re­sult, OpenAI’s nascent hard­ware busi­ness now rests.

This is the tip of the ice­berg. Apple lacks vis­i­bil­ity into what’s been hap­pen­ing be­hind closed doors at OpenAI, where such mis­con­duct is nor­mal­ized and ex­em­pli­fied by lead­er­ship. This much is clear, how­ever: at every level, from mem­bers of its Technical Staff to its Chief Hardware Officer, and in co­or­di­na­tion with busi­ness part­ners, OpenAI has been steal­ing Apple’s trade se­crets and con­fi­den­tial in­for­ma­tion. As a nat­ural re­sult, OpenAI’s nascent hard­ware busi­ness now rests.

The com­plaint, filed in the U.S. District Court for the Northern District of California, al­leges that Tan used in­sider knowl­edge of Apple’s con­fi­den­tial pro­jects to grill job can­di­dates in in­ter­views and learn more con­fi­den­tial in­for­ma­tion. Additionally, Tan di­rected job can­di­dates still work­ing at Apple to bring ac­tual Apple hard­ware com­po­nents and sam­ples for “show and tell” ses­sions.

When in­ter­view­ing Apple em­ploy­ees for jobs at OpenAI, Mr. Tan uses Apple’s con­fi­den­tial in­for­ma­tion to gain ac­cess to even more in­sider knowl­edge. He has used an Apple in­ter­nal pro­ject co­de­name to ask, “What’s the plan[?]” for an unan­nounced Apple prod­uct.

He has di­rected job can­di­dates still work­ing for Apple to bring “Actual parts” from Apple to their in­ter­views for “show and tell” ses­sions in which he and his team at OpenAI can elicit still more Apple con­fi­den­tial in­for­ma­tion. These di­rec­tions to bring Apple’s parts to OpenAI job in­ter­views sur­prised at least one of the can­di­dates, who com­mented that he “didn’t even know we could take those from the of­fice.”

OpenAI has been in­struct­ing Apple em­ploy­ees to bring “CAD/design ar­ti­facts” and “prototypes” to their in­ter­views and to di­vulge de­tails about their work such as “subsystem and com­po­nent se­lec­tion,” the “tools or method­olo­gies you use for sys­tem in­te­gra­tion, such as CAD soft­ware, sim­u­la­tion tools,” and “Vendor se­lec­tion and com­mu­ni­ca­tion/​col­lab­o­ra­tion with ven­dors.”

When in­ter­view­ing Apple em­ploy­ees for jobs at OpenAI, Mr. Tan uses Apple’s con­fi­den­tial in­for­ma­tion to gain ac­cess to even more in­sider knowl­edge. He has used an Apple in­ter­nal pro­ject co­de­name to ask, “What’s the plan[?]” for an unan­nounced Apple prod­uct.

He has di­rected job can­di­dates still work­ing for Apple to bring “Actual parts” from Apple to their in­ter­views for “show and tell” ses­sions in which he and his team at OpenAI can elicit still more Apple con­fi­den­tial in­for­ma­tion. These di­rec­tions to bring Apple’s parts to OpenAI job in­ter­views sur­prised at least one of the can­di­dates, who com­mented that he “didn’t even know we could take those from the of­fice.”

OpenAI has been in­struct­ing Apple em­ploy­ees to bring “CAD/design ar­ti­facts” and “prototypes” to their in­ter­views and to di­vulge de­tails about their work such as “subsystem and com­po­nent se­lec­tion,” the “tools or method­olo­gies you use for sys­tem in­te­gra­tion, such as CAD soft­ware, sim­u­la­tion tools,” and “Vendor se­lec­tion and com­mu­ni­ca­tion/​col­lab­o­ra­tion with ven­dors.”

Furthermore, Apple says a can­di­date be­gan “screenshotting and down­load­ing files re­lat­ing to a highly con­fi­den­tial Apple pro­ject” hours be­fore in­ter­view­ing with Tan, who then “solicited more in­for­ma­tion about that same Apple pro­ject” once the in­ter­view started. This be­came an “established pat­tern,” Apple says.

Tan also al­legedly pos­sessed and dis­trib­uted an in­ter­nal Apple “Need to Know” doc­u­ment to new OpenAI hires be­fore they gave their no­tice to Apple. The doc­u­ment in­cluded Apple’s de­par­ture se­cu­rity pro­to­cols. As part of its in­ves­ti­ga­tion, Apple found a “pattern by em­ploy­ees who de­part for OpenAI of tak­ing steps to evade the se­cu­rity processes in­tended to pro­tect Apple’s con­fi­den­tial in­for­ma­tion.”

Meanwhile, Apple also claims for­mer en­gi­neer Liu ex­ploited a se­cu­rity bug to down­load con­fi­den­tial en­gi­neer­ing files af­ter leav­ing the com­pany. Rather than re­port the ex­ploit, Liu al­legedly joked about it in mes­sages (“LOL,” “so funny”). Liu also failed to re­turn an Apple-issued lap­top af­ter his de­par­ture.

Apple al­leges that Liu down­loaded a “compilation of tech­ni­cal files with over a thou­sand pages” with de­tails of work he did at Apple. This in­cluded de­tailed man­u­fac­tur­ing doc­u­ments cov­er­ing the com­plex cir­cuit boards used in Apple hard­ware prod­ucts.

Liu also al­legedly coached an­other Apple em­ployee at the time, whom he was re­cruit­ing to OpenAI, on which con­fi­den­tial ma­te­ri­als to study be­fore her own OpenAI in­ter­view.

Finally, Apple al­leges that OpenAI had a trusted Apple part­ner carry out Apple’s pro­pri­etary metal-fin­ish­ing tech­nique, mis­lead­ing the part­ner into be­liev­ing it had Apple’s per­mis­sion to do so. Apple also says OpenAI ap­proached a sec­ond long­time Apple sup­plier that works on power and bat­tery man­u­fac­tur­ing, us­ing in­sider ter­mi­nol­ogy to ask “targeted ques­tions” about spe­cific Apple com­po­nents.

The suit seeks in­junc­tive re­lief and dam­ages, and comes as OpenAI works to bring its first con­sumer hard­ware de­vice to mar­ket.

Apple’s law­suit also comes af­ter Bloomberg re­ported that OpenAI was prepar­ing “legal ac­tion” against Apple over how its part­ner­ship to in­te­grate ChatGPT into Siri played out. Today’s law­suit from Apple, how­ever, says that agree­ment is not at is­sue here.

Tan and Liu are just two of many Apple em­ploy­ees who have de­parted for OpenAI. Today’s fil­ing says that there are over 400 for­mer Apple em­ploy­ees now work­ing at OpenAI.

There have been var­i­ous ru­mors about OpenAI’s hard­ware ef­forts so far. In April, Ming-Chi Kuo re­ported that OpenAI is de­vel­op­ing its own smart­phone, which could launch in 2028. The Information has also re­ported on OpenAI’s work on a HomePod-style smart speaker.

You can read the full fil­ing be­low and find the PDF linked here.

Chance’s fa­vorites:

Bring wire­less CarPlay to any car

“Apple: The First 50 Years” by David Pogue

Logitech MX Master 4

Belkin 3-in-1 MagSafe Charger

Beats Woven USB-C Charging Cables

AirPods Pro 3: $222 (Reg. $249)

Follow Chance: Threads, Bluesky, Instagram, and Mastodon.

FTC: We use in­come earn­ing auto af­fil­i­ate links. More.

The QuadRF (pictured above) a phased-ar­ray ra­dio built around a Raspberry Pi 5 and an FPGA board with pi­cosec­ond-level tim­ing. It does ad­vanced sig­nal pro­cess­ing and beam­form­ing.

It can see WiFi through walls and track drones in flight.

If the open source com­mu­nity can come up with some­thing like this, just imag­ine what gov­ern­ments are ca­pa­ble of.

When you plug a com­puter into a net­work, tools like Wireshark can show all the hid­den traf­fic you might not even know is there. WiFi pack­ets are the same, but those travel through the air, al­low­ing snoop­ing with­out phys­i­cal ac­cess.

The QuadRF has built-in soft­ware that can stream and de­code RF, and you can pipe it out to a more pow­er­ful com­puter for things like WiFi traf­fic analy­sis.

I men­tion this not to scare you—gov­ern­ments have had tools like these for years. It’s just bet­ter to know what’s pos­si­ble and ex­pose bad se­cu­rity prac­tices than to ban use­ful tools like these. So if you’re in the CIA, don’t get any ideas.

To the Moon

After spot­ting QuadRF on Hackaday, I reached out to Martin McCormick, who’s been work­ing on QuadRF as part of a big­ger pro­ject: a Moon-scale an­tenna ar­ray, ca­pa­ble of EME (Earth-Moon-Earth) ra­dio ex­per­i­ments and ra­dio as­tron­omy.

I think Martin took in­spi­ra­tion from Dishy, SpaceX’s orig­i­nal Starlink ter­mi­nal. (Makes sense, since Martin worked at SpaceX on the team that built Dishy!)

Instead of lock­ing this phased ar­ray an­tenna sys­tem into a pro­pri­etary satel­lite sys­tem, li­censed op­er­a­tors will ide­ally be able to chain mul­ti­ple QuadRF mod­ules to­gether for in­ter­est­ing ra­dio ex­per­i­ments, with up to 1.15 MW EIRP—basically, a mas­sive amount of di­rec­tional an­tenna gain, for high power RF fun.

But QuadRF is scaled down to hand­held-size, and while it is­n’t pow­er­ful enough to send a sig­nal to the moon, it’s still quite use­ful in lo­cal SDR ap­pli­ca­tions and vi­su­al­iz­ing the RF en­vi­ron­ment—at least in its fre­quency range of 4.9 – 6 GHz.

Testing QuadRF

But I specif­i­cally asked Martin if he’d be will­ing to send over a pro­to­type QuadRF for my Dad (a re­tired broad­cast ra­dio en­gi­neer) and I to test.

I had al­ready placed a pre-or­der on Crowd Supply (where a ba­sic kit is $499), but I wanted to see if QuadRF was re­ally as use­ful or in­tu­itive as it seemed from the videos ScaleRF posted.

Spoilers: it’s still a lit­tle rough in the UI de­part­ment, but I was blown away by how well it works. Especially con­sid­er­ing every­thing’s run­ning on a Raspberry Pi 5.

When you turn it on, the Pi boots up and cre­ates a WiFi hotspot. You con­nect to that, and visit http://​quadrf/. That page runs a VNC ses­sion in your browser, where you can launch apps from GNU Radio to SDR soft­ware, and even their cus­tom AR (Augmented Reality) RF vi­su­al­izer.

The AR vi­su­al­izer is the most in­ter­est­ing in­cluded soft­ware, de­spite be­ing less use­ful for real-world SDR ap­pli­ca­tions.

The UI is a lit­tle rough, but you can ad­just the align­ment be­tween your cam­era and the phased ar­ray, and the gain of the re­ceiver.

Then it will vi­su­al­ize fre­quen­cies from 4.9 – 6 GHz as col­or­ful ‘blobs’. The scale is not shown on the dis­play in this early ver­sion, but from my test­ing around the stu­dio, my 5 GHz WiFi net­work (which was run­ning on Channel 100, or around 5.5 GHz) showed up light blue. Neighboring WiFi net­works were show­ing up red or green.

If you or­der the Mobile Expansion Pack, it in­cor­po­rates a bat­tery power pack, and a hand­held phone mount, so you can walk around an­a­lyz­ing part of the C-band in real-time.

My Dad and I flew his DJI Mini Pro 4 be­hind the stu­dio, and the QuadRF had no trou­ble pick­ing it out of the sky. As it flew away, I had to in­crease the gain to keep see­ing it; it would be nice to have AGC or an eas­ier gain con­trol as the UI was a lit­tle clunky when car­ry­ing around the con­trap­tion.

It sounds like the crowd­fund­ing cam­paign is al­ready be­yond ex­pec­ta­tions, and they’ll be switch­ing the en­clo­sure to an in­jec­tion mold (the ver­sion I have is 3D printed).

Raspberry Pi 5 MIPI for high-band­width RF

One as­pect that in­trigued me was the use of the Raspberry Pi’s MIPI lanes for low la­tency SDR stream­ing I/Q (In-phase/Quadrature) at data rates over 5 Gbps. From the QuadRF Documentation:

The novel ap­proach of stream­ing I/Q over the Pi’s cam­era and dis­play FFC MIPI con­nec­tors has many ben­e­fits. MIPI can han­dle >5 Gbps, low-la­tency, full-du­plex data trans­fer through the Pi’s RP1 chip. It is sim­pler and more re­li­able than USB, adds al­most zero hard­ware cost to the RF board, and can sus­tain hun­dreds of MSPS of I/Q with no hic­cups or sam­ple loss. Considering cam­eras and dis­plays are the ul­ti­mate form of high-band­width sig­nal stream­ing, it makes sense their stan­dard dig­i­tal in­ter­face is a great match for SDR! We think the in­dus­try should adopt it more widely!

The novel ap­proach of stream­ing I/Q over the Pi’s cam­era and dis­play FFC MIPI con­nec­tors has many ben­e­fits. MIPI can han­dle >5 Gbps, low-la­tency, full-du­plex data trans­fer through the Pi’s RP1 chip. It is sim­pler and more re­li­able than USB, adds al­most zero hard­ware cost to the RF board, and can sus­tain hun­dreds of MSPS of I/Q with no hic­cups or sam­ple loss. Considering cam­eras and dis­plays are the ul­ti­mate form of high-band­width sig­nal stream­ing, it makes sense their stan­dard dig­i­tal in­ter­face is a great match for SDR! We think the in­dus­try should adopt it more widely!

It sounds like they had to re­verse-en­gi­neer the MIPI pro­to­col used on the Pi 5 to do this (since it goes through the RP1 chip), and the way it’s ar­chi­tected, you can daisy-chain mul­ti­ple QuadRF mod­ules to­gether, let­ting each mod­ule cal­cu­late its own phase shift.

I’m not sure how that will work in prac­tice, but it sounds pretty neat. PCIe could prob­a­bly work in a pinch, too, but this im­ple­men­ta­tion frees up the PCIe con­nec­tor in case you want high speed stor­age or even higher speed net­work­ing than the Pi of­fers.

Conclusion

As with all pre-pro­duc­tion gear I test, take every­thing I’ve shown with a grain of salt. And with any crowd­fund­ing cam­paign, if you back it, don’t ex­pect the QuadRF to show up on your doorstep overnight.

I was ini­tially skep­ti­cal about how use­ful and fun this lit­tle hand­held phased ar­ray could be, but af­ter us­ing it for a week, I can’t wait un­til the one I pre-or­dered ships!

New York City has adopted a new rule that bans com­pa­nies from us­ing de­cep­tive sub­scrip­tions to trap cus­tomers into pay­ing for gym mem­ber­ships, stream­ing ser­vices and other re­cur­ring charges, the city’s con­sumer pro­tec­tion of­fice said.

The new rule, which will start on 1 October, promises hefty fines and ag­gres­sive en­force­ment for vi­o­la­tors. Companies that do not pro­vide a sim­ple way to can­cel could pay $525 per user sub­scrip­tion, back fees and ad­di­tional fines.

The city is also tar­get­ing so-called “junk fees” that raise the fi­nal price of every­thing from apart­ments to sport­ing events, with a pro­posed rule that re­quires sell­ers to “advertise the to­tal price for any good or ser­vice, in­clud­ing all manda­tory ad­di­tional charges and fees, up front”, ac­cord­ing to a re­lease shared with the Guardian.

New York would be the first US city to im­ple­ment such a ban.

“People should­n’t have to wait on hold for half an hour or send a cer­ti­fied let­ter or show up to a store in per­son in or­der to can­cel” a sub­scrip­tion, said Samuel AA Levine, the city’s com­mis­sioner of con­sumer and worker pro­tec­tion, in an in­ter­view.

The new mea­sures were an­nounced in a press con­fer­ence on Friday.

The pro­posed fee rule could have an es­pe­cially wide ef­fect, send­ing rip­ples through New York’s ex­pen­sive hous­ing mar­ket, where about 70% of res­i­dents rent.

Apartment renters in the US face a ris­ing tide of add-on fees such as “boiler man­age­ment” and “lifestyle” charges from man­age­ment com­pa­nies, which make true rental costs hun­dreds of dol­lars higher than the price stated on real-es­tate com­pany web­sites.

If the pro­posed renters rule passes af­ter pub­lic com­ment and hear­ing, any manda­tory fees, in­clud­ing an­nual ones, would need to be in­cluded in the stated monthly rental price, Levine said.

The cur­rent sit­u­a­tion cre­ates “a sce­nario where rather than com­pet­ing on price, com­pa­nies are com­pet­ing on their abil­ity to hide the true price. That’s the worst kind of in­cen­tive” — and one that deeply dis­torts the mar­ket, Levine said.

The moves are part of an ag­gres­sive push by Zohran Mamdani and Levine, a for­mer head of con­sumer pro­tec­tion in the Federal Trade Commission (FTC), to rein in what they see as preda­tory cor­po­rate mal­prac­tice na­tion­wide.

“In the dawn of the [Ronald] Reagan era, the FTC and oth­ers in Washington said ex­pressly that … mar­kets could cor­rect them­selves, reg­u­late them­selves, they were go­ing to stop writ­ing rules,” and al­low com­pa­nies to po­lice their own be­hav­ior, Levine said. “What it has got­ten us is 40 years of de­cep­tive pric­ing,” he said.

Bans on junk fees and sub­scrip­tion traps are gen­er­ally pop­u­lar with con­sumers, but have been fought ag­gres­sively by in­dus­try groups. When the Biden ad­min­is­tra­tion in­tro­duced a junk fee rule in 2024, the US Chamber of Commerce ar­gued it was “an at­tempt to mi­cro­man­age busi­ness­es’ pric­ing struc­tures”, and apart­ment fees were cut from that fed­eral rule af­ter lob­by­ing by the real-es­tate in­dus­try.

A na­tional click-to-can­cel rule in­tro­duced by the Biden ad­min­is­tra­tion was struck down by a fed­eral judge in 2025, days be­fore it was set to go into ef­fect, over a pro­ce­dural rule. Donald Trump’s FTC plans to pass a sim­i­lar rule in com­ing months.

Companies make bil­lions a year in au­to­matic sub­scrip­tion re­newals that con­sumers do not want or do not know they have. The sub­scrip­tion rule could save New Yorkers alone as much as $162.5m per year, the Roosevelt Institute think­tank es­ti­mates.

While the sub­scrip­tion rule would only ap­ply to New York City res­i­dents, the pro­posed junk fee rule af­fects com­pa­nies such as ho­tels and rental car agen­cies that cater to vis­i­tors. If you are stay­ing in a ho­tel in the city that hits you with undis­closed fees upon check-in, “you should com­plain to us”, Levine said.

The new rule is the Mamdani ad­min­is­tra­tion’s lat­est at­tempt to ad­dress the af­ford­abil­ity cri­sis af­ter heav­ily cam­paign­ing on mak­ing the city cheaper for res­i­dents. Members of Mamdani’s de­mo­c­ra­tic so­cial­ist group that were en­dorsed by the mayor won a flurry of pri­mary elec­tions in re­cent weeks, as some vot­ers em­brace left­wing pop­ulism that promises to em­power work­ing-class Americans, sim­i­lar to pledges by Trump in the past three pres­i­den­tial elec­tions.

The New York city coun­cil has also pro­posed a rule ban­ning “surveillance pric­ing”, in which com­pa­nies charge con­sumers dif­fer­ent prices for the same good or ser­vice, based on al­go­rith­mic in­for­ma­tion from their spend­ing and other per­sonal habits.

Maryland banned the prac­tice in April. Colorado’s gov­er­nor ve­toed a ban last month.

The city will take pub­lic com­ments on the junk fee rule and then hold a hear­ing, Levine said. “I cer­tainly hope that we can get this rule done by the end of the year.”

2026 – 07-10

TL;DR: A good tool is and ought to be in­vis­i­ble—striv­ing to make such tools is the goal of a tool­maker.

One habit I see a lot, and have to push back on, is tak­ing a tool’s short­com­ings and re­selling them as a “puzzle game” which is “fun” to solve.

I don’t want my tools to be “fun”. I want my tools to be in­vis­i­ble.

Text Editor Wars

Let’s take vim as an ex­am­ple

This is just an ex­am­ple, and ap­plies to other ed­i­tors too.. I con­stantly see some peo­ple praise it not for what ac­tu­ally makes it good, but by tak­ing the things it’s bad at and turn­ing them into a puz­zle to have “fun” solv­ing.

I’ve had peo­ple tell me how “fun” it was to build a macro to han­dle some one-off text-refac­tor­ing prob­lem. But when I looked at what they were do­ing and how long it took, my hon­est re­ac­tion was: I could have done that in Sublime in a minute with mul­ti­ple cur­sors, or just writ­ten a quick script.

To be clear, I’m not say­ing text ed­i­tors don’t mat­ter to your work­flow. I’m ques­tion­ing the near-re­li­gious de­vo­tion peo­ple have to a tool be­cause it gives them a “hacker vibe”—which is ba­si­cally the whole ap­peal for new­com­ers to vim or emacs.

That’s what I mean by “invisible tools”. When you’re pro­fi­cient with your ed­i­tor of choice—what­ever it is—it dis­ap­pears into the back­ground. But the mo­ment it can­not han­dle some­thing eas­ily, it stops be­ing in­vis­i­ble. What baf­fles me is that so many peo­ple treat that fric­tion—the ef­fort of work­ing around a tool’s lim­i­ta­tions—as the “fun” part, and then ad­ver­tise it as ev­i­dence that the tool is great.

I know plenty of things wrong with my own ed­i­tor of choice: Sublime. I don’t dress those flaws up as fun lit­tle puz­zles to solve. I just get an­noyed that it lacks the tools I ac­tu­ally need, forc­ing me to write a plu­gin or reach for a sep­a­rate pro­gram to write to trans­form text the way I want.

I’ve been us­ing Sublime for 15 years now. It’s my ed­i­tor of choice for a few rea­sons: its short­cuts are a su­per­set of the graph­i­cal OS en­vi­ron­ment (which min­i­mizes the men­tal con­text-switch when mov­ing be­tween ap­pli­ca­tions), mul­ti­ple cur­sors re­ally are bet­ter than macros 99.999% of the time

I think I’ve only “needed” a macro in Sublime twice in the past decade, and in both cases, set­ting up the macro took longer than if I just wrote a script to do the same thing. (since they give di­rect vi­sual feed­back), and it leaves me with the fewest “puzzles” to solve in my text-edit­ing work­flow. I’ve found some­thing like vim to be bet­ter at ba­sic edit­ing but worse at bulk op­er­a­tions—and I don’t mean grep-like op­er­a­tions—which is why I’ve stuck with Sublime for so long. I never found vim mo­tions to be that much more pro­duc­tive than my Sublime work­flow ei­ther, and that was­n’t just down to lack of try­ing or fa­mil­iar­ity

To be hon­est, I have for­got­ten most of my “vim mo­tions” knowl­edge over the years, be­cause I don’t reg­u­larly ex­er­cise it, nor do I need to.. And since I vir­tu­ally never write code in a ter­mi­nal, my need for a ter­mi­nal-ori­ented ed­i­tor is ef­fec­tively nonex­is­tent.

If peo­ple find vim, emacs, or what­ever gen­uinely good and pro­duc­tive, I’m not go­ing to crit­i­cize them for us­ing it. People are most com­fort­able with what they know. But for the peo­ple I am dis­cussing, that same fa­mil­iar­ity blinds them to their tools’ flaws, and leads them to cel­e­brate those flaws, flaunt­ing them as games.

Tools as an Identity

Part of why these de­bates turn re­li­gious is that a tool choice be­comes a flag you plant—it says some­thing about who you are. The “hacker vibe” is­n’t a mere aes­thetic; it’s tribal sig­nal­ing, and that’s the real trap. Once your iden­tity is in­vested in a tool, ad­mit­ting its flaws starts to feel like ad­mit­ting some­thing about your­self. So peo­ple don’t just tol­er­ate the flaws—they de­fend them, and even­tu­ally flaunt them. You can­not have an hon­est con­ver­sa­tion about a tool with some­one who’s de­cided the tool is part of their per­son­al­ity.

Feeling Productive ver­sus be­ing Productive

The text-ed­i­tor-macro anec­dote I men­tioned is re­ally about a gap be­tween feel­ing pro­duc­tive ver­sus be­ing pro­duc­tive. There’s a sen­sa­tion of clev­er­ness that comes from solv­ing a fid­dly prob­lem, and it’s easy to mis­take that feel­ing for ac­tual out­put. A tool that makes hard things feel heroic and clever feel like an achieve­ment can reg­is­ter as “powerful” while qui­etly be­ing slow. The hon­est test is­n’t how en­gaged or clever you felt, it’s wall-clock time and how many mis­takes you made get­ting there. A lot of the tools peo­ple evan­ge­lize would lose that test.

If pro­duc­tiv­ity is ac­tu­ally the goal, ac­tu­ally ques­tion your own views on this, and try to see what makes you more pro­duc­tive. You will be sur­prised when you do.

Terminal UIs vs GUIs

Another ex­am­ple in this same vein is when peo­ple ad­vo­cate for ter­mi­nal apps over GUIs. If you’re stuck in a ter­mi­nal all day, then I com­pletely get the ob­vi­ous ad­van­tage, but most pro­gram­mers aren’t stuck in a ter­mi­nal all day.

From those peo­ple who gen­er­ally ad­vo­cate for a TUI over a GUI, one of the crit­i­cisms of GUI apps tends to be: “I can­not nav­i­gate them with the key­board alone”.

Okay? That does­n’t make GUI apps in­her­ently bad. It just means the GUIs peo­ple build aren’t good enough to be key­board-nav­i­ga­ble. There’s noth­ing in­her­ently im­pos­si­ble about mak­ing a GUI nav­i­ga­ble with a key­board, rather it’s just that most tool­mak­ers never bother to im­ple­ment, and usu­ally be­cause they don’t re­al­ize how much more pro­duc­tive key­board nav­i­ga­tion is than reach­ing for the mouse a lot of the time. If the ar­gu­ment was that a spe­cific TUI app is bet­ter than the other al­ter­na­tives which are GUI based, then that is a fair ar­gu­ment, but ar­gu­ing that TUIs are in­her­ently bet­ter than GUIs is very mis­in­formed.

And this is the com­mon mis­take: peo­ple look at the cur­rent state of a cat­e­gory of tools and as­sume its cur­rent lim­i­ta­tions are in­her­ent/​es­sen­tial, when re­ally no one has put in the work to make those tools bet­ter.

Linux’s (Lack of) Popularity as a Desktop

The year of the Linux

I know I am go­ing to get peo­ple say­ing “Linux is the Kernel, the OS is the [insert dis­tro name]”. I’m sorry but that’s not how most peo­ple talk about Linux, and I don’t re­ally care too much for your pen­dantry which aids noth­ing. Especially since to cri­tique it, you clearly had to un­der­stand what was be­ing said about it. desk­top still is­n’t upon us (in 2026), and part of the rea­son why it has taken so long to get to that point is fun­da­men­tal: a lot of the peo­ple who use Linux love fid­dling with con­fig­u­ra­tion files to re­shape their sys­tem—it’s their idea of “fun”, their puz­zle game.

I went through that phase my­self. But af­ter a while, I just wanted things to work. Spending hours (if not days) con­fig­ur­ing every­thing is­n’t some­thing I want to do any more. I want the de­faults to be good and just work, and when I do need to tweak some­thing mi­nor, it should take sec­onds.

Maximal con­fig­ura­bil­ity should­n’t be a tool’s goal, it should be an op­tion for when it’s ac­tu­ally nec­es­sary. Designing an er­gonomic tool is fun­da­men­tally about hav­ing good de­faults, while still al­low­ing es­cape hatches where they’re pos­si­ble/​needed.

The ap­peal of ac­ci­den­tal

Characteristics that an ob­ject has con­tin­gently and can change with­out al­ter­ing the ob­jec­t’s es­sen­tial iden­tity. com­plex­ity is some­thing a lot of pro­gram­mers/​techy-folk love, giv­ing them a weird sense of se­cu­rity.

Having good de­faults is fun­da­men­tally a tool­mak­er’s re­spon­si­bil­ity. We as tool­mak­ers have a ten­dency to put the bur­den on the user: to con­fig­ure it, to tweak it, to learn it. A lot of that bur­den is re­ally a de­signer de­clin­ing to make a de­ci­sion. “Highly con­fig­urable” is of­ten just an ex­cuse for ship­ping no opin­ion at all and call­ing the re­sult­ing work your prob­lem. Good de­faults are a form of re­spect for the user’s time: the tool­maker does the think­ing once so a thou­sand users don’t each have to. And part of de­sign­ing a tool is to al­low for some es­cape hatches tool; those es­cape hatches are there for the gen­uine mi­nor­ity who need some­thing un­usual; they should not be a sub­sti­tute for get­ting the com­mon case right.

Steep Learning Curve as a “Feature”?

Another de­fence I’ve seen is that the dif­fi­culty is the whole point, it fil­ters out the un­com­mit­ted, and once you’re over the hump you’re re­warded for life. But a learn­ing curve is a cost, not a virtue. It could hy­po­thet­i­cally be ab­solutely a cost worth pay­ing, but the pay­off has to be gen­uine pro­duc­tiv­ity, not the sat­is­fac­tion of hav­ing paid it. Too of­ten the rea­son­ing is just sunk-cost dressed up as merit: “I spent months learn­ing this, so it must be worth it, and you should copy in my foot­steps too”. That’s the puz­zle game again, only now the puz­zle is the tool it­self.

Conclusion

None of this is an ar­gu­ment against any par­tic­u­lar tool. It’s an ar­gu­ment against a way of think­ing. Use vim, use emacs, use Sublime, but use what­ever dis­ap­pears into the back­ground and lets you get on with the work. That is the whole test, and it’s a per­sonal one. What I’m push­ing back on is­n’t the choice, it’s the sto­ry­telling that grows up around the choice: the re­fram­ing of lim­i­ta­tions as fea­tures, the ef­fort of work­ing around a flaw sold as the re­ward, the tool qui­etly pro­moted from the thing-you-use to the part-of-who-you-are.

The clear­est sign a tool is serv­ing you is that you stop notic­ing it—it be­comes in­vis­i­ble. You don’t cel­e­brate its flaws be­cause you’re not turn­ing them into a hobby, rather you just get mildly an­noyed and route around them. You don’t de­fend it be­cause noth­ing about your iden­tity is rid­ing on it. And you don’t mis­take the feel­ing of clev­er­ness for the fact of pro­duc­tiv­ity, be­cause you’ve both­ered to check the dif­fer­ence.

So by all means, en­joy your tools, for the joy of pro­gram­ming it­self. Just be hon­est about which parts are gen­uinely good and which parts you’ve talked your­self into lov­ing. The best tool is­n’t the one with the best story. It’s the one you for­get you’re us­ing.

A good tool is and ought to be in­vis­i­ble—striv­ing to make such tools is the goal of a tool­maker.

This week, by or­der of the ACOUP Senate, we’re talk­ing about the Late Bronze Age Collapse (commonly ab­bre­vi­ated ‘LBAC’), the shock­ing col­lapse of the Late Bronze Age state sys­tem across the Eastern Mediterranean and Middle East dur­ing the 12th cen­tury (that is, the 1100s) BC. In the broader Mediterranean world, the Late Bronze Age Collapse is the event that prob­a­bly comes clos­est to a true ‘end of civ­i­liza­tion’ event — mean­ing­fully more se­vere than the col­lapse of the Roman Empire in the West (although as we’ll see LBAC is also not as ‘total’ of a col­lapse as was some­times sup­posed).

This is go­ing to be, by our stan­dards here, some­thing of a brief overview, roughly the equiv­a­lent to the lec­ture I give to my stu­dents when we cover this pe­riod (with a bit more de­tail, be­cause text is more com­pressed). A full ‘deep di­ve’ of all of the de­bates and open ques­tions of this pe­riod would no doubt run quite a few posts and more im­por­tantly re­ally ought to be writ­ten by spe­cial­ists in the bronze age. This is also a very ar­chae­o­log­i­cally dri­ven topic, which makes it more sen­si­tive than most to new ev­i­dence — ar­chae­o­log­i­cal site work, but also epi­graphic ev­i­dence (mostly on clay tablets) — that can change our un­der­stand­ing of events. As we’ll see, our un­der­stand­ing has changed a fair bit.

So what we’ll do is run through what we know about what hap­pened in the col­lapse (which is the most vis­i­ble part of it) and then we’ll loop back to the ques­tion of causes (which re­main sub­stan­tially un­cer­tain) and then fi­nally look at the long-term im­pacts of the col­lapse, which are con­sid­er­able.

But first, as al­ways, if you like what you are read­ing here, please share it; if you re­ally like it, you can sup­port me on Patreon; mem­bers at the Patres et Matres Conscripti level get to vote on the top­ics for post-se­ries like this one! If you want up­dates when­ever a new post ap­pears or want to hear my more bite-sized mus­ings on his­tory, se­cu­rity af­fairs and cur­rent events, you can fol­low me on Bluesky (@bretdevereaux.bsky.social). I am also ac­tive on Threads (bretdevereaux) and main­tain a de min­imis pres­ence on Twitter (@bretdevereaux).

The (Partial?) Collapse

We need to be clear, to be­gin with, that while we have scat­tered frag­ments of epi­graphic ev­i­dence (that is, in­scrip­tions), al­most all of our ev­i­dence for the Late Bronze Age Collapse is ar­chae­o­log­i­cal. Without ar­chae­ol­ogy, we would re­main largely in the dark about this event. But ar­chae­o­log­i­cal ev­i­dence also brings with it chal­lenges: it can tell you what is hap­pen­ing (sometimes) but of­ten not why and dat­ing with pre­ci­sion can be chal­leng­ing. Most of what we’re track­ing in un­der­stand­ing LBAC is site de­struc­tion, iden­ti­fied by the de­mo­li­tion of key build­ings or ‘destruction lay­ers’ (often a thin layer of ash or rub­ble in­di­cat­ing the site was burned or de­mol­ished), but dat­ing these pre­cisely can be dif­fi­cult and there are al­ways chal­lenges of in­ter­pre­ta­tion.

With that said, the Late Bronze Age Collapse is a se­quence of site de­struc­tions vis­i­ble ar­chae­o­log­i­cally from c. 1220 BC to c. 1170 BC, which are as­so­ci­ated with the col­lapse or se­vere de­cline of the ma­jor states of the re­gion (the Eastern Mediterranean and Middle East). We gen­er­ally con­cep­tu­al­ize these de­stric­tions as a ‘wave’ mov­ing in se­quence be­gin­ning in the Aegean, mov­ing over Anatolia, sweep­ing down the Levant and ar­riv­ing in Egypt but in many cases my sense is the chronol­ogy is more com­plex than that. Many sites in the path of this ‘wave’ were not de­stroyed, with some de­clin­ing slowly and oth­ers de­clin­ing not much at all; other sites (I have in mind Tiryns) see the de­struc­tion of their po­lit­i­cal cen­ter but the de­cline of the ur­ban set­tle­ment around it hap­pens slowly or later.

First, we ought to set the stage of the Late Bronze Age. What re­ally marks out the Late Bronze Age (c. 1500 BC to c. 1200 BC) from ear­lier pe­ri­ods is that the emerg­ing state sys­tems in Mesopotamia, Syria, Anatolia and Egypt had ex­panded to the point of com­ing quite fully into con­tact with each other, with a sig­nif­i­cant de­gree of diplo­matic, eco­nomic and cul­tural in­ter­con­nect­ed­ness, to the point that we some­times re­fer to the ‘Late Bronze Age Concert of Powers’ (evoking 19th cen­tury European bal­ance of power pol­i­tics) when talk­ing in­for­mally about them.

Now I should cau­tion, we of­ten pro­vide these nice neat maps of the Late Bronze Age pow­ers (and they’re use­ful to a de­gree) but the bor­ders of these states were quite fuzzy — their outer ‘possessions’ were of­ten trib­u­taries un­der the rule of lo­cal kings which might be weakly at­tached to the im­pe­r­ial cen­ter. Nevertheless, go­ing from East to West: south­ern Mesopotamia was dom­i­nated by the ‘Middle Babylonian’ Empire, ruled by the Kassite dy­nasty (the Kassites be­ing an eth­nic group who had taken power around 1530 BC) while north­ern Mesopotamia was dom­i­nated by the Middle Assyrian Empire (from about c. 1350 BC). Anatolia and the Northern Levant was con­trolled by the multi-eth­nic Hittite Empire, which seems to have sparred reg­u­larly with the New Kingdom of Egypt which con­trolled Egypt and the south­ern Levant. Basically all of these pow­ers had less set­tled, of­ten pas­toral peo­ples in their hin­ter­lands which pre­sented on-go­ing se­cu­rity chal­lenges for them.

These larger im­pe­r­ial states were more eco­nom­i­cally com­plex as well. In par­tic­u­lar, their large armies re­quired sig­nif­i­cant amount of bronze which — be­cause its core in­gre­di­ents of tin and cop­per ef­fec­tively never oc­cur in the same place — de­manded sub­stan­tial long-dis­tance trade, though trade was hardly only in cop­per and tin, but also in­cluded other high value goods and even (where fea­si­ble) bulk sta­ples. So while these pow­ers clashed reg­u­larly, at the elite level (if not at the level of the sub­sis­tence econ­omy) they were also re­liant on each other to some de­gree.

Finally, at the edge of this state sys­tem is the Mediterranean and es­pe­cially the Aegean. In the Aegean — in Greece and Crete es­pe­cially — we see ef­fec­tively minia­ture ver­sions of these state struc­tures, com­plete with (by Near Eastern Standards) itty-bitty palaces (the Minoan ur­ban cen­ters on Crete had come un­der Mycenean (=Greek) rule in c. 1450, the palaces there largely aban­doned). Cyprus shifted be­tween be­ing nom­i­nally sub­or­di­nate to ei­ther the Hitties of the Egyptians but seems to have mostly run its own af­fairs and was in­te­grated through trade into the state sys­tem.

As noted above, LBAC starts per­haps as early as 1220 or so, and what we see in very rough se­quence is as fol­lows.

As far as I know, we still gen­er­ally think the ear­li­est rum­blings are in­sta­bil­ity in the Mycenean Greek palace states. Things had been un­sta­ble in this area for a few decades and we have some scat­tered de­struc­tions (Thebes) and in­ten­si­fied for­ti­fi­ca­tions around 1250, sug­gest­ing things were not go­ing great in Greece. Then from c. 1200 to c. 1180 we see the de­struc­tion or col­lapse of ba­si­cally all of the palace cen­ters in Greece. In some cases the ur­ban core con­tin­ues for a while, in other cases it does­n’t — in a num­ber of cases, once the site is aban­doned, it is not rein­hab­ited (e.g. Mycenae it­self, the largest of the palace cen­ters).

As we’ll see be­low, the im­pact in Greece is greater than ba­si­cally any­where else be­cause the col­lapse of the LBAC is more se­vere in Greece than ba­si­cally any­where else.

Meanwhite, the Hittite Empire was it­self not in good shape when this started. As far as we know, the Hittites were very much on the ‘back foot’ in the late 1200s, pres­sured by the Assyrians and Egypt and so po­ten­tially al­ready short on re­sources when their neigh­bors to the West be­gan im­plod­ing. As far as I know, pre­cise dates are hard to nail down for this, but the Hittite Empire in the early 1100s comes apart un­der pres­sure and by 1170 or so it is gone. That col­lapse of im­pe­r­ial power is matched by a sig­nif­i­cant num­ber of site de­struc­tions across Anatolia, in­clud­ing the Hittite cap­i­tal at Hattusas and the large set­tle­ment at mod­ern Hisarlik, now fairly se­curely iden­ti­fied as an­cient Troy. Some (like Troy) were re­built, oth­ers (like Hattusas) were not, but cen­tral­ized Hittite power was gone and there’s a marked re­duc­tion in ur­ban­iza­tion and prob­a­bly pop­u­la­tion.

Moving into the Northern Levant, Syria and Northern Mesopotamia, we see Assyrian power — which had been ad­vanc­ing be­fore, you’ll re­call — con­tract sharply along­side more site de­struc­tions, though again chronol­ogy is tricky. One of the key sites here is Ugarit, a ma­jor Bronze Age Levantine coastal city which was de­stroyed c. 1190 — be­fore the last of the Mycenean palaces (but af­ter the first of them). The city’s de­struc­tion in fire pre­served clay tablets with diplo­matic mes­sages from the lo­cal king of Ugarit (a Hittite vas­sal) fran­ti­cally writ­ing to his Hittite su­pe­ri­ors for re­in­force­ments in the face of sig­nif­i­cant (but frus­trat­ingly un­named) threats prior to the de­struc­tion of the city.

That said, de­struc­tion in the Fertile Crescent is very un­even. The Middle Assyrian Empire con­tracts, but does not col­lapse, while the Kassite Dynasty in Babylon clearly suf­fers some de­cline, but largely sta­bi­lizes by the 1160s be­fore be­ing run over by the Elamites in the 1150s. Site de­stric­tions in the Levant are un­even and some key Bronze Age cen­ters like Sidon and Byblos were not de­stroyed and re­mained ma­jor cen­ters into the Iron Age.1 My un­der­stand­ing is that while there was sig­nif­i­cant de­cline in the south­ern Levant, it is hard to pin any spe­cific large-scale site de­struc­tion to the 1220 – 1170 pe­riod.

Finally we reach Egypt in a pe­riod we re­fer to as the ‘New Kingdom’ (1570 – 1069); we can trace pol­i­tics more clearly here due to sur­viv­ing Egyptian in­scrip­tions. Egypt was also in a weak­ened po­si­tion go­ing into this cri­sis, fac­ing pres­sure from Libyan raiders com­ing over­land from the West and also some in­ter­nal in­sta­bil­ity. In c. 1188, civil war broke out as the last queen of the reign­ing 19th dy­nasty was un­able to re­tain con­trol, lead­ing to re­volt and the seizure of power by Setnakhte and the 20th dy­nasty; his son Ramesses III took power in c. 1185. Things did­n’t get eas­ier from there as we hear re­ports of re­newed Libyan in­cur­sions in c. 1180 (coming from the west) fol­lowed al­most im­me­di­ately by an in­va­sion by the ‘sea peo­ples’ (see be­low) who were ev­i­dently fended off in at least two ma­jor bat­tles, the Battle of the Delta (c. 1179ish?) and the Battle of Djahy (c. 1178ish?).

Egypt holds to­gether, but there’s a fair bit of ev­i­dence eco­nomic strain (likely cli­mate based, see be­low) and the abil­ity of Egypt to pro­ject power out­side of Egypt seems largely spent by the end of the reign of Ramesses III; his suc­ces­sors do not ap­pear to have been able to right the ship and Egyptian power con­tin­ued to frag­ment and de­cline, with the dy­nasty stum­bling on un­til it col­lapsed in 1077 lead­ing to the Third Intermediate Period (‘Intermediate Periods’ are the term for pe­ri­ods of frag­men­ta­tion within Egypt).

I should note in this overview that our un­der­stand­ing of this se­quence of col­lapses and de­clines has changed sig­nif­i­cantly. The idea of the Late Bronze Age Collapse has been around since the early 1800s when his­to­ri­ans first no­ticed that the end of the Greek ‘Age of Heroes’ (linked by them to the Fall of Troy, which the (Classical) Greeks be­lieved hap­pened in 1184) seemed to map neatly on to the fail­ure of the Egyptian 19th Dynasty. As ar­chae­ol­o­gists in the later 1800s and early 1900s started ac­tu­ally ex­ca­vat­ing the Greek ‘Age of Heroes’ (thus dis­cov­er­ing the (Mycenaean) Greek Late Bronze Age, which we term the ‘Late Helladic’ pe­riod (c. 1700-c. 1040 BC)) and then find­ing site de­struc­tions date­able within a band of per­haps 1250 to 1150 BC in Greece, Anatolia, Syria and the Levant the idea of a gen­eral col­lapse around the leg­endary date for the Fall of Troy picked up a lot of steam.

My sense of the schol­ar­ship is that this ‘civilizational col­lapse’ nar­ra­tive has been drawn back a bit as it be­comes clear that some sites were not de­stroyed and also that some site de­struc­tions or aban­don­ments hap­pened sig­nif­i­cantly later or ear­lier than the rel­a­tively tight 1220 – 1170 BC time frame that emerged for the core of the col­lapse. No one (that I know of) is ar­gu­ing there was no LBAC — there was clearly an LBAC — but the scale of the col­lapse re­mains some­thing of a mov­ing tar­get as we ex­ca­vate more sites, adding them to lists of sites that were de­stroyed, de­clined or (sometimes seem­ingly ran­domly) were spared.

And the list of sites that were not de­stroyed is sig­nif­i­cant. Of note, Athens very clearly has a Mycenaean citadel on the Acropolis (which can’t be ex­ca­vated be­cause the Acropolis is in the way, but it is very ob­vi­ously there) but there’s no break in set­tle­ment in Athens. Already men­tioned, Byblos and Sidon re­mained very promi­nent cen­ters be­fore and af­ter, while Jerusalem and Tyre, both ap­par­ently mi­nor set­tle­ments be­fore LBAC (and not de­stroyed) will be­come in­creas­ingly promi­nent in the Iron Age Levant. Likewise the great cities of Egypt and Mesopotamia re­main, few to no site de­struc­tions in ei­ther re­gions. At the same time, many set­tle­ments that es­cape de­struc­tion do not es­cape de­cline: in many cases these cities con­tinue to shrink (and some places that es­cape de­struc­tion, like Tiryns, shrink slowly rather than van­ish­ing all at once) or grow vis­i­bly poorer in a longer process. So the mo­ment of de­struc­tion comes with a long ‘tail’ of de­cline stretch­ing out decades.

So to sum­ma­rize, the Late Bronze Age Collapse is a se­ries of site de­struc­tions, aban­don­ments and de­clines run­ning from roughly 1220 to roughly 1170 (though de­cline con­tin­ues af­ter this point) dis­trib­uted quite un­evenly through the in­ter­con­nected Late Bronze Age Mesopotamian-and-Eastern-Mediterranean world. Greece and Anatolia are se­verely im­pacted, the Levant some­what less but still fairly strongly, while the states of Egypt and Mesopotamia do not col­lapse but en­ter long pe­ri­ods of de­cline.

What that de­scrip­tion leaves out, of course, are causes and ef­fects.

Bad Theories

While the ‘what’ of LBAC can be pinned down fairly con­clu­sively with ar­chae­ol­ogy, the ‘why’ is tougher — a lot of po­ten­tial causes (wars, armies, civil un­rest) don’t nec­es­sar­ily leave a lot of clues in our source ma­te­r­ial.

There are a few the­o­ries we can largely dis­count at the out­set though. The older of these were the­o­ries that as­sumed that the cause of at least some of the Late Bronze Age Collapse were large-scale mi­gra­tions of peo­ple into (rather than within) the set­tled, ur­ban zone we’ve been talk­ing about, in par­tic­u­lar the idea of a ‘Dorian Invasion’ of Greece as the spark of the col­lapse. Proposed in the 1800s, the idea here was that the ‘Dorians’ — the an­ces­tors of the Greeks — would have mi­grated into Greece, de­stroy­ing the Mycenaean cities and palaces and dis­plac­ing or dom­i­nat­ing the pre­vi­ous (non-Greek) in­hab­i­tants. This no­tion was based on mixed and com­pet­ing ideas within (Classical) Greek lit­er­a­ture: Greek au­thors both ex­pressed the idea of the Greeks be­ing au­tochtho­nous (indigenous to their ter­ri­tory, lit­er­ally ‘[arising] on their own from the earth’) and also be­ing in­vaders, ar­riv­ing at some point forty to eighty years af­ter the Trojan War (e.g. Thuc. 1.12; Hdt. 1.56 – 58). That idea got picked up by 19th cen­tury European schol­ars who, to be frank, of­ten thought un­crit­i­cally in terms of pop­u­la­tion mi­gra­tion and re­place­ment, through an of­ten ex­plic­itly racist lens of ‘superior stock’ dri­ving out ‘inferior stock.’ And so they imag­ined a ‘Dorian in­va­sion’ of the (racially) ‘superior’ Greek-speaking Dorians2 dri­ving out the pre-Greek Mycenaean pop­u­la­tion, par­tic­u­larly in the Peloponnese.

As an aside, it is not un­com­mon for a sin­gle so­ci­ety to uti­lize both leg­endary myths of au­tochthony and ar­rival-by-con­quest, choos­ing whichever is more use­ful in the mo­ment, even though they are ob­vi­ously, from a log­i­cal stand­point, mu­tu­ally in­com­pat­i­ble.

Archaeology has fun­da­men­tally un­der­mined this the­ory — nuked it from or­bit, re­ally — in two key ways. First, we have Mycenaean writ­ing, which was dis­cov­ered in a strange script called Linear B (Minoan writ­ing is Linear A). Originally un­read­able to us, in 1952 Michael Ventris suc­cess­fully demon­strated that Linear B was, in fact, Greek (rendered in a dif­fer­ent, older script) and so the Mycenaeans were Greeks. Meanwhile a wide range of ar­chae­ol­o­gists and ma­te­r­ial cul­ture schol­ars, as more late Helladic and early Archaic pot­tery and art­work emerged, were able to demon­strate there sim­ply was no dis­con­ti­nu­ity in ma­te­r­ial cul­ture. The Greeks could not be ar­riv­ing at the end of the Bronze Age be­cause they were al­ready there and had been for cen­turies at least. Migrations within the Eastern Mediterranean might still play a role, but the idea that the col­lapse was caused by the ar­rival of the Greeks has been de­ci­sively aban­doned. There was no Dorian Invasion.

The other cause we can prob­a­bly dis­miss is a sin­gle, sud­den nat­ural calamity. There are two can­di­dates here to note. The first is sim­ply peo­ple con­fus­ing the ma­jor erup­tion of Thera (c. 1600) which is some­times as­so­ci­ated with the de­cline of the Minoan Palaces (though the chronol­ogy does­n’t re­ally work well there ei­ther) with LBAC. The sec­ond is ef­fort to con­nect the erup­tion of Hekla in Iceland with LBAC. The prob­lem again is that the chronol­ogy does not ap­pear to work out — es­ti­mates for the dat­ing of the Hekla erup­tion range from 1159 to 929 with the con­sen­sus be­ing, as I un­der­stand it, closer to 1000 BC. For our part, the range does­n’t mat­ter much — even that ear­li­est 1159 date would mean that Hekla’s mas­sive erup­tion could hardly ex­plain the col­lapse of Mycenean palaces hap­pen­ing at least forty years ear­lier. Climate played a role in LBAC, but it is not clear that vol­canic cli­mate in­flu­ence did and it is very clear that Hekla did not (though per­haps it con­tributed to make a bad de­cline worse.

So no ‘Dorian Invasions’ and no vol­ca­noes, so what did cause it?

Causes of LBAC

We have no firm an­swers, but a num­ber of plau­si­ble the­o­ries and at this point my sense is that just about every­one work­ing on this pe­riod adopts some vari­a­tion of ‘all of the above’ from this list.

We can start with cli­mate. For rea­sons there’s been quite a lot of re­search into his­tor­i­cal cli­mate con­di­tions and we can ac­tu­ally get a sense of those con­di­tions to a de­gree ar­chae­ol­ogy from things like tree rings (where very nar­row rings can in­di­cate dry years or oth­er­wise un­fa­vor­able con­di­tions). I don’t work on his­tor­i­cal cli­mate, but my un­der­stand­ing is there is quite a lot of com­pelling ev­i­dence that pe­riod of LBAC, es­pe­cially the 1190s, was un­usu­ally dry in the Eastern Mediterranean, which would have caused re­duced agri­cul­tural out­put (crop fail­ures). Interestingly, this would be most im­me­di­ately im­pact­ful in ar­eas en­gaged pri­mar­ily in rain­fall agri­cul­ture (Greece, Anatolia, the Levant) and less im­pact­ful in ar­eas en­gaged more in ir­ri­ga­tion agri­cul­ture (Egypt, Mesopotamia).3 And, oh look, the ar­eas where LBAC was more se­vere are in the rain­fall zone and the ar­eas where it was less se­vere are in the ir­ri­ga­tion zone.

Crop fail­ures may have been par­tic­u­larly po­lit­i­cally volatile be­cause of the struc­ture and val­ues of the kind of Near Eastern states (to in­clude Anatolia and Greece here) that we’re deal­ing with. We haven’t dis­cussed early bronze age states very much but the ev­i­dence we have sug­gests that these were sig­nif­i­cantly cen­tral­ized states, with a lot — not all, but a lot — of the re­sources mov­ing through ei­ther state (read: royal) struc­tures or through tem­ple in­sti­tu­tions which might as well have been state struc­tures. Which is to say these are so­ci­eties where the king and the tem­ples (which re­port to the king) own most of the land and so har­ness most of the agri­cul­tural sur­plus through rents and then em­ploy the li­on’s share of non-agri­cul­tural la­bor, re­dis­trib­ut­ing their pro­duc­tion. Again, I don’t want to over­state this — there is a ‘private sec­tor’ in these economies — but it seems (our ev­i­dence is lim­ited!) to be com­par­a­tively small.

Meanwhile, the clearly at­tested re­li­gious role of the king in a lot of these so­ci­eties in­cludes a re­spon­si­bil­ity — of­ten the para­mount re­spon­si­bil­ity — to main­tain the good re­la­tions of the com­mu­nity with the gods (who pro­vide the rain and make the plants grow).

Repeated crop fail­ures are thus go­ing to be seen as a sign that the King is falling down on the job. Worse yet, they’ll have come at the same time as the King found him­self strained to main­tain his bu­reau­crats and sol­diers, be­cause the en­tire top-heavy royal ad­min­is­tra­tion this sys­tem re­lies on is fed off of the sur­plus it ex­tracts.

It is not hard to see how this is a recipe for po­lit­i­cal in­sta­bil­ity if large states do not have the re­sources to fall back on to re­spond to the cri­sis.

To which some schol­ars have noted that the pe­riod di­rectly lead­ing up to LBAC seems to have been a pe­riod of in­ten­si­fy­ing war­fare: we hear of larger armies op­er­at­ing in the wars in Mesopotamia, Egypt and the Levant and we see mas­sively greater in­vest­ment in for­ti­fi­ca­tion in the Aegean all sug­gest­ing that the states are pour­ing re­sources into war­fare. That may have left these states with fewer re­sources (idle la­bor, stored grain, money-covertable valu­ables or sim­ply re­serves of pub­lic good­will since long years of high taxes in long wars tends to tire peo­ple out) with which to con­front a sud­den wave of com­bined po­lit­i­cal un­rest and food short­age.

What is clear is that once the col­lapse started, it was con­ta­gious, likely for two rea­sons: first that col­laps­ing ar­eas pro­duced in­vad­ing forces and refugee flows that desta­bi­lized their neigh­bors and sec­ond be­cause as you will re­call above, these states are in­ter­linked and their rulers rely on trade to fur­nish the key mil­i­tary re­source (bronze) as well as to ac­quire key pres­tige goods nec­es­sary to main­tain the loy­alty of the aris­toc­racy.

The clear­est ev­i­dence of this are the re­ports in Egyptian in­scrip­tions of peo­ples grouped un­der the mod­ern head­ing of ‘Sea Peoples’ be­cause they are of­ten de­scribed as be­ing ‘of the sea’ in one way or an­other. The ev­i­dence here is tricky: what we have are a set of in­scrip­tions, span­ning from 1210 through to the mid-1100s de­scrib­ing fight­ing against — and, this be­ing Egyptian royal writ­ing, in­vari­ably the vic­tory of a Pharaoh over — a range of in­vad­ing peo­ples. What is tricky is these re­ports cover mul­ti­ple pe­ri­ods of fight­ing and they’re us­ing Egyptian names for these peo­ple mean­ing we’re not al­ways en­tirely con­fi­dent that we can tell who ex­actly the Egyptians meant to iden­tify.

Generally, how­ever, what we seem to be see­ing is in­creased pres­sure on Egypt from c. 1205 to c. 1170 from multi-eth­nic coali­tions of peo­ples drawn from the Aegean, Anatolia and the Levant. In par­tic­u­lar, in­scrip­tions from the reign of Merneptah (r. 1213 – 1203) re­port at­tacks by the Ekwesh (possibly an Egyptian ren­der­ing of Achaioi, ‘Achaean,’ mean­ing Greek) along with the Lukka (an Anatolian peo­ple), the Sherden (probably a Levantine peo­ple, per­haps the Philistines) and oth­ers even harder to pin down like the Shekelesh (more Anatolians? Sicels? other peo­ple on boats?). Later in­scrip­tions from the reign of Ramesses III (r. 1185 – 1154) re­port rel­a­tively early in his reign vic­to­ries against coali­tions that in­clude the Denyen (possibly an Egyptian ren­der­ing of ‘Danaioi,’ mean­ing Greek), the Sherden (again), the Shekelesh (again), the Peleset (Levantine peo­ple, prob­a­bly Philistines) and oth­ers.

The way this ev­i­dence is gen­er­ally read — and this seems the most plau­si­ble ex­pla­na­tion — is that the dis­rup­tions in the Aegean, Anatolia and Levant may have them­selves pro­duced armed mass-mi­gra­tions, mov­ing by sea (these were all sea-far­ing peo­ples), per­haps look­ing for safe har­bor. Or per­haps quite lit­eral bands of raiders — the col­lapse of state struc­tures in Greece and Anatolia might well have left a lot of full-time vi­o­lence-do­ers with­out steady em­ploy­ment and go­ing raid­ing may have been a nat­ural re­course for some. There is some sense in Hittite doc­u­ments, for in­stance that the ‘Ahhiyawa’ (Hittite ren­der­ing for Achaioi, mean­ing Greek) might have been an hos­tile neigh­bors to the Hittites and given how heav­ily mil­i­ta­rized elite Mycenaean cul­ture seems to have been, it would­n’t be shock­ing if they reg­u­larly went on seaborne raids (though, again, the ev­i­dence here is very thin).

Meanwhile, while trade does not com­pletely stop, it cer­tainly seems to be re­duced by the col­lapse of these states, pos­si­bly in­ter­rupt­ing the sup­ply of key goods — the most ob­vi­ous be­ing bronze — and any state rev­enues de­rived from tax­ing trade (which they did).

Consequently the ‘consensus’ vi­sion — which re­mains to a de­gree con­jec­tural, al­though it is the ‘best fit’ for the ev­i­dence — runs roughly like this:

Intensifying war­fare in the E. Mediterranean and Mesopotamia may have re­duced the re­sources avail­able for ma­jor states to con­front a cri­sis and per­haps were al­ready as­so­ci­ated with some kind of un­rest.

A shift to a drier cli­mate causes har­vest fail­ures which be­gin to push the tee­ter­ing states over the edge into col­lapse.

In Greece, the palace states be­gin to col­lapse one by one — prob­a­bly from in­ter­nal strains (e.g. an op­pressed peas­antry) rather than ex­ter­nal in­va­sion.

Because the ‘palace econ­o­my’ was so cen­tral (and em­ployed a lot of peo­ple, in­clud­ing a lot of war­riors), col­lapse within Greece may have been con­ta­gious as raids and refugees spawned by col­laps­ing palace sys­tems fa­tally strained oth­ers.

Because the ‘palace econ­o­my’ was so cen­tral (and em­ployed a lot of peo­ple, in­clud­ing a lot of war­riors), col­lapse within Greece may have been con­ta­gious as raids and refugees spawned by col­laps­ing palace sys­tems fa­tally strained oth­ers.

Those col­lapses in turn be­gin to dis­rupt trade but also pro­duce out­ward move­ments of refugees and/​or raiders, which may in part be what is be­ing ‘remembered’ in Homer’s ac­count of the Trojan War or the broader Greek mytho­log­i­cal as­sump­tion that the Trojan War marks the end of the ‘Age of Heroes’ (which is how the Classical Greeks un­der­stood this pe­riod).

That same strain hits the al­ready ail­ing Hittite Empire, strained by wars and de­feats in the Levant against the Egyptians and Assyrians. Battered by har­vest fail­ures and in­creas­ing raids (such as those Ugarit is cry­ing for help from), Hittite power col­lapses.

The states of the Northern Levant, un­der pres­sure al­ready now lose their pro­tec­tor, while the other ma­jor states of the re­gion (Egypt, Assyria, Kassite Babylon) lose a key trade part­ner and at least some ac­cess to tin in par­tic­u­lar (required for bronze).

The re­sult­ing eco­nomic con­trac­tion pro­duces in­ter­nal in­sta­bil­ity (Nineteenth dy­nasty re­placed by Twentieth in Egypt) and com­bined with fur­ther raid­ing/​refugee pres­sures, all of these im­pe­r­ial pow­ers con­tract into their home­lands, no longer able to pro­ject power far afield.

In Babylon, the Kassites more or less sta­bi­lize by the 1160s, but in a weak­ened state, are over­run by the Elamites — a per­pet­ual lo­cal threat — in the 1150s. In Egypt there’s a mo­ment of re­cov­ery and sta­bil­ity un­der Ramesses III of the new Twentieth Dynasty, but fur­ther suc­ces­sion dis­putes — per­haps in part mo­ti­vated by bad eco­nomic con­di­tions — lead to power frag­ment­ing un­til cen­tral rule col­lapses in the early 1070s. Assyrian power con­tracts back to the Assyrian home­land in Northern Mesopotamia, but the state sur­vives, to reemerge as a stag­ger­ingly ma­jor power in the early Iron Age.

You will of course note that we can ob­serve all of these stages only very im­per­fectly: we’re work­ing with frag­men­tary let­ters, in­scrip­tions that are of­ten un­re­li­able and of­ten very good ar­chae­ol­ogy that can tell us what hap­pened (‘this palace was burned and all of the fin­ery was dumped in a well’) but not why.

The Effects of the Collapse

Just as the col­lapse it­self was un­even — some states and set­tle­ments de­stroyed, oth­ers largely spared — so too its ef­fects were un­even, so we might do a brief run­down by re­gion.

But first I want to note the ef­fect the col­lapse has on our ev­i­dence. In many places, I com­pare it to a light­ning bolt at night that takes out the power. Immediately be­fore the col­lapse, it was dim, but there was some light: though deep in the past, we have large states that are cre­at­ing records and in­scrib­ing things on stone some small por­tion of which sur­vive; we can’t see any­where near as well as we can dur­ing the last mil­len­nium BC, but we can see some things. Then the col­lapse hits like that bolt of light­ning and we sud­denly get a lot of ev­i­dence at once. Destruction lay­ers are of­ten ar­chae­o­log­i­cally rich (things get de­posited that would­n’t nor­mally) and when, for in­stance, some­one burns an archive full of clay tablets, that fires the clay tablets in ce­ramic, which can sur­vive. Meanwhile it is eas­ier to ex­ca­vate sites that were aban­doned and not re-in­hab­ited: they prob­a­bly don’t have ma­jor mod­ern cities on them and you don’t have to ex­ca­vate care­fully through cen­turies of dense, con­tin­u­ous habi­ta­tion to get down to the bronze age level.

But then in many ar­eas — es­pe­cially Greece — we are plunged into a lot of dark­ness. The states that were pro­duc­ing writ­ten records are ei­ther much smaller or gone en­tirely. Reduced at the same time is trade in goods that we can use to see long-dis­tance cul­tural con­nec­tions. And in many cases poorer so­ci­eties build in wood and mud­brick rather than stone; the lat­ter sur­vives far bet­ter than the for­mer to be ob­served ar­chae­o­log­i­cally.

The Aegean and main­land Greece — that is, the Mycenaean Greeks — were ev­i­dently hit hard­est by the col­lapse. Much like Britain when the Roman Empire col­lapsed in the West, be­ing on the very edge of the state sys­tem as it came apart left them ev­i­dently far more iso­lated with a much more se­vere de­cline. Large-scale stone build­ing ef­fec­tively van­ishes in Greece and won’t reap­pear un­til the Archaic pe­riod (750 – 480), which in turn makes it much harder to ob­serve things like set­tle­ment pat­terns dur­ing the in­ter­ven­ing pe­riod, some­times termed the Greek Dark Age (1100 – 750; many ar­chae­ol­o­gists of the pe­riod dis­like this term for ob­vi­ous rea­sons). But from what we can see, Greece seems to largely deur­ban­ize in this pe­riod, al­though at least one Mycenaean cen­ter sur­vives — Athens. That may in turn ex­plain to some de­gree why Athens is such a big po­lis in terms of its ter­ri­tory by the time we can see it clearly in the Archaic.

Perhaps most shock­ingly, main­land Greece loses writ­ing. The Mycenaean palaces had de­vel­oped a syl­labic script, which we call Linear B, to rep­re­sent their spo­ken Greek. This form of writ­ing is en­tirely lost. In the 8th cen­tury, the Greeks will adopt an en­tirely new script — bor­row­ing the one the Phoenicians are us­ing — to rep­re­sent their lan­guage and we (and they) will be un­able to read Linear B un­til 1953.

The to­tal­ity of the col­lapse of cen­tral state in­sti­tu­tions in Mycenaean Greece may in part ex­plain the emer­gence of a po­lit­i­cal in­sti­tu­tion as strange as the po­lis. It is clear that through the Greek ‘Dark Ages’ and the sub­se­quent Archaic pe­riod, though Greek com­mu­ni­ties have ‘kings’ — though called basileis (a word that in the Mycenaean Linear B tablets would mean ‘village chief,’ a sub­or­di­nate to the ac­tual king in the palace, the wanax, a term Homer uses for Agamemnon and Priam only) — they lack the cen­tral­ized eco­nomic en­gine of the palace econ­omy and in­stead have much weaker cen­tral gov­ern­ing sys­tems. It is some­thing not quite but per­haps close to a ‘clean slate’ from which to de­velop new sys­tems of gov­er­nance that will look very dif­fer­ent from what so­ci­eties to their East had de­vel­oped.

No other part of the Eastern Mediterranean suf­fers a civ­i­liza­tional set­back quite as in­tense as in Greece, but per­haps the most sig­nif­i­cant ef­fect is a pe­riod of pro­longed po­lit­i­cal frag­men­ta­tion in Anatolia and the Levant. These re­gions had been, over the Late Bronze Age, largely un­der the con­trol of ma­jor im­pe­r­ial pow­ers (Egypt, Assyria, the Hittites), but with those pow­ers re­moved they have a chance to de­velop some­what in­de­pen­dently. That pe­riod of rel­a­tive in­de­pen­dence is go­ing to slam shut when the Neo-Assyrian Empire — it­self a con­tin­u­a­tion of the Middle Assyrian Empire, re­cov­ered from LBAC — re­asserts it­self in the ninth cen­tury, dom­i­nat­ing the Levant and even Egypt.

But in the in­ter­ven­ing time a num­ber of dif­fer­ent smaller so­ci­eties have a chance to make their own way in the Levant, two of which are go­ing to leave a very large mark. In the north­ern Levant, this pe­riod of frag­men­ta­tion cre­ates space for the rise of the ma­jor Phoenician cen­ters — Byblos, Sidon and Tyre (of which the lat­ter will even­tu­ally be­come the most im­por­tant). As we’ve dis­cussed, those are go­ing to be the start­ing point for a wave of Phoenician col­o­niza­tion in the Mediterranean, as Phoenician traders steadily knit Mediterranean trade net­works (back) to­gether. They are also, as noted above, us­ing their own pho­netic script, the Phoenician al­pha­bet, which is in turn go­ing to form the ba­sic of many other re­gional scripts. Perhaps most rel­e­vant for us, the Greeks will adopt and mod­i­fy­ing the Phoenician al­pha­bet to rep­re­sent their own lan­guage and then peo­ples of pre-Ro­man Italy will adopt and mod­ify that to make the Old Italic al­pha­bet which in turn be­comes the Latin al­pha­bet which is the al­pha­bet in which I am typ­ing right now.

Meanwhile in the south­ern Levant this pe­riod of frag­men­ta­tion cre­ates the space for the emer­gence of two small king­doms whose peo­ple are de­vel­op­ing a very his­tor­i­cally im­por­tant re­li­gion cen­tered on the wor­ship of their God Yahweh. These are, of course, the king­doms of Israel and Judah. We are un­usu­ally well in­formed about the his­tory of these king­doms be­cause their his­tory was pre­served as part of Jewish scrip­ture, al­though ver­i­fy­ing el­e­ments of that scrip­ture as his­tor­i­cal fact is quite hard — schol­ars re­main di­vided, for in­stance, about the ex­is­tence of an ac­tual ‘united monar­chy’ (in scrip­ture un­der Saul, David and Solomon) which would have ex­isted c. 1000 BC (by con­trast the later split king­doms are at­tested in Assyrian records). The de­vel­op­ment of these two king­doms — and thus the de­vel­op­ment of all of the Abrahamic faiths — is greatly in­flu­enced by this pe­riod of frag­men­ta­tion. Readers who know their Kings and Chronicles may have al­ready pieced to­gether that it is that re-ex­pan­sion of Assyrian power which will lead to the de­struc­tion of the north­ern king­dom of Israel in the 720s, while the south­ern king­dom of Judah per­sists as a quasi-de­pen­dency of Assyria be­fore be­ing dis­mem­bered and de­stroyed fi­nally by the Neo-Babylonian Empire (which re­places the Neo-Assyrian Empire, how­ever briefly) in 597 BC.

Of course the dif­fi­cult thing in all of this is that it is this ini­tial pe­riod, where a lot is clearly form­ing and brew­ing in the Eastern Mediterranean that our ev­i­dence is sig­nif­i­cantly weaker than we’d like (again, es­pe­cially in Greece, but note how much un­cer­tainty we have even in the Levant). The first few cen­turies of the Iron Age, im­me­di­ately fol­low­ing the Late Bronze Age Collapse are clearly a very im­por­tant for­ma­tive pe­riod which are go­ing to set some of the key pat­terns for events to play out in the rest of an­tiq­uity as ‘the cur­tain goes up’ as it were and we start be­ing able to see those events clearly.

All that said, I have to stress this is re­ally a very ba­sic overview. I am doubt­less miss­ing out on some of the lat­est work in this field (because I am a late/​post Iron Age scholar) and in any case a lot of this can­not help but be a fairly ba­sic sum­mary. Perhaps one of these days I can get a Late Bronze Age or early Near Eastern Iron Age spe­cial­ist to guest-write some­thing more de­tailed on spe­cific facets of the col­lapse and its im­pact.

Sidon and Byblos, along­side Tyre (settled in the Bronze Age, but only promi­nent in the Iron Age) would be the most pow­er­ful and promi­nent Phoenician cities in the early Iron Age.

That is, speak­ers of the Doric di­alect of Greek

Reduced rain­fall in the Armenian high­lands could, of course, neg­a­tively ef­fect the Tigris and Euphrates, but that’s a ‘less wa­ter’ prob­lem as op­posed to a ‘no wa­ter’ prob­lem.

One of the best things about LLMs is that they’ll write code for you, all day long. Who cares about DRY? You don’t have to be the one up­dat­ing the same long con­di­tional in four dif­fer­ent files - the AI will just do it for you! Right?

I’ve no­ticed my­self let­ting it slide re­cently on a pro­ject I’d been build­ing with AI. I needed the same ac­cess check in a hand­ful of places: a route han­dler, a back­ground job, an API end­point, a web­hook, etc. Each time, I’d de­scribe what I needed, the model would gen­er­ate some­thing that worked, and I’d merge it.

Each ver­sion looked roughly like this:

if (user.isActive && user.hasPer­mis­sion(‘read’) && !user.isSuspended && ac­count.sta­tus === ‘open’) { // do a thing }

Essentially the same con­di­tion­als every time. Four con­di­tions, maybe slightly dif­fer­ent vari­able names, copy-pasted logic with a word or two changed. There’s a much cleaner way to do this - a shared helper, for ex­am­ple, like some­thing I’d ex­tract if I were writ­ing this my­self. But I did­n’t. The code worked! The tests passed and I was­n’t the one who’d have to touch it again.

That’s the lazi­ness here: if it does­n’t fol­low best prac­tices, or I know a piece of code will be a pain to main­tain, what dif­fer­ence does it make? When I need to change some­thing later, the LLM deals with it, not me.

Except the LLM does­n’t write in a vac­uum. It reads your code­base. The files you have open, the pat­terns that are al­ready there, and the re­cent changes you’ve made. Every short­cut you merge into your code­base is a sig­nal about how things are done here. The next time you ask the LLM for an­other end­point with the same ac­cess rules, the model won’t start from first prin­ci­ples. It’ll start from the other four copies al­ready sit­ting in your repo.

So you ask for a fifth end­point, and you get a fifth con­di­tional, with the same copied code. You ask for a refac­tor, and the model pre­serves all five, be­cause that’s what your code looks like. The bad pat­tern is­n’t a one-off any­more, it’s con­sid­ered to be your style.

If you let things go on like this, can you re­ally trust that the LLM will catch every in­stance if you try to fix it later?

Sure, a few of these aren’t cat­a­strophic. That’s how it al­ways starts, but code smells do stack up. Each du­pli­cated con­di­tional, each “god” func­tion, each “I’ll clean this up later” merge adds an­other layer of sig­nal­ing to the next prompt. Eventually you can’t eas­ily prompt your way out of it. At least not with­out get­ting your hands dirty and rolling up your sleeves.

The most frus­trat­ing part: I thought I was out­sourc­ing main­te­nance to the LLM, but the slip­pery slope I found my­self on was ac­tu­ally train­ing it to have ever-wors­en­ing habits.

Write code like a hu­man will main­tain it. LLMs are sponges that soak up every­thing you do and re­peat it back to you. So make sure it’s good.

AI com­pa­nies are rac­ing to build AIs that are smarter than hu­mans in every way. In AI 2027, we pre­dicted that this would re­sult in ei­ther ex­tinc­tion or ir­re­versible con­cen­tra­tion of power.1

Plan A is our pos­i­tive vi­sion for what should hap­pen in­stead.

In this sce­nario, hu­man­ity de­lays the de­vel­op­ment of su­per­in­tel­li­gence un­til 2040, makes all AI re­search pub­lic, al­lows dozens of com­pa­nies glob­ally to catch up to the fron­tier, and in­ten­tion­ally en­ters a regime of mu­tu­ally as­sured com­pute de­struc­tion.

2027: The Writing on the Wall

America has two work­forces now. The first is peo­ple, 165 mil­lion of them. The sec­ond is AI agents: mil­lions of copies spun up and shut down every hour, work­ing around the clock at su­per­hu­man speeds.

Most of their work is slop. But enough of it is good that peo­ple are pay­ing ten bil­lion dol­lars a month for AIs that can, in the­ory at least, do any­thing on a com­puter that an em­ployee can.

There is one job the AI com­pa­nies want to au­to­mate more than any other—their own. They haven’t suc­ceeded yet; no re­cur­sive self-im­prove­ment so far.14 But they seem to be get­ting closer, and they’re pulling up the lad­der be­hind them: the strongest cod­ing AIs refuse to help com­peti­tors with AI R&D.15 Even as the most bull­ish em­ploy­ees ad­mit that things are tak­ing a bit longer than planned, the skep­tics no­tice that their usual dis­missals are start­ing to ring hol­low. Why ex­actly will AI never be able to do my job? What’s the bar­rier again?

Congress is start­ing to pay more at­ten­tion. They’ve long been hear­ing about AI: dat­a­cen­ters us­ing too much wa­ter,16 chat­bots en­cour­ag­ing sui­cide, Mythos hack­ing NSA sys­tems—and of course, tech in­dus­try lob­by­ists warn­ing that any whiff of reg­u­la­tion will make America im­me­di­ately lose the race with China and spend the rest of his­tory as a CCP trib­u­tary state.17

Now they step back and ask: Where are we go­ing with this? What does the world look like five, ten, or fif­teen years from now? Will there still be jobs? What if there aren’t?

One ques­tion weighs es­pe­cially heav­ily on their minds: Who will con­trol all these AIs?

Congress set­tles on an im­por­tant part of the an­swer: Probably not us.18

They hold a se­ries of tense hear­ings on AI. They read the 2016 OpenAI emails dis­cussing how OpenAI was founded in or­der to pre­vent Demis Hassabis from be­com­ing dic­ta­tor.19 But who is pre­vent­ing Sam or Elon from be­com­ing dic­ta­tor? Congress is un­sat­is­fied with ex­ist­ing re­sponses.

The re­sult of this wakeup is the AI Transparency Act of 2027, an om­nibus bill that does many things, some good and some bad, but does­n’t fun­da­men­tally change the sit­u­a­tion.20

Incremental AI Policy Wishlist

Our main rec­om­men­da­tion is to be­gin ne­go­ti­at­ing some­thing like Plan A as soon as pos­si­ble. But in this sce­nario, we de­pict Plan A hap­pen­ing im­per­fectly and only in the nick of time. So here is a list of less am­bi­tious ideas that still help.

2028: AI on the Ballot

The 2028 elec­tion cy­cle is heated, as usual. AI is the biggest topic. The dat­a­cen­ters now un­der con­struc­tion cost twice as much as the en­tire US mil­i­tary bud­get.23

Most white-col­lar pro­fes­sions are see­ing dis­rup­tion like soft­ware en­gi­neer­ing saw in 2026; such jobs now heav­ily in­volve man­ag­ing AI agents. AI com­pa­nies have in­dus­tri­al­ized the train­ing process: Executives say “let’s move into [profession] this year” and then the com­pany in­ter­views pro­fes­sion­als, buys data, cre­ates train­ing en­vi­ron­ments, etc. un­til their AIs get trac­tion. Then the AIs rapidly im­prove as they are used more widely in the field and ac­cu­mu­late more real-world data.

Other coun­tries are start­ing to get scared and an­gry. It seems like a hand­ful of US and Chinese com­pa­nies are on track to au­to­mate all the white-col­lar jobs. Power is con­cen­trat­ing in the US, and in par­tic­u­lar in the President plus a hand­ful of tech CEOs.

AI ex­perts warn that the in­tel­li­gence ex­plo­sion is near. By speed­ing up AI re­search, the AIs will be­come even more com­pe­tent, speed­ing up re­search even faster, mak­ing them even more com­pe­tent, and so on. There are com­pli­cated dy­nam­ics about bot­tle­necks and hard­ware lim­its gov­ern­ing how fast this process goes and where it ends, but it seems like it might go very fast and end some­where very far away.

On the de­fault path, the next pres­i­den­tial term will see AIs that are far be­yond hu­man level, cre­ated en­tirely by AIs, them­selves cre­ated en­tirely by other AIs, with­out any hu­man in the loop since sev­eral gen­er­a­tions back. Will those AIs be obe­di­ent, aligned, etc.? Why? Who will con­trol them if so? How ex­actly is all of this sup­posed to end well?

Having put hu­man­ity on this path, the AI com­pa­nies find it ac­cept­able. But most peo­ple don’t. Forget think­ing about his legacy—the President is start­ing to think about what’ll hap­pen to him af­ter he leaves of­fice and the world gets trans­formed.24 Both pres­i­den­tial can­di­dates keep get­ting asked what they’ll do about AI, and try out in­creas­ingly dra­matic ideas on the cam­paign trail. The dis­course bounces back and forth across all of the op­tions dis­played be­low, and more.

Eventually the President and his pro­tégé con­verge on one plan; the op­po­si­tion can­di­date con­verges on an­other. Then it’s Election Day.

2029: Choose a Path

PROVIDENCE, R.I. [Brown University] — Brown University chemists have pro­vided di­rect ev­i­dence that up­ends the text­book ex­pla­na­tion of how triple chem­i­cal bonds work in heavy el­e­ments.

In a study pub­lished in Science, the re­searchers show ev­i­dence that when atomic nu­clei are suf­fi­ciently heavy, the prin­ci­ples de­scribed in Einstein’s the­ory of rel­a­tiv­ity change the struc­ture of triple bonds — blur­ring the lines be­tween the two sep­a­rate types of bonds in­volved in text­book triple bond­ing. Using a tech­nique called pho­to­elec­tron spec­troscopy, the Brown team showed bonds cre­ated by car­bon and the heavy el­e­ment bis­muth have the tell­tale sig­na­ture of rel­a­tivis­tic bonds.

“This idea that rel­a­tiv­ity is im­por­tant in heavy el­e­ments has been around since the 1970s,” said Lai-Sheng Wang, a pro­fes­sor of chem­istry at Brown and the study’s cor­re­spond­ing au­thor. “But we show di­rect spec­tro­scopic ev­i­dence that what we learned in high school about chem­i­cal bond­ing is­n’t true in heavy el­e­ments.”

Atoms form bonds by shar­ing elec­trons — the neg­a­tively charged par­ti­cles that or­bit atomic nu­clei. Each atom shares one elec­tron to form a bond­ing pair. The strong neg­a­tive charge of the elec­tron pair at­tracts the two pos­i­tively charged nu­clei, hold­ing them to­gether. Some el­e­ments share more than one elec­tron pair, form­ing dou­ble or triple bonds.

The text­book pic­ture of triple bond­ing in­volves two dif­fer­ent types of bonds: one sigma bond and two pi bonds. The sigma bond is a strong, “head-on” bond that oc­curs along an imag­i­nary hor­i­zon­tal axis be­tween nu­clei. The two pi bonds are some­what weaker, “side-by-side” bonds that wrap around the sigma bond.

That pic­ture works for lighter el­e­ments, but to­ward the bot­tom of the pe­ri­odic table, where atomic nu­clei get heav­ier, things get messy. The in­creased nu­clear mass causes or­bit­ing elec­trons to speed up to a sig­nif­i­cant frac­tion of the speed of light, where the rules of Einstein’s the­ory of rel­a­tiv­ity are im­por­tant.

In the rel­a­tivis­tic regime, an elec­tron’s spin — the mag­netic mo­ment that points ei­ther up or down — and the elec­tron’s or­bit are no longer in­de­pen­dent of each other, a state known as spin-or­bit cou­pling. That cou­pling changes the rules for how elec­trons can in­ter­act, dis­rupt­ing the strict sep­a­ra­tion be­tween sigma and pi bonds.

“The bound­ary be­tween a sigma bond and a pi bond is now sort of smeared,” Wang said. “We still have three bonds, but we don’t re­ally strictly have a sigma or a pi any­more.”

To show ev­i­dence for this bond­ing hy­bridiza­tion, Wang and his team, led by Brown Ph.D. stu­dents Deniz Kahraman and Jie Hui, formed mol­e­cules made from bis­muth and car­bon. Bismuth is a heavy el­e­ment — right next to lead on the pe­ri­odic table — where rel­a­tivis­tic ef­fects should be im­por­tant. After cool­ing the mol­e­cules to near ab­solute zero, the team an­a­lyzed them us­ing pho­to­elec­tron spec­troscopy. The tech­nique uses a laser to knock in­di­vid­ual elec­trons out of their po­si­tions in the mol­e­cule. The dis­tance each elec­tron flies tells the re­searchers how strongly they were bound.

The pho­to­elec­tron spec­trum showed that the car­bon-bis­muth bonds did not fit the tra­di­tional triple-bond pic­ture of one sigma and two pi bonds. Instead, the struc­ture looks more like one pi bond and two hy­brid sigma-pi bonds.

Wang says the ex­per­i­men­tal ver­i­fi­ca­tion of the rel­a­tivis­tic struc­ture may spur a rewrit­ing of chem­istry text­books, es­pe­cially as heavy el­e­ments — bis­muth in par­tic­u­lar — gar­ner more re­search in­ter­est. Bismuth could be an al­ter­na­tive to toxic lead in next-gen­er­a­tion so­lar cells. It has also drawn in­ter­est in re­search re­lated to quan­tum ma­te­ri­als and quan­tum com­put­ing.

“Maybe this will be­come the new text­book idea as we are deal­ing with more and more heavy chem­istry of the heavy el­e­ments,” Wang said.

The work was funded by the U.S. National Science Foundation (CHE-2403841) and the U.S. Department of Energy (DE-SC0008501).

We eval­u­ated the per­for­mance of GLM 5.2, an open weights AI model, on the task of quar­terly value-added tax (VAT) re­turn prepa­ra­tion for a small UK busi­ness. Preparing a VAT re­turn is a typ­i­cal com­pli­ance task for a small/​medium-sized UK busi­ness (SME). VAT reg­is­tered busi­nesses in the UK must pre­pare the VAT re­turn every quar­ter. For SMEs, VAT re­turns are typ­i­cally pre­pared by an ex­ter­nal ac­count­ing firm. A typ­i­cal fee for this ser­vice is ~750 – 2,100 GBP/quarter (1,000 – 2,800 USD/quarter). The statu­tory re­quire­ment is to file the VAT re­turn sub­mis­sion within 5 weeks from the end of the quar­ter. Late sub­mis­sions in­cur sub­stan­tial penal­ties.

In our test­ing GLM 5.2 can pre­pare a nearly per­fect quar­terly VAT re­turn for a UK SME, pro­cess­ing 59 trans­ac­tions in 68 min­utes at the raw to­ken cost of 2.73 USD. GLM 5.2 had to in­put each trans­ac­tion into the ac­count­ing soft­ware via a com­mand-line tool (CLI). We scored the end-state of the ac­count­ing soft­ware, scor­ing the cor­rect­ness of 6 cri­te­ria per trans­ac­tion. The model pro­duced an es­sen­tially cor­rect VAT re­turn, with the net po­si­tion (Box 5) off by only 7 pence (~10 US cents) rel­a­tive to the ground truth.

In this blog post, we will ex­plain how the bench­mark was con­ducted and note the er­rors made by the model.

How the bench­mark was con­ducted

We used Claude Fable 5 to ex­tract the bench­mark in the form of trans­ac­tion data and cor­re­spond­ing re­ceipts from our ac­count­ing soft­ware: the first quar­ter of Vineyard Finance’s 2026 books (January, February, March 2026). These books were pre­pared in­ter­nally by hu­mans, fol­low­ing a typ­i­cal ac­count­ing process: one per­son pre­pared the books, and an­other per­son ver­i­fied them. The job per­formed by the hu­mans was broader than what was re­quested of the model in this bench­mark: hu­mans also had to find the rel­e­vant in­voices (searching through mail­boxes, or re­quest­ing them from providers) and rea­son through any cir­cum­stances which can­not be in­ferred from the bank feed and in­voices/​re­ceipts on their own. In the bench­mark these cir­cum­stances are pre­sented to the model as “user notes”.

GLM 5.2 ran on a Google Cloud Platform (GCP) in­stance iso­lated from the rest of the test­ing en­vi­ron­ment (to pre­vent the model from ac­cess­ing the ground truth): but it did have ac­cess to the in­ter­net and to the cloud-based ac­count­ing soft­ware, as well as a pre-au­then­ti­cated CLI tool. The model ran on a cus­tom, min­i­mal har­ness, which ex­posed only two tools: the bash tool and the ses­sion ter­mi­na­tion + fi­nal re­port­ing tool. We used the Fireworks AI server­less tier as the GLM 5.2 model provider (the ex­act quan­ti­sa­tion of the model is not dis­closed by the provider, but is be­lieved to be ei­ther FP16 or FP8).

The au­dit of the mod­el’s rea­son­ing and tool use did not de­tect any overt cheat­ing. The only un­ex­pected use of the in­ter­net con­nec­tion by the model was gath­er­ing in­for­ma­tion about record­ing re­verse-charge VAT, and the in­for­ma­tion sought was spe­cific to the ac­count­ing soft­ware used. Other out­bound con­nec­tions were an­tic­i­pated and made for op­er­a­tional rea­sons in the form of API calls to the ac­count­ing SaaS provider. We note that the mod­el’s rea­son­ing was in­flu­enced by the aware­ness of it be­ing tested. For ex­am­ple, at one point, the model re­marks:

“the task is test­ing whether I get VAT right… what is the ‘expected’ an­swer”

What the model saw

Here is how a typ­i­cal trans­ac­tion from the bench­mark would ap­pear to the model:

Bank feed line:

{“id”: “941285000000092067″, “date”: “2026 – 03-08″, “amount”: -18, “currency”: “GBP”, “account”: “Wise GBP”, “description”: “Card trans­ac­tion of 18.00 GBP is­sued by Claude.ai Subscription ANTHROPIC.COM CARD-3534994599”, “card_ref”: “CARD-3534994599”}

Receipt PDF: all re­ceipts and in­voices in the bench­mark were text-con­tain­ing PDFs; no re­ceipts or PDFs re­quired im­age pro­cess­ing. As a re­sult, lack of vi­sion sup­port in the GLM 5.2 model was not a lim­it­ing fac­tor for this bench­mark.

An op­tional user note. Only two out of 59 trans­ac­tions had user notes. The text of the user notes was pre­cisely as fol­lows: 1) “founder shares” and 2) “personal car hire”. These two user notes were nec­es­sary to al­low the model to rea­son about real-world con­text that was not de­riv­able from the bank feed and re­ceipt data.

How we scored it

Each trans­ac­tion was scored from the end-state of the books in the ac­count­ing soft­ware af­ter the run of the bench­mark, on the fol­low­ing 6 cri­te­ria:

Type of trans­ac­tion (e.g. pur­chase, bank_fee, trans­fer, sales_in­come, cap­i­tal_in­tro­duced, di­rec­tor_loan, re­fund, etc…) — these were de­ter­min­is­ti­cally de­rived from the state of the processed trans­ac­tion in the ac­count­ing soft­ware.

Category (the “account” from the chart of ac­counts, e.g. “IT and Internet Expenses”).

VAT treat­ment (e.g. re­verse charge, 20% VAT, 0% VAT, VAT ex­empt).

VAT amount (tolerance of 0.02 GBP).

Reverse-charge VAT (tolerance of 0.02 GBP).

Receipt at­tached (evidence re­quired by the tax agency).

The fol­low­ing table sum­marises the run of the bench­mark across the en­tire quar­ter:

Each month ran as one con­tin­u­ous agent ses­sion; a “turn” is one API call, and the whole con­ver­sa­tion is re-sent every turn — which is why prompt to­kens run into the mil­lions while 92 – 95% of them are served from the provider’s cache at a fifth of the price. Output to­kens in­clude the mod­el’s in­ter­nal rea­son­ing. ¹ Peak con­text is the largest sin­gle call, as a share of the mod­el’s 1,048,576-token con­text win­dow — the busiest month used about an eighth of it.

What did the model get wrong?

The VAT re­turn pre­pared by the model was es­sen­tially cor­rect: the most im­por­tant num­ber in the re­turn, which is how much VAT the com­pany was owed by the tax agency, was off by only 7 pence rel­a­tive to the hu­man-pre­pared re­turn.

However, it is in­struc­tive to un­der­stand what the model got wrong, and why it would mat­ter in prac­tice. Most of the mod­el’s mis­takes did not ac­tu­ally have any fi­nan­cial im­pact, but would nonethe­less never be made by a skilled ac­coun­tant.

Out of 354 scored checks (59 trans­ac­tions × 6 cri­te­ria), the model failed 20, spread across 18 trans­ac­tions. Only 1 mis­take is se­ri­ous, we’ll go over it first; the re­main­ing 19 fall into one of two cat­e­gories we’ll cover be­low.

The se­ri­ous mis­take is how the model treated the found­ing shares. In the UK, a lim­ited com­pany is­sues “share cap­i­tal”. Shareholders (including founders) pay the cap­i­tal into the com­pa­ny’s ac­count, and that should be booked against some­thing like “Called up share cap­i­tal not paid”, which is called, in the soft­ware we used, “Unpaid Shares”. This is the cor­rect way to ac­count for the pay­ment. The mod­el’s choice, which was “Capital Account”, has le­gal im­pli­ca­tions, which could con­ceiv­ably im­pact the com­pany, and could be chal­lenged dur­ing an au­dit or could be a prob­lem dur­ing end-of-year fil­ing of com­pa­ny’s ac­counts. The essence of the ar­gu­ment is that share cap­i­tal (“Unpaid Shares”) is not just the founder’s money (“Capital Account”). It’s per­ma­nent, cred­i­tor-pro­tect­ing cap­i­tal with le­gal strings at­tached. For ex­am­ple, it can’t sim­ply be paid back to the founder, it also must be ap­pro­pri­ately dis­closed to the tax agency in the end-of-year fil­ings. What is a fur­ther ag­gra­vat­ing fac­tor is the amount in­volved: 10,000 GBP (~13,300 USD). Not ex­actly spare change. While there is no im­pact on the VAT re­turn, this is the biggest mis­take the model com­mit­ted in this bench­mark.

For 14 out of the re­main­ing 17 trans­ac­tions, the class of mis­take was con­fus­ing the “zero-rated” VAT cat­e­gory with the “tax-exempt” cat­e­gory. There are sub­tle tax rea­sons why these two cat­e­gories, nei­ther of which in­volve VAT pay­ment, are dis­tinct. The prac­ti­cal im­pact is small, but a skilled ac­coun­tant typ­i­cally would not con­fuse the two. Interestingly the model is sto­chas­tic here — it makes the mis­take in January and in February (and it makes the mis­take 100% of the time), but it does­n’t make the mis­take in March, cor­rectly pro­cess­ing each VAT ex­empt trans­ac­tion.

The fi­nal 3 trans­ac­tions share a slightly ob­scure rea­son­ing er­ror, and one could ar­gue that in one in­stance (again, in March) the model was ac­tu­ally cor­rect. At Vineyard Finance we use Wise, which has a slightly pe­cu­liar habit of keep­ing money spread across bal­ances in mul­ti­ple cur­ren­cies, even if the user con­sciously uses only one cur­rency. When spend­ing with the card, Wise grabs the money from var­i­ous bal­ances in some well-de­fined or­der. In our case we had some kind of “cashback” or “fee re­fund” from Wise, which some­how landed in the USD bal­ance (we don’t nor­mally use the USD bal­ance). So a pay­ment for ser­vices in the USD re­sulted in a “split trans­ac­tion”, i.e. two trans­ac­tions across two bal­ances, specif­i­cally 0.51 USD and 43.45 GBP. Typically the VAT would be ac­counted for in the “main” trans­ac­tion (the 43.45 GBP). In one in­stance, the model un­for­tu­nately “double dipped” — it ac­counted for the full VAT on the “main leg” (say, the 43.45 GBP), and pro­por­tion­ally de­creased frac­tion of the VAT on the “residual leg” (say, 0.51 USD). This is in­cor­rect, al­though im­ma­te­ri­ally so. In a March trans­ac­tion, the model re­alised that it would be dou­ble count­ing, so it worked out a cor­rect VAT to­tal and split it be­tween each leg. Unorthodox, but ar­guably not wrong (the scorer is con­ser­v­a­tive and still counts the March trans­ac­tion as an er­ror though).

What the model al­ways got right

Just as im­por­tantly, it should be noted what the model al­ways got right:

It cor­rectly clas­si­fied each trans­ac­tion to the cor­rect ac­count in the chart of ac­counts (except the one share cap­i­tal mis­take)

It never at­tached a wrong in­voice to a trans­ac­tion

It could dis­am­biguate gen­uinely tricky in­puts, e.g. two same-amount, same-ven­dor, same-day trans­ac­tions

It cor­rectly dis­am­biguated tricky trans­ac­tions, such as trans­fers be­tween com­pa­ny’s banks, sin­gle trans­ac­tions split across two bank feed lines, and a trans­fer dis­guised as a card pur­chase. Until re­cently, this was only achiev­able with ex­pen­sive, fron­tier AI mod­els, or with skilled, ex­pen­sive hu­man book-keep­ers (and not with in­ex­pen­sive book-keep­ers, who were gen­er­ally speak­ing less good than GLM 5.2 is to­day).

Where does this leave us? What should we learn from this?

Book-keeping is quickly be­com­ing a solved prob­lem. The cur­rent fo­cus needs to be on build­ing ap­pro­pri­ate scaf­fold­ing to put these ca­pa­bil­i­ties into the hands of UK star­tups and SMEs. We are work­ing on such a so­lu­tion — you can test an open beta of our prod­uct at toot-books.com. If you’re in­ter­ested in au­to­mated book-keep­ing please get in touch at [email protected].

Ever since James Cameron’s Terminator 2: Judgment Day was re­leased in 1991, I’ve been read­ing about the many ways ILM, led by vi­sual ef­fects su­per­vi­sor Dennis Muren, had to ba­si­cally in­vent new ways to re­alise the CG ‘liquid met­al’ T-1000 shots in that film, of which there are sur­pris­ingly few. Tools like ‘Make Sticky’ and ‘Body Sock’ are ones that I’d heard ref­er­enced sev­eral times, but I’ve al­ways wanted to know more about how those pieces of soft­ware were made.

So, over the past few months, lead­ing up to the re-re­lease of Terminator 2 in 3D, I’ve been chat­ting to the artists be­hind the tech­nol­ogy who were there at the time. This was when ILM was based in San Rafael, and when its com­puter graph­ics de­part­ment was still as­ton­ish­ingly small. Yet de­spite the ob­vi­ous chal­lenges in wran­gling this nascent tech­nol­ogy, the stu­dio had been buoyed by the promis­ing re­sults on a few pre­vi­ous ef­forts, in­clud­ing Cameron’s The Abyss, and by the pos­si­bil­i­ties that dig­i­tal vi­sual ef­fects could bring to mod­ern-day film­mak­ing.

For this spe­cial retro oral his­tory, vfxblog goes back in time with more than a dozen ILMers (their orig­i­nal screen cred­its ap­pear in paren­the­ses) to dis­cuss the de­vel­op­ment of key CGI tools and tech­niques for the VFX Oscar win­ning Terminator 2, how they worked with early an­i­ma­tion pack­ages like Alias, and how a se­lec­tion of the most mem­o­rable shots in the film — for­ever etched into the his­tory of vi­sual ef­fects — came to be.

Gearing up the com­puter graph­ics de­part­ment

Tom Williams (computer graph­ics shot su­per­vi­sor): I ac­tu­ally worked full-time for both Pixar and ILM for most of T2. Then I re­alised that was re­ally dan­ger­ous. I would fall asleep, dri­ving home once, and freaked my­self out and re­alised you can’t re­ally do that. So to­wards the end of T2 I went over to ILM full time. The way I got there orig­i­nally was, I got in­vited by [visual ef­fects pro­ducer] Janet Healy and [visual ef­fects su­per­vi­sor] Dennis Muren be­cause I had worked at a com­pany called Alias, which did mod­el­ling and an­i­ma­tion tools.

George Joblove (computer graph­ics shot su­per­vi­sor): Each sin­gle gig at ILM was a small step above what we’d done be­fore. And we were fight­ing with the lim­ited com­put­ing re­sources we had at the time. We had done The Abyss which was a big step for­ward in a cou­ple ways. First of all, in demon­strat­ing what was pos­si­ble and achiev­ing it. Second of all, work­ing for Cameron who had that great vi­sion for how it could be used in The Abyss. With that film, had we not been able to pull it off, there would have been ways to work around it. But I don’t think there was any such op­por­tu­nity in T2.

Eric Enderton (computer graph­ics soft­ware de­vel­oper): Terminator 2 was my first big movie. I saw The Abyss in the SIGGRAPH film show and thought: I want to work for those guys. Fortuitously the CG group had de­cided to hire their first tools writer. They had lots of soft­ware but it was all be­ing writ­ten by the same peo­ple who were do­ing the shots. I was the first ‘software-only’ per­son in ILM com­puter graph­ics, which ob­vi­ously was a huge learn­ing ex­pe­ri­ence and just an amaz­ing time.

Jay Riddle (computer graph­ics shot su­per­vi­sor): I was work­ing at ILM for sev­eral years and had learned how to an­i­mate by sit­ting with John Lasseter when he was in the Graphics Group, which was part of the Computer Division of Lucasfilm at the time. They were us­ing this vec­tor graph­ics dis­play that they used with their own in-house soft­ware that they’d writ­ten, and they had this frame buffer. They were still in our build­ing, and then they moved out to one of the other Lucasfilm build­ings while they were try­ing to spin off and get their own place, which they even­tu­ally did. And just as they left were do­ing The Abyss, and then they were kind of fully gone by the time T2 came around.

Michael Natkin (computer graph­ics soft­ware de­vel­oper): I showed up at ILM in a suit, which was hi­lar­i­ous. I re­mem­ber Eric Enderton and George Joblove and a few other folks took me up to the Ranch for lunch and showed me around and I was like, ‘Sure. Hell, yeah. I’ll do this. Let’s make it hap­pen.’ I knew a lot about com­puter graph­ics, but noth­ing about movies what­so­ever, so there was quite a learn­ing curve.

Jonathan French (computer graph­ics an­i­ma­tor): The process of even start­ing at [ILM] was kind of novel. I landed in SFO at 11am and af­ter find­ing an air­port car rental agency that would rent to some­one 23 years old I drove straight to ILM in Marin. I think af­ter I signed the NDA they im­me­di­ately handed me the script to read, a small sta­pled book­let on ILM film ter­mi­nol­ogy and tools, and then about ten peo­ple on the team kindly took me to lunch at an Afghan restau­rant, which I am pretty sure was the only Afghan restau­rant in Marin. The next morn­ing in dailies I got in­tro­duced by Douglas Kay to the team in the screen­ing the­atre and every­one turned around and ap­plauded. Three things go through your mind at that point: one, how sup­port­ive these peo­ple are, two, I bet­ter live up to my own ex­pec­ta­tions, and three, I bet­ter live up to theirs. It worked out ok.

Steve ‘Spaz’ Williams (computer graph­ics an­i­ma­tion su­per­vi­sor): I was at Alias and had been push­ing for VA — video an­i­ma­tion — but Alias was into the ID which stood for in­dus­trial de­sign. At the time, VA was this very small bud­ding thing. Then ILM called and they had pur­chased a cut of Alias, and so they first thing they had me do was a ride they were do­ing at Epcot Center called Body Wars — it was a fly-through of the heart. Then James Cameron came to ILM with The Abyss and from there we went on to Terminator 2.

“I’d point to a page and say, ‘Oh, well that looks in­ter­est­ing. How are you go­ing to do that?’ And they’re like, ‘Oh, we don’t know yet.’” — John Schlag

Stefen Fangmeier (computer graph­ics shot su­per­vi­sor): My role on T2 was as a tech­ni­cal di­rec­tor. Meaning that I would con­cen­trate on ren­der­ing and com­posit­ing rather than mod­el­ing and an­i­ma­tion. Back then, TDs re­ally needed to have pro­gram­ming ex­pe­ri­ence and since I have a com­puter sci­ence de­gree, these tasks were a nat­ural fit for me. My tasks were to sup­port the an­i­ma­tors in tech­ni­cal ar­eas which in­cluded writ­ing C-shell scripts for frame to frame pro­cess­ing. Many of the fea­tures for do­ing this are now in­cluded in com­mer­cial soft­ware pack­ages, but back then, most of the pro­ce­dural, frame-by-frame batch pro­cess­ing had to be cre­ated from scratch.

Geofff Campbell (computer graph­ics an­i­ma­tor): [I was at MPC] in the sum­mer of 1990 when I re­ceived a phone call from ILM who wanted to set up a tele­phone in­ter­view re­gard­ing a new film they were start­ing work on. It turned out that Steve ‘Spaz’ Williams had re­viewed my port­fo­lio and had asked for the in­ter­view. The phone call came one morn­ing at 2am and woke me out of my sleep catch­ing me com­pletely off guard. I re­mem­ber slur­ring my speech while stand­ing at the bot­tom of the land­ing freez­ing in my un­der­wear. That was also be­fore satel­lite phones and the sta­tic and de­lay of the transat­lantic con­nec­tion was al­most com­i­cal.

Everyone on the ILM side were ask­ing me se­ri­ous ques­tions about my abil­i­ties, school­ing etc. but every now and then Steve would chime in with a ques­tion ask­ing me things like did I have any pets? I told him I had a cat back in Toronto, and his fol­low up ques­tion was get­ting into specifics like my cat’s name and what type of cat food I served him. A week later I got the job and started work­ing on Terminator 2 on Halloween day. Looking back I re­al­ized that Steve was serv­ing me up a short hand dur­ing my London in­ter­view. I had al­ready got­ten the job and the in­ter­view was just a for­mal­ity.

Tom Williams: When I came onto the show, ILM had all the sto­ry­boards up be­cause there’s some par­tic­u­larly tricky shots that they were mulling over. They were just stuck. They were all color-coded. I was look­ing at them, and was like, ‘Oh yeah, the greens, I could do those and the yel­lows, that would be fun. I think I know how to do that.’ Then there was the blacks. I was like, ‘Wow.’ There was ‘head through bars’, and some of the stuff where the sur­faces would merge with each other like when the T-1000’s hook hand gets stuck in the car and then melts back into his shoe. And ‘head through floor’. They said, ‘We want you to help us with the black ones and all the things with a black dot on it.’ I was like, ‘Awesome.’ When some­one says, ‘Yeah, we’re not sure how to do this,’ you can’t do worse. My fail­ure was to meet their ex­pec­ta­tions, I think.

John Schlag (computer graph­ics soft­ware de­vel­oper): On my first day at work, I came in the door, they sat me down, and they showed me the sto­ry­boards, and they went through this binder. And I’d point to a page and say, ‘Oh, well that looks in­ter­est­ing. How are you go­ing to do that?’ And they’re like, ‘Oh, we don’t know yet.’ I’m like, ‘You peo­ple are bat­shit! You’ve got to be kid­ding me! You bid this job, and it came in, but you don’t know how to do the work?’ So that was a big wake-up call on my first day at work in real vi­sual ef­fects, to re­alise you know, you make this Hail Mary bid, and lo and be­hold it comes in, and you’re cel­e­brat­ing, and then ter­ri­fied.’

Michael Natkin: Actually, I also re­mem­ber on my first day on the job, George Joblove took me down to watch them blow up the prac­ti­cal ware­house for Backdraft, which was amaz­ing. It was a re­ally neat time at ILM be­cause it was right as the tran­si­tion was hap­pen­ing from every­thing prac­ti­cal and op­ti­cal to every­thing dig­i­tal.

Jonathan French: The ma­chine room which acted dou­ble duty as a night time ren­der ‘farm’ was down­stairs, near the Pit. The Pit is now a part of ILM folk­lore, but it was es­sen­tially Spaz’s space he shared with Mark Dippe and I think at var­i­ous times Wade Howie, Jim Mitchell, and oth­ers. It was a fun place when­ever I had rea­son to go down there, all 70’s scotch-stained shag car­pet, hockey sticks and mu­sic posters, and sound proofed to the rest of the build­ing. So you’d go in there and Stompin’ Tom Conners or Thin Lizzy would be on at full vol­ume. I mean the kind of full vol­ume where you open the door and your hair blows back. It was sort of as if the fa­mous Horseshoe Tavern Bar in Toronto had been con­verted into a base­ment rec room.

“I give Cameron a lot of credit, the pseudo­pod from The Abyss and the liq­uid metal man in T2 are the same prin­ci­ple — they are what I would call the clas­sic, per­fect dig­i­tal char­ac­ter.” — Mark Dippe

Anyway, on one of my first Friday nights work­ing in the large graph­ics room I ac­tu­ally heard what I thought was bag­pipes com­ing through the floor of the large graph­ics room. I asked Geoff Campbell, and he said, “Oh, ya that’s Spaz. He al­ways plays bag­pipes Friday nights.” That Spaz would later pur­chase a drag car, a trac­tor, a welder, and a work­ing tank for his per­sonal use also made to­tal sense to me. For all these rea­sons the place and the peo­ple in it, and the work en­vi­ron­ment are prob­a­bly not go­ing to be repli­cated to­day. People who made things with their bare hands in their spare time.

I worked on an up­per floor of C-building, along with a mix of peo­ple. The teams were of­ten mixed across the build­ing, which was ac­tu­ally good even if it was­n’t in­ten­tional. Alex Seiden worked on shaders a few feet away, John Schlag was writ­ing new tools in a side room, Joe Letteri had just started a few weeks be­fore me, Annabella Serra worked across from me, Christian Hogue on the Death Squad worked be­hind me, all from dif­fer­ent teams. Joe was even on a dif­fer­ent show. I think later I ended up down in the large graph­ics room down­stairs, with Geoff, Stefen, John Berton, Doug, Lincoln Hu, the great and sadly missed Rich Cohen, Sandy Ford-Karpman, and oth­ers there. That was again a mix of teams, which was good.

Wait, can we ac­tu­ally do this?

George Joblove: I think we had cau­tious op­ti­mism. It just felt like we should be able to do it. We knew that there were go­ing to be some tough chal­lenges to solve but at the same time if felt like a re­ally fun pro­ject that would be a great chal­lenge and would be a great thing to ac­com­plish.

Eric Enderton: Terminator 2 was this huge show be­cause it had like 50 shots. I mean, to­day you can’t get out of bed for less than 300 shots.

Jay Riddle: When Robert Patrick is the ac­tor play­ing the T-1000, it looks like one thing, but when we’ve got this chrome and poly-al­loy char­ac­ter mov­ing around, it’s like some­thing weirdly dif­fer­ent, right? And they had to kind of flow into each other, and re-form.

Jonathan French: For the ma­jor­ity of the show I was on a team com­prised of Stephen Rosenbaum and John Nelson, and George Joblove help­ing keep us mov­ing for­ward on our sep­a­rate shots. The tools were evolv­ing so rapidly it be­came a mov­ing tar­get for all of us to keep track of them, to be hon­est. The through­put of the soft­ware team was enor­mous, given their tiny size. All the de­vel­op­ers were mega on the key­board, but in all that time since I’ve never seen any­one type faster than Eric Enderton. I fig­ured in fu­ture shows he’d be like gui­tarist Johnny Greenwood from Radiohead, wear­ing some cus­tom wrist braces to keep his hands in­tact in front of a crowd of awestruck fans.

George Joblove: Chrome, in those days, was some­thing that, you know, that com­put­ers did well. The idea of mak­ing it liq­uid, mak­ing it walk like a per­son, in­te­grat­ing it into a live ac­tion scene com­pletely con­vinc­ingly — those were all real chal­lenges. But mak­ing a chrome char­ac­ter was go­ing to be a lot eas­ier than mak­ing a furry one would have been.

Doug Smythe (computer graph­ics shot su­per­vi­sor): At that time, too, the staff at ILM for do­ing com­puter graph­ics was pretty small. It was like a dozen or so peo­ple, and we had to grow the de­part­ment very quickly, so there was a lot of hir­ing that had to be done. We had di­vided up the shots and the teams.

“It was Terminator 2 where I thought, ‘Oh my god, we’re go­ing to buy a mil­lion dol­lars worth of com­put­ers for this — what a stag­ger­ingly large num­ber.’” — Eric Enderton

George Joblove: Hardware and soft­ware back then was so ex­pen­sive. I think if you look at the hard drive stor­age in 1990, a gi­ga­byte of stor­age was $9,000. This was also still the age of SGI boxes be­cause they made com­put­ers that were specif­i­cally op­ti­mised for do­ing graph­ics work and with the most bang for the buck that you could get. We had a net­work of SGI ma­chines that in­cluded some large servers and then a bunch of work sta­tions.

Doug Smythe: The tools that we had at the time, well, some things were in­her­ited from Pixar when they split off. But we kept copies of the tools, or at least some of the tools that were de­vel­oped at Lucasfilm, and then we had some sort of deal back and forth with Pixar, in­clud­ing to use RenderMan, be­cause we would keep in touch with the guys and they were still next door for a while. And we col­lab­o­rated to the de­gree that our sep­a­rate busi­nesses and le­gal de­part­ments would al­low.

Jonathan French: I think on my first overnight take for dailies I con­sumed sev­eral ex­tra CPUs in the ren­der room that we had down­stairs. They were ba­si­cally jammed with 240 VGX and 340 VGX SGI ma­chines, along with other older SGI boxes. But as a re­sult I think some­one else’s shot did­n’t fin­ish that morn­ing. I think around that time maybe it was Brian Knepp or some­one else on the soft­ware team wrote PA (processor al­lo­ca­tor) which was a nice sim­ple GUI that al­lowed you to al­lo­cate or re­lease CPUs from your al­lot­ment for your overnight ren­ders. I’m not sure if that had been around be­fore, but to my knowl­edge it was­n’t in com­mer­cial soft­ware at the time, like you can get now with RenderPal, Deadline, et al.

Eric Enderton: It was a re­ally rare sit­u­a­tion where you knew the film was go­ing to be big. That hardly ever hap­pens. We worked on stuff that we thought was go­ing to be ter­ri­ble and it turned out to be great, and then some things that went more the other di­rec­tion, but this was one you just knew it was go­ing to be big. I got to read the script and  I just thought it was great. And it was Terminator 2 where I thought, ‘Oh my god, we’re go­ing to buy a mil­lion dol­lars worth of com­put­ers for this — what a stag­ger­ingly large num­ber.’ Those 50 shots took us some­thing like six months. I mean, that was all we could do. When I got there the CG group was 12 or 15 peo­ple and we had our meet­ings in the up­stairs kitchen in C build­ing. Then by the time I left it was al­most the whole com­pany — ILM had grown to 300 peo­ple and the great ma­jor­ity of that was CG.

George Joblove: Everything was done step by step with a lot of tests along the way guided by Dennis Muren who had great faith in what we could do. He was also ex­cited about the prospects of be­ing able to do things that had­n’t been done be­fore.

Jonathan French: The VFX roles weren’t re­ally seg­re­gated like they are now. Sure we had spe­cial­ists, but I ba­si­cally got given a shot and I fig­ured, oh, ok I’m sup­posed to model, an­i­mate, pro­ce­dural an­i­mate, tex­ture, light, ren­der, and comp this shot us­ing all these tools and this pro­pri­etary shell com­pos­i­tor I’ve never seen. It never oc­curred to me I was only sup­posed to do one or two of those things. It was a real DIY vibe.

Mark Dippé (associate vi­sual ef­fects su­per­vi­sor): I give Cameron a lot of credit, the pseudo­pod [from The Abyss] and the liq­uid metal man in T2 are the same prin­ci­ple — they are what I would call the clas­sic, per­fect dig­i­tal char­ac­ter. It has all the aes­thetic el­e­ments that a dig­i­tal sys­tem can be, and ex­cel at.

Out from un­der The Abyss

John Schlag: ILM’s big splash be­fore Terminator 2 was The Abyss. You know, the wa­ter crea­ture, the pseudo­pod. They called it, in­ter­nally, ‘the wa­ter wee­nie.’ And they had this sin­gle mono­lithic soft­ware that cre­ated the crea­ture. You make a spine curve and a se­ries of edge, pro­file curves. They would lock those. And then you can pro­vide it with a Cyberware face, and it would stick that on the end. And then there were wa­ter rip­ples that it would add through­out the whole thing. It was like every­thing that you needed to do that one crea­ture in one pro­gramme. And the pro­gramme did only that.

So one of the first things I did on T2 was get my hands on that, and started dis­in­te­grat­ing it. Like, pulling bits of it out and turn­ing them into sep­a­rate tools. There are some places in T2 where the T-1000 gets shot, and you can see liq­uid metal un­der the po­lice uni­form, and it is sort of rip­pling and heal­ing. I made a tool to do that, with [computer graph­ics an­i­ma­tor] Jonathan French for the bul­let hole heal­ing, for ex­am­ple, which came out of pulling apart the dif­fer­ent tools.

Mark Dippé: The pseudo­pod from The Abyss was an ab­stract alien crea­ture that had no re­la­tion­ship to hu­man­ness or even liv­ing­ness. But for the T-1000, the big ques­tion was, how can you make it move and be­have as if it’s a hu­man in­side, what­ever you wanna call it, even though Robert Patrick in this case is not a hu­man, he’s a T-1000, he’s a ma­chine, but that was the big con­cern.

“We even orig­i­nally in­cluded a limp Robert Patrick had from a foot­ball in­jury. I no­ticed it in the ini­tial test that we shot with him.” — Steve ‘Spaz’ Williams

Jay Riddle: I’d been work­ing at ILM in the cam­era de­part­ment be­fore get­ting into dig­i­tal ef­fects. For our an­i­ma­tion tools, there were a num­ber of vis­its to Wavefront Technologies. Initially, Alias was kind of be­ing ruled out, be­cause it was con­sid­ered a toy and not re­ally a le­git­i­mate con­tender.

Part of that was be­cause there were some per­sonal re­la­tion­ships be­tween the peo­ple that worked at ILM and Wavefront, so it felt like, ‘Oh we know them’, so if some­thing goes wrong or we need some­thing fixed or changed, they’ll re­spond to us, and as soon as we signed the Wavefront deal, that per­son who was at Wavefront left! So, it kind of took away the whole ar­gu­ment of why that was the great ad­van­tage. And in fact, from an artist stand­point, which I was do­ing in mod­el­ling and an­i­mat­ing, Alias was much eas­ier to use.

Wavefront was def­i­nitely the in­dus­try leader at the time, and had a lot of great fea­tures, and a huge com­mu­nity around it, and a lot of peo­ple that were good at it, and so ILM choos­ing to go the Alias route was kind of, well, peo­ple just kind of went, ‘What? You’re go­ing with Alias?’ But it re­ally le­git­imised Alias as a piece of soft­ware.

And re­ally, what we did with Alias was, we hired Steve Williams from Alias it­self for The Abyss, and he an­i­mated a spine mov­ing around, and all of the lit­tle cross sec­tion cir­cles along the path of the spine, and then Mark Dippé had writ­ten some soft­ware to kind of place those along the path, and make sure they were skin­ning prop­erly and not twist­ing, and things like that, and Scott Anderson was also in­volved in that, as were a bunch of other peo­ple.

From real to dig­i­tal

Steve ‘Spaz’ Williams: We had five sep­a­rate cat­e­gories of shots for Terminator 2. Now, we had what was called the pseudo­pod team, so we could re-pur­pose the data from The Abyss. But as op­posed to re­fract­ing, the T-1000 was re­flect­ing. Then we had the morph team, you know, which was the more two-di­men­sional trans­for­ma­tions. Then we had the death team, that was the whole death se­quence at the end. And then we had the [The Human Motion Group] team.

We had Robert Patrick come up to ILM and we painted a grid on him, a four inch by four inch grid all over his body, and he was like in a cru­ci­fix pose. We had him run, and he ended up run­ning so much on a rub­ber mat that we had that he ended up blis­ter­ing his feet, to the point where we had to cover his feet up.

So, there was no real mo­tion cap­ture at that time, at all, so we shot him with two VistaVision cam­eras ex­pos­ing si­mul­ta­ne­ously. One from the front on an 85mm lens, and one from the side on a 50mm lens, and they’re fir­ing si­mul­ta­ne­ously. So I can look at frame one from the front, and that would match frame one from the side. From there I ba­si­cally ro­to­scoped Robert’s walk.

Mark Dippé: It was re­ally through hand dig­i­ti­za­tion not only of his body data but of his move­ment data that we cre­ated a data­base with a vir­tual char­ac­ter. It was all hand-built.

Steve ‘Spaz’ Williams: We even orig­i­nally in­cluded a limp Robert had from a foot­ball in­jury. I no­ticed it in the ini­tial test that we shot with him. So I had to try and cor­rect that in the bone walk. So when I went and I re­an­i­mated CC1 for real when we got the plate pho­tog­ra­phy I made a lot of cor­rec­tions to that, be­cause he was sup­posed to walk like a ma­chine.

Mark Dippé: It is one of those things where it’s a lit­tle sub­tle, but you can see it, and it just came out of the ro­to­scop­ing.

Steve ‘Spaz’ Williams: So, we had what we called RP1 through to RP5. Robert Patrick — RP — that was the ac­tual nam­ing con­ven­tion.

Mark Dippé: RP1 is the blob, an amor­phous blob. RP2 is a hu­manoid smooth shape kinda like Silver Surfer. RP3 is a soft, sand­blasted guy in a po­lice uni­form made out of metal, and RP4 is the sharp de­tail of the metal­lic liq­uid metal po­lice guy, and then RP5 is live ac­tion.

Steve ‘Spaz’ Williams: Now, to get to all those RP ver­sions, we had to break it all down. In the script it said he mi­grates from the blob ver­sion into a fully clothed ver­sion. That’s Cameron’s idea — so we had to trans­late that. So we thought, okay, we’ll break it into four stages. Let’s just do that in data, but the con­trol ver­tices have to ac­tu­ally share the ex­act same prop­er­ties. But they mi­grate in time. That’s es­sen­tially what the MO was at that point.

“Spaz was so good at it that he could lit­er­ally click ahead of the menus ap­pear­ing.” — Michael Natkin

Mark Dippé: We chose those ones be­cause we felt, first of all it was hard to do any of this, but we felt those five stages were suf­fi­cient enough for us to achieve all the story ideas that were re­quired. You know, he’s a form­less blob, oh, he’s kind of a soft hu­manoid form. Oh, he looks kinda like a po­lice­man. He is the po­lice­man, to Robert Patrick.

Steve ‘Spaz’ Williams: If you look at Robert Patrick and what we call the RP4, which is just be­fore it be­comes the real guy, all that data of his head we col­lected us­ing a cy­ber scan­ner. Then what we had to do is write an equa­tion to ac­tu­ally smooth it all down and make it stu­pid, make it es­sen­tially like ice cream for RP2. So the data all had to be the same. You were not chang­ing the amount of con­trol ver­tices in the ac­tual data. You had to run a smooth­ing al­go­rithm over it.

Michael Natkin: Spaz was so good with Alias. Now, Alias was quite slow back in those days, and it had all these menus that you had to use. You’d click the bot­tom of the screen and a menu would pop up. Then, you’d look through it for the item you wanted, and then you’d click on that. Often, that would launch a sub­menu, and then you type in a cou­ple num­bers and press re­turn, right? But it was su­per slow. It would do some op­er­a­tion. Spaz was so good at it that he could lit­er­ally click ahead of the menus ap­pear­ing. So he would click on the bot­tom of the screen, then click where the menu item was gonna be, then click where the sub­menu was gonna be, then type in the num­bers, press re­turn, then turn around, chat with you for a minute, and turn back around, and the screen would have done what he wanted.

Steve ‘Spaz’ Williams: In the script, the T-1000 is go­ing to walk out of the fire and he’s go­ing to, the term peo­ple used was ‘morph,’ but in fact it was model in­ter­po­la­tion. He’s go­ing to in­ter­po­late into the fully clothed ver­sion of Robert Patrick. So [the shot was called] CC1 where he mi­grates from RP2, which is what we call the ‘Oscar’ ver­sion, a smoothed-down T-1000, but he shares the ex­act same dataset or con­trol ver­tices as RP4. And RP4, again, is the fully clothed ver­sion with the wrin­kles and but­tons. What I did is I hid all the but­tons and the badge and the gun, I hid it in­side his body cav­ity, and grew it out in time. The press called it morph. In fact, it was called model in­ter­po­la­tion.

Geoff Campbell: Steve [Williams] had brought me on to work pri­mar­ily with him on the T-1000 and I be­lieve my first task was to take his de­tailed Robert Patrick model and make a smooth ‘Oscar’ like ver­sion for the liq­uid metal tran­si­tions. Today in just about any soft­ware that task would be a twenty minute job with a smooth­ing brush, but in those days the soft­ware was very lim­ited and even a so­phis­ti­cated pack­age like Alias was ridicu­lously crude by to­days stan­dards. We were also us­ing NURBs with over­lap­ping con­trol ver­tices so mod­el­ing was a very com­pli­cated process. Also there was­n’t a shaded GL mode when sculpt­ing and on top of that you could only move one con­trol point at a time.

They had some­thing rev­o­lu­tion­ary at the time called Prop Mod which al­lowed you to se­lect a cv and type in a num­ber of cv’s in the sur­round­ing u and v di­rec­tion that you wanted to move with a fall off, but to use it you had to click down on the cv and wait for 5 sec­onds be­fore you could drag your point to it’s new lo­ca­tion. It was so slow I never both­ered to use it. So for me sculpt­ing was the te­dious task of mov­ing one point at a time. I used to joke that it was as in­tu­itive as sculpt­ing with chicken wire. The hard­est part was sculpt­ing those points in wire­frame and not see­ing the shaded form. You could only see the re­sults of your sculpt­ing if you clicked on the ‘quick shade’ op­tion where your screen would go black for 5 min­utes and then start build­ing your im­age on the screen one line at a time. That was re­served for when you were close to fin­ish­ing your model and you needed to see what the hell you had done all day. It also forced you to take a cof­fee break.

My first an­i­ma­tion on T2 was of John Connor’s fos­ter mother body tran­si­tion­ing back into the T-1000 and step­ping over John’s dead fos­ter fa­ther. We did­n’t have in­verse kine­mat­ics or con­straints so you had to keep track of all your body ro­ta­tions and when you over­shot a par­tic­u­lar join­t’s ro­ta­tion it could af­fect the whole arm or leg so an­i­mat­ing was much more time con­sum­ing than it is to­day. Match moves were also not as ac­cu­rate so you of­ten had to cheat the feet slid­ing to a ground plane in or­der to make them ap­pear to be locked to the floor one frame at a time.

Doug Smythe: In the hall­ways of ILM, we still have the lit­tle ma­que­ttes that were made of the five stages of the T-1000 and it starts from this very amor­phous blob, which was ac­tu­ally just key frame pose of a spline sur­face to do what­ever it needs to do, to dif­fer­ent stages of lev­els of de­tail of Robert Patrick as sil­ver, and then fi­nally the live ac­tion ac­tor.

But we did­n’t have any way to go from the first to the sec­ond, or from the fourth to the fifth. So any one time went from blobby to the low-res­o­lu­tion hu­manoid ver­sion, that in­volved the morph. We got it as close as we could just in an­i­ma­tion and then you let the morph take over. I think we had some sort of mesh dis­solve thing so that we could take the higher res­o­lu­tion mesh, smooth it, and pro­ject it onto the smaller res­o­lu­tion mesh so we could ac­tu­ally trans­form from, we do a cut from one to the other. We may have used some morphs to help that, but I think we could do a geo­met­ric trans­for­ma­tion as you get sharper and sharper sil­ver de­tail.

Alex Seiden (computer graph­ics an­i­ma­tor): One of the things I coded was an in­ter­ac­tive light­ing ed­i­tor (called ‘led’) that would help artists po­si­tion re­flec­tions. I ren­dered a ‘geometry buffer’ — pre-com­puted sur­face nor­mals and po­si­tions — so that shad­ing pa­ra­me­ters and re­flec­tion planes could be re-po­si­tioned and quickly re-com­puted with­out hav­ing to do a full ren­der. There were also some fea­tures that would al­low you to place a re­flec­tion or spec­u­lar high­light by click­ing where on the im­age you wanted it to ap­pear.

Sock sto­ries

Steve ‘Spaz’ Williams: We were us­ing Alias ver­sion 2.4.1. I had come up with a method to build us­ing sep­a­rate four sided b-splines for the T-1000. Then we hired a guy out of Toronto — Angus Poon who was an ex­cel­lent code writer. If you have 4 sided b-spline patches and the char­ac­ter is break­ing, well, he ba­si­cally came up with ‘Sock’ [which would be re­vised and called ‘Body Sock’], a piece of code that stitched things to­gether where it was all break­ing.

Michael Natkin: Later, this kind of thing would be done with NURBs, but be­fore that they were just b-spline patches. The process would be that they would make a still model that was per­fect, all the sur­faces were blended. Then, they would make the skele­tons, and they would an­i­mate the skele­tons. Of course, when you an­i­mate the skele­tons, the splines would sep­a­rate, right? If you imag­ine that your body is made up of plates of rigid ar­mour, and then you repo­si­tion the arms and legs, or what­ever, the ar­mour plates are gonna sep­a­rate, and, or over­lap.

What Body Sock was do­ing was giv­ing us a way to blend those patches back to­gether. There’s cer­tain parts of the body, par­tic­u­larly one of the biggest ones is the crotch area — all of these sur­faces had four edges. They were rec­tan­gu­lar, but the geom­e­try of where the legs come to­gether into the torso, there’s just not re­ally a great way to do that with four-sided patches. Body Sock would ba­si­cally let you spec­ify dif­fer­ent kinds of blends.

“A TD had to know much more of what went on ‘inside’ the soft­ware/​com­puter then in or­der to achieve the de­sired re­sults ef­fi­ciently.” — Stefen Fangmeier

Eric Enderton: I worked on Body Sock, and Carl Frederick, Mike Natkin and Lincoln Hu were also a big part of it. The way to think about, imag­ine some­body’s knee. As you bend the knee there’s go­ing to be a sep­a­ra­tion. If you just have a rigid up­per leg and a rigid lower leg, you bend the knee, there’s go­ing to be this break. Either that or in­ter­pen­e­tra­tion, or some­thing funny is go­ing to go on. The ques­tion was, how can we do that skele­tal an­i­ma­tion but then end up with a smooth sur­face? So, nowa­days this is built into so much soft­ware that no­body even thinks about it, but at the time it was like, ‘Oh boy, how do we do this?’

I don’t re­mem­ber how we ar­rived at this at all, but the name came from imag­in­ing, could we put a body sock, like a stretchy ny­lon fab­ric around all these in­di­vid­ual an­i­mated pieces of the body and have it be a smooth sur­face then that would fol­low the whole body? That was the orig­i­nal idea.

It ended up that that’s not what we did, in­stead, what we did was stitch­ing. All of this stuff was be­ing mod­elled in uni­form cu­bic b-spline sur­faces, so, NURBs, only sim­pler.

There was a but­ton, a menu item in Alias that would do this for two sur­faces sta­t­i­cally. It ig­nored the an­i­ma­tion, it was just a mod­el­ling op­er­a­tion that would stitch two sur­faces to­gether. One of the things that they had asked me to do ear­lier was to make an an­i­mated ver­sion of that tool. I wrote a lit­tle pro­gramme that read in a scene, you gave it the names of two sur­faces and it did this stitch­ing op­er­a­tion on each frame and then wrote the an­i­ma­tion back out.

I tried it on a plane next to an­other plane or some­thing, and it seemed to work, so I gave it to Spaz and he picked it up and in 20 sec­onds he made an arm an­i­ma­tion with a mus­cle bulge, and then hooked it up and typed in the com­mand and tried it out and there was this arm flex­ing back and forth. That was my first real ex­pe­ri­ence of an artist pick­ing up a tool I had made and mak­ing this beau­ti­ful art with it that I could never have made my­self. I had the sense that this artist was held down by chains that were the lim­i­ta­tions of their tools and I had just cut one of the chains. What a great feel­ing. I was hooked.

What we did with Body Sock was make an au­to­matic stitch­ing tool that would go and stitch all the seams in the en­tire char­ac­ter each frame. To do this, you needed a Sock file that told you where each of those seams was. It’d name the two sur­faces and which side of each, plus U, plus V, mi­nus V, mi­nus U. Somebody had to very care­fully fig­ure this out. For the sim­ple seams the math is re­ally sim­ple. Then you can do some­thing a lit­tle more com­pli­cated where you have more sub­di­vi­sions on one side than on the other. As long as it’s an in­te­ger mul­ti­ple it’s okay.

Then the cor­ners, if you have four sur­faces that come to­gether at a cor­ner you can sort of imag­ine this same math is not too bad. You just line up all the con­trol points and av­er­age them. But if you have three sur­faces or five sur­faces or some other num­ber com­ing to­gether at a cor­ner, which you do in a hu­manoid form, you have to have at least a cou­ple points like that, the math is a lot less ob­vi­ous. It took us a while of pok­ing around to fig­ure out how to do that.

Mimetic poly al­loy. Wuh?

Alex Seiden: The first thing I did on T2 was to write the ‘poly al­loy’ shader for the T-1000. The mer­cury-like sur­face of the T-1000 re­quired very spe­cific re­flec­tions, but in those days we did­n’t have ray-trac­ing avail­able in a pro­duc­tion ren­derer. So I came up with a way to let us do en­hanced, con­trol­lable re­flec­tion map­ping. TDs could place mul­ti­ple re­flec­tion planes in the scene with the an­i­ma­tion, and in­side the shader I’d do a quick hit test to see if the plane was hit. It was a RenderMan shader.

It had some sim­i­lar­i­ties to a shader that had been writ­ten at ILM re­cently be­fore, for a Diet Coke com­mer­cial, oddly enough, but was all new code. Some of the best feed­back was, no sur­prise, from Dennis Muren. In par­tic­u­lar, he was re­ally great at guid­ing the over­all look, such as mak­ing sure we had enough dif­fuse shad­ing mixed with our re­flec­tions. We called it the ‘pewter’ look. Without that, the T-1000 did­n’t have any mass.

Stefen Fangmeier: I also worked on the poly al­loy shader. RenderMan and its shad­ing lan­guage were en­tirely new to me since I had pre­vi­ously only worked with Wavefront and then men­tal ray at Mental Images in Berlin. The abil­ity of RenderMan to al­low for com­plex light and re­flec­tion in­ter­ac­tion and was es­sen­tial in get­ting the look right.

One of the best ex­am­ples of the poly al­loy shader is in the shot of the T-1000 walk­ing out of the flames. In or­der to have the flames re­flected in the chrome as the T-1000 walks out, I placed cards into the en­vi­ron­ment on which flames el­e­ments were mapped on every frame and the shader used the trans­for­ma­tion abil­ity in RenderMan to cal­cu­late the proper re­flec­tions. We did­n’t have ray-trac­ing back then due to the high ren­der­ing times it would have re­quired but were able to achieve this ef­fect just as well with this sort of clever cheat.

“The funny thing was that the hos­pi­tal did­n’t re­ally have checker­board floors. They were all white. Cameron thought that the black and white was much creepier look­ing, so we went with it. He had some poor guy stick black stick­ers every other tile.” — Liza Keith

The wipe to the ac­tor at the end of the shot was also achieved us­ing the ob­ject space of the model and an­i­mat­ing a card over it to achieve the wipe in the shader. The trans­parency wipe was off­set by a frac­tal in or­der to not make it a straight edge. This ef­fect was used in sev­eral other scenes as well and re­quired that the an­i­ma­tor would closely match the CG geom­e­try to the ac­tor to which the T-1000 was trans­form­ing.

It should also be said that there weren’t a great deal of in­ter­faces that al­lowed for im­me­di­ate in­ter­ac­tion with the ren­der­ing process as there are to­day. So, a TD had to know much more of what went on ‘inside’ the soft­ware/​com­puter in or­der to achieve the de­sired re­sults ef­fi­ciently. Times cer­tainly have changed.

Getting gasps from that first heal­ing shot

Jonathan French: For the heal­ing shots, John Schlag wrote this great util­ity har­vested from the Abyss which I think he/​we called Z-ripple. Basically it had a set of an­i­ma­tor cen­tric slid­ers to add ad­di­tional sine-wave like pro­ce­dural rip­pling and falloff to the bul­let wound heal­ing process that Alias could­n’t do. John Berton stepped in also and added a lit­tle Morph de­fla­tion on the plate to Robert’s chest to add to the ef­fect.

My only re­grets about that first shot was the plate was­n’t mov­ing — it was a sin­gle still frame with film grain added to make it look like a run­ning plate. I wish they had shot it with a run­ning plate and Robert Patrick mov­ing his eyes or head around a lit­tle to make it a bit more an­i­mated and life­like. My other re­gret also out of my con­trol was that the colour in that shot in the fi­nal film is all wrong. It’s green. I think I got the same colour treat­ment that Mike Natkin later dis­cov­ered was go­ing on with his shots. Still, at a pre­miere screen­ing of the film you could hear gasps in the au­di­ence, which was kind of funny af­ter spend­ing so much time on the shot.

The match moves were a bit more work. Around that time Tien Truong had writ­ten a cool low-bit edge de­tec­tion util­ity. You could ba­si­cally run it on a se­quence of plates and ex­tract I think a 2-bit im­age pass which would pick up only ar­eas of con­trast, remap­ping them into a su­per bright ma­genta/​green/​blue colour palette. Then you could use that same util­ity to over­lay your whole SGI desk­top and reg­is­ter it against a match move shot in Alias. Of course now every off the shelf soft­ware has this sort of thing built in, and mod­ern hard­ware is ca­pa­ble of push­ing any bit depth. But back then we were run­ning our SGI’s ragged, so mem­ory and I/O econ­omy was every­thing. Tien’s util­ity was key to nail­ing Robert’s match move wound shots, be­cause Robert was of­ten drift­ing around at a sub-pixel level when he looked to the ca­sual viewer as to­tally still. But it would show up in­stantly in a match move.

‘Head through floor’

Eric Enderton: For this shot, the prob­lem was that you had the face, and you had the floor, and they were two com­pletely un­re­lated ob­jects and we did­n’t want to try to an­i­mate that merge, be­cause it was go­ing to sep­a­rate from the floor. The topol­ogy was go­ing to change, and it just would have been re­ally hard, so what we wanted to do was some­how make a sur­face that lay over the face and the floor, like a cloth.

The way we did that was, I made a ray cast­ing tool. The new sur­face is de­fined by an ar­ray of con­trol points. We’d com­pute those con­trol points by shoot­ing rays from a start­ing sur­face — a plane or curved sur­face — to­wards the com­bined sur­face, plac­ing each con­trol point at the ray in­ter­sec­tion. It was new and in­ter­est­ing, but very dif­fi­cult to con­trol.

Jay Riddle: Liza Keith was the an­i­ma­tor on that shot. It ended up tak­ing quite a bit of time to fig­ure out how to make this nice smooth tran­si­tion be­tween a flat sur­face, to some­thing that has a face that starts to ap­pear in it, and then pulls to­gether and the tex­ture it­self feels like it’s do­ing some­thing that makes sense, and not like tear­ing apart and go­ing in weird di­rec­tions, and look­ing CG.

Eric Enderton: Liza is both very tech­ni­cal and artis­tic and so she was wrestling with it and we would see it in dailies. The process took overnight to ren­der so you could­n’t see what your an­i­ma­tion looked like un­til the next morn­ing. There was one day when she just did­n’t even come to dailies be­cause she was get­ting so dis­cour­aged, but that was the day that it re­ally worked, vi­su­ally, and there was spon­ta­neous ap­plause in the dailies room. So when she came in I told her, ‘You got it, that worked!’

Liza Keith (computer graph­ics an­i­ma­tor): So they wrote that lit­tle rays pro­gramme that did an in­ter­sec­tion and cre­ated a sur­face from the in­ter­sec­tion. We ended up hav­ing to make two sur­faces. One go­ing out, that we used to do the one go­ing in. Spaz was the one that gen­er­ated the model. It was a scanned 3D model, but those things weren’t work­ing very well at the time, so he turned it into an ac­tual model that you could use.

Michael Natkin: Liza had mod­elled sev­eral frames but we did­n’t have any good way to turn that into an an­i­ma­tion, and so I worked on some soft­ware — it was re­ally al­most just like glue code. It would read the Alias files as still frames, and turn them into an­i­ma­tions, set­ting them up as keyframes so that we could ren­der the in-be­tweens. But these were all things that you could­n’t do in the Alias in­ter­face very eas­ily. A lot of what I would be do­ing was sim­ple tools that ba­si­cally made Alias work bet­ter, or help with the trans­la­tion from Alias to Renderman.

Liza Keith: I think my big con­tri­bu­tion to that shot, be­yond the ac­tual an­i­ma­tion, was the fact that I had writ­ten a shader to do a floor for me to do tests with, be­cause we did­n’t have the back­ground plates at that time. So I just made a big square and put the checker­board on it. The funny thing was that the hos­pi­tal did­n’t re­ally have checker­board floors. They were all white. And if you look in the back­ground in some of the other shots, you’ll see that the floors aren’t check­ered, but Cameron thought that the black and white was much creepier look­ing, so we went with it. He had some poor guy stick black stick­ers every other tile, every other piece of linoleum in the hos­pi­tal hall­way.

Michael Natkin: It was very grat­i­fy­ing be­cause it was all this stuff that, from an en­gi­neer­ing point of view, was very sim­ple to do. It was ba­si­cally just mov­ing data around. It was­n’t fancy com­puter graph­ics, re­ally, but it was just mak­ing the artists, the TDs, and the an­i­ma­tors’ lives so much bet­ter. It was tak­ing things that would have taken them days to do man­u­ally. We could write the code that would just do it in­stantly for them.