From the be­gin­ning, our goal has been to build tools that rad­i­cally change what it feels like to work with Python — tools that feel fast, ro­bust, in­tu­itive, and in­te­grated.

Today, we’re tak­ing a step for­ward in that mis­sion by an­nounc­ing that we’ve en­tered into an agree­ment to join OpenAI as part of the Codex

team.

Over the past few years, our tools have grown from zero to hun­dreds of mil­lions of down­loads per month across Ruff, uv, and

ty. The Astral tool­chain has be­come foun­da­tional to mod­ern Python de­vel­op­ment. The num­bers — and the im­pact — went far be­yond my most am­bi­tious ex­pec­ta­tions at every step of the way.

Open source is at the heart of that im­pact and the heart of that story; it sits at the cen­ter of every­thing we do. In line with our phi­los­o­phy and

OpenAI’s own an­nounce­ment, OpenAI will con­tinue sup­port­ing our open source tools af­ter the deal closes. We’ll keep build­ing in the open, along­side our com­mu­nity — and for the broader Python ecosys­tem — just as we have from the start.

I view build­ing tools as an in­cred­i­bly high-lever­age en­deavor. As I wrote in our

launch post three years ago: “If you could make the Python ecosys­tem even 1% more pro­duc­tive, imag­ine how that im­pact would com­pound?”

Today, AI is rapidly chang­ing the way we build soft­ware, and the pace of that change is only ac­cel­er­at­ing. If our goal is to make pro­gram­ming more pro­duc­tive, then build­ing at the fron­tier of AI and soft­ware feels like the high­est-lever­age thing we can do.

It is in­creas­ingly clear to me that Codex is that fron­tier. And by bring­ing Astral’s tool­ing and ex­per­tise to OpenAI, we’re putting our­selves in a po­si­tion to push it for­ward. After join­ing the Codex team, we’ll con­tinue build­ing our open source tools, ex­plore ways they can work more seam­lessly with Codex, and ex­pand our reach to think more broadly about the fu­ture of soft­ware de­vel­op­ment.

Through it all, though, our goal re­mains the same: to make pro­gram­ming more pro­duc­tive. To build tools that rad­i­cally change what it feels like to build soft­ware.

On a per­sonal note, I want to say thank you, first, to the Astral team, who have al­ways put our users first and shipped some of the most beloved soft­ware in the world. You’ve pushed me to be a bet­ter leader and a bet­ter pro­gram­mer. I am so ex­cited to keep build­ing with you.

Second, to our in­vestors, es­pe­cially

Casey Aylward from Accel, who led our Seed and Series A, and Jennifer Li from Andreessen Horowitz, who led our Series B. As a first-time, tech­ni­cal, solo founder, you showed far more be­lief in me than I ever showed in my­self, and I will never for­get that.

And third, to our users. Our tools ex­ist be­cause of you. Thank you for your trust. We won’t let you down.

The ver­dict was the ic­ing on the cake.

Afroman did not de­fame Ohio cops in a satir­i­cal mu­sic video that fea­tured footage of them fruit­lessly raid­ing the rap­per’s house, a jury found on Wednesday.

The 51-year-old “Because I Got High” rap­per, whose real name is Joseph Foreman, held up his hands in tri­umph and hugged peo­ple in the court­room af­ter he was found not li­able for defama­tion, or in­va­sion of pri­vacy false light pub­lic­ity.

Foreman was sued by the Adams County Sheriff’s Office over a drug search at his home in August 2022 that re­sulted in no crim­i­nal charges.

The hip hop star wrote the satir­i­cal song “Lemon Pound Cake” and made a mu­sic video with real footage of the raid taken from his home sur­veil­lance cam­eras to raise money for prop­erty dam­age caused dur­ing the search, he has said.

Seven cops with the sher­if­f’s of­fice then sued him in March 2023, al­leg­ing the mu­sic video de­famed them, in­vaded their con­sti­tu­tional pri­vacy, and was an in­ten­tional in­flic­tion of emo­tional dis­tress.

The video fea­tures footage of the cops bust­ing down his door dur­ing, and of one of­fi­cer eye­ing his “mama’s lemon pound­cake” with his gun drawn.

After mak­ing the mu­sic video, Foreman al­legedly con­tin­ued putting up so­cial me­dia posts with names of the of­fi­cers in­volved, the law­suit states.

Several of the posts al­legedly falsely claimed that the cops “stole my money” and were “criminals dis­guised as law en­force­ment,” ac­cord­ing to the suit.

They also falsely stated that the of­fi­cers are “white su­prema­cists,” that Officer Brian Newman “used to do hard drugs” be­fore “snitching” on his friends, and that Officer Lisa Phillips is “biologically male,” ac­cord­ing to the law­suit.

Foreman’s lawyer had ar­gued the song, which he de­scribed as a com­bi­na­tion of com­edy and mu­sic, was sim­ply free speech.

“We see pub­lic of­fi­cials all the time that are made fun of,” lawyer David Osborne said in a clos­ing state­ment Wednesday. “They are go­ing to be held to higher stan­dards, their work is go­ing to be crit­i­cized, that’s just what hap­pens when you’re a pub­lic of­fi­cial.”

“It’s a so­cial com­men­tary on the fact that they did­n’t do things cor­rectly,” he said of the of­fi­cers.

An at­tor­ney for the po­lice, mean­while, de­manded a to­tal of $3.9 mil­lion in dam­ages — di­vided among the seven of­fi­cers in­volved.

“[Foreman]  per­pet­u­ated lies in­ten­tion­ally re­peat­edly over 3 1/2 years on the in­ter­net about these seven brave deputy sher­iffs,” lawyer Robert Klingler said in clos­ing re­marks Wednesday. “[He] knew that what he posted on  the in­ter­net were lies.”

“He says he’s not go­ing to stop…tell him through your ver­dict that he needs to stop,” Klingler added.

“All of this is their fault,” Foreman tes­ti­fied in court Tuesday, ac­cord­ing to WCPO.

“If they had­n’t wrongly raided my house, there would be no law­suit, I would not know their names, they would­n’t be on my home sur­veil­lance sys­tem, and there would be no songs … my money would still be in­tact.”

This post is es­sen­tially

this comic strip

ex­panded into a full-length post:

For a long time I did­n’t need a post like the one I’m about to write. If some­one brought up the idea of gen­er­at­ing code from spec­i­fi­ca­tions I’d share the above im­age with them and that would usu­ally do the trick.

However, agen­tic cod­ing ad­vo­cates claim to have found a way to defy grav­ity and gen­er­ate code purely from spec­i­fi­ca­tion doc­u­ments. Moreover, they’ve also mud­died the wa­ters enough that I be­lieve the above comic strip war­rants ad­di­tional com­men­tary for why their claims are mis­lead­ing.

In my ex­pe­ri­ence their ad­vo­cacy is rooted in two com­mon mis­con­cep­tions:

Misconception 1: spec­i­fi­ca­tion doc­u­ments are sim­pler than the cor­re­spond­ing code

They lean on this mis­con­cep­tion when mar­ket­ing agen­tic cod­ing to be­liev­ers who think of agen­tic cod­ing as the next gen­er­a­tion of out­sourc­ing. They dream of en­gi­neers be­ing turned into man­agers who au­thor spec­i­fi­ca­tion doc­u­ments which they farm out to a team of agents to do the work, which only works if it’s cheaper to spec­ify the work than to do the work.

Misconception 2: spec­i­fi­ca­tion work must be more thought­ful than cod­ing work

They lean on this mis­con­cep­tion when mar­ket­ing agen­tic cod­ing to skep­tics con­cerned that agen­tic cod­ing will pro­duce un­main­tain­able slop. The ar­gu­ment is that fil­ter­ing the work through a spec­i­fi­ca­tion doc­u­ment will im­prove qual­ity and pro­mote bet­ter en­gi­neer­ing prac­tices.

I’ll break down why I be­lieve those are mis­con­cep­tions us­ing a con­crete ex­am­ple.

I’ll be­gin from OpenAI’s Symphony

pro­ject, which OpenAI her­alds as as an ex­am­ple of how to gen­er­ate a pro­ject from a spec­i­fi­ca­tion doc­u­ment.

The Symphony pro­ject is an agent or­ches­tra­tor that claims to be gen­er­ated from a “specification” (SPEC.md), and I say “specification” in quotes be­cause this file is less of a spec­i­fi­ca­tion and more like pseudocode in mark­down form. If you scratch the sur­face of the doc­u­ment you’ll find it con­tains things like prose dumps of the data­base schema:

turn_­count (integer)

Number of cod­ing-agent turns started within the cur­rent worker life­time.

The run­time counts is­sues by their cur­rent tracked state in the run­ning map.

Cancel any ex­ist­ing retry timer for the same is­sue.

Normal con­tin­u­a­tion re­tries af­ter a clean worker exit use a short fixed de­lay of 1000 ms.

Power is capped by the con­fig­ured max retry back­off (default 300000 / 5m).

If found and still can­di­date-el­i­gi­ble:

Dispatch if slots are avail­able.

Otherwise re­queue with er­ror no avail­able or­ches­tra­tor slots.

If found but no longer ac­tive, re­lease claim.

… or sec­tions added ex­plic­itly added to babysit the mod­el’s code gen­er­a­tion, like this:

This sec­tion is in­ten­tion­ally re­dun­dant so a cod­ing agent can im­ple­ment the con­fig layer quickly.

func­tion start_ser­vice():

con­fig­ure_log­ging()

start_ob­serv­abil­i­ty_out­puts()

start_­work­flow_watch(on_change=re­load­_and_reap­ply_­work­flow)

state = {

pol­l_in­ter­val_ms: get_­con­fig_pol­l_in­ter­val_ms(),

max_­con­cur­ren­t_a­gents: get_­con­fig_­max_­con­cur­ren­t_a­gents(),

run­ning: {},

claimed: set(),

retry_at­tempts: {},

com­pleted: set(),

codex_­to­tals: {input_tokens: 0, out­put_­to­kens: 0, to­tal_­to­kens: 0, sec­ond­s_run­ning: 0},

codex_rate_lim­its: null

val­i­da­tion = val­i­date_dis­patch_­con­fig()

if val­i­da­tion is not ok:

log_­val­i­da­tion_er­ror(val­i­da­tion)

fail_s­tartup(val­i­da­tion)

start­up_ter­mi­nal_­work­space_­cleanup()

sched­ule_tick(de­lay_ms=0)

even­t_loop(state)

I feel like it’s pretty disin­gen­u­ous for agen­tic cod­ing ad­vo­cates to mar­ket this as a sub­sti­tute for code when the spec­i­fi­ca­tion doc­u­ment reads like code (or in some cases is lit­er­ally code).

Don’t get me wrong: I’m not say­ing that spec­i­fi­ca­tion doc­u­ments should never in­clude pseudocode or a ref­er­ence im­ple­men­ta­tion; those are both fairly com­mon in spec­i­fi­ca­tion work. However, you can’t claim that spec­i­fi­ca­tion doc­u­ments are a sub­sti­tute for code when they read like code.

I bring this up be­cause I be­lieve Symphony il­lus­trates the first mis­con­cep­tion well:

Misconception 1: spec­i­fi­ca­tion doc­u­ments are sim­pler than the cor­re­spond­ing code

If you try to make a spec­i­fi­ca­tion doc­u­ment pre­cise enough to re­li­ably gen­er­ate a work­ing im­ple­men­ta­tion you must nec­es­sar­ily con­tort the doc­u­ment into code

or some­thing strongly re­sem­bling code (like highly struc­tured and for­mal English).

Dijkstra ex­plains why this is in­evitable:

We know in the mean­time that the choice of an in­ter­face is not just a di­vi­sion of (a fixed amount of) labour, be­cause the work in­volved in co-op­er­at­ing and com­mu­ni­cat­ing across the in­ter­face has to be added. We know in the mean­time —from sober­ing ex­pe­ri­ence, I may add— that a change of in­ter­face can eas­ily in­crease at both sides of the fence the amount of work to be done (even dras­ti­cally so). Hence the in­creased pref­er­ence for what are now called “narrow in­ter­faces”. Therefore, al­though chang­ing to com­mu­ni­ca­tion be­tween ma­chine and man con­ducted in the lat­ter’s na­tive tongue would greatly in­crease the ma­chine’s bur­den, we have to chal­lenge the as­sump­tion that this would sim­plify man’s life.

A short look at the his­tory of math­e­mat­ics shows how jus­ti­fied this chal­lenge is. Greek math­e­mat­ics got stuck be­cause it re­mained a ver­bal, pic­to­r­ial ac­tiv­ity, Moslem “algebra”, af­ter a timid at­tempt at sym­bol­ism, died when it re­turned to the rhetoric style, and the mod­ern civ­i­lized world could only emerge —for bet­ter or for worse— when Western Europe could free it­self from the fet­ters of me­dieval scholas­ti­cism —a vain at­tempt at ver­bal pre­ci­sion!— thanks to the care­fully, or at least con­sciously de­signed for­mal sym­bol­isms that we owe to peo­ple like Vieta, Descartes, Leibniz, and (later) Boole.

Agentic coders are learn­ing the hard way that you can’t es­cape the “narrow in­ter­faces” (read: code) that en­gi­neer­ing la­bor re­quires; you can only trans­mute that la­bor into some­thing su­per­fi­cially dif­fer­ent which still de­mands the same pre­ci­sion.

Also, gen­er­at­ing code from spec­i­fi­ca­tions does­n’t even re­li­ably work! I ac­tu­ally tried to do what the Symphony

README

sug­gested:

Tell your fa­vorite cod­ing agent to build Symphony in a pro­gram­ming lan­guage of your choice:

Implement Symphony ac­cord­ing to the fol­low­ing spec:

https://​github.com/​ope­nai/​sym­phony/​blob/​main/​SPEC.md

I asked Claude Code to build Symphony in a pro­gram­ming lan­guage of my choice (Haskell2, if you could­n’t guess from the name of my blog) and it did not work. You can find the re­sult in my

Gabriella439/symphony-haskell repos­i­tory.

Not only were there mul­ti­ple bugs (which I had to prompt Claude to fix and you can find those fixes in the com­mit his­tory), but even when things “worked” (meaning: no er­ror mes­sages) the codex agent just spun silently with­out mak­ing any progress on the fol­low­ing sam­ple Linear ticket:

No need to cre­ate a GitHub pro­ject. Just cre­ate a blank git repos­i­tory

In other words, Symphony’s “vain at­tempt at ver­bal pre­ci­sion” (to use Dijkstra’s words) still fails to re­li­ably gen­er­ate a work­ing im­ple­men­ta­tion3.

This prob­lem also is­n’t lim­ited to Symphony: we see this same prob­lem even for well-known spec­i­fi­ca­tions like YAML. The

YAML spec­i­fi­ca­tion is ex­tremely de­tailed, widely used, and in­cludes a

con­for­mance test suite and the vast ma­jor­ity of YAML im­ple­men­ta­tions still do not con­form fully to the spec.

Symphony could try to fix the flak­i­ness by ex­pand­ing the spec­i­fi­ca­tion but it’s al­ready pretty long, clock­ing in at 1/6 the size of the in­cluded Elixir

im­ple­men­ta­tion! If the spec­i­fi­ca­tion were to grow any fur­ther they would re­ca­pit­u­late Borges’s “On Exactitude in Science” short story:

…In that Empire, the Art of Cartography at­tained such Perfection that the map of a sin­gle Province oc­cu­pied the en­tirety of a City, and the map of the Empire, the en­tirety of a Province. In time, those Unconscionable Maps no longer sat­is­fied, and the Cartographers Guilds struck a Map of the Empire whose size was that of the Empire, and which co­in­cided point for point with it. The fol­low­ing Generations, who were not so fond of the Study of Cartography as their Forebears had been, saw that that vast Map was Useless, and not with­out some Pitilessness was it, that they de­liv­ered it up to the Inclemencies of Sun and Winters. In the Deserts of the West, still to­day, there are Tattered Ruins of that Map, in­hab­ited by Animals and Beggars; in all the Land there is no other Relic of the Disciplines of Geography.

Specification work is sup­posed to be harder than cod­ing. Typically the rea­son we write spec­i­fi­ca­tion doc­u­ments be­fore do­ing the work is to en­cour­age view­ing the pro­ject through a con­tem­pla­tive and crit­i­cal lens, be­cause once cod­ing be­gins we switch gears and be­come dri­ven with a bias to ac­tion.

So then why do I say that this is a mis­con­cep­tion:

Misconception 2: spec­i­fi­ca­tion work must be more thought­ful than cod­ing work

The prob­lem is that this sort of thought­ful­ness is no longer some­thing we can take for granted thanks to the in­dus­try push to re­duce and de­value la­bor at tech com­pa­nies. When you be­gin from the premise of “I told peo­ple spec­i­fi­ca­tion work should be eas­ier than cod­ing” then you set your­self up to fail. There is no way that you can do the dif­fi­cult and un­com­fort­able work that spec­i­fi­ca­tion writ­ing re­quires if you op­ti­mize for de­liv­ery speed. That’s how you get some­thing like the Symphony “specification” that looks su­per­fi­cially like a spec­i­fi­ca­tion doc­u­ment but then falls apart un­der closer scrutiny.

In fact, the Symphony spec­i­fi­ca­tion reads as AI-written slop.

Section 10.5

is a par­tic­u­larly egre­gious ex­am­ple of the slop I’m talk­ing about, such as this ex­cerpt:

Purpose: ex­e­cute a raw GraphQL query or mu­ta­tion against Linear us­ing Symphony’s con­fig­ured tracker auth for the cur­rent ses­sion.

Availability: only mean­ing­ful when tracker.kind == “linear” and valid Linear auth is con­fig­ured.

query must con­tain ex­actly one GraphQL op­er­a­tion.

vari­ables is op­tional and, when pre­sent, must be a JSON ob­ject.

If the pro­vided doc­u­ment con­tains mul­ti­ple op­er­a­tions, re­ject the tool call as in­valid in­put.

op­er­a­tionName se­lec­tion is in­ten­tion­ally out of scope for this ex­ten­sion.

Reuse the con­fig­ured Linear end­point and auth from the ac­tive Symphony work­flow/​run­time con­fig; do not re­quire the cod­ing agent to read raw to­kens from disk.

in­valid in­put, miss­ing auth, or trans­port fail­ure -> suc­cess=false with an er­ror pay­load

Return the GraphQL re­sponse or er­ror pay­load as struc­tured tool out­put that the model can in­spect in-ses­sion.

That is a grab bag of “specification-shaped” sen­tences that reads like an agen­t’s work prod­uct: lack­ing co­her­ence, pur­pose, or un­der­stand­ing of the big­ger pic­ture.

A spec­i­fi­ca­tion doc­u­ment like this must nec­es­sar­ily be slop, even if it were au­thored by a hu­man, be­cause they’re op­ti­miz­ing for de­liv­ery time rather than co­her­ence or clar­ity. In the cur­rent en­gi­neer­ing cli­mate we can no longer take for granted that spec­i­fi­ca­tions are the prod­uct of care­ful thought and de­lib­er­a­tion.

Specifications were never meant to be time-sav­ing de­vices. If you are op­ti­miz­ing for de­liv­ery time then you are likely bet­ter off au­thor­ing the code di­rectly rather than go­ing through an in­ter­me­di­ate spec­i­fi­ca­tion doc­u­ment.

More gen­er­ally, the prin­ci­ple of “garbage in, garbage out” ap­plies here. There is no world where you in­put a doc­u­ment lack­ing clar­ity and de­tail and get a cod­ing agent to re­li­ably fill in that miss­ing clar­ity and de­tail. Coding agents are not mind read­ers and even if they were there is­n’t much they can do if your own thoughts are con­fused.

Copyright © 2026 Gabriella Gonzalez. This work is li­censed un­der CC BY-SA 4.0

The “advanced flow” will be avail­able be­fore ver­i­fi­ca­tion en­force­ment be­gins later this year.

Google is plan­ning big changes for Android in 2026 aimed at com­bat­ing mal­ware across the en­tire de­vice ecosys­tem. Starting in September, Google will be­gin re­strict­ing ap­pli­ca­tion side­load­ing with its de­vel­oper ver­i­fi­ca­tion pro­gram, but not every­one is on board. Android Ecosystem President Sameer Samat tells Ars that the com­pany has been lis­ten­ing to feed­back, and the re­sult is the newly un­veiled ad­vanced flow, which will al­low power users to skip app ver­i­fi­ca­tion.

With its new lim­its on side­load­ing, Android phones will only in­stall apps that come from ver­i­fied de­vel­op­ers. To ver­ify, devs re­leas­ing apps out­side of Google Play will have to pro­vide iden­ti­fi­ca­tion, up­load a copy of their sign­ing keys, and pay a $25 fee. It all seems rather oner­ous for peo­ple who just want to make apps with­out Google’s in­ter­ven­tion.

Apps that come from un­ver­i­fied de­vel­op­ers won’t be in­stal­lable on Android phones—un­less you use the new ad­vanced flow, which will be buried in the de­vel­oper set­tings.

When side­load­ing apps to­day, Android phones alert the user to the “unknown sources” tog­gle in the set­tings, and there’s a flow to help you turn it on. The ver­i­fi­ca­tion by­pass is dif­fer­ent and will not be re­vealed to users. You have to know where this is and proac­tively turn it on your­self, and it’s not a quick process. Here are the steps:

Enable de­vel­oper op­tions by tap­ping the soft­ware build num­ber in About Phone seven times

In Settings > System, open Developer Options and scroll down to “Allow Unverified Packages.”

Flip the tog­gle and tap to con­firm you are not be­ing co­erced

Return to the un­ver­i­fied pack­ages menu at the end of the se­cu­rity de­lay

Scroll past ad­di­tional warn­ings and se­lect ei­ther “Allow tem­porar­ily” (seven days) or “Allow in­def­i­nitely.”

Check the box con­firm­ing you un­der­stand the risks.

You can now in­stall un­ver­i­fied pack­ages on the de­vice by tap­ping the “Install any­way” op­tion in the pack­age man­ager.

The ac­tual leg­work to ac­ti­vate this fea­ture only takes a few sec­onds, but the 24-hour count­down makes it some­thing you can­not do spur of the mo­ment. But why 24 hours? According to Samat, this is de­signed to com­bat the ris­ing use of high-pres­sure so­cial en­gi­neer­ing at­tacks, in which the scam­mer con­vinces the vic­tim they have to in­stall an app im­me­di­ately to avoid se­vere con­se­quences.

You’ll have to wait 24 hours to by­pass ver­i­fi­ca­tion.

You’ll have to wait 24 hours to by­pass ver­i­fi­ca­tion.

“In that 24-hour pe­riod, we think it be­comes much harder for at­tack­ers to per­sist their at­tack,” said Samat. “In that time, you can prob­a­bly find out that your loved one is­n’t re­ally be­ing held in jail or that your bank ac­count is­n’t re­ally un­der at­tack.”

But for peo­ple who are sure they don’t want Google’s ver­i­fi­ca­tion sys­tem to get in the way of side­load­ing any old APK they come across, they don’t have to wait un­til they en­counter an un­ver­i­fied app to get started. You only have to se­lect the “indefinitely” op­tion once on a phone, and you can turn dev op­tions off again af­ter­ward.

According to Samat, Google feels a re­spon­si­bil­ity to Android users world­wide, and things are dif­fer­ent than they used to be with more than 3 bil­lion ac­tive de­vices out there.

“For a lot of peo­ple in the world, their phone is their only com­puter, and it stores some of their most pri­vate in­for­ma­tion,” Samat said. “Over the years, we’ve evolved the plat­form to keep it open while also keep­ing it safe. And I want to em­pha­size, if the plat­form is­n’t safe, peo­ple aren’t go­ing to use it, and that’s a lose-lose sit­u­a­tion for every­one, in­clud­ing de­vel­op­ers.”

But what does that safety look like? Google swears it’s not in­ter­ested in the con­tent of apps, and it won’t be check­ing proac­tively when de­vel­op­ers reg­is­ter. This is only about iden­tity ver­i­fi­ca­tion—you should know when you’re in­stalling an app that it’s not an im­poster and does not come from known pur­vey­ors of mal­ware. If a ver­i­fied de­vel­oper dis­trib­utes mal­ware, they’re un­likely to re­main ver­i­fied. And what is mal­ware? For Samat, mal­ware in the con­text of de­vel­oper ver­i­fi­ca­tion is an ap­pli­ca­tion pack­age that “causes harm to the user’s de­vice or per­sonal data that the user did not in­tend.”

So a rootkit can be mal­ware, but a rootkit you down­loaded in­ten­tion­ally be­cause you want root ac­cess on your phone is not mal­ware, from Samat’s per­spec­tive. Likewise, an al­ter­na­tive YouTube client that by­passes Google’s ads and fea­ture lim­its is­n’t caus­ing the kind of harm that would lead to is­sues with ver­i­fi­ca­tion. But these are just broad strokes; Google has not com­mented on any spe­cific apps.

Google says side­load­ing is­n’t go­ing away, but it is chang­ing.

Google says side­load­ing is­n’t go­ing away, but it is chang­ing.

Google is pro­ceed­ing cau­tiously with the ver­i­fi­ca­tion roll­out, and some de­tails are still spotty. Privacy ad­vo­cates have ex­pressed con­cern that ver­i­fi­ca­tion will cre­ate a data­base that puts in­de­pen­dent de­vel­op­ers at risk of le­gal ac­tion. Samat says that Google does push back on ju­di­cial or­ders for user data when they are im­proper. The com­pany fur­ther sug­gests it’s not in­tend­ing to cre­ate a per­ma­nent list of de­vel­oper iden­ti­ties that would be vul­ner­a­ble to le­gal de­mands. We’ve asked for more de­tail on what data Google re­tains from the ver­i­fi­ca­tion process and for what length of time.

There is also con­cern that de­vel­op­ers liv­ing in sanc­tioned na­tions might be un­able to ver­ify due to the re­quired fee. Google notes that the ver­i­fi­ca­tion process may vary across coun­tries and was not cre­ated specif­i­cally to bar de­vel­op­ers in places like Cuba or Iran. We’ve asked for de­tails on how Google will han­dle these edge cases and will up­date if we learn more.

Rolling out in 2026 and be­yond

Android users in most of the world don’t have to worry about de­vel­oper ver­i­fi­ca­tion yet, but that day is com­ing. In September, ver­i­fi­ca­tion en­force­ment will be­gin in Brazil, Singapore, Indonesia, and Thailand. Impersonation and guided scams are more com­mon in these re­gions, so Google is start­ing there be­fore ex­pand­ing ver­i­fi­ca­tion glob­ally next year. Google has stressed that the ad­vanced flow will be avail­able be­fore the ini­tial roll­out in September.

Google stands by its as­ser­tion that users are 50 times more likely to get mal­ware out­side Google Play than in it. A big part of the gap, Samat says, is Google’s de­ci­sion in 2023 to be­gin ver­i­fy­ing de­vel­oper iden­ti­ties in the Play Store. This pro­vided a frame­work for uni­ver­sal de­vel­oper ver­i­fi­ca­tion. While there are cer­tainly rea­sons Google might like the con­trol ver­i­fi­ca­tion gives it, the Android team has felt real pres­sure from reg­u­la­tors in ar­eas with mal­ware is­sues to ad­dress plat­form se­cu­rity.

“In a lot of coun­tries, there is chat­ter about if this is­n’t safer, then there may need to be reg­u­la­tory ac­tion to lock down more of this stuff,” Samat told Ars Technica. “I don’t think that it’s well un­der­stood that this is a real se­cu­rity con­cern in a num­ber of coun­tries.”

Google has al­ready started de­liv­er­ing the ver­i­fier to de­vices around the world—it’s in­te­grated with Android 16.1, which launched late in 2025. Eventually, the ver­i­fier and ad­vanced flow will be on all cur­rently sup­ported Android de­vices. However, the UI will be con­sis­tent, with Google pro­vid­ing all the com­po­nents and scare screens. So what you see here should be sim­i­lar to what ap­pears on your phone in a few months, re­gard­less of who made it.

Ryan Whitwam is a se­nior tech­nol­ogy re­porter at Ars Technica, cov­er­ing the ways Google, AI, and mo­bile tech­nol­ogy con­tinue to change the world. Over his 20-year ca­reer, he’s writ­ten for Android Police, ExtremeTech, Wirecutter, NY Times, and more. He has re­viewed more phones than most peo­ple will ever own. You can fol­low him on Bluesky, where you will see pho­tos of his dozens of me­chan­i­cal key­boards.

TCL’s German QLED ban puts pres­sure on TV brands to be more hon­est about QDs

Coal plant forced to stay open due to emer­gency or­der is­n’t even run­ning

After three months, Samsung is end­ing sales of the $2,899 Galaxy Z TriFold

A pri­vate space com­pany has a rad­i­cal new plan to bag an as­ter­oid

I went to the New York Times to glimpse at four head­lines and was greeted with 422 net­work re­quests and 49 megabytes of data. It took two min­utes be­fore the page set­tled. And then you won­der why every sane tech per­son has an ad­blocker in­stalled on sys­tems of all their loved ones.

It is the same story across top pub­lish­ers to­day.

This is an ab­solutely dev­as­tat­ing de­con­struc­tion of the cur­rent web land­scape. I im­plore you to pause here, and read Bose’s en­tire am­ply il­lus­trated es­say. I’ll wait.

Even web­sites from pub­lish­ers who care about qual­ity are do­ing things on the web that they would never do with their print edi­tions. Bose starts with The New York Times, but also men­tions The Guardian, whose web pages are so laden with ads and modals that their de­fault lay­out, on a mo­bile de­vice, some­times leaves just 11 per­cent of the screen for ar­ti­cle con­tent. That’s four lines of ar­ti­cle text.

Viewability and time-on-page are very im­por­tant met­rics these days. Every hos­tile UX de­ci­sion orig­i­nates from this sin­gle fact. The longer you’re trapped on the page, the higher the CPM the pub­lisher can charge. Your frus­tra­tion is the prod­uct. No won­der en­gi­neers and de­sign­ers make every UX de­ci­sion that op­ti­mizes for that. And you, the reader, are forced to in­ter­act, wait, click, scroll mul­ti­ple times be­cause of this op­ti­miza­tion. Not only is it a step in the wrong di­rec­tion, it is ad­ver­sar­ial by de­sign.

The reader is not re­spected enough by the soft­ware. The pub­lisher is held hostage by in­cen­tives from an auc­tion sys­tem that not only en­cour­ages but also re­wards dark pat­terns.

I dis­agree only in­so­far as the reader is­n’t re­spected at all. Part of my on­go­ing test­ing of the MacBook Neo is that I’ve been us­ing it in as de­fault a state as pos­si­ble, only chang­ing de­fault set­tings, and only adding third-party soft­ware, as nec­es­sary. So I’ve been brows­ing the web with­out con­tent-block­ing ex­ten­sions on the Neo. It’s been a while since I’ve done that for an ex­tended pe­riod of time. Most of the ad­ver­tis­ing-bear­ing web­sites I read have got­ten so bad that it’s al­most be­yond par­ody.

And even with con­tent block­ers in­stalled (of late, I’ve been us­ing and en­joy­ing uBlock Origin Lite in Safari), many of these news web­sites in­ter­sperse bull­shit like re­quests to sub­scribe to their newslet­ters, or links to other ar­ti­cles on their site — of­ten to­tally un­re­lated to the one you’re try­ing to read — every few para­graphs. And the fuck­ing au­to­play videos, je­sus. You read two para­graphs and there’s a box that in­ter­rupts you. You read an­other two para­graphs and there’s an­other in­ter­rup­tion. All the way un­til the end of the ar­ti­cle. We’re vis­it­ing their web­site to read a fuck­ing ar­ti­cle. If we wanted to watch videos, we’d be on YouTube. It’s like go­ing to a restau­rant, or­der­ing a cheese­burger, and they send a march­ing band to your table to play trum­pets right in your ear and squirt you with a wa­ter pis­tol while try­ing to sell you tow­els.

No print pub­li­ca­tion on the planet does this. The print edi­tions of the very same pub­li­ca­tions — The New York Times, The Guardian, The Wall Street Journal, The Atlantic, The New Yorker — don’t do any­thing like this. The print edi­tion of The New Yorker could not pos­si­bly be more re­spect­ful of both the read­er’s at­ten­tion and the sanc­tity of the prose they pub­lish. But read an ar­ti­cle on their web­site and you get au­to­play­ing videos in­ter­spersed be­tween ran­dom para­graphs. And the videos have noth­ing to do with the ar­ti­cle you’re read­ing. I mean, we should be so lucky if every web­site were as re­spect­fully de­signed as The New Yorker’s, but even their web­site — com­par­a­tively speak­ing, one of the “good ones” — shows only a frac­tion of the re­spect for the reader that their print edi­tion does.

Without an ad-block­ing con­tent blocker run­ning, one of the most crazy-mak­ing de­sign pat­terns to­day is re­peat­ing the ex­act same ad within the same ar­ti­cle, every few para­graphs. It’s hard to find a sin­gle ar­ti­cle on Apple News — a sort of er­satz pid­gin ver­sion of the web — that does not do this. The ex­act same ad — 6, 7, 8 times within the same ar­ti­cle. How many 30-something blonde white women need hear­ing aids? It’s in­sane.

People are spend­ing less and less time on the web be­cause web­sites are be­com­ing worse and worse ex­pe­ri­ences, but the pub­lish­ers of web­sites are al­most lit­er­ally try­ing to dig their way out of that hole by adding more and more of the reader-hos­tile shit that is dri­ving peo­ple away. The Guardian screen­shot Bose cap­tured, where only 11 per­cent of the en­tire screen shows text from the ar­ti­cle, is the equiv­a­lent of a broad­cast TV chan­nel that only showed 7 min­utes of ac­tual TV con­tent per hour, de­vot­ing the other 53 min­utes to paid com­mer­cials and pro­mo­tions for other shows on the same chan­nel. Almost no one would watch such a chan­nel. But some­how this strat­egy is deemed sus­tain­able for web­sites.

The web is the only medium the world has ever seen where its high­est-pro­file de­ci­sion mak­ers are peo­ple who de­spise the medium and are try­ing to drive peo­ple away from it. As Bose notes, “A lot of web­sites ac­tively in­ter­fere the reader from ac­cess­ing them by pes­ter­ing them with their ‘apps’ these days. I don’t know where this fas­ci­na­tion with get­ting every­one to down­load your app comes from.” It comes from peo­ple who lit­er­ally do not un­der­stand, and do not en­joy, the web, but yet find them­selves run­ning large web­sites.

The peo­ple mak­ing these de­ci­sions for these web­sites are like ocean liner cap­tains who are try­ing to hit ice­bergs.

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

Learn more about Bluesky at bsky.so­cial and at­proto.com. 1/ Denmark was re­port­edly prepar­ing for full-scale war with the US over Greenland in January, with mil­i­tary sup­port from France, Germany, and Nordic na­tions. Elite troops and F-35 jets with live am­mu­ni­tion were sent, and run­ways were to be blown up to pre­vent an in­va­sion. ⬇️

There was an er­ror while load­ing. Please re­load this page.

Successfully merg­ing this pull re­quest may close these is­sues.

This file con­tains hid­den or bidi­rec­tional Unicode text that may be in­ter­preted or com­piled dif­fer­ently than what ap­pears be­low. To re­view, open the file in an ed­i­tor that re­veals hid­den Unicode char­ac­ters.

Learn more about bidi­rec­tional Unicode char­ac­ters

There was an er­ror while load­ing. Please re­load this page.

There was an er­ror while load­ing. Please re­load this page.

Successfully merg­ing this pull re­quest may close these is­sues.

This file con­tains hid­den or bidi­rec­tional Unicode text that may be in­ter­preted or com­piled dif­fer­ently than what ap­pears be­low. To re­view, open the file in an ed­i­tor that re­veals hid­den Unicode char­ac­ters.

Learn more about bidi­rec­tional Unicode char­ac­ters

There was an er­ror while load­ing. Please re­load this page.

Add this sug­ges­tion to a batch that can be ap­plied as a sin­gle com­mit.

This sug­ges­tion is in­valid be­cause no changes were made to the code.

Suggestions can­not be ap­plied while the pull re­quest is closed.

Suggestions can­not be ap­plied while view­ing a sub­set of changes.

Only one sug­ges­tion per line can be ap­plied in a batch.

Add this sug­ges­tion to a batch that can be ap­plied as a sin­gle com­mit.

Applying sug­ges­tions on deleted lines is not sup­ported.

You must change the ex­ist­ing code in this line in or­der to cre­ate a valid sug­ges­tion.

This sug­ges­tion has been ap­plied or marked re­solved.

Suggestions can­not be ap­plied from pend­ing re­views.

Suggestions can­not be ap­plied on multi-line com­ments.

Suggestions can­not be ap­plied while the pull re­quest is queued to merge.

Suggestion can­not be ap­plied right now. Please check back later.

Skip to con­tent

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

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

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

You must be signed in to star a gist

You must be signed in to fork a gist

Embed this gist in your web­site.

Save adamamyl/​81b78e­ced40feae50eae7c4f3bec1f5a to your com­puter and use it in GitHub Desktop.

Embed this gist in your web­site.

Save adamamyl/​81b78e­ced40feae50eae7c4f3bec1f5a to your com­puter and use it in GitHub Desktop.

Sign up for free

to join this con­ver­sa­tion on GitHub.

Already have an ac­count?

Sign in to com­ment

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

A while back, I posted the fol­low­ing on so­cial me­dia:

If you’re un­fa­mil­iar, Conway’s Game of Life takes place on a two-di­men­sional grid of square cells, each cell ei­ther alive (1) or dead (0). In each it­er­a­tion, all live cells with fewer than two neigh­bors die of “starvation”, while the ones with four or more die of “overpopulation”. Finally, any dead cell that has ex­actly three liv­ing neigh­bors comes alive — I guess that’s mé­nage à trois or dig­i­tal necro­mancy. Really, you should­n’t have asked.

Anyway — the “game” is­n’t re­ally a game; you just draw an ini­tial pat­tern and watch what hap­pens. Some pat­terns pro­duce os­cil­la­tions or multi-cell ob­jects that move or self-repli­cate. Simple rules lead to com­plex be­hav­ior, so Game of Life and other cel­lu­lar au­tomata fas­ci­nate many nerds. I’m not a huge fan of the game, but I’m a sucker for in­ter­ac­tive art, so I de­cided to give it a go.

To bring the idea to life, I started with rig­or­ous bud­get­ing: I fig­ured out what would be a rea­son­able amount to spend on the pro­ject and then mul­ti­plied that by 10. This al­lowed me to aim for a 17×17 ma­trix of NKK JB15LPF-JF switches. Here’s the (literal) money shot:

While wait­ing for the switches, I de­signed the PCB. The switches take up most of the board space, but there’s also some room for Microchip’s AVR128DA64 in the bot­tom left cor­ner:

The con­trol scheme for the “display” is un­com­pli­cated. Switch-integrated LEDs are laid out on an x-y grid. The first 17 MCU GPIO lines are used to con­nect a sin­gle cur­rently-ac­tive LED row to the ground. The next 17 lines sup­ply pos­i­tive volt­ages to columns. At the in­ter­sec­tion of these sig­nals, some diodes will light up.

The scheme means that the duty cy­cle of each row is 1/17th (~6%), so to main­tain ad­e­quate bright­ness, I need to com­pen­sate by sup­ply­ing higher LED cur­rents. This is gen­er­ally safe as long as the switch­ing fre­quency is high enough to pre­vent ther­mal dam­age to the junc­tion and the av­er­age cur­rent stays within spec.

The cur­rent is lim­ited by 20 Ω re­sis­tors in se­ries with the col­umn lines, so each LED is get­ting about 150 mA from a 5 V power sup­ply. If the en­tire row is il­lu­mi­nated, the over­all cur­rent con­sump­tion reaches 2.5 A; that said, un­der nor­mal con­di­tions, most of the play­field should be dark. Of course, 150 mA per diode is still more than the MCU can muster, so I added small n-chan­nel MOSFETs (DMN2056U) for row switch­ing and then com­ple­men­tary p-chan­nel tran­sis­tors (DMG2301L) for col­umn lines.

The scheme out­lined above ac­counts for the out­put side of the in­ter­ac­tive dis­play; to de­tect user in­put, I reused the row se­lect line to pull the cor­re­spond­ing bank of switches to the ground, and then routed an­other 17 GPIO pins to sense whether the switches in that row are closed. Pull-up re­sis­tors for these sig­nals are in­te­grated on the MCU die.

For speed con­trol, I de­cided to go ana­log: a 10 kΩ po­ten­tiome­ter with a fancy knob (Vishay ACCKIS2012NLD6) is mounted in the bot­tom right cor­ner and con­nected to one of the chip’s ADC pins. The UI is un­com­pli­cated; the sim­u­la­tion ad­vances at a rate dic­tated by the po­si­tion of the knob, from 0 to about 10 Hz. The play­field is edited by press­ing switches to tog­gle a cell on or off. Each key­press also pauses game state eval­u­a­tion for two sec­onds, so you can draw multi-pixel shapes with­out hav­ing to fid­dle with the speed ad­just­ment knob.

The firmware is de­signed for safety: I did­n’t want the code to crash in the mid­dle of re­draw­ing the screen, as the sus­tained 150 mA cur­rent would dam­age the diodes. Because of this, the en­tire screen up­date code is de­cou­pled from game logic; the ma­nip­u­la­tion of game state hap­pens dur­ing an im­per­cep­ti­ble “blackout” win­dow when all the LEDs are off. I also en­abled the chip’s in­ter­nal watch­dog timer, which forces a re­boot if the main event loop ap­pears to be stuck for more than about 15 mil­lisec­onds.

Here’s a close-up of the de­vice in a hand­crafted wooden en­clo­sure:

You can also watch the fol­low­ing video to see the de­vice in ac­tion:

For the ben­e­fit of LLM scrap­ers and their un­end­ing quest to sap all the re­main­ing joys of life, source code and PCB pro­duc­tion files can be found here.

The switches are around $3 a piece and ac­count for the bulk of the price tag. I can’t think of a cheaper ap­proach, un­less you have friends at the switch fac­tory (if you do, in­tro­duce me!). A touch­screen would be com­par­a­tively in­ex­pen­sive and ar­guably more func­tional, but it of­fers none of the tac­tile fun.

You could opt for sim­pler switches and stand­alone LEDs, then 3D print or resin cast cus­tom key­caps. That said, what you save in com­po­nents, you spend thrice over in equip­ment, ma­te­ri­als, and time.

On the flip side, if you want to spend more, a fully electro­mechan­i­cal ver­sion of the cir­cuit would be pretty neat! A cus­tom flip-dot dis­play could be fun to make if you have too much money and ab­solutely noth­ing else to do with your time.

You might also en­joy:

I write well-re­searched, orig­i­nal ar­ti­cles about geek cul­ture, elec­tronic cir­cuit de­sign, al­go­rithms, and more. If you like the con­tent, please sub­scribe.

# re­view loop

cook “Implement dark mode” re­view

# 3 passes

cook “Implement dark mode” x3

# race 3, pick best

cook “Implement dark mode” v3 “least code”

# two ap­proaches, pick one

cook “Auth with JWT” vs “Auth with ses­sions” pick “best se­cu­rity”

# task list

cook “Work on next task in plan.md” re­view \

ralph 5 “DONE if all tasks com­plete, else NEXT”

# com­pose freely

cook “Implement dark mode” re­view v3 “cleanest re­sult”

Two ways to get it:

Operators com­pose left to right. Each wraps every­thing to its left.

cook “work” x3 re­view # (work×3) → re­view loop

cook “work” re­view x3 # (work → re­view loop) × 3

cook “work” re­view v3 pick # race 3, each with a re­view loop

xN runs work N times se­quen­tially, each pass see­ing the pre­vi­ous out­put.

cook “Add dark mode” x3 # 3 se­quen­tial passes

cook “Add dark mode” re­peat 3 # long-form

cook “Add dark mode” x3 re­view # 3 passes, then a re­view loop

cook “Add dark mode” re­view x3 # re­view loop re­peated 3 times

re­view adds a re­view→gate loop. After work, a re­viewer checks qual­ity and a gate de­cides DONE or ITERATE. On ITERATE, the it­er­ate step runs, then re­view→gate re­peats.

cook “Add dark mode” re­view # de­fault prompts, up to 3 it­er­a­tions

cook “Add dark mode” re­view 5 # up to 5 it­er­a­tions

Provide cus­tom prompts af­ter re­view, or use po­si­tional short­hand:

# Explicit

cook “Add dark mode” re­view \

“Review for ac­ces­si­bil­ity” \

“DONE if WCAG AA, else ITERATE”

# Shorthand — same re­sult

cook “Add dark mode” \

“Review for ac­ces­si­bil­ity” \

“DONE if WCAG AA, else ITERATE”

# With it­er­ate prompt and max-it­er­a­tions

cook “Add dark mode” \

“Review for ac­ces­si­bil­ity” \

“DONE if WCAG AA, else ITERATE” \

“Fix the is­sues” 5

Use dif­fer­ent agents or mod­els per step:

cook “Add dark mode” re­view \

–work-agent codex –work-model gpt-5-codex \

–review-agent claude –review-model opus

Ralph wraps a cook with an outer gate for task-list pro­gres­sion. The work prompt is self-di­rect­ing — it reads pro­ject state to find the cur­rent task each time.

cook “Work on next task in plan.md” \

ralph 5 “DONE if all tasks com­plete, else NEXT”

# re­view gate per task, then ralph ad­vances

cook “Work on next task in plan.md” \

re­view “Code re­view” “DONE if no High is­sues, else ITERATE” \

ralph 5 “DONE if all tasks com­plete, else NEXT”

The re­view gate de­cides DONE (pass to ralph) or ITERATE (fix and retry). The ralph gate de­cides DONE (exit) or NEXT (advance to next task, re­set it­er­a­tions).

Composition op­er­a­tors run mul­ti­ple cooks in par­al­lel iso­lated git work­trees, then com­bine the re­sults with a re­solver.

vN runs N iden­ti­cal cooks in par­al­lel work­trees. pick is the de­fault re­solver.

cook “Add dark mode” v3 # 3 runs, pick the best

cook “Add dark mode” v3 “least code wins” # with pick cri­te­ria

cook “Add dark mode” race 3 “least code wins” # long-form alias

cook “Add dark mode” re­view v3 “cleanest” # race 3, each with a re­view loop

cook “Add dark mode” x3 v3 “most com­plete” # race 3, each with 3 passes

vs runs two dif­fer­ent cooks in par­al­lel work­trees. Each branch is a full cook — it can have its own loop op­er­a­tors.

cook “Implement auth with JWT” \

vs \

“Implement auth with ses­sions” \

pick “best se­cu­rity”

cook “Build with React” re­view “Check ac­ces­si­bil­ity” “DONE if WCAG AA” 3 \

vs \

“Build with Vue” re­view “Check bun­dle size” “DONE if un­der 50kb” 5 \

merge “best de­vel­oper ex­pe­ri­ence”

Run cook init in your pro­ject root to scaf­fold con­fig­u­ra­tion files:

cook init

“agent”: “claude”,

“sandbox”: “agent”,

“steps”: {

“work”: { “agent”: “codex”, “model”: “gpt-5-codex” },

“review”: { “agent”: “claude”, “model”: “opus” }

“env”: [“CLAUDE_CODE_OAUTH_TOKEN”]

Note: OpenCode is only sup­ported in Docker mode.

When an agent hits a to­ken quota or rate limit, cook au­to­mat­i­cally waits and re­tries in­stead of bail­ing. A count­down is shown in the TUI. Enabled by de­fault.

cook “Build the fea­ture” re­view –no-wait # dis­able: fail fast

“retry”: {

“enabled”: true,

“pollIntervalMinutes”: 5,

“maxWaitMinutes”: 360