One morning, Patrick Debois opened Slack and discovered that his team’s software factory had created 15 tickets about improving itself. The unsettling part was that nobody’s name was on them.
Before that, the same factory had moved beyond engineering maintenance and started contributing to marketing and sales work. The experiment raised a question that reaches far beyond coding agents: if a software factory can improve itself and work across departments, who owns it?
That question anchors episode two of After the Last Engineer. Patrick gave the industry the word DevOps when he organized the first DevOpsDays in 2009 and later co-authored The DevOps Handbook. Today, at Tessl, he is exploring the next version of a familiar challenge: turning a promising technical capability into an operating model that an organization can trust.
A software factory is not another engineering tool
Cloud strategy was often delegated to engineering or infrastructure teams. A software factory needs a broader mandate because it connects business intent, context, agents, verification, release, operations, and feedback across departments.
We see this as DevOps returning in a different shape. The tools are new, but the questions are familiar: Who owns the flow? What should be shared? Who can stop a release? What evidence makes automated work trustworthy?
Our first podcast episode showed that the bottleneck moves when agents make implementation cheap. Episode two goes further. When the factory itself becomes a business capability, responsibility must move with it.
A practical blueprint for building a software factory
1. Secure the mandate before choosing the tools
A factory cannot be introduced as, “Here are some agents; engineering will figure it out.” It changes how work enters the organization, how decisions are recorded, how risk is managed, and how different teams contribute to a product. That requires stakeholder authority, not only a tool budget.
The accountable owner might sit in engineering, a platform group, or a cross-functional transformation team. The reporting line matters less than the mandate. The owner needs authority to define shared controls, resolve competing priorities, fund the supporting infrastructure, and decide where autonomy stops.
Patrick is specific about the capabilities behind that mandate. Software engineering and AI engineering remain core because somebody must understand both the product and the agents changing it. Operations, security, and business owners define the boundaries. At Camplight, we summarize it this way: you do not merely need permission to test a software factory; you need a mandate to operate and improve it.
2. Start with one dependable loop
At Tessl, a factory hackathon produced five or six factories, exposing several possible shapes before the organization committed to one. A factory can begin with a prompt, gain context and tools, enter a repeatable loop, and only then mature into shared infrastructure.
The first loop should be narrow, measurable, and reversible. Maintenance is a strong candidate: dependency updates, bounded bugs, test repairs, documentation gaps, and recurring cleanup already have visible queues and acceptance criteria. The organization can learn how to review evidence, contain failures, and recover.
Patrick’s go/no-go test comes before the factory. If a local coding agent cannot complete one useful task with dependable context and a reliable verifier, do not scale yet. Make that loop repeatable before moving it into shared infrastructure. Start by asking where work stalls, what a correct result looks like, and how the system can prove it.
3. Choose the right point on the autonomy spectrum
A factory is not either manual or fully autonomous. It sits on a spectrum of automation. One workflow may stop for approval before implementation. Another may deploy a low-risk maintenance change automatically. A third may be allowed to create a disposable prototype but never touch production data.
Full autonomy is not the objective. The 60 percent example in the conversation is illustrative, not a universal target. Choose enough autonomy to improve flow without exceeding the organization’s ability to detect, contain, and recover from mistakes. Dependable partial automation can be more valuable than chasing 100 percent with invisible risk.
This also changes who can participate in product development. Product, marketing, sales, and eventually customers may be able to propose or prototype changes directly. Their access should expand with the quality of the controls, not with the confidence of the demo.
4. Centralize the safety primitives, not every workflow
Teams will want different models, agents, tools, and interaction styles. Forcing everybody through one rigid workflow can make the central factory slower than local experimentation. Patrick’s platform-team framing offers a better balance: provide paved roads and shared primitives, then let teams adapt the route.
- Identity and permissions: every agent acts with a known identity and the minimum access required.
- Sandboxes and isolation: untrusted work cannot freely affect shared systems.
- Verification: tests, linters, evaluators, and policy checks can reject an output independently of the agent that produced it.
- Delivery controls: releases have explicit approval boundaries, rollback paths, and recovery procedures.
- Observability: the organization can inspect what agents attempted, which context they used, and why a result was accepted.
- Architecture: repeatable decisions and constraints reduce the number of ways a locally plausible change can damage the wider system.
These controls are not evidence that AI-generated code is uniquely bad. Human code is the reason teams already use formatters, linters, tests, reviews, and release policies. Automation makes those practices more important because it increases the speed and volume at which both good and bad decisions can propagate. Our approach to independent verification in a software factory starts from that reality.
5. Turn context into organizational memory
Patrick recommends beginning with the shortest feedback loop: use an agent locally, learn how it behaves, and then add constraints. We agree that local use is often the fastest way to discover value. Our view at Camplight is that local context cannot be the final operating model for a team.
Prompts, intent, failed approaches, corrections, acceptance evidence, and reusable agent skills can become organizational intellectual property. When those artifacts remain on individual machines, every person repeats part of the same learning. A managed factory can preserve them so that an approved practice compounds and a rejected path does not have to be rediscovered.
More context does not automatically create alignment. Sales may need a demo immediately, marketing may need a promised capability, and engineering may need stability for current customers. All three realities can be valid. An agent cannot resolve that conflict by reading more documents. The organization still needs a decision process, a source of authority, and a way to record why one priority won.
A factory amplifies the operating system it enters. Clear decisions become reusable context. Confused priorities become faster confusion.
6. Expand beyond engineering deliberately
Tessl’s experiments surfaced two separate developments: the factory handled maintenance work that people had left behind, and it also started commenting on marketing and sales boards. Together, they suggest a business factory rather than a coding factory: one system helping multiple functions turn intent into tested artifacts.
The opportunity is real. A product person can test an interaction instead of describing it in a ticket. Marketing can update supporting material alongside a release. Sales can build a bounded demonstration around a prospect’s problem. Engineers can become platform builders who encode the guardrails, evaluators, and reusable capabilities that help those teams move safely.
But cross-functional reach should be earned. A factory that cannot recover a deleted database, explain an access decision, or detect a broken deployment is not ready to multiply its production touchpoints. Reach follows reliability.
7. Build what differentiates you; rent the rest
The old build-versus-buy question still applies. Agent runtimes, model access, sandboxes, proxies, and generic evaluation infrastructure can be purchased or assembled from reusable components. Rebuilding every primitive creates maintenance work without necessarily creating advantage.
The differentiating layer is usually the one closest to the organization’s product judgment: its context, workflows, architecture, acceptance criteria, risk boundaries, and accumulated operating knowledge. If your value sits beneath the factory, owning more infrastructure may be strategic. If your value is created on top of it, a managed platform may be the better foundation.
The decision is not simply whether to own the software. It is which capabilities the company must retain if a vendor, model, or market changes. Our dark software factory vendor checklist provides ten questions for examining that boundary.
A 30-day software factory discovery plan
- Week one: establish ownership and a baseline. Name one accountable owner, choose one constrained workflow, document its current lead time and failure modes, and define what the agent may never touch. Exit the week with a written mandate and a measurable problem.
- Week two: prove one local loop. Give a small group dependable context and one independent verifier. Run real but reversible tasks. If the loop cannot produce repeatable evidence, stop and fix it rather than adding more agents. Exit with at least one workflow that can succeed more than once under the same controls.
- Week three: make the learning shareable. Move the proven loop into a managed environment. Add identity, permissions, observability, recovery, and a shared record of prompts, failures, corrections, and acceptance evidence. Exit with an audit trail another team can understand.
- Week four: compare shapes before standardizing. Let a few teams adapt the proven primitives to similarly bounded work. A small factory hackathon can reveal which parts should become paved roads and which should remain local. Exit with a decision to expand, revise, or stop, supported by delivery and risk evidence.
The next DevOps problem is ownership
DevOps was never solved by installing a pipeline and handing it to operations. Software factories will not be solved by buying agents and handing them to engineering. Both shifts require organizations to redesign responsibility around a faster flow of work.
The 15 tickets were not a warning that the factory had become sentient. They showed that the system could propose work about its own operation before anybody had been made accountable for reviewing or acting on it. The separate movement into marketing and sales exposed the same organizational gap: the capability had expanded before accountability had caught up.
That is where we believe leaders should begin. Not with the model. Not with a promise of complete autonomy. Begin with the mandate, the owner, the first dependable loop, and the evidence required to trust it. Then let the factory grow at the same speed as the organization’s ability to govern it.
Watch the full 49-minute conversation with Patrick Debois on YouTube, listen via Spotify or RSS, and follow Patrick through his blog or LinkedIn.
If you are investing in, building, or operating a software factory, we would like to hear what ownership looks like in your organization. Contact Dany on LinkedIn if you would like to join a future episode.
