Architecting AI-Native Applications: A Spec-Driven Engineering Workflow Using Agentic Loops and Generative UI

The current era of software development presents a generational shift, comparable to the advent of the internet in the 1990s. However, for many developers—particularly those transitioning from traditional software engineering to AI-native development—the primary challenge is not just writing code, but establishing a systematic framework for moving from an unstructured idea to a production-ready application. Without a rigorous system, the use of Large Language Models (LLMs) often results in "prompting chaos," where lack of clear intent leads to architectural drift and unmanageable technical debt.

This post outlines a high-fidelity, five-step engineering pipeline designed to leverage agentic workflows, deep research capabilities, and spec-driven development to build complex applications—specifically focusing on an AI-native fitness tracker capable of parsing unstructured PDF workout programs into dynamic, trackable interfaces.

Phase 1: Requirement Engineering via Decision Tree Traversal (The Light PRD)

Every robust system begins with a clearly defined Product Requirements Document (PRD). In an agentic workflow, the goal is to move from "raw idea" to a "Light PRD" by resolving ambiguities before any code is written.

Using custom-built Claude skills, we can implement a process that utilizes a decision tree traversal approach. Rather than simply summarizing notes, the LLM acts as a technical interviewer. It analyzes initial inputs and identifies gaps in the functional requirements, user personas, or platform constraints (e.g., mobile vs. web). This skill is designed to traverse a design tree, asking follow-up questions until all core ambiguities—such as data persistence models (local-first vs. cloud) or parsing error handling strategies—are resolved and logged into a centralized decision log. This ensures that the subsequent development phases are grounded in a single source of truth.

Phase 2: Deep Research and Adversarial Verification

Once the PRD is established, the next challenge involves "unknown unknowns"—technical implementation details that require domain-specific research. For our fitness application, this involved researching how to parse semi-structured PDF data into a schema capable of driving a Generative UI.

We utilize a Deep Research Workflow within Claude Code. This process is computationally expensive in terms of token consumption but essential for accuracy. The workflow follows a three-stage cycle:

1. Scoped Search: Identifying the technical landscape (e.g., best practices for PDF parsing and schema generation).
2. Context Fetching: Aggregating data from multiple web sources to build a comprehensive knowledge base.
3. Adversarial Verification: This is a critical architectural safeguard. The agent does not take retrieved facts at face value; instead, it initiates an adversarial review of its own findings, cross-referencing claims against secondary sources to mitigate the risk of integrating hallucinated or outdated technical documentation into the system design.

Phase 3: UX Architecture and Generative UI Design

With a researched technical foundation, we transition to the PRD2UX phase. The objective here is to translate high-level requirements into granular UI/UX specifications that can be consumed by generative design tools like Claude Design or Google Stitch.

This stage focuses on defining the Information Architecture (IA) and Component States. A common failure in AI-generated UI is the lack of consideration for edge cases. Our workflow explicitly defines:

• Primary User Flows: Navigation from the workout library to specific daily sessions.
• State Management: Defining how components behave during loading, success, error, and empty states.
• Generative UI Logic: Designing a system where the LLM can render workout blocks (e.g., supersets, circuits) on the fly based on the parsed schema from the PDF.

By providing these low-fidelity wireframes and component specifications as structured prompts, we ensure that the generative design tool produces high-fidelity prototypes that are faithful to the original technical intent.

Phase 4: Spec-Driven Development with OpenSpec

The transition from design to implementation is managed via OpenSpec, a spec-driven development framework. Rather than attempting to build an entire application in a single prompt, we utilize "vertical slicing" to break the project into manageable Epics.

The engineering pipeline follows a strict hierarchy:

1. Proposal: A document outlining the intent (the "why"), the system design changes, and the technical rationale. Providing motivational context is vital; it allows the LLM to make informed "game-time" decisions when encountering unstated edge cases.
2. System Design & Task Lists: Breaking down the proposal into specific technical specifications and actionable task lists.
3. Implementation (The Apply Phase): Executing the tasks within a controlled environment, ensuring that each change is documented and traceable.

This approach prevents "scope creep" by forcing every new feature to be reconciled with existing architectural decisions.

Phase 5: Autonomous Execution via Sub-Agent Loops

The final stage of the pipeline is an autonomous execution loop capable of running overnight. By leveraging a Dynamic Workflow, we can automate the implementation of multiple epics sequentially.

This advanced architecture utilizes Sub-agent Driven Development:

• Implementation Agents: Specialized agents tasked with executing specific phases of an epic (e.g., parsing logic, UI rendering).
• Adversarial Review Agents: A separate agentic instance that performs a post-implementation audit to verify the work against the original specification and test for regressions using tools like iOS simulators or browser automation via MCP servers.

While this process is highly token-intensive and requires significant verification loops, it allows for the development of complex, multi-layered features—such as PDF parsing, local data storage, and dynamic workout tracking—with minimal human intervention. The result is a production-ready, functional application built on a foundation of rigorous engineering principles rather than iterative prompting.