From PRD to Verified Code: Building a Closed‑Loop AI Development Process

1. Turn Inputs into Specs

The first step is not writing UI code but extracting and clarifying all input sources: the PRD provides business goals, feature scope, and acceptance criteria; the API documentation supplies field structures, error codes, and front‑back boundaries; and Figma delivers page layout, component states, resource nodes, and interaction details.

If these artifacts are fed directly into a code‑generation AI, the model tends to fill gaps with guessed field names, assume only success paths, or insert placeholder images, making hidden assumptions hard to detect later.

Therefore the workflow requires the AI to produce a RequirementSpec first, documenting functional scope, page structure, field rules, interface dependencies, state flows, exception scenarios, tracking requirements, Figma node breakdowns, and acceptance standards, with each key conclusion linked to its source.

RequirementSpec: consolidated PRD, API, and design evidence.

ArchitectureDesign: module split, data flow, file placement, and validation strategy.

Agent: AI sub‑process with a fixed responsibility (e.g., code generation, compile verification, visual audit).

code‑generator: produces code according to the architecture and reports alignment.

ArchitectureAlignmentReport: post‑generation check confirming compliance with the design.

build‑verifier: runs lint, TypeScript compilation, and build checks.

visual‑auditor: compares UI against Figma.

direct‑read‑audit: records style values (color, font size, spacing) and their design node origins.

artifact: intermediate files such as field tables, Figma node info, and asset maps.

2. Two Human Gates: Requirement Review and Architecture Confirmation

After the RequirementSpec is generated, it undergoes a manual review focused on verifying the AI's understanding of business boundaries, completeness of core paths, coverage of exception scenarios, field credibility, and accurate recording of Figma components and resources.

Only after passing this review does the process move to ArchitectureDesign, which defines module decomposition, directory layout, component responsibilities, state management, API encapsulation, data flow, error handling, and validation tactics. For React Native projects, additional concerns include platform differences, component reuse, route registration, tracking lists, responsive layout, and asset handling.

During architecture design, Figma is not turned directly into style values; instead it creates a mapping from design blocks to implementation components and a "direct‑read plan" that tells the code‑generator which node IDs and properties to read.

3. Code Generation: Execute According to Architecture and Evidence

The code‑generator Agent does not simply "write TSX from requirements"; it follows the ArchitectureDesign to emit React Native / TypeScript code and produces an ArchitectureAlignmentReport proving compliance.

Before generating code, the agent reads the RequirementSpec, ArchitectureDesign, interface field artifacts, Figma summary, codeHints, and project rules. codeHints constrain reference pages, Figma styles, file limits, web‑specific handling, and dependency changes; team experience documents are also queried for RN page patterns, UI component library usage, lint rules, and tracking keywords.

For each design block, the agent creates an execution plan that specifies target file, component, data fields, interaction, and evidence. If a block lacks a concrete target, the agent marks it as blocked in the alignment report instead of writing code.

When Figma is involved, the agent verifies that disk artifacts such as metadata, raw nodes, reference code, coverage audit, asset mapping, unit contracts, and artifact manifests actually exist. Missing critical artifacts trigger a back‑flow to the requirement‑analyzer sub‑process to fill gaps; screenshots alone are never used as primary UI sources.

Before UI coding, a direct‑read‑audit.md file is generated, linking each visual constant to node_id + property name + raw_value + RN mapping. Colors, font sizes, corner radii, spacing, borders, shadows, and images must be traceable to original Figma values; screenshots serve only for final calibration.

Figma reference code is adapted to the team’s RN component library (e.g., div → View, text → Text, img → Image, button‑like frames → ZRN Button or Pressable, CSS flex → RN flexbox, shadows split into platform‑specific strategies). Component reuse is verified against ZRN UI props, default states, Web/Harmony availability, and style overrides; assets are processed according to the asset‑mapping classification.

The final implementation order remains stable: types.ts, api.ts, state hooks, leaf components, page containers, route/web registration, tracking/logging. After completion, the ArchitectureAlignmentReport lists files, blocks, interface fields, routes, UI mappings, tracking items, deviations, and pending verifications. Only when all key items pass can the build‑verifier proceed; otherwise up to five back‑flow rounds are allowed before a block is marked permanently blocked.

4. Compile Verification: From "Written" to "Runnable"

Completion of code generation does not finish the task. The build‑verifier Agent runs lint, TypeScript compilation, and required web build checks; in multi‑platform scenarios it also validates iOS, Android, and Harmony bundles.

If compilation fails, the AI does not merely echo the error; it automatically locates and fixes issues such as incorrect import paths, type mismatches, changed interface fields, missing platform suffixes, dependency misuse, or lint violations. Only errors that stem from external environment or require human judgment may be allowed to pass partially.

This step turns code that "looks correct" into code that the project toolchain actually accepts, serving as a fundamental quality gate.

5. Visual Audit: Closing the UI Evidence Loop

Passing compilation only proves the code runs, not that the UI matches the design. The visual‑auditor Agent compares the RN implementation against Figma for layout, spacing, typography, colors, component states, resources, responsive behavior, and cross‑device differences.

Sample audit results show side‑by‑side comparisons where most elements—structure, text, images, spacing, buttons, and floating panels—are faithfully reproduced, with only complex label layers missed.

Visual audit does not rely on whole‑page screenshots nor manual fixes. Instead it outputs a deviation list that is fed back to the code‑generator for precise correction, while still respecting the direct‑read‑audit rule that any new or adjusted visual constant must trace back to the original Figma raw value.

6. Experience Deposition: Strengthening the Process

After delivery, an experience‑depositor Agent captures effective prompts, common failures, repair methods, component reuse tips, Figma direct‑read rules, build issues, and visual deviations into SOPs, checklists, or templates. Writing this knowledge back into the workflow enables subsequent requirements to avoid the same pitfalls earlier.

Conclusion

Effective AI coding does not eliminate humans but reallocates responsibilities: AI handles information consolidation, code generation, error fixing, and visual audit; humans validate requirements, confirm architecture, make trade‑offs, and ensure business alignment.

The key to success is a stable human‑AI closed loop—requirement specification, manual review, architecture confirmation, evidence‑driven coding, compile verification, visual audit, and experience deposition—so that every link is traceable, verifiable, and repeatable, turning AI from a mere code‑generation tool into a collaborative engineering partner.