When Test Code Becomes the New Moat

Cloudflare built a Vite-based Next.js-compatible runtime in one week. How? They fed Vercel's years of Next.js docs and test suite into an AI.

They didn't copy code. They learned the spec. And the spec lived inside the test code.

The Success Paradox

As a project grows, it carries the weight of backward compatibility and a massive codebase. Like the Ship of Theseus, you replace parts while keeping the name.

Meanwhile, competitors start from a clean slate. They grab API specs and tests, extract only the core value, and build a lighter, more modern version. Zero legacy burden.

This is the fundamental problem of open source in the AI era.

SQLite's Foresight

SQLite's code is fully open. But the tests are private. They have a 92-million-line test suite — 590x the size of the source code.

100% branch coverage. Millions of test cases. Over a billion mutation tests. This is why SQLite can be open source while maintaining commercial defensibility.

Someone could fork SQLite and build a faster version. But they can't guarantee the corner cases SQLite has discovered over 30 years. That's why airplane black boxes use SQLite.

Tests Are the Spec

In the past, code itself was the value. If you wanted to know how something worked, you read the code — so you hid the code.

Not anymore. Tests that define how things should behave are the more expensive asset. AI rewrites the code. It just needs to satisfy the behavior the tests define.

The "software contract" became more valuable than the code. And tests are the most precise way to express that contract.

Is Open Source Dead Then

No. But the strategy will shift.

Commercial open source companies will face this question: it's fine to open the code, but will you open the tests too?

My bet is that the SQLite pattern becomes standard. Code public, tests private. "Read the code if you want to use our product. Write your own tests if you want to copy us."

It Matters for Solo Devs Too

If you're a solo dev running 7 projects, this is even more urgent. AI made initial speed insane, but code piled up without tests becomes refactoring hell.

Every time you touch one feature, you're scared something else breaks. And eventually that project dies.

Projects with good tests let AI refactor freely. As long as tests pass, AI has permission to rewrite the code.

What Counts as a Good Test

E2E tests are the core. Unit tests are tied to implementation and break on refactoring. They're too narrow to validate AI-rewritten code.

The real assets are integration/E2E tests that specify "given this input, this output should happen." Only tests written at the user-scenario level survive implementation changes.

One more thing: AI is great at generating code, but writing meaningful test scenarios still needs human domain knowledge. Humans find the edge cases. AI just writes them down.

Conclusion

The era of safely open code is over. What you really need to protect now is the behavior spec — the test code.

If you run an open source company, it's time to look at the SQLite pattern. If you're a solo dev, it's time to start writing tests first. If you're a company, it's time to re-rate the security level of your ADRs and test assets.

The easier AI makes it to clone code, the more valuable tests become.