The Best Instruction You Can Give an AI Coding Agent: 'When Uncertain, Do Less'

Ask a human teammate to fix a typo and you get a fixed typo.

Ask an AI coding agent the same thing and you might get the typo fixed, the surrounding function "cleaned up", two variables renamed, and a note about how it also improved the error handling.

Each change might be defensible on its own. Together they turn a ten-second review into a twenty-minute one, and you now own a diff you didn't ask for.

The agent isn't being malicious. It is being helpful with no idea where "helpful" stops.

The principle

UNIVERSAL-AGENTS.md ends with one line:

When uncertain, do less, not more.

Everything else in the file is an elaboration of it. Here is what it looks like in practice.

"Beneficial" is not "in scope"

Section 25 has my favorite sentence in the whole file:

A change being beneficial does not make it in scope.

That sentence is aimed squarely at the agent's strongest instinct. Most unwanted changes are good ideas: a cleaner name, a modern syntax, a dependency that's two versions behind. The rule acknowledges they might be improvements and still says no, because the request defines the work.

Section 8 backs it up with a list of reasons that don't justify touching a file: it could be improved, its formatting could be modernized, its naming could be clearer, its dependencies could be newer, its tests could be expanded. A possible improvement is not automatically part of the requested work.

What if the agent finds a real bug?

This is the interesting case. While working, the agent spots an unrelated problem. Sections 8 and 14 give a narrow path:

Fix it only if it directly prevents the requested change from working, or you explicitly authorize the fix.

Otherwise:

• Don't fix it silently.
• Don't redesign the surrounding code.
• Mention it only when it materially affects the requested work.

It's a deliberate trade-off. The agent doesn't smuggle in changes you'll discover during review, and it still flags problems that matter.

What to do when the request is unclear

Doing less also means not guessing. Section 2 says that if a request is ambiguous, incomplete, contradictory, or in conflict with the project, the agent should:

1. Stop before implementing.
2. Identify the specific ambiguity or conflict.
3. Ask the minimum number of questions necessary.
4. Wait for clarification.

And never guess requirements that materially affect the implementation.

Note the word minimum. An agent that fires ten clarifying questions at you is just as annoying as one that guesses. The goal is one or two sharp questions that unblock the work.

The priority order settles arguments

When goals conflict, Section 1 gives an explicit order: explicit user requirements, then correctness, then safety and security, then existing architecture and conventions, then minimal scope, then reuse, then maintainability, then documentation consistency.

That order answers