Webernetes: 100K lines of LLM code and the review that made it work

Last week Sam Rose released webernetes, a partial port of Kubernetes to TypeScript that runs in the browser. Almost all of it was written by LLMs. The project hit 235 points on Hacker News and immediately sparked the question everyone asks: is this just slop?

The answer is complicated, and I think that complication is the most interesting part.

What webernetes actually is

Webernetes is not Kubernetes compiled to WebAssembly. A simple Go "hello world" compiled to WASM is already ~540KB gzipped, bigger than webernetes itself at ~140KB gzipped. Porting all of Kubernetes that way would mean megabytes over the wire, and it would not even compile because Kubernetes calls system-level APIs that do not exist in the browser.

Instead, webernetes is a from-scratch TypeScript implementation of several Kubernetes components:

• A partial port of the kubelet binary, enough to run pods and probe them
• Ports of several Kubernetes controllers: pod scheduler, namespace controller, kube-proxy, deployment controller, and more
• A browser-based container network interface (CNI) so pods can talk to each other over a simulated network
• A browser-based container runtime that the kubelet talks to over the container runtime interface (CRI)
• An API for applying manifests and watching resources

It does not pull real images from Docker Hub. You define images using a TypeScript API, and they run in the browser's JavaScript runtime. The goal is not production Kubernetes. The goal is interactive Kubernetes content: tutorials, demos, documentation that actually runs.

The numbers

Those token consumption numbers are worth sitting with for a moment. Over 5 billion cached input tokens. The last week alone cost $1,811 in API fees. The author describes this as a panic response: he needed Deployments working for the demo, the first LLM attempt missed huge amounts of functionality, so he threw sub-agents at the problem. The token efficiency was, by his own admission, "extremely poor."

I bring this up not to dunk on the approach. I bring it up because this is what LLM-assisted development actually costs when you are doing something hard, and most of the breathless coverage skips the dollar figures.

Why this is not slop

The author makes two claims about quality control, and I think both are necessary and neither is sufficient alone.

First: he reviewed every line of code. Not a skim. A side-by-side comparison with the Kubernetes Go source, because most of the code is a direct port. This is how he found the three categories of LLM mistakes that kept showing up.

Shortcuts were the most common. Kubernetes has a lot of different cache types: LRU, expiring, FIFO, transforming. The LLM would implement them all as a plain Map. Faster to write. Wrong behavior. This happened more when porting larger files, which made him wonder if he was fighting post-training choices designed to make the output less verbose.

The LLM also tried to be helpful by inventing helper functions that did not exist in the Go source. Sometimes harmless. Sometimes subtly different behavior. Always made side-by-side review harder, so he asked it to remove them.

And then there was stuff that just went missing. Table tests in Go are arrays of test cases with shared test code underneath. The LLM would arbitrarily omit tests. Sometimes it would claim a test was "not applicable." Occasionally that was true. Usually it admitted to dropping it by mistake.

Second: he wrote 2,059 tests. 204 integration tests that run the exact same operations against both a k3s cluster and webernetes. 1,855 unit tests, mostly direct ports from the Kubernetes Go codebase. Same API calls. Same expected outcomes. You run pnpm test:node and it tests against k3s. You run pnpm test:browser and it tests against webernetes. If one passes and the other fails, you have a porting bug.

This dual-target testing setup is the real innovation here, and I wish more LLM-assisted projects did something like it. The question is never "does the code look right." It is always "does it behave the same as the reference implementation." Without an automated way to answer that, you are trusting your squishy human brain to reason through every edge case, and that does not work even for hand-written code.

The honest take

I keep going back and forth on whether this is the future or a very capable person doing something the hard way in a new style.

The review-every-line approach only works because webernetes is a port. There is a reference implementation to compare against. When you are building something genuinely new, there is no k3s cluster to test against. The contract is whatever you say it is, and the LLM is happy to write code that satisfies whatever contract you describe, even if the contract is wrong.

The token economics are also rough. $4,334 in API costs for a project that does not have revenue and is intended for educational content. The last week alone was $1,811 because the LLM's first attempt at Deployments was bad, so the author threw sub-agents at it. That is the core loop of LLM-assisted development: the model fails, you scale up the prompt engineering and the agent count, and sometimes that works and sometimes you just spent $300 watching it invent the wrong helper function again.

And the project scope is unusual. Most of the code is a translation, not an original design. The interesting engineering decisions (the browser CNI, the container runtime interface, the TypeScript image API) are precisely the parts that are not LLM-generated. The parts the LLM did well on are the boring translation work: method-by-method porting of Go to TypeScript. That is useful! It saved time! But "LLMs are good at mechanical translation" is a smaller claim than "LLMs wrote a Kubernetes clone."

What I actually like about it

The testing story is genuinely good. 204 integration tests running against both k3s and webernetes is the kind of infrastructure that most projects never bother with, and it is the reason we can have any confidence that the port works correctly. If you are going to use LLMs for porting or translation work, this dual-target pattern is worth copying.

The scope is honest. It is not trying to be a production Kubernetes distribution. It is for interactive content. That constraint means the author could skip things like ConfigMaps, Secrets, persistent volumes, and pod resources. The result is small enough to actually load in a browser. If it tried to be complete, it would fail.

The author's LLM failure taxonomy is useful. Shortcuts, invented helpers, and omitted tests are not unique to this project. Anyone who has done substantial LLM-assisted coding will recognize all three patterns. Having them documented with concrete examples from a real project is more valuable than another blog post about how AI changed everything.

The thing that bugs me

The token consumption graphs tell a story the prose does not fully reckon with. The peak week was 104M uncached input tokens, 2.2B cached input tokens, and 6.4M output tokens. That is the week the author "threw lots of tokens at the problem" by spinning up sub-agents.

I have done similar things. When the model's first attempt is bad, you try harder prompting. When that fails, you try more agents. When that fails, you try more sub-agents reviewing each other. The API bills mount. Sometimes you get lucky and the additional effort produces working code. Sometimes you spend $300 and the result is still wrong. There is no clean heuristic for when to stop and rewrite it yourself.

The author says "my time was still the most expensive line item." That is probably true for a salaried senior developer at ngrok. It is not true for most people reading this. If your time costs less than $1,811 per week, the API bill is the bottleneck, not your review hours.

Where this goes

Webernetes is open source at github.com/ngrok/webernetes. The author explicitly asks for contributions and feature requests. The current missing list is long: ConfigMaps, Secrets, pod resources, persistent volumes, and more that have not been needed for his content use case yet.

The broader question is whether the review-and-test pattern scales to projects that are not ports. If you are building something with no reference implementation, what is the equivalent of the k3s dual-target? Property-based testing? Formal specifications? I do not think anyone has a clean answer yet.

What webernetes proves is that LLMs can produce a large, working codebase when the human is willing to review every line and maintain a reference implementation to test against. That is a real thing. It is also a very specific thing, and I worry about the projects that will try to generalize it without the testing infrastructure that makes it work.