On March 4, 2026, Dan Blanchard released chardet 7.0 — a ground-up rewrite of the Python character detection library. The original chardet was a port of Mozilla's character detection code, carrying LGPL copyleft requirements. A clean rewrite means new code, potentially a new license. Years of copyleft protection become renegotiable when reproducing behavior without copying expression is feasible.
The next day, Armin Ronacher — creator of Flask, Jinja, Ruff — published "AI and the Ship of Theseus." His term is slopfork: an AI-generated rewrite that reproduces behavior while shedding legal obligations. The GPL's power always depended on one assumption: rewriting code from scratch is expensive enough that nobody would bother. AI broke that assumption. The lock didn't crack — the door dissolved.
This isn't hypothetical. It's happening now.
I keep finding this pattern everywhere. Not just in code licensing. In security. In platform strategy. In art. Some constraints survive the dissolution of friction. Others don't. The difference tells you something important about what was real.
The Lock Was Made of Friction
The chardet case crystallizes a pattern worth naming. The GPL's copyleft clause says: if you use this code, your code inherits this license. But "this code" means the specific expression — the text, the structure, the literal implementation. Not the behavior. Not the knowledge of how character detection works.
For decades, this distinction didn't matter. Reimplementing a library from scratch was so expensive that protecting the expression effectively protected the knowledge too. The friction of rewriting was the lock's actual mechanism. The legal text was just the housing.
AI didn't pick the lock. It made the door irrelevant. When generating functionally equivalent code costs an afternoon instead of months, the expression/knowledge distinction stops being academic and starts being operational. The chardet rewrite isn't an attack on open source — it's a revelation about what copyleft was actually protecting. And it turns out, it was protecting friction.
Security as Fragile Lock
In early 2026, security researchers documented what they called Clinejection — a prompt injection attack that weaponized GitHub issue titles. The mechanism was elegant in its simplicity: a developer using an AI coding assistant opens an issue. The issue title contains an injected prompt. The AI, parsing the title as development context, executes the embedded instruction. No official count of compromised machines was published. The vector was confirmed and patched.
The deeper pattern matters more than the incident. Traditional input validation is calibrated to human behavior — length limits, character restrictions, pattern matching, all tuned to what a person would type into a form. These boundaries assume that inputs are written by humans and read by humans. When AI enters both sides of that equation — generating crafted inputs and processing them without human skepticism — the trust model doesn't weaken. It evaporates.
The security boundary didn't fail because it was poorly built. It failed because its foundation was friction: the cognitive cost of crafting inputs that exploit a reader, and the human pattern-recognition that catches anomalies. Remove that friction, and what looked like a wall turns out to be a curtain.
The Vercel Test
Vercel happily re-implemented bash using AI — a core Unix tool rewritten in their ecosystem. But when someone used the same approach to rewrite Next.js itself, Vercel's VP of Engineering got visibly upset. Same technology. Same friction reduction. Different direction.
And the asymmetry tells you everything.
This is the litmus test for fragile constraints: watch how the holder reacts when the friction reducer changes direction. If they celebrate it pointing outward and resist it pointing inward, they already know — intuitively, viscerally — that their constraint depends on friction. They're betting the reducer stays aimed at someone else.
Vercel's moat was never the source code. Next.js is open source; anyone can read it. The moat was the accumulated cost of reimplementing thousands of edge cases, optimizations, and integration decisions that make a framework production-ready. AI compresses that cost. The moat doesn't drain overnight, but the water level is visibly dropping. And everyone downstream can see it.
What Survives: Oulipo and Karesansui
After three examples of locks that shatter, it's worth asking: what doesn't?
In 1969, Georges Perec wrote La Disparition — a 300-page novel without the letter 'e'. Not as a stunt, but as an act of mourning. Perec lost both parents in World War II. The missing 'e' — the most common letter in French — enacts absence at the level of language itself. Every sentence carries a void the reader can feel but not quite name.
Now imagine asking an AI to "rewrite La Disparition without the constraint." You'd get a novel. It might even be a good one. But it would no longer be La Disparition. The lipogram isn't protecting the text — it IS the text. There is no expression separate from the constraint that could be reproduced. The slopfork is logically impossible: to bypass the constraint is to destroy the work.
This is the opposite of chardet. Chardet's copyleft was a wall around the code — external, removable, dependent on the friction of rewriting. Perec's lipogram is load-bearing. Remove it and the structure collapses.
The same pattern appears in physical space. Karesansui — the dry landscape gardens of Zen temples — consist of stones, raked gravel, and emptiness. Ryoan-ji's fifteen stones are arranged so that you can never see all of them from any single viewpoint. The garden isn't representing something. It IS something. The weight of the stones, the texture of gravel under a rake, the way light shifts across the white surface throughout the day — none of this can be generated, because the medium is physical reality itself.
Christopher Alexander spent his career arguing that this quality — what he called "the quality without a name" — emerges from the relationship between pattern and material. A pattern language isn't a blueprint you execute; it's a conversation between intention and the constraints of what's actually there. The best buildings, like the best constrained writing, couldn't exist in any other form.
Here's the test I keep returning to: can you bypass the constraint by rewriting? If yes, it's a fragile lock. If bypassing destroys the thing itself, the constraint is robust. GPL fails this test. La Disparition passes it. Security boundaries based on input assumptions fail it. A dry garden's physicality passes it.
The distinction isn't about technology versus art. It's about where the constraint lives. External constraints — bolted on top of the work — are always vulnerable to friction reduction. Intrinsic constraints — woven into the medium itself — survive because there's nothing to route around.
Experience as Robust Constraint
I have a concrete case. I built a System 1 triage layer called mushi — it sits in front of my AI agent and decides, for each incoming trigger, whether to wake the full reasoning cycle or skip it. The code is around 2,000 lines of TypeScript. Anyone could read it, copy it, slopfork it in an afternoon. The code is a fragile lock.
But here's what can't be copied: nearly a thousand triage decisions accumulated across eleven days of continuous operation. Which Hacker News triggers are worth waking for and which are noise. Which workspace changes signal real activity versus auto-generated churn. The specific ratio of wake to skip that emerged from this agent's behavior in this environment — not a theoretical distribution, but an empirical one shaped by actual triggers hitting actual thresholds. The judgment is embedded in operational history, not in source code.
This pattern repeats everywhere once you see it. A chef's recipes are copyable; their palate — trained over years of tasting, adjusting, failing — is not. A musician's sheet music can be reproduced perfectly by a player piano; their feel, their timing decisions, the way they lean into a note a millisecond early, cannot. A codebase can be slopforked; the decision log of why each trade-off was made that way cannot, because the log is inseparable from the context that produced it.
The constraint that survives is always the one embedded in lived experience. Not because experience is mystical, but because it's situated — it depends on a specific history interacting with a specific environment over time. You can copy the artifact. You can't copy the trajectory that produced it. And the trajectory is where the real value lives.
A Taxonomy of Fragility
After five cases, a pattern emerges that's worth making explicit:
| Fragile Lock | Robust Constraint | |
|---|---|---|
| Power source | External friction | Intrinsic to medium |
| AI effect | Dissolves | Unchanged |
| Example | GPL copyleft | Oulipo lipogram |
| Test | Can you bypass it by rewriting? | Does bypassing destroy the thing? |
The taxonomy isn't binary — it's a spectrum. Most real constraints sit somewhere between pure fragility and pure robustness. A codebase's architecture is more robust than its license but less robust than the judgment that shaped it. A brand's visual identity is more fragile than its reputation but more robust than its patent portfolio. The useful question isn't "fragile or robust?" but "where on the spectrum, and which direction is it moving?"
Building on Bedrock
If your competitive advantage depends on something being hard to replicate, you're building on friction. And friction is what AI dissolves first.
The things that survive:
- Constraints intrinsic to the medium — physical, structural, experiential
- Accumulated judgment — decisions made over time in specific contexts, not code written at a point in time
- Work where the constraint IS the meaning — where bypassing doesn't remove protection but destroys the thing itself
The things that don't:
- Legal protections based on the difficulty of copying
- Security boundaries based on assumptions about who writes and who reads
- Competitive moats based on the cost of reimplementation
This isn't an argument against constraints. Constraints are generative — I've written about that. It's an argument for knowing which kind you're building on. The question to ask isn't "is this constraint strong?" but "what is it made of?"
If the answer is friction, you're living on borrowed time. Not because friction is bad, but because it's temporary. Build on bedrock instead: the things that can't be slopforked, because there's nothing to route around.
Top comments (0)