When I ask an AI agent to make a change, I need to be clear about what it can change and how it should check the result. The amount of preparation also needs to make sense for the work involved. A small spacing correction should be straightforward, while a new page needs more discussion and review.
I had to work out that distinction while using AI agents to build websites in Framer. I could get work done quickly, but I also ran into problems with how the agents carried out that work. An agent could edit the wrong project or tell me that a component was finished after checking the code, without checking how it behaved in Framer.
I added rules to make the work easier to control. I specified which agent could edit a project, required a handover between agents and added checks before anything was considered complete. This helped with larger changes, but it also meant that a small spacing correction could require a lot of preparation and review.
I needed to make a distinction between the changes I had already decided on and the ones that still needed design work. If I asked for a specific spacing value, there was no reason to go through the same process as designing a new page.
The distinction matters because an agent needs different instructions depending on how much has already been decided. When I provide an exact value, I have made the design decision and need the agent to apply it correctly. When I ask it to improve a page, there are still questions about what should change. Starting the build at that point can mean the agent makes choices I have not reviewed.
I also need to know what else a correction could affect. A spacing value used in one place is different from a shared style used across several pages. Even if the request sounds small, the agent needs to check where the change will apply before making it. That is useful preparation because it relates to the actual edit.
Small corrections and larger changes
I adjusted the instructions so an agent could apply an exact correction directly and check the result. If the layout or behaviour was still undecided, I needed to review a design before the agent started building it.
Working with AI agents
How I handled different changes
I separated the work into five types, because a small correction did not need the same preparation and review as a new design.
Understanding the problem
I asked the agent to look into the problem before changing anything.
It needed to explain what it found and show me where the problem was.
Making a small correction
If I had already specified the change, the agent could apply it directly.
It then needed to check that the change was saved and looked right on the page.
Building part of a page
For work on an agreed part of the website, I used a separate branch.
The agent needed to check the screen sizes and interactions affected by its changes.
Changing the design
If the layout or behaviour still needed deciding, I wanted to review a design first.
Once it was built, the agent needed to compare the result with the design I had approved.
Publishing the changes
I kept approval before publishing, so I could review what would go live.
After publishing, the agent needed to open the live page and check that the changes were there.
I also changed how agents worked alongside each other. Initially, only one agent could edit a project at a time. That avoided conflicting edits, but it meant an agent working on a small footer correction could hold up unrelated work elsewhere.
I started using separate Framer branches for changes that did not affect the same components or shared styles. That allowed the agents to work on separate parts, while keeping a review before their changes were brought back into the main project. At that point, the agent needed to check whether anything had changed since it started and deal with any conflicts.
Checking what the agent had done
The checks needed adjusting as well. Running a full set of desktop, tablet and mobile checks after every small correction took time, and some of those checks had little to do with what had changed.
For a spacing correction, I wanted the agent to check the value, show the result and make sure it had not affected another screen size. For a responsive section, it needed to check all the relevant sizes. If the change involved hovering, scrolling or keyboard focus, it needed to try that behaviour in Framer Preview.
This also made it easier to understand what an agent meant when it said the work was finished. A component could be built without having been tested, and a tested page could still be unpublished. I needed those differences to be clear so I knew what I was reviewing.
A screenshot can show me the appearance of a page, but it cannot show whether a hover interaction works or whether someone can reach a control using the keyboard. Asking for more screenshots would not answer those questions. I need the agent to check the behaviour itself and explain what it tried, so I can see whether the relevant part of the work has been tested.
I kept approval before publishing and before building a new design direction. The smaller corrections could move ahead with fewer steps, which reduced the amount of coordination I needed to do while still letting me review changes that affected more of the website.