Leadership1 publisher3 min readPublished
Evil Martians makes the API contract the artifact humans review in agent-written frontends
The consultancy's ten-check list treats generated code as something to prevent and detect rather than read line by line, which trades review labour for a dependency on whoever keeps the backend's OpenAPI spec current.
The Board Room · Leadership desk
What happened
- Evil Martians published a list of ten checks for frontend projects generating code faster than humans can review, aimed at making that code cheaper to review and harder to let decay unnoticed.
- Its premise is that ten thousand lines a week used to mean a team, complete with institutional memory and someone who knew why each bit of code looked as it did, and now one "person" can produce that volume.
- The post argues the new co-authors do not remember what was agreed yesterday, never answer for production, and will not be around in six months, while responsibility stays with the humans.
- The checks fall into three kinds: preventing code from being written via contracts, types and boundaries; finding what already exists via mutation testing, dead-code detectors and duplicate hunts; and making every check mandatory.
- Scope is frontend TypeScript and React with agents circa 2025-2026, and the post expects half the named tools to be renamed within a year while the categories hold.
Compiled by The Board RoomSomething wrong?How this is made
Why it matters
- constraint The item promising the largest review saving rests on a spec another team owns, so the ceiling on a frontend lead's relief is set by backend discipline rather than by which generator gets picked.
- decision Declaring the generated client off-limits to line-by-line review means choosing on purpose which code leaves the review budget, instead of letting that happen quietly as volume climbs.
- cost Making the checks binding puts the cost on whoever refuses to merge while a release waits; absent that person, every gate in the list is advisory.
- precedent Tuning lint rules to a known model's defaults turns rule maintenance into a recurring chore pegged to model releases rather than a one-time config decision.
Who pays for the first check is more interesting than what it generates. The OpenAPI item works only where the contract is authoritative and the backend keeps it current, and the post tells teams with no spec and no prospect of one to move on to the next check [10]. The review relief a frontend lead gets from it is therefore bounded by a commitment sitting in another team's backlog, which makes it a scheduling problem before it is a tooling one.
The mechanism deserves stating precisely, because it explains why one gate is not enough. The failure named is not broken syntax but a plausible invention: the model sees a user object and writes user.fullName while the backend returns firstName and lastName, and TypeScript accepts that whenever the frontend type was authored separately from the API [6]. Generating types, a client and Zod schemas from the spec makes the line stop compiling [7], and Zod sits behind the types because types are checked at build time while the response arrives at runtime [8]. Two gates, because there are two moments at which the shape can be wrong.
The governance decision is buried in the generated client. It stays in the repository, it is regenerated from the spec, manual edits are overwritten, and nobody writes or reviews it line by line [9]. A team adopting this is deciding on the record that a class of code in its repo will not be read, in exchange for a much smaller artifact that will be. Defensible trade, and better made deliberately than discovered during an incident.
A skeptic would say this is a tooling checklist from a consultancy with frontend work to sell. The text carries no defect rates and no before-and-after on review time; its strongest empirical statement is that unnecessary React effects are the most frequent AI edit in the firm's own practice [14][18]. The post also concedes the underlying problem predates AI, since without a contract the same API shape tends to exist in several places, and cheap machine-written code mainly made cheap hand-written descriptions on both sides [16]. So judge the list on mechanism rather than measurement, and the compile-time-versus-runtime argument survives that test.
Two of the three visible checks put their cost on people, not machines. Strict compiler settings such as noUncheckedIndexedAccess, which retypes arr[0] as element-or-undefined [11], and a lint config the post describes as a filter aimed at a specific writer whose known defaults it targets [12], slow down whoever is in a hurry, model or human. The heaviest rule set, sonarjs, is aimed at what a single line cannot show: cognitive complexity, identical branches, duplicated string literals, nested control flow, the file-level structure that generated code accumulates while reading well line by line [13].
Three of the ten checks are set out in the text available here; the other seven, including the detection tools, are named without their case being made [17]. That matters for sequencing. Prevention gates can be switched on this quarter and their cost lands immediately, on authors. Detection tools report on code already merged, so the first run against a fast-growing codebase is when a team finds out how much of last quarter's output is dead or untested.
What to watch
- Whether the seven undetailed checks put figures behind mutation testing and dead-code detection or leave them at category level.
- Whether the named tools survive the year, given the post's own forecast that half will be renamed while the categories hold.
- Whether any team publishes review-hours or escaped-defect figures for a contract-first pipeline, which would let the payoff be sized rather than argued.