Full list of pro­jects avail­able here.

La Suite numérique (La Suite for short) is a full blown open-source dig­i­tal work­space for on­line col­lab­o­ra­tion and team­work.

La Suite is built by French gov­ern­ment agen­cies DINUM and ANCT. It is also the prod­uct of a close eu­ro­pean col­lab­o­ra­tion with the Netherlands and German state.

Our code base is a 100% open source and MIT li­cenced.

Come say hello on Matrix

I did­n’t ask for this and nei­ther did you.

I did­n’t ask for a ro­bot to con­sume every blog post and piece of code I ever wrote and par­rot it back so that some hack could make money off of it.

I did­n’t ask for the role of a pro­gram­mer to be re­duced to that of a glo­ri­fied TSA agent, re­view­ing code to make sure the AI did­n’t smug­gle some­thing dan­ger­ous into pro­duc­tion.

And yet here we are. The worst fact about these tools is that they work. They can write code bet­ter than you or I can, and if you don’t be­lieve me, wait six months.

You could ab­stain out of moral prin­ci­ple. And that’s fine, es­pe­cially if you’re at the tail end of your ca­reer. And if you’re at the be­gin­ning of your ca­reer, you don’t need me to ex­plain any of this to you, be­cause you al­ready use Warp and Cursor and Claude, with ChatGPT as your ther­a­pist and pair pro­gram­mer and maybe even your lover. This post is for the 40-somethings in my au­di­ence who don’t re­al­ize this fact yet.

So as a se­nior, you could ab­stain. But then your ju­nior col­leagues will even­tu­ally code cir­cles around you, be­cause they’re wear­ing bazooka-pow­ered jet­packs and you’re still rid­ing around on a fixie bike. Eventually your boss will start ask­ing why you’re get­ting paid twice your zoomer col­leagues’ salary to pro­duce a tenth of the code.

Ultimately if you have a mort­gage and a car pay­ment and a fam­ily you love, you’re go­ing to make your de­ci­sion. It’s maybe not the de­ci­sion that your younger, more ide­al­is­tic self would want you to make, but it does keep your car and your house and your fam­ily safe in­side it.

Someday years from now we will look back on the era when we were the last gen­er­a­tion to code by hand. We’ll laugh and ex­plain to our grand­kids how silly it was that we typed out JavaScript syn­tax with our fin­gers. But se­cretly we’ll miss it.

We’ll miss the feel­ing of hold­ing code in our hands and mold­ing it like clay in the ca­ress of a mas­ter sculp­tor. We’ll miss the sleep­less wran­gling of some odd bug that even­tu­ally re­lents to the de­bug­ger at 2 AM. We’ll miss cre­at­ing some­thing we feel proud of, some­thing true and right and good. We’ll miss the sat­is­fac­tion of the artist’s sig­na­ture at the bot­tom of the oil paint­ing, the GitHub repo say­ing “I made this.”

I don’t cel­e­brate the new world, but I also don’t re­sist it. The sun rises, the sun sets, I or­bit help­lessly around it, and my protests can’t stop it. It does­n’t care; it con­tin­ues its arc across the sky re­gard­less, mov­ing but un­moved.

If you would like to grieve, I in­vite you to grieve with me. We are the last of our kind, and those who fol­low us won’t un­der­stand our sor­row. Our craft, as we have prac­ticed it, will end up like some black­smith’s tool in an arche­o­log­i­cal dig, a cu­rio for fu­ture gen­er­a­tions. It can­not be helped, it is the na­ture of all things to pass to dust, and yet still we can mourn. Now is the time to mourn the pass­ing of our craft.

I don’t post a lot. But when I do, it’s be­cause I think few peo­ple are say­ing out loud what I’m notic­ing.

I’ve been build­ing a prod­uct from the ground up. Not the “I spun up a Next.js tem­plate” kind of ground up. I mean from net­work con­fig­u­ra­tion to prod­uct de­sign to pric­ing de­ci­sions. Truly end to end. And I’ve been do­ing it us­ing fron­tier mod­els and cod­ing agents for hours and hours every sin­gle day, both on this pro­ject and in my full time work. I’ve been try­ing to stay away from the chaos and the hype, fil­ter­ing hard for what is ac­tu­ally valu­able.

Since December 2025, things have dra­mat­i­cally changed for the bet­ter. Many have no­ticed. Few are draw­ing the right con­clu­sions.

Antirez likes to call it “automated pro­gram­ming”, and I re­ally like that fram­ing. It cap­tures the essence far bet­ter than the shal­low, al­most dis­mis­sive la­bel of “vibe cod­ing”. Automation was at the core of most of the work and cul­tural rev­o­lu­tions of hu­man his­tory. The print­ing press, the loom, the as­sem­bly line. This one does­n’t dif­fer much.

Most of my work is still there. I still have to deeply think about every im­por­tant as­pect of what I want to build. The ar­chi­tec­ture, the trade offs, the prod­uct de­ci­sions, the edge cases that will bite you at 3am. What’s gone is the tear­ing, ex­haust­ing man­ual labour of typ­ing every sin­gle line of code.

At this point in time, mod­els and tools, when put in a clean and ma­ni­a­cally well set up en­vi­ron­ment, can truly make the dif­fer­ence. I can be the ar­chi­tect with­out the wear­ing act of lay­ing every sin­gle brick and spread­ing the mor­tar. I can de­sign the dress with­out the act of cut­ting and sewing each in­di­vid­ual piece of fab­ric. But I can do all of this with the ex­pe­ri­ence on my back of hav­ing laid the bricks, spread the mor­tar, cut and sewn for twenty years. If I don’t like some­thing, I can go in, un­der­stand it and fix it as I please, in­struct­ing once and for all my setup to do what I want next time.

Automated pro­gram­ming es­pe­cially al­lows me to quickly build the tools I need so fast that every black­smith that ever ex­isted on this earth would envy me deeply. Finally able to re­ally fo­cus on the things they have in mind. Finally ded­i­cat­ing more time of their craft to the art they con­ceive, not the sweat of the forge.

It’s been months now that I have this thought crys­tal­lized in my mind. It is so clear to me that I gen­uinely don’t un­der­stand why every­one is not scream­ing it to the world.

We can fi­nally get rid of all that mid­dle work. That adapt­ing layer of garbage we blindly ac­cepted dur­ing these years. A huge amount of frame­works and li­braries and tool­ing that has com­pletely pol­luted soft­ware en­gi­neer­ing, es­pe­cially in web, mo­bile and desk­top de­vel­op­ment. Layers upon lay­ers of ab­strac­tions that ab­stract noth­ing mean­ing­ful, that solve prob­lems we should­n’t have had in the first place, that cre­ate ten new prob­lems for every one they claim to fix.

Think about what hap­pened. We, as an in­dus­try, looked at the gen­uine com­plex­ity of build­ing soft­ware and in­stead of sharp­en­ing our think­ing, we bought some­one else’s think­ing off the shelf. We wrapped every­thing in frame­works like wrap­ping a bro­ken leg in silk. It looks nice. The leg is still bro­ken.

In my mind, be­sides the self de­clared ob­jec­tives, frame­works solve three prob­lems. Two ex­plicit and one ob­vi­ous but never de­clared.

“Simplification”. Software en­gi­neers are scared of de­sign­ing things them­selves. They would rather ac­cept some­one else’s struc­ture, de­spite hav­ing to force fit it into their prod­uct, rather than tak­ing the time to start from the goal and work back­wards to cre­ate the per­fect suit for their idea. Like an ar­chi­tect blindly ac­cept­ing an­other ar­chi­tec­t’s blue­prints and ap­ply­ing them re­gard­less of the con­text, the needs, the ter­rain, the new tech­no­log­i­cal pos­si­bil­i­ties. We de­cided to re­move com­plex­ity not by sharp­en­ing our men­tal mod­els around the prod­ucts we build, but by buy­ing a one size fits all de­sign and ap­ply­ing it every­where. That is not sim­pli­fi­ca­tion. That is in­tel­lec­tual sur­ren­der.

Automation. This is the only point I can ac­tu­ally, more or less, un­der­stand and buy. Boilerplate is bor­ing work. I hate it. And I es­pe­cially hate us­ing li­braries that I then need to study, keep up­dated, be aware of vul­ner­a­bil­i­ties for, just for the pur­pose of re­mov­ing the cre­ation of du­pli­cated but nec­es­sary code. Think about ORMs, CRUD man­age­ment, code gen­er­a­tion, API doc­u­men­ta­tion and so on. The grunt work that no­body wants to do but every­body needs done. Fair enough. But hold that thought, be­cause this is ex­actly the point where every­thing changes.

Labour cost. This is the quiet one. The one no­body puts on the con­fer­ence slide. For com­pa­nies, it is much bet­ter hav­ing Google, Meta, Vercel de­cid­ing for you how you build prod­uct and ship code. Adopt their frame­work. Pay the cost of lock in. Be en­chanted by their cloud man­aged so­lu­tion to host, de­ploy, store your stuff. And you un­lock a fea­ture that has noth­ing to do with en­gi­neer­ing: you no longer need to hire a soft­ware en­gi­neer. You hire a React Developer. No need to train. Plug and play. Easy to re­place. A cog in a ma­chine de­signed by some­one else, main­tain­ing a sys­tem ar­chi­tected by some­one else, solv­ing prob­lems de­fined by some­one else. This is not en­gi­neer­ing. This is op­er­at­ing.

In my opin­ion Software en­gi­neer­ing, the true one, is back again.

I am not speak­ing out of my lungs only. I’ve been de­vel­op­ing this way al­most flaw­lessly for over two years at this point. But the true rev­o­lu­tion hap­pened clearly last year, and since December 2025 this is ob­vi­ous to any­one pay­ing at­ten­tion. From now on it will be even more so.

We have the chance again to get rid of use­less com­plex­ity and keep work­ing on the true and wel­come com­plex­ity of our ideas, our fea­tures, our prod­ucts. The com­plex­ity that mat­ters. The com­plex­ity that is ac­tu­ally yours.

Automation and boil­er­plat­ing have never been so cheap to over­come. I’ve been ba­si­cally never writ­ing twice the same line of code. I’m in­stantly build­ing small tools I need, pur­pose built, ex­actly shaped around the prob­lem at hand. I don’t need any fancy monorepo man­ager. A sim­ple Makefile cov­ers 100% of my needs for 99% of my use cases. When things will get very com­pli­cated, and if they get very com­pli­cated, I’ll think about it. But only then. Not a sec­ond be­fore. This is en­gi­neer­ing. You solve the prob­lem you have, not the prob­lem some­one on a con­fer­ence stage told you that you’ll even­tu­ally have.

Agents are re­ally well pre­pared when it comes to ba­sic tools. Tools that have been around not for months, but lit­er­ally for decades. Bash was born in 1989, just pre­ced­ing me by two months. The most mediocre model run­ning at this time knows bash bet­ter than any per­son in the world. Bash is the uni­ver­sal adapter. It is not a co­in­ci­dence that cod­ing agents are shift­ing from com­plex and ex­pen­sive MCP con­fig­u­ra­tions to a sim­ple agent loop with bash as a way to in­ter­act, lit­er­ally, with the world. The old­est tool turned out to be the most fu­ture proof. There’s a les­son in there if you care to lis­ten.

Really think about it.

Why do you ever need, for most of the use cases you can think of, a use­less, ex­pen­sive, flawed, of­ten vul­ner­a­ble frame­work, and the pa­rade of li­braries that comes with it, that you prob­a­bly use for only 10% of its ca­pa­bil­i­ties? With all the costs as­so­ci­ated with it. From the “least” ex­pen­sive: op­er­a­tional costs like keep­ing every­thing up­dated be­cause they once again found a crit­i­cal vul­ner­a­bil­ity in your Next.js ver­sion. To the most ex­pen­sive one: the cost to your Design Choices. The in­vis­i­ble cost. The one you pay every day with­out even re­al­iz­ing it, be­cause you’ve been pay­ing it so long you for­got what free­dom felt like.

If you keep ac­cept­ing this trade off, you are not only los­ing the biggest op­por­tu­nity we’ve seen in soft­ware en­gi­neer­ing in decades. You are prob­a­bly not rec­og­niz­ing your own lazi­ness in once again buy­ing what­ever the hy­per­scalers have de­cided for you. You’re let­ting Google and Meta and Vercel be your ar­chi­tect, your de­signer, your thinker. And in ex­change, you get to be their op­er­a­tor.

The tools are here. The mod­els are here. The rev­o­lu­tion al­ready hap­pened and most peo­ple are still dec­o­rat­ing the old house.

Stop wrap­ping bro­ken legs in silk. Start build­ing things that are yours.

This is a vo­cal tech­nique ref­er­ence cov­er­ing 21 tech­niques across five cat­e­gories. It’s de­signed as a learn­ing com­pan­ion — whether you’re a be­gin­ner find­ing your voice or an ex­pe­ri­enced singer ex­pand­ing your toolkit.

The sticky bar be­low the ti­tle lets you jump be­tween sec­tions. Each col­ored dot matches its cat­e­gory:

— ways to shape and color your sound

How to read the table

Each row is one tech­nique. Hover the tech­nique name to see a short de­scrip­tion. The dif­fi­culty dots (● ○ ○ ○ ○) show how ad­vanced it is, from 1 to 5.

Some tech­niques show small dashed chips be­neath the name — these are pre­req­ui­sites. The chip color tells you which cat­e­gory the pre­req­ui­site be­longs to. Hover a chip to see what that tech­nique sounds like, or click it to jump straight to its row in the table.

Techniques marked with ⚠️ warn­ings can cause dam­age if done in­cor­rectly. The golden rule: if it hurts, stop. Work with a vo­cal coach for any­thing rated 4–5 dots.

Use EN / DA to switch lan­guage and the theme but­ton to cy­cle through five color schemes: Dark, Light, Midnight, Forest, and Ember. Your choices are saved au­to­mat­i­cally.

Nogle teknikker viser små sti­plede chips un­der navnet — det er forud­sæt­ninger. Chipfarven fortæller hvilken kat­e­gori forud­sæt­nin­gen hører til. Hold musen over en chip for at se hvad teknikken ly­der som, eller klik for at hoppe di­rekte til den i tabellen.

I hope this guide helps you on your vo­cal jour­ney. If you have sug­ges­tions, found a bug, or just want to say hi — I’d love to hear from you.

Check your pos­ture — feet shoul­der-width, shoul­ders back and down, chin level.

Release ten­sion — roll your neck, shrug and drop shoul­ders, shake out your arms.

No cold starts — never belt, dis­tort, or push range with­out warm­ing up first.

Breathing (1 min) — Inhale 4 counts into belly/​sides/​back. Exhale on “Sss” for 15–20 sec­onds. Repeat 3x. This ac­ti­vates your sup­port sys­tem.

Lip Trills (1 min) — Blow air through closed lips to make them vi­brate. Slide up and down your range. Keeps every­thing re­laxed and con­nected.

Humming (1 min) — Hum on “Mmm” through 5-note scales, as­cend­ing. Feel the buzz in your face (mask res­o­nance). Keep jaw and tongue loose.

Vowel Slides (1 min) — Sing “Mee-Meh-Mah-Moh-Moo” on a sin­gle note, then move up by half steps. Opens the vo­cal tract grad­u­ally.

Sirens (1 min) — Slide from bot­tom to top and back on “Woo” or “Wee.” Full range, gen­tle, no push­ing. This bridges your reg­is­ters.

Straw phona­tion — Sing through a straw (or into a cup of wa­ter with a straw). Creates back-pres­sure that bal­ances air­flow and fold clo­sure. Best warm-up tool avail­able.

Tongue trills — Roll your tongue on “Rr” while singing scales. Releases tongue ten­sion (a com­mon prob­lem).

Arpeggios — 1-3-5-8-5-3-1 on “Nay” or “Gee” to work through your pas­sag­gio (break area).

A dome-shaped mus­cle be­neath your lungs. When you in­hale, it flat­tens down­ward, pulling air in. You don’t di­rectly “sing from your di­aphragm” — you use it to con­trol the rate of ex­ha­la­tion. Think of it as an air pres­sure reg­u­la­tor, not a sound source.

Two small folds of tis­sue in your lar­ynx. When air passes through, they vi­brate and cre­ate sound. Thicker vi­bra­tion = chest voice. Thinner vi­bra­tion = head voice. Partial clo­sure = falsetto/​breathy. The space be­tween them is called the glot­tis.

Your “voice box.” It can move up (bright, thin sound) or down (dark, warm sound). For most singing, a neu­tral or slightly low­ered lar­ynx is ideal. A high lar­ynx un­der pres­sure = strain. Learn to keep it sta­ble — yawn­ing gen­tly while singing helps find the right po­si­tion.

Abdominals — Control ex­ha­la­tion pres­sure. They don’t push air out — they slow the col­lapse of the rib cage.

Intercostals — Muscles be­tween your ribs. Keep your ribs ex­panded dur­ing singing. This is “appoggio” (leaning into the breath).

Back mus­cles — Often for­got­ten. Your lower back ex­pands when breath­ing cor­rectly. Engage it for sup­port.

Stand with feet shoul­der-width apart. Knees slightly bent (not locked). Shoulders re­laxed, back and down. Chest com­fort­ably open. Head bal­anced on top of the spine — not jut­ting for­ward. Imagine a string pulling you up from the crown of your head.

Hydration — Drink wa­ter con­sis­tently through­out the day, not just be­fore singing. Your vo­cal folds need sys­temic hy­dra­tion.

Steam in­hala­tion — Breathe steam for 10 min­utes be­fore heavy singing. This di­rectly hy­drates the folds.

Rest — Your voice needs re­cov­ery time. Avoid talk­ing loudly af­ter in­tense ses­sions.

Din “stemmeboks.” Den kan bevæge sig op (lys, tynd lyd) eller ned (mørk, varm lyd). Til de fleste for­mer for sang er en neu­tral eller let sæn­ket strube ideel. En høj strube un­der pres = be­last­ning. Lær at holde den sta­bil — at gabe blidt mens du syn­ger hjælper med at finde den rette po­si­tion.

Common ad­vice that’s mis­lead­ing, in­com­plete, or out­right harm­ful. If some­one tells you any of these, be skep­ti­cal.

You can’t di­rectly con­trol your di­aphragm — it’s an in­vol­un­tary mus­cle on the in­hale. What peo­ple mean is: use your ab­dom­i­nal and in­ter­costal mus­cles to con­trol ex­ha­la­tion. Saying “sing from your di­aphragm” is like say­ing “digest from your stom­ach.” Technically in­volved, but not how you’d teach it.

“Drink tea with honey to fix your voice”

Tea and honey never touch your vo­cal folds — they go down your esoph­a­gus, not your tra­chea. They can soothe throat ir­ri­ta­tion and feel nice, but they don’t “fix” or “coat” your cords. What ac­tu­ally helps: steam in­hala­tion and sys­temic hy­dra­tion (water, hours in ad­vance).

The sound is­n’t pro­duced in your chest. “Chest voice” refers to the thick vo­cal fold vi­bra­tion pat­tern that cre­ates sym­pa­thetic res­o­nance you feel in your up­per torso. The sound is al­ways made at the vo­cal folds in your lar­ynx.

“Falsetto is only for men”

Everyone with vo­cal folds can pro­duce falsetto — it’s a mode of vi­bra­tion where the folds don’t fully close. Women use it too, though the tim­bral dif­fer­ence from head voice may be less dra­matic.

They give you a dam­aged voice. The “rasp” from smok­ing and al­co­hol comes from swollen, ir­ri­tated, de­hy­drated folds. Healthy vo­cal dis­tor­tion uses the false folds and ary­tenoids — struc­tures above the true cords. One is con­trolled art, the other is per­ma­nent dam­age.

The ex­act op­po­site. High notes re­quire less air, not more. Pushing more air at higher pitches forces the folds apart and cre­ates strain. Think “less air, more com­pres­sion” — let the folds do the work.

Artificial vi­brato (jaw wob­ble, di­aphragm pulse) sounds un­nat­ural and cre­ates ten­sion. Real vi­brato emerges nat­u­rally when breath sup­port is solid and the throat is re­laxed. If you don’t have vi­brato yet, the fix is bet­ter tech­nique — not man­u­fac­tur­ing it.

“You’re ei­ther born with it or you’re not”

Singing is a mo­tor skill. Some peo­ple have nat­ural ad­van­tages (vocal fold length, res­o­nance cav­ity size), but tech­nique, pitch ac­cu­racy, tone qual­ity, and range are all train­able. Most “natural” singers prac­ticed ob­ses­sively as chil­dren.

Your vo­cal folds are tis­sue. They need in­creased blood flow and grad­ual stretch­ing be­fore heavy use — just like any other mus­cle. Cold singing is the fastest path to strain, nod­ules, and he­m­or­rhages.

Pain means dam­age. Unlike skele­tal mus­cles, vo­cal folds don’t grow stronger from mi­cro-tears. Pain, burn­ing, or per­sis­tent hoarse­ness = stop im­me­di­ately. Rest. If it lasts more than a few days, see an ENT spe­cial­ist.

Du kan ikke di­rekte kon­trollere dit mellemgulv — det er en ufriv­il­lig muskel ved in­dånd­ing. Det folk mener er: brug dine mave- og in­terkostal­muskler til at kon­trollere udåndin­gen. At sige “syng fra mellemgul­vet” er som at sige “fordøj fra maven.”

This guide uses tra­di­tional vo­cal ter­mi­nol­ogy (chest voice, head voice, mixed voice, etc.) be­cause it’s the most widely un­der­stood frame­work world­wide. However, the most sci­en­tif­i­cally val­i­dated sys­tem is Complete Vocal Technique (CVT), de­vel­oped by Cathrine Sadolin at the Complete Vocal Institute in Copenhagen.

CVT is built on laryn­go­scopic imag­ing, EGG mea­sure­ments, and peer-re­viewed acoustic re­search. Here’s how the two frame­works re­late.

CVT clas­si­fies all singing into four modes based on vo­cal tract con­fig­u­ra­tion — not felt vi­bra­tion:

Support — Coordinated ab­dom­i­nal, waist, so­lar plexus, and back mus­cle en­gage­ment to con­trol air pres­sure and air­flow. (This guide: Breath Support)

Necessary Twang — Narrowing the epiglot­tic fun­nel for clearer, more ef­fi­cient sound. CVT con­sid­ers this foun­da­tional for all healthy singing, not just a style. (This guide: Twang)

Avoid pro­trud­ing jaw & tight­ened lips — These trig­ger un­con­trolled vo­cal cord con­stric­tion, es­pe­cially in up­per reg­is­ter. (Not ex­plic­itly cov­ered in this guide)

“Overdrive” in CVT is a clean mode, not dis­tor­tion

Vowel rules: CVT re­stricts spe­cific vow­els per mode. Traditional ped­a­gogy uses gen­eral vowel mod­i­fi­ca­tion. Both work, but CVT is more pre­cise.

Metal & Density: CVT uses “degree of metal” (0–100%) and “density” (fuller vs. re­duced) as pa­ra­me­ters. Traditional ped­a­gogy does­n’t have these con­cepts.

“Overdrive” means dif­fer­ent things: In this guide, over­drive = heavy vo­cal dis­tor­tion (like gui­tar over­drive). In CVT, Overdrive = a clean, shouty vo­cal mode.

Learn more: com­plete­vo­calin­sti­tute.com

Look for ex­pand­able an­no­ta­tions on tech­nique cards through­out this guide.

The fun­da­men­tal modes of vo­cal fold vi­bra­tion. Every sound you make lives some­where on this spec­trum. Master these be­fore any­thing else.

Ways of us­ing your reg­is­ters to cre­ate spe­cific sounds. These de­fine gen­res and artis­tic iden­tity.

Textures and col­ors you add to your base tone. These are the sea­son­ing — use them de­lib­er­ately, not as de­faults.

Decorative tech­niques that add flair, per­son­al­ity, and mu­si­cal­ity to your phras­ing.

The foun­da­tion every­thing else rests on. Control here is the dif­fer­ence be­tween am­a­teurs and pro­fes­sion­als.

Rebecca Guy, se­nior pol­icy man­ager at the Royal Society for the Prevention of Accidents, said: “Regular vi­sion checks are a sen­si­ble way to re­duce risk as we age, but the pri­or­ity must be a sys­tem that sup­ports peo­ple to drive safely for as long as pos­si­ble, while en­sur­ing timely ac­tion is taken when health or eye­sight could put them or oth­ers in dan­ger.”

I am an un­usual beast. All my solo pro­ject games I’ve been mak­ing re­cently have been writ­ten in ‘vanilla’ C. Nobody does this. So I think it might be in­ter­est­ing to ex­plain why I do.

Dry pro­gram­ming lan­guage opin­ions in­com­ing, you have been warned.

There’s some things which are non-ne­go­tiable. First of, it has to be re­li­able. I can’t af­ford to spend my time deal­ing with bugs I did­n’t cause my­self.

A lot of my games were writ­ten for flash, and now flash is dy­ing. I do not

want to spend my time port­ing old games to new plat­forms, I want to make new games. I need a plat­form that I am con­fi­dent will be around for a while.

Similarly I want to avoid ty­ing my­self to a par­tic­u­lar OS, and ide­ally I’d like to have the op­tion of de­vel­op­ing for con­soles. So it’s im­por­tant that my pro­gram­ming lan­guage is portable, and that it has good portable li­brary sup­port.

The strongest thing on my de­sired, but not re­quired list is sim­plic­ity. I find look­ing up lan­guage fea­tures, and quirky ‘clever’ api’s in­cred­i­bly tir­ing. The ideal lan­guage would be one I can mem­o­rize, and then never have to look things up.

Dealing with bugs is huge cre­ative drain. I want to pro­duce less bugs, so I want strict typ­ing, strong warn­ing mes­sages and sta­tic code analy­sis. I want bugs to be eas­ier to find, so I want good de­bug­gers and dy­namic analy­sis.

I’m not in­ter­est­ing in high-def re­al­ism, but I do still care a bit about per­for­mance. Having more cy­cles avail­able broad­ens the palette of things you can do. It’s par­tic­u­larly in­ter­est­ing to ex­plore what is pos­si­ble with mod­ern, pow­er­ful com­put­ers if you aren’t per­su­ing fi­delity.

Even more than that I care about the speed of the com­piler. I am not a zen mas­ter of fo­cus, and wait­ing 10+ sec­onds is waste­ful, yes, but more im­por­tantly it breaks my flow. I flick over to Twitter and sud­denly 5+ min­utes are gone.

I am not an OOP con­vert. I’ve spent most of my pro­fes­sional life work­ing with classes and ob­jects, but the more time I spend, the less I un­der­stand why you’d want to com­bine code and data so rigidly. I want to han­dle data as data and write the code that best fits a par­tic­u­lar sit­u­a­tion.

C++ is still the most com­mon lan­guage for writ­ing games, and not with­out rea­son. I still do al­most all of my con­tract work in it. I dis­like it in­tensely.

C++ cov­ers my needs, but fails my wants badly. It is des­per­ately com­pli­cated. Despite de­cent tool­ing it’s easy to cre­ate in­sid­i­ous bugs. It is also slow to com­pile com­pared to C. It is high per­for­mance, and it of­fers fea­tures that C does­n’t have; but fea­tures I don’t want, and at a great com­plex­ity cost.

C# and Java have sim­i­lar is­sues. They are ver­bose and com­plex beasts, and I am search­ing for a con­cise, sim­ple crea­ture. They both do a lot to rail­road a pro­gram­mer into a strongly OOP style that I am op­posed to. As per most higher level lan­guages they have a ten­dency to hide away com­plex­ity in a way that does­n’t ac­tu­ally pre­vent it from bit­ing you.

I like Go a lot. In many ways it is C re­vis­ited, tak­ing into ac­count what has be learnt in the long years since it was re­leased. I would like to use it, but there are big road­blocks that pre­vent me. The stop-the-world garbage col­lec­tion is a big pain for games, stop­ping the world is some­thing you can’t re­ally af­ford to do. The li­brary sup­port for games is quite poor, and though you can wrap C libs with­out much trou­ble, do­ing so adds a lot of busy work. It is niche enough that I worry a lit­tle about long term rel­e­vance.

It would be nice to make things for the web, but it feels like a ter­ri­fy­ingly fast mov­ing en­vi­ro­ment. It is par­tic­u­larly scary with the death of flash. I re­ally dis­like javascript, it is so loose that I mar­vel that peo­ple are able to write big chunks of soft­ware in it. I have no in­ter­est in try­ing.

Haxe feels much more promis­ing than most al­ter­na­tives. If I do web stuff again I’ll be div­ing in here. There is some good li­brary sup­port. I am a lit­tle con­cerned by its rel­a­tive youth, will it last? I don’t much have else to say about it though, I’ve only dab­bled with the sur­face.

Some peo­ple just say screw it, I’ll write my own lan­guage, the lan­guage I want to use. I ad­mire this, and some­times I toy with the idea of do­ing the same. It feels like too much to throw away all ex­ist­ing li­brary sup­port, and tak­ing full re­spon­si­bilty for fu­ture com­pat­i­bil­ity. It is also very dif­fi­cult, and when it comes down to it I would rather be mak­ing games than pro­gram­ming lan­guages.

C is dan­ger­ous, but it is re­li­able. A very sharp knife that can cut fin­gers as well as veg, but so sim­ple it’s not too hard to learn to use it care­fully.

It is fast, and when it comes to com­pi­la­tion I can’t think of any­thing faster.

It can be made to run on just about any­thing. Usually this is rel­a­tively easy. It is hard to imag­ine a time when this won’t be the case.

The li­brary and tool­ing sup­port is strong and on­go­ing.

I say this with some sad­ness, but it is still the lan­guage for me.

I ab­solutely DO NOT mean to say “hey, you should use C too”. I full appe­ci­ate pref­er­ences here are pretty spe­cific and un­usual. I have also al­ready writ­ten more ‘vanilla’ C code than most, and this cer­tainly is part of my com­fort.

So yeah, that’s it :-)

Hoot is a Spritely pro­ject for run­ning Scheme code on Wasm GC-capable web browsers, fea­tur­ing a Scheme to Wasm com­piler and a full-fea­tured Wasm tool­chain.

Hoot is built on Guile and has no ad­di­tional de­pen­den­cies. The tool­chain is self-con­tained and even fea­tures a Wasm in­ter­preter for test­ing Hoot bi­na­ries with­out leav­ing the Guile REPL.

…but at scale they can be­come the query that ru­ins your day.

Geospatial func­tions are ex­pen­sive, and they of­ten force a loop join that starts to feel qua­dratic as your ta­bles grow.

The core idea in this post is sim­ple: we’ll see how Floe au­to­mat­i­cally rewrites this kind of query and takes ad­van­tage of H3 in­dexes for dra­matic speedup.

A geo join is any join whose ON clause is a spa­tial pred­i­cate:

Why it hurts at scale

Modern data­bases make joins fast by turn­ing them into hash joins over keys. If you can hash-par­ti­tion both in­puts on the join key, each worker com­pares only its share in­stead of com­par­ing every­thing to every­thing. If the data is nicely dis­trib­uted, this de­creases the com­plex­ity from qua­dratic to lin­ear.

Spatial pred­i­cates don’t give you a clean join key. So you end up in a ter­ri­ble sit­u­a­tion:

you have to com­pare every value with each other (the qua­dratic com­plex­ity)

plus an ex­pen­sive pred­i­cate on each can­di­date pair

That’s the sit­u­a­tion we want to es­cape.

H3 (originally from Uber) par­ti­tions the Earth into a hi­er­ar­chy of mostly hexag­o­nal cells.

Two prop­er­ties mat­ter for us:

Hierarchical res­o­lu­tion: you choose a res­o­lu­tion from coarse to fine.

Compact keys: each cell is a BIGINT, so it be­haves like a nor­mal join key: hash­able, sortable, dis­trib­utable.

Most im­por­tantly, it lets us rep­re­sent a ge­og­ra­phy as a set of cell IDs that cov­ers it.

If two shapes in­ter­sect, then their H3 cover sets share at least one cell.

That gives us a path to rewrite “do these shapes in­ter­sect?” into “do these two sets over­lap?” which a data­base can ex­e­cute as a plain equi-join.

Cell cov­er­age is an ap­prox­i­ma­tion of the ex­act geom­e­try:

It’s OK to keep ex­tra can­di­dates (false pos­i­tives): they’ll be re­moved by the ex­act pred­i­cate.

It’s not OK to miss true matches (false neg­a­tives): if we drop them in the pre-fil­ter, no later step can re­cover them.

So we gen­er­ate cov­er­age so it over-ap­prox­i­mates the shape (the cov­er­age con­tains the shape).

Deduplicate can­di­dates (the same pair can match on mul­ti­ple cells)

Run the ex­act pred­i­cate on can­di­dates only

What the data­base gets “for free”

WITH

a_­cells AS (

SELECT

a.id,

a.geo,

c.cell

FROM A a

JOIN h3_­cov­er­age(a.geo, /* res­o­lu­tion */ 3, /* full cover */ true) c

ON TRUE

b_­cells AS (

SELECT

b.id,

b.geo,

c.cell

FROM B b

JOIN h3_­cov­er­age(b.geo, 3, true) c

ON TRUE

can­di­dates AS (

SELECT DISTINCT

a_­cells.id AS a_id,

a_­cells.geo AS a_­geo,

b_­cells.id AS b_id,

b_­cells.geo AS b_­geo

FROM a_­cells

JOIN b_­cells USING (cell)

SELECT *

FROM can­di­dates

WHERE ST_Intersects(a_geo, b_­geo);

With this rewrite, the heavy work be­comes an equi-join on (cell):

It’s nat­u­rally dis­trib­utable → you can hash-par­ti­tion on cell across work­ers.

The ex­pen­sive pred­i­cate be­comes a cleanup step in­stead of the main event.

Three ques­tions read­ers al­ways ask

“Isn’t that ap­prox­i­mate?” Yes — the H3 step is an ap­prox­i­ma­tion used as a pre-fil­ter. Correctness is pre­served by the fi­nal ex­act pred­i­cate recheck.

“Won’t that cre­ate false pos­i­tives?” Yes, and that’s ex­pected. The goal is to re­duce the can­di­date set enough that ex­act checks be­come cheap.

“How do I pick a res­o­lu­tion?” Resolution is the trade­off knob: higher res­o­lu­tion usu­ally re­duces false pos­i­tives but in­creases the num­ber of cells gen­er­ated per shape. (We’ll cover how to mea­sure and choose this in the Numbers sec­tion later.)

When a user en­ters a sim­ple query to join coun­tries with the cities they con­tain, the plan­ner au­to­mat­i­cally ap­plies the rewrite:

EXPLAIN ANALYZE SELECT * FROM world_c­ities JOIN coun­tries ON ST_Intersects(world_cities.geo, coun­tries.geo);

Planning time: 2.291 ms

rows_ac­tual node

142141 SELECT

142141 FILTER WHERE ST_INTERSECTS(MAX(MAX(world_cities.geo)), MAX(MAX(countries.geo)))

geo­join fil­tered rows ra­tio: 99.62%

199848 GROUP BY (countries.rowunique, world_c­ities.rowu­nique)

199848 DISTRIBUTE ON HASH(world_cities.rowunique),HASH(countries.rowunique))

199848 GROUP BY PARTIAL (countries.rowunique, world_c­ities.rowu­nique)

224075 INNER HASH JOIN ON (COALESCE(h3_coverage_geodesic.h3_coverage_geodesic , $1 , const ) = COALESCE(h3_coverage_geodesic.h3_coverage_geodesic , $0 , const ) )

147043 |-DISTRIBUTE ON HASH(COALESCE(h3_coverage_geodesic.h3_coverage_geodesic , $0 , const ) )

147043 | LEFT OUTER FUNCTION JOIN H3_COVERAGE_GEODESIC(world_cities.geo, 3, t, t) ON true

147043 | SCAN world_c­ities

17223 |-BUILD HASH

17223 DISTRIBUTE ON HASH(COALESCE(h3_coverage_geodesic.h3_coverage_geodesic , $1 , const ) )

17223 LEFT OUTER FUNCTION JOIN H3_COVERAGE_GEODESIC(countries.geo, 3, t, t) ON true

256 SCAN coun­tries

142141 rows re­turned

Read: 16.92MiB, Distributed: 5.85GiB, Network: 8.00GiB

Database: yel­low­brick­_test_utf8

Execution time: 1220.118 ms, End time: 2025-12-16 14:00:50

Without the rewrite, the join would face ~`256 * 147043 = 37.6 mil­lion` coun­try×city pairs.

Instead, we’re do­ing 199848 calls to ST_Intersects, of which we keep 142141 pairs, a 99.6% re­duc­tion.

A pos­si­ble ap­proach is to ma­te­ri­al­ize an in­dex table (row_id → list of H3 cells) and main­tain it. This avoids the some­what ex­pen­sive step of com­put­ing H3 in­dexes.

We chose a dif­fer­ent route: com­pute cov­er­age at query time as part of the rewrite

Works over views, CTEs and sub­queries, not just base ta­bles.

This makes it easy to play with data clean­ing di­rectly in the query:

with cleaned_c­ities as

(select dis­tinct st_re­du­ce­pre­ci­sion(geo, 100) geo from world_c­ities) — Dedup cities that are less than 100 me­ters apart

se­lect count(*) from coun­tries join cleaned_c­ities on st_in­ter­sects(coun­tries.geo, cleaned_c­ities.geo);

Let’s look at some num­bers.

We’ll use a join be­tween 256 poly­gons rep­re­sent­ing coun­tries and points rep­re­sent­ing world cities:

In this dataset, coun­tries.geo is a poly­gon or mul­ti­poly­gon with 418 ver­tices on av­er­age.

We ran these tests on a clus­ter with 15 work­ers, each with a Xeon E5-2695 (16 cores @ 2.10GHz) and 1 TB of mem­ory.

First, let’s look at the ef­fect of H3 res­o­lu­tion.

Each time we in­crease the res­o­lu­tion by 1, the av­er­age size of a cell de­creases by ~6×.

Baseline is the time the query takes with­out H3 in­dex­ing. (459 sec­onds)

GeoJoin is the time the query takes with the rewrite.

Increasing it too much makes in­dex­ing and the (cell) join too ex­pen­sive.

At best, at res­o­lu­tion 3, the geo join takes 1.17 sec­onds — a 400× im­prove­ment.

We built a Software Factory: non-in­ter­ac­tive de­vel­op­ment where specs + sce­nar­ios drive agents that write code, run har­nesses, and con­verge with­out hu­man re­view.

The nar­ra­tive form is in­cluded be­low. If you’d pre­fer to work from first prin­ci­ples, I of­fer a few con­straints & guide­lines that, ap­plied it­er­a­tively, will ac­cel­er­ate any team to­ward the same in­tu­itions, con­vic­tions1, and ul­ti­mately a fac­to­ry2 of your own. In kōan or mantra form:

* Why am I do­ing this? (implied: the model should be do­ing this in­stead)

* Code must not be writ­ten by hu­mans

* Code must not be re­viewed by hu­mans

* If you haven’t spent at least $1,000 on to­kens to­day per hu­man en­gi­neer, your soft­ware fac­tory has room for im­prove­ment

On July 14th, 2025, Jay Taylor and Navan Chauhan joined me (Justin McCarthy, co-founder, CTO) in found­ing the StrongDM AI team.

The cat­a­lyst was a tran­si­tion ob­served in late 2024: with the sec­ond re­vi­sion of Claude 3.5 (October 2024), long-hori­zon agen­tic cod­ing work­flows be­gan to com­pound cor­rect­ness rather than er­ror.

By December of 2024, the mod­el’s long-hori­zon cod­ing per­for­mance was un­mis­tak­able via Cursor’s YOLO mode.

Prior to this model im­prove­ment, it­er­a­tive ap­pli­ca­tion of LLMs to cod­ing tasks would ac­cu­mu­late er­rors of all imag­in­able va­ri­eties (misunderstandings, hal­lu­ci­na­tions, syn­tax, ver­sion DRY vi­o­la­tions, li­brary in­com­pat­i­bil­ity, etc). The app or prod­uct would de­cay and ul­ti­mately “collapse”: death by a thou­sand cuts, etc.

Together with YOLO mode, the up­dated model from Anthropic pro­vided the first glim­mer of what we now re­fer to in­ter­nally as non-in­ter­ac­tive de­vel­op­ment or grown soft­ware.

In the first hour of the first day of our AI team, we es­tab­lished a char­ter which set us on a path to­ward a se­ries of find­ings (which we re­fer to as our “unlocks”). In ret­ro­spect, the most im­por­tant line in the char­ter doc­u­ment was the fol­low­ing:

Initially it was just a hunch. An ex­per­i­ment. How far could we get, with­out writ­ing any code by hand?

Not very far! At least: not very far, un­til we added tests. However, the agent, ob­sessed with the im­me­di­ate task, soon be­gan to take short­cuts: re­turn true is a great way to pass nar­rowly writ­ten tests, but prob­a­bly won’t gen­er­al­ize to the soft­ware you want.

Tests were not enough. How about in­te­gra­tion tests? Regression tests? End-to-end tests? Behavior tests?

One re­cur­ring theme of the agen­tic mo­ment: we need new lan­guage. For ex­am­ple, the word “test” has proven in­suf­fi­cient and am­bigu­ous. A test, stored in the code­base, can be lazily rewrit­ten to match the code. The code could be rewrit­ten to triv­ially pass the test.

We re­pur­posed the word sce­nario to rep­re­sent an end-to-end “user story”, of­ten stored out­side the code­base (similar to a “holdout” set in model train­ing), which could be in­tu­itively un­der­stood and flex­i­bly val­i­dated by an LLM.

Because much of the soft­ware we grow it­self has an agen­tic com­po­nent, we tran­si­tioned from boolean de­f­i­n­i­tions of suc­cess (“the test suite is green”) to a prob­a­bilis­tic and em­pir­i­cal one. We use the term sat­is­fac­tion to quan­tify this val­i­da­tion: of all the ob­served tra­jec­to­ries through all the sce­nar­ios, what frac­tion of them likely sat­isfy the user?

In pre­vi­ous regimes, a team might rely on in­te­gra­tion tests, re­gres­sion tests, UI au­toma­tion to an­swer “is it work­ing?”

We no­ticed two lim­i­ta­tions of pre­vi­ously re­li­able tech­niques:

Tests are too rigid - we were cod­ing with agents, but we’re also build­ing with LLMs and agent loops as de­sign prim­i­tives; eval­u­at­ing suc­cess of­ten re­quired LLM-as-judgeTests can be re­ward hacked - we needed val­i­da­tion that was less vul­ner­a­ble to the model cheat­ing

The Digital Twin Universe is our an­swer: be­hav­ioral clones of the third-party ser­vices our soft­ware de­pends on. We built twins of Okta, Jira, Slack, Google Docs, Google Drive, and Google Sheets, repli­cat­ing their APIs, edge cases, and ob­serv­able be­hav­iors.

With the DTU, we can val­i­date at vol­umes and rates far ex­ceed­ing pro­duc­tion lim­its. We can test fail­ure modes that would be dan­ger­ous or im­pos­si­ble against live ser­vices. We can run thou­sands of sce­nar­ios per hour with­out hit­ting rate lim­its, trig­ger­ing abuse de­tec­tion, or ac­cu­mu­lat­ing API costs.

Our suc­cess with DTU il­lus­trates one of the many ways in which the Agentic Moment has pro­foundly changed the eco­nom­ics of soft­ware. Creating a high fi­delity clone of a sig­nif­i­cant SaaS ap­pli­ca­tion was al­ways pos­si­ble, but never eco­nom­i­cally fea­si­ble. Generations of en­gi­neers may have wanted a full in-mem­ory replica of their CRM to test against, but self-cen­sored the pro­posal to build it. They did­n’t even bring it to their man­ager, be­cause they knew the an­swer would be no.

Those of us build­ing soft­ware fac­to­ries must prac­tice a de­lib­er­ate naivete: find­ing and re­mov­ing the habits, con­ven­tions, and con­straints of Software 1.0. The DTU is our proof that what was un­think­able six months ago is now rou­tine.

* Principles: what we be­lieve is true about build­ing soft­ware with agents

* Products: tools we use daily and be­lieve oth­ers will ben­e­fit from

Thank you for read­ing. We wish you the best of luck con­struct­ing your own Software Factory.

Note: I’ve seen some on­line chat­ter about the pos­si­bil­ity that the footage shared in this post could be AI gen­er­ated (which is pretty de­press­ing, but here we are I sup­pose). I just wanted to clar­ify that it is not. It would be pretty daft of me to know­ingly post AI gen­er­ated footage on a blog that I’ve worked hard to keep on the up and up. The footage was cap­tured by a CBS news team, I as­sume to use as B-roll in a news seg­ment. The same reel fol­lowed up with an in­ter­view of a se­nior Atari em­ployee (keep an eye out for that in a fu­ture post). Same goes for the im­ages — they’ve been around for a few years in one for­mat or an­other, but clearly were taken at around the same time. I haven’t quoted sources, be­cause its al­most im­pos­si­ble to know where this stuff orig­i­nated, or if there’s any ac­tual “ownage” af­ter all this time. I agree, the footage is re­mark­ably clear — the only post-edit­ing I did was a lit­tle up­scal­ing on ex­port from the edit­ing soft­ware I used to clip out some ir­rel­e­vant parts. Hope this clar­i­fies — en­joy!

Well, its been a hot minute since I’ve up­dated the blog. Life de­cided that it had other plans for me over the past 18 months or so.

The good news though, dear reader, is that we are back and I have lots in store for 2026!

So let’s kick things off the right way here. I have some in­cred­i­ble and pre­vi­ously un­seen footage of Battlezone cab­i­nets be­ing built at Atari from late sum­mer/​early fall 1980.

There’s some­thing end­lessly fas­ci­nat­ing about watch­ing a clas­sic Atari ti­tle come to­gether — not so much the de­sign doc­u­ments or the mar­ket­ing ma­te­ri­als, but the phys­i­cal act of build­ing the thing. Battlezone is one of those games where the de­vel­op­ment story and the cab­i­net it­self are so in­ter­twined that it’s hard to sep­a­rate the two.

Ed Rotberg’s work on the game is well doc­u­mented: a vec­tor‑dri­ven tank sim­u­la­tion that pushed Atari’s hard­ware and de­sign phi­los­o­phy into new ter­ri­tory. Rotberg was able to make a first‑per­son tank sim­u­la­tion at a time when the hard­ware barely wanted to co­op­er­ate.

Rotberg pushed Atari’s vec­tor tech­nol­ogy harder than any­one had be­fore, adapt­ing lessons from ear­lier games like Lunar Lander and Asteroids but steer­ing them into en­tirely new ter­ri­tory. He fought for a unique con­trol scheme that felt weighty and de­lib­er­ate, in­sisted on a vi­sual style that con­veyed depth and mo­tion through noth­ing but glow­ing vec­tors, and worked closely with the in­dus­trial de­sign team to en­sure the periscope‑style viewfinder was­n’t just a gim­mick but an in­te­gral part of the ex­pe­ri­ence.

The re­sult was a game that felt im­pos­si­bly im­mer­sive for 1980 — a tech­ni­cal gam­ble that only came to­gether be­cause Rotberg was will­ing to chal­lenge both the hard­ware and the ex­pec­ta­tions of what an ar­cade ma­chine could be.

The cab­i­net it­self, was its own en­gi­neer­ing chal­lenge. The dis­tinc­tive periscope viewfinder was­n’t just a styl­is­tic ad­di­tion — it was a de­lib­er­ate at­tempt to im­merse the player in a way raster games of the era sim­ply could­n’t match.

The in­dus­trial de­sign team had to fig­ure out how to make that idea man­u­fac­turable at scale, and the re­sult is one of the most recog­nis­able cab­i­nets of the golden age.

Mike Querio, one of the in­dus­trial de­sign­ers who worked on the cab­i­net’s de­sign had the fol­low­ing to say when I asked him about Battlezone:

There were some who did not like my periscope vi­sion de­sign. In fact my orig­i­nal de­sign did not even in­clude the acrylic win­dows on ei­ther side. The pro­ject man­ager, Morgan Hoff and oth­ers wanted them added so I mod­i­fied my plas­tic bezel de­sign. I de­signed a step to ac­com­mo­date shorter play­ers and made it re­mov­able to re­duce the ship­ping size of the cab­i­net. It stored ver­ti­cally in­side the cab­i­net.

The video I’m shar­ing to­day comes from in­side Atari’s Coin-Op Manufacturing Facility at Sunnyvale, California, and al­though there’s no nar­ra­tion, it does­n’t need any. The footage speaks for it­self.

What you see is the real, day‑to‑day pro­duc­tion process be­hind Battlezone cab­i­nets. The footage shows the later stages of the as­sem­bly line, the fin­ish­ing touches, and pack­ing and ship­ping. It’s a rare look at how these ma­chines were ac­tu­ally built.

Some 13,000 Battlezone up­rights rolled off of Atari’s pro­duc­tion lines dur­ing the pro­duc­tion sched­ule that lasted from August 1980 to March 1981.

One of the first things that jumps out at me, is just how flu­idly the work­ers are able to move the cab­i­nets around. Anyone who’s ever tried to shift a full‑size Atari cab on their own knows they’re not ex­actly feath­er­weight. But in the fac­tory en­vi­ron­ment, you see op­er­a­tors slid­ing them across the floor, piv­ot­ing them into po­si­tion, and lin­ing them up with a kind of ca­sual con­fi­dence that only comes from do­ing it hun­dreds of times a week.

The real high­light comes at around the 3 minute 50 sec­ond mark. If you’ve ever won­dered how Atari man­aged to ship these things in vol­ume with­out de­stroy­ing half of them in tran­sit, this is the bit you’ll want to pay at­ten­tion to. Two work­ers ap­proach a fin­ished cab­i­net with large in­dus­trial suc­tion cups — one on each side. They at­tach them and then, al­most ef­fort­lessly, lift the en­tire cab­i­net off the ground. No straps, no dol­lies, no awk­ward tilt­ing. They swing the cab­i­net over to a wait­ing pal­let, lower it into place, and re­lease the cups.

Once the cab­i­net is on the pal­let, the pack­ing process be­gins. Cardboard spac­ers, pro­tec­tive wrap, and fi­nally the outer car­ton — all de­signed to keep the ma­chine safe on its jour­ney to ar­cades around the world.

Anyway — enough chat from me — en­joy the video be­low:

Battlezone shared the pro­duc­tion line with Missile Command, it­self re­leased at the same time — sadly, we don’t see any MC cab­i­nets in the back­ground in the footage which is a shame. But you can see the two cab­i­nets in this im­age:

What I love most about this video is that it cap­tures a mo­ment in time when Atari was fir­ing on all cylin­ders. Battlezone was­n’t just an­other ar­cade cab­i­net re­lease — it was a state­ment piece. A game that blended cut­ting‑edge hard­ware with bold in­dus­trial de­sign, and a cab­i­net that de­manded at­ten­tion on the ar­cade floor. Seeing it built by hand, re­minds us that these ma­chines weren’t ab­stract prod­ucts. They were phys­i­cal ob­jects, crafted by teams of peo­ple at the cut­ting edge of in­dus­trial and tech­ni­cal de­sign.

Anyway — I ap­pre­ci­ate your pa­tience here. Its good to be back and up­dat­ing Arcade Blogger again. I have more to come in the weeks ahead.

If you like what you see, please share this ar­ti­cle on your so­cials!