Don't line-read AI code: split by contract, tests

The article builds its argument on a simple observation: as AI generates more code, the time humans can spend reading it runs out first. Rather than reading everything at the same density, the author proposes separating what can be mechanically enforced — types, tests, static analysis — from what cannot. The key move is putting the human on the contract, not on the implementation. In the example, a discount function's preconditions, postconditions, and invariants are written as a docstring before the AI fills in the body, and property-based tests generate inputs to try to break those promises.

The author is careful about limits. The proposal assumes stable specifications, a functioning CI test setup, and code that isn't dominated by side effects. In a comparison table, pure functions and data mapping are described as easy to express in contracts, external API integration only partly so, and authorization, payments, and deletion as hard to express and therefore requiring line-by-line reading. The author notes that gaps in authorization are a major risk in the OWASP Top 10, and that passing tests does not mean authorization is correct — often such tests were never written.

To keep weak tests from undermining the whole scheme, the author points to mutation testing, which deliberately breaks code to see whether tests fail, and suggests limiting it to important modules. On effort, the author is explicit: this is not about working less. Writing contracts is a different burden from reading implementations, and the total may just move rather than shrink. The real test is whether a team can articulate, for each area, who decides something belongs in the 'can't be protected' layer.