Factory: Engineers Become Managers — Who Can Still Check Their Agents’ Work? (#AI4SDLC)
The hook on the thumbnail of this 18-minute talk by Davis Palmie, an engineer at Factory, continues our discussion of dark factories. At AI Engineer World's Fair 2026, he describes a system that turns bug reports and user feedback into production code. Humans set direction and govern agents. It sounds like a promotion, but let's read the job description :)
1️⃣ Manage the entire chain. Palmie argues that writing code has long ceased to be the main bottleneck. Changes wait for review, bugs need reproducing, documentation goes stale, and product decisions get lost between teams. His software factory connects these stages: signal → diagnosis → plan → code and tests → review → deployment → monitoring the result. Feedback feeds the next cycle. This develops the factory model from The New SDLC: engineers build the system that produces changes.
2️⃣ Prepare the environment. Factory has eight areas of agent readiness: linting and formatting, builds, tests, documentation, reproducible environments, modularity, observability, and security. Agents need clear commands, current instructions, and access to context beyond the repository. Humans benefit from all of this too. Add the ability to choose a model for each task and run execution within your own infrastructure.
3️⃣ Introduce autonomy gradually. Start with incident diagnosis: an agent reads a Sentry alert, gathers traces, and posts its findings in Slack. An engineer checks the diagnosis and decides what to do. Each stage gets an owner and oversight before the chain becomes a loop. This echoes our Loop Engineering discussion: a verifier must be able to say no in time.
This is where the thumbnail turns out to be bolder than the content. Palmie explicitly says precise execution does not prevent poor design: architecture, strategy, and approval of changes still require humans. He therefore has more in common with Dex Horthy than it might seem. Dex described how HumanLayer stopped following the changes produced by its lights-off factory and, during an incident, faced code it no longer understood well. His argument: tests check whether it works now, while the cost of poor design appears months later.
The managerial part of the job does grow: setting tasks, prioritizing, delegating, and giving feedback. But how do you check a solution once you stop understanding the system? For Geoffrey Litt, this is the new bottleneck: AI accelerates changes while the human mental model of the system falls behind. Making an engineer the reviewer does not automatically give them time to understand the work.
Palmie proposes useful metrics: signal-to-production time, human intervention count, time to repair, code shelf life, and cost per PR. I would qualify intervention count: it can fall because everything works, or because people have stopped checking. Comparable quality is essential here.
What does Factory sell? On the company's website, this picture becomes a platform: Droid for working with code, automations, model routing, Mission Control, reviews, and documentation that stays up to date. For organizations, there are integrations and access controls. The company sells tools for organizing and overseeing agents' work.
This is especially clear in Missions: an orchestrator breaks a goal into tasks, workers operate with fresh contexts, separate agents validate the result, and shared files hold state. Roles and checks become part of the product. So “Engineers become managers” also explains why you might buy Factory: if your job now involves managing agents, it offers a workspace for that management. Engineers bring their ability to assess architecture and understand what has actually been built.
#AI4SDLC #AI #Agents #Engineering #Management #DevTools