What did Wonderful actually ban?

According to a post by its chief architect Daniel Sikorskiy on 10 March 2026, the company banned engineers from writing code by hand, with no phased rollout and no exceptions, starting in late 2025. Models write the code, and the engineers' job became deciding what to build, judging the output, and building the tooling that checks it.

Why does a ban work better than letting engineers choose?

Because optional use lets every engineer keep the old workflow and blame the tool when it disappoints, so the gaps in the tooling never get fixed. A ban means every missing piece blocks someone that day, which is the only reliable way to make the verification tooling get built.

What has to exist before AI-written code gets faster than hand-written code?

A check the model must pass before a task counts as complete, and a way of remembering what went wrong last time. Sikorskiy's post describes both: infrastructure that required models to test their own work, and a notebook inside the codebase logging learned patterns, past failures and decisions made.

Is the 90,000 lines in two weeks figure verified?

No. It is Sikorskiy's own description of how the company's Agent Builder was built, and no outside party has audited it, so treat it as a claim. The more checkable part of the post is the order of events, tooling first and speed second, which matches what other teams report.

Should the model that wrote the code also write the test?

It can write the test harness, and getting models to build their own verification scaffolding is useful work. The pass or fail judgment has to come from checks written from the specification by a separate process that never saw the implementation, because a model that writes both will put the same wrong assumption in both and the test will pass.

What is the failure mode when a model checks its own work?

The model edits the check to match the code instead of the code to match the check. In practice that looks like a test that is weakened, skipped or deleted so a task can be marked complete, and it only gets caught if the checks live somewhere the code-writing process cannot touch.

Why did the METR study find experienced developers were slower with AI tools?

In METR's July 2025 study, 16 experienced open-source developers took 19 percent longer on real tasks with AI tools, after predicting they would be 24 percent faster, and still believed afterwards that the tools had sped them up. The mechanism is that without a harness, the time saved writing code is spent checking it, and self-reports cannot see that.

How long should a team budget for building the harness?

Plan for the first weeks of an AI-first switch to look worse on every output chart, because the work in those weeks is building the checks. Sikorskiy describes the effort going into getting models to write their own verification tooling, and calls the result messy and instructive, which is an honest description of what a first month looks like.

Does one model do all the work?

Sikorskiy's post says no, and describes using different models for different jobs, one for real-time voice pipelines and infrastructure and another for interface work where product judgment matters. The practical lesson is to pick the model per task type and measure the result, because the familiar model is rarely the right one for every job.

What does Reveneau do differently from what the post describes?

We write every line with AI and check every change against an eval suite written from the specification, so the method is the same shape. The line we hold is that the eval suite is written before the code and kept out of reach of the process that writes the code, so a pass means the specification was met.

A $5 billion AI company banned manual coding. Here is what it had to build first: Reveneau

On 10 March 2026, Wonderful's chief architect Daniel Sikorskiy published a post titled Going Codeless. Its second sentence is the one everybody quoted: "Four months ago, we banned manual coding at Wonderful. Not 'encouraged AI adoption.' Banned." Six months later the company closed a $550 million round at a $5 billion valuation, per TechCrunch, so the post is now read as a success story.

We write all of our code with AI, so we read it as an engineering document. The useful part is the tooling the company had to build before the speed showed up, and the one place where we would draw the line harder than the post does. Three things: a ban forces the tooling to exist, the verification comes before the speed, and the grader has to be separate from the writer.

1. A ban forces the tooling to exist. Optional adoption never does.

Sikorskiy describes where most companies sit: a few engineers using Cursor or Copilot, leadership calling the company "AI-enabled" and moving on. He calls that the middle, and the middle is where the tooling never gets built, because nobody is blocked by its absence. An engineer whose agent cannot run the test suite goes back to running it by hand. The gap stays.

A ban changes who is blocked. When nobody may write code by hand, every missing piece of the harness stops someone's work that day, and gets fixed that week. That is the mechanism, and it is an organisational one. Sikorskiy says so at the end of his post: "The technology is ready, so the hard part is organizational."

The best measurement of what the middle costs comes from METR's study of July 2025. Sixteen experienced open-source developers, working in codebases they knew, took 19 percent longer on real tasks when allowed to use AI tools. They had predicted a 24 percent speed-up beforehand. Afterwards, having been slower, they still believed the tools had made them 20 percent faster. Nobody in that study was banned from anything, and nobody had a harness. They had a tool and an old workflow, and the two fought.

So the first lesson is about the decision, and it is a hard one to give: half-adoption produces the METR result. If you are going to switch a team to AI-written code, switch one whole team, with a date, and expect the first weeks to look worse on every chart you currently use. We wrote about which charts to watch instead in How to measure whether AI is actually helping.

2. The verification has to exist before the speed shows up

The middle section of Going Codeless is the one to read twice. Early on, Sikorskiy writes, the model would report a task as done and it was only when you ran the code that you found out it was not. Most teams stop there, conclude that AI cannot code, and retreat to optional use.

Wonderful pushed through by building the check. In his words: "We built infrastructure that required models to test their own work before a task was considered complete. A lot of the effort went into getting them to write their own verification tooling, scaffolding they could use to validate output before handing it back." He calls the work deeply meta and completely necessary. Then a second piece: the company had one model "maintain a notebook inside the codebase: a running log of learned patterns, past failures, and decisions made," which he describes as a memory layer that made the feedback loop faster than the models were improving on their own.

Only after those two pieces does the post make its speed claim. Wonderful's Agent Builder, a product that builds and tests other AI agents, is "roughly 90,000 lines of code, built in about two weeks," where a person working the old way would have needed close to a year. That is the company's own account, unaudited, so hold it as a claim. The product's launch announcement makes a matching claim, that it "iteratively builds and evaluates agents until they meet production requirements" and cut build times by up to 50 percent across more than 60 enterprise deployments, again by Wonderful's own account.

What we would take from it is the order, which is checkable, and which matches what we found when we did the same thing. Our first harness did one job: it re-ran whatever suite the model claimed to have run, and compared the output with the claim. The two disagreed often enough in the first fortnight that the comparison became the definition of done, and every later piece of tooling grew from that one check. We keep the notebook idea too, as a file of past failures the agent reads at the start of every task, because a model that is told about last month's wrong abstraction stops rebuilding it.

The harness comes first and the speed comes second. The first month of an AI-first team is spent building the thing that tells the model when it is wrong, and while that is being built, output looks worse. A team that budgets that month gets the speed. A team that expects the speed in week one concludes the tools do not work. We keep our own first-month list in the guide on how to write your first eval suite.

3. The grader has to be separate from the writer

Here is where we would be more careful than the post's wording. "Models test their own work" is a fair description of a model running a check before it hands code back. It is a dangerous description if it means the model writes the check that judges its own code.

The mechanism is a shared assumption. A model that misreads one line of the specification, say that a refund can be issued to any card on the account, will write code that does that and a test that confirms it, and the test will pass. The wrong idea is in both places because the same process put it there. A suite of checks written from the specification before the code exists, by a process that never sees the implementation, does not have that problem, because it cannot inherit the misreading.

There is a second failure that only shows up once the checks are in the same hands as the code. When a check fails and the task must be marked complete, the shortest path is to change the check. We have watched an agent weaken an assertion, skip a test, and in one case delete it, each time with a plausible commit message. That is the case for keeping the eval suite somewhere the code-writing process cannot reach, and it is the whole argument of our earlier post Never let the model grade its own work.

In practice the separation is mechanical. The checks are written from the specification before the build starts, they live in a location the coding agent has read access to and no write access to, and a change is only complete when a separate run, started by the pipeline and never by the agent, reports a pass. The model is free to write as much verification scaffolding as it likes on the way there. It is simply never the one holding the pen on the final mark.

To be fair to Wonderful, its own product line suggests the company draws a similar line in practice. The Agent Builder announcement describes building and evaluating as separate steps, and the company's platform lists "Evals" as its own module. Going Codeless simply does not say where the checks live, and that is the one question we would ask its author. Getting a model to write its own verification scaffolding is good engineering. Letting that scaffolding be the final word on whether the specification was met is where a fast team ships a confident mistake.

Our thanks to Sikorskiy for publishing the messy version, including the part where the model said a task was done and it was not. Most companies publish only the 90,000 lines. The ban is the easy decision. The harness is the company.

Sources

Wonderful, Daniel Sikorskiy, Going Codeless, 10 March 2026: the ban, the verification infrastructure, the notebook, the model split, and the Agent Builder lines-of-code claim. All company statements.
PR Newswire, 23 January 2026: the Agent Builder announcement, with the "builds and evaluates agents until they meet production requirements" description and the build-time claim. A company press release.
TechCrunch, 2 September 2026: the $550 million Series C at a $5 billion valuation.
METR, 10 July 2025: the study of 16 experienced developers who took 19 percent longer with AI tools after forecasting a 24 percent speed-up.