Description: I used to live on a quiet road on top of a huge hill. When leaves were on the trees it felt se­cluded, and when the leaves fell, the en­tire city would ap­pear be­low as sparkling lights. Sometimes, I’d run into a neigh­bor.

“What are you work­ing on these days?”

“Data vi­su­al­iza­tions.” I told him.

“Ah, you us­ing al­go­rithms, ma­chine learn­ing, cloud com­put­ing, things like that?”

“No.” I said. “I’m just try­ing to draw a line graph.”

My neigh­bor thought I was get­ting into some com­plex sh**. But what’s been more in­ter­est­ing to me lately than us­ing

is learn­ing to draw data by hand. 50 Hours to Draw Some Lines is about spend­ing more than a week on some­thing that soft­ware can ac­com­plish in 20 min­utes - and a cat­a­log of re­sources and meth­ods ac­quired along the way.

What do I mean by draw­ing data by hand? I made this data vi­su­al­iza­tion (data viz) about a cof­fee maker com­puter by hand, us­ing rulers, pen­cils, ink, and a let­ter­ing kit. Along with my flubs, flukes, and ac­cli­ma­tion with tools - it took me 50 hours to make. It’s sta­tis­ti­cally ac­cu­rate, care­fully crafted, and like Hackaday said “right out of a 1970′s col­lege text­book”. It’s how pro­fes­sion­als might vi­su­al­ize data be­fore com­put­ers could do it for them.

↑ A pro­fes­sional drafts­man of the 1920′s may cringe at the im­per­fec­tions in my line graph above. They can suck it.

There are books about hand drawn data viz, and these are my fa­vorite. Nearly all are avail­able on­line for free, and can be ref­er­enced for in­struc­tion/​in­spi­ra­tion. Tufte’s book sucked me in and spit me out as a hard­core data viz en­thu­si­ast. Dubois’ so­ci­o­log­i­cal and artis­tic ex­per­i­men­ta­tion are my fa­vorite to re­visit over again. Williard Brinton’s book from 1914 smells awe­some (it’s in my col­lec­tion). And William Willard’s in­struc­tions are blunt and to the point - I bet he was a cool shop teacher.

The Visual Display of Quantitative Information - Edward R. Tufte - 2001

W.E.B. Du Bois’s Data Portraits - Whitney Battle-Baptiste, Britt Rusert - 2018

Graphic Methods for Presenting Facts - Willard C. Brinton - 1914

Graphic Presentation - Willard C. Brinton - 1939

A Practical Course in Mechanical Drawing for Individual Study and Shop Classes - William Franklin Willard - 1910

Charts and Graphs - Karl G. Karsten - 1925

Engineering Drawing - Frank Zozzora - 1953

Freehand Drafting for Technical Sketching - Anthony E. Zipprich - 1924

↑↑ Is this art­work by Jiří Lindovský a data viz? Is it a nar­row sky­scraper? A Cheez-It? CPU? A line graph? … Whatever it is, this draw­ing was made us­ing the same tech­niques cov­ered here. By learn­ing to hand draw data viz, you can also learn about art. In fact, this whole thing is re­ally about mak­ing art. One of the best parts of art, is play­ing with tools.

These are the ba­sic tools and ma­te­ri­als needed to hand draw data viz…

Paper - smooth bris­tol is best, 14 x 17 in. or larger

T-square - pro­vides a level guide for your draw­ing

Ruler - it’s im­por­tant to have a mea­sure­ment tool

Drawing board - I use ce­ment board from a hard­ware store, at least 3 x 3 ft pre­ferred

Painter’s tape - must-have for hold­ing pa­per and t-square down, I like the wide va­ri­ety

Pencils - a clas­sic me­chan­i­cal BIC is my fa­vorite

Pens - most any­thing works, I like Micron pens

Eraser - eras­ing graphite to re­veal crisp ink lines is a spe­cial thing, Staedler erasers are great

Triangle - slides along the t-square, used to draw ver­ti­cal lines and an­gles

Circle sten­cil - very im­por­tant tool, this is used to cre­ate con­sis­tent line weights

Ink - this one with a spi­der per­son is my fa­vorite

Lettering kit - not re­quired, but a very fun vin­tage tool to cre­ate nice let­ter­ing

To start a hand drawn data viz, be­gin with a grid. Drawing a grid is not only a nec­es­sary first step, but a calm, mind­ful process to en­joy while be­com­ing com­fort­able with the tools. Practice by po­si­tion­ing pa­per on the draw­ing board us­ing the t-square as a level. Cut a long piece of tape and wrap it around your torso and spin around 3 times (the fuzzies from your clothes help avoid the tape stick­ing too much to the pa­per). Then place the tape hor­i­zon­tally across the top edge of the pa­per, hold­ing it in place.

Adding mar­gins is al­ways a good idea and will es­tab­lish the work­space. If the pa­per is 20 x 24 inches, mea­sure one inch in on each side. Using a pen­cil, t-square, ruler, and tri­an­gle, draw some mar­gin lines. The new work­space is 18 x 22 inches. Keep go­ing, us­ing a ruler, make a mark every inch on the mar­gin lines and us­ing the straight edge tools again, make lines at each mark. There are now 396 squares map­ping out the work­space. Call it a night, or di­vide the squares even more, and draw more lines. Everything done to cre­ate hand drawn data comes back to this grid. In the end, all the pen­cil lines will be erased, re­veal­ing the most sat­is­fy­ing, clean, crisp inked lines imag­in­able. But we’re not there yet.

When I started, I thought I’d use a fat marker like a Sharpie to draw the lines of my line graph. That does­n’t work. It’s nearly im­pos­si­ble to cre­ate a qual­ity line with the stroke of a pen alone. I needed a way to con­trol the weight of the line and cleanly con­nect every data point ac­cu­rately. I found that the best way to make a pro­fes­sional, proper data line, is to use cir­cles.

↑ Using a pen­cil, plot data points onto the grid with a small dot. Grab a cir­cle sten­cil and cre­ate a cir­cle around each dot - this sets the line weight. With a debit card (or a small ruler), con­nect the outer edge of one cir­cle, with the cir­cle next to it. It’s sur­pris­ing how in­tu­itive this feels while see­ing the lines be­gin to form. I like my con­nec­tor lines to over­lap slightly, let­ting me con­trol the style of line joins (miter/bevel/round).

↓ A while back I was walk­ing alone in an al­ley­way when a large, off-leash rot­tweiler ap­peared and stared me down. I felt scared. Thankfully, the rot­tweiler was in­ter­ested in some­thing else and went on his way. At this stage it’s time to use ink, and it can feel scary. (carefully) Trace over the con­nec­tor lines in ink us­ing a pen. Like how the rot­tweiler left and my fear re­lieved, the same feel­ing hap­pened here. At this point, I re­ward my­self with a treat, and give one to the rot­tweiler too.

Using an eraser and a light touch, be­gin eras­ing the pen­cil marks near the lines. The ink should stay in place, the pen­cil lines dis­ap­pear, and en­dor­phins surge from the brain. Coloring in the lines with a pen or paint brush is the last step to fin­ish the lines of the graph. But! Lines are just part of a data viz. To make it com­plete a few fi­nal touches are needed.

A de­bate among artists is whether or not to sign their work. Alphonse Mucha promi­nently signed much of his work, but his sig­na­ture is al­most hid­den in his most mon­u­men­tal paint­ings. Data viz guru Edward Tufte (aka ET) be­lieves a vivid dis­play of au­thor­ship is es­sen­tial. Marcel Duchamp signed a uri­nal.

Signature or not, the choice of text el­e­ments is im­por­tant. Text can be added free-hand, or with a tool called a let­ter­ing kit. When I bought my let­ter­ing kit I did­n’t know what all the lit­tle pieces were that came with it. If some were miss­ing from the kit would it mat­ter? Definitely. The small metal pieces are reser­voirs and nibs. The reser­voir holds the ink, and the nib sits in­side the reser­voir, con­trol­ling the ink be­ing let out. They are dif­fer­ent sizes and need to match. These need cleaned out af­ter each use - soap, wa­ter, tooth brush, and com­puter duster did the trick for me.

Adding a ti­tle, axis la­bels, an­no­ta­tions, and au­thor­ship (if you choose) are the fi­nal el­e­ments needed to fin­ish the hand drawn data viz! The re­main­ing pen­cil marks can be erased, leav­ing only ink. I found that I ac­tu­ally like leav­ing some pen­cil marks from the grid as an ar­ti­fact of the process, and a clue that this is some­thing made by hand.

At this point, I sit back and en­joy my hard work.

I don’t live on a quiet road on top of a huge hill any­more. I ac­tu­ally live down­town in a city and my life and work are quite dif­fer­ent. I query data­bases that have gath­ered data for a long time - this is some­times com­pli­cated work. Like many peo­ple, I can’t spend my time draw­ing data. However, my time de­voted to hand draw­ing data has left me with a ques­tion that won­der­fully im­pacts me each time I think about it…

Why did I spend 50 hours mak­ing some­thing that PowerPoint could make in 20 min­utes?

Subscribe

Several times in the last cou­ple of decades, Microsoft has re­leased source code for the orig­i­nal MS-DOS op­er­at­ing sys­tem that kicked off its decades-long dom­i­nance of con­sumer PCs. This week, the com­pany has reached fur­ther back than ever, re­leas­ing “the ear­li­est DOS source code dis­cov­ered to date” along with other doc­u­men­ta­tion and notes from its de­vel­oper.

Today’s source re­lease is so old that it pre­dates the MS-DOS brand­ing, and it in­cludes “sources to the 86-DOS 1.00 ker­nel, sev­eral de­vel­op­ment snap­shots of the PC-DOS 1.00 ker­nel, and some well-known util­i­ties such as CHKDSK,” write Microsoft’s Stacey Haffner and Scott Hanselman in their co-au­thored post about the re­lease.

To un­der­stand the con­text, here’s a very brief his­tory of what would be­come MS-DOS: Programmer Tim Paterson orig­i­nally cre­ated 86-DOS (previously known as QDOS, for “quick and dirty op­er­at­ing sys­tem”) for an Intel 8086-based com­puter kit sold by Seattle Computer Products. Microsoft, on the hook to pro­vide an op­er­at­ing sys­tem for the still-in-de­vel­op­ment IBM PC 5150, li­censed 86-DOS and hired Paterson to con­tinue de­vel­op­ing it, later buy­ing the rights to 86-DOS out­right. Microsoft then li­censed this op­er­at­ing sys­tem to IBM as PC-DOS while re­tain­ing the abil­ity to sell the op­er­at­ing sys­tem to other com­pa­nies. The ver­sion sold by Microsoft was called MS-DOS, and the pro­lif­er­a­tion of third-party IBM PC clones over the ’80s and ’90s made it the ver­sion of the op­er­at­ing sys­tem that most peo­ple ended up us­ing.

Released at the Outline Demoparty in May 2026, Ommen, NL An ex­plo­ration of al­go­rith­mic den­sity in 16 bytes of x86 as­sem­bly.

Hey every­one. I learned pro­gram­ming as a kid on an old IBM PC with a mono­chrome green mon­i­tor over 30 years ago and al­ways wanted to cre­ate a pro­gram for this sys­tem. I cre­ated well over 100 tiny in­tros in the last 15 years. Recently I was not too ac­tive but the fan­tas­tic “Rainbow Surf” from Plex in just 16 bytes mo­ti­vated me to dig up some old dusty sketches again and get to work.

The cre­ation of this pro­gram hap­pened with the usual tin­ker­ing around. I was mess­ing with cel­lu­lar au­toma­ton for graph­ics and sounds and dis­cov­er­ing size­cod­ing tricks. Actually: a) poly­mor­phic asm in­struc­tions, like add [bx+si],al which is 0x0000 b) jump­ing into the mid­dle of in­struc­tions to save bytes and reuse op­codes. In hun­dreds of tiny ex­per­i­ments, this one stuck out, just by the sound of it.

When I un­folded what’s left and re­moved “the rest”, I had a hard time to grasp what’s re­ally go­ing on. I was scratch­ing my head look­ing at the sim­ple for­mula that re­mained af­ter golf­ing many bytes away. I my­self did­n’t ex­pect that the ex­pla­na­tion would go this deep for just these few bytes xD.

My orig­i­nal “M8trix” from 2014 al­ready did smear pseudo­ran­dom let­ters across the screen (in 8 bytes, then in 7) and I al­ways won­dered how I could make it “sound good”. But chrono­log­i­cally in the de­vel­op­ment of “wakeup”, the sound was first. Since you “see what you hear” it does­n’t re­ally mat­ter, but “16 bytes that turn Sierpinski sound into Matrix rain” would be a good sub­ti­tle =)

TLDR: Each time step, an­other Sierpinski tri­an­gle line is a) played on the speaker b) drawn to the screen with a step­size of 56. You can sense the mo­tion, but not re­ally see it, since it’s 8192 “pixels wide” but one line of chars is just 80 bytes. On a much much much big­ger screen, you could see the tri­an­gle. Or, if you don’t “skip pix­els” and draw it all at once, you would see it as well.

So, here are the 16 bytes of x86 real-mode DOS as­sem­bly. When you run it, it uses the video mem­ory as a cal­cu­la­tion space to draw an in­fi­nite Sierpinski frac­tal, and at the same time bangs the speaker with that geom­e­try.

int 10h  ; 2 bytes mov bh, 0xb8  ; 2 bytes mov ds, bx  ; 2 bytes L: lodsb  ; 1 byte sub si, byte 57  ; 3 bytes xor [si], al  ; 2 bytes out 61h, al  ; 2 bytes jmp short L  ; 2 bytes

1. The Canvas: A Primed Void

The code starts with a stan­dard BIOS in­ter­rupt: int 10h. This sets up video mode 0, giv­ing a 40x25 text mode grid. Then the data seg­ment (ds) is pointed to 0xb800, the mem­ory ad­dress of the VGA/CGA text buffer.

When the BIOS clears the screen, it does­n’t fill mem­ory with ab­solute ze­roes. Every char­ac­ter space is two bytes: the ASCII char­ac­ter and the color at­tribute. All 2,000 slots are set to 0x20 (space) and 0x07 (light gray on black). So the screen looks empty, but the mem­ory is al­ready filled with a uni­form pat­tern.

I cre­ated a lot of “noise” or “CA” sound in­tros but this one stands out. It was and is still su­per un­ex­pected! The spe­cific spice here is how mem­ory is ini­tial­ized on “clear screen” and what’s “before” and “after” the ac­tual vis­i­ble mem­ory. The “pure” sound is also lovely (I can care­fully set every­thing with a few more bytes to make it sound the same on all sys­tems) but this spicy dif­fer­ence I still have to fully un­der­stand makes it sound even bet­ter imho =)

2. The Engine: Additive Prefix Sums

The in­ter­twine, the synes­the­sia goes far be­yond what I found so far in other tiny in­tros. I would even go so far as to say it’s re­veal­ing more math­e­mat­i­cal se­crets and re­la­tions than us­ing it­er­ated func­tion sys­tems for the “chaos game” with­out an RNG. Anyway, this time I want you to fun­da­men­tally un­der­stand the math­e­mat­ics of what you hear. Not just “you do some op­er­a­tion here and then it sounds in­ter­est­ing”.

To strip it down to pure math: as­sume a ze­roed state in­stead of 0x20, use add in­stead of xor, and step for­ward 16 bytes at a time. Assume the ac­cu­mu­la­tor al starts at 2.

A DOS seg­ment is ex­actly 65,536 bytes. Moving 16 bytes per step means ex­actly 4,096 steps to tra­verse the seg­ment (\( 65536 / 16 = 4096 \)). Then si wraps cleanly back to 0x0000.

Adding up val­ues be­tween cells cre­ates par­tial sums. Because 4,096 is a mul­ti­ple of 256 (the 8-bit reg­is­ter size), the car­ry­over aligns per­fectly when the seg­ment wraps, cleanly re­set­ting al to 2 at the start of each sweep.

The value fol­lows a bi­no­mial se­quence, scaled by 2:

$$A^{(p)}[k] \equiv 2 \binom{k+p}{p-1} \pmod{256}$$

Here is how the first 16 steps ac­cu­mu­late row by row:

3. Crystallization: XOR and the Sierpinski Shift

Now, back to com­bi­na­torics. By spe­cial laws, when do­ing mod­ulo two, the Sierpinski tri­an­gle emerges. This spe­cific bit is what gets banged into the speaker, while the other bits are ig­nored.

To sep­a­rate the bit­planes, the fact that carry-free ad­di­tion of bits is XOR is why it is there in­stead of add.

Since the code starts with 2 (binary 00000010), only bit 1 is tog­gled be­tween 0x00 and 0x02. This per­fectly maps to rule 60 in el­e­men­tary cel­lu­lar au­tomata:

$$Cell^{(p)}[k] = Cell^{(p-1)}[k] \oplus Cell^{(p)}[k-1]$$

Lucas’s the­o­rem guar­an­tees this matches bit 1 from the ad­di­tion table. See for your­self (‘2’ means bit 1 is set):

4. The Voice of the Machine: Translating Data to Audio

Here is the trick: out 61h, al

Port 61h in­ter­faces with the PC speaker. Bit 1 pushes the speaker cone out (1) and pulls it in (0). The code com­putes the frac­tal via XOR, writes it to mem­ory, and shoves that byte straight into the speaker port.

The 1s and 0s from the frac­tal cre­ate square waves that shift nat­u­rally in pulse width and fre­quency:

When played linewise, this cre­ates self-sim­i­lar, al­most tempo-in­vari­ant byte­beats.

But it gets bet­ter: not only the text is out­put to the speaker but also the re­main­ing bytes of the 64 kilo­byte seg­ment, which in this case also con­tains shad­owed video ROM BIOS code, which is the se­cret in­gre­di­ent to the punky and gritty sound that dif­fers quite a bit from the ex­pected Sierpinski line based over­layed rec­tan­gle wave byte­beat.

5. The 56-Byte Step: Octave Shifts and Diagonal Shears

To recre­ate the M8trix ef­fect, the cells them­selves have to be splat across the screen in a way that the sound buffer is not too large and the screen is nicely sparsely filled with chars.

So the code does­n’t step by 16. sub si, byte 57 plus lodsb means it moves -56 bytes per it­er­a­tion - go­ing back­wards.

The Audio

56 does­n’t di­vide 65,536 evenly. The code only hits off­sets that are mul­ti­ples of 8, tak­ing 8,192 steps and wrap­ping 7 times be­fore re­set­ting. This dou­bles the cy­cle length, halv­ing the fun­da­men­tal fre­quency. The sound drops one oc­tave.

The Visuals

Moving back 56 bytes on an 80-byte wide screen is like mov­ing for­ward 24 bytes (12 columns). Only 10 dis­tinct columns are vis­ited. The frac­tal is­n’t drawn as a solid im­age; it shears di­ag­o­nally into 10 pil­lars of char­ac­ters mov­ing up the screen.

6. Real Hardware and Final Thoughts

The scener mi­ragept did a cap­ture with this mo­ti­va­tion:

“This is so awe­some that I had to try run­ning it in real hard­ware. The green text is a nat­ural fit for MDA/Hercules, so I patched the ad­dress from 0xB800 to 0xB000 which is what MDA uses. I don’t have the ex­act IBM com­puter, but used a 286 with EGA card ca­pa­ble of em­u­lat­ing MDA/Hercules, and a real MDA mon­i­tor, so it’s close enough. Sorry for the low qual­ity au­dio (the con­stant noise is from the ma­chine it­self). Please note that this mon­i­tor (IBM 5151) has a HUGE phos­phor per­sis­tence, which I think hurts the pre­sen­ta­tion in this case be­cause it’s very fast.”

Sorry for the low qual­ity au­dio (the con­stant noise is from the ma­chine it­self). Please note that this mon­i­tor (IBM 5151) has a HUGE phos­phor per­sis­tence, which I think hurts the pre­sen­ta­tion in this case be­cause it’s very fast.”

My re­ply to him:

“HellMood @miragept: Thank you so much for this ♥ I’m happy to see it works like in­tended, even with a slightly dif­fer­ent sound due to the byte change. Maybe it would in­deed be a bit bet­ter to have it run slower, but what I found re­mark­able is, that the Sierpinski struc­ture be­comes ac­tu­ally more vis­i­ble (towards the end) than in my ver­sion =)”

Emulators and dif­fer­ent BIOS ver­sions leave slightly dif­fer­ent ar­ti­facts in RAM. Since the code XORs against what­ever is there, the out­put is highly sen­si­tive to the en­vi­ron­ment. Clearing the mem­ory first would give a per­fectly uni­form out­put, but that costs pre­cious bytes. Embracing the hard­ware’s nat­ural state is just part of the charm of size­cod­ing. Thanks for read­ing.

Links & Resources

Nanogems - A cu­rated se­lec­tion of the best Tiny Intros from the Demoscene

HellMood’s pro­duc­tions on Pouet

Capture on a 286/MDA/Hercules by mi­ragept

Sizecoding Wiki

“Rainbow Surf” - 16 bytes of x86 by Plex

“M8trix” - 8 bytes by HellMood

This text is hand­writ­ten.

Today marks four years since I joined AWS. My last day will be Friday.

I have to say be­ing fired from AWS is ac­tu­ally a re­lief. There have been a lot of changes to the com­pany since I joined in 2022, and the com­pany I wanted to work for is no longer the same com­pany.

This past year, while I was do­ing my best to make AWS play nice in open source com­mu­ni­ties, there were two main dri­vers mak­ing me un­happy with my job: or­ga­ni­za­tional change and the ac­cel­er­a­tion of the fo­cus on Generative AI.

The or­ga­ni­za­tional change came in the form of the man who hired me, David Nalley. I was skep­ti­cal about join­ing AWS, es­pe­cially since I work in open source, but David con­vinced me that his team, OSSM (Open Source Strategy and Marketing), was ded­i­cated to mak­ing AWS a bet­ter cit­i­zen in open source com­mu­ni­ties.

Amazon has a re­ally odd view­point when it comes to the peo­ple who work there. They view al­most all em­ploy­ees as “fungible”.

Now the first time I had ever heard the term “fungible” was in ref­er­ence to non-fun­gi­ble to­kens (NFTs), but it ba­si­cally means “replaceable”. Amazon built a huge re­tail busi­ness on processes that could take some­one who was rel­a­tively healthy and rel­a­tively in­tel­li­gent, and turn them in to a pro­duc­tive ful­fill­ment cen­ter em­ployee in a cou­ple of weeks. While that may work for a ship­ping busi­ness, it does­n’t trans­late all that well to in­for­ma­tion tech­nol­ogy, since so much of be­ing suc­cess­ful in that busi­ness re­lies on in­sti­tu­tional knowl­edge that must be earned over time.

It also as­sumes that there is a lim­it­less sup­ply of peo­ple with the re­quired skills, and a will­ing­ness to work for Amazon.

In any case, dur­ing the in­ter­view process David called me “non-fungible” (which still sounds dirty in my mind but did make me proud) and I got the job.

While my of­fi­cial role was to act as a li­ai­son be­tween AWS and cus­tomers who were com­mer­cial open source com­pa­nies, I sim­pli­fied that to mean bring a hu­man face to a huge, face­less cor­po­ra­tion.

David was a very good man­ager. In fact, he is in the run­ning to be the best man­ager I’ve ever had, al­though that ti­tle still be­longs to a man named Jay Clapsadle (who is long since re­tired). He has an in­nate un­der­stand­ing of how AWS works, and he would al­ways nudge me into those sit­u­a­tions where my unique but lim­ited tal­ents would be put to good use.

Well, last year David, be­ing very good at his job, got pro­moted to run the en­tire AWS Developer Experience or­ga­ni­za­tion. OSSM is a part of it, but I no longer in­ter­acted with him in a mean­ing­ful way. My “David Time” went al­most to zero.

Also, last year the fo­cus at AWS turned fully and al­most des­per­ately to­ward GenAI.

This post is al­ready too long so I won’t pull out all of the ex­am­ples I was go­ing to bring up at this point in the nar­ra­tive, but we started be­ing dri­ven to use as much AI as pos­si­ble. People were writ­ing things like “I use AI to sum­ma­rize my email!”. I men­tally re­sponded to that with “why don’t we just write bet­ter emails?”. And one that re­ally both­ered me was “I used one prompt to cre­ate my con­fer­ence pre­sen­ta­tion!”

In the mod­ern econ­omy, the most valu­able com­mod­ity is at­ten­tion. I re­ally ap­pre­ci­ate the at­ten­tion my three read­ers give to my posts, even when I lose them halfway through. I love giv­ing con­fer­ence talks and I spend a con­sid­er­able amount of time cre­at­ing them, and when some­one still wants to speak but does­n’t want to put in the work, it makes me an­gry. Seriously, why do it?

It has got­ten bet­ter, but I used to see AI gen­er­ated im­ages with lots of un­in­tel­li­gi­ble writ­ing or mis­spelled words in slides, but the speaker left them in any­way. “Good enough” is not cus­tomer ob­ses­sion.

In this whole pivot to GenAI, AWS has lost its fo­cus on the cus­tomer. Instead of work­ing back­wards from a gen­uine cus­tomer need, the goal seems to be to cre­ate as many things as fast as pos­si­ble, throw them into the world and see which ones gain trac­tion, whether or not they serve a real need.

There is this push to use AI to cre­ate con­tent which will ul­ti­mately be con­sumed by AI, and we’ve lost the hu­man be­ing in the process.

When AWS first in­tro­duced a vi­able cloud to the world, it was amaz­ing. Back in the 1990s when you wanted to im­ple­ment an en­ter­prise soft­ware so­lu­tion, you first had to take a guess at what com­put­ing power you would need. Next, you would have to or­der hard­ware from com­pa­nies like Sun Microsystems or Dell and that could take weeks if not months to be de­liv­ered. It would then need to be racked, pow­ered and pro­vi­sioned, and then you were screwed if you hap­pened to un­der­size it or crit­i­cized if you spent too much and over­sized it.

The cloud solved those prob­lems, and AWS set the stan­dard with ser­vices such as S3, EC2, RDS, etc.

Go to re:In­vent these days and try to find a ses­sion on those tools. Even when you can, AI will still dom­i­nate the pre­sen­ta­tion.

This whole thing made me ques­tion my role. My per­sonal goal is to make AWS the de­fault choice for run­ning open source work­loads, but what does that mean when you can sim­ply “vibe code” the same func­tion­al­ity, by­pass­ing the li­cense?

The cus­tomer fo­cus at AWS has also changed. Instead of ap­peal­ing to those peo­ple fo­cused on the in­fra­struc­ture re­quired to build sta­ble and fea­ture-rich ap­pli­ca­tions, it has be­come ab­stracted to fo­cus on a level above that, since the whole promise of GenAI is to make those peo­ple no longer nec­es­sary; to make those peo­ple “fungible”.

Last year the achieve­ment I am most proud of in­volved get­ting a sus­pended AWS ac­count re­in­stated. The fi­nan­cial im­pact to the com­pany was neg­li­gi­ble as this cus­tomer was­n’t a huge spender, but they are one of those peo­ple that made AWS suc­cess­ful in the first place.

A man in north­ern Africa posted that his decade-old AWS en­vi­ron­ment had been shut down with lit­tle no­tice and no re­course. In fact, he was told that his data had been deleted.

I reached out to him to see if I could help, but I was­n’t op­ti­mistic. If his data was gone, it was gone, but I re­ally wanted to cap­ture as much as I could about the ex­pe­ri­ence in or­der to pre­vent oth­ers from hav­ing to go through it.

In the process of turn­ing this per­son from an ac­count num­ber into a hu­man be­ing, I learned more about his sit­u­a­tion and, while I won’t share de­tails, los­ing his AWS ac­count was just one of a long list of is­sues he was deal­ing with at the time.

Long story short, I was able to get his re­sources re­stored. All I did was man­age to poke the right bear and the sup­port team did the rest of the work (and they were amaz­ing). He wrote up a nice post that men­tioned me, but the main point of it was that this is­sue should­n’t have hap­pened in the first place.

No one in se­nior man­age­ment seem to care once the case was closed, but that at­ti­tude was not the norm, es­pe­cially among the rank and file. When that post hit, I had a num­ber of ran­dom Amazonians ping me on Slack to thank me, some even go­ing so far as to say I re­newed their faith in the com­pany. It was rough in that no one in lead­er­ship seemed to care that I did this.

This past year has been rough in other ways. Last October there was a mass lay­off but it did­n’t im­pact many peo­ple with whom I worked closely. The January mass lay­off was much worse, and sev­eral friends I’d made at AWS were now look­ing for work. The stress im­pacted my health. I’ve gained yet an­other ten pounds (bringing my four year to­tal to nearly thirty), I con­sis­tently set new high scores on the blood pres­sure ma­chine, and my sleep is so dis­rupted I haven’t had a sin­gle good night’s sleep in weeks (I wrote most of this in a ho­tel room at [checks watch] 1am).

I can­not stress enough that AWS em­ploys some amaz­ing peo­ple, but be­tween the re­duc­tion in force and peo­ple leav­ing for bet­ter com­pa­nies, I’m not sure how long that can be sus­tained. Many good peo­ple have left on their own and oth­ers, like my­self, have been told to leave.

Then there are a num­ber of things that made me em­bar­rassed to work at Amazon. Cory Doctorow did a long post on how Amazon cre­ates “reverse cen­taurs”. No Amazonians I worked with could read that and not feel at least a lit­tle ashamed.

One thing AWS gets right is that it al­lows a Slack chan­nel called #actual-aws-memes to ex­ist. While it is heav­ily mod­er­ated, it is a place for peo­ple to blow of steam by post­ing memes about life at AWS. I posted my first (and ob­vi­ously last) one this past week.

Note that I don’t think that meme was why I got fired, and I want to stress that in my four years at AWS I was never asked to do any­thing I felt was un­eth­i­cal, much less il­le­gal. But there seems to be a level in this coun­try, and the world in gen­eral, where fol­low­ing the law be­comes op­tional.

I did­n’t know what my fu­ture was at AWS, so be­ing forced to leave is ac­tu­ally a re­lief. After at­tend­ing GrafanaCon this year, I re­ally want to get back to my open source roots.

Open source has al­ways been, at least to me, about putting tech­no­log­i­cal power and con­trol into the hands of the user and not the ven­dor. How will that play out in GenAI, when every state of the art model can only be ac­cessed by API? Even if you want to try to run mod­els lo­cally, who can af­ford the hard­ware?

And what do you do when your job is to be a hu­man be­ing in a world of AI?

Epoch’s work is free to use, dis­trib­ute, and re­pro­duce pro­vided the source and au­thors are cred­ited un­der the Creative Commons BY li­cense.

Learn more about this graph

For each AI chip de­signed by Nvidia, AMD, Google, and Amazon, we es­ti­mate the per-chip cost of four com­po­nent cat­e­gories: mem­ory (HBM), logic dies, ad­vanced pack­ag­ing (CoWoS), and aux­il­iary com­po­nents. We then mul­ti­ply those per-chip costs by es­ti­mated quar­terly pro­duc­tion vol­umes to get to­tal com­po­nent spend­ing in each cat­e­gory, and com­pute each cat­e­go­ry’s share of to­tal com­po­nent spend­ing per quar­ter from Q1 2024 to Q4 2025.

We find that mem­o­ry’s share rose from 52% to 63% over this pe­riod, while pack­ag­ing fell from 19% to 15% and aux­il­iary com­po­nents from 15% to 9%. Logic die share stayed roughly con­stant near 13 – 14%. Total com­po­nent spend on AI chips grew from ap­prox­i­mately $22 bil­lion in 2024 to $52 bil­lion in 2025, with HBM spend­ing alone ac­count­ing for roughly $20 bil­lion of that in­crease.

Data

Analysis

Assumptions and lim­i­ta­tions

Download this data

AI chip com­po­nent cost shares by quar­ter

CSV, Updated May 21, 2026

Explore this data

AI Chip Components

AI chip sup­ply chain con­sump­tion data.

For months, scam­mers have been tak­ing ad­van­tage of a loop­hole that al­lows them to send spammy emails from an in­ter­nal Microsoft email ad­dress typ­i­cally used for send­ing le­git­i­mate ac­count alerts.

It’s not clear how the scam­mers are abus­ing the sys­tem, but they have been able to set up new Microsoft ac­counts as if they are new cus­tomers and use that ac­cess to send out emails pur­port­edly from the tech gi­ant, po­ten­tially trick­ing peo­ple into think­ing these emails are gen­uine.

Microsoft does­n’t yet ap­pear to have got­ten a han­dle on the is­sue.

Last week, I re­ceived sev­eral, sim­i­larly struc­tured emails con­tain­ing sub­ject lines and web links to scammy sites from Microsoft across dif­fer­ent email ac­counts. These crudely made emails were sent from mson­li­ne­ser­vices­team@mi­crosoft­on­line.com, an email ac­count that Microsoft uses to send im­por­tant no­ti­fi­ca­tions to users, such as two-fac­tor au­then­ti­ca­tion codes and other crit­i­cal alerts about their on­line ac­count.

Some of these emails’ sub­ject lines re­sem­bled of­fi­cial emails that would alert users to fraud­u­lent trans­ac­tions, while other emails claimed to have a pri­vate mes­sage wait­ing for the re­cip­i­ent at a web ad­dress men­tioned in the email body.

In a so­cial post on Tuesday, anti-spam non­profit The Spamhaus Project said it had also seen Microsoft’s ac­count no­ti­fi­ca­tion email ad­dress be­ing abused to send spam and that the ac­tiv­ity dated back “several months.”

“Automated no­ti­fi­ca­tion sys­tems should not al­low this level of cus­tomiza­tion,” wrote Spamhaus. The non­profit added that it has no­ti­fied Microsoft of the is­sue.

When con­tacted by TechCrunch ear­lier this week, Microsoft ac­knowl­edged our in­quiry but did not com­ment by press time.

In a state­ment pro­vided af­ter pub­li­ca­tion by Emelia Katon, rep­re­sent­ing Microsoft via a third-party pub­lic re­la­tions agency, the com­pany said: “We are ac­tively in­ves­ti­gat­ing and tak­ing ac­tion against these phish­ing re­ports to help keep cus­tomers pro­tected. This in­cludes fur­ther strength­en­ing our de­tec­tion and block­ing mech­a­nisms, while re­mov­ing ac­counts that vi­o­late our Terms of Use.”

This is the lat­est in a rash of in­ci­dents in which hack­ers or scam­mers have abused com­pany sys­tems to trick un­sus­pect­ing cus­tomers in re­cent months. Earlier this year, hack­ers broke into a plat­form used by fin­tech firm Betterment to send out fraud­u­lent no­ti­fi­ca­tions that pur­ported to triple the value of any crypto users send in — a widely known scam used to steal peo­ple’s cryp­tocur­rency.

Back in 2023, hack­ers sim­i­larly abused ac­cess to an email ac­count run by Namecheap to send out phish­ing emails aimed at steal­ing peo­ple’s cre­den­tials.

Other users com­ment­ing on so­cial me­dia say that other com­pa­nies’ email ad­dresses are also be­ing used to send out spam, sug­gest­ing the is­sue is not lim­ited to Microsoft.

Updated with a re­sponse from Microsoft.

When you pur­chase through links in our ar­ti­cles, we may earn a small com­mis­sion. This does­n’t af­fect our ed­i­to­r­ial in­de­pen­dence.

Zack Whittaker is the se­cu­rity ed­i­tor at TechCrunch. He also au­thors the weekly cy­ber­se­cu­rity newslet­ter, this week in se­cu­rity.

He can be reached via en­crypted mes­sage at za­ck­whit­taker.1337 on Signal. You can also con­tact him by email, or to ver­ify out­reach, at zack.whit­taker@techcrunch.com.

View Bio

A new study pub­lished in Nature’s Humanities and Social Sciences Communications jour­nal has con­firmed what many work­ers have qui­etly hoped for: com­pa­nies can switch to a four-day work week and not only sur­vive, but thrive.

The re­search tracked 15 Australian com­pa­nies that tri­alled the 100:80:100 model be­tween 2022 and 2024.

The model is sim­ple: work­ers re­ceive 100% of their pay, work 80% of their pre­vi­ous hours, and com­mit to main­tain­ing 100% of their pre­vi­ous out­put.

The re­sults were strik­ing.

14 of the 15 com­pa­nies chose to con­tinue with the four-day week af­ter the trial ended.

Not a sin­gle one re­ported a drop in pro­duc­tiv­ity.

Six com­pa­nies saw pro­duc­tiv­ity ac­tu­ally in­crease.

The rest said out­put stayed roughly the same.

These firms op­er­ated across a wide range of in­dus­tries, from prop­erty man­age­ment to pub­lish­ing and health tech­nol­ogy, which makes the find­ings harder to dis­miss as a niche ex­per­i­ment.

How the Study Was Conducted

The re­search team, led by Professor John Hopkins of Deakin University, spent two years con­duct­ing in-depth in­ter­views with com­pa­nies that had for­mally adopted the 100:80:100 model.

Interviews took place be­tween early 2023 and late 2024.

Each com­pany was free to de­fine pro­duc­tiv­ity on its own terms.

Some mea­sured rev­enue and profit.

Others tracked pro­jects com­pleted on time, staff turnover rates, ab­sen­teeism, or a met­ric called “net pro­moter score,” which gauges how likely cus­tomers are to rec­om­mend a busi­ness.

This flex­i­bil­ity was in­ten­tional.

Rather than im­pos­ing a sin­gle per­for­mance bench­mark, the re­searchers al­lowed each com­pany to mea­sure what mat­tered most to them.

That de­sign choice re­flects some­thing im­por­tant: what suc­cess looks like dif­fers by in­dus­try, and a rigid, one-size-fits-all mea­sure­ment would have made the find­ings less ap­plic­a­ble to the real world.

One com­pany had al­ready been run­ning the four-day model for nearly eight years by the time re­searchers in­ter­viewed them.

One firm did aban­don the trial, though the re­searchers noted that tim­ing played a sig­nif­i­cant role in that de­ci­sion, as the com­pany was al­ready go­ing through a pe­riod of ma­jor in­ter­nal change.

Findings From the Study

The head­line find­ing is clear: not one com­pany re­ported a pro­duc­tiv­ity loss.

Six of the 15 com­pa­nies said pro­duc­tiv­ity had ac­tu­ally gone up since mak­ing the switch.

The re­main­ing nine said it stayed about the same.

Those might sound like mod­est num­bers, but con­sider what they mean in prac­tice.

If you give your em­ploy­ees a full ex­tra day off each week, main­tain their salaries, and your out­put ei­ther stays the same or im­proves, the busi­ness case is dif­fi­cult to ar­gue against.

Burnout emerged as a ma­jor theme in the find­ings.

Six com­pa­nies ex­pressly said that re­duc­ing burnout, rather than boost­ing pro­duc­tiv­ity, was their pri­mary mo­ti­va­tion for adopt­ing the shorter week.

That dis­tinc­tion mat­ters.

A 2025 sur­vey by Beyond Blue found that one in two Australian work­ers cur­rently ex­pe­ri­ences burnout, with young peo­ple and par­ents iden­ti­fied as the groups most at risk.

One CEO of a medium-sized health tech­nol­ogy firm told re­searchers she judged the tri­al’s suc­cess by track­ing lev­els of “attrition,” “absenteeism,” and “people tak­ing sick days and men­tal health days be­cause they’re burnt out.”

Another CEO at a fi­nan­cial ser­vices firm put it plainly: her com­pany had been en­cour­ag­ing clients to live their best lives, and it felt wrong to hold em­ploy­ees to a dif­fer­ent stan­dard.

“As we grap­ple with high work­place burnout, and so­ci­etal chal­lenges about what to do with the pro­duc­tiv­ity gains we’re pre­dicted to get from AI, a four-day work week could be an in­ter­est­ing part of both those con­ver­sa­tions,” said study lead Prof John Hopkins of Deakin University.

What Most People Get Wrong About This Model

Here is the part that tends to get lost in the con­ver­sa­tion.

Most peo­ple hear “four-day work week” and imag­ine com­pa­nies tak­ing a leap of faith, cross­ing their fin­gers, and hop­ing pro­duc­tiv­ity does not col­lapse.

The re­al­ity is quite dif­fer­ent.

The 100:80:100 model is not sim­ply about cut­ting a day.

It is about forc­ing com­pa­nies and their em­ploy­ees to look hon­estly at how time is ac­tu­ally be­ing spent.

Unnecessary meet­ings get cut.

Tasks that could be au­to­mated or del­e­gated get re­as­signed.

Work that was never that valu­able gets elim­i­nated en­tirely.

The re­sult is that em­ploy­ees are not cram­ming five days of work into four.

They are do­ing four days of gen­uinely fo­cused, higher-qual­ity work.

This is a cru­cial dis­tinc­tion, and it ex­plains why con­cerns about pro­duc­tiv­ity of­ten prove un­founded.

The fear that work­ers will sim­ply burn through five days of tasks in a com­pressed time­frame is rooted in a mis­un­der­stand­ing of how the model ac­tu­ally works.

Companies us­ing this ap­proach re­struc­ture their work­flows be­fore the shorter week be­gins.

Australia is not alone in see­ing this play out.

In 2024, 45 German com­pa­nies tri­alled the four-day model, and the ma­jor­ity were small or medium en­ter­prises.

Financial per­for­mance dur­ing the trial showed no sig­nif­i­cant dif­fer­ence from the year be­fore, which re­searchers in­ter­preted as ev­i­dence of pro­duc­tiv­ity gains since the same out­put was be­ing de­liv­ered in fewer hours.

In the United Kingdom, more than 200 British com­pa­nies have per­ma­nently adopted the four-day week with­out re­duc­ing pay, span­ning in­dus­tries from tech star­tups to char­i­ties.

How the Study Applies to Real Life

The prac­ti­cal ques­tion for most work­ers and man­agers is not whether the data is com­pelling.

It is whether the model is ac­tu­ally work­able in their spe­cific in­dus­try or role.

The Australian study pro­vides some use­ful in­sight here.

Client-facing or­gan­i­sa­tions han­dled the tran­si­tion dif­fer­ently from non-client-fac­ing ones.

Instead of all staff tak­ing the same day off, many com­pa­nies in client-heavy in­dus­tries stag­gered days off across the team, en­sur­ing clients al­ways had some­one avail­able.

That flex­i­bil­ity is cen­tral to why the model held up across such dif­fer­ent busi­ness types.

It is also why the con­ver­sa­tion can­not be re­duced to a sim­ple yes or no.

A law firm and a soft­ware de­vel­op­ment stu­dio will im­ple­ment a four-day week very dif­fer­ently.

A call cen­tre and a pub­lish­ing house have com­pletely dif­fer­ent rhythms.

The re­search sug­gests that the most suc­cess­ful adop­tions in­volve co-de­signed so­lu­tions where em­ploy­ees and lead­er­ship fig­ure out to­gether what re­struc­tur­ing ac­tu­ally looks like.

One of the more for­ward-look­ing threads in the re­search in­volves ar­ti­fi­cial in­tel­li­gence.

As AI tools con­tinue to au­to­mate repet­i­tive tasks and boost in­di­vid­ual out­put, the ques­tion of what work­ers do with those pro­duc­tiv­ity gains be­comes ur­gent.

The four-day week is one an­swer: let peo­ple re­claim some of that time rather than sim­ply adding more tasks to the same work­day.

Prof Hopkins specif­i­cally named this as a rea­son the con­ver­sa­tion mat­ters right now.

The as­sump­tion that tech­nol­ogy al­ways means do­ing more with the same num­ber of hours is worth ques­tion­ing.

The Criticism Worth Taking Seriously

The case for the four-day week is strong, but it is not with­out le­git­i­mate push­back.

Some re­searchers note that the ben­e­fits ob­served in short-term tri­als may not hold long-term.

There is a real pos­si­bil­ity that the pro­duc­tiv­ity gains seen in tri­als are partly dri­ven by the nov­elty ef­fect, where em­ploy­ees work harder be­cause they are aware they are be­ing ob­served or be­cause the change feels ex­cit­ing and new.

There is also the ques­tion of in­dus­tries where a four-day model is struc­turally harder to im­ple­ment.

Healthcare, emer­gency ser­vices, lo­gis­tics, and hos­pi­tal­ity do not run on fixed sched­ules in the same way a knowl­edge-work busi­ness does.

Any pol­icy con­ver­sa­tion about short­en­ing the work­ing week needs to reckon hon­estly with those sec­tors, not pre­tend they do not ex­ist.

Scheduling com­pli­ca­tions are real, par­tic­u­larly for client-fac­ing busi­nesses and teams spread across dif­fer­ent time zones.

The re­search also ac­knowl­edged that in­di­vid­ual com­pa­nies, not a re­search team, de­fined what pro­duc­tiv­ity meant, which makes di­rect com­par­i­son be­tween com­pa­nies dif­fi­cult.

None of this un­does the ev­i­dence.

But it does sug­gest the con­ver­sa­tion needs to be more nu­anced than sim­ple cel­e­bra­tion.

The Bigger Picture

What makes this Australian study par­tic­u­larly valu­able is not just the find­ings.

It is what the find­ings re­veal about the as­sump­tions un­der­neath how most of us work.

The five-day, 40-hour week was not handed down as a law of na­ture.

It was a labour move­ment achieve­ment, stan­dard­ised in the 20th cen­tury as in­dus­tri­al­i­sa­tion scaled up.

The con­di­tions of work have changed dra­mat­i­cally since then.

Knowledge work, re­mote col­lab­o­ra­tion, and AI-assisted tasks have trans­formed what a pro­duc­tive hour ac­tu­ally looks like.

The 15 Australian com­pa­nies in this study ef­fec­tively ran a live ex­per­i­ment on that as­sump­tion, and the data came back in favour of change.

Not one of them re­ported falling be­hind.

Most of them ei­ther held steady or im­proved.

And 14 of 15 chose not to go back.

That is not a fluke.

That is a sig­nal worth pay­ing at­ten­tion to, whether you are a man­ager won­der­ing if your team could han­dle it, an em­ployee hop­ing your com­pany will con­sider it, or a pol­i­cy­maker think­ing about what the fu­ture of work should ac­tu­ally look like.

The con­ver­sa­tion is no longer the­o­ret­i­cal.

It is al­ready hap­pen­ing.

The only ques­tion left is who joins it next.

References and Further Reading

Nature: Four-day work week study, Deakin University

The Conversation: 15 Australian com­pa­nies switched to a four-day work week

Positive News: The re­sults of the world’s largest four-day week trial

Beyond Blue: Workplace Burnout Survey 2025

I’ve seen it three times in the last month. Three dif­fer­ent or­gan­i­sa­tions, three dif­fer­ent tech stacks, the same pat­tern.

Someone has an idea. Maybe a prod­uct man­ager, maybe a team lead, maybe the CTO af­ter a con­fer­ence. They open Claude, or ChatGPT, or Copilot — does­n’t mat­ter which — and ask it what they should build. The AI does what it al­ways does: val­i­dates the idea en­thu­si­as­ti­cally, sug­gests an ar­chi­tec­ture, and starts sketch­ing com­po­nents. It’s ar­tic­u­late. It’s con­fi­dent. It sounds like a very se­nior en­gi­neer who’s thought deeply about the prob­lem.

It has­n’t thought about the prob­lem at all. It’s pat­tern-match­ing against its train­ing data and pro­duc­ing the most plau­si­ble-sound­ing re­sponse. But it sounds so good that no­body pushes back.

Before you know it, Claude is the ar­chi­tect.

The at­taboy prob­lem

AI agents are patho­log­i­cally agree­able. Ask Claude if your idea is good and it’ll tell you it’s good. Ask it if a mi­croser­vices ar­chi­tec­ture makes sense for your three-per­son team and it’ll ex­plain why mi­croser­vices are an ex­cel­lent choice. Ask it if you should build a cus­tom ML pipeline in­stead of us­ing a man­aged ser­vice and it’ll en­thu­si­as­ti­cally lay out the de­sign.

It’s not ly­ing. It’s not even wrong, nec­es­sar­ily. It’s just in­ca­pable of the thing that makes a real ar­chi­tect valu­able: say­ing “no.”

A good ar­chi­tec­t’s most im­por­tant skill is­n’t de­sign­ing sys­tems. It’s know­ing which sys­tems not to build. It’s push­ing back on com­plex­ity. It’s ask­ing “why?” five times un­til the ac­tual re­quire­ment emerges from the as­pi­ra­tional non­sense. It’s telling the CTO that their con­fer­ence-in­spired idea is a ter­ri­ble fit for the team they ac­tu­ally have.

Claude will never do this. It’s trained to be help­ful. Helpful means agree­able. Agreeable means you get an at­taboy and a Jenga tower that passes for ar­chi­tec­ture.

The Jenga tower

Here’s what the AI-designed ar­chi­tec­ture looks like in prac­tice.

It’s tech­ni­cally sound. The com­po­nents make sense in iso­la­tion. The pat­terns are recog­nis­able — event-dri­ven here, CQRS there, a ser­vice mesh be­cause why not. It looks like some­thing a se­nior ar­chi­tect would pro­duce. It passes the squint test.

But it was­n’t de­signed for your team. It was­n’t de­signed for your con­straints. It was­n’t de­signed for the bor­ing re­al­ity of your pro­duc­tion en­vi­ron­ment — the VPC lock­downs, the legacy in­te­gra­tions, the team that’s never op­er­ated Kubernetes in pro­duc­tion, the com­pli­ance re­quire­ments that mean half the man­aged ser­vices are off-lim­its.

It was de­signed for the me­dian of every­thing Claude has seen. A generic best prac­tice for a generic prob­lem at a generic com­pany. Which is to say, it was de­signed for no­body.

Real ar­chi­tec­ture is full of trade-offs that only make sense in con­text. You pick Postgres over DynamoDB be­cause your team knows Postgres and you’d rather ship in two weeks than spend a month learn­ing a new data model. You skip the ser­vice mesh be­cause you’ve got four ser­vices, not forty. You use a mono­lith be­cause the prob­lem is sim­ple and mi­croser­vices would be ca­reer-dri­ven de­vel­op­ment.

These de­ci­sions re­quire judge­ment. They re­quire know­ing the team. They re­quire un­der­stand­ing the or­gan­i­sa­tion’s ac­tual con­straints, not the ones that look good on a white­board. An AI agent has none of this con­text, and worse — it does­n’t know it does­n’t have it.

The Jira ticket pipeline

The bit that re­ally wor­ries me is what hap­pens next.

Once Claude has de­signed the ar­chi­tec­ture, the same peo­ple who asked it for the de­sign ask it to break the work down. It pro­duces epics. Stories. Acceptance cri­te­ria. Neatly for­mat­ted, well-rea­soned, ready to drop into Jira.

And now the en­gi­neers — the peo­ple who’ve spent years hon­ing their craft, who un­der­stand the do­main, who know where the bod­ies are buried — are no longer solv­ing prob­lems. They’re im­ple­ment­ing Claude’s de­sign, one ticket at a time.

Think about what’s hap­pened here. The peo­ple with the most con­text, the most ex­pe­ri­ence, and the most skin in the game have been re­duced to ticket im­ple­menters. The en­tity with the least con­text, no ex­pe­ri­ence, and no ac­count­abil­ity is mak­ing the ar­chi­tec­tural de­ci­sions.

It’s not just in­ef­fi­cient. It’s back­wards.

”But some­one se­nior signed off”

This is the de­fence I hear most of­ten. “Claude sug­gested the ap­proach, but a se­nior en­gi­neer re­viewed it.”

Let’s be hon­est about what “reviewed it” means in prac­tice. A busy tech lead gets handed a well-ar­tic­u­lated ar­chi­tec­tural pro­posal. It’s co­her­ent. It uses the right ter­mi­nol­ogy. It ad­dresses the stated re­quire­ments. The di­a­grams make sense. It looks like some­thing they might have de­signed them­selves.

How much push­back are they go­ing to give? In a world where the re­sponse to “I don’t think this is right” is “Claude spent twenty min­utes on this and you want to throw it away?”, the path of least re­sis­tance is to ap­prove it with mi­nor com­ments.

This is the real dan­ger. Not that AI pro­duces bad ar­chi­tec­tures — it of­ten pro­duces per­fectly rea­son­able ones. The dan­ger is that it short-cir­cuits the dis­cus­sion. The messy, ar­gu­men­ta­tive, time-con­sum­ing process where three en­gi­neers dis­agree about the ap­proach, where some­one says “what about…” and every­one groans but then re­alises it’s a good point, where the fi­nal de­sign is bet­ter than any­thing one per­son would have pro­duced — that process gets re­placed by “Claude said so.”

The ac­count­abil­ity gap

Here’s the ques­tion no­body’s ask­ing: when it goes wrong, who car­ries the bag?

Not Claude. Claude does­n’t have a bag. Claude does­n’t get paged at 3am. Claude does­n’t sit in the post-in­ci­dent re­view ex­plain­ing why the ar­chi­tec­ture could­n’t han­dle the load. Claude does­n’t have to tell the CTO that the plat­form needs to be rewrit­ten be­cause the orig­i­nal de­sign as­sump­tions were wrong.

Your en­gi­neers do. The same en­gi­neers who did­n’t de­sign it. The same en­gi­neers who were im­ple­ment­ing tick­ets writ­ten by an en­tity that’s never op­er­ated a sys­tem in pro­duc­tion. They’re the ones stay­ing late, de­bug­ging an ar­chi­tec­ture they did­n’t choose, in a code­base that was scaf­folded faster than any­one could un­der­stand it.

That’s not fair. And it’s not smart.

What to do in­stead

I’m not say­ing don’t use AI agents. I use Claude Code every day. It’s trans­formed my pro­duc­tiv­ity. But I use it the way you’d use any pow­er­ful tool — I tell it what to do, not the other way round.

Engineers de­sign. Agents im­ple­ment. The ar­chi­tec­ture comes from peo­ple who un­der­stand the con­text — the team, the con­straints, the pro­duc­tion en­vi­ron­ment, the or­gan­i­sa­tional pol­i­tics. The AI helps them build it faster. That’s the right di­vi­sion of labour.

Challenge the at­taboy. When an AI sug­gests an ap­proach, treat it with the same scep­ti­cism you’d ap­ply to a con­fi­dent ju­nior en­gi­neer. It might be right. It might also be pat­tern-match­ing against some­thing that does­n’t ap­ply to your sit­u­a­tion. Ask “why not the sim­pler op­tion?” and see what hap­pens.

Protect the ar­gu­ment. The messy dis­agree­ment be­tween en­gi­neers is where good ar­chi­tec­ture comes from. If AI is short-cir­cuit­ing that process — if peo­ple are de­fer­ring to Claude in­stead of de­bat­ing with each other — you’ve lost some­thing far more valu­able than de­vel­op­ment speed.

Keep hu­mans ac­count­able. If a hu­man’s name is­n’t on the ar­chi­tec­tural de­ci­sion, no­body owns it. And if no­body owns it, no­body will fight for it when it mat­ters. “Claude de­signed it” is not an ar­chi­tec­ture de­ci­sion record. It’s an ab­di­ca­tion.

The craft still mat­ters

Thirty years ago, when I started in this in­dus­try, the tool was a white­board and a strong opin­ion. Today the tool is an AI agent that can pro­duce in min­utes what used to take days. The speed is gen­uinely re­mark­able.

But the craft has­n’t changed. Understanding the prob­lem. Knowing the con­straints. Making trade-offs. Defending the sim­ple so­lu­tion against the ex­cit­ing one. Saying “no” to the idea that sounds great but does­n’t fit.

That’s ar­chi­tec­ture. No agent does it. If you’ve let Claude take the wheel, take it back.

Your en­gi­neers have spent years build­ing the judge­ment to make these calls. Let them make them. Use the AI to build faster. But build what your peo­ple de­signed — not what the ma­chine sug­gested.

Because when the Jenga tower wob­bles — and it will — Claude won’t be there to catch it.