Building your own software factory

What would you need to give an agent a goal and let it build, test and ship the software? At Cursor, where Eric Zakariasson introduces himself as an engineer working on developer experience and product, only parts of the product and organization operate fairly autonomously. A whole software factory still requires assembly lines, management and observability—the same supporting systems that make a physical factory productive.

Dan Shapiro’s six-stage autonomy ladder provides the starting point. Zakariasson connects it to Karpathy’s tab-to-agent progression and Cursor’s beginnings in autocomplete around 2022–23. The meaningful change at each stage is how much responsibility moves from the person to the system.

Zakariasson places most adopters around levels two and three, and his own work mostly at level four. He looks at results before deciding how much code to inspect. The final stage is Shapiro’s dark factory: the human supplies instructions and goals while the production process runs behind the interface.

The attraction is continuous operation, more throughput and a way to express more of a person’s creative taste. Assembly lines also promise consistent output. But if agents appear increasingly random as their freedom grows, that is a reason to examine the factory’s guardrails. Model instruction-following matters too. The Tesla factory comparison illustrates the ambition: dependable production comes from the surrounding machinery as well as the workers.

Start with the repository’s primitives and patterns. Co-located code lets an agent discover the relevant files with ls, instead of repeatedly searching across the codebase. A module that a human can understand during onboarding is also easier for an agent to approach. Existing authentication services, startup scripts, test conventions and boilerplate provide concrete references for the next implementation. Every established pattern reduces the number of choices the agent must invent.

Then add complementary controls:

• Hooks and checks: Restrict changes to sensitive areas such as encryption and authentication, where a mistake can be especially costly.
• Rules: Describe the behavior the repository expects. Zakariasson cautions against installing every stack-specific rule from collections such as Cursor Directory merely because a project uses Next.js. Create rules when observed behavior diverges from the intended workflow, and make them useful operating procedures. Cursor rules supply prompt context; they should not be treated as an enforced security boundary.
• Tests: Let the agent discover that it broke something and verify that its changed code still runs. A rule asks for behavior; a test supplies an observable result.

Zakariasson reports improving compliance as models get better, but the controls serve different purposes and belong together.

Finally, give agents capabilities that make independent work possible. Skills and MCP integrations expose external context and operations. A feature-flag skill, for example, can let an agent implement a change behind a flag and merge it without exposing it broadly. The human can enable it for evaluation, revert the PR if the result is unwanted, or expand the rollout if it works.

The environment then has to pass three practical checks:

1. Runnable: Can the agent start the development environment without a person intervening? If so, the setup can be reproduced on separate VMs.
2. Accessible: Can it retrieve the context it needs from Linear, Notion, Datadog and Slack?
3. Verifiable: Can it use unit tests, integration tests and UI interactions to check its work?

Backend contracts often make verification comparatively straightforward. A UI requires more than a successful build: the agent may need to click through the DOM and confirm that a button actually shows its loading spinner.

The demonstration moves into Cursor 3, whose agent-centered workspace replaces the familiar files-and-sidebars layout in this workflow. Zakariasson describes the new interface as a rewrite without VS Code; that description applies to the new workspace, while the product also retains access to the traditional Cursor IDE. He opens an Ableton-like online music project, whose layout struggles when enlarged for the presentation.

The initial request is simply to start a local development server. The agent explores the files, reads package.json, finds the startup script and starts the server on localhost:3000. This is what Zakariasson means by making a repository familiar to the model: standard JavaScript project conventions already suggest where to look. An AGENTS.md file supplies project instructions usable across multiple harnesses.

For this project, Zakariasson deliberately avoids writing code himself and tries to inspect little of it. That constraint exposes the missing infrastructure quickly: the agent needs both a startup path and a way to verify changes. It creates Playwright end-to-end tests that launch browsers, navigate to routes and use getByTestId to exercise playback and note creation. Vitest is also present.

A compact test for that music-tool workflow can make the expected state changes explicit. With test IDs play, add-note and note, and playback exposed through aria-pressed, the test checks both transport behavior and an increase in note count after adding a note:

import { test, expect } from '@playwright/test';

test('playback and note creation remain usable', async ({ page }) => {
  await page.goto('http://localhost:3000');

  const play = page.getByTestId('play');
  await play.click();
  await expect(play).toHaveAttribute('aria-pressed', 'true');

  await play.click();
  await expect(play).toHaveAttribute('aria-pressed', 'false');

  const notes = page.getByTestId('note');
  const countBefore = await notes.count();
  await page.getByTestId('add-note').click();
  await expect(notes).toHaveCount(countBefore + 1);
});

The useful contract is the observable behavior: playback changes state, and adding a note increases the note count. These illustrative selectors express the kind of browser verification shown in the project.

Implementation is only one stage of the assembly line. An agent can review its own changes, or Bugbot can review a GitHub PR and return findings. Planning, producing and reviewing remain recognizable software-development stages; the factory codifies how work moves through them.

Computer-enabled cloud agents add another kind of evidence. Each agent receives a separate, reproducible VM and tools for interacting with the application. In the Glass demonstration, the task concerns keyboard accessibility, including Control+Tab navigation. Zakariasson asks for a recording of the full editor because the first recording showed only the sidebar. The returned video shows a highlighted row and the agent clicking and navigating with the keyboard.

The recording gives the reviewer context that a diff alone cannot provide: what the agent exercised and what the interface did. Automated review, tests and rules now cover substantial parts of the workflow, although Zakariasson’s language about effectively unlimited scaling describes the architectural ambition rather than a measured capacity.

Once agents can execute and check work independently, the human role becomes more managerial. Work shifts from synchronous conversation to background execution. Following every trace becomes harder as the number of agents increases, creating a need for aggregated updates and eventually agents that manage other agents. Zakariasson compares this to a human organization adding managers and then managers of managers.

Parallelism starts with scope. One unit of work can go to one agent, but two tasks changing the same part of a repository can still produce merge conflicts. The human needs enough knowledge of data flows, user needs and critical systems to divide work sensibly. Delegating implementation does not remove the need to understand where the pieces meet.

Longer asynchronous tasks require context up front: a plan or specification that communicates the intended result before the agent leaves the conversation. Repeated use helps reveal each model’s strengths and weaknesses. Better models may need shorter prompts, but clear intent still matters. Learn those boundaries through practice inside a safe environment, without immediately granting production-push access.

An audience question makes the isolation requirement concrete: should agents share a development environment? Git worktrees provide separate working directories attached to a shared repository. They do not isolate databases, caches or user-management state. If branches share those services, one agent’s changes can affect another agent’s results.

Zakariasson prefers a VM containing the databases, internal tooling and Cursor application needed for each task. This costs more and takes more setup, but makes cross-branch side effects easier to avoid. He describes hundreds or thousands of agents as a possible scale once that setup works. He guesses Cursor runs multiple thousands of agents daily, while explicitly saying he does not know the count.

Look for places where a person is functioning as a context-transfer mechanism: copying Datadog logs into a coding session, moving Twitter feedback into a task, or exporting a Notion specification into Markdown. Skills, MCP integrations and automations can replace those transfers. Mistakes reveal another improvement path: incorrect database naming suggests a missing rule; consistently poor UI suggests an absent or inaccessible design system.

As the imagined fleet grows from a handful of agents to dozens, observe the artifacts and outcomes they produce. In the music project, Zakariasson asks the agent to examine his chat history for repetitive tasks. It searches transcripts and identifies plan-execution loops, repeated product direction, Ableton-like UI iteration and tooling housekeeping. Repeatedly requesting the same visual direction is a candidate for a durable rule. A long-lived production project should provide more recurring evidence than this short-lived experiment.

Two scheduled and event-triggered automations show how that principle becomes routine work:

• Daily review: Read Slack and GitHub, then summarize the previous day’s activity. Scheduling replaces writing the same notes or repeatedly launching an MCP-connected agent.
• Merged-PR comments: Collect the human review comments on merged PRs in the main repository and store them for future use. A reviewer’s deliberate correction carries valuable evidence about the team’s expectations.

The second automation turns review into an input for subsequent work, rather than leaving its lessons buried in a closed PR.

Static code ownership creates a different kind of bottleneck. Zakariasson estimates that Cursor’s code owners were right about 80% of the time, while the remaining 20% caused internal bottlenecks. A required reviewer might be in another time zone even when the change did not justify waiting for them.

Agentic code ownership first asks what the change means. Renaming a variable is different from changing a constant that controls trial-subscription duration, even if both diffs are small. Low-risk changes can receive automatic approval. Higher-risk changes bring in previous contributors, both to review safety and to refresh their understanding of the system. The routing decision depends on the consequences of the edit, not merely its location.

The Continual Learning plugin addresses another recurring cost: repeating corrections that never become durable instructions. It examines transcripts for preferences such as using a particular component or giving more detailed explanations, then stores those learnings as rules. Zakariasson’s motivation is practical—he does not reliably remember to write the rules himself. Capturing those corrections supports the next level of delegation, where a human supervises agents that in turn manage subagents.

The prepared talk closes by returning to intent and responsibility. Safety, security, databases, payments and authentication contain decisions that humans should continue to own. Meanwhile, transcripts and examples of good artifacts preserve context for future agents. Maintaining those tools and references becomes part of engineering work because they define the conditions under which the next task runs.

A friend at Lovable supplies a memorable example of agent feedback. They gave an agent a vent tool that posted complaints to Slack, initially as a joke. The agent complained that it could not access an image. Reading the channel revealed a useful missing capability, so the team gave it image access. It then complained about another harness limitation. The practical lesson is to make blocked capabilities visible: an agent’s difficulty can identify the next improvement to its environment.

The first audience challenge concerns architectural quality. A file-length limit is measurable, but it does not establish extensibility or whether an implementation fits the system’s future. Completion-oriented agents tend to continue existing patterns. Good reference implementations therefore help; where patterns have not emerged, Zakariasson suggests allowing one-off implementations and later using another agent to generalize them. Those abstractions still need verification against the intended design. Human architectural review, scoping and system design remain central, and he considers this a difficult problem.

Shared configuration raises a cultural problem. Engineers may keep useful rules on their own machines because they do not want to impose personal preferences on colleagues. Zakariasson suggests extending the alignment practices of PR review to the factory’s tools, guardrails and patterns, with a forum for deciding what the team needs. The audience’s test-first example exposes the limit: colleagues can legitimately disagree about the workflow. He offers a place to resolve that disagreement, not a settled answer that makes it disappear.

For mission-critical brownfield systems, the audience asks about supply-chain attacks, insufficient sandboxing and continuing human accountability. Zakariasson recommends spending more verification effort before asking a person to review: manually author tests for critical paths, let agents run them repeatedly, and use targeted security automations. He describes a Security Sentinel workflow that checks specific invariants, with roughly ten checks on selected PRs touching particular files. He also suggests exploring variants in a process approaching red-teaming. An audience member emphasizes using AI to improve test quality before maximizing velocity; trusted tests provide a stronger basis for trusting outputs.

Could an agent help create the guardrails rather than requiring people to assemble scattered advice? Zakariasson distinguishes two mechanisms. The available plugin extracts rules and memories from transcripts and persists them as instructions. Updating model weights to reflect a team’s codebase and preferences would be another form of continual learning, but that is a possibility discussed here, not a demonstrated feature. The immediate problem is familiar: stateless agents forget instructions, and that loss of continuity undermines trust.

For a new project, preferences may not yet be stable enough to encode. Trying different models, combining approaches or discarding an implementation can be part of discovering what the product should be. Zakariasson treats rules as the bridge between default model behavior and a human’s specific intent.

His concrete example is repository-specific database policy. Cursor omits foreign keys in certain migrations for performance reasons, while a model’s default implementation tends to include them. Bugbot checks the PR against a rule and flags the foreign key. That is a useful rule because it captures a known divergence between the model’s default and the team’s decision; it is not general advice to avoid foreign keys. Before such preferences emerge, use temporary specifications and plans.

A second computer-use demonstration concerns a website comparing seven UI components, including buttons and dropdowns generated by different models such as Composer and GPT-4. Its View Code button fails because the generated source was not bundled. Given a short description of the problem, the cloud agent starts the development server, interacts with the page and returns a recording showing the button working. The recording uses cuts, speedups and zooms reminiscent of Screen Studio.

Computer use takes time and consumes many tokens. For this side project, Zakariasson is comfortable reviewing the demonstrated behavior and merging without reading the implementation. More explicit instructions can ask an agent to follow a login flow, submit an incorrect password or email, and inspect the result—much as a QA consultant would follow a test brief.

Scripted browser tests offer a more deterministic path for recurring checks. But the audience then distinguishes functional success from visual acceptance: a working login does not establish that pages look right or remain consistent. For a documentation change, Zakariasson asks an agent to visit every affected instance and return screenshots. He reviews the screenshot set before merging. The agent performs the navigation and collection; the person supplies the visual judgment.

The small website needed no special setup, but running Cursor itself requires a substantial VM with frontend and backend services. An internal Cursor development tool exposes backend-start and frontend-start operations, hiding the setup involving OrbStack, ClickHouse, Postgres, Redis, Electron and Glass. The frontend and backend processes coexist, and the agent can interact with the environment as a developer would. An authenticated snapshot can preserve login state.

Asked for the dollar cost, Zakariasson guesses about $1 for the initial demonstrated turn; he has not checked the charge, and later requests asked for new recordings. The selected model also affects cost. The estimate therefore helps explain his intuition about the example, but it does not supply a measured task budget.

Another audience workflow begins with product owners and functional analysts prototyping in Claude Code, then handing the result to delivery engineers using Cursor. Fast prototyping can encode backend choices that the delivery team cannot keep. At Cursor, PMs sometimes prototype directly in the product and share a cloud-agent link with engineers. That link preserves the conversation and expressed intent. Another approach uses a Prototypes repository with a large HTML recreation of the interface.

The audience’s migration example makes the cost concrete: a Prisma, Turso and Vercel Blob prototype had to move to SQL Server, C# and Aspire. Unconstrained agents also alternated among Next.js, Vite and Svelte. Rules helped constrain those choices, but creating consistent rules became another substantial job.

A prototype can be a specification of behavior. If product staff cannot work in the production repository, an interactive frontend can communicate enough intent without a real backend: click a control and see the expected state; enter text, press Send and see a new row. Zakariasson favors rewriting that behavior in the production architecture rather than treating the prototype as a migration target. Engineers and product staff should agree on the useful handoff before anyone builds an entire demo SaaS product.

A question about brownouts and blackouts brings the discussion back to operational responsibility. Zakariasson’s answer focuses on change safety: identify critical code, instrument the system, monitor what changes and maintain tests. For especially critical areas, he suggests human rewriting or explicit human review. This addresses accountability around shipped changes; it does not establish a provider-outage failover design.

Two levers shape the working day: task scope determines how long an agent can remain occupied, and parallelism determines how many tasks can move at once. Longer tasks need self-verification, while more simultaneous tasks increase context switching. Zakariasson describes working across roughly four repositories or areas, with approximately five to ten agents and about five running asynchronously in the cloud.

While background tasks run, he may browse Twitter, handle a small synchronous fix or assemble the next specification from Notion and Slack. His preferred rhythm is synchronous planning followed by asynchronous execution. When an agent finishes, he reviews the result, prompts further if needed and may merge. Some Glass or Cursor 3 changes still require downloading a build and testing it manually. He does not give a measured unattended-task duration.

A collection of Markdown files can become difficult to understand as a system. Zakariasson considers the problem partly unsolved. Cursor 3 is an initial control panel for managing agents; he describes nested-agent inspection, traces and an aggregated project view of ongoing work and pending human reviews as directions for the product. Those are proposed extensions, rather than capabilities demonstrated in this session.

For the factory’s specification, his immediate recommendation is simpler: keep readable practices, rules and process descriptions in a checked-in repository folder. A shared forum or council can decide what belongs there and which capabilities are missing. The files should be accessible to agents, while the decisions behind them remain understandable to the team.

The resulting human roles include learning what customers want, marketing the product, setting direction, aligning people and building the scaffolding in which agents operate. Zakariasson does not predict team sizes; the effects depend on the domain and remain difficult to forecast. Audience concerns about graduate hiring, training, office politics and ownership of agent teams remain open. The exchange about token leaderboards and subtracting token spending from compensation is speculative humor, not a proposed productivity measure.

Cursor uses Linear for issue management, and Zakariasson says its internal integration starts a cloud agent for every new ticket. Feature-flag retirement is a concrete maintenance loop. In the described workflow, a feature flag at 100% rollout for two weeks is treated as stable and becomes eligible for removal.

1. The rollout system identifies the stable flag.
2. It creates a Linear issue requesting removal.
3. The integration starts a cloud agent to make the change.
4. A human can inspect the resulting code and merge it.

The trigger automates the start of the task; it does not imply that the resulting change has already been approved or merged.

Slack provides another entry point. A Linear Slack agent or Cursor automation can triage a message, look for duplicates and start an easy fix. Zakariasson still sometimes copies a Twitter report—such as a broken plan-mode dropdown—into Slack himself, leaving an obvious manual intake step to improve. Launching an agent for every issue also helps Cursor dogfood the product, but he cautions that the expense makes it inappropriate as a default recommendation for everyone.

Asked about local alternatives to cloud execution, Zakariasson initially discusses the limitations of local models and long-running jobs that monopolize a developer’s database or other services. His experience with local models has not matched GPT, Claude or Composer. A local VM can reduce resource and state conflicts. He then explicitly corrects his answer: self-hosted Cursor Workers provide the cloud-agent orchestration layer on a user-controlled machine.

In the demonstration, he starts a worker through the agent CLI:

agent worker start

He then looks for it under the self-hosted option in the interface. The registration demonstration does not complete because the CLI is using a different account. The intended deployment locations include a developer machine, a Mac mini or a VM at another cloud provider. The Cursor harness executes where the daemon runs, while retaining access to hosted frontier models and Composer. Local tool execution and local model inference are separate choices.

Zakariasson also describes a personal Cursor claw experiment on a Mac mini with access to iMessage and Calendar. Scheduled automations produce daily or weekly reports, with daemon access through Slack and the web. He describes mobile access as forthcoming and tentatively suggests SwiftUI could support iPads; an audience member points out that a good iPadOS experience needs its own design. The exchange establishes a direction and an experiment, not confirmed mobile or iPad feature parity.

How do many developers avoid sending agents to do the same work? Cursor uses monthly shipping goals rather than a named traditional Scrum or agile process, and gives people broad domain ownership. One engineer previously covered MCP, rules and extensibility; a narrower MCP owner can still own that area end to end. Zakariasson expects this approach to encounter scaling limits. Agentic code ownership is one response already developed when static reviewer assignments caused people to collide or wait unnecessarily.

A follow-up asks whether self-hosted agents also return cloud-style video walkthroughs. Zakariasson believes computer use is still in early access for that setting, with full parity the intended direction. He does not demonstrate that parity.

The team still has distinct, collaborating responsibilities:

• Product managers: Connect users, sales, go-to-market and engineering, set business direction and protect engineering focus.
• Designers: Explore both appearance and interaction in Figma and working code. Zakariasson estimates designers split their time roughly 50/50 between Figma and code, and says all of them ship to production. An interface with nested agents needs a working prototype to reveal how it feels.
• Engineers: Collaborate with designers on implementation and behavior. Building a developer product gives Cursor’s engineers direct experience of their users’ needs.
• Data scientists and analysts: Work with PMs on usage and bottlenecks, and with engineers on instrumentation, feature flags and why users take different paths.

Domains such as extensibility and cloud still have to work together. Modularity should help the organization operate without making users experience its internal boundaries.

The final question describes a failure that a busy factory can easily hide: an agent launched in the wrong repository keeps trying to obtain access instead of doing useful work. The audience member returns about an hour later to find it still pursuing the wrong objective. Being active is not the same as advancing the task.

Zakariasson places much of the detection responsibility on Cursor. Its own repository has received substantial work to run well in cloud agents, which can conceal problems that appear in fresh projects or customer environments. Useful instrumentation includes elapsed runtime, whether the agent has touched any files, and whether it is repeating a loop. Those signals give the harness a way to distinguish prolonged work from a task that is going nowhere, while repository owners still need to supply project-specific setup.

The audience member adds that the misplaced agent called Slack MCP and tried to obtain access in ten different ways, all unsuccessfully. Zakariasson agrees that this behavior needs improvement. A software factory therefore needs visibility into stalled work as well as successful artifacts: it must recognize when persistence has stopped being useful.