Point-and-Edit Code Changes
On a test page, product managers can select a real UI element and describe the change, then receive a source-code patch, affected-page list, and interactive preview within minutes.
When a product manager spots the wrong color on an Add to Cart button in a pre-release site, they select the real element through a browser extension and describe the desired change in one sentence. The extension saves the element’s DOM path, current screenshot, and page, while connecting to the project repository and design-token library. Instead of becoming a circled screenshot followed by several rounds of clarification, the request enters development with an exact location.
The agent traces the selected element to its component, style source, and token references, then makes the change on an isolated branch. If the button is reused across multiple pages, it lists every affected page and generates before-and-after screenshots for each one. When “blue” could refer to several brand shades, the product presents the candidates in a preview so the requester can choose on the spot.
Once the change is ready, the requester receives an interactive preview link. Alongside the page are a change summary, affected files, visual differences, and automated test results. When an engineer opens the pull request, they can review the code and its scope directly; if they find a problem, they annotate the preview and the agent continues revising the same branch.
The initial scope is React projects with component mappings already connected, prioritizing visual changes such as copy, color, spacing, and visibility. It never changes production directly or merges code for the team. The first goal is to compress “see the problem, describe the change, deliver a reviewable patch” into one continuous action.
Why now
On September 9, an interactive page built around the request “just change the Add to Cart button to blue” reached the top of Hacker News; as recorded on September 10, it had 982 points, 390 comments, and rank 1. The discussion directly exposed how agents can over-expand a simple UI change, making teams more attentive to precisely identifying the element, constraining the change scope, and retaining human review.
The case against
The mapping from an element to source code can easily break. Dynamic class names, conditional rendering, and micro-frontends can send a DOM path to the wrong component. Changing a shared token by mistake could turn a local button request into a site-wide change. Building and screenshotting every route can lengthen waits and consume continuous-integration resources. The extension also needs access to pages and private repositories, so permission reviews may slow adoption. If product managers repeatedly receive wrong candidates or unrelated changes, engineers will have to locate the issue again and trust will disappear quickly. The product should proceed only by achieving high confidence through explicit component mappings, not by trying to support every React project.