No Figma MCP? How We Still Built 350+ Figma-Accurate Screens With Kiro
If you have watched a demo of AI building a frontend recently, you have probably seen the same trick. Someone connects a coding assistant to Figma through an MCP server, selects a frame, and a few seconds later a working screen appears in the browser. It is impressive, and for plenty of teams it is a perfectly sensible way to work.
When we started building a multi-step customer journey for a regulated financial services company, that trick wasn't available to us. The AI agent had been approved with restrictions after a security review, the designs were still evolving rather than signed off, and every screen still had to be accurate enough to stand up to design sign-off, accessibility testing and audit.
The product was an online account-opening journey for a retail savings product, built as a React and TypeScript single-page application styled with Tailwind. It ran to more than 350 screens once every variant, error state and mobile layout was counted, taking customers through product selection, personal details, address history, identity verification, financial information and a final review, and it sat on a shared component library documented in Storybook that we built alongside the screens.
This is the story of how we solved that problem with Kiro and spec-driven development. It is also, we think, a useful case study for anyone leading teams that want the speed of AI without losing control of quality, because the things that made it work had more to do with what we built around the AI than with the AI itself.
The obvious route was closed for good reasons
The design files held unreleased product rules and customer-facing copy, so the organisation was careful about which tools could touch them. Kiro had been approved after a security review, but MCP as a whole had not, so connecting Kiro to a Figma MCP server was off the table by default. Kiro itself ran in supervised mode, so a person approved every file change and every command. That added friction, especially once skills were building whole screens, but we accepted it in exchange for knowing that a person was accountable for every change.
It would be easy to see all of this as red tape, but we didn't. In 2025 a popular community Figma MCP server was found to have a serious remote code execution flaw, which is precisely the kind of risk a security team in financial services exists to prevent.
What we did have was the Figma REST API, a Dev Mode seat for code exports, a component library we were building as we went, and Kiro's spec-driven workflow. The question was whether that was enough to give the AI a real understanding of the design without it ever looking at Figma.
Our first automated attempt went badly, and taught us the most
For the very first screen we did everything by hand, copying the CSS for each layer, exporting the icons and saving a PNG of the frame. Kiro's result was close enough that the review comments were only about small details.
Doing that for more than 350 screens and variants, on desktop and mobile, wasn't realistic, so we tried pulling the whole Figma file through the API and handing Kiro the JSON. That went badly. The file was so large that the model lost track of what it was building, it had no image to check against, and the JSON described shapes and coordinates rather than anything meaningful. Where any of us would see a primary button, the model saw a coloured rectangle at a particular position.
Working out why the manual version had succeeded was the turning point. Without realising it, we had been practising what AI engineers now call context engineering, which means giving the model only the information it needs, in a form it can use, for the single task in front of it. For a screen, that came down to three things, each trimmed to what mattered, which were a picture of the screen, clean icons, and exact values for layout and styling. Handing over the whole file had done the opposite, burying the useful signal under thousands of nodes the model had no reason to see. From then on, every screen came with all three, one frame at a time, and we found that the quality of what Kiro built followed closely from the quality of the context we gave it.
We gave every screen a design contract
We came to call it the design contract for the screen. It told Kiro exactly what to build and gave reviewers a checklist of values to verify, while the PNG and the Figma frame itself remained the reference for anything the summary left out, such as borders, shadows and images.
It records what a careful frontend engineer checks by eye, including spacing and padding, sizes and alignment, typography, which words are bold, the exact copy, colours, corner shapes and which library component each element should become. It never contains customer data, and every value is mapped through our token map and component inventory, so Kiro's first instinct is to reuse what already exists.
The contract came with a clear rule, which was that it is the single source of truth. If a value was unclear or didn't match the picture, Kiro had to explain what it saw and ask a question before going any further. We would much rather answer a question than untangle a confident guess.
We taught Kiro to read Figma the way an engineer does
Having the right data wasn't enough, because a design file can be read in more than one way and an AI will happily choose the wrong one. So we wrote a steering file for building screens from Figma that reads like the notes an experienced engineer would give a new starter.
It explains which parts of a frame belong to the shared page layout and which belong to the screen, so Kiro doesn't rebuild the header on every page. It explains quirks of Figma that catch people out, such as how alignment works in vertical layouts, and how to tell whether a mobile button sits straight after the content or is pinned to the bottom of the screen. It insists that copy matches Figma word for word and wraps in the same places. None of these rules are complicated, but each one removed a whole category of mistakes from every screen that followed.
A journey is more than a set of screens
In a financial services journey, the unhappy paths matter as much as the happy one, because that is where customers are told their details couldn't be verified or that a service is unavailable. We needed the connections between screens to be as reliable as the screens themselves.
The designers had drawn the journey as named arrows between frames, and we built a skill that reads those arrows and combines them with the text from the code export in Figma's Dev Mode. For each section it produces a design spec with the flow, every error and branch, and the content and validation rules for each screen. Variants that sat side by side in Figma without arrows went into a manifest of every screen and variant, drafted by a script and confirmed by a person, because a mislabelled error screen can look entirely plausible.
The manifest paid for itself early. It showed us that on mobile, several long desktop forms were split across two or three screens, which responsive styling alone can't handle, so we planned for it from the start rather than discovering it in testing.
The flow from Figma then became the reference for navigation in the built app, and end-to-end tests walk through the happy and unhappy paths to prove each screen leads where it should.
We made the rules impossible to miss
A design system is much more than styled components, and we learnt that by building ours alongside the screens. Every component carries decisions that a Figma frame never shows, such as how a button behaves while loading, how an error is announced to a screen reader and where focus lands when a dialog closes. At the start those decisions lived in a few people's heads, where an AI can't reach them.
Putting them in every prompt didn't work, because prompts get shorter as deadlines get closer. Instead we put the standing rules where Kiro reads them automatically. Steering files hold our coding, testing, security and accessibility standards. Architecture decision records explain the choices already made. Specs hold testable acceptance criteria for each feature, skills handle the jobs we repeat, and hooks check each save for personal data and each finished task for leaked credentials.
The component library became the other half of the answer, with one firm rule about how Kiro uses it. If a component and variant exist, use them through their props. If the library can't express what Figma shows, change the library as a small reviewed update and rebuild the screen against it. If the design is the odd one out, ask the designers. Whenever a screen needed something the library couldn't do, we changed the library rather than patching the component on that screen, because every patch is a new version of that component that the library's tests and accessibility checks never see.
That rule is how the library grew. When our modal couldn't match a new overlay design, it gained the missing options, and every later screen got them for free.
We applied the same thinking to design tokens. Hard-coded colours were replaced with tokens wherever they had slipped into screens, and browser tests in the library confirm that the tokens resolve correctly in a real application, because a token that looks right in isolation can still break once it is consumed.
Figma couldn't answer every question about behaviour, and we were firm that the AI shouldn't guess. Open questions went to the design team, and their answers went back into the spec, or into steering if they applied more widely. Those conversations mattered as much as any tool we built.
Every correction made the next screen better
Each screen went through the same loop. A build skill assembled it from library components, started the local development server and rendered every variant. A review skill compared the result with the Figma PNG and checked it against the design contract and our code standards. Then an engineer reviewed it.
The step that made the biggest difference came next. Whenever the engineer spotted something the AI had missed, we didn't just fix that screen. We wrote it into the build and review skills and the steering checklist, so it would be caught automatically on every screen after it.
One early example was an input whose error message wasn't properly linked for screen readers. It looked fine, but it was the mistake Kiro made most often in input components, and once it went into our steering and review checks it rarely reached human review. Findings like that, from overlays with the wrong copy to containers with doubled borders, turned our skills from a rough first draft into a record of everything the team had learnt.
It also changed what reviewers did. With the library, the AI review and the CI pipeline handling the details, they stopped hunting for missing focus rings and started asking whether each screen was right for its moment in the journey.
We measured the process, not just the product
"The AI seems to be doing well" is never going to satisfy a risk or compliance team, so we track four measures.
| Measure | What it tells us |
|---|---|
| Tests passing on committed code | How reliably code merged to main passes every check in the pipeline |
| Automation coverage | How much of the code automated tests exercise, with thresholds that fail the build if it drops |
| AI drift | How many acceptance criteria still lack working code and a test, assessed by having Kiro review each criterion against the code and tests, which shows how closely the AI built what the spec asked for |
| Screen coverage against design | Which screens and variants are built, in review or still to do |
AI drift has been the most revealing of the four. Beyond the number, its reviews surfaced gaps before they slipped through, and occasionally showed that a difference from the ticket was a deliberate decision that needed recording rather than fixing.
What this means if you lead an engineering team
For leaders weighing up spec-driven development, a few lessons stand out from this project.
The constraint that blocked the easy route made the result better. Without Figma MCP we had to decide deliberately what the AI should see, and we ended up with a design contract we fully understand and can audit.
Design the context as carefully as the prompt. The largest gains came from deciding exactly what the model should see for each task and keeping everything else out of view, which is a discipline that applies well beyond frontend work.
Your design system is your biggest lever. The more decisions it encodes, the less the AI has to guess, and the less your reviewers have to catch.
Keep people where judgement matters. Automated drafting and AI review are fast and useful first passes, but in a regulated journey a person still confirms them.
Make every correction permanent. A team that feeds its review findings back into its skills gets better with every screen, while a team that fixes issues one at a time stays where it started.
Evidence beats reassurance. Measuring drift alongside tests and coverage gives risk and compliance teams something concrete to look at, which makes conversations about AI adoption much easier.
Spec-driven development is often described as a way to stop AI coding from drifting, and it does that. In a regulated setting, though, its real value is that it takes what your designers and engineers know and writes it down in a form an AI can follow and an auditor can read.
