Thin Routes: Why Agents Fear Your 250-Line Handler

The 250-line route nobody owns

It starts innocently. The agent adds a checkout route: validate, check the user, create the order. Forty clean lines.

Next session adds coupons inline.

Then tax math.

Then a retry loop.

Then "temporary" logging that formats receipts.

By month two the file is 250 lines. Auth beside pricing beside email.

No human reads it end to end.

Thin routes are not a style choice

They decide whether anyone can reason about your endpoints.

Agents make fat routes rot faster than people do. Three reasons.

Agents cannot hold 250 lines in view. They pattern-match. The access check three screens up might as well not exist.

Copy-paste is their favorite reuse. Ask for the same validation on a new route and they duplicate the block. Three routes later, the validation has three truths.

Paywalls die in long files. The check sits at line 12. The branch an agent adds at line 200 returns early, past it.

A skipped paywall is the most expensive bug an agent can add. Length is its accomplice.

What to do

Write the law where agents read it.

Every route does four things.

Validate the input.

Check who is asking.

Make one call.

Return the result.

Put a number on it. About 40 lines.

"Keep routes clean" produces 250 lines. "40 lines" produces extraction. A count settles every argument.

Build the habit into review. Routes swell five lines at a time, and each step feels harmless.

Catch the drift at 45 lines, not at 250.

When a route crosses the line, the fix is always extraction. Never a bigger allowance.

A worked example

Take a route that lets a signed-in user post a feedback request.

The thin version checks who they are.

It checks the title is present and not absurdly long.

It creates the post through the one place that owns posts.

It returns the result.

That is the whole route.

The fat version also formats a welcome email, checks the plan, updates a counter, notifies an admin and logs analytics.

Each of those belongs somewhere else. Moving them out is what makes the route reviewable.

How to thin a route that already exists

Do it in layers, and test after every cut.

Pull validation out first. Then the business logic, one piece at a time. Then side effects like email.

Three small extractions beat one heroic rewrite. If a cut breaks something, you know which one.

Thin against fat

Thin routes mean more files. A newcomer learns the map first.

That cost is real. A file count is easy to navigate. Line-count rot is not.

Know this first

Thin routes mean more small files. Newcomers learn the map first. Some older routes in the kit are longer than 40 lines.

The rule is a target for new work.

Why BoringPush is the way to do this

Short routes are readable routes.

BoringPush gives every route the same four moves.

Validate. Check access.

Make one call. Respond.

Agents copy the shape. Reviewers read it in a minute. Nothing hides.

FAQ

Do thin routes stay thin without constant policing?

Yes, once the check is automated. A line-count check in review plus the 40-line clause in the conventions file makes a violation fail loudly instead of drifting quietly. Agents adapt to enforced constraints within a session or two.

What counts toward the 40 lines?

Everything in the file. No accounting games: the limit's power is its crudeness. Teams that exempt imports end up with 60-line "40-line" routes.

Note that some older BoringPush routes are longer than 40 lines; the rule is a target for new work, not a claim about every file.

Where does middleware fit?

Shared access checks live in one function that every route calls, so the route keeps a single visible line for it. True cross-cutting concerns such as rate limits and logging belong in real middleware or wrappers. Explicit beats magic: a reader sees the protection without hunting through config.

Should Server Actions follow the same law?

Yes. Same four movements, same cap, same extraction reflex. Actions sit beside components, which invites UI logic inside them, so the law matters twice as much there.

How do I thin a 250-line route that already exists?

Extract in layers without changing behavior. Pull validation out first, then the business logic in pieces, then side effects such as email.

Test the route after each cut. Three small sessions beat one heroic rewrite.

Does the 40-line law apply to human-written code?

Yes. Humans rot routes too, just slower and with better excuses. Agents write faster, so structure has to constrain harder.

Keep reading

• Build Features With AI That Don't Need Rewrites — the pipeline this law slots into
• OpenCode SaaS Starter: Stop the Every-Session Redesign — the file the law lives in
• Will Claude Code Respect Your Boilerplate? 6 Tests — the scorecard thin routes satisfy