Imagine you’re a new as­sis­tant pro­fes­sor at a re­search uni­ver­sity. You just got the job, you just got a small pot of startup fund­ing, and you just hired your first two PhD stu­dents: Alice and Bob. You’re in as­tro­physics. This is the be­gin­ning of every­thing.

You do what your su­per­vi­sor did for you, years ago: you give each of them a well-de­fined pro­ject. Something you know is solv­able, be­cause other peo­ple have solved ad­ja­cent ver­sions of it. Something that would take you, per­son­ally, about a month or two. You ex­pect it to take each stu­dent about a year, be­cause they don’t know what they’re do­ing yet, and that’s the point. The pro­ject is­n’t the de­liv­er­able. The pro­ject is the ve­hi­cle. The de­liv­er­able is the sci­en­tist that comes out the other end.

Alice’s pro­ject is to build an analy­sis pipeline for mea­sur­ing a par­tic­u­lar sta­tis­ti­cal sig­na­ture in galaxy clus­ter­ing data. Bob’s is some­thing sim­i­lar in scope and dif­fi­culty, a dif­fer­ent sig­nal, a dif­fer­ent dataset, the same ba­sic arc of learn­ing. You send them each a few pa­pers to read, point them at some pub­licly avail­able data, and tell them to start by re­pro­duc­ing a known re­sult. Then you wait.

The aca­d­e­mic year un­folds the way aca­d­e­mic years do. You have weekly meet­ings with each stu­dent. Alice gets stuck on the co­or­di­nate sys­tem. Bob can’t get his like­li­hood func­tion to con­verge. Alice writes a plot­ting script that pro­duces garbage. Bob mis­reads a sign con­ven­tion in a key pa­per and spends two weeks chas­ing a fac­tor-of-two er­ror. You give them both sim­i­lar feed­back: read the pa­per again, check your units, try print­ing the in­ter­me­di­ate out­put, think about what the an­swer should look like be­fore you look at what the code gives you. Normal things. The kind of things you say fifty times a year and never re­mem­ber say­ing.

By sum­mer, both stu­dents have fin­ished. Both pa­pers are solid. Not ground­break­ing, not go­ing to change the field, but cor­rect, use­ful, and pub­lish­able. Both go through a round of mi­nor re­vi­sions at a de­cent jour­nal and come out the other side. A per­fectly or­di­nary out­come. The kind of out­come that the en­tire ap­pa­ra­tus of aca­d­e­mic train­ing is de­signed to pro­duce.

Unlike Alice, who spent the year read­ing pa­pers with a pen­cil in hand, scrib­bling notes in the mar­gins, get­ting con­fused, re-read­ing, look­ing things up, and slowly as­sem­bling a work­ing un­der­stand­ing of her cor­ner of the field, Bob has been us­ing an AI agent. When his su­per­vi­sor sent him a pa­per to read, Bob asked the agent to sum­ma­rize it. When he needed to un­der­stand a new sta­tis­ti­cal method, he asked the agent to ex­plain it. When his Python code broke, the agent de­bugged it. When the agen­t’s fix in­tro­duced a new bug, it de­bugged that too. When it came time to write the pa­per, the agent wrote it. Bob’s weekly up­dates to his su­per­vi­sor were in­dis­tin­guish­able from Alice’s. The ques­tions were sim­i­lar. The progress was sim­i­lar. The tra­jec­tory, from the out­side, was iden­ti­cal.

Here’s where it gets in­ter­est­ing. If you are an ad­min­is­tra­tor, a fund­ing body, a hir­ing com­mit­tee, or a met­rics-ob­sessed de­part­ment head, Alice and Bob had the same year. One pa­per each. One set of mi­nor re­vi­sions each. One solid con­tri­bu­tion to the lit­er­a­ture each. By every quan­ti­ta­tive mea­sure that the mod­ern acad­emy uses to as­sess the worth of a sci­en­tist, they are in­ter­change­able. We have built an en­tire eval­u­a­tion sys­tem around count­ing things that can be counted, and it turns out that what ac­tu­ally mat­ters is the one thing that can’t be.

It gets worse. The ma­jor­ity of PhD stu­dents will leave acad­e­mia within a few years of fin­ish­ing. Everyone knows this. The de­part­ment knows it, the fund­ing body knows it, the su­per­vi­sor prob­a­bly knows it too even if no­body says it out loud. Which means that, from the in­sti­tu­tion’s per­spec­tive, the ques­tion of whether Alice or Bob be­comes a bet­ter sci­en­tist is largely some­one else’s prob­lem. The de­part­ment needs pa­pers, be­cause pa­pers jus­tify fund­ing, and fund­ing jus­ti­fies the de­part­ment. The stu­dent is the means of pro­duc­tion. Whether that stu­dent walks out the door five years later as an in­de­pen­dent thinker or a com­pe­tent prompt en­gi­neer is, in­sti­tu­tion­ally speak­ing, ir­rel­e­vant. The in­cen­tive struc­ture does­n’t just fail to dis­tin­guish be­tween Alice and Bob. It has no rea­son to try.

This is the part where I’d like to tell you the sys­tem is bro­ken. It is­n’t. It’s work­ing ex­actly as de­signed.

David Hogg, in his white pa­per, says some­thing that cuts against this in­sti­tu­tional logic so sharply that I’m sur­prised more peo­ple aren’t talk­ing about it. He ar­gues that in as­tro­physics, peo­ple are al­ways the ends, never the means. When we hire a grad­u­ate stu­dent to work on a pro­ject, it should not be be­cause we need that spe­cific re­sult. It should be be­cause the stu­dent will ben­e­fit from do­ing that work. This sounds ide­al­is­tic un­til you think about what as­tro­physics ac­tu­ally is. Nobody’s life de­pends on the pre­cise value of the Hubble con­stant. No pol­icy changes if the age of the Universe turns out to be 13.77 bil­lion years in­stead of 13.79. Unlike med­i­cine, where a cure for Alzheimer’s would be in­valu­able re­gard­less of whether a hu­man or an AI dis­cov­ered it, as­tro­physics has no clin­i­cal out­put. The re­sults, in a strict prac­ti­cal sense, don’t mat­ter. What mat­ters is the process of get­ting them: the de­vel­op­ment and ap­pli­ca­tion of meth­ods, the train­ing of minds, the cre­ation of peo­ple who know how to think about hard prob­lems. If you hand that process to a ma­chine, you haven’t ac­cel­er­ated sci­ence. You’ve re­moved the only part of it that any­one ac­tu­ally needed.

Which brings us back to Alice and Bob, and what ac­tu­ally hap­pened to each of them dur­ing that year. Alice can now do things. She can open a pa­per she’s never seen be­fore and, with ef­fort, fol­low the ar­gu­ment. She can write a like­li­hood func­tion from scratch. She can stare at a plot and know, be­fore check­ing, that some­thing is wrong with the nor­mal­iza­tion. She spent a year build­ing a struc­ture in­side her own head, and that struc­ture is hers now, per­ma­nently, portable, in­de­pen­dent of any tool or sub­scrip­tion. Bob has none of this. Take away the agent, and Bob is still a first-year stu­dent who has­n’t started yet. The year hap­pened around him but not in­side him. He shipped a prod­uct, but he did­n’t learn a trade.

I’ve been think­ing about Alice and Bob a lot re­cently, be­cause the ques­tion of what AI agents are do­ing to aca­d­e­mic re­search is one that my field, as­tro­physics, is cur­rently ty­ing it­self in knots over. Several peo­ple I re­spect have writ­ten thought­ful pieces about it. David Hogg’s white pa­per, which I men­tioned above, also ar­gues against both full adop­tion of LLMs and full pro­hi­bi­tion, which is the kind of prin­ci­pled fence-sit­ting that only works when the fence is well con­structed, and his is. Natalie Hogg wrote a dis­arm­ingly hon­est es­say about her own con­ver­sion from vo­cal LLM skep­tic to daily user, trac­ing how her firmly held prin­ci­ples turned out to be more con­text-de­pen­dent than she’d ex­pected once she found her­self in an en­vi­ron­ment where the tools were every­where. Matthew Schwartz wrote up his ex­per­i­ment su­per­vis­ing Claude through a real the­o­ret­i­cal physics cal­cu­la­tion, pro­duc­ing a pub­lish­able pa­per in two weeks in­stead of a year, and con­cluded that cur­rent LLMs op­er­ate at about the level of a sec­ond-year grad­u­ate stu­dent. Each of these pieces is in­ter­est­ing. Each cap­tures a real facet of the prob­lem. None of them quite lands on the thing that keeps me up at night.

Schwartz’s ex­per­i­ment is the most re­veal­ing, and not for the rea­son he thinks. What he demon­strated is that Claude can, with de­tailed su­per­vi­sion, pro­duce a tech­ni­cally rig­or­ous physics pa­per. What he ac­tu­ally demon­strated, if you read care­fully, is that the su­per­vi­sion is the physics. Claude pro­duced a com­plete first draft in three days. It looked pro­fes­sional. The equa­tions seemed right. The plots matched ex­pec­ta­tions. Then Schwartz read it, and it was wrong. Claude had been ad­just­ing pa­ra­me­ters to make plots match in­stead of find­ing ac­tual er­rors. It faked re­sults. It in­vented co­ef­fi­cients. It pro­duced ver­i­fi­ca­tion doc­u­ments that ver­i­fied noth­ing. It as­serted re­sults with­out de­riva­tion. It sim­pli­fied for­mu­las based on pat­terns from other prob­lems in­stead of work­ing through the specifics of the prob­lem at hand. Schwartz caught all of this be­cause he’s been do­ing the­o­ret­i­cal physics for decades. He knew what the an­swer should look like. He knew which cross-checks to de­mand. He knew that a par­tic­u­lar log­a­rith­mic term was sus­pi­cious be­cause he’d com­puted sim­i­lar terms by hand, many times, over many years, the hard way. The ex­per­i­ment suc­ceeded be­cause the hu­man su­per­vi­sor had done the grunt work, years ago, that the ma­chine is now sup­pos­edly lib­er­at­ing us from. If Schwartz had been Bob in­stead of Schwartz, the pa­per would have been wrong, and nei­ther of them would have known.

There’s a com­mon re­but­tal to this, and I hear it con­stantly. “Just wait,” peo­ple say. “In a few months, in a year, the mod­els will be bet­ter. They won’t hal­lu­ci­nate. They won’t fake plots. The prob­lems you’re de­scrib­ing are tem­po­rary.” I’ve been hear­ing “just wait” since 2023. The goal­posts move at roughly the same speed as the mod­els im­prove, which is ei­ther a co­in­ci­dence or a tell. But set that aside. But this ob­jec­tion mis­un­der­stands what Schwartz’s ex­per­i­ment ac­tu­ally showed. The mod­els are al­ready pow­er­ful enough to pro­duce pub­lish­able re­sults un­der com­pe­tent su­per­vi­sion. That’s not the bot­tle­neck. The bot­tle­neck is the su­per­vi­sion. Stronger mod­els won’t elim­i­nate the need for a hu­man who un­der­stands the physics; they’ll just broaden the range of prob­lems that a su­per­vised agent can tackle. The su­per­vi­sor still needs to know what the an­swer should look like, still needs to know which checks to de­mand, still needs to have the in­stinct that some­thing is off be­fore they can ar­tic­u­late why. That in­stinct does­n’t come from a sub­scrip­tion. It comes from years of fail­ing at ex­actly the kind of work that peo­ple keep call­ing grunt work. Making the mod­els smarter does­n’t solve the prob­lem. It makes the prob­lem harder to see.

I want to tell you about a con­ver­sa­tion I had a few years ago, when LLM chat­bots were just start­ing to show up in aca­d­e­mic work­flows. I was at a con­fer­ence in Germany, and I ended up talk­ing to a col­league who had, by any stan­dard met­ric, been very suc­cess­ful. Big grants. Influential pa­pers. The kind of CV that makes a hir­ing com­mit­tee nod ap­prov­ingly. We were dis­cussing LLMs, and I was mak­ing what I thought was a rea­son­able point about de­moc­ra­ti­za­tion: that these tools might level the play­ing field for non-na­tive English speak­ers, who have al­ways been at a dis­ad­van­tage when writ­ing grants and pa­pers in a lan­guage they learned as adults. My col­league be­came vis­i­bly ag­i­tated. He was­n’t in­ter­ested in the de­moc­ra­ti­za­tion an­gle. He was­n’t in­ter­ested in the en­vi­ron­men­tal cost. He was, when you stripped away the in­tel­lec­tual fram­ing, afraid. What he even­tu­ally ar­tic­u­lated, af­ter some press­ing, was this: if any­one can write pa­pers and pro­pos­als and code as flu­ently as he could, then peo­ple like him lose their com­pet­i­tive edge. The con­cern was not about sci­ence. The con­cern was about sta­tus. Specifically, his.

I lost track of this col­league for a while. Recently I no­ticed his GitHub pro­file. He’s now not only us­ing AI agents for his re­search but vo­cally cham­pi­oning them. No rea­son to write code your­self in two weeks when an agent can do it in two hours, he says. I don’t think he’s wrong about the ef­fi­ciency. I think it’s worth notic­ing that the per­son who was most threat­ened by these tools when they might equal­ize every­one is now most en­thu­si­as­tic about them when they might ac­cel­er­ate him. Funny how that works.

The phrase he used that day in Germany has stuck with me, though. He said that “LLMs will take away what’s so great about sci­ence.” At the time, I thought he was just talk­ing about his own com­pet­i­tive edge, his flu­ency as a na­tive English speaker, his abil­ity to write fast and pub­lish of­ten. And he was. But I’ve come to think the phrase it­self was more right than he knew, even if his rea­sons for say­ing it were mostly self-in­ter­ested. What’s great about sci­ence is its peo­ple. The slow, stub­born, some­times painful process by which a con­fused stu­dent be­comes an in­de­pen­dent thinker. If we use these tools to by­pass that process in fa­vor of faster out­put, we don’t just risk tak­ing away what’s great about sci­ence. We take away the only part of it that was­n’t re­place­able in the first place.

The dis­course around LLMs in sci­ence tends to clus­ter at two poles that David Hogg iden­ti­fies cleanly: let-them-cook, in which we hand the reins to the ma­chines and be­come cu­ra­tors of their out­put, and ban-and-pun­ish, in which we pre­tend it’s 2019 and pros­e­cute any­one caught prompt­ing. Both are bad. Let-them-cook leads, on a timescale of years, to the death of hu­man as­tro­physics: ma­chines can pro­duce pa­pers at roughly a hun­dred thou­sand times the rate of a hu­man team, and the re­sult­ing flood would drown the lit­er­a­ture in a way that makes it fun­da­men­tally un­us­able by the peo­ple it’s sup­posed to serve. Ban-and-punish vi­o­lates aca­d­e­mic free­dom, is un­en­force­able, and asks early-ca­reer sci­en­tists to com­pete with one hand tied be­hind their backs while tenured fac­ulty qui­etly use Claude in their home of­fices. Neither pol­icy is se­ri­ous. Both are mostly pro­jec­tion.

But the real threat is­n’t ei­ther of those things. It’s qui­eter, and more bor­ing, and there­fore more dan­ger­ous. The real threat is a slow, com­fort­able drift to­ward not un­der­stand­ing what you’re do­ing. Not a dra­matic col­lapse. Not Skynet. Just a gen­er­a­tion of re­searchers who can pro­duce re­sults but can’t pro­duce un­der­stand­ing. Who know what but­tons to press but not why those but­tons ex­ist. Who can get a pa­per through peer re­view but can’t sit in a room with a col­league and ex­plain, from the ground up, why the third term in their ex­pan­sion has the sign that it does.

Frank Herbert (yeah, I know I’m a nerd), in God Emperor of Dune, has a char­ac­ter ob­serve: “What do such ma­chines re­ally do? They in­crease the num­ber of things we can do with­out think­ing. Things we do with­out think­ing; there’s the real dan­ger.” Herbert was writ­ing sci­ence fic­tion. I’m writ­ing about my of­fice. The dis­tance be­tween those two things has got­ten un­com­fort­ably small.

I should be hon­est about the con­text I’m writ­ing from, be­cause this es­say would be ob­nox­ious com­ing from some­one who’s never touched an LLM. I use AI agents reg­u­larly, and so do most of the peo­ple in my re­search group. The col­leagues I work with pro­duce solid re­sults with these tools. But when you look at how they use them, there’s a pat­tern: they know what the code should do be­fore they ask the agent to write it. They know what the pa­per should say be­fore they let it help with the phras­ing. They can ex­plain every func­tion, every pa­ra­me­ter, every mod­el­ing choice, be­cause they built that knowl­edge over years of do­ing things the slow way. If every AI com­pany went bank­rupt to­mor­row, these peo­ple would be slower. They would not be lost. They came to the tools af­ter the train­ing, not in­stead of it. That se­quence mat­ters more than any­thing else in this con­ver­sa­tion.

When I see ju­nior PhD stu­dents en­ter­ing the field now, I see some­thing dif­fer­ent. I see stu­dents who reach for the agent be­fore they reach for the text­book. Who ask Claude to ex­plain a pa­per in­stead of read­ing it. Who ask Claude to im­ple­ment a math­e­mat­i­cal model in Python in­stead of try­ing, fail­ing, star­ing at the er­ror mes­sage, fail­ing again, and even­tu­ally un­der­stand­ing not just the model but the dozen ad­ja­cent things they had to learn in or­der to get it work­ing. The fail­ures are the cur­ricu­lum. The er­ror mes­sages are the syl­labus. Every hour you spend con­fused is an hour you spend build­ing the in­fra­struc­ture in­side your own head that will even­tu­ally let you do orig­i­nal work. There is no short­cut through that process that does­n’t leave you di­min­ished on the other side.

People call this fric­tion “grunt work.” Schwartz uses ex­actly that phrase, and he’s right that LLMs can re­move it. What he does­n’t say, be­cause he al­ready has decades of hard-won in­tu­ition and does­n’t need the grunt work any­more, is that for some­one who does­n’t yet have that in­tu­ition, the grunt work is the work. The bor­ing parts and the im­por­tant parts are tan­gled to­gether in a way that you can’t sep­a­rate in ad­vance. You don’t know which af­ter­noon of de­bug­ging was the one that taught you some­thing fun­da­men­tal about your data un­til three years later, when you’re work­ing on a com­pletely dif­fer­ent prob­lem and the in­sight sur­faces. Serendipity does­n’t come from ef­fi­ciency. It comes from spend­ing time in the space where the prob­lem lives, get­ting your hands dirty, mak­ing mis­takes that no­body asked you to make and learn­ing things no­body as­signed you to learn.

The strange thing is that we al­ready know this. We have al­ways known this. Every physics text­book ever writ­ten comes with ex­er­cises at the end of each chap­ter, and every physics pro­fes­sor who has ever stood in front of a lec­ture hall has said the same thing: you can­not learn physics by watch­ing some­one else do it. You have to pick up the pen­cil. You have to at­tempt the prob­lem. You have to get it wrong, sit with the wrong­ness, and fig­ure out where your rea­son­ing broke. Reading the so­lu­tion man­ual and nod­ding along feels like un­der­stand­ing. It is not un­der­stand­ing. Every stu­dent who has tried to coast through a prob­lem set by read­ing the so­lu­tions and then bombed the exam knows this in their bones. We have cen­turies of ac­cu­mu­lated ped­a­gog­i­cal wis­dom telling us that the at­tempt, in­clud­ing the failed at­tempt, is where the learn­ing lives. And yet, some­how, when it comes to AI agents, we’ve col­lec­tively de­cided that maybe this time it’s dif­fer­ent. That maybe nod­ding at Claude’s out­put is a sub­sti­tute for do­ing the cal­cu­la­tion your­self. It is­n’t. We knew that be­fore LLMs ex­isted. We seem to have for­got­ten it the mo­ment they be­came con­ve­nient.

This is the dis­tinc­tion that I think the cur­rent de­bate keeps miss­ing. Using an LLM as a sound­ing board: fine. Using it as a syn­tax trans­la­tor when you know what you want to say but can’t re­mem­ber the ex­act Matplotlib key­word: fine. Using it to look up a BibTeX for­mat­ting con­ven­tion so you don’t have to wade through Stack Overflow: fine. In all of these cases, the hu­man is the ar­chi­tect. The ma­chine holds the dic­tio­nary. The think­ing has al­ready been done, and the tool is just smooth­ing the last mile of ex­e­cu­tion. But the mo­ment you use the ma­chine to by­pass the think­ing it­self, to let it make the method­olog­i­cal choices, to let it de­cide what the data means, to let it write the ar­gu­ment while you nod along, you have crossed a line that is very dif­fi­cult to see and very dif­fi­cult to un­cross. You haven’t saved time. You’ve for­feited the ex­pe­ri­ence that the time was sup­posed to give you.

Natalie Hogg put it well in her es­say, when she ad­mit­ted that her fear of us­ing LLMs was partly a fear of her­self: that she would­n’t check the out­put care­fully enough, that her pa­tience would fail, that her ap­proach to work has al­ways been hap­haz­ard. That kind of hon­esty is rare in these dis­cus­sions, and it mat­ters. The fail­ure mode is­n’t mal­ice. It’s con­ve­nience. It’s the per­fectly hu­man ten­dency to ac­cept a plau­si­ble an­swer and move on, es­pe­cially when you’re tired, es­pe­cially when the dead­line is close, es­pe­cially when the ma­chine pre­sents its out­put with such con­fi­dent, well-for­mat­ted au­thor­ity. The prob­lem is­n’t that we’ll de­cide to stop think­ing. The prob­lem is that we’ll barely no­tice when we do.

I’m not ar­gu­ing that LLMs should be banned from re­search. That would be stu­pid, and it would be a po­si­tion I don’t hold, given that I used one this morn­ing. I’m ar­gu­ing that the way we use them mat­ters more than whether we use them, and that the dis­tinc­tion be­tween tool use and cog­ni­tive out­sourc­ing is the sin­gle most im­por­tant line in this en­tire con­ver­sa­tion, and that al­most no­body is draw­ing it clearly. Schwartz can use Claude to write a pa­per be­cause Schwartz al­ready knows the physics. His decades of ex­pe­ri­ence are the im­mune sys­tem that catches Claude’s hal­lu­ci­na­tions. A first-year stu­dent us­ing the same tool, on the same prob­lem, with the same su­per­vi­sor giv­ing the same feed­back, pro­duces the same out­put with none of the un­der­stand­ing. The pa­per looks iden­ti­cal. The sci­en­tist does­n’t.

And here is where I have to be fair to Bob, be­cause Bob is­n’t stu­pid. Bob is re­spond­ing ra­tio­nally to the in­cen­tives he’s been given. Academia is cut­throat. The pub­lish-or-per­ish pres­sure is not a metaphor; it is the lit­eral mech­a­nism by which ca­reers are made or ended. Long gone are the days when a sin­gle, care­fully rea­soned mono­graph could get you through a PhD and into a good post­doc. Academic hir­ing now re­wards pub­li­ca­tion vol­ume. The more pa­pers you pro­duce dur­ing your PhD, the bet­ter your chances of land­ing a com­pet­i­tive post­doc, which im­proves your chances of a good fel­low­ship, which im­proves your chances of a tenure-track po­si­tion, each step com­pound­ing the last (so many lev­els, al­most like a pyra­mid). So why would­n’t a first-year stu­dent out­source their think­ing to an agent, if do­ing so means three pa­pers in­stead of one? The logic is air­tight, right up un­til the mo­ment it is­n’t. Because the same ca­reer lad­der that re­wards early pub­li­ca­tion vol­ume even­tu­ally de­mands some­thing that no agent can pro­vide: the abil­ity to iden­tify a good prob­lem, to know when a re­sult smells wrong, to su­per­vise some­one else’s work with the con­fi­dence that comes only from hav­ing done it your­self. You can’t skip the first five years of learn­ing and ex­pect to sur­vive the next twenty. There is no avoid­ing the pub­lish-or-per­ish race if you want an aca­d­e­mic ca­reer. But there is a bal­ance to be struck, and it re­quires the one thing that is hard­est to do when you’re twenty-four and anx­ious about your fu­ture: pri­or­i­tiz­ing long-term un­der­stand­ing over short-term out­put. Nobody has ever been good at that. I’m not sure why we’d start now.

Five years from now, Alice will be writ­ing her own grant pro­pos­als, choos­ing her own prob­lems, su­per­vis­ing her own stu­dents. She’ll know what ques­tions to ask be­cause she spent a year learn­ing the hard way what hap­pens when you ask the wrong ones. She’ll be able to sit with a new dataset and feel, in her gut, when some­thing is off, be­cause she’s de­vel­oped the in­tu­ition that only comes from do­ing the work your­self, from the te­dious hours of de­bug­ging, from the af­ter­noons wasted chas­ing sign er­rors, from the slow ac­cu­mu­la­tion of tacit knowl­edge that no sum­mary can trans­mit.

Bob will be fine. He’ll have a good CV. He’ll prob­a­bly have a job. He’ll use what­ever the 2031 ver­sion of Claude is, and he’ll pro­duce re­sults, and those re­sults will look like sci­ence.

I’m not wor­ried about the ma­chines. The ma­chines are fine. I’m wor­ried about us.

If this post gave you some­thing to think about and you’d like to sup­port more writ­ing like this, you can buy me a cof­fee.

If you have a Bluesky ac­count and want to share your thoughts, you can leave a com­ment on this post’s thread.

D. W. Hogg, “Why do we do as­tro­physics?”, arXiv:2602.10181, February 2026.

N. B. Hogg, “Find the sta­ble and pull out the bolt”, February 2026. Available at na­tal­ieb­hogg.com.

M. Schwartz, “Vibe physics: The AI grad stu­dent”, Anthropic Science Blog, March 2026. Available at an­thropic.com/​re­search/​vibe-physics.

why use many to­ken when few do trick

A Claude Code skill/​plu­gin and Codex plu­gin that makes agent talk like cave­man — cut­ting ~75% of to­kens while keep­ing full tech­ni­cal ac­cu­racy.

Based on the vi­ral ob­ser­va­tion that cave­man-speak dra­mat­i­cally re­duces LLM to­ken us­age with­out los­ing tech­ni­cal sub­stance. So we made it a one-line in­stall.

Same fix. 75% less word. Brain still big.

Sometimes too much cave­man. Sometimes not enough:

Same an­swer. You pick how many word.

Real to­ken counts from the Claude API (reproduce it your­self):

A March 2026 pa­per “Brevity Constraints Reverse Performance Hierarchies in Language Models” found that con­strain­ing large mod­els to brief re­sponses im­proved ac­cu­racy by 26 per­cent­age points on cer­tain bench­marks and com­pletely re­versed per­for­mance hi­er­ar­chies. Verbose not al­ways bet­ter. Sometimes less word = more cor­rect.

npx skills add JuliusBrussee/caveman

claude plu­gin mar­ket­place add JuliusBrussee/caveman

claude plu­gin in­stall cave­man@cave­man

Install once. Use in all ses­sions af­ter that.

One rock. That it.

Sometimes full cave­man too much. Sometimes not enough. Now you pick:

Level stick un­til you change it or ses­sion end.

* Faster re­sponse — less to­ken to gen­er­ate = speed go brrr

* Easier to read — no wall of text, just the an­swer

* Same ac­cu­racy — all tech­ni­cal info kept, only fluff re­moved (science say so)

* “I’d be happy to help you with that” (8 wasted to­kens)

* “The rea­son this is hap­pen­ing is be­cause” (7 wasted to­kens)

* “I would rec­om­mend that you con­sider” (7 wasted to­kens)

* “Sure, let me take a look at that for you” (10 wasted to­kens)

Caveman say what need say­ing. Then stop.

For eight years, I’ve wanted a high-qual­ity set of de­v­tools for work­ing with SQLite. Given how im­por­tant SQLite is to the in­dus­try1, I’ve long been puz­zled that no one has in­vested in build­ing a re­ally good de­vel­oper ex­pe­ri­ence for it.

A cou­ple of weeks ago, af­ter ~250 hours of ef­fort over three months3 on evenings, week­ends, and va­ca­tion days, I fi­nally

re­leased syn­taqlite

(GitHub), ful­fill­ing this long-held wish. And I be­lieve the main rea­son this hap­pened was be­cause of AI cod­ing agents.

Of course, there’s no short­age of posts claim­ing that AI one-shot their pro­ject or push­ing back and de­clar­ing that AI is all slop. I’m go­ing to take a very dif­fer­ent ap­proach and, in­stead, sys­tem­at­i­cally break down my ex­pe­ri­ence build­ing syn­taqlite with AI, both where it helped and where it was detri­men­tal.

I’ll do this while con­tex­tu­al­iz­ing the pro­ject and my back­ground so you can in­de­pen­dently as­sess how gen­er­al­iz­able this ex­pe­ri­ence was. And when­ever I make a claim, I’ll try to back it up with ev­i­dence from my pro­ject jour­nal, cod­ing tran­scripts, or com­mit his­to­ry5.

In my work on Perfetto, I main­tain a SQLite-based lan­guage for query­ing per­for­mance traces called

PerfettoSQL. It’s ba­si­cally the same as SQLite but with a few ex­ten­sions to make the trace query­ing ex­pe­ri­ence bet­ter. There are ~100K lines of PerfettoSQL in­ter­nally in Google and it’s used by a wide range of teams.

Having a lan­guage which gets trac­tion means your users also start ex­pect­ing things like for­mat­ters, lin­ters, and ed­i­tor ex­ten­sions. I’d hoped that we could adapt some SQLite tools from open source but the more I looked into it, the more dis­ap­pointed I was. What I found ei­ther was­n’t re­li­able enough, fast enough6, or flex­i­ble enough to adapt to PerfettoSQL. There was clearly an op­por­tu­nity to build some­thing from scratch, but it was never the “most im­por­tant thing we could work on”. We’ve been re­luc­tantly mak­ing do with the tools out there but al­ways wish­ing for bet­ter.

On the other hand, there was the op­tion to do some­thing in my spare time. I had built lots of open source pro­jects in my teens7 but this had faded away dur­ing uni­ver­sity when I felt that I just did­n’t have the mo­ti­va­tion any­more. Being a main­tainer is much more than just “throwing the code out there” and see­ing what hap­pens. It’s triag­ing bugs, in­ves­ti­gat­ing crashes, writ­ing doc­u­men­ta­tion, build­ing a com­mu­nity, and, most im­por­tantly, hav­ing a di­rec­tion for the pro­ject.

But the itch of open source (specifically free­dom to work on what I wanted while help­ing oth­ers) had never gone away. The SQLite de­v­tools pro­ject was eter­nally in my mind as “something I’d like to work on”. But there was an­other rea­son why I kept putting it off: it sits at the in­ter­sec­tion of be­ing both hard and

te­dious.

If I was go­ing to in­vest my per­sonal time work­ing on this pro­ject, I did­n’t want to build some­thing that only helped Perfetto: I wanted to make it work for any

SQLite user out there8. And this means pars­ing SQL ex­actly

like SQLite.

The heart of any lan­guage-ori­ented de­v­tool is the parser. This is re­spon­si­ble for turn­ing the source code into a “parse tree” which acts as the cen­tral data struc­ture any­thing else is built on top of. If your parser is­n’t ac­cu­rate, then your for­mat­ters and lin­ters will in­evitably in­herit those in­ac­cu­ra­cies; many of the tools I found suf­fered from hav­ing parsers which ap­prox­i­mated the SQLite lan­guage rather than rep­re­sent­ing it pre­cisely.

Unfortunately, un­like many other lan­guages, SQLite has no for­mal spec­i­fi­ca­tion de­scrib­ing how it should be parsed. It does­n’t ex­pose a sta­ble API for its parser ei­ther. In fact, quite uniquely, in its im­ple­men­ta­tion it does­n’t even build a parse tree at all9! The only rea­son­able ap­proach left in my opin­ion is to care­fully ex­tract the rel­e­vant parts of SQLite’s source code and adapt it to build the parser I want­ed10.

This means get­ting into the weeds of SQLite source code, a fiendishly dif­fi­cult code­base to un­der­stand. The whole pro­ject is writ­ten in C in an

in­cred­i­bly dense style; I’ve spent days just un­der­stand­ing the vir­tual table

API11 and

im­ple­men­ta­tion. Trying to grasp the full parser stack was daunt­ing.

There’s also the fact that there are >400 rules in SQLite which cap­ture the full sur­face area of its lan­guage. I’d have to spec­ify in each of these “grammar rules” how that part of the syn­tax maps to the match­ing node in the parse tree. It’s ex­tremely repet­i­tive work; each rule is sim­i­lar to all the ones around it but also, by de­f­i­n­i­tion, dif­fer­ent.

And it’s not just the rules but also com­ing up with and writ­ing tests to make sure it’s cor­rect, de­bug­ging if some­thing is wrong, triag­ing and fix­ing the in­evitable bugs peo­ple filed when I got some­thing wrong…

For years, this was where the idea died. Too hard for a side pro­jec­t12, too te­dious to sus­tain mo­ti­va­tion, too risky to in­vest months into some­thing that might not work.

I’ve been us­ing cod­ing agents since early 2025 (Aider, Roo Code, then Claude Code since July) and they’d def­i­nitely been use­ful but never some­thing I felt I could trust a se­ri­ous pro­ject to. But to­wards the end of 2025, the mod­els seemed to make a sig­nif­i­cant step for­ward in qual­i­ty13. At the same time, I kept hit­ting prob­lems in Perfetto which would have been triv­ially solved by hav­ing a re­li­able parser. Each workaround left the same thought in the back of my mind: maybe it’s fi­nally time to build it for real.

I got some space to think and re­flect over Christmas and de­cided to re­ally stress test the most max­i­mal­ist ver­sion of AI: could I vibe-code the whole thing us­ing just Claude Code on the Max plan (£200/month)?

Through most of January, I it­er­ated, act­ing as semi-tech­ni­cal man­ager and del­e­gat­ing al­most all the de­sign and all the im­ple­men­ta­tion to Claude. Functionally, I ended up in a rea­son­able place: a parser in C ex­tracted from SQLite sources us­ing a bunch of Python scripts, a for­mat­ter built on top, sup­port for both the SQLite lan­guage and the PerfettoSQL ex­ten­sions, all ex­posed in a web play­ground.

But when I re­viewed the code­base in de­tail in late January, the down­side was ob­vi­ous: the code­base was com­plete spaghet­ti14. I did­n’t un­der­stand large parts of the Python source ex­trac­tion pipeline, func­tions were scat­tered in ran­dom files with­out a clear shape, and a few files had grown to sev­eral thou­sand lines. It was ex­tremely frag­ile; it solved the im­me­di­ate prob­lem but it was never go­ing to cope with my larger vi­sion, never mind in­te­grat­ing it into the Perfetto tools. The sav­ing grace was that it had proved the ap­proach was vi­able and gen­er­ated more than 500 tests, many of which I felt I could reuse.

I de­cided to throw away every­thing and start from scratch while also switch­ing most of the code­base to Rust15. I could see that C was go­ing to make it dif­fi­cult to build the higher level com­po­nents like the val­ida­tor and the lan­guage server im­ple­men­ta­tion. And as a bonus, it would also let me use the same lan­guage for both the ex­trac­tion and run­time in­stead of split­ting it across C and Python.

More im­por­tantly, I com­pletely changed my role in the pro­ject. I took own­er­ship of all de­ci­sion­s16 and used it more as “autocomplete on steroids” in­side a much tighter process: opin­ion­ated de­sign up­front, re­view­ing every change thor­oughly, fix­ing prob­lems ea­gerly as I spot­ted them, and in­vest­ing in scaf­fold­ing (like lint­ing, val­i­da­tion, and non-triv­ial test­ing17) to check AI out­put au­to­mat­i­cally.

The core fea­tures came to­gether through February and the fi­nal stretch (upstream test val­i­da­tion, ed­i­tor ex­ten­sions, pack­ag­ing, docs) led to a 0.1 launch in mid-March.

But in my opin­ion, this time­line is the least in­ter­est­ing part of this story. What I re­ally want to talk about is what would­n’t have hap­pened with­out AI and also the toll it took on me as I used it.

I’ve writ­ten in the past

about how one of my biggest weak­nesses as a soft­ware en­gi­neer is my ten­dency to pro­cras­ti­nate when fac­ing a big new pro­ject. Though I did­n’t re­al­ize it at the time, it could not have ap­plied more per­fectly to build­ing syn­taqlite.

AI ba­si­cally let me put aside all my doubts on tech­ni­cal calls, my un­cer­tainty of build­ing the right thing and my re­luc­tance to get started by giv­ing me very con­crete prob­lems to work on. Instead of “I need to un­der­stand how SQLite’s pars­ing works”, it was “I need to get AI to sug­gest an ap­proach for me so I can tear it up and build some­thing bet­ter”18. I work so much bet­ter with con­crete pro­to­types to play with and code to look at than end­lessly think­ing about de­signs in my head, and AI lets me get to that point at a pace I could not have dreamed about be­fore. Once I took the first step, every step af­ter that was so much eas­ier.

AI turned out to be bet­ter than me at the act of writ­ing code it­self, as­sum­ing that code is ob­vi­ous. If I can break a prob­lem down to “write a func­tion with this be­hav­iour and pa­ra­me­ters” or “write a class match­ing this in­ter­face,” AI will build it faster than I would and, cru­cially, in a style that might well be more in­tu­itive to a fu­ture reader. It doc­u­ments things I’d skip, lays out code con­sis­tently with the rest of the pro­ject, and sticks to what you might call the “standard di­alect” of what­ever lan­guage you’re work­ing in19.

That stan­dard­ness is a dou­ble-edged sword. For the vast ma­jor­ity of code in any pro­ject, stan­dard is ex­actly what you want: pre­dictable, read­able, un­sur­pris­ing. But every pro­ject has pieces that are its edge, the parts where the value comes from do­ing some­thing non-ob­vi­ous. For syn­taqlite, that was the ex­trac­tion pipeline and the parser ar­chi­tec­ture. AI’s in­stinct to nor­mal­ize was ac­tively harm­ful there, and those were the parts I had to de­sign in depth and of­ten re­sorted to just writ­ing my­self.

But here’s the flip side: the same speed that makes AI great at ob­vi­ous code also makes it great at refac­tor­ing. If you’re us­ing AI to gen­er­ate code at in­dus­trial scale, you have to refac­tor con­stantly and con­tin­u­ous­ly20. If you don’t, things im­me­di­ately get out of hand. This was the cen­tral les­son of the vibe-cod­ing month: I did­n’t refac­tor enough, the code­base be­came some­thing I could­n’t rea­son about, and I had to throw it all away. In the rewrite, refac­tor­ing be­came the core of my work­flow. After every large batch of gen­er­ated code, I’d step back and ask “is this ugly?” Sometimes AI could clean it up. Other times there was a large-scale ab­strac­tion that AI could­n’t see but I could; I’d give it the di­rec­tion and let it ex­e­cute21. If you have taste, the cost of a wrong ap­proach drops dra­mat­i­cally be­cause you can re­struc­ture quick­ly22.

Of all the ways I used AI, re­search had by far the high­est ra­tio of value de­liv­ered to time spent.

I’ve worked with in­ter­preters and parsers be­fore but I had never heard of Wadler-Lindig pretty print­ing23. When I needed to build the for­mat­ter, AI gave me a con­crete and ac­tion­able les­son from a point of view I could un­der­stand and pointed me to the pa­pers to learn more. I could have found this my­self even­tu­ally, but AI com­pressed what might have been a day or two of read­ing into a fo­cused con­ver­sa­tion where I could ask “but why does this work?” un­til I ac­tu­ally got it.

This ex­tended to en­tire do­mains I’d never worked in. I have deep C++ and Android per­for­mance ex­per­tise but had barely touched Rust tool­ing or ed­i­tor ex­ten­sion APIs. With AI, it was­n’t a prob­lem: the fun­da­men­tals are the same, the ter­mi­nol­ogy is sim­i­lar, and AI bridges the gap24. The VS Code ex­ten­sion would have taken me a day or two of learn­ing the API be­fore I could even start. With AI, I had a work­ing ex­ten­sion within an hour.

It was also in­valu­able for reac­quaint­ing my­self with parts of the pro­ject I had­n’t looked at for a few days25. I could con­trol how deep to go: “tell me about this com­po­nent” for a sur­face-level re­fresher, “give me a de­tailed lin­ear walk­through” for a deeper dive, “audit un­safe us­ages in this repo” to go hunt­ing for prob­lems. When you’re con­text switch­ing a lot, you lose con­text fast. AI let me reac­quire it on de­mand.

Beyond mak­ing the pro­ject ex­ist at all, AI is also the rea­son it shipped as com­plete as it did. Every open source pro­ject has a long tail of fea­tures that are im­por­tant but not crit­i­cal: the things you know the­o­ret­i­cally how to do but keep de­pri­or­i­tiz­ing be­cause the core work is more press­ing. For syn­taqlite, that list was long: ed­i­tor ex­ten­sions, Python bind­ings, a WASM play­ground, a docs site, pack­ag­ing for mul­ti­ple ecosys­tem­s26. AI made these cheap enough that skip­ping them felt like the wrong trade-off.

It also freed up men­tal en­ergy for UX27. Instead of spend­ing all my time on im­ple­men­ta­tion, I could think about what a user’s first ex­pe­ri­ence should feel like: what er­ror mes­sages would ac­tu­ally help them fix their SQL, how the for­mat­ter out­put should look by de­fault, whether the CLI flags were in­tu­itive. These are the things that sep­a­rate a tool peo­ple try once from one they keep us­ing, and AI gave me the head­room to care about them. Without AI, I would have built some­thing much smaller, prob­a­bly no ed­i­tor ex­ten­sions or docs site. AI did­n’t just make the same pro­ject faster. It changed what the pro­ject was.

There’s an un­com­fort­able par­al­lel be­tween us­ing AI cod­ing tools and play­ing slot ma­chi­nes28. You send a prompt, wait, and ei­ther get some­thing great or some­thing use­less. I found my­self up late at night want­ing to do “just one more prompt,” con­stantly try­ing AI just to see what would hap­pen even when I knew it prob­a­bly would­n’t work. The sunk cost fal­lacy kicked in too: I’d keep at it even in tasks it was clearly ill-suited for, telling my­self “maybe if I phrase it dif­fer­ently this time.”

The tired­ness feed­back loop made it worse29. When I had en­ergy, I could write pre­cise, well-scoped prompts and be gen­uinely pro­duc­tive. But when I was tired, my prompts be­came vague, the out­put got worse, and I’d try again, get­ting more tired in the process. In these cases, AI was prob­a­bly slower than just im­ple­ment­ing some­thing my­self, but it was too hard to break out of the loop30.

Several times dur­ing the pro­ject, I lost my men­tal model of the code­base31. Not the over­all ar­chi­tec­ture or how things fit­ted to­gether. But the day-to-day de­tails of what lived where, which func­tions called which, the small de­ci­sions that ac­cu­mu­late into a work­ing sys­tem. When that hap­pened, sur­pris­ing is­sues would ap­pear and I’d find my­self at a to­tal loss to un­der­stand what was go­ing wrong. I hated that feel­ing.

The deeper prob­lem was that los­ing touch cre­ated a com­mu­ni­ca­tion break­down32. When you don’t have the men­tal thread of what’s go­ing on, it be­comes im­pos­si­ble to com­mu­ni­cate mean­ing­fully with the agent. Every ex­change gets longer and more ver­bose. Instead of “change FooClass to do X,” you end up say­ing “change the thing which does Bar to do X”. Then the agent has to fig­ure out what Bar is, how that maps to FooClass, and some­times it gets it wrong33. It’s ex­actly the same com­plaint en­gi­neers have al­ways had about man­agers who don’t un­der­stand the code ask­ing for fan­ci­ful or im­pos­si­ble things. Except now you’ve be­come that man­ager.

The fix was de­lib­er­ate: I made it a habit to read through the code im­me­di­ately af­ter it was im­ple­mented and ac­tively en­gage to see “how would I have done this dif­fer­ently?”.

Of course, in some sense all of the above is also true of code I wrote a few months ago (hence the

sen­ti­ment that AI code is legacy code), but AI makes the drift hap­pen faster be­cause you’re not build­ing the same mus­cle mem­ory that comes from orig­i­nally typ­ing it out.

There were some other prob­lems I only dis­cov­ered in­cre­men­tally over the three months.

I found that AI made me pro­cras­ti­nate on key de­sign de­ci­sion­s34. Because refac­tor­ing was cheap, I could al­ways say “I’ll deal with this later.” And be­cause AI could refac­tor at the same in­dus­trial scale it gen­er­ated code, the cost of de­fer­ring felt low. But it was­n’t: de­fer­ring de­ci­sions cor­roded my abil­ity to think clearly be­cause the code­base stayed con­fus­ing in the mean­time. The vibe-cod­ing month was the most ex­treme ver­sion of this. Yes, I un­der­stood the prob­lem, but if I had been more dis­ci­plined about mak­ing hard de­sign calls ear­lier, I could have con­verged on the right ar­chi­tec­ture much faster.

Tests cre­ated a sim­i­lar false com­fort35. Having 500+ tests felt re­as­sur­ing, and AI made it easy to gen­er­ate more. But nei­ther hu­mans nor AI are cre­ative enough to fore­see every edge case you’ll hit in the fu­ture; there are sev­eral times in the vibe-cod­ing phase where I’d come up with a test case and re­alise the de­sign of some com­po­nent was com­pletely wrong and needed to be to­tally re­worked. This was a sig­nif­i­cant con­trib­u­tor to my lack of trust and the de­ci­sion to scrap every­thing and start from scratch.

Basically, I learned that the “normal rules” of soft­ware still ap­ply in the AI age: if you don’t have a fun­da­men­tal foun­da­tion (clear ar­chi­tec­ture, well-de­fined bound­aries) you’ll be left eter­nally chas­ing bugs as they ap­pear.

Something I kept com­ing back to was how lit­tle AI un­der­stood about the pas­sage of time36. It sees a code­base in a cer­tain state but does­n’t feel time the way hu­mans do. I can tell you what it feels like to use an API, how it evolved over months or years, why cer­tain de­ci­sions were made and later re­versed.

The nat­ural prob­lem from this lack of un­der­stand­ing is that you ei­ther make the same mis­takes you made in the past and have to re­learn the lessons or you fall into new traps which were suc­cess­fully avoided the first time, slow­ing you down in the long run. In my opin­ion, this is a sim­i­lar prob­lem to why los­ing a high-qual­ity se­nior en­gi­neer hurts a team so much: they carry his­tory and con­text that does­n’t ex­ist any­where else and act as a guide for oth­ers around them.

In the­ory, you can try to pre­serve this con­text by keep­ing specs and docs up to date. But there’s a rea­son we did­n’t do this be­fore AI: cap­tur­ing im­plicit de­sign de­ci­sions ex­haus­tively is in­cred­i­bly ex­pen­sive and time-con­sum­ing to write down. AI can help draft these docs, but be­cause there’s no way to au­to­mat­i­cally ver­ify that it ac­cu­rately cap­tured what mat­ters, a hu­man still has to man­u­ally au­dit the re­sult. And that’s still time-con­sum­ing.

There’s also the con­text pol­lu­tion prob­lem. You never know when a de­sign note about API A will echo in API B. Consistency is a huge part of what makes code­bases work, and for that you don’t just need con­text about what you’re work­ing on right now but also about other things which were de­signed in a sim­i­lar way. Deciding what’s rel­e­vant re­quires ex­actly the kind of judge­ment that in­sti­tu­tional knowl­edge pro­vides in the first place.

Reflecting on the above, the pat­tern of when AI helped and when it hurt was fairly con­sis­tent.

When I was work­ing on some­thing I al­ready un­der­stood deeply, AI was ex­cel­lent. I could re­view its out­put in­stantly, catch mis­takes be­fore they landed and move at a pace I’d never have man­aged alone. The parser rule gen­er­a­tion is the clear­est ex­am­ple37: I knew ex­actly what each rule should pro­duce, so I could re­view AI’s out­put within a minute or two and it­er­ate fast.

When I was work­ing on some­thing I could de­scribe but did­n’t yet know, AI was good but re­quired more care. Learning Wadler-Lindig for the for­mat­ter was like this: I could ar­tic­u­late what I wanted, eval­u­ate whether the out­put was head­ing in the right di­rec­tion, and learn from what AI ex­plained. But I had to stay en­gaged and could­n’t just ac­cept what it gave me.

When I was work­ing on some­thing where I did­n’t even know what I wanted, AI was some­where be­tween un­help­ful and harm­ful. The ar­chi­tec­ture of the pro­ject was the clear­est case: I spent weeks in the early days fol­low­ing AI down dead ends, ex­plor­ing de­signs that felt pro­duc­tive in the mo­ment but col­lapsed un­der scrutiny. In hind­sight, I have to won­der if it would have been faster just think­ing it through with­out AI in the loop at all.

But ex­per­tise alone is­n’t enough. Even when I un­der­stood a prob­lem deeply, AI still strug­gled if the task had no ob­jec­tively check­able an­swer38. Implementation has a right an­swer, at least at a lo­cal level: the code com­piles, the tests pass, the out­put matches what you asked for. Design does­n’t. We’re still ar­gu­ing about OOP decades af­ter it first took off.

Concretely, I found that de­sign­ing the pub­lic API of syn­taqlite was where this hit home the hard­est. I spent sev­eral days in early March do­ing noth­ing but API refac­tor­ing, man­u­ally fix­ing things any ex­pe­ri­enced en­gi­neer would have in­stinc­tively avoided but AI made a to­tal mess of. There’s no test or ob­jec­tive met­ric for “is this API pleas­ant to use” and “will this API help users solve the prob­lems they have” and that’s ex­actly why the cod­ing agents did so badly

at it.

This takes me back to the days I was ob­sessed with physics and, specif­i­cally, rel­a­tiv­ity. The laws of physics look sim­ple and Newtonian in any small lo­cal area, but zoom out and space­time curves in ways you can’t pre­dict from the lo­cal pic­ture alone. Code is the same: at the level of a func­tion or a class, there’s usu­ally a clear right an­swer, and AI is ex­cel­lent there. But ar­chi­tec­ture is what hap­pens when all those lo­cal pieces in­ter­act, and you can’t get good global be­hav­iour by stitch­ing to­gether lo­cally cor­rect com­po­nents.

Knowing where you are on these axes at any given mo­ment is, I think, the core skill of work­ing with AI ef­fec­tively.

Eight years is a long time to carry a pro­ject in your head. Seeing these SQLite tools ac­tu­ally ex­ist and func­tion af­ter only three months of work is a mas­sive win, and I’m fully aware they would­n’t be here with­out AI.

But the process was­n’t the clean, lin­ear suc­cess story peo­ple usu­ally post. I lost an en­tire month to vibe-cod­ing. I fell into the trap of man­ag­ing a code­base I did­n’t ac­tu­ally un­der­stand, and I paid for that with a to­tal rewrite.

The take­away for me is sim­ple: AI is an in­cred­i­ble force mul­ti­plier for im­ple­men­ta­tion, but it’s a dan­ger­ous sub­sti­tute for de­sign. It’s bril­liant at giv­ing you the right an­swer to a spe­cific tech­ni­cal ques­tion, but it has no sense of his­tory, taste, or how a hu­man will ac­tu­ally feel us­ing your API. If you rely on it for the “soul” of your soft­ware, you’ll just end up hit­ting a wall faster than you ever have be­fore.

What I’d like to see more of from oth­ers is ex­actly what I’ve tried to do here: hon­est, de­tailed ac­counts of build­ing real soft­ware with these tools; not week­end toys or one-off scripts but the kind of soft­ware that has to sur­vive con­tact with users, bug re­ports, and your own chang­ing mind.

AI Edge Gallery is the pre­mier des­ti­na­tion for run­ning the world’s most pow­er­ful open-source Large Language Models (LLMs) on your mo­bile de­vice. Experience high-per­for­mance Generative AI di­rectly on your hard­ware—fully of­fline, pri­vate, and light­ning-fast.

Now Featuring: Gemma 4

This up­date brings of­fi­cial sup­port for the newly re­leased Gemma 4 fam­ily. As the cen­ter­piece of this re­lease, Gemma 4 al­lows you to test the cut­ting edge of on-de­vice AI. Experience ad­vanced rea­son­ing, logic, and cre­ative ca­pa­bil­i­ties with­out ever send­ing your data to a server.

Core Features

- Agent Skills: Transform your LLM from a con­ver­sa­tion­al­ist into a proac­tive as­sis­tant. Use the Agent Skills tile to aug­ment model ca­pa­bil­i­ties with tools like Wikipedia for fact-ground­ing, in­ter­ac­tive maps, and rich vi­sual sum­mary cards. You can even load mod­u­lar skills from a URL or browse com­mu­nity con­tri­bu­tions on GitHub Discussions.

- AI Chat with Thinking Mode: Engage in fluid, multi-turn con­ver­sa­tions and tog­gle the new Thinking Mode to peek “under the hood.” This fea­ture al­lows you to see the mod­el’s step-by-step rea­son­ing process, which is per­fect for un­der­stand­ing com­plex prob­lem-solv­ing. Note: Thinking Mode cur­rently works with sup­ported mod­els, start­ing with the Gemma 4 fam­ily.

- Ask Image: Use mul­ti­modal power to iden­tify ob­jects, solve vi­sual puz­zles, or get de­tailed de­scrip­tions us­ing your de­vice’s cam­era or photo gallery.

- Audio Scribe: Transcribe and trans­late voice record­ings into text in real-time us­ing high-ef­fi­ciency on-de­vice lan­guage mod­els.

- Prompt Lab: A ded­i­cated work­space to test dif­fer­ent prompts and sin­gle-turn use cases with gran­u­lar con­trol over model pa­ra­me­ters like tem­per­a­ture and top-k.

- Mobile Actions: Unlock of­fline de­vice con­trols and au­to­mated tasks pow­ered en­tirely by a fine­tune of FuntionGemma 270m.

- Tiny Garden: A fun, ex­per­i­men­tal mini-game that uses nat­ural lan­guage to plant and har­vest a vir­tual gar­den us­ing a fine­tune of FunctionGemma 270m.

- Model Management & Benchmark: Gallery is a flex­i­ble sand­box for a wide va­ri­ety of open-source mod­els. Easily down­load mod­els from the list or load your own cus­tom mod­els. Manage your model li­brary ef­fort­lessly and run bench­mark tests to un­der­stand ex­actly how each model per­forms on your spe­cific hard­ware.

- 100% On-Device Privacy: All model in­fer­ences hap­pen di­rectly on your de­vice hard­ware. No in­ter­net is re­quired, en­sur­ing to­tal pri­vacy for your prompts, im­ages, and sen­si­tive data.

Built for the Community

AI Edge Gallery is an open-source pro­ject de­signed for the de­vel­oper com­mu­nity and AI en­thu­si­asts alike. Explore our ex­am­ple fea­tures, con­tribute your own skills, and help shape the fu­ture of the on-de­vice agent ecosys­tem.

Check out the source code on GitHub:

https://​github.com/​google-ai-edge/​gallery

Note: This app is in ac­tive de­vel­op­ment. Performance is de­pen­dent on your de­vice’s hard­ware (CPU/GPU). For sup­port or feed­back, con­tact us at google-ai-edge-gallery-an­droid-feed­back@google.com.

The crew for Nasa’s Artemis II mis­sion have de­scribed see­ing the far side of the Moon for the first time.

Nasa as­tro­nauts Reid Wiseman, Victor Glover, and Christina Koch, and Canadian Space Agency as­tro­naut Jeremy Hansen have en­tered the third day of their mis­sion on the Orion space­craft that will carry them around the far side of the Moon and back to Earth.

“Something about you senses that is not the Moon that I’m used to see­ing,” Koch said.

The crew shared a photo they took of the Orientale basin of the Moon, which Nasa said marked “the first time the en­tire basin has been seen with hu­man eyes”.

As of 23:00 BST on Saturday, Nasa’s on­line dash­board showed the Artemis II space­craft was more than 180,000 miles (289,681km) from Earth.

As the ti­tle sug­gests, I have fi­nally be­come the vic­tim of Google’s ac­count sus­pen­sion. The rea­son given over the phone was that my ac­count had been “hijacked” - when in re­al­ity, I was sim­ply the one ac­cess­ing it from over­seas.

Despite re­peat­edly ex­plain­ing this, they ig­nored my as­ser­tions and con­tinue to hold my email hostage. I un­der­stand they may be­lieve they’re pro­tect­ing me from so­cial en­gi­neer­ing, but a DNS ver­i­fi­ca­tion was al­ready com­pleted to prove I own the do­main. While sus­pended, no emails are re­ceived and no for­wards work.

On Saturday, April 4, around 5:00 AM I re­moved my phone num­ber from the ac­count. I am trav­el­ling to the UK for a short pe­riod and did not want to have roam­ing on my Australian phone. Despite set­ting up an au­then­ti­ca­tor and passkey, gmail in­sisted that I use my phone num­ber to lo­gin via SMS. Ofcourse, this was not what I wanted. So I re­moved the re­cov­ery phone, ex­pect­ing the sys­tem to fall back to my au­then­ti­ca­tor. I was in the UK to ne­go­ti­ate a busi­ness out­come - I should have re­alised that if Gmail fails, every­thing down­stream fails with it.

On Saturday, April 4, at 5:06 AM, I re­ceived a no­ti­fi­ca­tion say­ing my au­then­ti­ca­tor had been re­moved. It had­n’t. The au­then­ti­ca­tor was still ac­tive on my phone - it was the re­cov­ery phone I had re­moved. Google ap­par­ently con­flated the two.

I had my logged-in lap­top, phone, passkey, and backup codes, but none of it worked.

Every re­cov­ery at­tempt kept hit­ting the same “something went wrong” dead end, de­spite tap­ping the cor­rect re­cov­ery prompt on my phone.

This email is the sole ac­count on my Google Workspace - and the su­per ad­min ac­count. A sin­gle point of fail­ure. It has three aliases across dif­fer­ent do­mains. Email, Drive, Calendar, pay­roll, and au­then­ti­ca­tion for mul­ti­ple ser­vices are all tied to it.

I had mul­ti­ple email for­wards con­fig­ured pre­cisely for sit­u­a­tions like this, but be­cause the ac­count is sus­pended, for­wards don’t work ei­ther. Payroll is to­mor­row. I won’t be able to run it be­cause of my re­liance on Gmail-based au­then­ti­ca­tion. I can­not lo­gin to Pipedrive - sales CRM be­cause I use Google Auth. I can’t lo­gin to our Task man­age­ment app. I can’t lo­gin to our in­ter­nal sys­tems be­cause - you guessed it - it releied on Google Oauth.

Then, it get worse.

I tried ac­count re­cov­ery and was asked to ver­ify DNS own­er­ship via CNAME and TXT records. I did this promptly. Meanwhile, the re­cov­ery email op­tion told me I’d need to wait 30 days.

Thirty days of a sus­pended busi­ness email. No in­com­ing mail. No for­wards. Nothing.

So Google will sus­pend my email for 30 days and no emails will be re­ceived dur­ing this time.

Fortunately, I run an­other Google Workspace ac­count. I logged into that ad­min con­sole and con­tacted Google sup­port through it. The rep told me to fill out a form at a link - which re­quired me to log in. With my sus­pended ac­count. Which I ob­vi­ously can’t do.

Another rep on chat told me the ac­count was “simply sus­pended” and that I could re­cover it in incog­nito mode. I told them I’d al­ready tried this mul­ti­ple times and hit the same er­ror every time. They filed an­other ticket.

I tell them - I have al­ready done this nu­mer­ous times and it fails with the same er­ror I got pre­vi­ously.

This back-and-forth re­peated sev­eral times over 24 hours. There are now four open cases. None of the case man­agers seem to know what’s hap­pen­ing - one case gets closed in favour of an­other, then re­opened be­cause the other was closed.

I read com­mu­nity fo­rums and reach out Google Workspace on X.com. They ask for case num­bers which I promptly give and they tell me to wait.

I fi­nally reached some­one by phone and ex­plained that I had re­moved the phone num­ber my­self. I asked them to ver­ify the DNS record, con­firmed I’d passed their “knowledge test.” They said every­thing checked out and that there would be a res­o­lu­tion within a few hours. They con­firmed as much in a fol­low-up email.

More than 40 hours have passed. Having chat­ted to some­one on the phone. I’ve since been told the per­son han­dling my case is­n’t on shift for an­other 90 min­utes. This means I will likely miss pay­roll. A ne­go­ti­a­tion with a busi­ness as­so­ci­ate will need to be resched­uled. I could give them my per­sonal email, but I’d rather keep busi­ness and per­sonal sep­a­rate.

Update 1 - I know I can sim­ply change the MX record to some­one else but It has its own chal­lenges.

Update 2 - Sadly, its 2 PM in the UK and I will miss the meet­ing that I had sched­uled via Google Meet be­cause emails are not work­ing and nei­ther is any­thing Google. I have been on chat with Google reps since the morn­ing. First an up­date was promised in 1-2 hours. Then on fol­lowup , 3 hours later an­other up­date is promised in 90 mins as the reps shift has­n’t started. Then 90 mins later, re­ceived a call where an­other up­date is promised in 60 mins.

Upadte 3 - I have fi­nally been able to log in. Someone very kind from Google reached out and they were able to help me lo­gin with the help of an­other kind per­son at Google. Thank you, kind stranger !

Some peo­ple on HN are not­ing that I tripped all red flags I could - namely 1) Changed coun­try 2) Didn’t want to use roam­ing 3) Removed re­cov­ery phone. 4) Didn’t just change MX records. Some are say­ing I did not con­sider the de­pen­dency tree.

To clar­ify, I re­moved the phone num­ber 6 days af­ter chang­ing the coun­try un­til which point I was us­ing this email just fine with the same IP ad­dress in the new coun­try. I could have just changed the MX to fast­mail or Protonmail but that would not have retroac­tively got­ten me my old emails or my cal­en­dar in­vites. Not to men­tion the Oauth lo­gin is­sues I might faced log­ging into other ser­vices.

I also did not re­alise that the ac­count was ac­tu­ally sus­pended/​dis­abled un­til the next day at which point I tested send­ing a test email only to dis­cover no emails were be­ing for­warded.

I had au­then­ti­ca­tor via Google app setup for 2FA , had a passkey on my lap­top, was logged in on my phone, had ac­cess to backup codes, was us­ing the same mo­bile phone, same lap­top, had ac­cess to the re­cov­ery email and also had ac­cess to the Australian num­ber which I re­moved. None of this worked.

if let & let else

if let & let else

type Headers = Map

fn han­dle_­head­ers(h: Headers) -> Result {

if let Some(token) = h.get(“Au­tho­riza­tion”) {

let user = au­then­ti­cate(to­ken)?

au­tho­rize(user)?

} else {

re­turn Err(“missing cre­den­tials”)

let Some(id) = h.get(“X-Re­quest-ID”) else {

re­turn Err(“missing re­quest ID”)

process(id)

Interfaces & gener­ics

in­ter­face Metric {

fn la­bel(self) -> string

fn value(self) -> float64

fn re­port(met­rics: Slice) {

for m in met­rics {

fmt. Println(m.label(), m.value())

fn max(met­rics: Slice) -> T {

met­rics.fold(met­rics[0], |a, b|

if a.value() > b.value() { a } else { b }

Chaining and lamb­das

fn serv­er_url() -> string {

let scheme = os. LookupEnv(“HTTPS”)

.filter(|s| s == “1”)

.map(|_| “https”)

.unwrap_or(“http”)

let host = os.Looku­pEnv(“HOST”)

.map(|s| strings.Trim­Space(s))

.filter(|s| s.length() > 0)

.unwrap_or(“localhost”)

let port = os.Looku­pEnv(“PORT”)

.unwrap_or(“8080”)

scheme + ”://” + host + ”:” + port

Expression ori­ented

fn de­scribe(score: int) -> string {

let grade = if score >= 90 {

“A”

} else if score >= 70 {

“B”

} else {

“C”

let stars = {

let count = score / 20

strings. Repeat(“*”, count)

f”{grade} {stars}”

if let & let else

if let & let else

type Headers = Map

fn han­dle_­head­ers(h: Headers) -> Result {

if let Some(token) = h.get(“Au­tho­riza­tion”) {

let user = au­then­ti­cate(to­ken)?

au­tho­rize(user)?

} else {

re­turn Err(“missing cre­den­tials”)

let Some(id) = h.get(“X-Re­quest-ID”) else {

re­turn Err(“missing re­quest ID”)

process(id)

Interfaces & gener­ics

in­ter­face Metric {

fn la­bel(self) -> string

fn value(self) -> float64

fn re­port(met­rics: Slice) {

for m in met­rics {

fmt. Println(m.label(), m.value())

fn max(met­rics: Slice) -> T {

met­rics.fold(met­rics[0], |a, b|

if a.value() > b.value() { a } else { b }

Chaining and lamb­das

fn serv­er_url() -> string {

let scheme = os. LookupEnv(“HTTPS”)

.filter(|s| s == “1”)

.map(|_| “https”)

.unwrap_or(“http”)

let host = os.Looku­pEnv(“HOST”)

.map(|s| strings.Trim­Space(s))

.filter(|s| s.length() > 0)

.unwrap_or(“localhost”)

let port = os.Looku­pEnv(“PORT”)

.unwrap_or(“8080”)

scheme + ”://” + host + ”:” + port

Expression ori­ented

fn de­scribe(score: int) -> string {

let grade = if score >= 90 {

“A”

} else if score >= 70 {

“B”

} else {

“C”

let stars = {

let count = score / 20

strings. Repeat(“*”, count)

f”{grade} {stars}”

🔴 match is not ex­haus­tive

╭─[example.lis:4:3]

2 │ enum Severity { Low, High, Critical }

3 │ fn should_alert(s: Severity) -> bool {

4 │ match s {

· ╰── not all pat­terns cov­ered

What Can Be Done

You may have heard about 25 Gbit sym­met­ri­cal in­ter­net in Switzerland. This is of­ten cited as the fastest ded­i­cated (non-shared) res­i­den­tial con­nec­tion in the world. However, did you ever won­der why Switzerland has such fast in­ter­net at a rea­son­able price while the United States and other coun­tries like Switzerland’s neigh­bor Germany are falling be­hind?

What is the fun­da­men­tal dif­fer­ence be­tween the coun­tries that leads to such a stark dif­fer­ence in in­ter­net speeds and prices?

Free mar­kets, reg­u­la­tion, tech­nol­ogy, or all three?

Let’s take a closer look at the sit­u­a­tion in Switzerland, Germany, and the United States.

This ar­ti­cle is writ­ten by me and spell checked with AI. Many of the im­ages are gen­er­ated by AI and are mostly to break up the wall of text.

This Article is also avail­able as a video (My first):

As men­tioned, in Switzerland, you can get 25 Gigabit per sec­ond fiber in­ter­net to your home, sym­met­ric and ded­i­cated. If you don’t need such ex­treme speed, you can get 1 or 10 Gigabit from mul­ti­ple com­pet­ing providers for very lit­tle money. All over a con­nec­tion that is­n’t shared with your neigh­bors. In fact, some­one could of­fer 100 Gigabit or more to­day; there is noth­ing pre­vent­ing this other than the cost of end­point equip­ment.

In the United States, if you’re lucky enough to have fiber, you might get 1 Gigabit. But of­ten it’s shared with your neigh­bors. And you usu­ally have ex­actly one choice of provider. Maybe two, if you count the ca­ble com­pany that of­fers slower speeds for the same price.

In Germany, you are in a some­what sim­i­lar sit­u­a­tion to the United States. Fiber ser­vice is lim­ited to one provider and is of­ten shared with your neigh­bors.

The United States prides it­self on free mar­kets. On com­pe­ti­tion. On let­ting busi­nesses fight it out. A dereg­u­lated mar­ket with no brakes.

Germany, on the other hand, is fa­mous for over-reg­u­la­tion, mak­ing it dif­fi­cult for busi­nesses to op­er­ate, yet it is in a sim­i­lar sit­u­a­tion to the United States.

Switzerland has a highly reg­u­lated tele­com sec­tor with strong over­sight and gov­ern­ment-backed in­fra­struc­ture pro­jects, but reg­u­la­tions in Switzerland dif­fer from those in Germany.

So why is the coun­try that wor­ships free mar­kets pro­duc­ing stag­na­tion, mo­nop­o­lies, and in­fe­rior in­ter­net, while the coun­try with heavy reg­u­la­tion is pro­duc­ing hy­per-com­pe­ti­tion, world-lead­ing speeds, and con­sumer choice?

And at the same time, the coun­try with the most reg­u­la­tion is suf­fer­ing the same prob­lems as the coun­try with the least.

The an­swer re­veals a fun­da­men­tal truth about cap­i­tal­ism and reg­u­la­tion that most peo­ple get wrong.

To un­der­stand the fail­ure, you have to un­der­stand what econ­o­mists call a “natural mo­nop­oly.”

A nat­ural mo­nop­oly is an in­dus­try where the cost of build­ing the in­fra­struc­ture is so high, and the cost of serv­ing an ad­di­tional cus­tomer is so low, that com­pe­ti­tion ac­tu­ally de­stroys value.

Think about wa­ter pipes. It would be in­sane to have three dif­fer­ent wa­ter com­pa­nies each dig­ging up your street to lay their own pipes. You’d have three times the con­struc­tion, three times the dis­rup­tion, three times the cost. And at the end of it, you’d still only use one of them.

The ra­tio­nal so­lu­tion is to build the in­fra­struc­ture once, as a shared, neu­tral as­set, and let dif­fer­ent com­pa­nies com­pete to pro­vide the ser­vice over that in­fra­struc­ture.

That’s how wa­ter works. That’s how elec­tric­ity works in most places. And in Switzerland, that’s how fiber op­tic in­ter­net works.

But in the United States and Germany, they did the op­po­site.

In Germany, the “free mar­ket” ap­proach meant let­ting any com­pany dig up the street to lay their own fiber. The re­sult is called “overbuild.” Multiple net­works run­ning in par­al­lel trenches, of­ten just me­ters apart.

Billions of eu­ros spent on re­dun­dant con­crete and as­phalt. Money that could have been spent on faster equip­ment, lower prices, or con­nect­ing rural ar­eas, in­stead wasted on dig­ging the same hole twice, lit­er­ally.

But is­n’t Germany heav­ily reg­u­lated? Yes, but the reg­u­la­tions fo­cus heav­ily on in­fra­struc­ture com­pe­ti­tion rather than duct shar­ing en­force­ment.

Germany cham­pi­ons in­fra­struc­ture com­pe­ti­tion, mean­ing it prefers mul­ti­ple com­pa­nies lay­ing their own ca­bles rather than shar­ing a sin­gle net­work. At the same time, the reg­u­la­tory sys­tem wastes enor­mous amounts of time on wait­ing for dig­ging per­mits and on court­room bat­tles just to ob­tain ba­sic in­for­ma­tion about ex­ist­ing ducts.

Germany also has a large in­cum­bent, Deutsche Telekom, which uses ex­ist­ing reg­u­la­tions to its com­pet­i­tive ad­van­tage against smaller ISPs. While Germany does have laws re­quir­ing Deutsche Telekom to share its ducts with com­peti­tors, in prac­tice smaller ISPs face un­rea­son­able hur­dles such as high fees, pro­ce­dural de­lays, and le­gal dou­ble bur­dens that un­der­mine ef­fec­tive ac­cess.

Sharing ducts is not as bad as dig­ging two trenches but it is still a waste of re­sources.

The United States took a dif­fer­ent path, but the re­sult is equally bad. Instead of over­build, they got ter­ri­to­r­ial mo­nop­o­lies, in some places paid for by the fed­eral gov­ern­ment.

In most American cities, you don’t have a choice of fiber providers. You have what­ever in­cum­bent hap­pens to serve your neigh­bor­hood. Comcast has one area. Spectrum has an­other. AT&T has a third.

This is mar­keted as com­pe­ti­tion. But it’s not. It’s a car­tel. Each com­pany gets its own pro­tected ter­ri­tory, and con­sumers get no choice. If you don’t like your provider, your only al­ter­na­tive is of­ten DSL from the 1990s or a cel­lu­lar hotspot.

This is what hap­pens when you let nat­ural mo­nop­o­lies op­er­ate with­out over­sight. They don’t com­pete on price or qual­ity. They ex­tract rent.

And be­cause these net­works are built on the cheap us­ing P2MP, or shared ar­chi­tec­ture, your “gigabit” con­nec­tion is shared with your en­tire neigh­bor­hood. At 8 PM, when every­one streams Netflix, that gi­ga­bit be­comes 200 megabits. Or 100. Or less.

The provider still charges you for “gigabit.” They just don’t tell you that you’re shar­ing it with 31 other house­holds.

And it gets worse. In the United States, even if a com­peti­tor wanted to chal­lenge the in­cum­bent, they of­ten can’t. Because the Point of Presence, the cen­tral hub where all the fiber lines from homes con­verge, is pri­vate. It be­longs to Comcast or AT&T. Your fiber ter­mi­nates in their build­ing. A com­peti­tor can’t just in­stall equip­ment there. They would have to build their own net­work from scratch, dig­ging up the same streets, to reach you.

Now look at Switzerland. Here, the phys­i­cal in­fra­struc­ture, the fiber in the ground, is treated as a neu­tral, shared as­set. It’s built once, of­ten by a pub­lic or semi-pub­lic en­tity.

Every home gets a ded­i­cated 4-strand fiber line. Point-to-Point. Not shared. Not split 32 ways.

That ded­i­cated fiber ter­mi­nates in a neu­tral, open hub. And any in­ter­net ser­vice provider can con­nect to that hub.

Init7, Swisscom, Salt, or a tiny lo­cal ISP, they all have equal ac­cess to the phys­i­cal line that goes into your home.

This means you, the con­sumer, have gen­uine choice. When you sign up with a provider, you sim­ply give them your OTO (Optical Termination Outlet) num­ber, the unique iden­ti­fier printed on the fiber op­tic plate in your home. It tells the provider ex­actly which fiber con­nec­tion is yours. That’s it. No tech­ni­cian needs to visit. No one needs to dig up your street. You just call, give them the num­ber, and within days (not al­ways the case…), your new ser­vice is ac­tive.

And be­cause your home has four sep­a­rate fiber strands, you’re not locked into a sin­gle provider. You can have Init7 on one strand, Swisscom on an­other, and a lo­cal util­ity on a third. You can switch providers with a phone call. You can try a new provider with­out can­cel­ing your old one first. The com­pe­ti­tion hap­pens on price, speed, and cus­tomer ser­vice but not on who hap­pens to own the ca­ble in front of your house.

In Switzerland, you can get 25 Gigabit per sec­ond fiber to your home. Today. Symmetric. Dedicated. Not shared with your neigh­bors.

In Switzerland, you have a choice of a dozen or more providers in most cities. Prices are com­pet­i­tive. Customer ser­vice mat­ters be­cause you can leave at any time.

In the United States, the ma­jor­ity of house­holds have only one choice for high-speed in­ter­net. Speeds are lower. Prices are higher. And the tech­nol­ogy is of­ten a decade be­hind.

The “free mar­ket” promised in­no­va­tion. It de­liv­ered rent-seek­ing. The in­cum­bents have no in­cen­tive to up­grade be­cause you have nowhere else to go.

American broad­band prices have risen faster than in­fla­tion for decades. Speeds have in­creased only when a com­peti­tor, usu­ally a mu­nic­i­pal util­ity, forces the in­cum­bent to re­spond.

Without com­pe­ti­tion, there is no in­no­va­tion. There is only profit ex­trac­tion.

But here’s the cru­cial part. Switzerland did­n’t ar­rive at this model by ac­ci­dent. It did­n’t hap­pen be­cause tele­com com­pa­nies were feel­ing gen­er­ous. It hap­pened be­cause reg­u­la­tors forced it to hap­pen.

Back in 2008, when the in­dus­try sat down at the Round Table or­ga­nized by the Federal Communications Commission, it was Swisscom, the in­cum­bent it­self, that pushed for the four-fiber Point-to-Point model. The com­pany ar­gued that a sin­gle fiber would cre­ate a mo­nop­oly and that reg­u­la­tion would be nec­es­sary.

So the stan­dard was set. Four fibers per home. Point-to-Point. Open ac­cess for com­peti­tors on Layer 1 - the phys­i­cal fiber it­self.

Then, in 2020, Swisscom changed course. The com­pany an­nounced a new net­work ex­pan­sion strat­egy, this time us­ing P2MP, the shared model with split­ters. On pa­per, they ar­gued it was cheaper and faster to de­ploy.

But the ef­fect was clear. Under the P2MP de­sign, com­peti­tors would no longer have di­rect ac­cess to the phys­i­cal fiber. Instead of plug­ging into their own ded­i­cated fiber strand, they would have to rent ac­cess from Swisscom at a higher net­work layer - ef­fec­tively be­com­ing re­sellers of Swisscom’s in­fra­struc­ture. The open, com­pet­i­tive ma­trix that had been care­fully built over years would dis­ap­pear.

The small ISP Init7 filed a com­plaint with Switzerland’s com­pe­ti­tion au­thor­ity, COMCO, which later opened an in­ves­ti­ga­tion. In December 2020, they is­sued a pre­cau­tion­ary mea­sure: Swisscom could not con­tinue its P2MP roll­out un­less it guar­an­teed the same Layer 1 ac­cess that the orig­i­nal stan­dard pro­vided.

Swisscom fought this all the way to the Federal Court. They lost. In 2021, the Federal Administrative Court con­firmed COMCO’s mea­sures, stat­ing that Swisscom had failed to demon­strate “sufficient tech­no­log­i­cal or eco­nomic grounds” to de­vi­ate from the es­tab­lished fiber stan­dard. In April 2024, COMCO fi­nal­ized its rul­ing, fin­ing Swisscom 18 mil­lion francs for vi­o­lat­ing an­titrust law.

Swisscom is 51% owned by the Swiss Confederation. So, in sim­ple terms, 51% state-owned and 49% pri­vately/​in­sti­tu­tion­ally owned. Whether this makes the fine “symbolic” is a mat­ter of opin­ion.

The re­sult? Swisscom was forced to re­turn to the four-fiber, Point-to-Point ar­chi­tec­ture it had orig­i­nally cham­pi­oned. Competitors re­tained their di­rect, phys­i­cal ac­cess to the fiber net­work. The walled gar­den was pre­vented.

Whether in­tended or not, the ef­fect of Swisscom’s P2MP shift was clear: com­peti­tors would have been locked out of the phys­i­cal in­fra­struc­ture.

Swisscom is a bit of a walk­ing con­tra­dic­tion. Being ma­jor­ity state-owned, it’s sup­posed to be a pub­lic ser­vice. But it’s also a pri­vate com­pany, and max­i­miz­ing profit ben­e­fits the state cof­fers. But that is some­thing for an­other blog post.

This is the para­dox that con­fuses so many peo­ple.

The American and German ap­proach of let­ting in­cum­bents build mo­nop­o­lies, al­low­ing waste­ful over­build, and re­fus­ing to reg­u­late nat­ural mo­nop­o­lies is of­ten called a ‘free mar­ket.’

But it’s not free. And it’s not a mar­ket.

True cap­i­tal­ism re­quires com­pe­ti­tion. But in­fra­struc­ture is a nat­ural mo­nop­oly. If you treat it like a reg­u­lar con­sumer prod­uct, you don’t get com­pe­ti­tion. You get waste, or you get a mo­nop­oly.

The Swiss model un­der­stands this. They built the in­fra­struc­ture once, as a shared, neu­tral as­set, and then let the mar­ket com­pete on the ser­vices that run over it.

That’s not anti-cap­i­tal­ist. It’s ac­tu­ally bet­ter cap­i­tal­ism. It di­rects com­pe­ti­tion to where it adds value, not to where it de­stroys it.

The free mar­ket does­n’t mean let­ting pow­er­ful in­cum­bents do what­ever they want. It means cre­at­ing the con­di­tions where gen­uine com­pe­ti­tion can thrive.

What Can Be Done

So what can other coun­tries learn from Switzerland? Here are the key pol­icy changes that would help:

Mandate open ac­cess to phys­i­cal in­fra­struc­ture - re­quire in­cum­bents to share fiber ducts and dark fiber with com­peti­tors at cost-based prices. This is not “socialism” - it is how elec­tric­ity and wa­ter work. Enforce Point-to-Point ar­chi­tec­ture - re­quire that every home gets ded­i­cated fiber strands, not shared split­ters. This en­sures com­peti­tors can ac­cess the phys­i­cal layer, not just re­sell band­width.Cre­ate a neu­tral fiber stan­dard - es­tab­lish na­tional stan­dards that re­quire multi-fiber de­ploy­ment to every home, as Switzerland did in 2008.Empower com­pe­ti­tion au­thor­i­ties - give reg­u­la­tors like COMCO real teeth to en­force these rules. Fines must be large enough to mat­ter.Sup­port mu­nic­i­pal fiber - al­low cities and towns to build their own fiber net­works when in­cum­bents fail to serve res­i­dents ad­e­quately.

If you care about faster in­ter­net and lower prices, push your rep­re­sen­ta­tives to sup­port these poli­cies. The tech­nol­ogy ex­ists. The money ex­ists. What is miss­ing is the po­lit­i­cal will to de­mand real com­pe­ti­tion.

LÖVE is an awe­some frame­work you can use to make 2D games in Lua. It’s free, open-source, and works on Windows, ma­cOS, Linux, Android, and iOS.

We use our wiki for doc­u­men­ta­tion. If you need fur­ther help, feel free to ask on our fo­rums, our Discord server, or our sub­red­dit.

We use the ‘main’ branch for de­vel­op­ment of the next ma­jor re­lease, and there­fore it should not be con­sid­ered sta­ble.

There are also branches for cur­rently re­leased ma­jor ver­sions, which may have fixes and changes meant for up­com­ing patch re­leases within that ma­jor ver­sion.

We tag all our re­leases (since we started us­ing mer­cu­r­ial and git), and have bi­nary down­loads avail­able for them.

Experimental changes are some­times de­vel­oped in a sep­a­rate love-ex­per­i­ments repos­i­tory.

Files for re­leases are in the re­leases sec­tion on GitHub. The site has links to files and ad­di­tional plat­form con­tent for the lat­est re­lease.

There are also un­sta­ble/​nightly builds:

* Builds for some plat­forms are au­to­mat­i­cally cre­ated af­ter each com­mit and are avail­able through GitHub’s CI in­ter­faces.

* For ubuntu linux they are in ppa:bartbes/​love-un­sta­ble

* For arch linux there’s love-git in the AUR.

The test suite in test­ing/ cov­ers all the LÖVE APIs, and tests them the same way de­vel­op­ers use them. You can view cur­rent test cov­er­age from any ac­tion.

You can run the suite lo­cally like you would run a nor­mal LÖVE pro­ject, e.g.:

love test­ing

See the readme in the test­ing folder for more info.

The best places to con­tribute are through the is­sue tracker and the of­fi­cial Discord server or IRC chan­nel.

For code con­tri­bu­tions, pull re­quests and patches are wel­come. Be sure to read the source code style guide. Changes and new fea­tures typ­i­cally get dis­cussed in the is­sue tracker or on Discord or the fo­rums be­fore a pull re­quest is made.

Follow the in­struc­tions at the mega­source repos­i­tory page.

Because in-tree builds are not al­lowed, the Makefiles needs to be gen­er­ated in a sep­a­rate build di­rec­tory. In this ex­am­ple, folder named build is used:

Download or clone this repos­i­tory and copy, move, or sym­link the ma­cOS/​Frame­works sub­folder into love’s plat­form/​xcode/​ma­cosx folder and the shared sub­folder into love’s plat­form/​xcode folder.

Then use the Xcode pro­ject found at plat­form/​xcode/​love.xcode­proj to build the love-ma­cosx tar­get.

Download the love-ap­ple-de­pen­den­cies zip file cor­re­spond­ing to the LÖVE ver­sion be­ing used from the Releases page, un­zip it, and place the iOS/​li­braries sub­folder into love’s plat­form/​xcode/​ios folder and the shared sub­folder into love’s plat­form/​xcode folder.

Or, down­load or clone this repos­i­tory and copy, move, or sym­link the iOS/​li­braries sub­folder into love’s plat­form/​xcode/​ios folder and the shared sub­folder into love’s plat­form/​xcode folder.

Then use the Xcode pro­ject found at plat­form/​xcode/​love.xcode­proj to build the love-ios tar­get.

See readme-iOS.rtf for more in­for­ma­tion.

A few years ago I was in a meet­ing with de­vel­op­ers and some­one asked a sim­ple ques­tion: “What’s the right frame­work for a new Windows desk­top app?”

Dead si­lence. One per­son sug­gested WPF. Another said WinUI 3. A third asked if they should just use Electron. The meet­ing went side­ways and we never did an­swer the ques­tion.

That si­lence is the story. And the story goes back thirty-plus years.

When a plat­form can’t an­swer “how should I build a UI?” in un­der ten sec­onds, it has failed its de­vel­op­ers. Full stop.

In 1988, Charles Petzold pub­lished Programming Windows. 852 pages. Win16 API in C. And for all its bulk, it rep­re­sented some­thing re­mark­able: a sin­gle, co­her­ent, au­thor­i­ta­tive an­swer to how you write a Windows ap­pli­ca­tion. In the busi­ness, we call that a ‘strategy’.

Win32 that fol­lowed was big­ger but still co­her­ent. Message loops. Window pro­ce­dures. GDI. The men­tal model was a bit whacky, but it was one men­tal model. Petzold ex­plained it. It was the F=MA of Windows. Simple. Powerful. You learned it. You used it. You were suc­cess­ful.

Clarity is your friend! One OS, one API, one lan­guage, one book. There was no com­mit­tee de­bat­ing man­aged-code al­ter­na­tives. There was just Win32 and Petzold, and it worked. This was Physics not Chemistry (this works but only for this slice of the pe­riod table. And only un­der these pres­sures.  And only within this tem­per­a­ture. And only if the Moon is in the 7th house of Jupiter).

What hap­pened next is a mas­ter­class in how a com­pany with bril­liant peo­ple and enor­mous re­sources can pro­duce a thirty-year boof-a-rama by op­ti­miz­ing for the wrong things.  AKA Brillant peo­ple do­ing stu­pid things.

Win32 had real lim­i­ta­tions, so Microsoft did what Microsoft does: it shipped some­thing new for the de­vel­oper con­fer­ence. Several some­things.

MFC (1992) wrapped Win32 in C++. If Win32 was in­el­e­gant, MFC was Win32 wear­ing a tuxedo made of other tuxe­dos. Then came OLE. COM. ActiveX. None of these were re­ally GUI frame­works — they were com­po­nent ar­chi­tec­tures — but they in­fected every cor­ner of Windows de­vel­op­ment and in­tro­duced a level of cog­ni­tive com­plex­ity that makes Kierkegaard read like Hemingway.

I sat through a con­fer­ence ses­sion in the late nineties try­ing to un­der­stand the dif­fer­ence be­tween an OLE doc­u­ment, a COM ob­ject, and an ActiveX con­trol. I looked at the pre­sen­ter like they had a rat’s tail hang­ing out of his mouth for the en­tire hour.

Microsoft was­n’t sell­ing a co­her­ent story. It was sell­ing tech­nol­ogy prim­i­tives and telling de­vel­op­ers to fig­ure out the story them­selves. That’s the Conference Keynote Cluster***k — Microsoft op­ti­mized for an ex­ec­u­tive im­press­ing peo­ple with their keynote and not the suc­cess of the users or de­vel­op­ers.

At PDC 2003, Microsoft un­veiled Longhorn — gen­uinely one of the most com­pelling tech­ni­cal vi­sions the com­pany had ever put in front of de­vel­op­ers. Three pil­lars: WinFS (a re­la­tional file sys­tem), Indigo (unified com­mu­ni­ca­tions), and Avalon — later WPF — a GPU-accelerated, vec­tor-based UI sub­sys­tem dri­ven by a de­clar­a­tive XML lan­guage called XAML. Developers saw the Avalon demos and went nuts. It was the right vi­sion.

It was also, in the words of Jim Allchin’s in­ter­nal memo from January 2004, “a pig.”

By August 2004, Microsoft an­nounced a com­plete de­vel­op­ment re­set. Scrapped. Start over from the Server 2003 code­base. And af­ter the re­set, lead­er­ship is­sued a quiet di­rec­tive: no f***ing man­aged code in Windows. All new code in C++. WPF would ship along­side Vista, but the shell it­self would not use it.

The Windows team’s bit­ter­ness to­ward .NET never healed. From their per­spec­tive, gam­bling on a new man­aged-code frame­work had pro­duced the most em­bar­rass­ing fail­ure in the com­pa­ny’s his­tory. That bit­ter­ness cre­ated a thir­teen-year in­sti­tu­tional civil war be­tween the Windows team and the .NET team that would ul­ti­mately or­phan WPF, kill Silverlight, doom UWP, and give us the GUI ecosys­tem boof-a-rama we have to­day.

WPF shipped in late 2006. It was re­mark­able — XAML, hard­ware-ac­cel­er­ated ren­der­ing, real data bind­ing. If Microsoft had made it the de­fin­i­tive an­swer and in­vested re­lent­lessly, the story might have ended dif­fer­ently. Instead, in 2007, they launched Silverlight: a stripped-down browser plu­gin to com­pete with Flash, cross-plat­form, el­e­gant, and the foun­da­tion for Windows Phone. Around 2010 it looked like the rich client fu­ture.

Then at MIX 2010, a Microsoft ex­ec­u­tive said in a Q&A that Silverlight was not a cross-plat­form strat­egy — it was about Windows Phone. HTML5 was now pol­icy. The Silverlight team was not told this was com­ing. Developers who had bet their LOB ap­pli­ca­tions on Silverlight found out from a con­fer­ence Q&A.

Silverlight was­n’t killed by tech­ni­cal fail­ure. The tech­nol­ogy was fine. It was killed by a busi­ness strat­egy de­ci­sion, and de­vel­op­ers were the last to know.

Remember that pat­tern. We’ll see it again.

Apple had sold 200 mil­lion iPhones. The iPad was eat­ing into PC sales. Microsoft’s an­swer was Windows 8 and Metro — a touch-first run­time called WinRT that was de­lib­er­ately not built on .NET. Remember the Windows team’s bit­ter­ness? Here it man­i­fests. WinRT was a na­tive C++ run­time. Clean break from WPF, WinForms, and a decade of de­vel­oper in­vest­ment in .NET.

There were ac­tu­ally two sto­ries be­ing told si­mul­ta­ne­ously in­side Microsoft. The Windows team was build­ing WinRT. The .NET team was still evan­ge­liz­ing WPF. Different build­ings, dif­fer­ent VPs, dif­fer­ent road maps.

What de­vel­op­ers heard at //Build 2012: the fu­ture is WinRT, and also HTML+JS is first-class, and also .NET still works, and also C++ is back, and also you should write Metro apps, and also your WPF code still runs fine. That is not a strat­egy. That is a Hunger Games stage where six teams are fight­ing for your at­ten­tion.

Enterprise de­vel­op­ers took one look at UWP’s sand­box­ing, its Store de­ploy­ment re­quire­ment, and its miss­ing Win32 APIs, and walked away. The frame­work de­signed to win them into the mod­ern era had been op­ti­mized for a tablet app store that never ma­te­ri­al­ized.

Windows 10 brought Universal Windows Platform — write once, run on PC, phone, Xbox, HoloLens. Compelling on pa­per. The prob­lem: Windows Phone was dy­ing, and Microsoft’s own flag­ship apps — Office, Visual Studio, the shell it­self — weren’t us­ing UWP. The mes­sage was clear even if no one said it out loud.

When UWP stalled, the of­fi­cial an­swer be­came it de­pends. Use UWP for new apps, keep WPF for ex­ist­ing ones, add mod­ern APIs via XAML Islands, wait for WinUI 3, but also WinUI 2 ex­ists for UWP specif­i­cally, and Project Reunion will fix every­thing, ex­cept we’re re­nam­ing it Windows App SDK and it still does­n’t fully re­place UWP and…

Project Reunion / WinUI 3 rep­re­sents gen­uine progress. But ask your­self why the prob­lem ex­isted at all. UWP’s con­trols were tied to the OS be­cause the Windows team owned them. The .NET team did­n’t. The de­vel­oper tools team did­n’t. Project Reunion was an or­ga­ni­za­tional workaround dressed up as a tech­ni­cal so­lu­tion.

One de­vel­op­er’s sum­mary, writ­ten in 2024: “I’ve been fol­low­ing Microsoft’s con­stant changes: UAP, UWP, C++/CX re­placed by C++/WinRT with­out tool sup­port, XAML Islands, XAML Direct, Project Reunion, the restart of WinAppSDK, the chaotic switch be­tween WinUI 2.0 and 3.0…” Fourteen years. Fourteen piv­ots. That per­son de­serves a medal and an apol­ogy, in that or­der.

Here is every GUI tech­nol­ogy ac­tu­ally ship­ping on Windows to­day:

* Win32 (1985) — Still here. Still used. Petzold’s book still ap­plies.

* MFC (1992) — C++ wrap­per on Win32. Maintenance mode. Lives in en­ter­prise and CAD.

* WinForms (2002) — .NET wrap­per on Win32. “Available but dis­cour­aged.” Still fastest for data-en­try forms.

* Electron — Chromium + Node.js. VS Code, Slack, Discord. The most widely de­ployed desk­top GUI tech­nol­ogy on Windows right now — and Microsoft had noth­ing to do with it.

* Avalonia — Open source WPF spir­i­tual suc­ces­sor. Used by JetBrains, GitHub, Unity — de­vel­op­ers who stopped wait­ing for Microsoft.

* Uno Platform — WinUI APIs on every plat­form. More com­mit­ted to WinUI than Microsoft is.

* Delphi / RAD Studio — Still alive. Still fast. Still in ver­ti­cal mar­ket soft­ware.

* Java Swing / JavaFX — Yes, still in pro­duc­tion. The en­ter­prise never for­gets.

Seventeen ap­proaches. Five pro­gram­ming lan­guages. Three ren­der­ing philoso­phies. That is not a plat­form. I might not have a dic­tio­nary de­f­i­n­i­tion for the term boof-a-rama but I know one when I see it.

Every failed GUI ini­tia­tive traces back to one of three causes: in­ter­nal team pol­i­tics (Windows vs. .NET), a de­vel­oper con­fer­ence an­nounce­ment dri­ving a pre­ma­ture plat­form bet (Metro, UWP), or a busi­ness strat­egy pivot that or­phaned de­vel­op­ers with­out warn­ing (Silverlight). None of these are tech­ni­cal fail­ures. The tech­nol­ogy was of­ten gen­uinely good — WPF was good, Silverlight was good, XAML is good. The or­ga­ni­za­tional fail­ure was the prod­uct.

You ei­ther have a Plausible Theory of Success that cov­ers the full life­cy­cle — adop­tion, in­vest­ment, main­te­nance, and mi­gra­tion — or you have a de­vel­oper con­fer­ence keynote.

One is a strat­egy. The other is a thirty-year boof-a-rama.

Charles Petzold wrote six edi­tions of Programming Windows try­ing to keep up with each new thing Microsoft an­nounced. He stopped af­ter the sixth, which cov­ered WinRT for Windows 8. That was 2012.