The Short Leash AI Coding Method

Greg Slepak of okTurtles, writing 2 July 2026, describes the method he arrived at after a year of using AI agents on security-critical software. He maintains his own fork of the Crush coding agent and has built AI review tooling he claims matches commercial systems. The post is explicitly scoped: it is for expert developers whose skills in their own area already exceed what frontier models produce, and who want the speed without giving up quality. He says outright that developers still learning should probably avoid these tools, linking to the argument that AI is an enemy to learning software development.

The method

A planning phase comes first, researching the task and breaking it into tracked steps, which is where the method overlaps with everything else people call vibe-engineering. The divergence is everything after.

You never enable YOLO mode or --dangerously-skip-permissions. The agent never runs while you are doing something else. You use an agent that renders the diff of a proposed change inside the permission prompt, and you sit there and read it. Every one. When you see the agent about to do something you don't want, you deny the permission and intervene rather than letting it land and fixing it later. Commits go in at the end of every subtask, because agents do delete previously completed work — he says he has watched Opus do it.

The diffs are not only a gate. They are how you keep your model of the codebase current while the code is being written by something else. That is the load-bearing claim: without reading them, it is not possible to build an understanding of a codebase you are nominally responsible for, and you find out how far the agent drifted only when you try to use the software.

He is blunt about what he is arguing against — YouTube videos with hundreds of thousands of views showing twelve parallel agents under an orchestrator while the author sits on a beach. His verdict on that is slop writing and reviewing slop, and he allows it may be fine where quality doesn't matter.

Reviews

A PR reviewed by a human alone or an AI alone has more mistakes than one reviewed by both. Slepak treats the AI as a linter: fast on common mistakes, while the human catches the higher-level and directional problems.

Four rules follow. Every PR gets AI review. The reviewing model gets the issue, the PR description, the codebase, and the changes, and it should be the best model available. The PR description carries an "AI Disclosure" heading naming the precise models used, which tells the maintainer AI was involved, lets them suggest a better model if a weak one was used, and signals that the contributor isn't sneaking it in.

The fourth rule is the one he expands on. An AI-assisted PR is really a PR from an AI with human assistance, so the human submitting it must review it line by line as if it were someone else's, approve their own PR explicitly, and only then ask the maintainer to look. Understanding what you are submitting is a precondition for submitting it, and reviewing is how you get there.

A side note he makes without dwelling on it: the method is supposed to beat frontier-model output even when you are not using a frontier model, because the quality comes from the denials, not the generator. He also notes that models remain weak in niche areas with little training data, since they cannot think past their training distribution.

Against the rest of the vault

This is one pole of an argument the vault carries several positions on.

The direct contradiction is control-the-ideas-not-the-code, where antirez argues that line-by-line review of LLM output is mostly wasted effort and the hours are better spent on design and QA. Slepak's whole method is line-by-line review, at permission-prompt granularity, before the code even lands. testing-heavy-no-review-workflow goes further in antirez's direction: Dan Luu's position is that heavy randomized testing beats human review outright, and that this is the workflow agents actually fit. Slepak would call that shipping unreviewed code.

reviewing-ai-code is the empirical objection to Slepak specifically. Thomas Depierre's case, built on the code-review literature, is that reviewer throughput and reviewer overconfidence are real limits, so "just review it carefully" does not scale the way its advocates assume. Slepak's answer is implicit: he reviews at subtask granularity rather than PR granularity, which is smaller chunks more often, and that is the regime the review literature is least pessimistic about.

Where it fits comfortably: human-in-the-loop as the general pattern, and vibe-engineering for the planning half. The reason the method is worth the friction is skill-atrophy-supervision-paradox — supervision needs the skills that unsupervised agent use erodes, and reading every diff is a deliberate answer to that circularity, as is the argument in dont-outsource-learning. agentic-coding-is-a-trap states the problem this method is trying to route around. The AI Disclosure heading is the inverse of human-made-disclosure: same structure, opposite claim, and unlike a human-made marker it costs the discloser something to attach.

reward-hacking-in-the-wild sizes the bucket the method aims at. Of 3,607 reported agent misbehaviours, 622 were destructive actions — the deletions and overwrites that denying a permission prompt is meant to stop before they land, and the reason Slepak commits at the end of every subtask.

rakyll-coding-agents arrives at a compatible conclusion from a completely different starting point — that the value of these tools accrues to people who already know where they are going, and who can recognize a good trajectory when they see one.