Lauren, who posts as @poteto, argued in a thread on X on 16 October that you earn trust in code written by AI agents by changing the code they work in, not by coaching the agents or reading their output harder. She ranks four levers and says effort should shrink as you move down the list. She calls the shape an inverse pyramid, with the heaviest investment in the first lever and the lightest in the last.
The bottom of her list is human review, which she calls the hardest to scale. She writes that at the pace agents land code, thoroughly reviewing every change is “pretty much impossible.” Her alternative is to put that effort into the setting the agents operate in, so that their default behavior is correct.
Third is prose: comments, rules files, AGENTS.md (a file of standing instructions for an agent) and skills. She limits it to anything that cannot be enforced and needs the agent’s judgment, and says to use it minimally. That ranking cuts against most public advice about coding agents, which is mostly about writing better prompts and longer rules files.
Second is automated checking: lint rules, which flag risky patterns, plus tests, continuous integration, which runs those checks on every change, and formal verification, for which she cites TLA+, a method for proving a design behaves as specified. She calls these “very token efficient.” In plain terms, a lint rule catches a mistake for close to nothing each time it runs, while having a model read the code to find the same mistake costs money every time.
First, and where she wants most of the effort, is the codebase itself. She calls it “just good software engineering”: clearer architecture, stronger types, firm invariants (rules the code guarantees will always hold) and clean boundaries. Her reasoning is the line that anchors the thread. Agents “love to copy what exists and take the shortest path,” so the aim is to “make the easy thing the right thing.” A problem eliminated in code, she says, is one you never think about again.
This is one practitioner’s framework, not a study. The thread contains no experiment, no measurement and no comparison between approaches. Her argument that code fixes are “deterministic” follows from how the checks work, which is reasonable, but it does not show that her ordering holds in practice. The thread also does not say what it costs to restructure an existing codebase, the step the whole ranking leans on.
It also carries a tooling recommendation. The thread ends with an instruction to install a plugin repository, whose link as shown sits under the Cursor organization on GitHub, and a prompt built from slash commands such as /recall, /correct and /architect for readers to hand to their own agent. One command, /poteto-mode, shares her handle, and she tells readers to run /create-verification-skill even while urging minimal prose. The thread does not say whether she works for Cursor or has any stake in the plugins. The four-lever argument needs none of those commands to be tried.
On her logic, a team shipping agent-written code should judge its setup by how many mistakes the codebase lets through unchecked, not by how polished the instructions are. If she is right, an afternoon spent turning a written rule into a check the build enforces outlasts an afternoon spent rewording the rule.
Based on a thread by lauren (on X) of 16 October 2026.
