A software factory needs structured code, reusable patterns, rules, tests, isolated environments, and access to the context agents need.
2
The human role shifts from writing code to managing asynchronous agents, reviewing outcomes, and making decisions about security, architecture, payments, and other sensitive areas.
3
Factories improve through feedback loops that turn repeated work, review comments, failures, and agent transcripts into automations and rules.
Summary
Eric Zakariasson describes software development as a factory that can move from autocomplete, to pair programming, to agents producing most of the code, and eventually to a system where agents plan, build, test, review, and ship work with limited human intervention. He explains the setup required: modular code, established patterns, rules that emerge when agents fail, hooks around sensitive areas, automated tests, and environments that agents can start and use without help. His own workflow uses isolated cloud VMs, browser-based testing, automated code review, scheduled reports, Linear and Slack integrations, and continual learning from transcripts and PR comments. The human role becomes managerial. People scope and parallelize work, provide context through plans and specifications, inspect outcomes, and retain responsibility for architecture, security, authentication, databases, and payments. Zakariasson is also direct about the limits. Code quality and team-wide agreement on factory rules remain difficult, and agents need strong observability to detect loops, wasted work, and unsafe changes.
A software factory is the next step after pair programming with an agent
Zakariasson places common AI-assisted development between levels two and three, where a developer exchanges requests and suggestions with an agent. At the next level, the agent generates most of the code while the human reviews it. He describes his own work as closer to level four, where he delegates as much as possible and reviews outputs before inspecting code. A software factory goes further. It is a black box, or a "dark factory," where agents build, test, review, and ship code after a human provides intent, instructions, and a goal. The benefits he gives are higher throughput, consistent outputs, and more room for a person's creativity.
Agents work better when the codebase exposes clear patterns and boundaries
The foundation is a codebase that is easy to locate and understand. Zakariasson recommends modular, collocated code so an agent can find the relevant files without searching the whole repository. Existing patterns also matter, such as authentication methods, startup scripts, and test-writing conventions. Agents can copy these references instead of inventing a new approach. He compares this to onboarding a human developer: if the repository is easy for a person to learn, it is more likely to be usable by an agent. The setup should also define hooks and rules, especially around encryption, sensitive data, authentication, and other areas where a mistake could be costly.
Rules should emerge from failures instead of being installed wholesale
Zakariasson says Cursor rules are often misunderstood. Teams may install every rule associated with their framework, but he has found that useful rules usually emerge when agents repeatedly go off track. A rule then records the desired procedure, similar to a standard operating procedure, and tells agents what they can and cannot do. His example is database migrations at Cursor, where the team avoids foreign keys for performance reasons even though models often add them because they are a familiar pattern. Bugbot can flag that mismatch during review. Rules bridge the model's default behavior and the team's actual intent, so they should change as the codebase and preferences become clearer.
Self-verification determines how far agents can work without supervision
A factory needs systems that let agents check their own work. Zakariasson lists unit tests, integration tests, and UI tests that click through the DOM. Backend checks are often easier because contracts and boundaries are explicit. Web interfaces need tests that verify visible behavior, such as whether a button works and displays a loading spinner. In his music-agent project, the agent created end-to-end Playwright tests and used Vitest. Cursor's cloud agents can also control a computer, record their browser actions, and return a video for human inspection. Zakariasson describes several stages in the factory: plan, produce, review, and follow the full software lifecycle through automated, codified work.
Parallel agents require isolated environments and deliberate task boundaries
Moving from synchronous work to asynchronous work changes the developer's job. Zakariasson usually runs about five to ten agents asynchronously in the cloud, while planning or handling smaller tasks himself. Parallel work must be scoped because agents changing the same code can create merge conflicts. He prefers separate virtual machines, each with its own copy of the codebase, database, cache, and internal tooling. Shared workspaces can use Git worktrees, but separate services are still needed to avoid side effects between branches. He says this costs more and takes more setup, yet an isolated environment can eventually support scaling to 100 or 1,000 agents.
Factory improvements come from automating the human steps around agents
Zakariasson asks managers to find every place where people copy information between systems. Logs from Datadog, user feedback, and specifications in Notion can become inputs to skills, MCP tools, or separate automations. He demonstrates a daily review that reads Slack and GitHub and sends a summary of the previous day's work. Another automation reads merged pull-request comments because human review comments carry high signal and can be stored for later use. A code-owner automation estimates pull-request risk, approves low-risk changes, and finds relevant reviewers for higher-risk work. These loops reduce repeated manual work and give the factory information it can use later.
Continual learning can turn agent conversations into project rules
Zakariasson describes a continual-learning plugin that searches previous agent transcripts for corrections and preferences. If a developer repeatedly tells an agent to use one component instead of another, or asks for more verbose descriptions, the system can store that instruction as a rule. This avoids relying on the person to remember to write a rule after every correction. He calls the plugin a practical shortcut rather than true model training. A more advanced approach would change model weights based on the codebase and the team's behavior. In either case, he sees memory and stored context as necessary because agents are otherwise stateless and may forget instructions.
Human accountability remains necessary for architecture and high-risk decisions
Zakariasson tells people to keep important decisions in human hands, including safety, security, databases, payments, and authentication. For mission-critical systems, he recommends writing tests for critical behavior, running security automations against specific invariants, and spending compute up front to explore variants and red-team changes. Humans still need to review architecture and system design because agents tend to finish the immediate task rather than plan for how the code will evolve. He also says observability should detect agents that run for a long time without touching files, repeat themselves, or work in the wrong repository. A factory can reduce code review, but it cannot remove responsibility for what ships.
Team-wide factory rules need shared ownership and a place to be decided
Zakariasson acknowledges that engineers naturally build personal tools and may keep rules on their own machines when teammates have different preferences. He suggests applying familiar alignment practices, such as pull-request review, to the factory itself. Teams need a forum or council to decide which rules, integrations, guardrails, and conventions belong in the shared system. For new products, he does not expect all good rules to be known in advance. He recommends using temporary plans and specifications first, then allowing durable rules to emerge from actual work. Factory configuration is a human change-management problem as much as a technical one.
