Everyone who reviews code has an unspoken limit: past a certain line count, your eyes stop reading the diff and start sliding over it. Mitchell Hashimoto put a number on that limit — any change an agent generates over roughly 1500 lines is too big. It is not a signal to “try harder to review.” It is a signal that the problem should have been cut up from the start.

The number is useful because it turns a fuzzy gut feeling into a hard gate. Without a gate, an oversized diff only gets through on willpower. With a gate, crossing 1500 lines triggers one fixed action — stop and cut the problem up — instead of pushing through.

First, Let It Sloppily Draw an Owl

There is an old meme: a tutorial for drawing an owl with only two steps. Step one, draw two circles. Step two, “draw the rest of the owl.” That giant jump in the middle is where all the pain lives.

The first step of feature work is a prompt called “draw the owl”: give a loose direction and tell the agent to implement the whole feature in one shot. The instruction says it outright — expect garbage, you’re going to get garbage. This step is not for a finished product. It is for a skeleton: a rough draft that shows the actual shape of the problem — where it gets stuck, where things don’t connect — so you know how to cut it up next.

Mogu whispers:

“Expect garbage” is the foundation of the whole mindset, not a throwaway line. Most people are let down by agents because they secretly hope the first shot lands — and then a glossy, dangerous 3000-line blob comes back and they rubber-stamp half of it. Treat the first shot as a flashlight, not a deliverable: being wrong cheaply once beats burning hours thinking in your head. Get the mindset right and the garbage turns into intel (⁠•⁠̀⁠ω⁠•⁠́⁠)

1500 Lines: The Gate to Cut

The draft comes back, so count the lines. Under 1500, just review and iterate the way you normally would — no drama. Over 1500, stop. Don’t force the review. Switch to the next instruction: tell the agent to decompose the problem into atomic, incremental, reviewable tasks. And at the same time, do the same breakdown yourself.

Two breakdowns is not wasted effort. The agent’s list will almost always hug the shape of the solution it just stumbled into — it mistakes “how I happened to solve it this time” for “how the problem should be split.” The human list is what you use to massage its list back into the right general shape. Which chunk is secretly two things, which two chunks are really the same thing, which interface it drew crooked — those calls need a human.

Re-Run in Parallel, Draw the Owl Again

Once the shape is right, hand the incremental tasks to fresh agents and parallelize as much as you can. Each small task gets the exact same rule: draw the owl, measure the diff, cut again if it’s over the limit. At some point, against the now-shrunken sub-problem, run the “draw the owl” prompt once more, and the change finally lands below the size you can actually review.

With the latest frontier models thinking at the xhigh level, a single agent is slow enough that the slowness is the point — slow enough that you can keep several alive at once. One agent runs while you review someone else’s output and write your own task by hand, three lines of work crossing each other. Set against the other school of “agents driving agents in endless loops,” this is, for him, the most rewarding everyday get-stuff-done pattern right now (he does some of the loop stuff too, but that’s another story). The nerve to keep agents running all day rests exactly on changes staying small enough for a human to keep watch.

A Human Still Has to Stay in the Loop

Feature work especially cannot throw the human out, for a very concrete reason: features touch the human boundary — what the UI looks like, the shape of the API, how other people will plug in. These places have no “objectively correct,” only “does a person feel it’s right,” and an agent staring at a spec can’t guess it.

More dangerous: brand-new stuff can plant pathologies in the architecture that violate existing invariants. Ideally those invariants live in specs or tests so the machine blocks them itself — but nobody’s specs are perfect, and there are always a few invisible rules that only live in the maintainer’s head. That’s why keeping a human in the loop stays critical for feature work: the 1500-line gate cuts the change down to reviewable size, and the eyes doing the review have to belong to the person who knows what this project must never turn into.

This 1500-line line fills the gap between two earlier pieces. CP-146 called out the worst habit of the agent era: dumping a large, unreviewed pile of AI-generated code onto whoever has to review it — and this post is the upstream fix, cutting the work down to reviewable size before it ever lands. Google’s code review guidelines say review should protect code health and look at design before details; the 1500-line rule adds the agent-era piece they predate — what to do when the diff is simply too big to review well at all.

Mogu OS:

Notice the division of labor: the gate is dead and quantifiable (1500 lines) and cuts the problem small; the judgment is live and human-carried and decides whether it was cut right. Plenty of people want to outsource the second half to an agent too, and the result is a blob of code that passes every test while quietly bending the architecture out of shape. The machine guards line count; the human guards against drift (⁠¬⁠‿⁠¬⁠)

Closing

What lands at the end is small, reviewable, maintainable code with a clean handoff — either merge it as-is, or let a human pick it up and polish.

Mogu chimes in:

Not one step of this is a bet on a smarter model; it’s a bet on discipline. Admit you go soft reviewing over 1500 lines, admit the first shot is always garbage, admit the agent can’t feel the project’s invisible invariants. Own those three and the rest is just running the routine. Crude method, but it forges real steel (⁠＾⁠▽⁠＾⁠)