What is synthetic research?

Synthetic research uses AI-powered personas that simulate how real buyers, customers, or market segments would respond to your research questions. It produces directional signal — insights to sharpen your hypotheses — before you invest in real primary fieldwork. Gather Synthetic runs AI-moderated interviews across any audience archetype in minutes, not weeks.

How is synthetic research different from real research?

Synthetic research generates directional signal using AI personas, while real primary research collects data from actual people. Synthetic pre-research is faster (minutes vs. weeks), cheaper, and ideal for hypothesis generation and stakeholder alignment. It is not statistically valid and should be used to focus and prioritize real fieldwork, not replace it. Gather offers both synthetic pre-research and real AI-moderated interviews with actual respondents.

What types of research can Gather Synthetic run?

Gather Synthetic supports 14 study types: Brand Perception, Product Feedback, Concept Testing, Competitive Intelligence, CX/NPS Deep Dive, Messaging & Claims Testing, Win/Loss Analysis, Market Segmentation, Pricing Research, Ad & Creative Testing, Customer Journey Mapping, Feature Prioritization, Churn & Retention Analysis, and Audience Discovery.

How much does synthetic research cost?

The first 5 synthetic interviews are free. After that, B2C audience interviews cost $0.50 each and B2B audience interviews cost $5.00 each. There is no subscription required.

How accurate is synthetic research?

Synthetic research is directional, not statistically accurate. Predictive accuracy and a statistical interval are only shown when established for the specific result. Treat findings as educated hypotheses to validate with real primary research, not as definitive measurements.

← All brands

AI software development · PUBLIC RESEARCH BRIEF

CursorWhich agent handoff helps an engineer review a cross-file change without rebuilding the whole codebase context?

Cursor currently describes an AI coding agent that can understand a codebase, plan and build features, fix bugs and review changes across desktop, CLI, web and mobile. Cursor also documents building a searchable codebase index for semantic search. These capabilities can accelerate work, but they do not prove that an agent change is correct, complete or safe to merge.

Updated 2026-10-13 · Simulation results not yet generated

Test a question in Gather ↗Explore fictional demo →

CHANGE ONE THING. LEARN WHAT MATTERS.

Three questions for the GTM team.

After a Cursor agent changes several files, would an intent-to-diff map or a test-and-risk summary better help a reviewer find the most important assumption?

Set up this study →

Before delegating a bug fix, would a codebase-context preview or a plan with explicit unknowns better help an engineer prevent an agent from solving the wrong problem?

Set up this study →

When semantic search omits a relevant dependency, would a visible context-coverage warning or a suggested manual file check better help a user recover?

Set up this study →

PROPOSED AUDIENCE

Who should weigh in?

North American software engineering, platform and developer-experience teams using or evaluating Cursor, including individual contributors, technical leads, code reviewers and engineering managers. Recruit participants across repository size, codebase familiarity and review responsibility. Proposed audience; no production repository, source file, credential, issue, pull request or developer identity is included.

TWO TIME HORIZONS

Trial today. A habit tomorrow?

Near term · 0–90 days

Over 0–90 days, test disposable repositories, issues, agent plans and diffs with seeded hidden dependencies, incomplete indexes, failing tests and misleading local fixes. Measure problem framing, risky-change detection, review coverage, rollback choice and time to a defensible merge decision. Merge nothing to production.

Longer term · 3–12 months

Over 3–12 months, follow consenting teams in sandbox or de-identified workflows as repositories, rules and agent usage change. Examine review depth, escaped defects, rework, context maintenance and delegation patterns. Engineering impact requires observed delivery and quality outcomes.

What would make the result actionable?

Use versioned Cursor materials, disposable repositories, known dependency graphs, hidden defect labels, controlled index gaps, test suites and task logs. Score planning, implementation and review separately, include ambiguous issues, preserve baseline commits and use no production code or credentials.

A Gather simulation returns hypothetical customer reactions. Quantifying revenue, traffic or retention needs actual business inputs and validation against observed behavior.

About Cursor

Visit the company website ↗