What is the smallest fix?
It is the least code you can change to make the bug go away, and nothing more. For the bakery basket, that is one line: the count starts as the text '0' when it should be the number 0. Every other line on the page already works.
AI assistants don't aim for the smallest fix by default. Asked to fix something, they often improve, refactor and restyle at the same time, because the examples they learned from are full of cleaned-up code. Each extra change is something you have to read and test, and something that can break. Asking for the smallest fix keeps the answer the size of the problem.
What is wrong with the bakery basket?
Press **Add to baskit** in the Preview a few times. The basket shows 01, then 011, then 0111. You expected 1, 2, 3. The pattern is the clue: something is gluing characters together instead of adding numbers.
In JavaScript, + adds two numbers, and joins text when either side is text. The script sets count to '0' with quotes, which makes it text. So count + 1 becomes '0' + 1, which is '01'. There is no error in the console, because joining text is perfectly legal. Only the expected-versus-actual numbers show the bug.
This is why the request needs the numbers you saw. “The basket count is wrong” could mean it doesn't change, goes up by two, or resets. “It shows 01, then 011” has only one likely cause, and an assistant, or a colleague, can name it straight away.
let count = '0'; // text
count = count + 1; // '01'
let count = 0; // number
count = count + 1; // 1How do you ask for the smallest fix?
Say it directly: “give me the smallest fix”, “only change what is needed” or “change as few lines as possible”. Then give the evidence: the script, what you expected and what happened. The **Prompt check** view ticks Small step when your request asks for one, and the lesson's limits ingredient ticks when you say what must stay the same.
Send this in the practice area. The reply names the one line, explains why it is wrong, and returns your own page with that line changed.
On my bakery menu, the basket count goes wrong. When I click Add the first time it shows 01, then 011. I expected 1, then 2. Please give me the smallest fix, only change what is needed. Here is my script:
let count = '0';
document.querySelectorAll('.add').forEach(function (btn) {
btn.addEventListener('click', function () {
count = count + 1;
document.getElementById('count').textContent = count;
});
});What happens when you ask without that limit?
Send the same evidence without asking for a small fix and you get the rewrite reply. It does fix the count. It also moves the menu into a JavaScript array, renders it as cards, saves the basket in localStorage, changes your colours and fonts, and renames the page. Read the array carefully: the lemon tart is missing.
Every one of those changes might be fine on its own. Together they turn a one-line fix into a new page you haven't read. Your Sunday customers don't care that the code is “more scalable”; they care that the lemon tart is still on the menu. Rewrites are also how old bugs come back and new ones arrive, because nobody reviews four hundred changed lines as carefully as one.
How do you check that only one line changed?
Press **Use this code**, then open the **Review** view. It compares the assistant's code with yours and highlights each line you change from now on. Before you edit, read the reply's code side by side with what you had. On a real project, a diff tool does the same job: git diff shows every added and removed line since your last commit.
For this fix, the only difference is let count = '0'; becoming let count = 0;. Then test: press each Add button and watch the count go 1, 2, 3. A small fix is quick to check, which is the whole point.
Should you make small fixes yourself?
Often, yes. The buttons say “baskit”. You don't need an assistant for a typo: change the word, check the Preview, done. Making small edits yourself keeps you familiar with your own code, and it is faster than writing a request and reviewing a reply.
A good rule: ask the assistant when you don't know why something is broken, and fix it yourself when you do. Once the assistant has explained the cause, like text versus numbers here, you can usually spot the same problem elsewhere without asking again.
When is a bigger change the right answer?
Sometimes the smallest fix is a patch over a design that keeps causing bugs. If the same kind of bug keeps appearing, or the code is so tangled that every fix breaks something else, a rewrite may be worth it. Make that a separate, deliberate decision, never a side effect of fixing a typo.
A useful test: could you explain to a friend why the bug happened? If yes, a small fix is almost always enough. If the answer is a shrug and “the code is a mess”, it is time to plan a restructure, in daylight, with a commit behind you and a list of what the page must still do afterwards.
When you do want a bigger change, still ask for it in steps. Fix the bug first with the smallest change and commit it. Then ask for the restructure as its own request, review it as new code, and test every feature the old version had. A list of those features, written before you start, makes the check much easier.
How does this compare with real AI tools?
The pretend assistant here picks from fixed replies, so asking for the smallest fix always gets the one-line answer. Real tools are less predictable. Even when you ask for a minimal change, some will still reformat code or rename things. Others follow the request closely. Either way, the Review habit protects you: compare, read every changed line, test, and undo anything you didn't ask for.
If a tool keeps rewriting more than you asked, make the request narrower. Paste only the lines around the bug and ask for the corrected lines back, rather than the whole file. Then you apply the change yourself, and nothing outside those lines can move.
Field notes
- The smallest fix changes only the code needed to remove the bug.
- Assistants don't aim for small fixes by default, so ask for one in plain words.
- In JavaScript,
+joins text when either side is text, which is why 0 became 01. - Fix tiny problems like typos yourself; it is quicker than asking.
Easy to get wrong
A request without a size limit invites a rewrite. Asking for the smallest fix keeps the change easy to review.
Rewrites drop menu items, change prices and add libraries without saying so. The bug being gone tells you nothing about the rest of the page.
It is faster, and you stay in charge of your own code. Save requests for problems you don't understand yet.
Questions people ask
Why does JavaScript join instead of add?
The + operator does both jobs. If either side is a string, it joins them as text. Values from inputs and many APIs arrive as strings, so this bug is common. Number(value) turns text into a number.
What if the smallest fix doesn't work?
Then share what happened after the fix: the new error or the new expected-versus-actual numbers. Keep asking for small changes, one at a time, so you always know which change did what.
Is it rude to tell an assistant not to change things?
No. It has no feelings to hurt, and clear limits get better answers. The same request works well with human colleagues too.