Theo on Disposable AI Code and Verifying Important Software

How much AI-generated code should engineers read? My provocative answer is that many people read too large a percentage of what they generate. The more important part is that they may not yet be generating enough code for experiments and verification. That is different from saying critical production code should escape review.

Think of software on a spectrum: a tiny side project with one viewer is at one end, and firmware for a pacemaker is at the other. A failure can have vastly different consequences. I think online arguments often go wrong because people assume their own place on that spectrum applies to everyone else.

For the sake of the argument, assume every line of your shipped code is so important that a mistake could cost a life. In that case I agree that every shipped line deserves careful human review. My argument is about the additional code you can create around it, not about weakening that review.

Code can be useful without ever becoming part of a product. You can write a separate tool, experiment or test to investigate a hypothesis or check important behavior. If producing a program becomes cheaper, more of these previously uneconomical investigations become possible.

I make up some numbers to illustrate the old workflow: perhaps I read 1,000 lines a day, wrote 200 and merged 100. Code was expensive to produce, and code intended for production went through review. These are illustrative figures, not measurements or a recommended productivity target.

Now imagine reading a similar amount but generating 2,000 lines and merging 500. The apparent gap between generated and read code sounds alarming until you ask what the rest is for. Much of it may be discarded after testing an idea rather than submitted for review or merged.

Previously, writing a large amount of code for a one-off question was hard to justify. I might have added analytics to a product and written SQL to answer a user question, but that took time. Cheaper generation makes it more plausible to produce a temporary program for a specific question.

Consider a financial ERP system where a mistake could cause substantial losses. My proposal is not to merge unreviewed output into it. Keep the scrutiny appropriate to the system, and consider additional generated checks, debuggers and experiments around the important code.

I use exaggerated ratios—hundreds or thousands of verification lines for a line of production code—to make the point that verification can be much larger than the code it examines. Those numbers are rhetoric, not a safety standard: line count alone does not establish test quality or coverage.

If the existing test harness is itself important, I suggest experimenting at another layer: tools that inspect runs, logs or assumptions without replacing the vetted process. A generated checker can also be wrong, so its results need interpretation and independent validation before they support an important decision.

A viewer says most generated code goes into test harnesses and guardrails, with the agent receiving the results. That is the kind of use I mean. Whether you write or review the production code and tests by hand, the extra experimental layer can help explore possibilities that were previously too costly.

Suppose a safety-critical engineer previously wrote and verified 100 lines and read 200 in a day. I am not asking that engineer to stop checking the important work. The numbers are hypothetical: the point is to preserve the established verification process while considering additional ways to investigate.

In my example, the engineer might write and verify 80 lines, read 400 and generate 800 lines of exploratory code kept outside the product. That disposable code could probe assumptions and exercise the 80 lines. Its usefulness depends on whether the checks are sound and appropriately isolated, not on the volume generated.

I wrote a large amount of JavaScript to organize roughly a hundred files on my Windows computer. Doing that by hand would have been hard to justify. My point is that a program can be a disposable instrument for one task rather than a permanent feature someone must maintain.

Generated code can still be poor, and unverified code in important systems can cause harm. I agree with critics on that. My claim is that cheaper generation gives us another way to investigate and verify; it does not make the generated output automatically trustworthy or free of operational risk.

Examples from my own work include custom lint rules, one-off debuggers, instrumentation for React code and load-testing experiments. These tools let me ask questions I might not previously have spent time implementing. Their results are evidence to inspect, not a guarantee that a system is correct.

My distinction is between making critical code cheaper and creating more cheap code around it. I am advocating the latter. Reading code takes time and care; the goal is not to rush unsafe changes into production but to find more ways to improve the code that matters.

I draw a funnel of importance. At the top are disposable experiments; lower down are things I would like to work, then business-critical systems, and finally software where a failure could kill someone. These are illustrative categories, and one engineer’s work can span several of them in the same day.

Historically, producing throwaway code could cost as much effort as writing carefully maintained code. I think that cost discouraged exploration. With generation, an engineer working on critical firmware can preserve the strict boundary around it while doing more experiments outside that boundary.

For my projects, different parts deserve different attention. I like a suggestion to ask an agent for a file-by-file summary of a large diff, then investigate anything surprising. A summary can help navigate a change, but it can omit or misstate details; how much direct review is needed depends on the consequences and the team’s process.

In Lakebed, I read all the function signatures and API definitions because their quality affects future maintenance. I also generate small applications with multiple agents to see whether they can use a new API. If the experiments reveal confusion, I can improve the interface before shipping it.

Existing tests, harnesses and wrappers for safety-critical work may also deserve careful review. On top of those, an agent might try several one-off theories, write additional tests or make an experimental port to compare implementations. An experiment that will never merge can still answer a useful question.

I understand the resistance because the loudest examples of AI coding can be careless output shipped to users without adequate checking. I dislike that too. But poor examples do not eliminate the potential value of disposable experiments used to support a responsible engineering process.

I also use AI to review code before bringing it to my team, often asking multiple agents to check it. That can produce useful feedback, but model reviews can miss defects or agree on the same mistake; they supplement rather than guarantee independent verification.

My closing request is to be more creative about what code can do. Treat some programs as disposable instruments for one question or theory, and keep the appropriate review for the code and evidence that matter. The aim is better verification, not an excuse to ship unsafe output.