Software teams can get more from AI agents by delegating work across the full software development lifecycle, rather than adding AI to tools built for writing code line by line.
2
Agents need context from code, documentation, meetings, incidents, team memory, and engineering systems to produce useful plans and changes.
3
The engineer's role moves toward orchestrating parallel agents, setting direction, communicating clearly, and handling security, ownership, and auditability.
Summary
Eno Reyes argues that enterprise software development needs an agent-native workflow rather than AI features layered onto human-oriented coding tools. Agents should help with research, planning, PRDs, ticket creation, coding, testing, pull requests, incident response, and the documentation that follows incidents. The quality of their work depends heavily on context. That includes code and architecture, but also customer transcripts, meeting notes, design decisions, runbooks, Slack discussions, logs, and previous incidents. Reyes describes Factory's droids working across these sources, asking for clarification, producing plans, and executing tasks through existing engineering tools. He is honest that fully automating incident response is not realistic today, and he stresses enterprise concerns such as audit logs, ownership, security, and indemnification. His view is that developers will spend less time writing individual lines of code and more time coordinating systems of agents and shaping how their teams work.
Reyes says current AI coding products mostly add AI to tools designed for humans to write individual lines of code. That may produce incremental improvements, but he sees little clarity about the larger change. He compares this approach with Henry Ford's quote about people asking for faster horses. Factory's proposed shift requires delegating much of the software lifecycle to agents, with an interface for managing tasks, shared context from engineering tools, agents that produce dependable results, and infrastructure for many agents to work at once. He presents those requirements as difficult engineering problems that Factory has worked on with large organizations.
Agents extend engineers instead of replacing their judgment
Reyes rejects the idea that agents can replace human ingenuity. He compares agents to climbing gear and production software to climbing Mount Everest. Vibe coding can help with simpler work, but it is not enough for a legacy Java 7 application that runs 5% of global bank transactions. In his example of a Factory droid, the agent searches the repository, checks the branch and machine, reviews recent changes, and uses memories from previous interactions. It returns a plan and asks the user to clarify parts of the task before it writes code, runs pre-commit hooks and linting, and opens a pull request that passes CI.
Reyes says AI tools are only as good as the context they receive. After investigating thousands of droid-assisted development sessions, Factory found that failures often happen because the agent lacks information needed to solve the problem, rather than because the model is incapable. He gives ordinary examples of context that models do not automatically know, such as a morning standup, a meeting, or a whiteboard discussion. Teams can provide that information through transcribed notes, uploaded photos, and integrations with their data sources. Agents therefore need access to the information between systems, not only the files in a code repository.
Planning with agents starts by delegating research
Reyes says the hardest part of software development is often deciding what to build. For a feature involving a new model release in an existing chat application, a droid can search the internet, inspect the codebase, use product goals from organizational memory, and read a recent design document. Planning then becomes a shared exploration process. The agent does the groundwork and research, while people review possibilities and make decisions. He also says platforms will need to handle integrations more cleanly, since requiring every developer to install multiple MCP servers and distribute API keys creates unnecessary friction.
Company documentation can become operational memory for agents
Factory used three months of customer transcripts, meeting notes, and architectural knowledge to plan a feature for cloud development environments. The knowledge droid was asked to find patterns in customer feedback that matched the team's assumptions and identify technical constraints. Those intermediate documents fed into a final PRD. A droid with access to Linear and Jira could then turn that PRD into a roadmap with dependent tickets and work that eight code droids could handle in parallel. Reyes says PRDs, design documents, RCA templates, roadmaps, and meeting transcripts give agents a map of how the team thinks, especially when the documents explain why decisions were made.
Incident response can use context from across the organization
Reyes demonstrates a droid taking a Sentry incident and producing an RCA and mitigation plan. Traditional incident response scatters information across logs, metrics, historical incidents, runbooks, team discussions, and people's memory. An agent with access to those sources can gather the material and reduce the search from hours to minutes. After an incident, it can create runbooks, update response workflows, and store the team's knowledge. Reyes says Factory has seen teams cut incident response time in half and reduce repeat incidents, although he also says it would be unreasonable to claim that all SRE and RCA work can be automated today.
Developers move from the inner loop to orchestration
Reyes says strong developers are spending less time in an IDE writing individual lines of code. They manage agents that can work on several tasks at once and build patterns around the wider software workflow. In this model, developers move from executing each step to orchestrating systems that work on their behalf. He argues that clear thinking and communication with both people and AI matter more than optimizing one particular system. Agents can amplify an engineer's abilities, but they still need people to set direction, resolve ambiguity, and decide how the organization should operate.
Enterprise agents require explicit controls and ownership
Reyes closes by framing Factory as an enterprise platform and asks organizations to consider what happens when an agent takes a dangerous action. He mentions security, audit logs, responsibility, ownership, auditability, and indemnification. The issue is not only whether an agent can execute a command, but whose responsibility it is if something goes wrong. He tells security professionals and lawyers to ask these questions early and warns that running an unrestricted 'YOLO mode' inside an enterprise is a poor approach. Factory's controls are part of the product problem, alongside agent capability.
"The future belongs to developers who understand how to work with agents, not those who hope that AI will just do the work for them."14:21
Who should watch
You work on a large or legacy codebase where coding agents lack the product and organizational context needed to make safe changes.
Your team is considering agents for planning, ticket creation, incident response, or documentation, rather than only code generation.
You are responsible for enterprise security, auditability, ownership, or legal risk around autonomous software agents.
