When Shipping Gets Cheaper Than Studying: UXR Enters the Loop

When a coding agent can implement a feature in an afternoon, a months-long formative study before the build becomes hard to justify — and a growing body of practice argues that research instrumentation, not research itself, is what should be built alongside the feature. Practitioners are calling this shift "research-in-the-loop": UX research integrated into AI-assisted development, with agents building intercept surveys, event logging and dashboards from a few lines of requirements.

The economics mirror an older one. Early photographers worked slowly because film was expensive and each exposure cost something; digital cameras made each shot nearly free, so much of the learning moved to after the shot. Software is following the same curve. Teams now pick a direction, build, release, and watch. Iteration is cheap.

What changes when a release outpaces a study?

A bad photo stays on your card. A bad release reaches real people. That asymmetry is why research cannot disappear, even when shipping is nearly free. A release tells a team what happened; dashboards show that people abandoned a workflow. They do not show what those people were trying to do or what confused them. Those questions remain the territory of research, and building the wrong thing quickly is still a failure.

Historically, researchers needed engineering help for almost everything: an intercept survey triggered when someone abandons a flow, event logging for a new feature, a feedback button tied to a release, a dashboard showing where work stalls. Engineering time went to features instead. A coding agent can now build these instruments alongside the feature itself, often from a few lines in the requirements.

How does research-in-the-loop work in practice?

The approach spans three phases. Before the build, research shapes what a release must capture. During the build, agents implement that capture with the feature. After release, researchers study what happened, and what they learn feeds the next requirements. The method supports three activities:

• Evaluation — did the change produce predicted outcomes, and did it introduce anticipated problems, tracked through predefined metrics?
• Investigation — why did people behave as they did, and what went unpredicted, often pursued through qualitative follow-up on data anomalies?
• Discovery — what needs and problems did the team never anticipate, requiring open-ended research independent of instrumentation?

The article offers a worked example: a help-desk product where departments currently pass tickets through a central queue, and a team adds direct department-to-department transfer. A research section in the spec states expectations (tickets reach the right team faster, fewer handoffs), success signs (less time from creation to resolution, fewer tickets through three or more departments, lower support cost per ticket), harm signs (more send-backs, more reopened tickets), what to track (every handoff, grouped by department, in a small research dashboard), and when to talk to people (when a department sends back an unusually high share of tickets, schedule contextual inquiry).

Where does the method stop short?

Such a spec is not a complete evaluation design. If resolution times drop after release, seasonality or staffing changes could explain it as well as the feature; a valid evaluation may require a comparison group, a sample size, and an observation period. Faster resolution may also mask unchanged handling time if only queue waiting shrinks.

Qualitative research stays essential and can run on three tracks: a fixed cadence such as weekly sessions regardless of releases; signals, where data points to a group or moment worth exploring; and hard-to-reverse decisions like pricing or sensitive-data handling, which deserve evidence before commitment.

New skills follow: spec fluency in markdown and basic Git, directing coding agents, analytics literacy covering events, cohorts, feature flags and staged rollouts, and data plumbing via MCP connections and APIs. The core skills — asking good questions, avoiding bias, sound experimental design, ethical practice — matter more, not less. An agent can build a survey in minutes; the researcher is accountable for asking the right questions.

Open questions remain, from who owns research requirements to whether measuring every release pulls teams toward small, measurable improvements at the expense of bigger ones. The entry point is modest: audit data readiness, write one research section for one release, and share it with the team. As the piece closes, a photographer with a digital camera takes far more pictures than one with film — someone still has to know which picture to keep.