The reality is that coding agents are rapidly taking over the tactical work of generating code using context from Spec-Driven Development (SDDs). But there’s a catch: we are currently letting AI guess all that human (aka customer) context. If we want systems that actually solve problems rather than just build screens faster, UX Researchers must shift from evaluating wireframes and writing reports to serving as the “Requirements Engineers” who build the data-backed context layer for these modern ways of developing digital products.
Here is why context is king in this new development world, and how UXR teams hold the keys to it.
I’ve noticed an interesting pattern emerging in Spec-Driven Development (SDDs) pipelines. Engineers are relying on coding agents not just to write code but also to generate Markdown files that include all customer and user context.
I’ve seen AI rapidly spin up documents detailing user constraints, JTBD, edge cases, and feature requirements.
Here is the problem: the model is guessing. It is pulling from generalized training weights, not the nuanced reality of the experts who actually use the product. When an engineering team feeds these hollow `.md` files back into a coding agent, the AI builds a perfectly functional, but potentially useless, product.
The AI isn’t doing this because it’s broken; it’s doing this because it lacks Clarity of Intent. The model defaults to building layers of menus and complex navigation because no one gave it the strict, empirical constraints to stop it. This can create significant friction for the people on the ground trying to do their jobs.
Right now, UX Researchers and subject matter experts possess a wealth of empirical data: Jobs To Be Done (JTBD), personas, unstructured interview data, and behavioral observations.
The issue? That data is trapped in slide decks and PDF reports.
An LLM agent can’t read a 40-page deck and instinctively understand how to balance a complex enterprise workflow. We aren’t saving time by letting the AI guess the persona; we are shifting our effort from data collection to endless insight validation and bug fixing later.
To fix this, UXR needs to move upstream. We have to stop viewing persona definitions and JTBD frameworks as qualitative design exercises and start treating them as strict system requirements. This is the often messy line where human intuition meets AI logic. By that, I mean the UXR team must literally format their empirical research into structured markdown (.md) files that serve as the foundational context, forcing the AI to align with reality.
The role of the UX Researcher is undergoing a phase shift. You aren’t just summarizing interviews anymore; you are writing the instructions that govern autonomous agents. You are the Requirements Engineer, guiding AI agents in developing solutions for people.
Here is what the shift looks like in practice:
From “Empathy” to “System Constraints”: Instead of a persona card that says “Sarah is busy and values efficiency,” the UXR creates a context file that explicitly instructs the coding agent: “Under no circumstances should this flow require more than two clicks, and it must prioritize offline data caching over real-time syncing.”
Replacing AI Hallucinations with Ground Truth: When an agent attempts to draft an SDD, it should be forced to ingest the UXR’s data-backed context files first. Instead of the LLM inventing a hypothetical user, it references rigorous, validated facts.
Controlling the Logic, Not Just the Pixels: UXR teams influence the product not by critiquing wireframes after they are built, but by dictating the logic the AI uses to generate them in the first place.
This shift in capability allows for incredible speed, but it increases the need for high-level human intent. If your organization relies on conversational models to define user needs, it will build software that functions perfectly but may miss the mark.
AI can’t do its best work unless you get the basics right first. The organizations making the biggest leaps aren’t tweaking models; they are building better context pipelines. UXRs have the exact data required to create this context. It’s time to stop letting it sit in a presentation and start using it to program the machine.
How is your team currently bridging the gap between UXR data and engineering context? Are you seeing models “guess” the user intent?
No posts

Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.