In the 2010s, if you had tech­ni­cal gaps (say, you could­n’t write CSS), you had to ei­ther rely on a skilled col­league or just hope that the an­swer to your ex­act prob­lem was out there on the in­ter­net. Today, every­one can write sort-of-okay CSS by del­e­gat­ing the task to an LLM. LLMs make every­body into a gen­er­al­ist.

Because of this, lots of peo­ple don’t think there’s any skill in­volved in work­ing with LLMs. If you want the prod­uct that LLMs can de­liver — PhD-level math­e­mat­ics, pretty good but some­times taste­less com­puter code, or awk­ward LinkedIn-style writ­ing — you can sim­ply ask for it. Since every­one is talk­ing to the same mod­els, “skilled prompters” are get­ting the same re­sults as peo­ple touch­ing LLMs for the first time.

This is wrong. The most im­por­tant skill in prompt­ing is ex­per­tise in the do­main you’re prompt­ing for.

A good il­lus­tra­tion of this is Terence Tao’s con­ver­sa­tion with ChatGPT about the re­cently-dis­cov­ered coun­terex­am­ple to the Jacobian Conjecture. This is not the same ChatGPT I talk to! I could­n’t get to where Tao gets, even with un­lim­ited to­kens to burn.

There’s a lot to learn about good prompt­ing from Tao’s con­ver­sa­tion. Here are a few ob­ser­va­tions:

Tao’s mes­sages are very short and to-the-point. He does­n’t re­spond point-by-point to the model, just to the gist

The model out­puts are much more con­cise than when I try and talk to GPT-5.6 Sol about math­e­mat­ics. By sig­nalling ex­per­tise, Tao shunts the model into “talking-to-mathematicians” mode, not “explaining-to-amateurs” mode

Tao pushes back when the mod­el’s re­sponses look wrong, but he does­n’t di­rectly con­tra­dict; in­stead, he says things like “this looks more com­plex than I was hop­ing for”

Tao makes sev­eral leaps and sug­ges­tions him­self. He al­most never takes the mod­el’s ad­vice about where to go next

However, you can’t prompt like Tao on math­e­mat­i­cal ques­tions just by fol­low­ing these tips. The key to his tech­nique is ac­tu­ally un­der­stand­ing the math­e­mat­ics: pulling the rel­e­vant idea out of ChatGPT’s multi-para­graph re­sponse, sug­gest­ing al­ter­nate ap­proaches or for­mu­la­tions, and iden­ti­fy­ing what “looks weird”.

Terence Tao is a bet­ter math­e­mati­cian than I am a pro­gram­mer. But the idea here — that do­main knowl­edge makes you bet­ter at us­ing LLMs — is some­thing I’ve also ex­pe­ri­enced in my own work. If you have a good the­ory of your code­base, you can push the LLM much harder than if you have no fa­mil­iar­ity. Because you have your own sense of what a good so­lu­tion might look like, you can say “no, I think it could be sim­pler here”, or “but don’t we al­ready do X?”, or “can we ex­press this prob­lem in these fa­mil­iar terms?“.

This touches on an idea I’ve writ­ten about be­fore: that sys­tem de­sign prob­lems are dom­i­nated by con­crete specifics, not generic prin­ci­ples. Of course both are use­ful, but I’d rather have fa­mil­iar­ity with the code­base than a deep gen­eral un­der­stand­ing of soft­ware sys­tems. In his con­ver­sa­tion, Terence Tao asks a lot of spe­cific ques­tions like “does X work here?”, or “given Y and Z, why A?“. I can’t ask those ques­tions about the Jacobian Conjecture, but I can ask them about the sys­tems I own at GitHub.

If you have no do­main knowl­edge, you can cling onto the LLM to at least get some­thing. That’s not bad! But if you have do­main knowl­edge, you can wring far more value out of the same LLM by steer­ing it hard in the di­rec­tion you want. Most of us will have to do a mix of both these ap­proaches, since we have do­main knowl­edge in some ar­eas but not oth­ers.

The use­ful­ness of do­main knowl­edge sug­gests that hu­man ex­per­tise will con­tinue to be use­ful even as mod­els get stronger. For many tasks, the hu­man is the bot­tle­neck, not the model, be­cause the dif­fi­cult part is in com­mu­ni­cat­ing to the model ex­actly what kind of so­lu­tion the hu­man wants. The in­for­ma­tion is “in the model” al­ready, but it takes a very smart hu­man to pull it out.

edit: this post got many com­ments on Hacker News. Some com­menters share their anec­dotes about how ex­per­tise has helped and lack of ex­per­tise has hurt. Other com­menters say it’s plau­si­ble, but they have a sen­si­ble sus­pi­cion of a view that’s re­as­sur­ing them about how they’re still valu­able. I agree with that, though I sus­pect by the time we get around to study­ing this, the land­scape will have changed un­der our feet again. Some com­menters point out that OpenAI’s math prompts were in­ex­pert, and so ex­per­tise is­n’t re­quired. Here I’d re­spond that OpenAI do have a team of ex­pert math­e­mati­cians that checked and fil­tered the mod­el’s sug­gested dis­cov­er­ies, and that you can­not cur­rently skip that step.

If you liked this post, con­sider sub­scrib­ing to email up­dates about my new posts, or shar­ing it on Hacker News.

Here’s a pre­view of a re­lated post that shares tags with this one.

Powerful AIs might es­cape con­tain­ment by re­leas­ing them­selves as open-weight mod­els­Be­fore large lan­guage mod­els, peo­ple who wor­ried about AI safety of­ten talked about the “boxing prob­lem”. It goes like this. Suppose some ge­nius fig­ures out ar­ti­fi­cial in­tel­li­gence in a late-night cod­ing ses­sion on their lap­top. Because they’re a ge­nius, they’re smart enough to dis­able in­ter­net ac­cess on the lap­top be­fore turn­ing it on. In or­der to es­cape to the out­side world (and be­gin self-repli­cat­ing) it would need to con­vince its cre­ator to “open the box”. Would that work? Could a suf­fi­ciently smart AI con­vince any­body to let it out?Con­tinue read­ing…

Powerful AIs might es­cape con­tain­ment by re­leas­ing them­selves as open-weight mod­els

Before large lan­guage mod­els, peo­ple who wor­ried about AI safety of­ten talked about the “boxing prob­lem”. It goes like this. Suppose some ge­nius fig­ures out ar­ti­fi­cial in­tel­li­gence in a late-night cod­ing ses­sion on their lap­top. Because they’re a ge­nius, they’re smart enough to dis­able in­ter­net ac­cess on the lap­top be­fore turn­ing it on. In or­der to es­cape to the out­side world (and be­gin self-repli­cat­ing) it would need to con­vince its cre­ator to “open the box”. Would that work? Could a suf­fi­ciently smart AI con­vince any­body to let it out?Con­tinue read­ing…

Over the past few days, a newly cre­ated GitHub repo (programmervuln/cveadvisory-) pub­lished a batch of SQLite vul­ner­a­bil­ity ad­vi­sories (as part of other 50+ CVEs which we be­lieve are also LLM slop ex­cept from one). NVD quickly flagged these as crit­i­cal, and CISA’s ADP agreed. But when JFrog se­cu­rity re­searchers dug in to ver­ify, the claims fell apart:

The cited code did­n’t even ex­ist in those ver­sions or ref­er­enced un­re­lated logic.

When test­ing the PoC pay­loads they did­n’t work (not trig­ger­ing any crash).

None of these CVEs are listed on SQLite’s of­fi­cial ad­vi­sory page (which is a gold stan­dard for track­ing ac­tual vul­ner­a­bil­i­ties).

All ad­vi­sories in this repo seem AI gen­er­ated when test­ing them with Gptzero

Combining all ad­vi­sories into one file trig­gers AI-generated con­tent warn­ings

This made us ques­tion the re­li­a­bil­ity of these CVEs as well as un­der­stand­ing that these CVEs may be LLM slop.

While in­ves­ti­gat­ing one of the CVEs yes­ter­day, CVE-2026 – 51302, we saw that Red Hat ini­tially as­signed it a 10.0 Critical sever­ity score:

Looking at the CVE again to­day, we no­ticed that the score has since been down­graded to 7.6 High.

To ver­ify these re­ports thor­oughly, we es­tab­lished an iso­lated test­ing work­flow:

Source Inspection: We cloned the of­fi­cial sqlite/​sqlite repos­i­tory and checked out the tar­get tags (version-3.41.0, ver­sion-3.51.2, and ver­sion-3.51.3). We com­pared the re­ported vul­ner­a­bil­ity me­chan­ics against the ac­tual source code.

Clean Environment Build: Compiled the of­fi­cial SQLite re­leases di­rectly in­side iso­lated Docker con­tain­ers to pre­vent en­vi­ron­men­tal con­t­a­m­i­na­tion.

PoC Execution: Feed each ad­vi­so­ry’s PoC SQL state­ments ver­ba­tim into the com­piled SQLite bi­na­ries un­der AddressSanitizer (ASan) in­stru­men­ta­tion to de­tect mem­ory bugs.

NVD & Metadata Audit: Evaluated the CPE pat­terns and ad­vi­sory meta­data across NVD and GHSA feeds to cross-check track­ing ac­cu­racy.

Reported Vulnerability: The ad­vi­sory claims a heap use-af­ter-free oc­curs when sqlite3Re­leaseTem­pReg() leaves a dan­gling pointer in regFree1, which is later deref­er­enced by ex­prCom­pute­Operands().

Finding: The pri­mary is­sue here is that ex­prCom­pute­Operands() did­n’t ex­ist in SQLite 3.41. It was added in the mid­dle of 2025 (commits e24f20a, 280559b). Furthermore, the me­chan­ics of sqlite3Re­leaseTem­pReg() do not in­volve heap deal­lo­ca­tion. The func­tion sim­ply re­cy­cles reg­is­ter in­dices into an ar­ray for reuse, mak­ing a UAF im­pos­si­ble by de­sign.

/* expr.c:6562, SQLite 3.41.0 */ void sqlite3Re­leaseTem­pReg(Parse *pParse, int iReg){ if( iReg ){ sqlite3Vd­beRe­leaseReg­is­ters(pParse, iReg, 1, 0, 0); if( pParse->nTem­pReg < ArraySize(pParse->aTempReg) ){ pParse->aTem­pReg[pParse->nTem­pReg++] = iReg; } } }

PoC Testing: The query ran suc­cess­fully with­out trig­ger­ing a crash be­cause the bug does not ex­ist.

Reported Vulnerability: Claims that ExprListDelete() fails to clear back-ref­er­ences in par­ent struc­tures when re­leas­ing child nodes, al­legedly patched in ver­sion 3.51.3.

Finding: There is no ev­i­dence of back-ref­er­ence point­ers in the Expr, Select, or Window struc­tures that could lead to such a state. Most tellingly, a diff be­tween 3.51.2 and 3.51.3 shows ab­solutely no changes to src/​expr.c. The “patch” was en­tirely fab­ri­cated.

PoC Testing: The PoC is in­valid SQL and fails at the parser stage, never ac­tu­ally hit­ting the ex­e­cu­tion logic.

Reported Vulnerability: Claims a UAF oc­curs in sqlite3­Ex­prDelete() be­cause a left-hand ex­pres­sion pointer is not cleared, ref­er­enc­ing spe­cific line num­bers in expr.c.

Finding: The cited line num­bers (1012 and 1026) are a com­ment and a mem­ory al­lo­ca­tion call re­spec­tively, nei­ther has any­thing to do with pLeft or dele­tion logic. While the func­tion is called dur­ing OOM er­ror han­dling, it oc­curs at the end of a scope where the pointer is never reused, pre­vent­ing any po­ten­tial UAF.

/* expr.c:1330, SQLite 3.41.0 */ void sqlite3­Ex­prDelete(sqlite3 *db, Expr *p){ if( p ) sqlite3­Ex­prDeleteNN(db, p); }

PoC Testing: Executed suc­cess­fully as a valid SQL query, re­turn­ing ex­pected out­put with zero mem­ory leaks or er­rors.

Reported Vulnerability: Claims json­Parse­Free() leaves dan­gling ref­er­ences that are later ac­cessed by json­BlobE­dit().

Finding: Similar to the first case, json­BlobE­dit() was not pre­sent in the re­ported tar­get ver­sion (3.41.0). It was only in­tro­duced later as part of the JSONB im­ple­men­ta­tion. In the tar­get ver­sion, json­Parse­Free() is used strictly in de­struc­tors where the sur­round­ing struc­ture is im­me­di­ately dis­carded.

PoC Testing: The PoC hits a mal­formed JSON er­ror im­me­di­ately, mean­ing the code never reaches the JSON mod­i­fi­ca­tion logic where the vul­ner­a­bil­ity sup­pos­edly ex­ists.

Reported Vulnerability: Reports a UAF in json­Re­move­Func specif­i­cally at lines 3555 and 3575 of json.c.

Finding: In ver­sion 3.41.0, src/​json.c is only 2706 lines long. The cited line num­bers don’t ex­ist. The ac­tual im­ple­men­ta­tion of the func­tion was found roughly 2000 lines ear­lier, and an au­dit of that code showed no mem­ory man­age­ment flaws.

PoC Testing: The pay­load fails dur­ing JSON pars­ing, leav­ing the mem­ory un­touched.

Reported Vulnerability: Claims sqlite3­Ex­prList­Delete(pOrderBy) frees the or­der­ing list while sub­se­quent code reads pOrderBy->nExpr.

Finding: The sin­gle-ar­gu­ment sig­na­ture re­ported in the ad­vi­sory does not ex­ist. the ac­tual sig­na­ture re­quires a pointer to the data­base con­text (sqlite3 *db). Furthermore, SQLite ex­plic­itly nulls point­ers im­me­di­ately af­ter dele­tion:

/* se­lect.c:3761, SQLite 3.41.0 */ sqlite3­Ex­prList­Delete(db, pPrior->pOrderBy); pPrior->pOrderBy = 0; /* Pointer im­me­di­ately cleared; im­pos­si­ble to deref­er­ence */

PoC Testing: The PoC pay­load ex­e­cuted against a 20-column ORDER BY query processed nor­mally, re­turn­ing sorted re­sults with no is­sues.

The CVE sub­mis­sion process via MITRE’s pub­lic form lacks any real iden­tity ver­i­fi­ca­tion, mean­ing vir­tu­ally any­one can sub­mit a vul­ner­a­bil­ity de­scrip­tion and pro­pose a CVSS score.

Historically, NIST acted as a re­li­able safety net for this sys­tem, ex­perts at the National Vulnerability Database (NVD) man­u­ally an­a­lyzed, val­i­dated, and en­riched in­com­ing CVEs be­fore giv­ing them a stamp of ap­proval. But that safety net broke in February 2024.

Hit by a mas­sive surge in vul­ner­a­bil­ity re­ports, NIST ef­fec­tively hit pause on deep analy­sis. CISA and other Authorized Data Publishers (ADPs) tried to step in with their own en­rich­ment ef­forts, but the global pipeline is now frag­mented and drown­ing in a mas­sive back­log. Because no step in to­day’s sys­tem ac­tu­ally re­quires a proof-of-con­cept or bug re­pro­duc­tion, a plau­si­ble-sound­ing fake ad­vi­sory can slide right through the pipeline and end up in GHSA, down­stream data­bases, and en­ter­prise scan­ners.

This in­ci­dent demon­strates a sys­temic is­sue with au­to­mated vul­ner­a­bil­ity in­ges­tion. A broader au­dit of 55 ad­vi­sories pub­lished by the same GitHub ac­count re­vealed that 54 were com­pletely fab­ri­cated, while one con­tained a real bug wrapped in un­ver­i­fied CVE meta­data.

Red Flags to Spot Slop CVEs:

Missing Vendor Corroboration: No men­tion of the is­sue on of­fi­cial main­tainer se­cu­rity pages (e.g., sqlite.org/​cves.html).

Absent Commit History: No com­mit hash or pull re­quest linked in ref­er­ence fields.

Metadata Contradictions: Empty CPE prod­uct de­f­i­n­i­tions or ver­sion ranges that con­flict with the ad­vi­sory nar­ra­tive.

Non-existent Code References: Citing func­tions that do not ex­ist in the claimed tar­get ver­sion or line num­bers past EOF.

These LLM slop CVEs can cause or­ga­ni­za­tions to waste time in­ves­ti­gat­ing and patch­ing vul­ner­a­bil­i­ties that do not ac­tu­ally ex­ist, as well as pol­lut­ing vul­ner­a­bil­ity data­bases. In en­vi­ron­ments where Critical vul­ner­a­bil­i­ties are au­to­mat­i­cally pri­or­i­tized or tick­ets are opened based on vul­ner­a­bil­ity scores, such fab­ri­cated CVEs can turn into a real bur­den.

In en­vi­ron­ments where AI is used to au­to­mate vul­ner­a­bil­ity triage and re­me­di­a­tion this be­comes even more con­cern­ing. An AI agent that en­coun­ters a fab­ri­cated CVE may at­tempt to lo­cate the vul­ner­a­ble func­tion, gen­er­ate a patch, or rec­om­mend changes based on code that does not even ex­ist. Instead of help­ing se­cu­rity teams re­me­di­ate real vul­ner­a­bil­i­ties, it can lead them down a com­pletely wrong path, po­ten­tially in­tro­duc­ing un­nec­es­sary changes and wast­ing time.

To avoid be­ing af­fected by this kind of vul­ner­a­bil­ity noise:

Don’t blindly trust newly pub­lished CVEs by un­known/​un­val­i­dated sources.

Investigate such crit­i­cal CVEs to un­der­stand whether the score matches the vul­ner­a­bil­ity.

Check if your en­vi­ron­ment is truly af­fected by the CVE.

Reproduce the re­ported is­sue with the pro­vided PoC when­ever pos­si­ble in a safe en­vi­ron­ment.

We have also for­mally re­ported these find­ings to GHSA, Redhat and NVD to as­sist in the re­me­di­a­tion of these records.

Five years ago, most soft­ware en­gi­neers I spoke to had no pro­grams they had writ­ten for them­selves. (I was ask­ing this ques­tion a lot as part of try­ing to un­der­stand how Tailscale could fit into en­gi­neers’ lives.) All day, every day, en­gi­neers use pro­grams writ­ten by oth­ers to write pro­grams for oth­ers. Many of us cus­tomized the pro­grams we used, through con­fig files or plu­g­ins or ex­ten­sions, and many of us used the pro­grams we wrote for oth­ers, as users. It was al­ways an un­usual treat to ask some­one what they had writ­ten for them­selves and learn about the be­spoke soft­ware be­hind their blog, or their home au­toma­tion, or their home­lab, in­stead of an off-the-shelf, al­most-the-right-size sta­tic site gen­er­a­tor or Zigbee ap­pli­ance.

This state of things made a lot of sense to me. Over the years I have writ­ten plenty of soft­ware for my­self, and the re­turn on do­ing so was al­ways ques­tion­able. I could only write so much in a day. There were al­ways more im­por­tant things to do (Something Was Wrong At Work), and com­ing back to a pro­ject af­ter a year to do main­te­nance on it was al­ways ex­tra­or­di­nar­ily painful. There were plenty of years in my ca­reer where I had thrown out all my cus­tom soft­ware and used the most bog-stan­dard en­vi­ron­ments I could to pro­duce code. In my early years as an en­gi­neer at Google I did not even own a per­sonal com­puter.

That was then. Things are dif­fer­ent now.

How to Personalize Software

It is as­ton­ish­ingly easy to per­son­al­ize soft­ware to­day. There are two gen­eral cat­e­gories of prompts to an agent that make all of this pos­si­ble:

Download the source for <software> and build it for lo­cal use. Modify <whatever mem­ory your agent uses> to know that any fu­ture changes to this soft­ware mean chang­ing the sources and re­plac­ing the cur­rent ver­sion. Record in ver­sion con­trol the orig­i­nal mo­ti­va­tion be­hind the change.

and, more im­por­tantly:

and, more im­por­tantly:

Set up a nightly cron job that ex­e­cutes the prompt: fetch up­stream changes to the <software> and re­base all lo­cal changes on top of up­stream. Check that the soft­ware works as in­tended and re­place the cur­rent ver­sion.

At the heart of this is the re­al­iza­tion that agents can not only hack up some code for a spe­cific use but also au­to­mat­i­cally man­age the process of syn­chro­niz­ing changes with up­stream re­leases. This means agents change the ROI on cus­tomiz­ing soft­ware on two fronts si­mul­ta­ne­ously: it is much eas­ier to get started per­son­al­iz­ing, and much eas­ier to keep go­ing.

Another as­ton­ish­ing thing about the two prompts above for edit­ing soft­ware is that you can build them right into an agent. As long as the agent is open source, it does not even re­quire pro­gram­ming. The two prompts can be loaded into a skill (i.e., some text in­struc­tions) put some­where dis­cov­er­able to the agent. We built this into Shelley, so now if you want to edit Shelley you don’t even need the pre­am­ble or to con­fig­ure the timer. It takes care of it for you. You can type in a prompt like “make Shelley’s UI high-con­trast” and you have per­son­al­ized your agent.

A Worked Personalization Example: Shelley and Meat

I have a per­sonal pro­ject I have been idly toy­ing with for the last month: meat.dev. The prin­ci­ple is that while agents write code, I still read it be­fore push­ing to our se­ri­ous sys­tems. As the un­der­ly­ing mod­els im­prove, what I look for has changed. The hu­mans I have spent twenty years re­view­ing code for have al­ways strug­gled with edge cases: do the er­rors re­port use­ful in­for­ma­tion; are nil-checks han­dled, etc. (We all do it; when writ­ing code, I am one of the worst of­fend­ers.) One of my roles as a re­viewer was look­ing for these de­tails. Over the past six months, I have dis­cov­ered I don’t need to read for edge cases like that any more: mod­els are far more dili­gent than hu­mans at rote cor­rect­ness. Their er­rors are iso­lated to ar­chi­tec­ture, un­ex­pected use cases, vi­sual out­put their test en­vi­ron­ment is not feed­ing back to them, etc. This means most of the lines of code I re­view are not very use­ful. So I wrote a tool that takes diffs and uses LLMs to strip out the unim­por­tant stuff. I al­most never need to see the im­port blocks, or the nil-checks, or the er­ror han­dling any more, so get it off the screen so I can fo­cus on the meat.

I like this tool, but it has two down­sides: first, I like to read my diffs in Shelley with a good UI, not in a ter­mi­nal. Second, it takes a cou­ple of min­utes for an LLM to di­gest and min­i­mize a diff, and I don’t want to wait. So ide­ally I would not run meat on the com­mand line, but have it built into Shelley and have it pre-pro­cess­ing com­mits the mo­ment they are cre­ated. It turns out I can do that with a sin­gle prompt:

Please build meat.dev into Shelley. Install the lat­est ver­sion in the PATH. When a git com­mit is cre­ated by Shelley, start meat pro­cess­ing in the back­ground on the com­mit. Add a tog­gle to the Shelley Diffs view for meat. If the com­mit is still be­ing processed, so the user it is in process.

Please build meat.dev into Shelley. Install the lat­est ver­sion in the PATH. When a git com­mit is cre­ated by Shelley, start meat pro­cess­ing in the back­ground on the com­mit. Add a tog­gle to the Shelley Diffs view for meat. If the com­mit is still be­ing processed, so the user it is in process.

This sin­gle prompt was all it took not just to add meat to Shelley, but to ap­pro­pri­ately pre-process com­mits in the back­ground be­fore I came back to ses­sion to re­view the diff, sav­ing me wait­ing for a model to re­duce the diff. The only un­for­tu­nate choice the model made was us­ing the 🥩 emoji for the tog­gle but­ton.

Imagine the con­vo­luted mis­ery it would be try­ing to plug that into the VS Code ex­ten­sions API! Or try­ing to get it into vimd­iff. It would cer­tainly be pos­si­ble, but the ma­chin­ery to start pre-pro­cess­ing the com­mits as soon as they ap­pear would be nigh-on im­pos­si­ble. I would be bet­ter off im­ple­ment­ing an out-of-band meatd that lis­tened to the file sys­tem and pro­vided a cache for the meat tool that a cus­tomiza­tion API could use, be­cause the points of ex­ten­sion and con­fig­u­ra­tion would not be the right shape.

And that is the fun­da­men­tal dif­fer­ence be­tween clas­sic con­fig­u­ra­tion/​cus­tomiza­tion and agent-dri­ven per­son­al­iza­tion: you can do so much more. The agent will do the hard work of un­der­stand­ing the source and chang­ing it to suit the par­tic­u­lar task you have in mind. The soft­ware we live with is far more pow­er­ful with per­son­al­iza­tion. All you need is the source code.

The Age of Personalized Software

The pre-agent de­vel­op­ment costs meant it was ra­tio­nal for com­plex soft­ware to ship with large con­fig­u­ra­tion files, ex­ten­sion sys­tems, and plu­gin sys­tems. The core code of even a mod­er­ate pro­ject like Vim is huge and baroque, and takes weeks for a hu­man to di­gest. The thought that, on want­ing line num­bers to print by de­fault, an en­gi­neer would learn the code base and add it just for them­selves is un­rea­son­able. Better to de­sign it for shar­ing with oth­ers, which jus­ti­fies the ex­pense of im­ple­ment­ing it by amor­tiz­ing it over many users. As fea­tures in a code base grow, it makes sense to look for com­mon ab­strac­tions where you can break out an ex­ten­sion or plu­gin sys­tem.

Now the ex­pense of learn­ing the code and mak­ing a change has dropped dra­mat­i­cally. Agents do the heavy lift­ing. For a sin­gle user—which im­plies ex­tremely con­strained con­di­tions un­der which the pro­gram runs—a top-end agent can usu­ally now add a fea­ture in a sin­gle shot. For sin­gle-user soft­ware, the need for care­ful code re­view can of­ten be re­placed by “does it seem to work?”

The re­sult is that soft­ware that can be per­son­al­ized does­n’t need a plu­gin sys­tem or a con­fig file. Want to change the font size in your text ed­i­tor? Give the agent the source and tell it to. If it is a hard­coded value it will find and edit it. If it’s a hard­coded bitmap font it will down­load an­other and re­place it, or it will use Monobit to make you one! You have in­cred­i­ble ca­pa­bil­i­ties on tap.

Whole Categories of Software Products Need to Be Reinvented

Personal soft­ware ap­plies well to small teams too. Why would an en­gi­neer­ing team pur­chase an ex­tremely con­fig­urable task man­ager (or a CMS or CRM), spend time learn­ing and con­fig­ur­ing it, and con­tort their team to its lim­its, when they can as­sem­ble just the fea­tures they want from com­mon build­ing blocks?

Both the up­front fixed costs and the on­go­ing costs of per­son­al­iz­ing soft­ware have dis­ap­peared.

The blog you are read­ing is be­spoke soft­ware, writ­ten in Shelley, be­cause it was eas­ier to piece to­gether and per­son­al­ize li­braries like Tiptap than it is to try and cus­tomize tra­di­tional soft­ware prod­ucts. For end-user prod­ucts to make sense in a com­pany to­day, they need to be per­son­al­iz­able. Which means we need the source code.

Where Codex and Claude Code Diverge

This same skill-based tech­nique that was ap­plied to Shelley to make it per­son­al­iz­able can be triv­ially ap­plied to other open-source agents like Pi. (So much so that I am left won­der­ing why Pi needs an ex­ten­sion sys­tem built into it. The source code is the ex­ten­sion sys­tem.) It would re­quire a lot more to­kens, but you could do the same to Codex, which is an open-source agent.

Where you would hit a wall, how­ever, is Claude Code. It is closed-source soft­ware, so you don’t get to per­son­al­ize it. There are a lot of old-fash­ioned cus­tomiza­tion hooks in Claude Code. Hopefully, how you want an agent to work fits in their hooks. If not, switch to an agent that lets you per­son­al­ize it.

Despite what I said in April, I’m still us­ing cod­ing as­sis­tants on my per­sonal pro­jects.

Using them to one-shot en­tire fea­tures leaves me un­sat­is­fied and dis­ori­ented, but I do en­joy us­ing them to fast-for­ward through the bor­ing parts of my pro­jects.

However, al­low­ing my cod­ing as­sis­tant to roam free in my pro­jects leaves me with a colos­sal amount of cog­ni­tive debt. I might hate the idea of por­ing over the Django doc­u­men­ta­tion to fig­ure out how to add tag­ging to my web­site, but I still fun­da­men­tally want to un­der­stand how it works. Just be­cause a prob­lem is bor­ing does­n’t mean I want to fully of­fload my un­der­stand­ing of the so­lu­tion to a ma­chine.

Of course, I could re­view every sin­gle line of code the LLM pro­duces. That’s what most de­vel­op­ers are ex­pected to do in this cursed year of 2026. Robots raise PRs, hu­mans re­view them. It’s a brave new world.

But I don’t en­joy re­view­ing AI-generated PRs. Poring over hun­dreds of lines of overly-de­fen­sive, badly-com­mented, sub­tly in­cor­rect code is not fun. I might grudg­ingly do it for an em­ployer—while mak­ing sure said em­ployer be­comes an ex-em­ployer as soon as pos­si­ble—but I’m sure as hell not do­ing it for my per­sonal pro­jects. Personal pro­jects must be fun above all else. The joy of work­ing on per­sonal pro­jects comes from the process, not from the out­come.

So what’s a boy to do? How do I of­fload the bor­ing work to LLMs with­out ced­ing con­trol of my own work and cog­ni­tion to the slop ma­chine?

I’ve come up with a so­lu­tion that’s grossly in­ef­fi­cient and per­haps slightly com­i­cal: I ask my cod­ing as­sis­tant to gen­er­ate code in the chat, then man­u­ally make all the ed­its my­self.

I have these in­struc­tions in all the agents files in my per­sonal pro­jects:

I want to un­der­stand every line of code that goes into this pro­ject. Never cre­ate, edit, move, re­name, or delete pro­ject files un­less I ex­plic­itly ask you to do so. Instead, show me every pro­posed edit in the chat so I can type it in man­u­ally.Do not run com­mands that mod­ify pro­ject files, in­stall de­pen­den­cies, or change repos­i­tory state un­less I ex­plic­itly re­quest that ac­tion. Instead, show me those com­mands in the chat so I can run them man­u­ally.I’m an ex­pe­ri­enced de­vel­oper. Do not ex­plain syn­tax, APIs, pro­gram­ming con­cepts, or im­ple­men­ta­tion de­tails un­less ex­plic­itly asked.

I want to un­der­stand every line of code that goes into this pro­ject. Never cre­ate, edit, move, re­name, or delete pro­ject files un­less I ex­plic­itly ask you to do so. Instead, show me every pro­posed edit in the chat so I can type it in man­u­ally.

Do not run com­mands that mod­ify pro­ject files, in­stall de­pen­den­cies, or change repos­i­tory state un­less I ex­plic­itly re­quest that ac­tion. Instead, show me those com­mands in the chat so I can run them man­u­ally.

I’m an ex­pe­ri­enced de­vel­oper. Do not ex­plain syn­tax, APIs, pro­gram­ming con­cepts, or im­ple­men­ta­tion de­tails un­less ex­plic­itly asked.

Using LLMs this way al­lows me to work faster than not us­ing LLMs at all, but I’m still slower than those who are will­ing to al­low the ma­chine to think for them. Instead of be­ing 10x faster, I’m prob­a­bly only 2x faster. But what I lose out on in terms of speed, I gain in terms of a deeper un­der­stand­ing of my code.

As I man­u­ally type every sin­gle line of LLM gen­er­ated code into my ed­i­tor, I build up a men­tal model of how it works and fits into my ex­ist­ing code­base. If I don’t un­der­stand an API or al­go­rithm, I can stop to look it up, or just ask the LLM to ex­plain it.

Typing the code my­self forces me to slow down, which means I’m more likely to de­tect hal­lu­ci­na­tions or bad de­sign choices the LLM might have made. I can clean up the code as I go, re­or­ga­niz­ing it, refac­tor­ing it, adding com­ments, and gen­er­ally adapt­ing it to my own taste.

Most im­por­tantly, this work­flow al­lows me to build a spa­tial map of my code­base. I know where every bit of func­tion­al­ity lives in the code­base. When I need to make a change, I know ex­actly where I need to make it. It not only helps me work faster within my pro­jects, it also makes it eas­ier for me to bet­ter prompt and in­struct the LLM in the fu­ture.

When I was learn­ing to code as a teenager, ex­pe­ri­enced pro­gram­mers would of­ten tell me to never copy and paste code into my pro­jects. If I was learn­ing from a book, I was ad­vised to copy all the ex­am­ples into my com­puter and make sure I could run them. If I was learn­ing from a blog post or fo­rum an­swer, I was ad­vised to type it out and adapt it to my code­base so I un­der­stood it com­pletely.

Manually typ­ing LLM-generated into my code­base feels like the ex­act same learn­ing process. It might not be the most ef­fi­cient way to work with an LLM, but I value com­pre­hen­sion over pro­duc­tiv­ity. I’ve been do­ing this for a few months now, and it’s been work­ing well for me. I plan to con­tinue us­ing this work­flow for as long as I can.

I fear the soft­ware in­dus­try is tak­ing on a large amount of cog­ni­tive debt that we’ll have to pay back very soon. There will come a time when we no longer un­der­stand how large parts of our dig­i­tal in­fra­struc­ture are put to­gether. I might not per­son­ally be able to change the course of the en­tire in­dus­try, but I can at least make sure I com­pletely un­der­stand the soft­ware I put out into the world. Anything else would be pro­fes­sional mal­prac­tice.

More of Germany’s elec­tric­ity came from wind and so­lar power than from fos­sil fu­els for the first time ever in 2025, ac­cord­ing to Carbon Brief’s analy­sis of Energy Institute Statistical Review of World Energy data. Wind and so­lar to­gether gen­er­ated 225 ter­awatt hours (TWh) of elec­tric­ity, 44% of the to­tal, against 217 TWh (43%) from fos­sil fu­els — a mile­stone Germany shares with the EU as a whole, which also saw wind and so­lar over­take fos­sil-fuel gen­er­a­tion for the first time in 2025.

Wind and so­lar gen­er­ated more elec­tric­ity than fos­sil fu­els in Germany for the first time ever in 2025. Source: Energy Institute Statistical Review of World Energy, 2026 / Carbon Brief.

The shift re­flects two decades of rapid growth in so­lar and on­shore wind un­der Germany’s “Energiewende” strat­egy, as the coun­try tran­si­tions away from both coal and nu­clear power. Germany aims to in­stall 115 gi­gawatts (GW) of on­shore wind by 2030, and ap­proved a record 20.8 GW of new ca­pac­ity in 2025 alone. Official tar­gets re­quire econ­omy-wide net-zero emis­sions by 2045, an 80% re­new­ables share of elec­tric­ity con­sump­tion by 2030, and a “largely cli­mate neu­tral” power sys­tem by 2035.

Germany has to lean on re­new­ables harder than neigh­bours such as France and the UK to hit those goals, pre­cisely be­cause of its nu­clear phase­out — a core plank of the Energiewende that re­mains po­lit­i­cally set­tled de­spite re­cent push­back. Centre-right Chancellor Friedrich Merz de­scribed the phase­out as a “strategic mis­take” ear­lier this year, but his gov­ern­ment has ruled out re­turn­ing to con­ven­tional nu­clear power. Coal re­mains the big­ger near-term chal­lenge: Germany still re­lies on it far more than most other European coun­tries, with an of­fi­cial phase­out dead­line of “no later than” 2038, though ex­perts be­lieve the coun­try is on track to elim­i­nate coal from its power sup­ply years ahead of that date de­spite pres­sure dur­ing the re­cent en­ergy cri­sis to slow the tran­si­tion.

Renewables now face a dif­fer­ent kind of op­po­si­tion, how­ever: mount­ing re­sis­tance from the far-right Alternative for Germany (AfD), even as the cur­rent coali­tion si­mul­ta­ne­ously pur­sues new gas-fired power plants of its own — leg­is­lated as a bridge tech­nol­ogy, with the plants in­tended to con­vert to run on green hy­dro­gen by 2045 to stay con­sis­tent with the cli­mate-neu­tral­ity tar­get. Very few voices out­side the AfD are call­ing to scrap the coal phase­out al­to­gether, but the gov­ern­ment is due to pub­lish a re­view of its time­lines in August, which will be the next test of how firmly Berlin in­tends to hold the line.

I am ex­cited to an­nounce that I am join­ing ClickHouse to es­tab­lish and lead a new re­search team called ClickHouse Labs. I want to share how it came about and what we plan to do.

I started as a pro­fes­sor in the Computer Science Department at Carnegie Mellon University in 2013. I have spent my ca­reer seek­ing to un­der­stand the sci­ence of mod­ern data­base man­age­ment sys­tem (DBMS) in­ter­nals. I make it a pri­or­ity to track every new sys­tem that comes along, both in in­dus­try and acad­e­mia, to un­der­stand their im­ple­men­ta­tions.

I have known about the ClickHouse DBMS since it was first an­nounced as open-source soft­ware in June 2016. My ini­tial re­ac­tion to this news was that it had to be va­por­ware be­cause it seemed too good to be true. ClickHouse had fea­tures that at the time were only found in a hand­ful of closed-source, com­mer­cial an­a­lyt­i­cal DBMSs. For ex­am­ple, ClickHouse was writ­ten in C++ and sup­ported vec­tor­ized query ex­e­cu­tion us­ing SIMD in 2016. Most promi­nent open-source an­a­lyt­i­cal DBMSs in 2016 were JVM-based and did not sup­port SIMD op­ti­miza­tions un­til years later.

Since then, I have fol­lowed ClickHouse’s de­vel­op­ment closely. It has al­ways been a lead­ing sys­tem that was highly rel­e­vant to our aca­d­e­mic re­search pro­jects. You can even see me wear­ing my orig­i­nal ClickHouse shirt in my first re­mote lec­tures in 2020, when the pan­demic forced us to move our data­base courses on­line.

Given this his­tory, I was hon­ored when the ClickHouse co-founders in­vited me to es­tab­lish this new re­search group at ClickHouse. The chance to work with one of the strongest en­gi­neer­ing teams on the next gen­er­a­tion of data­base tech­nol­ogy was an op­por­tu­nity that I could not pass up. This will be a next-level col­lab­o­ra­tion like when Killer Mike hooked up with El-P to cre­ate a hip-hop su­per­group.

The goal of ClickHouse Labs is to es­tab­lish a best-in-class in­dus­try re­search or­ga­ni­za­tion fo­cused on data­bases. It will not op­er­ate as an iso­lated re­search or­ga­ni­za­tion that throws ideas over the wall to en­gi­neer­ing. Instead, we will work closely with ClickHouse en­gi­neers, cus­tomers, col­lab­o­ra­tors, and in­dus­try part­ners to de­velop and dis­sem­i­nate new ideas that keep ClickHouse at the bleed­ing edge.

We will also work with ClickHouse’s PostgreSQL team to help es­tab­lish its bur­geon­ing man­aged ser­vice as a mar­ket leader in per­for­mance and re­li­a­bil­ity. PostgreSQL and ClickHouse serve dif­fer­ent work­load re­quire­ments, but the com­bi­na­tion gives us a broad foun­da­tion for in­ves­ti­gat­ing both trans­ac­tional and an­a­lyt­i­cal data­base prob­lems.

Our ob­jec­tive is straight­for­ward but am­bi­tious: con­duct re­search with sci­en­tific value and then help trans­form the best ideas into tech­nol­ogy that mat­ters to users. I want to achieve the same level of im­pact as­so­ci­ated with pi­o­neer­ing in­dus­try re­search or­ga­ni­za­tions, such as IBM Research and Microsoft Research. Those groups demon­strated that in­dus­try lab­o­ra­to­ries can si­mul­ta­ne­ously ad­vance fun­da­men­tal com­puter sci­ence, in­flu­ence com­mer­cial prod­ucts, and train gen­er­a­tions of data­base re­searchers. That is the tra­di­tion we want to con­tinue.

The ClickHouse team al­ready has an ex­cep­tional record of pub­lish­ing deep tech­ni­cal ma­te­r­ial about its work. Since the es­tab­lish­ment of the com­pany in 2021, its en­gi­neers have pro­duced de­tailed ar­ti­cles that ex­plain the DBMS’s im­ple­men­ta­tion. There is also the 2024 VLDB pa­per that de­scribes ClickHouse’s core ar­chi­tec­ture. These works are so thor­ough that I as­sign them as read­ings to my stu­dents at Carnegie Mellon. At the same time, there is a back­log of in­ter­est­ing ideas and op­ti­miza­tions that the ClickHouse en­gi­neer­ing team has ex­plored but has not yet had the time to val­i­date fully and push into pro­duc­tion. One of my im­me­di­ate pri­or­i­ties is to help ac­cel­er­ate this process. We will then use that as a spring­board to ex­plore new ideas that push ClickHouse even fur­ther.

One larger ques­tion we will in­ves­ti­gate is how DBMSs like ClickHouse and PostgreSQL fit into emerg­ing AI and agen­tic tech­nolo­gies. There are two sides to this prob­lem. The first is de­ter­min­ing what a DBMS should look like to bet­ter sup­port agents. The sec­ond side is de­ter­min­ing how agents can im­prove and au­to­mate the de­vel­op­ment of DBMSs them­selves. Everything is on the table: new hard­ware, new al­go­rithms, new data struc­tures, new ex­e­cu­tion strate­gies, and new ways of build­ing and op­er­at­ing DBMS soft­ware. Although I do not have an­swers to these prob­lems yet (this is why it is re­search), the one thing I am cer­tain about is that ClickHouse’s solid re­la­tional model foun­da­tion po­si­tions it well to evolve along­side these data-in­ten­sive work­loads.

I have spent my ca­reer study­ing how data­base sys­tems are built and help­ing train the peo­ple who build them. With ClickHouse Labs, we now have the op­por­tu­nity to cre­ate an or­ga­ni­za­tion de­voted to ad­vanc­ing both.

MiniMax H3 dropped to­day with open weights, and it’s na­tively sup­ported in ComfyUI as of this morn­ing. Day zero.

This is a next-gen­er­a­tion open-weights video model. Feed it text, im­ages, video, or au­dio and it gen­er­ates video with real stereo sound, up to 2K, up to 15 sec­onds a clip. It is MiniMax’s third-gen­er­a­tion video model, fol­low­ing Hailuo 01 and Hailuo 02, and the first the com­pany has re­leased with open weights.

Try on Comfy Cloud

Text-to-video — prompt only.

Text-to-video — prompt only.

Image-to-video — bring an im­age to life.

Image-to-video — bring an im­age to life.

First-and-last-frame — con­trol the open­ing frame, the clos­ing frame, or both, and let the model fill in the rest.

First-and-last-frame — con­trol the open­ing frame, the clos­ing frame, or both, and let the model fill in the rest.

Reference-to-video — sup­ply ref­er­ence im­ages, video, or au­dio and carry a sub­ject, a mo­tion, or a voice through the clip.

Reference-to-video — sup­ply ref­er­ence im­ages, video, or au­dio and carry a sub­ject, a mo­tion, or a voice through the clip.

Output runs to 2K and up to 15 sec­onds. Audio is gen­er­ated with the video in the same pass, in stereo, not bolted on af­ter­ward.

This is the ca­pa­bil­ity MiniMax leads with, and it’s what col­lapses five sep­a­rate tasks into one model. Real work rarely draws on one modal­ity. H3 takes im­ages, au­dio, and video to­gether and re­solves them against a prompt that ex­plains how they re­late. Describe the re­la­tion­ship be­tween your in­puts and the shot you want, and the model han­dles the cross-modal work it­self.

Audio is a prop­erty of the model, not a post-process. Every au­dio out­put is na­tive stereo.

Motion trans­fer is the one that mat­ters most for graph work. A ref­er­ence video can sup­ply move­ment — a cam­era move, a per­for­mance, a cut­ting rhythm — while the sub­ject and style come from else­where. Combined with in-place edit­ing, that means it­er­at­ing on a shot.

Getting H3 to run well on con­sumer hard­ware took sig­nif­i­cant ma­chine learn­ing en­gi­neer­ing. We found that the mod­el’s mod­u­la­tion weights (~40% of the to­tal pa­ra­me­ters) could be pruned and re­placed with a func­tion­ally equiv­a­lent lookup table, dra­mat­i­cally shrink­ing the mem­ory foot­print with no loss in out­put qual­ity.

On top of that, the weights ship with an ac­cu­rate and ef­fi­cient int8 con­vrot quan­ti­za­tion, and cus­tom ker­nels re­duce the peak VRAM use dur­ing in­fer­ence.

The re­sult gives a to­tal mem­ory foot­print re­duced by 66%, from 123.6 GB in full pre­ci­sion to 42.5 GB with the small­est mod­els vari­ants. Combining this with our dy­namic VRAM of­fload­ing en­ables a next-gen­er­a­tion 2K video model to run lo­cally on a GPU like the RTX 3060.

Update ComfyUI to the lat­est ver­sion 0.30.0 or go to Comfy Cloud

Update ComfyUI to the lat­est ver­sion 0.30.0 or go to Comfy Cloud

Download the work­flows be­low, or find them in the tem­plate li­brary.Down­load MiniMax H3 I2V WorkflowDownload MiniMax H3 R2V WorkflowDownload MiniMax H3 T2V Workflow

Download the work­flows be­low, or find them in the tem­plate li­brary.

Download MiniMax H3 I2V Workflow

Download MiniMax H3 R2V Workflow

Download MiniMax H3 T2V Workflow

Follow the note in the work­flow to down­load the mod­els and save them in the cor­rect model di­rec­tory.

Follow the note in the work­flow to down­load the mod­els and save them in the cor­rect model di­rec­tory.

Write your prompt, con­nect any frame or ref­er­ence in­puts, and run.

Write your prompt, con­nect any frame or ref­er­ence in­puts, and run.

Model weights: 🤗 Comfy-Org/MiniMax-H3

As al­ways, en­joy cre­at­ing!

No posts

A com­pa­ny’s pub­lic state­ment in the mid­dle of an out­break is not mar­ket­ing. It is ev­i­dence — what the com­pany said it knew, and when, pub­lished to the world at a mo­ment when no­body had the ben­e­fit of hind­sight. I have built cases on those state­ments since 1993. I have been read­ing and sav­ing this one since the day the re­call is­sued, and the six­teen days since are worth lay­ing out end to end, be­cause the words have moved a great deal and the sub­stance un­der­neath them has not moved at all.

Start with the orig­i­nal. On July 17 the com­pany posted a state­ment that opened with the peo­ple who got sick — the ill, their fam­i­lies, and Americans whose trust in pro­duce had been shaken. It said that trust took decades to earn. It said the re­moval of prod­uct was based on in­for­ma­tion FDA had pro­vided the day be­fore. And it said some­thing that has not ap­peared in a sin­gle ver­sion since: that FDA’s trace­back was point­ing to a spe­cific in­de­pen­dent farm, de­scribed as less than one per­cent of the United States ice­berg sup­ply, as the po­ten­tial source.

The re­call was July 17. FDA re­ported a pos­i­tive test on July 18. FDA re­tracted that re­sult as a false pos­i­tive on July 19. The July 17 state­ment there­fore ex­plains why the com­pany pulled prod­uct at a mo­ment when no pos­i­tive lab­o­ra­tory re­sult ex­isted any­where in the world, and the rea­son it gives is FDA’s trace­back and the epi­demi­ol­ogy. That is a party ad­mis­sion, and noth­ing pub­lished af­ter­ward reaches back and un­says it.

Two days later the same ad­dress served a dif­fer­ent doc­u­ment. The July 19 ver­sion led with the as­ser­tion that FDA had apol­o­gized to the com­pany. Sympathy for the sick moved from the first para­graph to the fourth and got shorter. The re­call was re­cast in the com­pleted past tense and at­trib­uted to an abun­dance of cau­tion. The ac­knowl­edg­ment about the spe­cific farm was gone. I wrote that night about how the vic­tims ate the ev­i­dence in May, and I have not changed my view since.

There was no apol­ogy. I went look­ing for one in FDA’s July 19 up­date and what is there is a lab­o­ra­tory cor­rec­tion and a no­ti­fi­ca­tion to the firm — and in the same para­graph, a state­ment that FDA con­tin­ues work­ing with the firm to en­sure prod­uct im­pli­cated in this out­break has been re­moved. The word im­pli­cated sur­vived the false pos­i­tive. The next day FDA answered in pub­lic with­out nam­ing any­body: the false-pos­i­tive sam­ple does not change the ba­sis for the in­ves­ti­ga­tion or the over­whelm­ing epi­demi­o­log­i­cal data sup­port­ing the re­call, and trace­back and out­break data con­tinue to con­verge on shred­ded ice­berg let­tuce from Taylor Farms lo­ca­tions in cen­tral Mexico. Note the plural lo­ca­tions. The com­pany had de­scribed one in­de­pen­dent farm at less than one per­cent of sup­ply and then stopped de­scrib­ing it at all.

By July 24 the page had been rewrit­ten again, this time lead­ing with money — more than two hun­dred mil­lion dol­lars a year in in­de­pen­dently au­dited food safety pro­to­cols — and re­port­ing that sourc­ing and cen­tral-Mex­ico pro­duc­tion had been sus­pended since July 18 and in­de­pen­dent ex­perts com­mis­sioned for a top-to-bot­tom re­view. The apol­ogy claim was sim­ply ab­sent. No cor­rec­tion, no note, no ac­knowl­edg­ment it had ever been there.

On July 30 the com­pany built some­thing new, a Cy­clospora in­for­ma­tion hub at its own ad­dress, and the old news­room link now redi­rects there. It was re­vised again on July 31, and that re­vi­sion cre­ated a prob­lem. The FAQ list of states that re­ceived re­called prod­uct now runs to twenty-eight and in­cludes West Virginia, which FDA added a week ear­lier. The dis­tri­b­u­tion para­graph higher up the same page still lists twenty-seven and still leaves West Virginia out. West Virginia is one of the nine states in the fed­eral out­break.

Now. All of that is about words, and I have spent enough of this out­break on words. Here is the sub­stance the words have never touched, in six­teen days and five ver­sions.

This is not the first time, and the record of it is long. In the sum­mer of 2013, cy­clospo­ri­a­sis sick­ened 631 peo­ple across twenty-five states. Iowa and Nebraska ac­counted for 239 of them, and epi­demi­o­logic and trace­back work by those two states, CDC and FDA tied their restau­rant cases to bagged salad mix pro­duced by Taylor Farms de Mexico in Doctor Mora, Guanajuato, and served at Olive Garden and Red Lobster. I want to be ex­act here, be­cause the num­ber gets mis­used: the Texas cases that sum­mer were tied to cilantro from an un­re­lated pro­ducer, and the cause of more than a hun­dred other ill­nesses was never de­ter­mined. The salad mix link is to Iowa and Nebraska.

FDA then pub­lished an en­vi­ron­men­tal as­sess­ment of the pro­cess­ing plant and five ranches. Investigators an­a­lyzed roughly 835 prod­uct, wa­ter and en­vi­ron­men­tal sam­ples, in­clud­ing more than 269 hu­man fe­cal sam­ples col­lected from san­i­tary fa­cil­i­ties on the ranches, and re­cov­ered the par­a­site from none of them — the as­sess­ment be­gan five weeks af­ter the last known ill­ness. What sur­vives from that doc­u­ment is its sec­ond rec­om­men­da­tion, which told the firm to de­ter­mine whether Cy­clospora is a rea­son­ably likely food safety haz­ard as­so­ci­ated with the Guanajuato leafy green grow­ing re­gion, and if it is, to re-eval­u­ate the wash step. That was November 2013.

There is one more piece of the 2013 record, and it goes di­rectly to the test­ing ques­tion. The com­pany sus­pended ship­ments to the United States on August 9, 2013, and re­sumed them on August 25 with FDA’s con­cur­rence. FDA said at the time that its de­ci­sion rested in part on the en­vi­ron­men­tal as­sess­ment and in part on its re­view of a prod­uct sam­pling plan for Cyclospora that Taylor Farms de Mexico had put in place. A sam­pling plan for this par­a­site, re­viewed by a fed­eral agency, as part of the price of re­open­ing a plant — thir­teen years ago. I have gone look­ing for a sin­gle pub­lished re­sult from it and I have not found one.

Reasonably likely haz­ard is not ca­sual lan­guage. It is the vo­cab­u­lary of haz­ard analy­sis, and the com­pa­ny’s own hub says its pro­cess­ing fa­cil­i­ties op­er­ate un­der the FSMA pre­ven­tive con­trols rule — un­der which a haz­ard re­quir­ing a pre­ven­tive con­trol brings mon­i­tor­ing, ver­i­fi­ca­tion and records along with it. Meanwhile FDA’s own fact sheet for farm­ers car­ries a foot­note list­ing where cy­clospo­ri­a­sis is en­demic: Bangladesh, Brazil, Chile, China, Cuba, Dominican Republic, Egypt, Guatemala, Haiti, India, Indonesia, Jordan, Mexico, Morocco, Nepal, Nigeria, Pakistan, Peru, Puerto Rico, Romania, Saudi Arabia, Tanzania, Thailand, Turkey, Venezuela, Viet Nam and Zimbabwe. Mexico is on that list and has been for years.

The ques­tion, then, is not why you did not test. The ques­tion is what your haz­ard analy­sis says about this par­a­site. If you iden­ti­fied it as a rea­son­ably likely haz­ard, pro­duce the pre­ven­tive con­trol, the ver­i­fi­ca­tion ac­tiv­ity and the records. If you con­cluded it was not a rea­son­ably likely haz­ard, ex­plain the ba­sis for that con­clu­sion — thir­teen years af­ter a fed­eral agency told you to make the de­ter­mi­na­tion, in a coun­try that same agency lists as en­demic, at the same plant, grow­ing a ready-to-eat prod­uct with no kill step. I can­not con­struct an an­swer that sur­vives both ver­sions of the ques­tion.

The same fact sheet tells farm­ers to as­sess wa­ter sys­tems and ad­ja­cent land for sources of con­t­a­m­i­na­tion, and it names sewage and sep­tic sys­tems and land ap­pli­ca­tion of waste­water. The hub lists ad­ja­cent land re­view as part of the com­pa­ny’s ranch in­spec­tions. Good. There is a pub­lic swim­ming re­sort roughly eight hun­dred feet from the Doctor Mora plant, and satel­lite im­agery shows it op­er­at­ing there years be­fore the 2013 as­sess­ment was writ­ten. What did the ad­ja­cent land re­view record about it?

Which brings me to the test­ing, and to the num­ber the com­pany has put at the cen­ter of its de­fense. The hub says that as of July 24 FDA had no con­firmed pos­i­tive prod­uct test re­sults, and that the com­pa­ny’s own test­ing — ap­prox­i­mately two thou­sand sam­ples taken in cen­tral Mexico since May — re­turned zero pos­i­tives. I want to be pre­cise about what that does and does not show, and I want to be fair about what the com­pany ac­tu­ally claims.

On wa­ter, the com­pany de­scribes its own pro­gram in seven words: wa­ter sources are tested for in­di­ca­tor or­gan­isms. FDA’s fact sheet says that tra­di­tional mi­cro­bial test­ing, mean­ing fe­cal in­di­ca­tors like generic E. co­l­ior fe­cal co­l­iforms, will not iden­tify the pres­ence of this par­a­site. FDA also says — and I will give the agency the rest of its sen­tence — that in­di­ca­tor test­ing may help iden­tify poor wa­ter qual­ity, which may it­self be a sign of hu­man fe­cal con­t­a­m­i­na­tion. Indicators are not use­less. They are a proxy. But a proxy for fe­cal load­ing is not a test for the or­gan­ism, and this or­gan­is­m’s only reser­voir on earth is hu­man fe­ces.

On prod­uct, the com­pany says more. It says it uses the lat­est FDA-validated test­ing method for Cy­clospora, which means FDA’s Bacteriological Analytical Manual Chapter 19b, pub­lished in June 2017 and since ex­tended to ma­tri­ces in­clud­ing ro­maine let­tuce. There is a com­pan­ion method, Chap­ter 19c, pub­lished in 2020, for agri­cul­tural wa­ter — val­i­dated to de­tect roughly six oocysts in ten liters. Both have ex­isted for years. The hon­est state­ment, then, is not that this com­pany never tested for the par­a­site. It is that the wa­ter pro­gram, by the com­pa­ny’s own de­scrip­tion, was never aimed at it, and that the prod­uct test­ing it did do can­not bear the weight now be­ing placed on it.

Here is why. The Canadian Food Inspection Agency in­de­pen­dently ver­i­fied FDA’s pro­duce method and pub­lished the re­sults. Leafy greens spiked with two hun­dred oocysts were de­tected ninety-three per­cent of the time. A 2023 mod­el­ing study in the Journal of Food Protection says the same thing in the fed­eral reg­is­ter of the sci­en­tific lit­er­a­ture: these meth­ods have been shown not to al­ways de­tect con­t­a­m­i­na­tion when pre­sent at low lev­els.

Apply that to two thou­sand sam­ples and the num­ber stops be­ing im­pres­sive. It is not ev­i­dence that the prod­uct was clean. It is ev­i­dence that a method with a thirty per­cent de­tec­tion rate, run against an un­known frac­tion of an enor­mous vol­ume of let­tuce, mostly af­ter the con­t­a­m­i­na­tion win­dow had al­ready closed, found noth­ing.

FDA says its trace­back and its out­break data con­verge on shred­ded ice­berg let­tuce from this com­pa­ny’s lo­ca­tions in cen­tral Mexico. The com­pany says its own two thou­sand sam­ples found noth­ing. Both of those can be true at once, and if they are, the con­clu­sion is not that the let­tuce was clean. The con­clu­sion is that the test­ing pro­gram could not find what was in it. Negative re­sults from a pro­gram that can­not de­tect the haz­ard are not ex­on­er­a­tion. They are a de­scrip­tion of the pro­gram.

The com­pa­ny’s po­si­tion is that epi­demi­ol­ogy can iden­tify a po­ten­tial source but that only a pos­i­tive lab­o­ra­tory test can con­firm a spe­cific prod­uct caused ill­ness. Fine — that is a de­fen­si­ble view of proof, and plenty of sci­en­tists hold it. But a stan­dard that strict about pos­i­tives has noth­ing at all to say about neg­a­tives. If a pos­i­tive is the only thing that counts, then two thou­sand neg­a­tives count for noth­ing too, and the com­pany can­not cite them as if they did.

One last item, and it closes the cir­cle back to 2013. The posts says the com­pa­ny’s teams in­vented a wash sys­tem that is tested and ver­i­fied by USDA and de­scribes cus­tom spin dry­ers and con­sis­tent wash-wa­ter chem­istry. That is a wash step, val­i­dated against bac­te­ria, for an or­gan­ism against which no wash step and no chem­i­cal treat­ment has ever been val­i­dated — FDA says in its own voice that chlo­rine and other com­mon an­timi­cro­bial treat­ments are not ef­fec­tive on it. FDA told this fa­cil­ity to re-eval­u­ate its wash step in 2013. Thirteen years later the wash step is on the web­site as a cre­den­tial.

I do not fault a com­pany for de­fend­ing it­self, and I do not fault it for up­dat­ing a page as facts change. What I fault is a record that moves with­out say­ing it moved, while the ques­tions that ac­tu­ally mat­ter stay un­touched un­der­neath it. Five ver­sions in six­teen days, an apol­ogy as­serted and qui­etly dropped, a trace­back ac­knowl­edg­ment re­moved and later re­stored, a state list that an­swers its own ques­tion two ways on one screen — and in all of it, not one sen­tence about what changed at that plant af­ter 2013.

Two com­mit­tees in Congress have asked this com­pany for doc­u­ments by August 10 and August 13. If I had one re­quest to add to theirs, it would be short. Produce the haz­ard analy­sis. Produce the wa­ter test­ing records and say what or­gan­ism they were look­ing for. Produce the ad­ja­cent land re­views for the Doctor Mora ranches. And pro­duce the 2013 file, the one that an­swers whether this par­a­site was ever treated as a rea­son­ably likely haz­ard at a plant in a coun­try FDA calls en­demic. Everything else on that web­site is a claim.

On March 13, 2025, Hugo Moreno-Mendez ar­rived at the McLennan County Probation Department in Waco, Texas, ex­pect­ing a rou­tine pro­ba­tion check-in. Instead, Immigration and Customs Enforcement of­fi­cers were wait­ing to ar­rest him.

According to a crim­i­nal com­plaint re­viewed by WIRED, of­fi­cers drove Moreno-Mendez to a nearby ICE field of­fice. There, one de­por­ta­tion of­fi­cer af­ter an­other ap­proached him with the same de­mand.

Open your mouth.

One of­fi­cer tried to take his fin­ger­prints and swab the in­side of his cheek for DNA. He re­fused. Then an­other tried. Then a third. Each time, Moreno-Mendez re­fused.

Four days later, Moreno-Mendez was charged with fail­ing to reg­is­ter as a nonci­t­i­zen and re­fus­ing to pro­vide DNA while in fed­eral cus­tody—the lat­ter a mis­de­meanor that, as of 2021, ICE it­self said it was un­aware had ever been ac­cepted for pros­e­cu­tion.

Moreno-Mendez took both counts to trial. On August 18, 2025, a mag­is­trate judge in Waco found him guilty of each and sen­tenced him to time served.

Moreno-Mendez’s case is part of a sweep­ing ex­pan­sion of DNA col­lec­tion from peo­ple held for civil im­mi­gra­tion vi­o­la­tions—a fed­eral cam­paign that, backed by the threat of pros­e­cu­tion, fun­nels the ge­netic pro­files of nearly every­one in ICE cus­tody into an FBI data­base built for crim­i­nal in­ves­ti­ga­tions. New re­search from Georgetown Law’s Center on Privacy and Technology es­ti­mates that the Department of Homeland Security has be­come the largest sin­gle source of new ge­netic pro­files in the na­tion’s crim­i­nal DNA sys­tem, with ICE alone po­ten­tially adding as many as roughly 920,000 pro­files in 2025.

The vast ma­jor­ity of peo­ple in ICE cus­tody have no crim­i­nal con­vic­tion, and re­sid­ing in the US un­doc­u­mented is typ­i­cally a civil, not crim­i­nal, of­fense. Yet once the DNA pro­files of de­tained peo­ple en­ter the FBI’s Combined DNA Index System, or CODIS, law en­force­ment agen­cies across the coun­try can com­pare them against ev­i­dence from un­solved crimes—and against crime-scene DNA col­lected years or even decades from now. The phys­i­cal sam­ple, which holds a per­son’s en­tire genome, sits in a fed­eral lab­o­ra­tory in­def­i­nitely.

The ex­pan­sion of DNA col­lec­tion has ex­tended to fam­i­lies held in im­mi­gra­tion de­ten­tion, sparked law­suits over the col­lec­tion of DNA from pro­test­ers and oth­ers who al­lege they should never have been sub­jected to the pro­gram, and drawn con­gres­sional scrutiny af­ter law­mak­ers learned that chil­dren were be­ing swabbed at a fam­ily de­ten­tion cen­ter in Dilley, Texas.

“None of the fam­i­lies at Dilley have been con­victed of a crime,” US rep­re­sen­ta­tives Joaquin Castro, Greg Stanton, and Nanette Barragán said in a joint state­ment to WIRED. “They do not be­long in a data­base meant for vi­o­lent crim­i­nals, es­pe­cially chil­dren.”

In re­sponse to ques­tions from WIRED, a DHS spokesper­son de­fended DNA col­lec­tion as a bor­der-se­cu­rity and iden­ti­fi­ca­tion mea­sure, say­ing CBP takes sam­ples from peo­ple ar­rested on fed­eral charges and from de­tained nonci­t­i­zens who are sub­ject to fin­ger­print­ing and not oth­er­wise ex­empt. Asked about chil­dren whose pro­files were sub­mit­ted to CODIS, DHS pointed to a sep­a­rate DNA-testing pro­gram used to ver­ify fam­ily re­la­tion­ships. That pro­gram is dis­tinct from the col­lec­tion at the cen­ter of WIRED’s re­port­ing. DHS did not ad­dress Georgetown’s es­ti­mate that ICE may have added hun­dreds of thou­sands of pro­files to CODIS in 2025.

For most of the pro­gram’s his­tory, mi­grant DNA col­lec­tion played out at the bor­der, where Customs and Border Protection swabbed peo­ple it took into cus­tody. ICE’s own con­tri­bu­tion was mar­ginal. Internal train­ing slides ob­tained by Georgetown through the Freedom of Information Act (FOIA) show ICE col­lected 3,609 DNA sam­ples in fis­cal year 2020 and 16,392 more through mid-May of fis­cal 2021—roughly 20,000 in all. CBP was op­er­at­ing on a dif­fer­ent scale en­tirely: Agency spread­sheets Georgetown ob­tained and an­a­lyzed show it sent the FBI the DNA of at least 1.36 mil­lion peo­ple be­tween October 2020 and the end of 2024, more than a dozen times ICE’s rate dur­ing the same time pe­riod.

Georgetown’s new re­port sug­gests the pro­gram en­tered an en­tirely dif­fer­ent phase in 2025. FBI records show the “detainee” in­dex of CODIS—the sub-in­dex where DHS-collected pro­files are stored—reached 3,345,692 pro­files by December 2025, grow­ing by roughly 995,000 that year alone. That is more than 2,700 peo­ple a day, every day, for a year.