The Software Factory: From Bug Report to Production Code — Davis Palmie, Factory
Davis Palmie of Factory explains the software factory, a system of agents that turns bug reports and user feedback into production code. He covers leadership concerns about cost, model choice, engineering roles, and org structure, argues that coding was never the bottleneck, and lays out principles for a factory: model agnosticism, sovereign deployment, and SDLC-wide integration. He also describes eight pillars of agent readiness, starting with narrow use cases like incident triage, and closes with why outcome metrics should replace token counts.
From typing code to governing agents
Davis Palmie, a member of technical staff at Factory, argues that software engineering is moving from writing code by hand to governing a system of agents that turns input signals such as bug reports, Sentry alerts, and user feedback into production code. He calls that system the software factory. Palmie speaks from experience on both sides: he co-founded Lummetric, an agent platform for investment teams that went through Y Combinator and was acquired by Factory, and before that he led engineering at Slalom’s innovation lab, where he saw AI rollouts in large enterprises and in more AI-native organizations.
Three eras of AI engineering
Palmie traces three phases. The first was tab autocomplete and next-token prediction, where the engineer stayed firmly in the driver’s seat. The second brought whole-file generation, which turned engineers into discerning copy-paste editors who still controlled the output. The third is agents that are tightly coupled to the codebase: they gather their own context, call tools, and debug their own output. He notes that autocomplete once felt magical and now looks quaint, and that each step up the abstraction ladder (tokens, files, context, entire systems) has made engineers more valuable rather than less. The current shift is the next rung. Engineers keep guardrails tight, catch code drift, and set high-level priorities, while the system does the implementation work.
Four questions every leader asks
Palmie organizes the leadership concerns around AI-generated output into four questions.
Cost first. He points to public stories of runaway AI budgets, such as Uber’s CTO exhausting an annual AI budget by April and Microsoft pulling back Claude Code licenses to cut spend. Factory is not locked to one model provider, so teams can match cost and capability per task. His CEO’s analogy is that a kid who needs algebra tutoring doesn’t need Albert Einstein.
Second is access to the best model. Palmie rejects the idea that you must bet on one model. With open-source models improving, he argues for choosing the right tool for each job, or routing dynamically.
Third is the future of the engineer. The line between product and engineering is blurring. Engineers will build and maintain the system that produces the code, and they will set its high-level direction.
Fourth is the organization. Team boundaries are blurring, and context has to flow across them. Information silos were already harmful for humans, and they are worse for agents.
Coding was never the bottleneck
The central claim is that writing code was the easy part. Palmie asks the audience to look at real engineering metrics: the median time to review a PR, how long it takes to reproduce a user bug report, who keeps docs current with every PR and every strategy meeting, and who maintains test suites. Testing, product, and engineering often operate as separate worlds. If you pull your DORA metrics and look at the time from code written to code in production, he suspects it dwarfs the time spent making the change. The real need is cohesion across these surfaces. Docs go stale, dead code lingers, and communication layers multiply between strategy, product, engineering, and QA. Humans struggle with this, and agents struggle even more. Building a factory therefore means letting agents bridge these services and understand the organization’s nuance.
What a software factory does
A software factory is a system of agents that takes a team from input signal to production deployment. Palmie describes agents taking on customer support, product engineering, and deployment operations. Across those roles they triage incidents, make plans, create and update docs, write and review code, test, roll out releases, and monitor them. He is clear that this is too much to attempt at once, and that teams need time to build trust.
His advice is to start narrow and verifiable. Incident triage is the example. An agent reads a Sentry alert, pulls traces and other context, and posts a diagnosis in Slack, and engineers review it and decide what to do. As correct diagnoses accumulate, the team develops trust in that pillar. Each stage needs careful ownership and monitoring before the pipeline is allowed to loop. Once the output of the system can be tied back to its input signal, Palmie says, organizational self-improvement becomes possible.
Three principles
Palmie gives three principles a software factory should follow.
First, it should be model agnostic. He says GPT 5.2 can match the latest Opus models on code review at half the price, and that open-source alternatives can be 10 to 30 times cheaper. Being free of a single lab means teams can weigh speed, task efficacy, and cost together.
Second, deployment should be sovereign. Organizations should not have to compromise their security architecture or policies to fit AI in. Factory supports fully managed deployments, bring-your-own-machine setups, and fully airgapped environments.
Third, the factory must be integrated across the SDLC. Docs changes should inform code and vice versa, and planning goals should shape what gets tested. Palmie stresses that the pillars are interdependent: a weakness in one is a weakness in the whole system, and an improvement to one sub-team improves the entire system.
What it looks like in practice
In AI-native organizations, Palmie sees sub-teams fused and incrementally automated under one factory. Common patterns include triaging incoming signals so the agent has a diagnosis before a human answers the page, proactively scanning for secrets and vulnerabilities, creating and maintaining tests while pruning brittle ones, keeping docs synced with code and meeting channels, and reviewing code, commenting on PRs, and monitoring rollouts. The human role moves toward judgment and correction, and the way the agent learns from those corrections matters.
He frames the enterprise payoff as scaling. In a large, fragmented company, managing teams scales linearly with headcount. A software factory should move that burden from O(n) to roughly O(1). Governance (guardrails, agents, docs, testing policies) gets defined once and standardized across the organization, pulling everyone toward the highest bar rather than the lowest common denominator. Because agents work across all these surfaces, they can hold a shared quality bar, unify context in one place, and give executives visibility into how the whole SDLC is performing.
Surface agnosticism
Palmie argues that agents should be surface agnostic, just as models should be vendor agnostic. Teams should not have to change their tooling to fit an AI provider. Factory offers agents on remote machines, in the CLI, and in Slack, and across whatever tools teams already use. Humans and agents may use different services, but they should share the same underlying harness and context.
Agent readiness: eight pillars
The undertaking of building a factory tends to surface tribal knowledge, manual processes, and outdated information. Fixing these helps agents and engineers alike. Factory evaluates agent readiness across eight pillars: validation (linters and formatters as guardrails), build systems (documented build commands and CI), feedback loops (tight unit and integration tests, plus readmes and AGENTS.md files), reproducible dev environments an agent can use, modular code with clear boundaries and resistance to sprawl, observability (how long it takes to learn why something failed), and proactive security scanning for secrets and vulnerabilities. Palmie’s takeaway is that agents and humans walk the same roads, so paving them well pays off twice.
Governance, rollout, and human direction
He insists that you cannot govern what you cannot see. Engineers must monitor agent performance and control behavior. At Factory, every action is auditable, operates under the organization’s standards, and uses role-based access control with least privilege. Rollout should be incremental: automate individual pillars first, and only then turn the system into a loop.
Palmie is clear that precise execution does not fix poor design. Humans remain essential for architecture, strategy, and direction, and they serve as validation gates. Engineers will not be replaced, but judgment and prioritization now matter more than mechanical implementation skill. Just as code no longer has to be punched onto cards, code no longer has to be written by hand. Teams set strategy and risk parameters and let agents execute.
Measure outcomes, not tokens
The closing argument targets vanity metrics. Lines of code and tokens generated are gameable and not tied to outcomes. Token leaderboards at large companies, he says, encourage profligate spending, which is Goodhart’s law playing out in real time: once token usage becomes the target, it stops being a good measure. The question is not who spends the most on tokens but who gets the highest-leverage outcomes from that spend.
The metrics Factory prefers are signal-to-production time, human intervention count, median time to repair, shelf life of code, and cost per PR. Agent readiness, in his framing, is a precursor to effective engineering, and agents need the same careful governance as engineers: tooling, access levels, and review systems. The end user does not care how much an organization spends on AI. They care about the improvements the software factory delivers.