UX loses its fixed place in the AI agent-driven software lifecycle

The problem the agentic software factory still hasn't solved

In August 2026, Anthropic published a software development lifecycle (SDLC) roadmap designed for teams in which AI agents write most of the code. Google had published something similar, though less prescriptive, in May 2026, and OpenAI had done the same in November 2025. The three documents agree on one point: if writing code becomes fast and cheap, the other steps of the process (planning, deciding, testing, approving) need to keep up with that pace.

The Nielsen Norman Group, in an article published on October 30, 2026 and authored by Tanner Kohler, went straight to the point missing from these three roadmaps: UX becomes context for AI to consult, not a step with an owner. User research, the decision about what's worth building, and the evaluation of what was built are left without a formal place in the process.

How Anthropic's AI-native SDLC works

Anthropic's roadmap keeps the six classic SDLC stages (plan, design, build, test, launch, maintain), but changes who executes each one. AI agents generate a chain of artifacts in markdown, versioned like code, and humans approve each one at a control gate. What guides the AI is what Anthropic calls context: code conventions, brand guidelines, security rules, and documented UX standards.

The table below summarizes the difference between the traditional cycle and the proposed one:

None of these six stages has UX as the owner of the approval gate. The expectation is that UX knowledge, turned into context and rules, is already embedded in what the AI produces.

Where the model assumes what doesn't yet exist

The NN/G article dismantles this expectation step by step, and this is where the angle matters to anyone who designs product: the roadmap assumes capabilities that simply aren't in the described process.

In the Plan stage

Anyone can generate an intent.md, but nothing in the process guarantees that this file originates from a real user need rather than from a favorite solution of whoever wrote it. The individual creation of the intent.md also favors silos: without input from other people on the team, the product owner becomes the sole filter, deciding alone based on what they already know. Product owner, engineering, and UX historically balanced business viability, technical feasibility, and user desirability; if engineering stops being a constraint and UX becomes a line of markdown, only the business criterion is left at the approval gate.

In the Design stage

The spec.md and the mockup generated by AI depend on someone curating, maintaining, and updating the design context, exactly as those responsible for design systems have always done. Anthropic's roadmap doesn't say who does this work. Worse: it has the product owner iterate on the mockup, and a mockup generated by AI without user testing is, in practice, interface (UI) work, not experience (UX) work.

Solving a person's exact need in a simple and elegant way still requires exploratory research to understand what people need to do and evaluative research to check whether the solution delivers that. The roadmap never mentions user research.

In the Test and Maintain stages

In Test, AI compares finished screens against the mockup approved in the Design stage. This ensures visual consistency, not usability or accessibility: the team that builds the product usually shares the same blind spot as whoever designed it, and no external research comes in to break that bias. In Maintain, monitoring covers technical health (errors, security failures), not usage success.

NN/G illustrates this with a plausible scenario: a feature launched through this process sees low adoption and is quickly abandoned, but the automated signals flag nothing because the code works perfectly. The real problem was confusing labeling, and there was no usability signal being monitored to catch that before launch.

The sentence that sums up the AI labs' bet

The NN/G article cites Google's publication as a synthesis of the argument common to all three roadmaps:

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.

Google, publication on AI-native SDLC (May 2026)

The problem, NN/G points out, is that "expressing intent" presumes that whoever writes it already knows what the right intent is. Discovering that is research work, not prompt work.

The three roles UX still needs to occupy

NN/G had already argued in a previous article that UX serves three functions as AI accelerates software production: deciding what's worth building and strengthening the team's collective judgment, evaluating what was built, and feeding the AI generation process with context. Anthropic's roadmap only covers the third function well.

For the other two, the article proposes concrete actions, organized by responsibility:

• Deciding what's worth building: the intent.md template should require answers about what the person is trying to do and what their life would look like if the problem were solved, not just capture the solution already decided on. Researchers should be able to submit an intent.md documenting a problem even before anyone proposes a solution.
• Sharing approval criteria: design and product splitting responsibility for approving what enters the pipeline, with criteria such as evidence that the problem is real and that solving it maximizes benefit for the people who use the product.
• Evaluating what was built: defining in advance when a mockup or spec requires human UX review or a quick user test, the same way architecture changes escalate to a senior architect.
• Monitoring usage signals, not just system signals: a drop in task success rate should trigger an alert with the same priority as a spike in server errors, with task abandonment, conversion drops, and rising support tickets as formal signals.
• Taking ownership of UX context curation: someone needs to own the documented UX rules, drafting the first version even knowing it will be imperfect, because if the UX person doesn't do it, another area will do it instead.
• Making research and design systems machine-readable: if agents can't easily find existing research insights, they'll simply ignore them and go their own way.

What remains open

NN/G itself admits it doesn't have a ready answer for questions like which UX knowledge can become codified context and which requires case-by-case human judgment. What's clear is that faster production doesn't eliminate the need to discover the right problem or to check whether the result works for the people who will use it.

For those designing products today, the practical takeaway isn't to reject these roadmaps or adopt them without question. It's to join the conversation now, while companies are still deciding how to adapt this model, and to claim a formal place in the Plan, Test, and Maintain stages before they settle into place without UX inside.