wet: write every time

die kunst guter entwickler war es, nicht zweimal dasselbe zu tippen. die religion, die daraus wurde, hat uns 641 packages fuer einen persoenlichen blog beschert.

es gab in der softwareentwicklung eine obsession, die so selbstverstaendlich wirkte, dass man sie kaum noch als designentscheidung wahrgenommen hat: code darf nicht dupliziert werden.

don't repeat yourself. dry. aus einer vernuenftigen regel (dieselbe validierung nicht an drei stellen inkonsistent pflegen) wurde eine heilige ordnung. die kunst guter entwickler war es zu abstrahieren und zu generalisieren. wer das konnte, galt als senior. wer copy-paste machte, als schlampig.

daraus folgte fast alles, was die letzten fuenfzehn jahre software-architektur dominiert hat: shared libraries, interne plattformen, design systems, cms, package ecosystems. viel arbeit sollte einmal gemacht werden und dann allen dienen. das war die rational oekonomische antwort auf teure entwicklerzeit.

nur: die kostenfunktion hat sich gerade extrem verschoben, und mit ihr droht dem dogma der dry-religion die aufklaerung.

write every time

es ist sommer. das erinnert an diese troepfelburgen am strand, bei denen man mit nassem sand immer wieder kleine tuerme hochgezogen hat. wenn agentic software engineering schlecht laeuft, sieht die software genauso aus: immer wieder parallele strukturen gebaut, sse in der app, und warum die benutzen wenn man nochmal eine parallelstruktur mit einem websocket daneben stellen kann, und so weiter.

wet ist also nicht die aufforderung, spaghetticode und ai slop zu feiern. wet heisst write every time: wenn schreiben billig ist, ist der default nicht mehr „teile und amortisiere“, sondern „schreib das, was du jetzt brauchst, und zwar schlank, klar und vor allem kompromisslos fuer deinen stakeholder optimiert, und vielleicht schon sehr bald ohne fremdes fundament darunter“.

das cms, das sich nicht mehr rechnet

vor zwei jahren war ein content-management-system noch eine ziemlich gute investition.

nicht-technische mitarbeiter konnten websites pflegen. templates einmal bauen, inhalte hundertmal aendern. workflow, preview, rechte, mediathek. die plattform amortisierte sich, weil die alternative (jedes mal muss ein teurer entwickler die website anfassen) viel teurer war als die steife abstraktion und die datenbank darunter.

heute halte ich das fuer eine fehlkalkulation.

ki ist absurd gut darin, hoch optimierte webseiten zu erzeugen. und ja: auch nicht-technische menschen koennen das. github kann ohne viel friktion kontrollprozesse abbilden. am ende steht statt einem cms mit datenbank, plugin-friedhof und update-angst eine schlanke website. fuer statische seiten wirklich nur noch static html. global auf einem cdn. schnell, simpel, kaum angriffsflaeche.

forms und kleine funktionen sind in stunden implementiert, nicht in sprint-planungen fuer das naechste plugin. wiederkehrende komplexe dinge (ein auth-flow, ein checkout-fragment, ein dashboard-widget) braucht man nicht in einer monolitischen plattform zu generalisieren. man zeigt der ki ein anderes projekt als pattern und laesst sie den ausschnitt schreiben, der hier gebraucht wird.

deduplizierung kostet hier wie frueher. sie bringt keinen mehrwert mehr, der die komplexitaet rechtfertigt. die „eine wahrheit“ im cms war die antwort auf teure copy-paste-arbeit von menschen. fuer eine maschine, die in sekunden eine zweite, dritte, zehnte variante schreibt, ist die eine wahrheit oft nur lock-in mit extra schritten.

und auch wartung ist kein argument dagegen: automatische agenten arbeiten scheduled ueber mehrere projekte.

das ist wet auf projektebene: lieber jedem kunden sein eigenes schlankes, fuer ihn personalisiertes dashboard als die plattform, die alle zu 80 prozent bedient. (die oekonomische seite dieser verschiebung habe ich in fluessige software [8] beschrieben. hier geht es um die architektur darunter.)

ein schritt zurueck: wie dry zum dependency tree wurde

dieselbe logik, die cms und plattformen heilig gesprochen hat, hat ein stockwerk tiefer das package-oekosystem gebaut.

nicht zweimal schreiben → wiederverwenden → packages. packages brauchen packages → dependency trees. dependency manager loesen das chaos auf, indem sie versionen pinnen, resolven, updaten und dabei eine illusorische ordnung erzeugen: npm install fuehlt sich zwar an wie kontrolle, ist aber blindes vertrauen in hunderte fremder maintainer.

beispiel dieser einfache blog: angular-frontend, fastapi-backend.

im package.json stehen zwoelf production-dependencies (angular-kern, marked, rxjs, ein bisschen ssr-tooling). im package-lock sind es 641 packages. das backend listet fuenfzehn direkte abhaengigkeiten in der pyproject.toml; uv.lock kommt auf 76. zusammen ueber 700 abhaengigkeiten. das ist eine voellige fehlentwicklung.

und das ist kein enterprise-monster mit monorepo und microfrontends. das ist ein persoenlicher blog. von den 641 ist der loewenanteil transitive last von framework und build-tooling. genau das ist der punkt: du waehlst ein modernes frontend-setup und erbst hunderte packages, die du nie geoeffnet hast.

wer behauptet, in so einem npm-projekt zu verstehen, welche 641 dependencies in welchen versionen da mitlaufen und was sie im install-hook tun, luegt.

supply chain: das mess hat zaehne

das waere ein aesthetisches und kognitives problem, wenn packages nur aufblaehen wuerden. sie tun mehr.

allein in den letzten zwoelf monaten ist die npm- und pypi-welt von einer serie von supply-chain-angriffen durchgeschuettelt worden, die das alte „wir haben doch snyk“ laecherlich wirken lassen.

im september 2025 markierte der shai-hulud-wurm einen bruch: aus nervigen typosquats wurde selbstreplizierende malware im oekosystem. maintainer-accounts wurden kompromittiert, populaere packages vergiftet, der payload stahl credentials und publizierte sich in weitere packages weiter, automatisiert. [1] [2]

im maerz 2026 traf es axios, eine der meistgenutzten javascript-libraries (dreistellige millionen weekly downloads). ueber kompromittierte maintainer-credentials erschienen backdoored releases; eine phantom-dependency mit postinstall-script lieferte eine cross-platform rat. wer npm install in der falschen stunde machte, installierte nicht nur http-client-code. [3]

kurz darauf litellm auf pypi, ironischerweise ein stueck ai-infrastruktur, mit getamperten releases, credential stealer, backdoor. [4] im mai 2026 brachte eine weitere welle (mini shai-hulud) unter anderem dutzende @tanstack/-packages in minuten um, wieder mit wurm-logik. [5] im august 2026 erneut: hunderte packages, darunter teile des keyv/cacheable-oekosystems, wormable, preinstall-hooks, automatisches republishing. packages mit ueber 150 millionen weekly downloads im umfeld. [6] [7]

alerts sind pflaster, keine architektur

github dependency alerts, snyk, dependabot, lockfile-audit: nuetzlich. ich nutze sowas. aber sie sind ein bugfix auf ein strukturelles problem, keine solide loesung.

sie reagieren auf bekanntes. sie kommen nach dem publish. sie aendern nicht die tatsache, dass build-systeme hunderte ausfuehrungskontexte von fremden freigeben, bevor eure app ueberhaupt startet.

die frage ist aus meiner sicht: ist dieses modell perspektivisch noch sinnvoll?

„dann verstehe ich meinen code nicht mehr“

das klassische gegenargument der alten garde lautet sinngemaess: wenn die ki den code schreibt, verliere ich die kontrolle. ich verstehe mein system nicht mehr.

ich halte das fuer quatsch, und zwar weil es schon quatsch war bevor ai im spiel war.

dieselbe person, die ai-generierten code misstraut, hat gestern npm install ausgefuehrt und hunderte packages akzeptiert, von denen sie die allermeisten nie geoeffnet hat. kontrolle war eine selbstvergewissernde erzaehlung. die realitaet war vertrauen in ein oekosystem plus ein scanner-dashboard.

softwareentwicklung in 24 monaten

es ist schwer, bei der geschwindigkeit der momentanen entwicklungen belastbare vorhersagen zu treffen. aber ich denke: wenn die kostenfunktion so bleibt, und ai wird nicht wieder schlechter im schreiben, sieht der default-stack fuer viele produkte aus meiner sicht in 24 monaten so aus:

• minimal native html, oft static, wo es reicht
• minimal plain css, statt framework-kathedralen fuer drei seiten
• gezielte interaktivitaet, forms und kleine funktionen als schlanker code, nicht als cms-plugin
• webassembly direkt von der ki geschrieben
• keine dependency-religion: libraries dort, wo der nutzen brutal klar ist (krypto, codecs, wirklich hartes), nicht als reflex und nur wenn die eigene ki den code gereviewed hat
• patterns statt plattformen: wiederkehrendes als referenzprojekt oder snippet, das die ki jedes mal frisch einpasst, eben write every time
• duplikation erlauben, wenn sie klarer und sicherer ist als die falsche abstraktion

duplizierte code-elemente koennen effektiver sein als dry. nicht weil dry dumm war, sondern weil dry die antwort auf teure menschliche tipparbeit war. wenn die maschine tippt, ist die teure arbeit die falsche generalisierung.

ki ist der neue dependency tree

nicht alles ist wet was glaenzt. die neue kuenstlich intelligente welt bringt aber auch neue probleme mit sich. statt dem sinnbildlichen random person in nebraska zu vertrauen, muss man nun seinem llm vertrauen, und das ist hart. ohne aluhuete rauszupacken: die letzten monate haben gezeigt, dass us- und chinesische regierungen die militaerisch-strategische bedeutung von llms erkannt haben. es ist also nicht davon auszugehen, dass die jeweiligen llms keine instruktionen enthalten, gewisse kleine hintertueren einzubauen. dabei reicht es voellig, den randomisierungsalgorithmus leicht weniger zufaellig als zufaellig zu gestalten, und fuer die eigenen dienste oeffnen sich die tueren wie von geisterhand.

wir koennen das hier nicht vertiefen, aber eine souveraene offene ki-strategie ist fuer die eigene wirtschaft und sicherheit absolut unabdingbar. offen bedeutet dabei eben nicht nur open weights, sondern auch open training data, also echtes open source. sonst hat man das supply-chain-problem again, with extra steps.

wet your code

die obsession, keinen code zu duplizieren, hat uns software beschert, die vor lauter wiederverwendung niemand mehr kontrollieren konnte. das war der preis fuer produktivitaet in einer welt knapper entwicklerstunden.

ai aendert den preis. write every time ist dann keine schlamperei. es ist die rueckkehr zu software, die man besitzen kann: schlank, absichtlich, auf jeder ebene neu geschrieben wenn noetig, und deshalb oft sicherer und ehrlicher als der tree, den wir kontrolle nannten.

aber damit das mittelfristig funktioniert, ist ein bewusstes investieren in eine offene supply chain unendlich wichtig.