The Rewrite Postmortem: What k10s Tells Us About Unsupervised AI Coding

In May 2026, two teams working in the same problem domain published nearly opposite stories within the same week. The k10s team, builders of a Kubernetes dashboard, posted I’m Going Back to Writing Code by Hand. Their AI-assisted “vibe-coded” build had collapsed under its own architecture: a god-object monolith with data races severe enough that the only sensible fix was a full rewrite in Rust. The WorkOS team, that same week, published The Self-Driving Codebase: Building Horizon at WorkOS, a working account of code agents running production-grade autonomy under a deliberate orchestrator design.

Same domain. Same week. Opposite outcome. Reading the two side by side is the most honest education in AI governance you can get right now.

What Actually Failed at k10s

The k10s postmortem is unusually direct. The author did not blame the models. The author blamed the absence of architectural authority. Features were added by prompting. State management lived wherever the most recent generation happened to put it. The codebase consolidated, organically, into a single god object that owned too much to refactor safely. When concurrency bugs surfaced, the team could not isolate them because the architecture had no boundaries to isolate against. Data races were not introduced by a bad commit. They were the steady-state behavior of a system with no contract between its parts.

The decision they reached is the part worth reading twice. They did not stop using AI. They concluded that the way they had been using it produced a codebase no human could reason about, and that rewriting from scratch in Rust, with a hand-designed architecture and technical guardrails in place before any agent touches it, was cheaper than continuing to debug the existing one. The rewrite is not a retreat from AI assistance. It is the reconstruction of the constraint surface that should have existed before the first prompt.

What Worked at WorkOS

Horizon is the same kind of story told from the other side. WorkOS describes a code agent stack that runs across their production codebase with real autonomy, and the description spends most of its time not on the model but on the scaffolding around it. The orchestrator. The eval harness. The merge gates. The taxonomy of work that gets delegated and the taxonomy that does not. The human architectural decisions that the agent inherits as immovable.

The WorkOS engineers do not credit a particular model. They credit a system in which the model operates inside a designed envelope. The agent is fast at the tasks the system gives it. The system, not the agent, decides what those tasks are.

Two teams. Same week. Same domain. The k10s team operated without a constraint surface and burned a codebase. The WorkOS team designed the constraint surface first and ran the agent inside it. The model was not the difference. The harness was.

The Sentence That Names the Lesson

Read enough of these accounts and a single sentence emerges across all of them. The governance lever is not “use AI less.” It is “design the constraint surface before the agent writes the first line.”

The constraint surface is the union of three things. An architecture decided by humans, written down, and treated as immovable for the duration of the work. A set of technical guardrails: type systems, lint rules, test coverage thresholds, concurrency contracts, module boundaries. A review discipline that converts agent output into committed code only after a human has read it. Without those three, the agent will produce code that compounds into a structure no one can answer for. With those three, the agent’s speed becomes leverage instead of liability.

The k10s team is now installing those three around a fresh codebase. The WorkOS team installed them before the agent ever ran. The cost difference between those two sequences is the rewrite.

Why “Just Be More Careful” Misses It

A reading of the k10s postmortem that ends with “the lesson is to be more disciplined with AI” is the reading that guarantees the next postmortem. Discipline is not a personal virtue. It is an architectural property of the system the team works inside. Antirez held the discipline alone on the Redis Array type because he is one of the most respected systems engineers alive and the project was small enough to fit in one head. Most teams are not antirez and most projects are not small enough for one head. The discipline has to be encoded, not improvised.

We have written about antirez’s four-month Redis Array build as the practitioner version of disciplined AI collaboration and about code smells as the governance layer that survives the AI contributor. The k10s case is the negative space of those posts. Same problem, no encoded discipline, predictable outcome.

What This Means for Your Engineering Practice

Three actions are worth taking this quarter if your team has shipped anything substantial with AI assistance.

First, audit your constraint surface before your next AI-assisted feature. Write down the architectural decisions that are immovable. Write down the modules that own state and the contracts between them. Write down the test, type, and concurrency guarantees that the codebase enforces today. If that document does not exist, the agent is already operating without one, and the next data race is a calendar event, not a surprise.

Second, draw the line between architecture and implementation in writing. Agents are excellent at implementation inside a stable architecture. Agents are catastrophic at architecture under no supervision. The line is the asset. Most teams have not drawn it.

Third, treat the orchestrator as a first-class system, not a script. The WorkOS lesson is that the part of the stack that decides what the agent does, what it can touch, how its output is gated, and how its work is reviewed is the part that determines whether autonomy compounds value or compounds debt. Build that part on purpose.

The k10s rewrite is not the end of vibe-coding as a practice. It is the cost of having tried it on a serious codebase without the surrounding governance. The cheapest version of that lesson is the version your team reads in someone else’s postmortem before writing its own.

The slogan is easy. The constraint surface is the work.

This analysis synthesizes I’m Going Back to Writing Code by Hand (blog.k10s.dev, May 2026) and The Self-Driving Codebase: Building Horizon at WorkOS (WorkOS, May 2026).

Victorino Group helps engineering organizations design the constraint surface that turns AI autonomy into shipping leverage instead of rewrite risk. Let’s talk.