06 Jun, 2026

I’m a soft­ware en­gi­neer, com­plet­ing 10 years of pro­fes­sional ex­pe­ri­ence this year. I started my ca­reer as a web fron­tend en­gi­neer (it was eas­ier for me to de­bug fron­tend code back then, so I chose that path), but shortly tran­si­tioned to (web) back­end and never looked back.

Through a se­ries of co­in­ci­dences, once I stepped into back­end de­vel­op­ment, I ended up work­ing in soft­ware de­vel­op­ment roles in the do­mains of fi­nance, book­keep­ing and pay­ment pro­cess­ing, where I had great au­ton­omy and a close and can­did re­la­tion­ship with Product Managers and stake­hold­ers.

I learnt a lot about the do­main and how to ef­fec­tively write pro­grams for it: PCI com­pli­ance, dou­ble-en­try ledgers, es­crows, rec­on­cil­i­a­tion, pay­ment life­cy­cles, bank trans­fer idem­po­tency, etc.

It was, then, ob­vi­ous that I should fo­cus my ca­reer on be­com­ing an ex­pert on that do­main to stand out as a pro­fes­sional and dif­fer­en­ti­ate my­self in a field that showed signs of an in­creas­ing need for do­main spe­cial­ists.

The first pil­lar to erode: do­main-spe­cific knowl­edge

Last year, I got hired by a com­pany in the fi­nance work­space. So far, I had worked on com­pa­nies that do have a strong pay­ment and fi­nance com­po­nent to their op­er­a­tions/​of­fer­ings, but that were not solely fi­nance-fo­cused com­pa­nies.

That com­pany also em­braced AI whole­heart­edly, so I got ChatGPT and Claude Enterprise ac­counts from day one and was en­cour­aged to use them for my re­search, ex­plo­ration, and even cod­ing, al­beit with a warn­ing that I should still re­view and own every sin­gle line that made it into pro­duc­tion.

One of my first pro­jects in­volved re­work­ing the legacy on­line pay­ment sys­tem, which was a mess. They hired me for (among other things) my pre­vi­ous ex­pe­ri­ence in build­ing that and trusted me with the task.

Different from the other com­pa­nies I had worked for so far, they wanted the “Design Docs” I write be­fore cod­ing to be read­able by both en­gi­neers and prod­uct man­agers - so they should­n’t be a tech­ni­cal deep dive and more of an ar­chi­tec­tural view. I wrote my first one with min­i­mal AI as­sis­tance - I even called LLMs “stochastic par­rots” at the time, a view I no longer hold - and de­liv­ered it.

I val­ued my knowl­edge and thought no LLMs could re­place it.

Then my man­ager reached out to me: even though you’re de­liv­er­ing code at a good pace, you’re tak­ing too long to de­liver those Design Docs. Are you us­ing AI? You should use more AI.

“No way this will work”, I thought in my head, but agreed. The mod­els at that time were not as good as the ones we have now, but they did pro­vide a good speed-up on my writ­ing and even the de­ci­sion-mak­ing.

And then I started re­al­iz­ing: all the knowl­edge I have ac­cu­mu­lated over the years: the trade-offs be­tween im­ple­men­ta­tions, how ac­quir­ing works, how to struc­ture idem­po­tency to pre­vent dou­ble-charges, every­thing, was be­com­ing use­less. Even though the mod­els still needed some steer­ing, they could con­nect the dots on how to struc­ture such sys­tems, which was the hard­est part that only de­vel­ops in your brain af­ter years of hands-on ex­pe­ri­ence. That was my first shock.

But sure, I thought, they can do that be­cause there’s plenty of ar­ti­cles on the web on how that shit works along with all the tech­ni­cal doc­u­men­ta­tion, and we have blog posts ex­plain­ing how to ap­ply the tech­ni­cal tools to the do­main. For hu­mans, it may take a long time to learn all that, but that’s train­ing data so the mod­els can pick it up.

What the mod­els will never be good at, and that’s where hu­mans will shine, is de­bug­ging! I had ac­cu­mu­lated a good ex­pe­ri­ence de­bug­ging race con­di­tions and dis­trib­uted sys­tems in pro­duc­tion. That was my ticket to long-term em­ploy­a­bil­ity.

The sec­ond pil­lar to erode: de­bug­ging and dis­trib­uted sys­tems

So, af­ter LLMs started get­ting good at writ­ing docs and help­ing plan the ac­tual im­ple­men­ta­tions, they be­came good at cod­ing. It started in the sec­ond half of 2025 with the Claude Code hype, then Codex came and so on. Although I was us­ing LLMs for writ­ing unit tests every day be­fore that, I was­n’t trust­ing them to write the full im­ple­men­ta­tion yet.

The nat­ural next step was to in­tro­duce more AI into writ­ing code. And hon­estly, I liked it. I like ship­ping things to pro­duc­tion and see­ing users happy as much as I like cod­ing, so I was trad­ing one thing that I like for an­other one that I also like, it was fair.

LLMs were be­com­ing good at cod­ing, but it still could­n’t de­bug the mess left be­hind (by then or by the hu­mans), so I still had a role that was big­ger than steer­ing the ro­bot - a ticket to em­ploy­a­bil­ity.

Everything seemed fine.

Then came the MCPs, the agen­tic work­flows and Claude 4.5 and the sky started to fall.

Claude 4.5, to be hon­est, was­n’t that good. It solved like 60% of the bugs given a stack trace and some con­text (a Sentry link with Sentry MCP en­abled was all it took in most cases). Sometimes it gave a so­lu­tion that sounded plau­si­ble but was to­tally wrong.

This time, how­ever, I stopped doubt­ing the ma­chines. I saw bugs that in the past would eas­ily take 1 day of full-time de­bug­ging be­ing one-shot­ted by Claude Code. Of course, not all of them yet, but the pat­tern was clear.

Then came 4.6, 4.7, GPT 5.5, Opus 4.8 and the DataDog MCP… Now I have CLIs that one-shots bugs across dis­trib­uted sys­tems for me. Bugs that I could­n’t solve in the past. Bugs that would take 2 days of full-time de­bug­ging. Bugs across dis­trib­uted sys­tems that lack dis­trib­uted ob­serv­abil­ity. 90% of the bugs are one-shot­ted now, in­clud­ing bizarre race con­di­tions, un­ex­pected cor­ner-cases, third-party in­te­gra­tion is­sues, un­doc­u­mented API edge cases, every­thing. I hardly have to in­ter­vene.

Of course, I’m still em­ploy­able be­cause some­one has to re­view the code and steer the ro­bot. But I’m just an­other off-the-shelf en­gi­neer now. I have no do­main ex­per­tise that an­other Sr. en­gi­neer steer­ing an LLM can­not match. All my fi­nance and pay­ment do­main ex­per­tise, all the de­bug­ging in­tu­ition and dis­trib­uted sys­tem knowl­edge earned through hours of sweat and tears, is now prompt­able.

We were taught that gen­er­al­ists and spe­cial­ists will al­ways have their roles. But now the mar­ket is shap­ing every­one into be­com­ing a gen­er­al­ist. That’s not a bad thing per se, un­til you look un­der the eco­nom­ics of sup­ply and de­mand: if every­one is a gen­er­al­ist, the price of a gen­er­al­ist falls if there’s no de­mand to match. And we all know the de­mand is dry­ing up.

The third pil­lar, the one that has­n’t eroded yet: code qual­ity and ar­chi­tec­ture

I still have one pil­lar stand­ing, though: code qual­ity and soft­ware ar­chi­tec­ture - what’s now be­ing re­duced to be­ing called “taste” 1.

Along the course of my ca­reer, I al­ways liked to refac­tor, al­ways prized good code, and ne­go­ti­ated time in the sprint for it. DDD, Hexagonal, Clean Architecture, you know all the buzz­words. I like this topic, I like to dis­cuss the trade-offs and dif­fer­ent ideas on how to shape code­bases. I re­ally like it.

This is the last pil­lar stand­ing. Except that no­body cares any­more.

Agents do a re­ally bad job at keep­ing code­bases or­ga­nized. If you don’t steer them, they’ll hit a cir­cu­lar de­pen­dency is­sue sooner than you think. Will du­pli­cate code. Add un­nec­es­sary com­ments. Mix up pure func­tions and side-ef­fects. Disregard the prin­ci­ples of SOLID.

That should keep hu­mans em­ployed, ex­cept that this skill is now be­ing re­duced to the word “taste”. But it’s not just a re­nam­ing, the in­dus­try is mov­ing to a world where code or­ga­ni­za­tion is less im­por­tant.

Sure, hu­mans should steer the agent to pre­vent spaghetti code­bases with cir­cu­lar de­pen­dency graphs. We don’t want F-rated code­bases that are im­pos­si­ble to touch with­out break­ing some­thing. But a C or D? It’s now fine. Nobody needs A or B-grade code­bases any­more be­cause they’re be­ing made for LLMs, not for hu­mans to read.

I don’t want to ar­gue if this is in­her­ently good or bad. If the source code is now writ­ten for ma­chines to read and not hu­mans, it may be ac­tu­ally ok to tar­get them.

But that’s an­other pil­lar of my ex­per­tise that’s erod­ing. A good chunk of the knowl­edge I ac­cu­mu­lated on that topic is not that valu­able any­more. All the time I spent on it - read­ing books, do­ing real-world ex­er­cises, dis­cussing with other en­gi­neers, writ­ing ADRs - is be­com­ing use­less.

What now?

I’m still em­ployed and I see my­self em­ployed (at least in that com­pany) for a fore­see­able fu­ture. But I don’t know what to think about the long-term.

I spent 10 years (even more when you ac­count for non-pro­fes­sion ex­pe­ri­ence) get­ting good at things that are be­com­ing less and less valu­able. My last pil­lar of ex­per­tise is now re­duced to a “taste” and will prob­a­bly won’t last long.

And I know that’s not just me. About 8 months ago there was a lay­off at my cur­rent com­pany (not re­lated to AI, ac­cord­ing to them). Some bril­liant ex-cowork­ers were laid off and are still look­ing for jobs. Most of them suf­fer from the same prob­lem I out­lined here: their do­main ex­per­tise is not enough to stand out any­more.

The com­pany is now hir­ing again for a few roles and do­main fa­mil­iar­ity is not a strong dif­fer­en­tia­tor any­more. We used to list “Software Engineer - Area”. Now it’s just “Software Engineer” and the team as­sign­ment comes af­ter the of­fer is ac­cepted.

Of course, this is good for bril­liant en­gi­neers that never had the chance to get deep into the do­main and now have bet­ter chances at get­ting a job, but it’s also sad to think that other bril­liant en­gi­neers that spent their lives col­lect­ing do­main knowl­edge are now com­pet­ing on the same lane.

The only way out for keep­ing my em­ploy­a­bil­ity in the long-term now seems to be shift­ing my do­main ex­per­tise to some­thing LLMs will not get good at so eas­ily. But what’s left?

I thought about go­ing back to col­lege, learn­ing Math, Statistics, ad­vanced Machine Learning and ap­ply­ing for re­search role at a fron­tier lab. Except that there are no fron­tier labs in my coun­try, the few ones that ex­ist are flood­ing with ap­pli­ca­tions and I have fam­ily mat­ters that makes mov­ing to an­other coun­try dif­fi­cult. By the time I can af­ford to make that jump, RSI may have made re­searchers ob­so­lete.

Maybe I should con­sider trans­form­ing my wood­work­ing hobby into a pro­fes­sion…

Update (Jun 7): this post went vi­ral. I wrote an­other post re­ply­ing to some com­ments from so­cial me­dia and ex­pand­ing some of my ar­gu­ments. You can read it here.

See this, this and this for ref­er­ence. Don’t take this as an en­dorse­ment of the con­tent in­side any of these posts.↩

See this, this and this for ref­er­ence. Don’t take this as an en­dorse­ment of the con­tent in­side any of these posts.↩

#ai

#llm

#software en­gi­neer­ing

Preflight Checklist

I have searched ex­ist­ing re­quests and this fea­ture has­n’t been re­quested yet

This is a sin­gle fea­ture re­quest (not mul­ti­ple fea­tures)

Problem Statement

Preflight note. The clos­est open is­sue is #40347. Related: #47316 (closed), #38276 (closed as out of scope for this repo), #36011 (stale). I am fil­ing this as a con­sol­i­da­tion and ex­ten­sion of #40347 with cor­rected tech­ni­cal fram­ing (Claude Code plu­gin de­vel­op­ment against Desktop ex­ten­sions), named pri­mary sourc­ing for the Cowork Linux-VM ar­chi­tec­ture, and cur­rent mar­ket data. Happy to merge into #40347 if main­tain­ers pre­fer; please route rather than close if a dif­fer­ent venue is cor­rect.

On scope: this is­sue con­cerns Claude Code in two con­crete ways. (1) Claude Code plu­g­ins are de­vel­oped and tested against Claude Desktop ex­ten­sions, which has no Linux build, so plu­gin work cur­rently re­quires switch­ing OS. (2) Cowork in­vokes the Claude Code bi­nary in­side a Linux VM on ma­cOS, so the Linux ex­e­cu­tion path al­ready ex­ists in­side the Claude Code prod­uct and is the prac­ti­cal thing miss­ing as a pub­lished tar­get.

What this is­sue is ask­ing for A pub­lic Anthropic po­si­tion on Linux desk­top sup­port, and ide­ally a first-party build. A rea­soned “not on the cur­rent roadmap, and here is why” would re­solve most of what this is­sue is about. There is, to my knowl­edge, no pub­lic state­ment on Linux desk­top sup­port; the ab­sence is it­self part of the prob­lem.

Current state

Anthropic dis­trib­utes Claude Desktop for ma­cOS and Windows only. The of­fi­cial down­load page states “Not avail­able for Linux”. Claude Code (the CLI) runs na­tively on Linux but is a ter­mi­nal tool, not a sub­sti­tute for the desk­top GUI. Desktop ex­ten­sions (the sur­face Claude Code plu­g­ins are tested against), com­puter use, desk­top dic­ta­tion and Cowork are avail­able only in Claude Desktop. Linux users there­fore have no of­fi­cially sup­ported graph­i­cal path to these ca­pa­bil­i­ties, and in par­tic­u­lar no way to de­velop and test Claude Code plu­g­ins as desk­top ex­ten­sions with­out switch­ing to ma­cOS or Windows.

Why this is struc­turally hard to jus­tify Anthropic al­ready builds, signs and dis­trib­utes Linux soft­ware. Per code.claude.com/​docs/​en/​setup, Claude Code ships signed apt, dnf and apk repos­i­to­ries and per-ar­chi­tec­ture bi­na­ries (linux-x64, linux-ar­m64, musl vari­ants). The pipeline ex­ists.

The Cowork agent al­ready de­pends on Linux in­side the prod­uct. Independent re­verse-en­gi­neer­ing by Simon Willison on launch day (12/01/2026), cor­rob­o­rated by Pluto Security and pvieito (“Inside Claude Cowork”), found that on ma­cOS Cowork boots a cus­tom Ubuntu 22.04 VM via Apple’s Virtualization Framework (VZVirtualMachine) and runs the Claude Code bi­nary in­side it un­der bub­blewrap and sec­comp. Anthropic’s own doc­u­men­ta­tion con­firms the hy­per­vi­sor split: Apple Virtualization.framework on ma­cOS, Hyper-V on Windows. The com­mu­nity pro­ject johnz­fitch/​claude-cowork-linux demon­strates the same Cowork mode run­ning na­tively on Linux x86_64 by stub­bing the ma­cOS na­tive mod­ules and skip­ping the VM en­tirely. The Linux ca­pa­bil­ity al­ready ex­ists in­side the prod­uct; what’s miss­ing is a pub­lished Linux tar­get.

Why it mat­ters that it is miss­ing Claude Desktop han­dles OAuth to­kens, API keys, and ex­ten­sion con­fig­u­ra­tions. It is a cre­den­tial-han­dling ap­pli­ca­tion run­ning on de­vel­oper work­sta­tions.

Linux users cur­rently ob­tain it via third-party repack­ages of the Windows Electron build. The lead­ing pro­ject, aad­drick/​claude-desk­top-de­bian (roughly 4.5k stars), is gen­uinely high qual­ity: signed apt and dnf repos­i­to­ries, .deb/.rpm/AppImage/AUR/Nix builds, CI-tested, a –doctor di­ag­nos­tic, and up­stream track­ing within days (latest re­lease 05/06/2026, track­ing Claude Desktop 1.11187.1). It is also, by de­f­i­n­i­tion, not ven­dor-signed and not ven­dor-au­dited. A non-triv­ial num­ber of Claude users en­trust their cre­den­tials and lo­cal filesys­tem ac­cess to a third-party repack­age be­cause Anthropic ships noth­ing of­fi­cial. The struc­tural risk is not about the cur­rent main­tain­ers; it is the prece­dent on a plat­form Anthropic’s own agent run­time de­pends on.

Linux is not a fringe de­vel­oper plat­form. Stack Overflow 2025 (49,000+ re­spon­dents, 177 coun­tries): Ubuntu pri­mary OS for 27.7% of pro­fes­sional de­vel­op­ers. StatCounter: India desk­top Linux 16.21% (July 2024); US crossed 5% in June 2025.

Proposed Solution

Publish an of­fi­cial Claude Desktop build for Linux, tar­get­ing the two cur­rent Ubuntu LTS re­leases (and Debian) as a signed .deb via an Anthropic-operated apt repos­i­tory, us­ing the same dis­tri­b­u­tion pipeline Claude Code al­ready uses for Linux.

Alternative Solutions

Claude Code CLI: of­fi­cial and runs na­tively on Linux with signed apt/​dnf/​apk repos­i­to­ries. Excellent for ter­mi­nal work­flows and runs lo­cal MCP servers fine. Not a sub­sti­tute for the desk­top GUI: no sur­face for test­ing Claude Code plu­g­ins as desk­top ex­ten­sions, no com­puter use, no Cowork.

Web client (claude.ai): sup­ports re­mote MCP con­nec­tors but no desk­top ex­ten­sions, no com­puter use, no Cowork. Loses con­ver­sa­tion state on browser crash; higher RAM and bat­tery cost than a na­tive client.

Community repack­ages (aaddrick/claude-desktop-debian, johnz­fitch/​claude-cowork-linux, Snap wrap­pers, k3d3 NixOS flake): func­tional and what I cur­rently use. Unofficial, not ven­dor-signed, not ven­dor-au­dited.

Windows build un­der Wine: clip­board and font in­te­gra­tion break, MCP sub­process han­dling is un­re­li­able, no first-party se­cu­rity up­dates.

Switching to ma­cOS or Windows to test plu­g­ins: cur­rent workaround. Friction on every it­er­a­tion; not a real fix.

Priority

High - Significant im­pact on pro­duc­tiv­ity

Feature Category

Developer tools/​SDK

Use Case Example

I run Ubuntu LTS as my pri­mary de­vel­op­ment en­vi­ron­ment. Per the Stack Overflow 2025 Developer Survey, this is the case for 27.7% of pro­fes­sional de­vel­op­ers.

I run Ubuntu LTS as my pri­mary de­vel­op­ment en­vi­ron­ment. Per the Stack Overflow 2025 Developer Survey, this is the case for 27.7% of pro­fes­sional de­vel­op­ers.

I de­velop Claude Code plu­g­ins. Plugins are tested and it­er­ated on as Claude Desktop ex­ten­sions, which re­quires Claude Desktop. There is no Linux build.

I de­velop Claude Code plu­g­ins. Plugins are tested and it­er­ated on as Claude Desktop ex­ten­sions, which re­quires Claude Desktop. There is no Linux build.

The cur­rent workaround is to switch to ma­cOS every time I need to test a plu­gin as an ex­ten­sion. This is fric­tion on every it­er­a­tion of a plu­gin I am build­ing on Linux, and a suf­fi­ciently bad er­gonomic that it dis­cour­ages plu­gin de­vel­op­ment from Linux en­tirely.

The cur­rent workaround is to switch to ma­cOS every time I need to test a plu­gin as an ex­ten­sion. This is fric­tion on every it­er­a­tion of a plu­gin I am build­ing on Linux, and a suf­fi­ciently bad er­gonomic that it dis­cour­ages plu­gin de­vel­op­ment from Linux en­tirely.

With an of­fi­cial Linux build I would in­stall via apt from an Anthropic-signed repos­i­tory and de­velop, test and it­er­ate on Claude Code plu­g­ins as desk­top ex­ten­sions on the same ma­chine I write them on.

With an of­fi­cial Linux build I would in­stall via apt from an Anthropic-signed repos­i­tory and de­velop, test and it­er­ate on Claude Code plu­g­ins as desk­top ex­ten­sions on the same ma­chine I write them on.

Additional Context

Sources for the load-bear­ing claims, named pri­mary where pos­si­ble.

Platform sup­port ma­trix

claude.com/​down­load: “Not avail­able for Linux”.

code.claude.com/​docs/​en/​desk­top: desk­top app avail­able for ma­cOS and Windows.

Claude Code al­ready on Linux

code.claude.com/​docs/​en/​setup: signed apt, dnf and apk repos­i­to­ries; per-plat­form bi­na­ries (linux-x64, linux-ar­m64, linux-x64-musl, linux-ar­m64-musl); Ubuntu 20.04+/Debian 10+.

Cowork Linux-VM ar­chi­tec­ture

Simon Willison, “First im­pres­sions of Claude Cowork”, 12/01/2026 (simonwillison.net): VZVirtualMachine via Apple’s Virtualization Framework boot­ing a cus­tom Linux root filesys­tem.

Simon Willison, “First im­pres­sions of Claude Cowork”, 12/01/2026 (simonwillison.net): VZVirtualMachine via Apple’s Virtualization Framework boot­ing a cus­tom Linux root filesys­tem.

Pluto Security: cor­rob­o­rat­ing re­verse-en­gi­neer­ing deep dive, Ubuntu 22.04 in­side the VM.

Pluto Security: cor­rob­o­rat­ing re­verse-en­gi­neer­ing deep dive, Ubuntu 22.04 in­side the VM.

pvieito, “Inside Claude Cowork”: ma­cOS host → Apple Virtualization Framework → Ubuntu 22.04 VM → bub­blewrap → sec­comp → Claude Code at /usr/local/bin/claude.

pvieito, “Inside Claude Cowork”: ma­cOS host → Apple Virtualization Framework → Ubuntu 22.04 VM → bub­blewrap → sec­comp → Claude Code at /usr/local/bin/claude.

Anthropic doc­u­men­ta­tion con­firms the hy­per­vi­sor split (Apple Virtualization.framework on ma­cOS, Hyper-V on Windows) with­out con­firm­ing the re­verse-en­gi­neered in­ter­nals.

Anthropic doc­u­men­ta­tion con­firms the hy­per­vi­sor split (Apple Virtualization.framework on ma­cOS, Hyper-V on Windows) with­out con­firm­ing the re­verse-en­gi­neered in­ter­nals.

johnz­fitch/​claude-cowork-linux: work­ing com­mu­nity port that stubs the ma­cOS na­tive mod­ules and runs Cowork di­rectly on Linux x86_64 with no VM.

johnz­fitch/​claude-cowork-linux: work­ing com­mu­nity port that stubs the ma­cOS na­tive mod­ules and runs Cowork di­rectly on Linux x86_64 with no VM.

Community pack­ag­ing

aad­drick/​claude-desk­top-de­bian: roughly 4.5k stars; .deb, .rpm, AppImage, AUR, Nix; signed apt and dnf repos­i­to­ries at pkg.claude-desk­top-de­bian.dev; lat­est re­lease v2.0.18+claude1.11187.1 dated 05/06/2026; –doctor di­ag­nos­tic; CI-tested; ex­per­i­men­tal Cowork on Linux.

aad­drick/​claude-desk­top-de­bian: roughly 4.5k stars; .deb, .rpm, AppImage, AUR, Nix; signed apt and dnf repos­i­to­ries at pkg.claude-desk­top-de­bian.dev; lat­est re­lease v2.0.18+claude1.11187.1 dated 05/06/2026; –doctor di­ag­nos­tic; CI-tested; ex­per­i­men­tal Cowork on Linux.

Related: aad­drick/​claude-desk­top-arch, emsi/​claude-desk­top, k3d3/​claude-desk­top-linux-flake.

Related: aad­drick/​claude-desk­top-arch, emsi/​claude-desk­top, k3d3/​claude-desk­top-linux-flake.

Demand

StatCounter: India desk­top Linux 16.21% (July 2024); US crossed 5% in June 2025; global ap­prox­i­mately 4.7% in 2025.

If a first-party build is not on the roadmap

A lower-cost fall­back that would ad­dress most of the trust and se­cu­rity con­cerns: a pub­lic state­ment on the in­stall doc­u­men­ta­tion that Linux is not cur­rently planned (with rough hori­zon if any), ac­knowl­edge­ment of a rec­om­mended com­mu­nity pro­ject, a one-off se­cu­rity re­view sum­mary of that pro­ject, and ex­plicit se­cu­rity guid­ance for Linux users on cre­den­tial han­dling and MCP server con­fig­u­ra­tion.

Steelmanned counter-case

The strongest in­ter­nal “not now”, so this is­sue in­vites a real con­ver­sa­tion rather than a po­lite close.

Volume does not jus­tify the en­gi­neer­ing tax. Cowork par­ity, Windows hard­en­ing and agent ca­pa­bil­ity work all plau­si­bly out­rank a third desk­top plat­form.

Volume does not jus­tify the en­gi­neer­ing tax. Cowork par­ity, Windows hard­en­ing and agent ca­pa­bil­ity work all plau­si­bly out­rank a third desk­top plat­form.

Linux frag­men­ta­tion cre­ates a dis­pro­por­tion­ate sup­port tax: dis­tros, dis­play servers, sand­box­ing mod­els, graph­ics stacks. The com­mu­nity pro­jec­t’s com­mit log shows the sur­face (AppArmor userns blocks, KDE Plasma SNI races, Wayland HiDPI, eCryptfs path-length fail­ures).

Linux frag­men­ta­tion cre­ates a dis­pro­por­tion­ate sup­port tax: dis­tros, dis­play servers, sand­box­ing mod­els, graph­ics stacks. The com­mu­nity pro­jec­t’s com­mit log shows the sur­face (AppArmor userns blocks, KDE Plasma SNI races, Wayland HiDPI, eCryptfs path-length fail­ures).

Enterprise Linux de­vel­op­ers are largely served by re­mote de­vel­op­ment and the CLI. A desk­top GUI may not un­lock en­ter­prise rev­enue pro­por­tion­ate to its cost.

Enterprise Linux de­vel­op­ers are largely served by re­mote de­vel­op­ment and the CLI. A desk­top GUI may not un­lock en­ter­prise rev­enue pro­por­tion­ate to its cost.

Opportunity cost. Every en­gi­neer-quar­ter on Linux desk­top is a quar­ter not on agent qual­ity, MCP ecosys­tem, Cowork hard­en­ing, or en­ter­prise con­trol planes.

Opportunity cost. Every en­gi­neer-quar­ter on Linux desk­top is a quar­ter not on agent qual­ity, MCP ecosys­tem, Cowork hard­en­ing, or en­ter­prise con­trol planes.

Distribution is non-triv­ial. Signed re­pos, GPG keys, AppImage sign­ing, Snap, AUR, Nix.

Distribution is non-triv­ial. Signed re­pos, GPG keys, AppImage sign­ing, Snap, AUR, Nix.

A rea­son­able se­nior de­ci­sion could weigh these and con­clude “not on the cur­rent roadmap”. I would un­der­stand that. What I do not un­der­stand is the ab­sence of any pub­lic po­si­tion at all, and the struc­tural se­cu­rity cost of that si­lence to cur­rent Linux users.

Note on the triage bot

I am aware this is­sue is processed by an au­to­mated triage sys­tem. I have writ­ten it as a sin­gle con­sol­i­dated re­quest with a clear pri­mary ask and a lower-cost fall­back (the “good no” path in Additional Context). Please route rather than close if a dif­fer­ent venue is cor­rect; please re­spond rather than close as “not planned” with­out a stated ra­tio­nale, be­cause the ab­sence of a stated ra­tio­nale is part of what this is­sue is ask­ing to fix.

Happy to con­tribute and help main­tain.

Twenty Ninth International Obfuscated C Code Contest

Where to start

See be­low for links to the 2025 win­ning IOCCC en­tries.

Check out the in­dex.html web pages for each win­ning en­try. They have most of the in­for­ma­tion you need to com­pile and run the win­ning pro­gram. Take a look at the win­ning source code and try to fig­ure out how it works. You might also want to check out the au­thor’s re­marks for even more de­tails.

You may down­load all win­ning en­tries in the form of a com­pressed tar­ball for this year’s con­test.

For IOCCC29, the vol­ume and qual­ity of sub­mis­sions were at near-his­toric heights.

IOCCC28 was spec­u­lated to have at­tracted a record num­ber of sub­mis­sions due to the 4-year ab­sence, al­low­ing au­thors to re­fine their sub­mis­sions, re­sult­ing in a higher-than-usual sub­mis­sion qual­ity.

IOCCC29 was the sec­ond con­sec­u­tive con­test af­ter the 2020 – 2024 hia­tus. And yet, the num­ber of sub­mis­sions for IOCCC29 was sim­i­lar to last year’s con­test, and the over­all sub­mis­sion qual­ity re­mained high for this con­test. So per­haps the in­creased sub­mis­sion vol­ume, com­bined with a higher-than-usual sub­mis­sion qual­ity, is due to fac­tors such as im­proved web­site de­sign, in­creased so­cial me­dia pres­ence, au­thors build­ing on the ideas of past win­ning en­tries, and other fac­tors?

Starting with the close of IOCCC28, the pro­ce­dures used for clos­ing the con­test to new sub­mis­sions, the judg­ing process, se­lect­ing the win­ning en­tries, prepar­ing the up­date to the web­site, and the process to cre­ate the live show on the Our Favorite Universe were care­fully doc­u­mented. And while this doc­u­men­ta­tion re­quired ad­di­tional time as well as more ef­fort, the doc­u­men­ta­tion process re­sulted in over­all im­prove­ments to how the IOCCC is run.

A few days af­ter the pre­sen­ta­tion of the win­ning en­tries for IOCCC29 has been made on the Our Favorite Universe YouTube chan­nel. The record­ing of the main show will be di­vided up into in­di­vid­ual seg­ments. Then, each win­ning en­try will be up­dated to in­clude a link to a YouTube seg­ment un­der a new Award pre­sen­ta­tion near the top of the win­ning en­try’s in­dex.html page.

Fun chal­lenge info

We have added fun chal­lenges to this year’s win­ning en­tries com­pe­ti­tion, un­der the “Judges’ re­marks” sec­tion. After you fig­ure out what a given win­ning en­try does, we en­cour­age you to at­tempt the fun chal­lenge.

Some of these chal­lenges are eas­ier than oth­ers. In some cases, you’re asked to cre­ate an al­ter­na­tive ver­sion of prog.c or a re­lated file. In some cases you are asked to pro­duce an ex­pla­na­tion about some­thing.

If the fun chal­lenge is still open (check the “A fun chal­lenge” sec­tion for the given win­ning en­try), con­sider sub­mit­ting a GitHub pull re­quest as a con­tri­bu­tion.

If the fun chal­lenge is closed, but you think you have a bet­ter so­lu­tion, con­sider sub­mit­ting a GitHub pull re­quest as a con­tri­bu­tion. If the IOCCC Judges agree that you so­lu­tion is bet­ter, we will con­sider it.

If you be­lieve you have an even bet­ter (or im­prove­ment) to win­ning en­try’s fun chal­lenge, please con­sider sub­mit­ting a GitHub pull re­quest, for the IOCCC judges to con­sider.

Rules and Guidelines for this con­test

The fi­nal ver­sions of the IOCCC rules and guide­lines that were in ef­fect for this con­test were:

2025 rules ver­sion 29.15 2025 – 12-02

2025 guide­lines ver­sion 29.08 2025 – 12-02

The IOCCC rules and guide­lines for IOCCC29 rep­re­sented a sub­stan­tial rewrite over pre­vi­ous con­tests, thanks in part to a num­ber of vol­un­teers: giv­ing the IOCCC judges use­ful ed­its, text rewrites, con­sol­i­da­tion, as well as over­all im­proved or­ga­ni­za­tion.

Looking for­ward to the next con­test

We plan to open IOCCC30 to­wards the end of 2026 and have the con­test run for a sim­i­lar amount of time, clos­ing some­time to­wards the end of Q1 2027.

As we per­form the ac­tions needed to open IOCCC30, we plan to in­ter­nally doc­u­ment the process as we did dur­ing the clos­ing of IOCCC29.

About two or three weeks af­ter the IOCCC29 win­ning en­tries have been posted, and we process some of the early pull re­quests against the 2025 di­rec­tory tree, the IOCCC Judges plan to go on an IOCCC va­ca­tion.

We had in­tended to go on an IOCCC va­ca­tion af­ter re­leas­ing the win­ners of IOCCC28, but then the ef­forts to process bug fixes and en­hance­ments to the mkioc­c­cen­try repo took so much time that by the time that repo was sta­ble, it was time to open IOCCC29. Therefore, this time, we plan to wait un­til af­ter the end of our post-IOC­C­C29 IOCCC va­ca­tion be­fore work­ing on any mkioc­c­cen­try repo PRs.

While work­ing on cre­at­ing po­ten­tial write-ups for sub­mis­sions that en­tered the fi­nal round of the set of judg­ing rounds:

A few sub­mis­sions were set aside in the fi­nal round of the fi­nal set of rounds.

We gained an ad­di­tional level of ap­pre­ci­a­tion for a num­ber of the re­main­ing en­tries.

While the win­ning en­try au­thors came from lo­ca­tions of pre­vi­ous win­ning au­thors, this IOCCC29 had an au­thor - jing­p49 from a new lo­ca­tion: Taiwan.

This con­test saw a Hat trick of Hat-tricks by:

Yusuke Endoh: 2025/endoh1, 2025/endoh2, and 2025/endoh3

Nick Craig-Wood: 2025/ncw1, 2025/ncw2, and 2025/ncw3

Don Yang: 2025/yang1, 2025/yang2, and 2025/yang3

Notable and re­mark­able win­ning en­tries of IOCCC29 in­clude, but are not lim­ited to:

2025/cable - Subleq com­puter

2025/cesmoak - Black hole punch­card Fortran

2025/endoh3 - patch/​diff quine

2025/jhshrvdp - Quasi-rogue-like game

2025/jingp49 - Dr. WHO se­quence

2025/ncw1 - GameBoy em­u­la­tor

2025/tompng - Ocean sound gen­er­a­tor

2025/uellenberg - Quine pong

2025/yang2 - Zoltraak en­cod­ing

Those are just a few of the many amaz­ing win­ners of the IOCCC29, so be sure to check out the rest!

As we dis­cussed above, there were quite a few ex­cel­lent sub­mis­sions that did­n’t quite make the fi­nal cut. We truly ap­pre­ci­ate the hard work each au­thor put into their en­tries, but we’re sorry that we can’t award based solely on ef­fort.

We re­ceived many great sub­mis­sions that did­n’t quite make the cut as win­ners. If you sub­mit­ted some­thing for IOCCC29 that did­n’t win, think about pol­ish­ing your code and giv­ing it an­other shot for IOCCC30. Interestingly, more than one win­ner of IOCCC29 was ac­tu­ally an im­proved ver­sion of code that did­n’t win in a pre­vi­ous con­test.

Encouragement for those who did not win this year

We know many of you that sub­mit­ted to the IOCCC put in a ton of ef­fort into your sub­mis­sions for this year’s IOCCC. We can’t just give out awards to every­one. That would mean tak­ing away from the sub­mis­sions that we think are the best and de­serve to win.

Sometimes, a fi­nal round sub­mis­sion might be good enough to be a win­ning IOCCC en­try, only to be beaten by a sim­i­lar, but slightly bet­ter sub­mis­sion. If you think this hap­pened with your sub­mis­sion, con­sider sub­mit­ting an en­hanced ver­sion to the next IOCCC.

PLEASE DO NOT give up hope! There are some sub­mis­sions that have been sub­mit­ted with re­vi­sions, mul­ti­ple times be­fore ris­ing to the level of a win­ning IOCCC en­try. You might also want to try with a dif­fer­ent type of sub­mis­sion al­to­gether for the next IOCCC.

If you’re not plan­ning to im­prove and re­sub­mit your non-win­ning en­try for the next IOCCC, you’re wel­come to pub­lish it.

On com­pil­ing and run­ning win­ning en­tries

Some C com­pil­ers aren’t as great as they could be. If yours is­n’t work­ing well, you might want to try com­pil­ing with an up­dated ver­sion of clang and/​or gcc in­stead.

If you en­counter prob­lems in com­pil­ing and/​or run­ning the win­ning en­tries, see the FAQ on:

Compiling IOCCC en­tries

IOCCC en­try de­pen­den­cies

Problems com­pil­ing en­tries

Running IOCCC en­tries

For ad­di­tional in­for­ma­tion on how to sub­mit fixes, see the FAQ on:

How to sub­mit a fix - how to sub­mit a fix to an en­try

Update au­thor in­for­ma­tion - how to cor­rect or up­date an IOCCC au­thor’s in­for­ma­tion

For even more in­for­ma­tion

Reporting an IOCCC web­site prob­lem

Submitting a fix to the IOCCC web­site

How to con­tact the IOCCC - up-to-date con­tact de­tails

IOCCC FAQ - ad­di­tional in­for­ma­tion on the IOCCC

www.ioccc.org - the pri­mary IOCCC web­site

Winning Entries of 2025 - The 29th IOCCC

Download all win­ning en­tries from 2025

2025/ayu - IMO award

2025/cable - Best imag­i­nary em­u­la­tor

2025/cesmoak - Retro space award

2025/diels-grabsch - Best one liner

2025/dogon - Consistently con­stant award

2025/endoh1 - Most likely to daz­zle

2025/endoh2 - Most likely to shock

2025/endoh3 - Most re­silient

2025/ferguson - Opposite award

2025/howe - Most likely to in­vade

2025/jhshrvdp - Most likely to tele­port

2025/jingp49 - Who won award

2025/kurdyukov - Most likely to count

2025/mattpep - Most ob­fus­cated op­tions

2025/ncw1 - Best real em­u­la­tor

2025/ncw2 - Best frac­tional em­u­la­tor

2025/ncw3 - Best use of Unicode

2025/tompng - Most sooth­ing

2025/uellenberg - Ping pong prize

2025/yang1 - Compound prize

2025/yang2 - Most mag­i­cal word

2025/yang3 - INABIAF award

Jump to: top

Five lead­ing sci­en­tists were ousted from the an­nual meet­ing of the American Diabetes Association (ADA) in New Orleans on Friday. Their crime: hand­ing out copies of an ed­i­to­r­ial, pub­lished in the jour­nal Diabetes Care on April 29, sharply crit­i­ciz­ing the Trump ad­min­is­tra­tion’s on­go­ing at­tacks on sci­en­tific re­search.

Those ousted were Steven Kahn, pro­fes­sor of med­i­cine at the University of Washington and ed­i­tor-in-chief of Diabetes Care, who co-au­thored the pub­lished ed­i­to­r­ial; for­mer ADA pres­i­dent Desmond Schatz of the University of Florida, Gainesville; Aaron Kelly, pe­di­atrics pro­fes­sor at the University of Minnesota; Justin Ryder of Northwestern University; and Irl Hirsch, also of the University of Washington. The five were hand­ing out reprints of the ed­i­to­r­ial out­side a room where NIH di­rec­tor Jay Bhattacharya had been sched­uled to speak. Bhattacharya can­celled and an­other NIH of­fi­cial spoke in his stead.

“They phys­i­cally grabbed us, forced us out of the con­fer­ence cen­ter, and now are telling us we can no longer at­tend this meet­ing,” Kelly told MedPage Today, which first re­ported the in­ci­dent. “They’re tak­ing our lan­yards. It re­ally has come to this in America. Censorship is real. America needs to stand up. Scientists, stand up. Physicians, stand up.”

The ADA con­firmed to MedPage Today that five reg­is­tered sci­en­tists had been re­moved from the meet­ing, claim­ing the sci­en­tists had vi­o­lated the or­ga­ni­za­tion’s code of con­duct for con­fer­ences. “These at­ten­dees were es­corted out by our on­site event se­cu­rity be­cause they demon­strated be­hav­ior not con­sis­tent with this code of con­duct,” the ADA me­dia team said in a state­ment. “They were re­spect­fully given the op­por­tu­nity to cease this be­hav­ior and chose not to which is why they were es­corted out.”

“All at­ten­dees will con­duct them­selves in a pro­fes­sional and re­spect­ful man­ner, free from any form of dis­crim­i­na­tion, ha­rass­ment, or in­tim­i­da­tion,” the code of con­duct states. “Inappropriate con­duct, in­clud­ing but not lim­ited to ha­rass­ment; threat­en­ing or un­wel­come phys­i­cal or ver­bal ac­tions; or dis­or­derly or dis­rup­tive con­duct such as protest­ing, will not be tol­er­ated.”

I am not sure i am in the right place but we are all out of op­tions here since we could­n’t get any help from the game or steam sup­port.

Since around the 13/03, there is a ma­jor sys­temic prob­lem in every game that uses Steam Networking for P2P games.

For ex­am­ple, in the game Street Fighter 6, when play­ing with one Israeli or an­other with PC to PC the ping be­tween play­ers are ~120ms. when play­ing with European play­ers the ping is around 60 – 80ms which means it works well, it cur­rently af­fects only Israeli play­ers when play­ing PC to PC. Since Street Fighter 6 sup­ports cross-play we have tried play­ing PC to PS5 and the ping is a flaw­less 5 – 10ms.

It cur­rently af­fects all play­ers in Israel, we have a few dozens in our com­mu­nity with sev­eral ISPs, we have of course at­tempted speak­ing to our ISPs and port for­ward­ing and we have found no net­work is­sues on their part. in other P2P games that don’t use steam net­work­ing the is­sue is not ex­is­tent(for ex­am­ple, Tekken 8).

We are cur­rently don’t know what we can do with this is­sue since noth­ing we have done have helped and 120ms is too high for it to be playable in any P2P game.

While I can’t con­firm but heard re­ports from play­ers in other mid­dle east­ern coun­tries like Egypt that they also re­port on this is­sue so it could be re­gion-wide.

Part of Teaching an AI Agent to Make Beautiful Charts

A fresh col­lege de­gree used to come with a quiet edge in the job mar­ket. New grads had bet­ter odds of land­ing work than the av­er­age worker, and that edge held for as long as any­one tracked it. Not any­more. They now face higher un­em­ploy­ment than the work­force as a whole, and the gap is the widest on record.

What makes this strange is the tim­ing. The re­ver­sal did not start with ChatGPT, and it did not start with the pan­demic. It started in early 2019, be­fore ei­ther one was on the radar.

The chart tracks a sin­gle num­ber, a re­cent grad’s un­em­ploy­ment rate mi­nus the rate for all work­ers. Below the zero line grads come out ahead of the typ­i­cal worker, and above it they fall be­hind.

The com­par­i­son is worth pin­ning down. “All work­ers” is the whole U.S. la­bor force, and most of them are older and more ex­pe­ri­enced than a new grad­u­ate, so a fresh grad starts at a nat­ural dis­ad­van­tage. For decades the de­gree more than can­celed that dis­ad­van­tage out. Now it does not.

For decades, the de­gree was a buffer

A re­cent grad al­most al­ways had a bet­ter shot at be­ing em­ployed than the av­er­age worker. The cush­ion was real, and it was biggest ex­actly when the econ­omy was worst.

The edge peaked in the depths of the Great Recession. In mid-2010, grads were around 7% un­em­ploy­ment while the work­force over­all ran close to 10%, the widest that ad­van­tage ever got. Recessions gut con­struc­tion and man­u­fac­tur­ing first, sec­tors that lean heav­ily on work­ers with­out de­grees, so a diploma was worth the most pre­cisely when jobs were van­ish­ing.

The edge van­ished in 2019, be­fore AI and be­fore COVID

In February 2019 the gap crossed zero, and the 12-month av­er­age has stayed pos­i­tive every month since. That tim­ing rules out both of the easy ex­pla­na­tions. The flip pre­dates the gen­er­a­tive-AI boom by years, and COVID by a year.

This was a slow struc­tural drift, not a sud­den shock. The Cleveland Fed traces the ero­sion back fur­ther still. The job-find­ing ad­van­tage of young grads has been fad­ing since around 2000, and their edge over high-school work­ers closed around 2019. The pan­demic did not cause it ei­ther, and the 2020 spike is the clear­est ev­i­dence. When un­em­ploy­ment ex­ploded that year, both lines shot up to­gether, so the gap held roughly steady through 2020 and 2021. The penalty was al­ready there. The lock­downs just buried it un­der a big­ger num­ber.

Now it is the widest gap on record

By early 2026 re­cent grads sat at 5.6% un­em­ploy­ment against 4.2% for all work­ers, the widest gap on record. The spread has grown in al­most every year since the 2019 flip.

What makes the record stranger is the back­drop. This is not a re­ces­sion story. Overall un­em­ploy­ment sits at a healthy 4.2%, yet new grads are the ones strug­gling. Every ear­lier spike in their un­em­ploy­ment ar­rived with a broad down­turn. This one is theirs alone.

Unemployment is only half the pic­ture. Of the new grads who do have jobs, about 41% are un­der­em­ployed, work­ing roles that never re­quired a de­gree in the first place.

Remote work, or AI?

So what broke? The hon­est an­swer is that econ­o­mists are still ar­gu­ing about it. In June 2026 the New York Fed made the case that re­mote work, not AI, is the main cul­prit, pin­ning about 64% of the rise in young-grad un­em­ploy­ment on it. Employers, the Fed ar­gues, are wary of hir­ing in­ex­pe­ri­enced peo­ple into re­mote roles, where the on-the-job men­tor­ship that turns a new grad into a pro­duc­tive worker is hard to de­liver. The tim­ing fits, since the climb started well be­fore AI took hold.

Stanford re­searchers see AI’s fin­ger­prints any­way. Their study found that early-ca­reer work­ers ages 22 to 25 in the most AI-exposed jobs saw em­ploy­ment fall about 16% since late 2022, a drop that sur­vived even af­ter they stripped out re­mote-friendly roles. Both can be true. Either way, the en­try-level rungs are the ones be­ing pulled out, and tech is the sharpest edge. Recent com­puter sci­ence grad­u­ates now post some of the high­est un­em­ploy­ment rates of any ma­jor, af­ter the num­ber of CS de­grees more than dou­bled into a shrink­ing pile of open­ings.

The on-ramp broke, not the de­gree

This is an en­try-level prob­lem, not proof that a de­gree stopped pay­ing off. Older de­gree-hold­ers are do­ing fine. U.S. work­ers 25 and up with a bach­e­lor’s or more had just 2.8% un­em­ploy­ment in April 2026, per the Bureau of Labor Statistics, com­fort­ably be­low the rate for high-school grads. The dam­age is con­cen­trated al­most en­tirely in the young. Since 2019, re­cent grads have taken the brunt of the rise while un­em­ploy­ment for older de­gree-hold­ers has barely moved, per the St. Louis Fed, and the New York Fed still pegs the life­time re­turn on a de­gree near 12.5%.

New grads have not fallen be­hind their peers who skipped col­lege, ei­ther. Young work­ers with­out a de­gree sit at 7.2% un­em­ploy­ment, well above the grads’ 5.6%. A de­gree still beats no de­gree. What it no longer does is beat the av­er­age.

None of this is set­tled. The Economic Policy Institute ar­gues the pic­ture is more mixed, with the col­lege wage pre­mium flat for years and new grads still do­ing no worse than young work­ers with­out de­grees. The de­gree still opens the door. It just no longer gets you through it faster than every­one else.

How this chart was made

This chart was built by an AI agent and graded against the Tufte Test, a data vi­su­al­iza­tion qual­ity stan­dard built by Goodeye Labs on Truesight.

Data source: The Labor Market for Recent College Graduates from the Federal Reserve Bank of New York, built from the U.S. Census Bureau and Bureau of Labor Statistics Current Population Survey. “Recent grad­u­ates” are non­stu­dents ages 22 to 27 with at least a bach­e­lor’s de­gree, “young work­ers” are ages 22 to 27 with­out one, and “all work­ers” are ages 16 to 65. The cleaned dataset is avail­able here.

Explore our hand-picked col­lec­tion of 11,082 out-of-copy­right works, free for all to browse, down­load, and reuse. This is a liv­ing data­base with new im­ages added every week.

For a long time I was skep­ti­cal of LLMs—whenever I reached for them I was dis­ap­pointed by the re­sults. Last year I tried Copilot and Cursor to tweak a game I’d built, and nei­ther gen­er­ated work­ing changes. At a pre­vi­ous job I tried Gemini to out­line prod­uct briefs and gen­er­ate wire­frames, but ended up throw­ing them all away. Every time I tried LLMs it was for some­thing I was al­ready good at, and they did a worse job than I would have.

Having joined Jane Street this past sum­mer, I’m find­ing AI sup­port in­dis­pens­able. There’s just so much that’s new to me, and so much I’m not good at yet, like OCaml and Bonsai. But one big sur­prise is how much it’s changed the thing I’m best at: my de­sign work­flow.

Instead of la­bor­ing over spec docs, build­ing Figma mock­ups, writ­ing pro­pos­als, and re­view­ing the im­ple­men­ta­tion with devs, I find my­self build­ing pro­to­type fea­tures that just do the ex­act thing I have in mind. What that looks like in prac­tice is:

Write some­thing de­scrib­ing the prob­lem and my pro­posal

Open my ed­i­tor, start a build, the server, and Claude, us­ing that de­scrip­tion I wrote as the prompt

Get the ba­sic func­tion­al­ity work­ing to prove to my­self that it’s pos­si­ble

Iterate on that as much as I want

Push changes to a de­vel­op­ment en­vi­ron­ment and ask users what they think

Submit a fea­ture (our ver­sion of a pull re­quest) that looks and be­haves ex­actly the way I want

A pro­to­type fea­ture in the ac­tual code­base has felt bet­ter in al­most every way com­pared to mock­ups and docs. Take a pro­to­type I made re­cently that added LLM prompt­ing to a JSQL in­put (JSQL is an in­ter­nal SQL di­alect that we use for lots of dif­fer­ent user-fac­ing tools). This pro­to­type re­ally works, and I spent days liv­ing with it and test­ing it. Claude gave me free, un­lim­ited it­er­a­tion, un­both­ered when I changed my mind for the 50th time or asked for a small tweak. I re­fined the Submit but­ton, added key­board short­cuts, tweaked copy, ad­justed the prompt, and added gen­er­ated con­fir­ma­tion mes­sages. These are work­flow im­prove­ments that would have taken days or weeks of en­gi­neer­ing and de­sign back-and-forth at my pre­vi­ous job, or more likely would just never have hap­pened.

All the ef­fort spent on this fea­ture went into im­prov­ing the real ar­ti­fact, and none on an­cil­lary in-be­tween work like cre­at­ing Figma com­po­nents or for­mat­ting docs.

It took me a while to ar­rive at this work­flow. When I joined last sum­mer, I only ap­proached smaller-sized tasks with AI, like UX pa­per­cut fixes. For big­ger ideas I was still us­ing Figma and docs, and when I tried mak­ing those things with Claude it failed.

But in the past 2 months the sit­u­a­tions where I’ve reached for Figma have fallen off a cliff. Through some com­bi­na­tion of im­proved mod­els, my own fa­cil­ity with them, and care­fully choos­ing the right scope, AI is now work­ing for big stuff too—not just the JSQL prompt but a half dozen other pro­to­types that make user-fac­ing, data model, and li­brary changes, in­clud­ing some that are 2000+ line diffs; I’m us­ing it to im­ple­ment in­ter­ac­tive pro­to­types for brand new apps af­ter de­sign­ing them in Figma; and for some new apps I’m even skip­ping Figma en­tirely, it­er­at­ing on the vi­sual de­sign from the be­gin­ning with Claude.

As a de­signer this has been em­pow­er­ing. Engineers have the abil­ity to cre­ate work­ing proofs of con­cept when they have an idea. Designers have to con­vince other peo­ple to do that for us. For an idea like “direct LLM prompt­ing in the JSQL in­put” I’d be propos­ing some­thing whose fea­si­bil­ity is not even clear at the out­set; get­ting some­one to build a pro­to­type might waste their time. In other cases I might pro­pose some­thing that does­n’t clearly fill a user need. By us­ing Claude to make these ideas real I’m mak­ing it a lot eas­ier for oth­ers to eval­u­ate them—they can just use it.

But there’s a down­side: in this work­flow, the re­viewer is given a fully baked fea­ture. Does that mean they have zero in­put on the func­tion­al­ity and are just sup­posed to re­view the code? Review is not the most fun work—the equiv­a­lent in the de­sign world would be get­ting a de­tailed wire­frame from a PM and be­ing asked to make it look good. I want to make my pro­posal as clearly and com­pletely as pos­si­ble, but I still want my en­gi­neer­ing team­mates to treat it the same way they’d treat a mockup in Figma, as some­thing they and I can it­er­ate on to­gether in de­sign-space.

Our so­lu­tion for now is just to think about these fea­tures dif­fer­ently. I write a short re­minder in the de­scrip­tion: pro­to­types are liv­ing pro­posal docs, the code is dis­pos­able, and a re­view­er’s job is to give feed­back about the de­sign and user ex­pe­ri­ence. Eventually, re­view­ers still take over the idea and im­ple­ment it in a sep­a­rate fea­ture, ref­er­enc­ing the pro­to­type but own­ing the pro­duc­tion code. In prac­tice we’re still fig­ur­ing out what makes sense and feels good with this new work­flow.

There’s also a fear I have that de­sign­ing with Claude keeps me out of a fluid, cre­ative mind­set and stuck in an it­er­a­tive one, con­strained to the out­comes I think Claude can pro­duce. That’s fine for ma­ture tools, where changes are it­er­a­tive, but might mean I miss ideas when work­ing on some­thing new.

This is a fa­mil­iar ten­sion. When I was get­ting started pro­fes­sion­ally in 2011 there was a lot of dis­course about whether de­sign­ers should code. Critics ar­gued that once you’ve started pro­gram­ming you’re less likely to make big changes to an idea. But I liked mak­ing web­sites, and I liked pro­gram­ming, so I kept writ­ing code. Then, when fron­tend frame­works like React be­came com­mon and fron­tend de­vel­op­ment got more com­pli­cated, like oth­ers I de­cided to spe­cial­ize. I still made per­sonal pro­jects in React—that cer­tainly helped me in­ter­act with devs—but I spent al­most all my time at work in Figma and docs.

Had I joined Jane Street be­fore LLMs, I think I would have be­come even more en­trenched in Figma. With JavaScript I at least have some ex­pe­ri­ence; OCaml and Bonsai are en­tirely new, and con­tribut­ing on a tech­ni­cal level would have felt out of reach. Instead I’m back to mak­ing the real thing, and it feels amaz­ing to be work­ing in the medium again. I feel more free than ever to just try things.

Edwin is a de­signer on the op­tions desk at Jane Street.

Motorola has ef­fec­tively bricked its WiFi routers with­out warn­ing, and the is­sue has been on­go­ing for nearly a month, ac­cord­ing to a Mashable in­ves­ti­ga­tion and user com­plaints across the App Store, Amazon, and Reddit.

Sometime around mid-May, Motorola’s MotoSync+ app for iOS and Android went down. On iOS, the MotoSync+ app opens to the lo­gin screen, and a load­ing wheel just spins and spins. On Android, the app also loads to the lo­gin screen but dis­plays a “Server License Expired” mes­sage.

Because the Motorola MotoSync+ app is re­quired to set up all new com­pat­i­ble WiFi routers re­leased by Motorola, many users have been com­pletely blocked from us­ing their routers.

You May Also Like

Some Motorola cus­tomers may also be com­pletely un­aware of the is­sue, as ex­ist­ing router se­tups may con­tinue to work — for now. However, if that user ever needs to fac­tory re­set their router, which Motorola rec­om­mends when ex­pe­ri­enc­ing cer­tain prob­lems, they must use the app to do so, ac­cord­ing to Motorola’s sup­port doc­u­men­ta­tion. Likewise, users with new Motorola routers can only add de­vices, change set­tings, or per­form trou­bleshoot­ing within the MotoSync+ app.

Mashable reached out to Motorola re­peat­edly for this story, but the com­pany has­n’t pro­vided any ex­pla­na­tion for the prob­lems.

A Mashable screen­shot show­ing er­rors with the iOS MotoSync+ app. Credit: Mashable screen­shot

A Reddit user shared this screen­shot from the Android app (personal info ob­scured). Credit: Screenshot cour­tesy of Reddit

Motorola’s net­work­ing prod­ucts and the MotoSync+ app are pro­duced and op­er­ated by Premier LogiTech, LLC, which li­censes the Motorola brand for WiFi prod­ucts.

What’s hap­pen­ing to Motorola routers?

Mashable first no­ticed the is­sue in May shortly af­ter we be­gan test­ing one of Motorola’s lat­est net­work­ing de­vices, the Motorola Q15 WiFi 7 mesh router, which came out late last year and costs be­tween $129.99 and $349.99, de­pend­ing on the con­fig­u­ra­tion.

Luckily, we set up the base router be­fore the MotoSync+ app stopped work­ing, so the router con­tin­ues to work for now. However, we can­not set up the rest of the mesh net­work while the app is un­avail­able.

In com­ments on sites like Reddit and Amazon, an­gry users have left dozens of com­ments about the sit­u­a­tion and the lack of cus­tomer sup­port from Motorola.

Motorola has yet to pub­licly ad­dress the is­sue, and its routers are still be­ing sold on Amazon and at re­tail­ers such as Best Buy. Motorola’s main web­site con­tin­ues to pro­mote its routers on the Motorola Network ecom­merce shop as well.

However, Motorola re­cently re­moved all of its routers and modems from the Motorola Network on­line store, and prod­uct pages now re­turn a 404 “Page not found” er­ror or redi­rect to the home page. An archive of the site shows that Motorola was still sell­ing routers up un­til at least May 18, roughly one week af­ter the app stopped work­ing.

Mashable Light Speed

All of Motorola Network’s prod­ucts have sud­denly been re­moved from sale. Credit: Mashable screen­shot

What are Motorola Network users say­ing?

A Reddit thread about the MotoSync+ app is­sue was orig­i­nally posted on May 12 and has quickly been filled with neg­a­tive com­ments from other un­happy cus­tomers.

“Tried with­out suc­cess to con­tact tech sup­port again yes­ter­day,” said Reddit user u/​Ok_­For­tune_8672. “Unless you are con­tact­ing them about a cell­phone, the lights are out and no­body’s home.”

Consumers have re­sorted to leav­ing neg­a­tive com­ments across Motorola router prod­uct pages on sites like Amazon.

“Phone based setup did­n’t work, re­turned. Motorola sup­port was non-ex­is­tent,” reads one Amazon re­view posted on May 5, sug­gest­ing the MotoSync+ is­sue may have started ear­lier than pre­vi­ously re­ported.

The App Store and Google Play Store pages for the MotoSync+ app have also been filled with neg­a­tive re­views. According to the MotoSync+ app pro­file on the App Store, the MotoSync+ app last re­ceived an up­date two months ago.

“The pre­vi­ous MotoSync app worked won­der­fully with my MG8702 router, but ever since I was forced to switch to the MotoSync+ app, it’s been a pain,” said one user, ref­er­enc­ing how Motorola shut down its orig­i­nal legacy MotoSync app in April, push­ing users to the new MotoSync+ app.

However, it seems that the orig­i­nal MotoSync app faced sim­i­lar down­time is­sues a few years ago, too. Back in 2023, Reddit users re­ported that they were un­able to use the legacy MotoSync app to set up and edit their de­vices for roughly a month be­fore the app be­gan work­ing again.

What’s even more frus­trat­ing for some users: The new MotoSync+ app of­fers an op­tional sub­scrip­tion ser­vice for pre­mium fea­tures. Paying users can’t ac­cess these fea­tures ei­ther while the app is down.

Motorola cus­tomers on plat­forms such as Reddit re­port con­tact­ing the com­pany and re­ceiv­ing ei­ther a generic au­to­mated re­ply or no re­sponse at all. However, Reddit user u/​SnooPo­em­s7789, who started the main thread on Reddit about the is­sue, posted that they re­ceived a re­ply on May 14 from Motorola claim­ing it was an “issue with our net­work­ing ven­dor” and the com­pany was “taking ac­tions to ad­dress the prob­lem.”

Another Reddit user re­ported call­ing a cus­tomer sup­port num­ber listed on the MotoSync+ app and be­ing con­nected with a router soft­ware com­pany called Gryphon. The com­pany cur­rently sells the Motorola MQ20 router on its web­site. However, Gryphon re­port­edly told the cus­tomer that they “don’t sup­port MotoSync” and the user needed to speak to Motorola di­rectly.

MotoSync+ app in the App Store Credit: Mashable screen­shot

Interestingly, Gryphon has an app called Gryphon Connect on Apple’s App Store that looks ex­actly like the MotoSync+ app. The user in­ter­face and even the App Store screen­shots and mar­ket­ing copy pro­mot­ing the app are iden­ti­cal, with only the brand names for Gryphon and Motorola swapped out for each app.

Mashable also reached out to Gryphon to in­quire about the com­pa­ny’s re­la­tion­ship with Motorola.

“While the apps may look sim­i­lar and are both as­so­ci­ated with Gryphon tech­nol­ogy, the Motorola MQ20 uses a dif­fer­ent plat­form and man­age­ment sys­tem from the Gryphon Tower, Guardian, and AX mod­els,” a Gryphon spokesper­son said in a state­ment pro­vided to Mashable. “The Motorola MQ20 has its own ded­i­cated sup­port en­vi­ron­ment and di­ag­nos­tic tools, which are han­dled specif­i­cally by Motorola Support. They have ac­cess to the proper sys­tem needed to check the router sta­tus, set­tings, logs, and ad­vanced di­ag­nos­tics for the MQ20.”

For now, how­ever, many Motorola cus­tomers are left with­out an­swers or a work­ing WiFi router — at least for the time be­ing.

“Tbh if I was you I would go ahead and get rid of it and get a dif­fer­ent router,” wrote Reddit user u/​SnooPo­em­s7789 in the replies to other users on his Reddit thread. “They lit­er­ally made it a pa­per­weight now.”