AI Breaking Your Webpage Again? Try the Small-Step Verification Method

When using an AI assistant to modify a webpage, the worst part isn't that it can't make the change—it's that it quietly breaks something else in the process. You ask it to switch a button to a blue filled style, the page does look better, but the mobile navigation menu stops opening. Even worse, if you bundle several modification requests at once, there's no way to tell which change caused the problem.

This is an underappreciated pain point when AI coding tools hit the real world: generation speed keeps getting faster, but verification cost hasn't dropped in step. Developer Angelo shared a workflow on Dev.to built around the "small-step edit loop," and the core idea is simple—make only one visible change at a time, declare up front what must keep working, verify immediately after the change, then move on to the next step.

Why changing multiple things at once so easily gets out of control

An AI's modification to a webpage is essentially a local code change, but a webpage is an interconnected system. A button's style change may involve CSS class names, pseudo-class states, event bindings, and layout context; the mobile navigation's expand logic may depend on the DOM structure or style priority that got changed. When you package "change the button color" and "adjust the header spacing" into a single request, the model touches multiple places in one output, and when something goes wrong you're facing a diff that mixes several changes—and the cost of troubleshooting spikes.

The advice from the original article is to shrink the edit loop: pick one visible change, describe clearly which functions must keep working, then check the page before continuing. The value of this loop is that it moves "regression verification" from the last step to every step, so problems are caught the moment they're introduced.

Regression Testing refers to the process of confirming that new changes haven't broken existing functionality. In AI-assisted programming, regression testing is especially important because the model may inadvertently introduce side effects—for example, changing a CSS class name breaks a JavaScript selector that depends on that class. In traditional development, regression testing is usually performed in a batch after a feature is complete; the small-step edit loop breaks regression verification down into an immediate check after each change, which is essentially a "continuous verification" strategy. Its cost is far lower than troubleshooting a mixed diff after the fact, because the problem is located within the context of a single change, and the developer can immediately determine the root cause and roll back.

Draw a clear boundary for each change

"Help me optimize this page" opens just about everything up to the AI. By contrast, only a specific request can be verified. The example instruction from the original article is worth borrowing directly:

Change the primary sign-up button to a blue filled style. Keep its text label, navigation target, and position unchanged. Preserve the visible keyboard focus state. Don't touch the other buttons.

The structure of this instruction breaks down into three layers: what to change (the button style), what must not be touched (label, target, position, other buttons), and the accessibility behavior that must be preserved (visible keyboard focus). The third layer is the easiest to overlook, and it's precisely the part AI most easily breaks when changing styles. Apply this template to the element you're editing—the more specific the constraints, the clearer the verification checklist.

Use element references instead of text descriptions

If the tool supports selecting an element in the preview, use that reference directly to tell the AI which element you mean. If not, fall back to giving the label text and position, or attach an annotated screenshot. The original article points out a detail: two buttons may look similar but serve completely different purposes, and a purely text description can easily lead the AI to modify the wrong object.

Another practical tip is to display the running page and the conversation interface side by side as much as possible. When verifying, look at both the page itself and the AI's description of its own changes—the discrepancy between the two is often a signal of a hidden problem.

Point-and-edit Annotation is an interaction pattern: the developer selects or circles a UI element directly on the preview canvas, and the tool automatically passes that element's DOM path or selector to the AI as context, eliminating ambiguity in natural-language descriptions. Compared with text instructions like "change that blue button to...", an element reference pins down the target precisely, and is especially useful for components that look similar but function differently. This pattern reduces the risk of the AI mistakenly modifying unrelated elements, and also makes modification instructions more concise. Some tools also support annotating regions on a screenshot as a fallback for point-and-edit.

Verification can't just look at appearance

After changing the button, click it to confirm the navigation target is correct; Tab to it with the keyboard to confirm the focus state is visible; narrow the window to confirm there's no misalignment on small screens. If it's a form, additionally test empty submission and invalid value input. The checks listed in the original article all point to the same principle: appearance checks cover only a small part of a change's impact surface—interaction, accessibility, and responsive layout all need their own verification actions.

If you do find a problem, the original article's advice is to stop stacking further changes and have the AI check the latest edit against the last working version. Also get into the habit of saving a working copy or committing code before starting the next change—this is the lowest-cost rollback mechanism.

Keyboard Focus Visibility in Accessibility means that when a user navigates with the Tab key, the currently focused element must have a clear visual indicator (such as an outline or highlight). This is a basic requirement of WCAG (Web Content Accessibility Guidelines). When modifying styles, AI often inadvertently removes the focus indicator by resetting outline or overriding the :focus pseudo-class, leaving keyboard users unable to tell where they are. During verification, besides clicking with the mouse, you should also actively press Tab to traverse interactive elements and confirm the focus state hasn't been broken. This check is extremely low-cost, yet it catches a class of high-frequency regression problems.

The tooling-layer problem Pulse wants to solve

The article's author, Angelo, uses this as an opportunity to introduce Pulse, a desktop tool he developed. His starting point was wanting to see both the code and the result when collaborating with AI, while extra configuration work always pulls attention away from what you're doing. Pulse puts chat, editor, and live preview into a single desktop workspace, supports point-and-edit annotation in the preview, and also includes built-in token optimization, optional smart routing, and local voice settings.

On pricing, the macOS and Windows versions cost a one-time $39, and you need to supply your own API key for a supported model provider, with cloud AI usage billed separately. It should be noted that this section is clearly promotional in nature; the workflow advice in the article has general reference value, but tool selection should still be judged according to your own needs.

Where this method really applies

The value of the small-step edit loop isn't limited to small operations like changing a button. Any code modification involving AI can use it, as long as runtime behavior is involved: one change, one explicit constraint list, one set of targeted verification actions, one commit. It sacrifices a bit of rhythm in exchange for locatable problems and a rollback-able history. At a time when AI generation speed far outpaces human verification speed, this kind of rhythm control is itself an engineering capability.

One-line Summary

AI webpage edits should be small-step: one change at a time, clear constraints, immediate verification—reducing the cost of regression troubleshooting.

Paragraph Summary

The article addresses the problem that AI coding tools easily and quietly break other functionality when modifying webpages, and proposes a "small-step edit loop" workflow. The core practice is: let the AI change only one visible thing at a time, declare in advance which functions must keep working, and verify immediately after the change before moving on. Modification instructions should include three layers of constraints—what to change, what must not be touched, and which accessibility behaviors must be preserved. Verification needs to cover click navigation, keyboard focus, narrow-screen layout, and invalid form input; it can't just look at appearance. When a problem is found, stop stacking changes, check against the last working version, and get into the habit of saving a working copy. The article also introduces the desktop tool Pulse, which integrates chat, editor, and live preview and supports point-and-edit annotation, though it is promotional in nature.