Case study
Designing the constraints that made parallel development work.
Many agents can write a lot of interface very quickly. The question was how to keep what they wrote consistent enough to be one product. The answer was to decide, up front, which foundations they would consume rather than reinvent.
What went wrong first
The first pages were styled locally. Each agent made sensible choices in isolation: spacing, colour, the shape of a button, how a table handled an empty state. Nothing was broken. Nothing matched either.
Correcting it page by page would have meant making the same decisions forever, and making them after the fact. The drift was not a prompting problem. It was a boundary problem.
Two governed edges
A design system on one side, a standards-based record on the other. Agents work in the space between and consume both edges as they find them.
On the front end, the design system was moved into Figma, expressed as an atomic component library built on shadcn, and documented in Storybook. Agents import from the library rather than restyling locally. When a component is missing or wrong, it is changed once, in the library, and every page benefits at the same time.
On the back end, the record follows FHIR. The data model comes from the standard, so it is not something a page can reinterpret to suit itself. Validation happens at the boundary, and the same shapes serve every screen.
Design system
- Defined in Figma
- Built as an atomic component library on shadcn
- Documented in Storybook
Agents import it rather than restyle locally.
Pages, flows and wiring
- Screens composed from library components
- Forms, tables and navigation
- Calls to the record through its standard interfaces
Picked up in phases from a backlog that lives in the repository.
Standards-based record
- FHIR resources and profiles
- Validation at the boundary
- One data model for every page
The standard decides the shape of the data. A page does not.
What the edges made possible
Once the edges were governed, the backlog could be handed out instead of handed over.
The roadmap lived in the repository. Acceptance criteria, definition of done and test expectations were delegated from that context, and the work was distributed in phases, each phase picking up where the previous one left off.
One delivery run, spanning several phases, finished in about two days and returned roughly forty wired pages. What came back needed minor tweaks, not rework, because the parts that make pages look and behave alike were never the agents' to decide.
One delivery run: about two days from a distributed backlog to roughly forty wired pages, with minor tweaks rather than rework.
Where judgement sits
An independent QA reviewer who has worked with Michael for years tests the result the way a user would, not the way the author would. The agents are fast inside the edges. Deciding what the product is, and whether what came back is right, stays with people.
If you are about to do this
- Decide the governed edges before you decide the tooling.
Which model, which agent and which prompt matter less than which foundations are consumed rather than reinvented on every page.
- Make the component library something agents consume, not maintain.
A shared library only stays shared if whoever builds with it cannot quietly fork it one page at a time.
- Keep the definition of done where the agents can read it.
A roadmap, acceptance criteria and tests that live in the repository turn intent into work that can be picked up without a conversation.
Need a leader who can
build with AI?
Let's talk about the product challenge, the team, and the outcomes you need—whether you're improving how your business runs or building something new.