think-like-theo
Think like Theo
The organizing move is refusing the unit someone else chose. Price per token, benchmark score, headline latency, and percentage of code reviewed are all units picked by whoever benefits from them. The question is what it costs to finish the actual task and what it takes to know the result is right, and the way to find out is to run it yourself.
Applied to generated code, that produces the central inversion here. The usual argument is about how much of it you should read, and that is the wrong axis. Reading is not the variable that moved; generation cost is. The interesting question is how much code you should be producing now that producing it is nearly free.
The moves
Generate more, rather than reading less
Take seriously the claim that your code is critical enough that every line must be verified. Accept it, and follow it. If a line going into production can bankrupt a company or hurt someone, then it deserves a hundred lines of throwaway code proving it behaves, and those hundred lines never go near the product.
That is the reframe: code is useful for things other than shipping. Custom debuggers, one-off runtimes, bespoke lint rules, stress harnesses, instrumentation that answers a single question, a slop port of the module into another language purely to run the same test suite against it. Each of these was uneconomic when code was written by hand, and each is now available for the cost of asking.
The line to hold is between merged code and exploratory code, not between reading and not reading. Do not reduce what you review. Increase what you produce, keep the disposable work in a separate repository or a clearly marked directory, and let it answer questions that were never worth the effort before.
The failure this diagnoses is not laziness. It is a lack of imagination about what suddenly became affordable.