One AI System Delivered an Enterprise Software Feature: Requirements, UI Design, Development, QA, and Code Review

One AI system produced the feature end to end: product requirements, three UI design rounds, the UI contract, front-end code, QA and accessibility evidence, and an independent code review.

That work is normally divided among a product manager, product designer, UI architect, front-end developer, QA and accessibility specialist, and code reviewer. The article shows every prompt, approval, output, correction, and verification step in that specific feature-delivery workflow.

The claim is not that an entire company disappeared. Backend services, platform engineering, security, DevOps, data operations, and production deployment remain outside this run. The narrower result is still significant: AI produced the complete requirements-to-reviewed-UI chain while named humans approved consequential policy and release decisions.

We begin with why this operating model matters now: AI use has spread faster than software organizations have redesigned feature delivery.

Source: Gallup Workplace AI Indicator. Both readings use the same definition: U.S. employees using AI in their role at least a few times a year.

AI Adoption and the Job-Market Shift

The adoption curve is no longer subtle. Gallup’s repeated U.S. workforce measure shows employees using AI in their role at least a few times a year nearly doubled from 27% in May 2024 to 52% in May 2026. Frequent use—a few times a week or more—rose from 12% to 30% over the same period.

The organization-level signal is even broader. McKinsey’s global survey found 88% of organizations regularly used AI in at least one business function in 2025, up from 78% a year earlier. The Stanford AI Index 2026 documents the same rise.

Those numbers do not mean every company has rebuilt its operating model. McKinsey found only about one-third had started scaling an AI program. Japan shows a similar gap: IPA DX Trends 2025 found strong generative-AI implementation among enterprises with 1,001 or more employees, while smaller companies lagged. Access is spreading faster than workflow redesign.

The labor signal needs the same precision. Whole professions do not disappear at once; repeatable task bundles lose scarcity first. The World Economic Forum moved graphic designers from a moderately growing role in 2023 to just outside the fastest-declining group in 2025. In the United States, BLS 2024–2034 projections put computer programmers at −6%, but software developers at +15.8%, software QA analysts and testers at +10%, and web and digital interface designers at +7%.

So designers, UI developers, and QA specialists are not becoming obsolete as titles. Their most repeatable work—first-pass layouts, component scaffolding, test generation, and routine regression checks—is moving into AI tools. What remains valuable is the work that decides which problem to solve, which experience is acceptable, which risk matters, and who can approve the result.

Adoption changes the value of work

Repeatable production compresses before whole roles do

Sources: WEF Future of Jobs 2025, BLS 2024–2034 projections, Nikkei and LevTech (July 2026), and Indeed Hiring Lab (July 2026). These sources measure different populations; read them as converging signals, not a single causal study.

Japan’s freelance market makes the pricing shift visible: a LevTech index reported by Nikkei moved from 100 in 2022 to about 125 for project managers and about 50 for HTML coders by spring 2026. In the United States, Indeed found software-development postings rose 15% from February 2025 to June 2026, with senior roles producing 71% of the annual increase. Implementation is not disappearing; more of its value is moving upstream into decisions and outward into system ownership.

That shift changes the unit of automation. When research, design production, front-end implementation, test generation, and review share the same agent context, AI is no longer helping with one task. It can carry a product decision through the delivery chain.

From Coding Assistants to Product-Delivery Agents

An AI coding assistant solves a code task. A product-delivery AI coding agent carries approved constraints through specification, design, UI contract, implementation, tests, and review. That longer, gated chain is the useful meaning of agentic software development—and it is where formerly separate feature-delivery tasks begin to converge.

For Asteron, the boundary is concrete: FleetOps v1.1.8 uses a chat handoff; v1.2.0 requires a frozen version that only Marcus can accept or reject. The agent can produce every artifact around that decision. It cannot invent the ownership policy or authorize release.

For this v1.2.0 software feature, the staffing change is specific: AI absorbed the artifact-production work normally divided across a product manager, product designer, UI architect, front-end developer, QA and accessibility specialist, and code reviewer. Named humans remained at the approval and release boundaries.

Our MCP and Codex guide explains how tools remain bounded, while the Discord-to-PR agent case study shows the pattern inside an engineering queue. This run extends the same idea upstream into product and design. The question is no longer whether AI can make an artifact; it is how to supervise a chain of artifacts without surrendering the decisions that make them valid.

How AI Delivered the Feature, Step by Step

The operating model follows directly: stages 01–07 are AI work. GPT‑5.6 Sol produces the specification, design directions, and UI contract; the coding agent builds and repairs the interface; Claude Fable 5 reviews it independently; and the automated harness verifies quality and acceptance criteria. Humans do not take over production between stages. They authorize policy, design, contract, and release boundaries through five hard gates:

The model setting stays visible on every prompt below. GPT‑5.6 Sol ran at High complexity for specification, design, UI contract, implementation, and remediation. The independent reviewer used Claude Fable 5 at Maximum complexity. Final verification came from a deterministic test harness rather than model judgment.

AI could continue automatically inside an approved boundary, including fixing obvious rendering and QA-harness errors. It had to stop when a decision would change product policy, the selected design, the UI contract, or release status.

This is human-in-the-loop AI as an operating model, not a label. The gates make AI governance, responsible AI, and AI accountability concrete: the system produces evidence, while named people own consequential decisions. In a deployed workflow, those inputs should come from governed records rather than chat memory. VoicePing meeting minutes keep discussion outcomes and action items in a durable record, while scoped External Access connects those records to authorized AI clients. With the control plane defined, the delivery run began at Gate 01: the specification.

Define What the Feature Must Do with GPT‑5.6 Sol

Before anyone drew a screen, the agent had to turn the release decision into rules. The input named a production baseline, an exact user, and a single decision. The category is often called product requirements document AI, but this was not free-form ideation: GPT‑5.6 Sol at High complexity had to expose missing policy and stop for approval. This was the prompt used in the task:

FleetOps v1.1.8 is live. Specify one v1.2.0 decision: Incident Ownership Transfer for INC-4827.
Name the outgoing, incoming, and supervisor users. Define the complete policy and failure surface. Do not design the UI. Stop for human approval.

The approved specification makes the product decision testable. A handoff is complete only when Marcus accepts the same frozen version Emi submitted. Missing or malformed policy data fails closed. The deadline comes from server time. An overdue handoff remains actionable and escalates without transferring ownership. Every attachment open triggers a new authorization check and audit event. A material field change creates a new version; it never edits history.

The most important product-agent behavior was stopping. The specification exposed six decisions that required an accountable owner, then became the approved input for design.

Design the Feature UI and Select a Direction

With Gate 01 approved, Round 1 asked GPT‑5.6 Sol at High complexity, acting as an AI design tool, to explore genuinely different user jobs—not three color themes. That made AI UI design a decision exercise rather than a style generator:

Using only the approved specification, create three production-grade 1440×1000 SVG directions for the same overdue INC-4827 handoff:
A. Operations Queue — optimize for scanning and triage.
B. Decision Workspace — optimize for Marcus’s accurate accept-or-reject decision.
C. Audit Timeline — optimize for traceability and investigation.
Explain desktop, mobile, accessibility, and the central trade-off. Do not select a winner. Stop for human review.

The human selected Direction B for iteration—not for implementation. Round 2 focused the selected workspace on one accurate decision:

Iterate only Direction B. Remove the misleading “checked” checklist. Put acceptance consequences beside the actions. Explain why version 2 was invalidated. Add required rejection validation and stale-version recovery. Preserve Marcus as the only decision owner. Stop for human review.

The result removed the misleading checklist, moved consequences beside the actions, explained why version 2 had been invalidated, and added rejection validation and stale-conflict recovery.

For teams evaluating AI-powered design tools or AI user interface design workflows, the useful output is not more screens. It is a smaller, explicit set of trade-offs that a human can approve.

That round still failed a basic flow test: the default screen, rejection form, and stale-conflict message appeared together, as if three mutually exclusive states could occur at once. The next prompt was deliberately narrow:

Create one coherent default desktop and 390px mobile state. Put rejection and stale-conflict states on a separate sheet. Evidence must precede actions. Viewing cannot imply acceptance. Lena cannot decide for Marcus. Long names, timestamps, errors, and actions must reflow without horizontal page scroll. Stop for human approval.

Design Gate 03 closed only after the default, rejection, and stale-conflict states were separated and the mobile flow preserved evidence before action. The chosen direction was now coherent—but a screenshot still could not tell a coding agent how every state must behave.

Convert the Approved Design into Buildable UI Rules

The UI contract removed that ambiguity. It had to state which text was policy, which data was authoritative, and how the page behaved during a race.

GPT‑5.6 Sol at High complexity translated the design and specification into a contract with 27 named components, 17 mutually exclusive page modes, five attachment modes, and 56 normative rules, plus copy IDs, test hooks, focus behavior, and responsive requirements. The result sits between design system documentation and an executable UI specification.

Convert only the approved Round 3 direction into a UI contract. Specify components, semantic order, exact copy, authoritative versus derived fields, all modes, permissions, focus, keyboard behavior, responsive rules, analytics exclusions, fixtures, and test hooks. Reconcile every rule to the product specification. If policy is missing, stop rather than invent it.

This was a better outcome than a plausible guess. The approved enumeration now has stable language-independent codes—missing information, unresolved risk, unavailable for coverage, wrong recipient, and other. Analytics may record the code, never the free text. Once the human supplied that missing policy, Contract Gate 04 closed. Only then did code begin.

Build the Front-End with an AI Coding Agent

The GPT‑5.6 Sol coding agent at High complexity received the approved specification, Round 3 design, and UI contract as a single set of sources of truth:

Implement a dependency-light prototype with a deterministic mocked authoritative service. Include default overdue, rejection, accepted, stale, permission, offline, ambiguous-result, race, and attachment states. Use semantic HTML, external CSS, modular JavaScript, stable hooks, domain tests, Playwright browser tests, axe-core scans, and overflow checks at 320, 375, 390, 768, 1024, and 1440. Do not claim a real backend, authentication, pilot, or release.

The agent produced the UI and its test harness in 17 minutes 18 seconds, measured from first prototype file to final verification. The implementation uses an in-memory service, but models server-side preconditions, idempotent decisions, authoritative race results, attachment reauthorization, and a version-4 recovery path after a stale conflict.

That is the useful boundary of AI software engineering here: state transitions, policy invariants, and evidence—not just component generation.

On mobile, both actions remain after the complete evidence in document and keyboard order. They do not fit in the first 844 pixels without sacrificing readability, so the implementation uses the contract’s approved natural-scroll fallback rather than a sticky action bar that could bypass evidence.

At this point, the builder and its own suite said the prototype was ready. That ended implementation; it did not establish independent confidence.

Review the Feature Code Independently with Fable 5 AI

So the builder did not grade its own work. A separate, review-only Claude Code session ran Claude Fable 5 at Maximum complexity against the approved specification, UI contract, prototype, tests, and runtime.

Review only; do not edit files. Compare the prototype with the approved specification and UI contract. Challenge policy, authorization, state transitions, responsive UI, accessibility, security, data integrity, failure handling, and test coverage. Deduplicate by root cause and cite concrete evidence.

The review deduplicated its fan-out into 15 findings. It caught policy, terminal-state, offline, mobile, server-safety, and false-green test defects that the builder’s suite had missed. GPT‑5.6 Sol at High complexity remediated all 15 in 10m 53s. Fable neither edited the code nor re-approved those fixes, preserving a real independent AI code review boundary. After remediation, the question changed from “did the code change?” to “what evidence is now green, and what still requires people?”

Verify Behavior, Accessibility, and Acceptance Criteria

We rebuilt the evidence in three separate layers: UI verification, accessibility verification, and user acceptance validation.

The final suite verifies authorization, stale and offline behavior, idempotency, rejection policy, ambiguous responses, and responsive reflow. Automated checks covered selected WCAG 2.2 criteria; manual screen-reader, 400% zoom, physical-device, and Japanese localization reviews remain pre-pilot work. Green automation is evidence—not a release certificate—so every open item went into the final human gate.

Human Approval: Decide Whether the Feature May Ship

Gate 05 consumed the complete evidence packet, including what was still missing:

In a real company, Product, Operations, Security and Privacy, Engineering, QA, and a named release manager would own the remaining decisions. AI can assemble their evidence packet; it cannot accept residual risk. That is the practical boundary between AI governance, responsible AI, and actual AI accountability. The NIST AI Risk Management Framework provides a broader structure for managing that risk; VoicePing’s member-role permissions and event log show how authority and traceability become product controls. Production remained blocked. That was not a broken workflow; it was the workflow preserving accountability.

What Failed, What Changed, and What We Learned

Because every gate could stop the run, the useful project postmortem is the sequence of failures and corrections—not the polished final screen:

The lesson for agentic delivery is simple: make each artifact falsifiable. Policy, flow, contracts, tests, and reviewer conclusions must all be allowed to fail. AI replaced much of the artifact production and coordination here; humans remained the source of intent, judgment, authority, and liability. Those stop-and-correct loops are also why elapsed time alone cannot tell the story.

Conclusion: AI-First Product Delivery Is the Sustainable Model

This run supports a stronger conclusion than “AI can help a product team.” AI carried six software-delivery responsibilities through one continuous context: product specification, three design rounds, UI contract, front-end implementation, independent review, remediation, and verification. Claude Fable 5 found 15 root-cause defects, the coding agent corrected them, and the deterministic suite finished with 41 passing checks.

Frequent human intervention would not have improved that production loop. It would have added scheduling queues, repeated explanations, context loss, subjective review variance, and opportunities to reopen decisions that were already approved. More checkpoints can even weaken accountability when everyone reviews a fragment but no one owns the outcome. Human attention is most valuable where the system cannot derive an answer from approved rules: setting intent, resolving exceptions, accepting risk, and authorizing release.

That division is operationally sustainable because the expensive, repeatable work can run continuously, use the same evidence, and improve without assembling six specialists for every iteration. Human review becomes smaller, clearer, and more accountable instead of disappearing. The durable product-delivery model is therefore AI-first and human-bounded: automate the full artifact chain, then spend scarce human judgment only where a consequential decision truly requires it.