Sebastian Schkudlara
AI can write a lot of code before I have finished deciding what the feature actually needs.
That speed is useful. It also creates a very specific kind of mess. You ask for a small change and get a correct implementation surrounded by a new helper, a configuration layer, an abstraction for the helper, and comments explaining why all of it may become useful later.
Nothing in the patch looks completely absurd. That is what makes it dangerous.
The tests pass. The feature works. Six months later, somebody has to understand all of it.
Passing tests does not make complexity free
Most code review asks sensible questions. Does the implementation match the requirement? Does it handle failure? Are the tests real, or are they decorative?
I wanted Lope to ask one more question:
Is this patch larger than the problem?
That question sounds subjective until you look at the usual evidence. An abstraction has one caller and no job of its own. A setting has one possible value. A new path duplicates something the project already does. Half the code exists to support a future nobody has committed to building.
Every extra layer charges rent. The bill arrives as slower reviews, harder debugging, and riskier rollbacks.
Minimal does not mean clever
There is a bad version of minimalism where everything becomes one compressed function and the author feels very smart. I am not interested in that.
Good minimal code can be boring. It still has clear names, tests, error handling, and enough documentation to explain the non-obvious parts. It simply refuses to build machinery before the machinery has a job.
For me, a useful minimality review comes down to a few checks:
- Does this use a path the project already trusts?
- Which pieces can disappear without changing the result?
- Are we solving today’s requirement or rehearsing for an imaginary roadmap?
- Would the smaller version be easier to verify and undo?
If a reviewer cannot suggest a concrete smaller version, “simplify this” is not much of a finding. It is a mood.
Lope now asks this during engineering work
In the recent Lope v0.13.1 work, engineering execute reviews and implement prompts gained a minimality audit in the normal quality path. Spec review and deterministic evidence checks stay separate.
The default audit is advisory. It does not reject code because it has a high line count, and it does not block an otherwise correct change. Sometimes a large change is exactly what the problem needs. The audit looks for avoidable machinery and asks the reviewer to name a safer, smaller replacement. Teams that want material bloat to block a run can opt into the stricter mode.
That distinction matters. The point is not to make the diff look tidy. The point is to keep the proof surface small enough that another person can reason about it.
Independent review helps here because the implementation agent has momentum. It has already chosen an approach, created the files, and made the pieces fit. A separate reviewer has less emotional investment in preserving the construction.
Sometimes its most useful contribution is: delete this layer and call the existing function.
The second question
I still want to know whether AI-generated code works.
Now I also want to know what we can remove.
The first question gets a feature over the line. The second decides how much of that feature the team will still be carrying next year.