The one-feature rule: why smaller asks get you better code
In one sentence:A working habit for building with AI: describe one feature, let your agent build it, test it yourself, commit it, and only then start the next one.
What it actually is
The one-feature rule is a working habit for building with AI: you describe one feature, let your agent build it, test it yourself, commit it, and only then ask for the next one. No prompt covers two features. Nothing new starts until the last thing provably works.
Think of a home renovation. If you gut the kitchen, retile the bathroom, and rewire the hallway in the same week, then notice the lights flickering, which job caused it? Could be any of them. Do the jobs one at a time and the answer is always “the last one.” Code behaves the same way. When your agent ships five features in one pass, a bug could hide in any of them, or in the seams where they meet.
The rule sounds slow. It’s usually faster, because the debugging time it saves dwarfs the minute it takes to write four extra prompts. It also protects something the big prompt quietly destroys: your understanding of your own app. One feature at a time, you can follow what changed. Five at a time, you’re a passenger.
Why your AI just did this
Your agent will accept a giant prompt without complaint. Ask for “login, user profiles, and a dashboard” and it produces a plan, edits twenty files, and reports success. The trouble surfaces afterward. The login code imports from the profile code, the dashboard assumes both exist, and when one piece fails you can’t remove it without unraveling the others. Agents are good at generating a lot of code and bad at telling you which tenth of it is the broken tenth.
Scope also decides how sharp the agent stays. A sprawling multi-feature session drags you into the endless “no, fix that” loop that prompt fatigue describes: each fix touches code from three features, and each touch risks breaking a fourth. Keeping one feature in play keeps the diff readable and the agent focused on a single job. It’s also one of the few habits that reliably gets people past the 70 percent wall, because the last stretch of any project is mostly debugging, and debugging stays sane only when changes arrive in small, testable pieces.
When you’ll run into it
The classic moment is the first prompt of a new project: “Build me a recipe app with accounts, favorites, search, and sharing.” What comes back demos well for two minutes. Then a bug appears, and you have no idea which of the four features owns it.
You’ll also meet it in the diff. After a big prompt, git diff shows 25 changed files, and reading it feels like grading an essay you didn’t write. Compare that with the diff after “add a favorites button”: a handful of files you can skim in a minute.
And you’ll meet it when you try to undo. If everything landed in one giant change (or worse, with no commits at all), you can’t peel the broken feature away from the three good ones. The undo is all or nothing, and both options hurt.
What to check
- Write the next feature as one sentence before you prompt. If the sentence needs “and” twice, split it into two features
- Click through the new feature yourself, in the running app, before asking for anything else. The agent saying “done” is a claim; your own click is the proof
- Commit every feature that survives your test, with a message naming it:
git commit -m "add password reset". New to commits? Start with git basics - Switch to plan mode when a single feature still feels big. The plan will tell you whether it’s secretly three
- Keep a plain list of postponed features (a
TODO.mdworks fine), so everything you cut from this prompt has somewhere to wait - Revert the one bad commit with
git revertinstead of asking the agent to undo its own changes from memory
Say it like a dev
Instead of: “build me the login, the dashboard, and the settings page” Say: “Let’s start with login only: email and password, no social sign-in. I’ll test it before we touch anything else.”
Instead of: “you broke something, fix everything” Say: “Search stopped working right after the commit that added the export button. Look at that one diff first.”
Instead of: “undo whatever you just did” Say: “Revert the last commit, then let’s redo the notifications feature on its own.”
People actually ask
“Why does my AI break things when I ask for several features at once?”
Each feature the agent builds in one pass gets woven into the others through shared files and shared assumptions. When something fails, you can't isolate the cause or remove one feature without disturbing the rest. Asking for one feature at a time keeps every change small enough to test, understand, and undo on its own.
“How small is 'one feature'?”
A good test: you can describe it in one sentence without needing 'and' twice, and you can verify it works by clicking through your app for a minute or two. 'Users can reset their password by email' is one feature. 'Add auth' is five or six features wearing a trench coat.
“Do I really need to commit after every feature?”
Yes, and it's the cheapest insurance you'll get. A commit after each working feature gives you a save point you can return to with one command, instead of asking the agent to undo its changes from memory, which it does badly. If a feature goes wrong, you revert one small commit and lose nothing else.
Related terms
Go deeper
Checked against
Just met this in a real session? Glim reads it in plain words.
Paste what your agent just did, a git diff, your terminal, or its summary, and Glim tells you what changed and what to check before you ship. Nothing stored.
Explain my session →