Faire’s five-PR preview-build tool: planning beyond the ticket, outcome still unmeasured
Faire’s five-PR preview-build tool: planning beyond the ticket, outcome still unmeasured
Original account. Cursor’s May 26, 2026 customer interview with Faire senior engineer Blair McAlpine describes one internal feature rather than an aggregate PR count. Faire’s large web application often required developers to run the whole app locally to inspect a change. McAlpine wanted each new PR to bring up a remote sandbox where colleagues could try it.
Visible work chain, according to the interview. McAlpine initiated the goal and used Cursor plan mode to iterate on a step-by-step plan; each step was assigned its own PR. He handed that plan to a cloud agent, which ran for two hours and produced five stacked PRs. He says a working internal preview-build tool existed in less than a day; his prior expectation was weeks. He reports working on other things while the agent ran. This is a specific, human-defined feature plan with an explicit multi-PR execution boundary, not evidence that an agent originated the feature or owned acceptance. First-person quotes within vendor-written account.
Boundary of observation. The interview does not link the original plan, five PRs, individual reviewer comments, CI, merge or production deployment. ‘Produced five PRs’ does not establish that five PRs were merged in two hours, nor that the tool was adopted; ‘working internal tool’ is McAlpine’s report of initial functionality, not measured use. It gives no active human minutes for planning/review/repair, cloud-agent cost, incident or later maintenance record, or measured developer time saved by preview use. No separate Faire-published preview-tool follow-up found by searches of Faire engineering, engineer name, preview builds, and the tool name as of September 30. Other reposts of this interview add no independent outcome verification.
Why it matters. This moves the single-feature search one junction deeper than process sketches: the human decomposed a sizable goal into reviewable dependency-ordered changes, and the agent executed that plan. It still cannot establish lifecycle ROI. Five stacked PRs are review surfaces, not five units of customer value; actual reviewer load might grow or shrink. Ask for the plan and PR stack, the number of reviewed/merged/revised layers, time spent by reviewer and owner, tool use after launch and first 30 days of repair before making a maintained-change claim. Compare SQLFluff’s public two-PR repair for original review/merge/release evidence; neither source alone closes the entire chain.
Other examples in the same interview are separate work. Faire’s MobX-to-React migration coordinated by its Swarm system uses a scraper to enumerate usages in S3 and then delegates changes to agents after each prior PR merge. That is a migration, not the five-PR preview feature, and the article does not link their outcomes. A weekly 2,000+ automation-run total and weekly PR-throughput claim are team-level metrics, not this feature’s costs or benefit.