wet: write every time

the craft of good developers used to be not typing the same thing twice. the religion that grew out of that left us with 641 packages for a personal blog.

software development had an obsession so self-evident that it barely registered as a design decision anymore: code must not be duplicated.

don't repeat yourself. dry. a sensible rule (do not maintain the same validation inconsistently in three places) became holy order. the craft of good developers was to abstract and generalize. whoever could do that counted as a senior. whoever copy-pasted counted as sloppy.

from that followed almost everything that has dominated software architecture for the last fifteen years: shared libraries, internal platforms, design systems, cms, package ecosystems. work should be done once and then serve everyone. that was the rationally economic answer to expensive developer time.

except: the cost function has just shifted hard, and with it the dogma of the dry religion faces its enlightenment.

write every time

it is summer. that reminds me of those drip sandcastles on the beach, where you keep stacking small towers out of wet sand. when agentic software engineering goes badly, the software looks the same: parallel structures built again and again, sse in the app, and why use that if you can also put a parallel structure with a websocket next to it, and so on.

so wet is not an invitation to celebrate spaghetti code and ai slop. wet means write every time: when writing is cheap, the default is no longer “share and amortize”, but “write what you need now, lean, clear, and above all ruthlessly optimized for your stakeholder, and maybe very soon without a foreign foundation underneath”.

the cms that no longer pays off

two years ago a content management system was still a pretty good investment.

non-technical staff could maintain websites. build templates once, change content a hundred times. workflow, preview, permissions, media library. the platform paid for itself because the alternative (every time an expensive developer has to touch the site) was much costlier than the rigid abstraction and the database underneath.

today i consider that a miscalculation.

ai is absurdly good at producing highly optimized websites. and yes: non-technical people can do that too. github can model review processes without much friction. what you end up with, instead of a cms with a database, a plugin graveyard, and update anxiety, is a lean site. for static pages really only static html. global on a cdn. fast, simple, almost no attack surface.

forms and small functions are implemented in hours, not in sprint plans for the next plugin. recurring complex things (an auth flow, a checkout fragment, a dashboard widget) do not need to be generalized into a monolithic platform. you show the ai another project as a pattern and let it write the slice you need here.

deduplication still costs here, as before. it no longer delivers value that justifies the complexity. the “single source of truth” in the cms was the answer to expensive human copy-paste work. for a machine that writes a second, third, tenth variant in seconds, that single truth is often just lock-in with extra steps.

and maintenance is not an argument against it either: automated agents work on schedules across multiple projects.

that is wet at the project level: better each customer gets their own lean, personalized dashboard than the platform that serves everyone at 80 percent. (i described the economic side of this shift in liquid software [8]. here it is about the architecture underneath.)

one step back: how dry became the dependency tree

the same logic that sanctified cms and platforms built the package ecosystem one floor down.

do not write twice → reuse → packages. packages need packages → dependency trees. dependency managers resolve the mess by pinning versions, resolving, updating, and producing an illusory order: npm install feels like control, but it is blind trust in hundreds of strangers who maintain your stack.

example: this simple blog. angular frontend, fastapi backend.

the package.json lists twelve production dependencies (angular core, marked, rxjs, a bit of ssr tooling). the package-lock has 641 packages. the backend lists fifteen direct dependencies in pyproject.toml; uv.lock comes to 76. together over 700 dependencies. that is a complete developmental dead end.

and this is not an enterprise monster with monorepos and microfrontends. this is a personal blog. of the 641, the lion’s share is transitive load from framework and build tooling. that is exactly the point: you pick a modern frontend setup and inherit hundreds of packages you have never opened.

anyone who claims to understand, in such an npm project, which 641 dependencies in which versions are running and what they do in an install hook is lying.

supply chain: the mess has teeth

that would be an aesthetic and cognitive problem if packages only bloat. they do more.

in the last twelve months alone the npm and pypi worlds have been shaken by a series of supply-chain attacks that make the old “we have snyk” line look ridiculous.

in september 2025 the shai-hulud worm marked a break: from annoying typosquats to self-replicating malware in the ecosystem. maintainer accounts were compromised, popular packages poisoned, the payload stole credentials and republished itself into further packages, automatically. [1] [2]

in march 2026 it hit axios, one of the most used javascript libraries (hundreds of millions of weekly downloads). via compromised maintainer credentials, backdoored releases appeared; a phantom dependency with a postinstall script delivered a cross-platform rat. whoever ran npm install in the wrong hour installed more than http client code. [3]

shortly after, litellm on pypi, ironically a piece of ai infrastructure, with tampered releases, credential stealer, backdoor. [4] in may 2026 another wave (mini shai-hulud) took down dozens of @tanstack/ packages in minutes, again with worm logic. [5] in august 2026 again: hundreds of packages, including parts of the keyv/cacheable ecosystem, wormable, preinstall hooks, automatic republishing. packages with over 150 million weekly downloads in the vicinity. [6] [7]

alerts are band-aids, not architecture

github dependency alerts, snyk, dependabot, lockfile audit: useful. i use that stuff. but they are a bugfix on a structural problem, not a solid solution.

they react to the known. they arrive after publish. they do not change the fact that build systems grant hundreds of foreign execution contexts before your app even starts.

the question, from my point of view: is this model still sensible going forward?

“then i no longer understand my code”

the classic counterargument of the old guard goes roughly: if the ai writes the code, i lose control. i no longer understand my system.

i think that is nonsense, and specifically because it was already nonsense before ai entered the picture.

the same person who mistrusts ai-generated code ran npm install yesterday and accepted hundreds of packages, most of which they never opened. control was a self-reassuring story. the reality was trust in an ecosystem plus a scanner dashboard.

software development in 24 months

it is hard, at the speed of current developments, to make reliable predictions. but i think: if the cost function stays like this, and ai does not get worse at writing, the default stack for many products looks like this in 24 months from my point of view:

• minimal native html, often static where that is enough
• minimal plain css, instead of framework cathedrals for three pages
• targeted interactivity, forms and small functions as lean code, not as cms plugins
• webassembly written directly by the ai
• no dependency religion: libraries where the benefit is brutally clear (crypto, codecs, truly hard stuff), not as a reflex, and only if your own ai has reviewed the code
• patterns instead of platforms: recurring work as a reference project or snippet that the ai fits in fresh each time, that is write every time
• allow duplication when it is clearer and safer than the wrong abstraction

duplicated code can be more effective than dry. not because dry was stupid, but because dry was the answer to expensive human typing. when the machine types, the expensive work is the wrong generalization.

ai is the new dependency tree

not everything that is wet glitters. the new artificially intelligent world brings new problems too. instead of trusting the proverbial random person in nebraska, you now have to trust your llm, and that is hard. without putting on tin-foil hats: the last months have shown that us and chinese governments have recognized the military-strategic importance of llms. so it is not safe to assume that the respective llms contain no instructions to build certain small backdoors. it is enough to make the randomization algorithm slightly less random than random, and for one’s own services the doors open as if by themselves.

we cannot go deep here, but a sovereign open ai strategy is absolutely indispensable for one’s own economy and security. open here does not just mean open weights, but also open training data, that is real open source. otherwise you have the supply-chain problem again, with extra steps.

wet your code

the obsession with not duplicating code left us with software that, for all its reuse, nobody could still control. that was the price of productivity in a world of scarce developer hours.

ai changes the price. write every time is then not sloppiness. it is the return to software you can own: lean, intentional, rewritten on every level when needed, and therefore often safer and more honest than the tree we used to call control.

but for that to work in the medium term, a conscious investment in an open supply chain is infinitely important.

translated from the german original by grok 4.5