In early March 2026, Dan Blanchard released chardet v7.0 — a "ground-up, MIT-licensed rewrite" of a Python library that’s been quietly detecting character encodings since 2006. The original was written by Mark Pilgrim and released under the LGPL, one of the stricter open source licences that requires derivative works to stay under the same terms. Blanchard’s rewrite was produced entirely by Claude Code, working from a design document in an empty repository with no access to the original source tree.

The new version is 48 times faster, more accurate, and licensed under MIT — the permissive licence that lets anyone do essentially anything with the code. The resulting code shares less than 1.3% similarity with any prior version. Twenty years of copyleft protection, undone in five days.

This matters, but not for the reason most of the commentary thinks it does.

The legal story everyone’s telling

Most of the coverage has framed this as a licensing story. Ars Technica ran a detailed investigation into Blanchard’s process. Glyn Moody at Techdirt and Walled Culture pushed the analysis further, connecting it to the broader erosion of software copyright. Mark Pilgrim, the original author, opened a GitHub issue two days after the release arguing his LGPL rights had been violated. The resulting debate got heated in the way open source licensing debates always do.

The core questions are reasonable: can AI-assisted clean-room reimplementation circumvent the GPL? Does the LGPL still mean anything if an AI can rewrite the entire codebase from a specification?

But the answers aren’t actually new. Clean-room reimplementation has been legally permissible for decades — it’s how Stallman’s GNU project recreated Unix in the 1980s, and how Compaq spent $1 million to reverse-engineer the IBM PC BIOS in 1982. The legal principle is well-established: if you can produce functionally identical software without copying any protected expression, you’re not infringing copyright. The code is new. The licence is yours to choose.

What’s changed isn’t the law. It’s the economics. What previously required teams of skilled engineers working for months or years can now be done by one person with an AI coding agent in a matter of days. Blanchard described his process clearly: he wrote a design document specifying the architecture and requirements, started Claude Code in a fresh repository with explicit instructions not to reference the LGPL-licensed original, and let it build the whole thing.

The cost of clean-room reimplementation just collapsed by several orders of magnitude. Which means the real question was never about law at all.

What copyleft actually depends on

The GPL and its variants work because of a specific assumption: that reimplementing software from scratch is so expensive that nobody will bother. If you want to use GPL-licensed code, it’s cheaper to accept the copyleft terms than to rewrite it. The licence’s enforcement mechanism isn’t really the courts. It’s the prohibitive cost of the alternative.

Agentic coding tools have just removed that cost barrier. If Claude Code can rewrite chardet in five days, it can rewrite anything of similar complexity. And the tools are getting better, not worse. Anthropic’s Claude, working through its coding agent, can now handle multi-file projects with architectural coherence that would have seemed implausible eighteen months ago.

This doesn’t mean the GPL is dead. It means its practical enforcement mechanism, the economic impossibility of reimplementation, is eroding fast. For small-to-medium libraries, it’s already gone. For larger projects, give it a year or two.

Salvatore Sanfilippo (antirez, the creator of Redis) sees something interesting in this. His take is that AI-assisted reimplementation could actually be good for open source. "Now that code is every day less important than ideas," he wrote, "open source can be strongly accelerated by AI." The person who’s been thanklessly maintaining a library in their spare time can now accomplish ten times as much with AI assistance. The bottleneck shifts from writing code to having good ideas about what to build.

I think he’s right about the direction, but I’m not sure he’s reckoning fully with the implications. If code is disposable, then the thing that makes open source valuable isn’t the code at all. It’s the design decisions, the architectural knowledge, the understanding of edge cases accumulated over years. Lose that understanding and you run up real cognitive debt — software the team ships but no longer comprehends. And those things live in documents, in commit messages, in the maintainer’s head — not in the source files.

The epistemic shift

This is the part that’s easy to miss, and it’s the part I keep coming back to.

I’ve been writing about the shift from code to intent for months now — the argument that as AI coding tools mature, the valuable skill stops being implementation and starts being direction. Knowing what to build, for whom, and why. chardet v7.0 is that thesis made concrete, more concrete than I expected this soon.

Blanchard didn’t write the code. He wrote the specification. He described the architecture, defined the requirements, set the constraints. Claude Code did the rest. The intellectual contribution, the thing that actually mattered, was the design document. Not the Python files it produced.

I noticed this in my own work recently. I spent three days building an automation pipeline, and when I looked back at the git history, the actual code had been rewritten twice from scratch during the process. The first version worked. The second was architecturally different but functionally identical. The third was cleaner again. The code kept changing. What didn’t change was the specification document I’d written before any of it started. That document is the real artefact. The code is just whatever today’s best rendering of it happens to be.

Scale that up and the implications for copyright get genuinely odd. Copyright law protects specific expression — the particular way an idea is written down in code. It doesn’t protect the underlying ideas, algorithms, or functional requirements. When the expression becomes trivially reproducible from the ideas, the protection becomes... well, technically it still exists. But it’s about as meaningful as copyrighting a specific arrangement of bricks when anyone with a blueprint and a bricklaying robot can build an identical house in an afternoon.

What proprietary software companies should be worried about

The open source implications get most of the attention, but proprietary software has an arguably bigger problem.

If clean-room AI reimplementation of an LGPL library passes legal muster (and the precedent strongly suggests it does), then the same process works against proprietary software. You don’t need access to the source code. You need access to the software’s behaviour: its inputs, outputs, API contracts, and documented functionality. Feed that into an AI coding agent with a well-structured specification, and you get a functionally equivalent product with entirely new code and no licensing obligations whatsoever.

Companies that compete on the basis of their codebase, rather than their data, their network effects, or their customer relationships, should be paying very close attention. The moat just got significantly shallower.

I’m genuinely uncertain how quickly this plays out for larger, more complex software. A character encoding library is one thing. An enterprise ERP system is quite another. But the direction of travel is clear enough, and the tools are improving fast. Anthropic’s Managed Agents already allow autonomous AI agents to run complex, multi-file tasks without human oversight. The ceiling for what can be reimplemented in a clean room is rising every quarter.

Open Source 2.0, or open source’s funeral?

Sanfilippo’s optimistic reading deserves more attention than it’s getting. He imagines a future where people collaborate on prompts rather than patches — "open source hacking but functioning at a level above the code itself." Instead of submitting pull requests with code changes, contributors would submit improved specifications, better architectural descriptions, refined design documents that produce better code when fed through an AI.

It’s appealing, and it rhymes with something real. The Nebraska problem — that critical infrastructure depends on an exhausted volunteer maintaining a library nobody thanks them for — could genuinely improve if AI handles the grinding implementation work while humans focus on design and direction.

But there’s a tension here that I don’t think anyone has fully resolved. Open source licensing works because it applies to code. Design documents, specifications, and prompts don’t have the same legal framework. The copyright conversation has so far concentrated on training data — the UK’s AI copyright dilemma is a good worked example of how messy that gets — but the downstream question of what gets generated, and under what terms, is only just starting. If the valuable artefact moves from code to specification, the entire licensing infrastructure that supports collaborative open source development needs to move with it. And nobody’s built that yet.

What do you copyright in a prompt-driven world? The specification? The prompt itself? The architectural decisions? Nobody has good answers yet, and the legal tooling assumes that source code is the thing worth protecting. That assumption is crumbling, and nothing has emerged to replace it.

What your team should actually own

So the question worth sitting with is this.

If any codebase can be regenerated in days by an AI working from a good specification — and we’re not there for everything, but we’re there for a growing category of software — then what should your team actually own?

Not the code. The code is a commodity now, or heading there fast.

The things that can’t be regenerated: deep domain knowledge. Customer relationships. Proprietary data. Institutional understanding of edge cases. Design documents that encode decades of lessons about what works and what doesn’t. The architectural taste that knows when to use the boring solution and when the problem genuinely demands something novel.

The chardet rewrite is a small thing in isolation. A Python library isn’t the Berlin Wall. But it’s a clean, well-documented example of a shift that’s going to touch everything in software over the next few years. The legal questions will get argued about and eventually settled. The interesting question is the epistemic one: when code is disposable, what’s left that’s worth owning?

I don’t think the answer is "nothing." I think it’s "different things than we’re used to protecting." And the organisations that figure out what those things are — and build their strategy around owning them — are going to be in a much stronger position than the ones still treating their codebase as a competitive advantage.

The code was never really the point. We just didn’t have a way to prove it until now.