Last night, I was re­jected from yet an­other pitch night. It was just the pre-in­ter­view, and the prob­lem was­n’t my prod­uct. I al­ready have MRR. I al­ready have users who de­pend on it every day.

The feed­back was sim­ply: “What do you even need fund­ing for?”

I hear this time and time again when I try to grow my ideas. Running lean is in my DNA. I’ve built tools you might have used, like web­se­quence­di­a­grams.com, and niche prod­ucts you prob­a­bly haven’t, like eh-trade.ca. That ob­ses­sion with ef­fi­ciency leads to suc­cess­ful boot­strap­ping, and hon­estly, a lot of VCs hate that.

Keeping costs near zero gives you the ex­act same run­way as get­ting a mil­lion dol­lars in fund­ing with a mas­sive burn rate. It’s less stress­ful, it keeps your ar­chi­tec­ture in­cred­i­bly sim­ple, and it gives you ad­e­quate time to find prod­uct-mar­ket fit with­out the pres­sure of a board breath­ing down your neck.

If you are tired of the mod­ern “Enterprise” boil­er­plate, here is the ex­act play­book of how I build my com­pa­nies to run on nearly noth­ing.

The naive way to launch a web app in 2026 is to fire up AWS, pro­vi­sion an EKS clus­ter, set up an RDS in­stance, con­fig­ure a NAT Gateway, and ac­ci­den­tally spend $300 a month be­fore a sin­gle user has even looked at your land­ing page.

The smart way is to rent a sin­gle Virtual Private Server (VPS).

First thing I do is get a cheap, re­li­able box. Forget AWS. You aren’t go­ing to need it, and their con­trol panel is a labyrinth de­signed to ex­tract billing up­grades. I use Linode or DigitalOcean. Pay no more than $5 to $10 a month.

1GB of RAM sounds ter­ri­fy­ing to mod­ern web de­vel­op­ers, but it is plenty if you know what you are do­ing. If you need a lit­tle breath­ing room, just use a swap­file.

The goal is to serve re­quests, not to main­tain in­fra­struc­ture. When you have one server, you know ex­actly where the logs are, ex­actly why it crashed, and ex­actly how to restart it.

Now you have con­straints. You only have a gi­ga­byte of mem­ory. You could run Python or Ruby as your main back­end lan­guage—but why would you? You’ll spend half your RAM just boot­ing the in­ter­preter and man­ag­ing gu­ni­corn work­ers.

I write my back­ends in Go.

Go is in­fi­nitely more per­for­mant for web tasks, it’s strictly typed, and—cru­cially for 2026—it is in­cred­i­bly easy for LLMs to rea­son about. But the real magic of Go is the de­ploy­ment process. There is no pip in­stall de­pen­dency hell. There is no vir­tual en­vi­ron­ment. You com­pile your en­tire ap­pli­ca­tion into a sin­gle, sta­t­i­cally linked bi­nary on your lap­top, scp it to your $5 server, and run it.

Here is what a com­plete, pro­duc­tion-ready web server looks like in Go. No bloated frame­works re­quired:

pack­age main

im­port (

“fmt”

“net/http”

func main() {

http.Han­dle­Func(“/”, func(w http.Re­spon­seWriter, r *http.Request) {

fmt.Fprintf(w, “Hello, your MRR is safe here.“)

// This will com­fort­ably han­dle 10,000s of re­quests per sec­ond

// on a potato.

http.Lis­te­nAnd­Serve(”:8080″, nil)

If you have a graph­ics card sit­ting some­where in your house, you al­ready have un­lim­ited AI cred­its.

When I was build­ing eh-trade.ca, I had a spe­cific prob­lem: I needed to per­form deep, qual­i­ta­tive stock mar­ket re­search on thou­sands of com­pa­nies, sum­ma­riz­ing mas­sive quar­terly re­ports. The naive so­lu­tion is to throw all of this at the OpenAI API. I could have paid hun­dreds of dol­lars in API cred­its, only to find a logic bug in my prompt loop that re­quired me to run the whole batch over again.

Instead, I’m run­ning VLLM on a dusty $900 graph­ics card (an RTX 3090 with 24GB of VRAM) I bought off Facebook Marketplace. It’s an up­front in­vest­ment, sure, but I never have to pay a toll to an AI provider for batch pro­cess­ing again.

For lo­cal AI, you have a dis­tinct up­grade path:

* Start with Ollama. It sets up in one com­mand (ollama run qwen3:32b) and lets you try out dozens of mod­els in­stantly. It’s the per­fect en­vi­ron­ment for it­er­at­ing on prompts.

* Move to VLLM for pro­duc­tion. Once you have a sys­tem that works, Ollama be­comes a bot­tle­neck for con­cur­rent re­quests. VLLM locks your GPU to one model, but it is dras­ti­cally faster be­cause it uses PagedAttention. Structure your sys­tem so you send 8 or 16 async re­quests si­mul­ta­ne­ously. VLLM will batch them to­gether in the GPU mem­ory, and all 16 will fin­ish in roughly the same time it takes to process one.

* Use Transformer Lab for any­thing more ad­vanced. If you need to do any model pre-train­ing or fine-tun­ing, Transformer Lab makes it easy on lo­cal hard­ware.

To man­age all this, I built la­conic, an agen­tic re­searcher specif­i­cally op­ti­mized for run­ning in a con­strained 8K con­text win­dow. It man­ages the LLM con­text like an op­er­at­ing sys­tem’s vir­tual mem­ory man­ager—it “pages out” the ir­rel­e­vant bag­gage of a con­ver­sa­tion, keep­ing only the ab­solute most crit­i­cal facts in the ac­tive LLM con­text win­dow.

I also use llmhub, which ab­stracts any LLM into a sim­ple provider/​end­point/​apikey combo, grace­fully han­dling both text and im­age IO whether the model is run­ning un­der my desk or in the cloud.

You can’t do every­thing lo­cally. Sometimes you need the ab­solute cut­ting-edge rea­son­ing of Claude 3.5 Sonnet or GPT-4o for user-fac­ing, low-la­tency chat in­ter­ac­tions.

Instead of jug­gling billing ac­counts, API keys, and rate lim­its for Anthropic, Google, and OpenAI, I just use OpenRouter. You write one OpenAI-compatible in­te­gra­tion in your code, and you in­stantly get ac­cess to every ma­jor fron­tier model.

More im­por­tantly, it al­lows for seam­less fall­back rout­ing. If Anthropic’s API goes down on a Tuesday af­ter­noon (which hap­pens), my app au­to­mat­i­cally falls back to an equiv­a­lent OpenAI model. My users never see an er­ror screen, and I don’t have to write com­plex retry logic.

New, in­sanely ex­pen­sive mod­els are be­ing re­leased every week. I con­stantly hear about de­vel­op­ers drop­ping hun­dreds of dol­lars a month on Cursor sub­scrip­tions and Anthropic API keys just to have an AI write their boil­er­plate.

Meanwhile, I’m us­ing Claude Opus 4.6 all day and my bill barely touches $60 a month. My se­cret? I ex­ploit Microsoft’s pric­ing model.

I bought a GitHub Copilot sub­scrip­tion in 2023, plugged it into stan­dard VS Code, and never left. I tried Cursor and the other fancy forks when they briefly sur­passed it with agen­tic cod­ing, but Copilot Chat al­ways catches up.

Here is the trick that you might have missed: some­how, Microsoft is able to charge per re­quest, not per to­ken. And a “request” is sim­ply what I type into the chat box. Even if the agent spends the next 30 min­utes chew­ing through my en­tire code­base, map­ping de­pen­den­cies, and chang­ing hun­dreds of files, I still pay roughly $0.04.

The op­ti­mal strat­egy is sim­ple: write bru­tally de­tailed prompts with strict suc­cess cri­te­ria (which is best prac­tice any­way), tell the agent to “keep go­ing un­til all er­rors are fixed,” hit en­ter, and go make a cof­fee while Satya Nadella sub­si­dizes your com­pute costs.

I al­ways start a new ven­ture us­ing sqlite3 as the main data­base. Hear me out, this is not as in­sane as you think.

The en­ter­prise mind­set dic­tates that you need an out-of-process data­base server. But the truth is, a lo­cal SQLite file com­mu­ni­cat­ing over the C-interface or mem­ory is or­ders of mag­ni­tude faster than mak­ing a TCP net­work hop to a re­mote Postgres server.

“But what about con­cur­rency?” you ask. Many peo­ple think SQLite locks the whole data­base on every write. They are wrong. You just need to turn on Write-Ahead Logging (WAL). Execute this pragma once when you open the data­base:

PRAGMA jour­nal_­mode=WAL;

PRAGMA syn­chro­nous=NOR­MAL;

Boom. Readers no longer block writ­ers. Writers no longer block read­ers. You can now eas­ily han­dle thou­sands of con­cur­rent users off a sin­gle .db file on an NVMe drive.

Since im­ple­ment­ing user au­then­ti­ca­tion is usu­ally the most an­noy­ing part of start­ing a new SQLite-based pro­ject, I built a li­brary: smhanov/​auth. It in­te­grates di­rectly with what­ever data­base you are us­ing and man­ages user signups, ses­sions, and pass­word re­sets. It even lets users sign in with Google, Facebook, X, or their own com­pany-spe­cific SAML provider. No bloated de­pen­den­cies, just sim­ple, au­ditable code.

The tech in­dus­try wants you to be­lieve that build­ing a real busi­ness re­quires com­plex or­ches­tra­tion, mas­sive monthly AWS bills, and mil­lions in ven­ture cap­i­tal.

By uti­liz­ing a sin­gle VPS, sta­t­i­cally com­piled bi­na­ries, lo­cal GPU hard­ware for batch AI tasks, and the raw speed of SQLite, you can boot­strap a highly scal­able startup that costs less than the price of a few cof­fees a month. You add in­fi­nite run­way to your pro­ject, giv­ing your­self the time to ac­tu­ally solve your users’ prob­lems in­stead of sweat­ing your burn rate.

If you are in­ter­ested in run­ning lean, check out my auth li­brary and agent im­ple­men­ta­tions on my GitHub. I’ll be hang­ing around the com­ments—let me know how you keep your server costs down, or tell me why I’m com­pletely wrong.

Skip to con­tent

Secure your code as you build

We read every piece of feed­back, and take your in­put very se­ri­ously.

Include my email ad­dress so I can be con­tacted

Use saved searches to fil­ter your re­sults more quickly

To see all avail­able qual­i­fiers, see our doc­u­men­ta­tion.

Sign up

You signed in with an­other tab or win­dow. Reload to re­fresh your ses­sion.

You signed out in an­other tab or win­dow. Reload to re­fresh your ses­sion.

You switched ac­counts on an­other tab or win­dow. Reload to re­fresh your ses­sion.

Notifications

You must be signed in to change no­ti­fi­ca­tion set­tings

You can’t per­form that ac­tion at this time.

Seven coun­tries now gen­er­ate nearly all of their elec­tric­ity from re­new­able en­ergy sources, ac­cord­ing to newly com­piled fig­ures.

Albania, Bhutan, Nepal, Paraguay, Iceland, Ethiopia and the Democratic Republic of Congo pro­duced more than 99.7 per cent of the elec­tric­ity they con­sumed us­ing ge­ot­her­mal, hy­dro, so­lar or wind power.

Data from the International Energy Agency (IEA) and International Renewable Energy Agency (IRENA) also re­vealed that a fur­ther 40 coun­tries gen­er­ated at least 50 per cent of the elec­tric­ity they con­sumed from re­new­able en­ergy tech­nolo­gies in 2021 and 2022 — in­clud­ing 11 European coun­tries.

“We don’t need mir­a­cle tech­nolo­gies,” said Stanford University Professor Mark Jacobson, who pub­lished the data.

“We need to stop emis­sions by elec­tri­fy­ing every­thing and pro­vid­ing the elec­tric­ity with Wind, Water and Solar (WWS), which in­cludes on­shore wind, so­lar pho­to­voltaics, con­cen­trated so­lar power, ge­ot­her­mal elec­tric­ity, small hy­dro­elec­tric­ity, and large hy­dro­elec­tric­ity.”

Professor Jacobson also noted that other coun­tries like Germany were also ca­pa­ble of run­ning off 100 per cent re­new­able-gen­er­ated elec­tric­ity for short pe­ri­ods of time.

Figures re­leased by the IEA in January show that the UK gen­er­ated 41.5 per cent of its elec­tric­ity from re­new­able sources in 2022 — up 10.5 per cent from the year be­fore.

In Scotland, re­new­able en­ergy tech­nolo­gies gen­er­ated the equiv­a­lent of 113 per cent of the coun­try’s over­all elec­tric­ity con­sump­tion in 2022.

“These record-break­ing fig­ures are a ma­jor mile­stone on Scotland’s jour­ney to net-zero, clearly demon­strat­ing the enor­mous po­ten­tial of our world-class re­new­able en­ergy re­sources,” Claire Mack, chief ex­ec­u­tive of Scottish Renewables, said at the time.

While Scotland’s elec­tric­ity gen­er­a­tion was dom­i­nated by wind power, re­searchers pre­dict that so­lar will come to dom­i­nate global elec­tric­ity sup­plies over the com­ing decades.

There has been sig­nif­i­cant progress in re­cent years with im­prov­ing ef­fi­ciency rates for so­lar cells, pri­mar­ily boosted by the so-called ‘miracle ma­te­ri­al’ per­ovskite.

Commercial costs have also fallen, which led sci­en­tists at the University of Exeter and University College London to claim last year that so­lar en­ergy has reached an “irreversible tip­ping point” that will see it be­come the world’s main source of en­ergy by 2050.

Their 2023 pa­per, pub­lished in the jour­nal Nature Communications, found that tech­no­log­i­cal and eco­nomic ad­vances meant the tran­si­tion to clean en­ergy is not just reach­able, but in­evitable.

“Due to tech­no­log­i­cal tra­jec­to­ries set in mo­tion by past pol­icy, a global ir­re­versible so­lar tip­ping point may have passed where so­lar en­ergy grad­u­ally comes to dom­i­nate global elec­tric­ity mar­kets, with­out any fur­ther cli­mate poli­cies,” the re­searchers wrote in the study.

“Solar en­ergy is the most widely avail­able en­ergy re­source on Earth, and its eco­nomic at­trac­tive­ness is im­prov­ing fast in a cy­cle of in­creas­ing in­vest­ments.”

I’m part of the desk­top soft­ware gen­er­a­tion. From Windows 95 to Windows 7, I grew us­ing mostly-of­fline soft­ware on com­put­ers op­er­ated via mouse and key­board, well be­fore tablets and smart­phones. Recently, I’ve been miss­ing one par­tic­u­lar part of that era: its con­sis­tency in de­sign. I want to tell you about id­iomatic de­sign, em­pha­size the im­por­tance of ho­mo­ge­neous in­ter­faces, and sug­gest that we’ve lost some­thing im­por­tant.

Suppose you’re log­ging into a web­site, and it asks: “do you want to stay logged in?” There are many ways in which the web­site could ask you for an an­swer: for ex­am­ple, a text field where you can en­ter “Yes” or “No”, or a drop­down where you can se­lect “Keep me logged in” or “Log me out when I close this win­dow.” But in re­al­ity, it’ll al­ways be a check­box. Why is that?

The check­box is a de­sign id­iom: it’s such a com­mon de­sign that as a user, you know how to use it with­out think­ing about it, and if you were mak­ing a web­site and had to ask this ques­tion, you would also put in a check­box with­out think­ing about it. To builders and users alike, it is a stan­dard de­sign pat­tern that every­one can rely on.

A check­box is also part of an in­ter­face. You’re us­ing it to in­ter­act with a sys­tem by in­putting data. Interfaces are bet­ter the less think­ing they re­quire: whether the in­ter­face is a steer­ing wheel or an on­line form, if you have to spend any amount of time fig­ur­ing out how to use it, that’s bad. As you in­ter­act with many things, you want ho­mo­ge­neous in­ter­faces that give you con­sis­tent ex­pe­ri­ences. If you learn that Command + C is the key­board short­cut for copy, you want that to work every­where. You don’t want to have to re­mem­ber to use CTRL + Shift + C in cer­tain cir­cum­stances or right-click → copy in oth­ers, that’d be an­noy­ing.

But that’s where we’ve ended up. Software is on the in­ter­net now, and the in­ter­faces aren’t ho­mo­ge­neous at all. There are hun­dreds of ways that dif­fer­ent web­sites ask you to pick dates, en­ter your credit card num­ber, or do any num­ber of com­mon tasks. Keyboard short­cuts dif­fer from app to app. There are so many dif­fer­ent ways of in­ter­ac­tion that you can’t re­mem­ber or learn them at all. Using web ap­pli­ca­tions in 2023 is an ex­er­cise of “where do I find what I want to do?” over and over again.

By con­trast, one of the strengths of the desk­top soft­ware era was high con­sis­tency across in­ter­faces by use of de­sign id­ioms. Look at this pic­ture from Windows 2000:

The vi­su­als feel a lit­tle ugly and dated: it’s blocky, the font is­n’t great, and the col­ors are dull. But the in­ter­face gets a cou­ple of things re­ally right:

* The File, Edit, View… menu struc­ture was stan­dard. No mat­ter whether you were in Adobe Photoshop or Microsoft Excel, you knew that save is un­der File, redo is un­der Edit, full-screen is un­der View, etc.

* The menu is nav­i­ga­ble by key­board: there’s a lit­tle un­der­line in each of the menu items, e.g. F in File and N in New, un­der­neath. They in­di­cate key­board short­cuts. You can en­ter ALT+F to open the File menu, then hit N to open a new file. This caters to power-users while mak­ing the short­cuts easy to learn.

* The sta­tus bar at the bot­tom tells you every­thing about the cur­rent state: page, col­umn, word count, whether you’re track­ing changes, in in­sert-mode, etc.

* Menu items are clearly la­beled. Words, not icons, are the pri­mary in­ter­face to ac­tions. Icons are used only where they are most ob­vi­ous. The en­tire in­ter­face leaves lit­tle to the imag­i­na­tion. In the pic­ture above, there’s no “I won­der what this does?” You know how to use it, even if you’ve never used it be­fore.

Crucially, these de­sign id­ioms were used not just in Microsoft Word, but through­out the en­tire Windows ecosys­tem. Take a look at this Windows XP lo­gout screen:

Every sin­gle but­ton is clearly vi­su­ally a but­ton and says ex­actly what it does. And each one has a lit­tle un­der­line to in­di­cate its key­board short­cut. Isn’t that nice?

The desk­top soft­ware era was one of ho­mo­ge­neous in­ter­faces, per­haps be­cause the op­er­at­ing sys­tem and its GUI li­braries dic­tated broad swaths of de­sign, and those con­straints guided de­vel­op­ers to­ward con­form­ing pat­terns.

The browser soft­ware era is one of het­ero­ge­neous in­ter­faces. Take a look at these screen­shots from two of my fa­vorite web ap­pli­ca­tions: Figma and Linear.

These are prob­a­bly the two best pieces of en­ter­prise soft­ware avail­able to­day. And though they have many of the same fea­tures — team set­tings, ab­stract item hi­er­ar­chies, col­lab­o­ra­tive com­ments, etc. — they don’t share a sin­gle icon. They have no de­sign id­ioms in com­mon. They have dif­fer­ent key­board short­cuts. Both are very well-de­signed from first prin­ci­ples, but do not con­form to what other in­ter­faces the user might be fa­mil­iar with.

We are in an era of in­di­vid­u­ally well-de­signed, use­ful web ap­pli­ca­tions, and they’re all unique. Even in prod­ucts by the same com­pany, the ex­pe­ri­ences are het­ero­ge­neous: us­ing GMail is noth­ing like us­ing GSuites is noth­ing like us­ing Google Docs. In ag­gre­gate, this is very frus­trat­ing. The lack of ho­mo­ge­neous in­ter­faces means that I spend most of my dig­i­tal time not in a state of pro­duc­tive flow, but hunt­ing and peck­ing all over the screen, ask­ing my­self “Can I click that? Does this open in a new tab? Will the browser’s back but­ton let me go back?” Awful!

This lack of ho­mo­gene­ity is for two rea­sons:

All the pat­terns in de­sign­ing for mouse-and-key­board ap­pli­ca­tions had to be rein­vented with the ad­vent of the touch­screen. Most web ap­pli­ca­tions have to en­able both a mo­bile and desk­top ex­pe­ri­ence, and those in­ter­ac­tion forms are very dif­fer­ent. Therefore, most user ex­pe­ri­ences have since then been stuck in an awk­ward mid­dle, e.g. ham­burger menus in­tended for mo­bile apps also used for desk­top apps, etc. Consequently, there are a ton of bad de­sign pat­terns every­where you look. Modern fron­tend de­vel­op­ment has a cul­ture of copy­ing and re-us­ing mod­u­lar com­po­nents, so it’s easy to copy-paste bad de­sign pat­terns and per­pet­u­ate the is­sue. After 10+ years of this, there has been a gen­er­a­tionally cor­ro­sive ef­fect on the qual­ity of UI/UX de­sign.

If every­one were to fol­low the same de­sign id­ioms, then the in­ter­faces would look pretty con­sis­tent. In the early days of the in­ter­net, there were strong de­sign id­ioms: hy­per­links to other pages were un­der­lined blue, and pur­ple if you had al­ready vis­ited them. Great! Today, every web­site pre­sents its own guess­ing game on how el­e­ments of the in­ter­face are styled. Is that a link? Maybe!

It may be sur­pris­ing that mod­ern web de­sign is so uni­d­iomatic, be­cause the HTML/CSS stan­dards are very pre­scrip­tive. The is­sue is that even though there are stan­dards for writ­ing HTML, no-one writes HTML any­more. People write React in TypeScript or the lat­est frame­work. They im­port count­less npm pack­ages. All that goes through a com­plex build process to out­put some­thing that runs in the browser.

Frontend de­vel­op­ers aren’t wrong to do this. Browsers to­day are ex­tremely pow­er­ful and of­fer gen­eral-pur­pose APIs that can let you do pretty much any­thing if you are cre­ative about it. For ex­am­ple, Figma does­n’t fol­low any HTML de­sign id­ioms be­cause there is no HTML. It’s writ­ten in web as­sem­bly; they are on the cut­ting edge of im­ple­ment­ing desk­top-style soft­ware in the browser. Of course that breaks the HTML-webpage-as-document model. The browser’s back but­ton, key­board short­cuts, etc. fall by the way­side while a hu­man-com­puter in­ter­ac­tion par­a­digm is re­built.

In short, there are few web de­sign id­ioms be­cause front-end de­vel­op­ment is mov­ing too quickly. Engineers are con­cerned with what is pos­si­ble more than with ques­tions of pol­ish, and right­fully so. Multi-user, real-time col­lab­o­ra­tion is much more valu­able than power-user key­board short­cuts. There are both end­less fron­tend pack­ages and in­ter­ac­tion for­mats to de­ploy them into, so in­sti­tut­ing one-size-fits-all id­ioms on a space so large is very dif­fi­cult. It will take time for the cut­ting edge to cool down, and for the most suc­cess­ful pat­terns to be­come ap­par­ent and even­tu­ally id­iomatic.

And yet, some of the most suc­cess­ful prod­uct or­ga­ni­za­tions of to­day ag­gres­sively pur­sue their own de­sign id­ioms and achieve some ho­mo­gene­ity in their in­ter­faces.

Apple is a great ex­am­ple. We’ve talked about Microsoft of the past, but Apple to­day dri­ves a highly opin­ion­ated de­sign sys­tem. Apple’s gen­eral li­brary of fonts, but­tons, col­ors, etc. and its con­sis­tency across all of Apple’s na­tive ap­pli­ca­tions and de­vices have cre­ated a pow­er­ful con­form­ing ef­fect for third-party ap­pli­ca­tions. Even when us­ing a third-party app on your iPhone, in­ter­act­ing via the key­board, pinch-to-zoom, etc. is all con­trolled by iOS. This is a big part of Apple’s it-just-works ef­fect. Strong, taste­ful, id­iomatic de­sign is at the core of Apple’s suc­cess.

What’s in­ter­est­ing about the it-just-works ef­fect is that it makes users trust the de­faults and avoid cus­tomiza­tion. You see a sim­i­lar dy­namic on plat­forms like Substack, where as an au­thor I don’t have any abil­ity to se­lect the font or even un­der­line text. But the con­strain­ing de­faults are taste­fully set, and it works great. Substack’s and Apple’s de­sign prin­ci­ples gain adop­tion as those prod­ucts suc­ceed, since de­sign­ers look to them as suc­cess­ful ex­am­ples. Those de­signs even­tu­ally be­come id­ioms by (1) peo­ple con­verg­ing on them as good de­signs and (2) fre­quency of use in the com­mu­nity.

As a prod­uct builder, you want to fol­low de­sign id­ioms as closely as prac­ti­cally pos­si­ble, be­cause it makes your soft­ware eas­ier to use and it max­i­mizes com­pat­i­bil­ity across de­vices/​browsers. I fol­low these rules of thumb and break them only rarely:

Study and fol­low HTML/CSS id­ioms when­ever pos­si­ble. For ex­am­ple, a link should be un­der­lined, col­or­ful, pointer on mouseover, and writ­ten as an tag. Avoid JavaScript reim­ple­men­ta­tions of HTML ba­sics, e.g. React Button com­po­nents in­stead of styled el­e­ments. Study and fol­low browser id­ioms when­ever pos­si­ble. The back but­ton should al­ways work. Copy-pasting the URL should bring you to the same in­ter­face. CTRL-clicking a nav­i­ga­tional el­e­ment should open it in a new tab.If you de­vi­ate from gen­eral id­ioms, make sure that your de­signs are fully in­ter­nally con­sis­tent and at least “idiomatic” within your or­ga­ni­za­tion.Pre­fer words to icons. Use only icons that are uni­ver­sally un­der­stood.If in doubt, make vi­sual el­e­ments look ob­vi­ous. There should never be con­fu­sion about whether some­thing is a but­ton or a tab.If at an im­passe, re­fer to two types of re­source to as­sist in your judg­ment:The best-de­signed web­sites that you know; Books on in­ter­face de­sign from decades past. Most in­ter­face de­sign prob­lems of to­day are not new, but re­peats of his­tory, with solved analo­gies in the past.

I dream of the day when every datepicker or credit card form on the in­ter­net is ex­actly the same: when af­ter thirty years of it­er­a­tive de­vel­op­ment and mil­lions of at­tempts, we’ve fi­nally con­verged on the best one. I dream of a fu­ture where in every web app, CTRL-Click opens the thing in a new tab. It would be nice…

Skip to con­tent

Secure your code as you build

We read every piece of feed­back, and take your in­put very se­ri­ously.

Include my email ad­dress so I can be con­tacted

Use saved searches to fil­ter your re­sults more quickly

To see all avail­able qual­i­fiers, see our doc­u­men­ta­tion.

Sign up

You signed in with an­other tab or win­dow. Reload to re­fresh your ses­sion.

You signed out in an­other tab or win­dow. Reload to re­fresh your ses­sion.

You switched ac­counts on an­other tab or win­dow. Reload to re­fresh your ses­sion.

Notifications

You must be signed in to change no­ti­fi­ca­tion set­tings

Cache TTL silently re­gressed from 1h to 5m around early March 2026, caus­ing quota and cost in­fla­tion Cache TTL silently re­gressed from 1h to 5m around early March 2026, caus­ing quota and cost in­fla­tion

You can’t per­form that ac­tion at this time.

This is a heav­ily in­ter­ac­tive web ap­pli­ca­tion, and JavaScript is re­quired. Simple HTML in­ter­faces are pos­si­ble, but that is not what this is.

Learn more about Bluesky at bsky.so­cial and at­proto.com. A state­ment re­gard­ing the re­moval of DDLC from the Google Play Store:

In his clas­sic

Programming Perl — affectionately known to a gen­er­a­tion of tech­nol­o­gists as “the Camel Book” — Larry Wall fa­mously wrote of the three virtues of a pro­gram­mer as lazi­ness, im­pa­tience, and hubris:

If we’re go­ing to talk about good soft­ware de­sign, we have to talk about Laziness, Impatience, and Hubris, the ba­sis of good soft­ware de­sign. We’ve all fallen into the trap of us­ing cut-and-paste when we should have de­fined a higher-level ab­strac­tion, if only just a loop or sub­rou­tine. To be sure, some folks have gone to the op­po­site ex­treme of defin­ing ever-grow­ing mounds of higher level ab­strac­tions when they should have used cut-and-paste. Generally, though, most of us need to think about us­ing more ab­strac­tion rather than less.

Of these virtues, I have al­ways found lazi­ness to be the most pro­found: packed within its tongue-in-cheek self-dep­re­ca­tion is a com­men­tary on not just the need for ab­strac­tion, but the aes­thet­ics of it. Laziness dri­ves us to make the sys­tem as sim­ple as pos­si­ble (but no sim­pler!) — to de­velop the pow­er­ful ab­strac­tions that then al­low us to do much more, much more eas­ily.

Of course, the im­plicit wink here is that it takes a lot of work to be lazy: when pro­gram­mers are en­gaged in the seem­ing lazi­ness of

ham­mock-dri­ven de­vel­op­ment, we are in fact turn­ing the prob­lem over and over in our heads. We un­der­take the hard in­tel­lec­tual work of de­vel­op­ing these ab­strac­tions in part be­cause we are op­ti­miz­ing the hy­po­thet­i­cal time of our fu­ture selves, even if at the ex­pense of our cur­rent one. When we get this cal­cu­lus right, it is glo­ri­ous, as the ab­strac­tion serves not just our­selves, but all who come af­ter us. That is, our lazi­ness serves to make soft­ware eas­ier to write, and sys­tems eas­ier to com­pose — to al­low more peo­ple to write more of it.

Ideally, you would want those that ben­e­fit from ab­strac­tions to pay the virtue of lazi­ness for­ward — to use their new-found power to them­selves la­bor on the ab­strac­tions they make. But a con­se­quence of the broad­en­ing of soft­ware cre­ation over the past two decades is it in­cludes more and more peo­ple who are un­likely to call them­selves pro­gram­mers — and for whom the virtue of lazi­ness would lose its in­tended mean­ing.

Worse, the ex­tra­or­di­nary pro­duc­tiv­ity al­lowed by mod­ern ab­strac­tions has given rise to an em­pha­sis on a kind of false in­dus­tri­ous­ness. Pejoratively, this was the

rise of the bro­gram­mer, with the virtue of ironic lazi­ness and ham­mock-dri­ven de­vel­op­ment dis­placed by

hus­tle porn about crush­ing code.

Onto this dry tin­der has struck the light­ning bolt of LLMs. Whatever one’s dis­po­si­tion is to soft­ware cre­ation, LLMs al­low that to be ap­plied with (much) greater force, so it should be of lit­tle sur­prise that LLMs have served as an­a­bolic steroids for the bro­gram­mer set.

Elated with their new-found bulk, they can’t seem to shut up about it. Take, for ex­am­ple, bro­gram­mer-of-note

Garry Tan, who has been par­tic­u­larly in­suf­fer­able about his LLM use, brag­ging about his rate of thirty-seven thou­sand

lines of code per day (and “still speed­ing up”):

If lazi­ness is a virtue of a pro­gram­mer, think­ing about soft­ware this way is clearly a vice. And like as­sess­ing lit­er­a­ture by the pound, its fal­lacy is clear even to novice pro­gram­mers.

As for the ar­ti­fact that Tan was build­ing with such fre­netic en­ergy, I was broadly ig­nor­ing it. Polish soft­ware en­gi­neer Gregorein, how­ever,

took it apart, and the re­sults are at once pre­dictable, hi­lar­i­ous and in­struc­tive: A sin­gle load of Tan’s “newsletter-blog-thingy” in­cluded mul­ti­ple test har­nesses (!), the Hello World Rails app (?!), a stow­away text ed­i­tor, and then eight dif­fer­ent vari­ants of the same logo — one of which with zero bytes.

The prob­lem here is­n’t these is­sues per se (which are all fix­able!), and it is­n’t even the be­lief that the method­ol­ogy that cre­ated them rep­re­sents the fu­ture of soft­ware en­gi­neer­ing (though that is cer­tainly an­noy­ing!).

The prob­lem is that LLMs in­her­ently lack the virtue of lazi­ness. Work costs noth­ing to an LLM. LLMs do not feel a need to op­ti­mize for their own (or any­one’s) fu­ture time, and will hap­pily dump more and more onto a lay­er­cake of garbage. Left unchecked, LLMs will make sys­tems larger, not bet­ter — ap­peal­ing to per­verse van­ity met­rics, per­haps, but at the cost of every­thing that mat­ters. As such, LLMs high­light how es­sen­tial our hu­man lazi­ness is: our fi­nite time forces us to de­velop crisp ab­strac­tions in part be­cause we don’t want to waste our (human!) time on the con­se­quences of clunky ones. The best en­gi­neer­ing is al­ways borne of con­straints, and the con­straint of our time places lim­its on the cog­ni­tive load of the sys­tem that we’re will­ing to ac­cept. This is what dri­ves us to make the sys­tem sim­pler, de­spite its es­sen­tial com­plex­ity. As I ex­panded on in my talk

The Complexity of Simplicity, this is a sig­nif­i­cant un­der­tak­ing — and we can­not ex­pect LLMs that do not op­er­ate un­der con­straints of time or load to un­der­take it of their own vo­li­tion.

This is not to say, of course, that LLMs won’t play an im­por­tant role in our fu­ture: they are an ex­tra­or­di­nary tool for soft­ware en­gi­neer­ing, but — as out­lined in our

guide­lines for LLM use at Oxide — they are but a tool. We can put them to use tack­ling the non-ironic (and non-vir­tu­ous!) as­pects of pro­gram­mer lazi­ness — help­ing us take on thorny prob­lems like tech­ni­cal debt —  or

use them to pro­mote our en­gi­neer­ing rigor, but it must be in ser­vice of our own vir­tu­ous lazi­ness: to yield a sim­pler, more pow­er­ful sys­tem that serves not just our­selves, but the gen­er­a­tions of soft­ware en­gi­neers to come af­ter us.

In 2020, I started mak­ing my own soft drinks, in­clud­ing a sugar-free, caf­feine-free cola! If you’re just look­ing for the cur­rent recipes, you can find them on GitHub. They were in­spired by recipes like Open Cola and Cube Cola.

Otherwise, read on for “log book”-style in­struc­tions and pic­tures of my first at­tempts, which have been adapted from this Mastodon thread.

We start by mak­ing a fla­vor emul­sion from es­sen­tial oils! These oils are ex­tremely strong, and can cause skin ir­ri­ta­tions, so if you want to be safe, wear la­tex gloves for this step!

We also need su­per small quan­ti­ties. In this at­tempt, I’m aim­ing for:

There! In to­tal, we have about 2 ml of es­sen­tial oil. This will lend fla­vor to about 9 L of cola!

But oils don’t dis­solve in wa­ter, right? They would just float on the sur­face!

So what we’ll add next is gum ara­bic, a nat­ural emul­si­fier, that will help the oil form tiny, tiny droplets that stay dis­persed in wa­ter!

Combine 2 g of gum ara­bic, 4 ml wa­ter, and our oil mix­ture with a hand mixer. Keep mix­ing un­til it emul­si­fies, it will take on a milky brown color and the oily phase will dis­ap­pear. This took me about 5 min­utes.

Next, we add: 40 ml of caramel color, which will give the cola its dark ap­pear­ance.

As well as 5 g cit­ric acid, and an ad­di­tional 10 ml of wa­ter. You can also add caf­feine at this point, but one of the main mo­ti­va­tions for me to make my own cola is to have cola with­out caf­feine (it gives me headaches).

Stop mix­ing when it starts smil­ing at you! :D This is our fin­ished cola con­cen­trate. It smells de­li­cious!

Other recipes would now in­te­grate this into sugar syrup made from 1 kg of sugar, but I want to try a vari­a­tion us­ing ar­ti­fi­cial sweet­en­ers, for di­et­ing rea­sons. This is a com­bi­na­tion of sodium cy­cla­mate and sac­cha­rin, which is pretty com­mon in Germany. I’ll use 70 ml.

This gives us about 120 ml of the fin­ished cola syrup! \o/ I’ve been fol­low­ing the Cube-Cola recipe.

Because this is still a very con­cen­trated so­lu­tion and hard to han­dle, I’m di­lut­ing it down to 1 L. In the­ory, this should give a nice cola when di­luted fur­ther in a ra­tio of 1:8. First taste test com­ing up!

It’s good! It’s re­ally good! The sweet­ness is just right for me, and the oil blend tastes nice and cola-y! :)

I like my drinks re­ally sour, so I might add an­other… 10 g of cit­ric acid to this batch. There is a slightly bit­ter af­ter­taste, which I at­tribute to the ar­ti­fi­cial sweet­ener I’m us­ing.

I might also tweak the oil ra­tios to ac­cen­tu­ate the cit­rus fla­vors a bit more in the next batch. And I thought this would be too much food col­or­ing, but it seems pretty per­fect!

What I’d be re­ally ex­cited to try is mak­ing other fla­vors: Orange soda! Cherry soda! Almond & apri­cot soda!

Open Soda (Note: site is no longer on­line as of 2026…) has two pretty weird ones (including a bub­ble gum soda?!), but that’s pretty much all I found. There still seems to be po­ten­tial for re­verse en­gi­neer­ing! :)

And here are two more re­sources I found while prepar­ing my in­gre­di­ents to­day: Jan Krüger’s blog post about tweak­ing cola recipes and Richard Grove’s Notes on Making Cola, which go deeper into food chem­istry!

Made a sec­ond batch of cola syrup with­out caramel color. It’s much weirder to drink than I ex­pected.

I also switched to su­cralose as a sweet­ener, hop­ing that it would have less af­ter­taste. Instead of 1000 g sugar in the orig­i­nal recipe, I used 1.6 g su­cralose, which is ridicu­lous, but it’s still too sweet for my taste. :O

And I made a tool up­grade! It’s im­por­tant to get these small quan­ti­ties right…

This week’s batch: blood or­ange + al­mond + lime (in a 2:1:1 ra­tio), plus as much or­ange food col­or­ing as I dared to put in! :D

I cut the amount of su­cralose in half — still a bit too sweet for my taste. Had to com­pletely guess the oil ra­tios, but I’m happy with how it turned out! My whole apart­ment smells like marzi­pan now.

This time, when I did the mix­ing in a big plas­tic bowl, I no­ticed some float­ing stuff on the con­cen­trate, which I as­sume are tiny plas­tic shav­ings pro­duced by the hand mixer? I fil­tered them out, and might switch to glass or metal con­tain­ers.

In to­day’s cola batch, I re­duced the amount of su­cralose fur­ther to 0.4 g, added 0.07 g vanillin, as well as a bit more cas­sia oil. Good stuff! I call it “Syntez-Cola”, be­cause I com­bined ideas from Cube-Cola and Jan Krüger’s recipe! :)

… this is the point where I should start a blog post, and a Git repo with ver­sion num­bers and a changelog, I guess. :P (Edit 2026: Here you go!)

I found de­caf Coca-Cola in a su­per­mar­ket last week, and could do a di­rect taste com­par­i­son. At this point, I pre­fer my cola by a large mar­gin! Coca-Cola tasted bland, like molten cola pop­si­cles. It had an in­ter­est­ing dry­ness to it, though, which I’m not sure how to repli­cate.

Made a sim­ple or­ange soda to­day, re­ally happy with how it turned out! I put the recipe here, along with my mod­i­fied cola recipe, and the al­mond + blood or­ange drink I in­vented!

blinry al­mond 0.1.1 con­tains less al­mond oil, to high­lights the cit­rus fla­vors a bit more. Find the up­dated recipe here.

One of these two bot­tles is a ver­sion with sugar in­stead of su­cralose. 400 g of sugar seem to be a good re­place­ment for 0.6 g su­cralose. Curious to see whether peo­ple will be able to taste the dif­fer­ence! :) (Edit 2026: They to­tally could!)

blinry or­ange 0.1.1, now with 14% more or­ange! :D Recipe here.

Since these early ex­per­i­ments, I made a hand­ful batches of these recipes with­out mod­i­fi­ca­tion. I still think they’re re­ally nice! Especially blinry or­ange is rather unique.

If you try them for your­self, I’d be happy about feed­back!

And I’m still think­ing what in­gre­di­ents might go into a DIY Mountain Dew, or a DIY Fassbrause…

You can add your com­ment to this post in the Fediverse! Alternatively, drop me a mail at mil@blinry.org.

The ma­cOS Dock is built around apps, not win­dows. Multiple dis­plays and desk­tops make it hard to track what’s open where. bor­ing­Bar keeps win­dows or­ga­nized by desk­top, with in­stant pre­views, one-click desk­top switch­ing, and pinned apps within reach.

bor­ing­Bar also gives you a search­able app launcher, scroll-to-switch desk­tops, full win­dow ti­tles on chips, and a cleaner work­space when you hide the Dock. As a bonus, it makes ma­cOS feel more fa­mil­iar if you’ve just switched from Windows or Linux.

Shows only the win­dows on the ac­tive desk­top for that dis­play, so you stay fo­cused on what is in front of you.

Jump to any desk­top on the cur­rent dis­play with one click, and see how many win­dows are open on each one.

Search and launch apps from a sin­gle list, then open it in­stantly with a con­fig­urable global short­cut.

Hover a chip to pre­view win­dows be­fore switch­ing, so you can pick the right one faster.

Unread badges from ma­cOS ap­pear di­rectly on chips, so im­por­tant up­dates stay vis­i­ble.

When an app needs your at­ten­tion, its chip gives a sub­tle pulse so you no­tice it right away.

Scroll up or down on the bar to move be­tween desk­tops. Direction is con­fig­urable.

Choose small, medium, or large. Pick the size that suits you best.

Collapses mul­ti­ple win­dows into one chip, with a count badge.

Hide app name text on chips while keep­ing icons and win­dow count badges.

Show full win­dow ti­tles in chips, or just the app name for a cleaner look.

Keeps the Dock out of the way while you use bor­ing­Bar, then brings it back when you turn the fea­ture off.

Mirror bars across mul­ti­ple mon­i­tors, in­clud­ing se­tups where the sys­tem set­ting “Displays have sep­a­rate Spaces” is off.

Right-click the bar and choose Show Desktop, or click the rib­bon at the far right edge to re­veal the desk­top.

Right click on any app in the bar to pin them to the bar it­self or to the top of the ap­pli­ca­tion menu.

bor­ing­Bar re­quires two ma­cOS per­mis­sions. Accessibility is used to ob­serve and in­ter­act with win­dows, desk­tops, and apps on your be­half. Screen Recording is used solely to fetch win­dow thumb­nail pre­views and is not used for any­thing else. You can ver­ify this your­self: the pur­ple dot in Control Center only ap­pears when thumb­nails are be­ing fetched, and you will not see it from bor­ing­Bar at any other time.

Yes. You can down­load and try bor­ing­Bar free for 14 days with all fea­tures un­locked. A li­cense is re­quired to con­tinue us­ing it af­ter the trial.

Personal li­censes come in two fla­vors:

Perpetual — a one-time $40 pur­chase cov­er­ing 2 de­vices, with 2 years of sup­port and up­dates in­cluded. The soft­ware keeps work­ing af­ter that; you just won’t re­ceive fur­ther up­dates.

Yearly — a sub­scrip­tion start­ing at $7.99/year for 1 de­vice, with ad­di­tional de­vices at $2/year each, up to 5.

Business li­censes are billed an­nu­ally, start at 6 users, and use vol­ume pric­ing, so the per-user cost drops as your team grows:

For ex­am­ple, a 6-user busi­ness li­cense is $20.99/year, a 20-user li­cense is $69.99/year, and a 50-user li­cense is $144.99/year.

What is the dif­fer­ence be­tween a per­sonal and busi­ness li­cense?

Both li­censes give you ac­cess to the same fea­tures. A per­sonal li­cense is for in­di­vid­ual use and comes in two fla­vors: a one-time per­pet­ual pur­chase cov­er­ing 2 de­vices, or a yearly sub­scrip­tion cov­er­ing up to 5 de­vices. A busi­ness li­cense is an an­nual sub­scrip­tion in­tended for use within a com­pany or or­ga­ni­za­tion and in­cludes vol­ume pric­ing.

Can I use my li­cense on mul­ti­ple Macs?

Each li­cense seat is linked to one de­vice. A per­pet­ual per­sonal li­cense in­cludes 2 seats; a yearly per­sonal li­cense cov­ers 1 to 5 de­vices. For yearly per­sonal and busi­ness li­censes, make sure to pur­chase the ap­pro­pri­ate num­ber of seats up­front, as seats can­not be added to an ex­ist­ing li­cense. If you need more later, you can pur­chase a sep­a­rate li­cense. Multiple users on the same ma­chine share a sin­gle seat.

Personal li­cense hold­ers re­ceive an ac­ti­va­tion key by email af­ter pur­chase. Business li­cense hold­ers need to add each team mem­ber from the Business License Management page first. In the bor­ing­Bar app, that team mem­ber then en­ters their email ad­dress and re­ceives a one-time code to con­firm and ac­ti­vate their li­cense.

bor­ing­Bar can hide the Dock for you while it is run­ning, but it will still be vis­i­ble in Mission Control. When you turn the fea­ture off or quit the app, the Dock comes right back.

Enter the email ad­dress as­so­ci­ated with your busi­ness li­cense to sign in.

We sent a 6-digit code to

Enter the email ad­dress as­so­ci­ated with your per­sonal li­cense.

Sorry to bother you on Saturday. Thought this was im­por­tant to share.

The first thing you learn about a loom is that it’s easy to break.

The shut­tle runs along a track that warps with hu­mid­ity. The hed­dles hang from cords that fray. The reed is a row of thin metal strips, bent by hand, that bend back just as eas­ily. The warp beam cracks if you over-tighten it. The trea­dles loosen at the joints. The breast beam, the cloth roller, the ratchet and pawl, the lease sticks, the cas­tle; the whole con­trap­tion is wood and string held to­gether by ten­sion. It’s a piece of in­ge­nu­ity and crafts­man­ship, but one as del­i­cate as the clothes it man­i­fests out of wild plant fibers. It is, also, the foun­da­tional tool of an en­tire in­dus­try, tex­tiles, that has kept its rel­e­vance to our days of heavy ma­chin­ery, fac­to­ries, en­ergy fa­cil­i­ties, and dat­a­cen­ters.

It is not nearly as easy to break a dat­a­cen­ter.

It is made of con­crete and steel and cop­per and it’s on the big­ger side. It has in­ter­change­able servers, and bio­met­ric locks and tall elec­tri­fied fences and heav­ily armed guards and re­dun­dancy upon re­dun­dancy: every com­po­nent du­pli­cated so that no sin­gle fail­ure brings the whole thing down. There is no trea­dle to loosen or reed to bend back.

But say you man­aged to by­pass the guards, jump the fences, open the locks, and lo­cate all the servers. Then you’d face the al­go­rithm. The dat­a­cen­ter was never your goal; the al­go­rithm lurk­ing in­side is. It does­n’t run on that rack, or any rack for that mat­ter. It is a dig­i­tal pat­tern dis­trib­uted across mil­lions of chips, mir­rored across con­ti­nents; it could be re­con­sti­tuted else­where, and it’s trained to ad­dict you at a glance, like a mod­ern Medusa.

But say you man­aged to elude the stare, stop the repli­ca­tion, and break the pat­terns. Then you’d face su­per­in­tel­li­gence. The al­go­rithm was also not your goal; the vi­brant, ethe­real, la­tent su­per­in­tel­li­gence lurk­ing in­side is. Well, there’s noth­ing you can do here: It al­ways “gets out of the box” and, sud­denly, you are in­side the box, like a chimp be­ing played by a hu­man with a ba­nana. It’s just so tasty…

There’s an­other so­lu­tion to break a dat­a­cen­ter: You can bomb it, like one ham­mers down the loom.

Some have ar­gued that this is the way to en­sure a rogue su­per­in­tel­li­gence does­n’t get out of the box. A dif­fer­ent rogue crea­ture took the pro­posal se­ri­ously: last month, Iran’s Revolutionary Guard re­leased satel­lite footage of OpenAI’s Stargate cam­pus in Abu Dhabi and promised its “complete and ut­ter an­ni­hi­la­tion.”

But you prob­a­bly don’t have a rogue na­tion handy to ful­fill your wishes. Maybe you will end up bombed in­stead and we don’t want that to hap­pen. That’s what hap­pens with rogue in­tel­li­gences: you can’t pre­dict them.

And yet. Two hun­dred years of in­creas­ingly im­pen­e­tra­ble tech­nol­ogy—from looms to dat­a­cen­ters—have not changed the first thing about the peo­ple who live along­side it. The evo­lu­tion of tech­nol­ogy is a fea­ture of the world just as much as the per­ma­nent fragility of the hu­man body.

And so, more and more, it is peo­ple who are the weaker link in this chain of in­evitable doom. And it is peo­ple who will be tar­geted.

April of 1812. A mill owner named William Horsfall was rid­ing home on his beau­ti­ful white stal­lion back from the Cloth Hall mar­ket in Huddersfield, UK. He had spent weeks boast­ing that he would ride up to his sad­dle in Luddite blood (a pre­cious sub­stance that served as fuel for the mills).

A few yards later, at Crosland Moor, a man named George Mellor—twenty-two years old—shot him. It hit Horsfall in the groin, who, nom­i­na­tive-de­ter­min­is­ti­cally, fell from his horse. People gath­ered, re­proach­ing him for hav­ing been the op­pres­sor of the poor. Naturally, loyal to his prin­ci­ples in death as he was in life, he could­n’t hear them. He died one day later in an inn. Mellor was hanged.

April of 2026. A dat­a­cen­ter owner named Samuel Altman was dri­ving home on his beau­ti­ful white Koenigsegg Regera back from Market Street in San Francisco, US. He had spent weeks boast­ing that he would scrap and steal our blog posts (a pre­cious sub­stance that serves as fuel for the dat­a­cen­ters).

A few hours later, at Russian Hill, a man named Daniel Alejandro Moreno-Gama—twenty years old—al­legedly threw a Molotov cock­tail at his house. He hit an ex­te­rior gate. Altman and his fam­ily were asleep, but they’re fine. Moreno-Gama is in cus­tody.

This kind of vi­o­lence must be con­demned. This is not the way. It’s hor­ri­ble that it is hap­pen­ing at all. And yet, for some rea­son, it keeps hap­pen­ing.

Last week, the house of Ron Gibson, a coun­cil­man from Indianapolis, was shot at thir­teen times. The bul­let holes are still there. The shooter left a mes­sage on his doorstep: “NO DATA CENTERS.” Gibson sup­ports a dat­a­cen­ter pro­ject in the Martindale-Brightwood neigh­bor­hood. He and his son were un­harmed.

In November 2025, a 27-year-old anti-AI ac­tivist threat­ened to mur­der peo­ple at OpenAI’s SF of­fices, prompt­ing a lock­down. He had ex­pressed a de­sire to buy weapons.

Increasingly, as the ob­jects of peo­ple’s anger and frus­tra­tion and des­per­a­tion be­come un­reach­able be­hind fences and guards, or ab­stracted away in ones and ze­ros, or el­e­vated above the clouds, the mob will turn their unas­sail­able emo­tions to­ward hu­man tar­gets.

I don’t want to triv­i­al­ize the griev­ances of the peo­ple who fear for their fu­tures. I don’t want to de­fend Altman’s de­ci­sions. But this is not the way. This is how things de­volve into chaos.

And I won­der: how des­per­ate can peo­ple be be­fore these iso­lated events be­come a snow­ball of vi­o­lence that will be re­sisted by nei­ther dat­a­cen­ters nor rich peo­ple’s houses?

Every time I hear from Amodei or Altman that I could lose my job, I don’t think “oh, ok, then al­low me pay you $20/month so that I can adapt to these un­cer­tain times that have fallen upon my des­tiny by chance.” I think: “you, for fuck’s sake, you are do­ing this.” And I con­sider my­self a pretty lev­el­headed guy, so imag­ine what not-so-lev­el­headed peo­ple think.

There’s a lot of fric­tion to es­ca­lat­ing vi­o­lence, but that fric­tion dis­solves the mo­ment this sen­ti­ment starts to be com­mon. Normally, it just fades away any­way, but there’s one sce­nario where I see it in­evitably es­ca­lat­ing:

If peo­ple feel that they have no place in the fu­ture.

If they feel ex­pelled from the sys­tem—they’re un­able to buy stuff, their skills be­come ob­so­lete, their chance at earn­ing a liv­ing is re­placed by a swarm of AI agents, they think we are truly go­ing to die (so far, the vi­o­lence has been tied mostly to safety AI move­ments)—then they will feel they have noth­ing to lose.

And then, and I’m sorry to be so blunt, then it’s die or kill.

Perhaps the most se­ri­ous mis­take that the AI in­dus­try made af­ter cre­at­ing a tech­nol­ogy that will trans­ver­sally dis­rupt the en­tire white-col­lar work­force be­fore en­sur­ing a safe tran­si­tion, was mak­ing it ex­plicit by do­ing con­stant dis­courses that amount to: “we are cre­at­ing a tech­nol­ogy that will trans­ver­sally dis­rupt the en­tire white-col­lar work­force be­fore en­sur­ing a safe tran­si­tion.”

And, to top it off, they add “careful down there.”

The dif­fer­ence be­tween AI and, say, looms, is that this has been broad­cast to the en­tire globe, and it has been treated in a sort of self-con­scious way. The AI lead­ers know the prob­lems that will emerge and so they can­not help but talk about them con­stantly and so they are let­ting us know, which makes them look like psy­chopaths. How do you guys think peo­ple will re­act to this? You should be much less self-con­scious and much more self-aware: re­al­ize what you sound like!

People hate AI so much that they are prone to at­tribute to it every­thing that’s go­ing wrong in their lives, re­gard­less of the truth. That’s why they mix real ar­gu­ments, like data theft, with fake ones, like the wa­ter stuff. Employers do it, too. Most lay­offs are not caused by AI, but it’s the per­fect ex­cuse to do some­thing that’s oth­er­wise so­cially rep­re­hen­si­ble.

AI has be­come the per­fect scape­goat. It does­n’t help that the en­tire AI in­dus­try has de­cided that throw­ing rocks at its own roof is its best sell­ing point: If AI is so pow­er­ful and so dan­ger­ous and soon to be so ubiq­ui­tous, then what is so un­ex­pected about peo­ple blam­ing every­thing on it?

Nothing that Altman could say jus­ti­fies vi­o­lence against him. This is an un­de­ni­able truth. But un­for­tu­nately, vi­o­lence might still en­sue. I hope not, but I guess we are see­ing what ap­pears to be the first cases.

I just hope that, con­trary to the cases of ChatGPT-induced psy­chosis, chat­bot ad­dic­tion, AI-blamed job lay­offs, and a grow­ing trend of il­lit­er­acy, it stops.