Change request: one small update

I have been in a situation where I wanted to make one minor change in an app and ended up ruining much more than that.

The request looked simple. Change a logo. Update the UI on one page. Fix one button. It felt like the kind of work AI should complete quickly.

So I would tell it: make change A. Then change B. Then change C.

What I did not realize was that each small change could be connected to something else in the app. By the time I tested the result, it was not only fixing the thing I asked for. It had also changed things that were related to it in the background.

That is how a small update can become an AI slop loop. You keep fixing the next problem, but you slowly lose sight of the stable product you started with.

What the request did not say

My early prompt would be something like this:

Change the UI on this page to the newer model we are implementing.

It tells AI what to change, but not what to leave alone.

That missing part matters.

Think about a filter button. It may look like one button, but its behavior can be connected to other filters, columns, backgrounds, or the way information is shown. AI may see those related parts and make changes that look sensible from its point of view.

But I may not want those changes yet.

The same thing happened when I was building a form for commitments. I wanted to improve how an amount such as 5.99 was added. But a change in that form also affected how totals appeared elsewhere. The decimals began taking up space, numbers wrapped onto another line, and the whole layout started looking unstructured.

The form was only one part of the app. The impact was larger.

The first task is not “change it”

I now try not to begin with implementation.

I begin with analysis.

Before AI changes anything, I ask it to check what the request is connected to and tell me what else might need to move with it. If changing one button affects two other buttons, I want to know that before the change—not after I discover a broken screen in testing.

This gives me a decision to make.

Maybe those other changes are necessary. If they are, I can approve them deliberately. If they are not, I can tell AI to leave them alone.

That is different from asking it to make one change and hoping it understands the rest.

My change boundary now

Once I understand the impact, I give AI a clearer boundary. It looks more like a change ticket than a casual request.

TASK: Change [the exact screen, button, form, or behaviour].

DO: Make only this agreed change.

ANALYSE FIRST: List the related files, features, and user flows this could affect. Do not implement until I approve the scope.

DO NOT: Change unrelated UI, behaviour, documentation, code, data handling, or other features without asking first.

CHECK: Tell me how the change should be tested, including related screens or values that could be affected.

REPORT BACK: Show what changed, what did not change, what you tested, and anything still uncertain.

The “do not” part is important for me. In fact, it can be longer than the “do” part.

I do not mean that AI should never touch code. A code change may be needed. I mean it should not change code, documentation, screens, or behaviour outside the scope I have approved.

And if the analysis shows that the small request needs two more changes to work properly, I do not want AI to decide that on its own. I want it to show me the connection, explain why, and wait for me to say yes or no.

The check that keeps the change small

After the work is done, I do not only read a summary saying the task is complete.

I test the app. I look at the part I asked to change, then the related parts that the analysis identified. I check the layout, the values, the user flow, and anything that could have moved in the background.

I also keep the work documented and keep a stable version of the product in GitHub. If a change creates more problems than it solves, I do not want to wonder where the working version went. I want a clear place to return to and a record of what changed.

This is not only an AI habit. A normal code-review process works in a similar way: look at the actual changed files, run checks, and decide whether the change is ready before merging it. GitHub’s review guidance explains why reviewing a diff can catch bugs and logic errors while the work is still fresh.

I have written before about choosing the right level of review for each task. I Do Not Review Every AI Task the Same Way explains that part in more detail. For product changes, I now know that the review starts before AI writes the first line.

The decision I keep for myself

AI can make a focused change quickly. It can also point out relationships I may have missed.

That is useful.

But it should not decide the scope of the change just because it found other things that could be improved.

My rule now is simple: analyze first, agree the boundary, make the change, test the result, then move forward.

It has helped me stop treating every small fix as a new guessing game. More importantly, it has helped me keep a working product while I improve it.