The Role of UX in Agentic Software Factories - NN/G

Find the training option that fits your learning style.
October 30, 2026 2026-10-30
In August 2026, Anthropic published its vision of an AI-native software development lifecycle (SDLC) following similar, though less prescriptive, publications by Google (May 2026) and OpenAI (November 2025). The three visions differ in details, but all sideline UX, reducing it to behind-the-scenes context that guides AI generation. But this is only part of the value UX offers. UX also discovers what users need, strengthens the team’s shared judgment about what to build, and evaluates what gets built. Organizations that adopt this model as described risk losing the very user insight their AI context depends on. This article examines Anthropic’s playbook to show where it leaves UX out and what UX teams can do about it.
The software development lifecycle (SDLC) is the sequence of stages software goes through as it’s built. The stages typically include:
Early versions of the SDLC emerged in the 1960s, often referred to as "waterfall," before the Agile movement of the early 2000s reworked them into short, repeated cycles.
Anyone working on software is likely familiar with elements of the SDLC, whether they call it that or not. But it’s important to recognize that the SDLC framework primarily describes an engineering perspective. UX has long fought to defend its place in the traditional SDLC.
Anthropic, Google, and OpenAI’s publications all make a simple argument: AI agents make writing code (the Build stage) fast and cheap, so the other stages must also adapt to maximize productivity gains. Deliverable creation, human approvals, and governing policies must be redesigned to keep pace with AI agents without lowering quality standards. Google summarizes the main argument of all three well:
"The most profound shift in software engineering isn't a new language, framework, or cloud service. It's the transition from writing code to expressing intent, and trusting intelligent systems to translate that intent into working software.”
Anthropic’s playbook retains the six traditional SDLC stages, but AI becomes the primary executor, and humans monitor quality along the way. The stages revolve around a chain of version-controlled artifacts generated by AI agents in Markdown and reviewed by the individuals who control each approval gate, serving as an audit trail of what was decided and by whom.
What guides the AI’s work is context: curated instructions that tell the AI how the organization does things and that constrain its work. Context can include coding conventions, brand guidelines, security rules, and UX standards. In theory, the better the context, the more likely the AI’s output will meet the organization’s standards without human correction — the ultimate goal. This is a significant departure from the traditional SDLC, in which a person both creates and evaluates all the work.
Anthropic’s AI-Native SDLC
The product owner gathers (research-informed) requirements and decides what gets built.
Anyone can submit an idea by generating an intent.md with AI. The product owner approves or rejects it.
Designers parse the documented requirements to create, iterate on, and test designs.
AI turns an approved intent.md into a spec.md, using the company’s standards as context. The product owner mocks up and iterates on the interface with an AI-design tool, then approves the spec.
Engineers write the code.
AI uses the spec.md to create a plan.md file outlining instructions for the AI coding agent. Once an engineer approves the plan, an agent writes the code.
QA specialists check that the software works properly.
AI checks its own work against the intent.md, spec.md, plan.md, and mockup, overseen by engineers.
Engineers review and release the code.
AI reviews the code for bugs, security risks, and compliance with the organization’s standards, before a technical lead approves each release.
Engineers monitor the product and fix problems.
Automated checks monitor the product’s health. When something breaks, AI diagnoses it and writes a new intent.md to restart the cycle.
Versions of this new SDLC are already happening — perhaps you’re right in the middle of it. But it’s too early to tell how well this SDLC suits companies of all kinds, since it’s so heavily oriented to software production. It’s also important to recognize the conflict of interest: AI labs want companies to make this shift because it drives greater use of their products.
In our self-paced course, Writing Specs for AI-Built Products, you'll learn to design the foundation AI-built products need to succeed.
UX does not own a stage or approval gate in Anthropic’s playbook. It assumes that UX knowledge, codified as context and skills, will help the AI create high-quality, user-centric products. However, it does not define space for UX professionals to get directly involved. Let’s unpack some of these assumptions.
The lifecycle starts with the creation of an intent.md in the Plan stage. It assumes the author will independently honor user needs rather than just fixating on favorite solutions. What’s to stop the submission of an intent.md that’s not linked to any clear user need? Even a well-intentioned author working with detailed UX context is limited by what they or their organization already knows, and the playbook does not create space to discover new user needs.
The individual creation of intent.mds also encourages silos over collaboration. It becomes easy for individuals (or the system itself) to create these artifacts in isolation without the perspectives of other team members, relying solely on the product owner’s judgment to approve, edit, or reject the proposals. This is a recipe for low buy-in across the team, unchallenged biases, and a flood of intent.md files from every direction.
Product owners, engineering, and UX have long represented three balancing perspectives: business viability, technical feasibility, and user desirability, respectively. But if AI-coding