Building your own software factory — Eric Zakariasson, Cursor

April 28, 20261:23:3726,000 views

Summary

Eric Zakariasson, an engineer at Cursor focused on developer experience, presents a workshop on transitioning from single-agent pair programming to running autonomous software factories — drawing on his firsthand experience dog-fooding Cursor internally. The talk is structured around four phases: levels of autonomy, pre-factory setup, building the factory, and scaling it.

Zakariasson references Dan Shapiro's six-stage autonomy framework, arguing that most developers are currently at Level 2–3 (pair programmer mode), while his own work is approaching Level 4 — where the engineer acts as a manager delegating the majority of implementation to agents and reviewing outputs rather than code. The ultimate goal is Level 6: a 'dark factory' where agents autonomously plan, implement, test, and ship code with only high-level human intent provided.

The foundation of a functional factory rests on three primitives: codebase structure (co-located, modular code agents can discover without deep search), guardrails (hooks preventing agents from touching sensitive areas like auth or encryption, plus dynamically-emerging cursor rules rather than pre-installed generic rule packs), and enablers (skills, MCP tools, and isolated VM environments agents can self-start). He emphasizes that rules should emerge from observing agent failures rather than being preloaded, because modern models are increasingly good at instruction-following.

Zakariasson demonstrates Cursor 3, a complete rewrite of the IDE designed for agent-first workflows with no VS Code dependency. He showcases cloud agents running on dedicated VMs with computer-use capabilities, enabling agents to record screen sessions as verification artifacts. Playwright-based end-to-end tests are created by agents to self-verify UI changes (clicking around the DOM, testing play buttons, navigation), and BugBot is integrated with GitHub PRs to automate code review.

For async work management, he advocates frontloading context through detailed specs or plans before launching agents, then context-switching to other work. He typically runs five to ten cloud agents asynchronously at any given time. Key automations he runs internally at Cursor include: a daily review agent that aggregates Slack and GitHub activity; a 'read merged PR comments' agent that extracts high-signal human review feedback to improve future agent behavior; an agentic code-owner system that assesses PR risk level and dynamically routes reviews (approving low-risk changes automatically, pulling in domain experts for high-risk ones); a continual learning plugin that scans chat transcripts to extract and persist rules without manual effort; and a Linear-Slack integration that auto-spawns cloud agents for every new issue, including automated stale feature flag removal.

For scaling, Zakariasson stresses that humans must shift from worker to manager mindset: scoping parallelizable work to avoid merge conflicts, maintaining tribal knowledge of data flow and critical systems, and building observability to catch agents going off-rails. He cautions against letting agents push directly to production and recommends spending significant compute on testing before human review — including security sentinel automations that run multiple invariant checks on sensitive PRs.

Cursor workers, announced the day of the talk, allow the same cloud-agent orchestration infrastructure to run on any machine (Mac Mini, self-hosted VMs), enabling local-compute economics with frontier model access. The session closes with Q&A covering team collaboration on rules, enterprise brownfield risk mitigation, GUI acceptance testing via computer-use recording, multi-agent coordination at the org level, and the evolving role of engineers as architects and factory operators rather than code writers.

Key Takeaways

•Build verifiable systems first: agents that can self-check via unit tests, Playwright browser automation, or computer-use screen recording are far more trustworthy than agents that cannot verify their own output.
•Let cursor rules emerge dynamically from observed agent failures rather than pre-installing generic rule packs — modern models follow specific rules well enough that rules should encode real gaps, not assumed ones.
•Isolate agents in dedicated VMs or separate environments to prevent side effects between parallel workstreams; shared environments cause subtle state pollution and merge conflicts.
•Frontload context via detailed specs or plans before launching async agents; the more context provided upfront, the less babysitting is required during execution.
•Shift your mental model from 'worker' to 'manager': identify where humans are still in the loop unnecessarily (copy-pasting logs, triaging Slack mentions) and automate those handoffs with MCP skills or scheduled automations.
•Run a continual learning automation that scans past chat transcripts to extract and persist correction patterns as rules — this removes the manual burden of rule authorship.
•For critical or security-sensitive code, spend more tokens on pre-merge checks: run multiple security sentinel agents checking specific invariants before any human review is required.
•The agentic code-owner pattern — risk-scoring PRs and routing reviews dynamically — removes bottlenecks from static CODEOWNERS files while keeping human oversight for high-risk changes.
•Use Cursor cloud agents with computer-use to automate GUI acceptance testing: ask the agent to navigate, click, and screenshot every relevant state, then review the recording rather than the code.
Cursor workers allow the same agent orchestration infrastructure to run on any machine (Mac Mini, self-hosted VM), enabling local-compute economics with access to frontier models.

Transcript

Um, okay. So, we're starting five minutes early. Um, hey everyone. I'm Eric. I'm an engineer cursor and I mostly work at developer experience and product. And today I kind of wanted to talk to you about my experiences like working at Cursor dog fooding the product and like getting to a place where you can build your own like software factory and like what that kind of like takes and the practical steps getting there. To be honest, I don't think we're really there yet. Like sub parts of the produ...