The “Dark Factory” pattern refers to fully autonomous AI software pipelines where AI agents plan, write, test, and deploy code without human review. Anthropic’s Claude Code sits at the center of these workflows, allowing developers to operate headless codebases that require no human intervention. As a front-running example, we have seen a recent Mania around ClawBot where people attempt this without Industrial Planning and Controls. This begs the question: “We can go Dark Factory, but Should we go Dark Factory?”
Derived from the manufacturing concept of fully automated factories that can operate with the lights off, a Dark Factory in software takes autonomous AI coding from an “assisted” stage to total autonomy.
Rather than a human reviewing AI-generated pull requests, the system completes tasks, verifies regressions through testing, and ships straight to production using an orchestration framework. As a seasoned Operator with multiple teams in production, we need more control over the process in order to satisfy our Auditors and our Stake Holders. The question is now at what level is Human Control Sufficient and can we assist that control with tools to make the Dark Factory pattern produce optimally for the Business Objectives.
In the next eighteen months the industry is going to cross a chasm. On the near side: humans writing pull requests, peer reviewers checking code, QA running test suites, sprint ceremonies, two-week cycles, twenty-page PRDs nobody reads. On the far side: humans setting objectives at the top, coding agents doing the implementation in the middle, humans accepting results at the bottom — and a cryptographic audit log running through the whole thing so we have Observability and Audibility.
Both processes work, but the far side is faster by an order of magnitude. But there is a transition cost — operational, cultural, regulatory — and the teams that don’t plan for it will get stuck. The way we plan and describe Software Objectives is crucial and the way we setup our coding repos to maintain context and integrity for the plan needs to get a lot more rigorous.
Here’s the map from here to there.
Most software organizations operate on a refined version of the same playbook we have used for a decade. A product manager pre-digests objectives into user stories. The team plans a sprint. Engineers pick up tickets, write code, open pull requests. Peer reviewers inspect. Tests run. Staging deploys. QA exercises. Release. Repeat every two weeks.
The ceremony has a lot of people in it. It has a lot of latency. It has a lot of meetings. It also has decades of operational learning baked in — peer review catches bugs, separation of duties satisfies auditors, staged rollout protects production. It’s not stupid. It’s just expensive and slow.
In the last eighteen months a new pattern emerged. Engineers got better coding assistants — Copilot, Cursor, Claude Code, the rest. The process of how we build Software didn’t fundamentally change. Sprints still ran. PRs still got opened. Reviewers still inspected, and the individual Engineer seemed to get a little faster.
This is comfortable. It feels like a tool, not a transformation. Most production teams are here right now and most of them think they’ve reached the destination.
They haven’t. This is the on-ramp.
The next step is qualitatively different. At some point in early 2026 coding tools became good enough to take a whole Objective, decompose it into subtasks, plan the dependencies, execute, commit, and open a PR without a human ever looking at the code itself. This is very uncomfortable for Engineers supporting a Production codebase who will get calls at unfortunate hours when code breaks. For a Coder this is a nightmare if you are the one who has to go in and fix broken code you didn’t design and didn’t pay attention to the architecture.
The vibe-code generation YOLO’d their way over this chasm with mixed results. They had nothing to lose. Replit demos, side projects, weekend builds — let the agent rip, see what happens. If it breaks, throw it away.
Production teams are crossing more slowly because we have things the vibe-coders don’t: audit obligations, security obligations, customer trust, regulatory exposure. We can’t let an unconstrained agent commit to main and call it good. We have a CISO. We have a SOC 2 report. We have customers paying us not to surprise them.
So we’re paused staring into the Chasm, watching the Vanguard widen the gap, knowing we have to cross but not sure how.
Close your eyes and imagine the YOLO Gone Wild scenario.
A Junior Engineer cranks up NemoClaw on Friday afternoon before margaritas. They hand the bot a Business Objective: implement SSO for enterprise. The bot happily spawns sub-agents to fan out and attack. It pulls down an awkward dev branch of your repo. Because there’s an env file on the Filesystem it helps itself to your production credentials. One of the child agents decides it needs a new SaaS account so it signs up using your company card. It refactors a module it thinks looks ugly. It deletes a feature it thinks is unused. It opens a PR, but the PR is so large nobody can review it meaningfully, and the test suite passes, so it gets merged. You wake up Tuesday morning to a Stripe alert for $12,000 in API charges, a Slack thread from your largest customer about a missing feature, and a security regression that nobody noticed because the agent disabled the noisy lint check that was flagging it.
Nobody is going to sign off on that. Not your CTO. Not your CISO. Not your auditor. Not your board.
This is the actual blocker. The technology is ready. The governance isn’t.
Best practices for how we manufacture Software in an autonomous factory mode are crystallizing this year. Three principles are emerging across regulatory bodies, audit frameworks, and serious enterprise practice:
Humans bookend the SDLC, always. A human issues every Objective. A human accepts every result. Everything in between can be agent work, but the entry and exit are non-negotiable. No agent issues an Objective to itself. No agent merges its own work to main without a human signoff event.
Every transition gets logged with a cryptographic audit trail. Who issued the Objective. When. Which agent claimed it. What plan was generated. What code got committed to support this Objective. Who accepted the result. When. Signed at each step, immutable. Your SOC 2 auditor is going to start asking for this. Your customers are going to start asking for this. Your insurer is going to start asking for this.
The repository becomes a contract. When agents are doing the implementation, the repo needs to begin with and maintain relevant context for the project. The conventions, the architectural intent, the business context, the economic constraints — all of it has to live in the repo as machine-readable context. A CLAUDE.md or equivalent that any agent picking up a card can reference. If the context isn’t there, the agent makes it up, and you get drift.
These three principles are how production teams cross the chasm without becoming the cautionary tale.
On the dark-factory side of the Chasm, the SDLC looks unrecognizable to a 2024-era Engineer.
The Product Manager’s job collapses upward. They stop translating Engineering details. They start integrating the chaos. A customer sends an email saying what would be cool is X. Someone records a post-lunch idea on their phone. Someone screenshots a competitor and circles a feature. Sales pings Slack with three customer requests.
The PM pulls all of it — every transcript, every screenshot, every Slack thread, plus the brand folder, the product roadmap, the analytics dashboards, the CRM, the Stripe data — into context. (Claude Desktop with MCP servers handles this natively today.) Then the PM tells the model: read this, listen to this, synthesize, give me a list of Objectives with acceptance criteria and relevant context, then drop them on the execution board for scheduling.
The Objective show up as cards. The card has a verbose description, machine-readable acceptance criteria, references to the relevant context files in the repo, and a blank return field where the coding agent will report what it did and what decisions it made. Humans decide when each Objective is ready for implementation and schedule appropriately.
The coding agent claims elegible cards, reads the context and makes a plan to achieve the results. It implements. It commits. It opens a PR. It writes back to the card explaining its decisions and trade-offs. Human Engineers can Observe this behavior and intervene if the decisions are off, but as we gain confidence in the tools, I think we are going to go hands off and the lights in the factory will start to dim.
A human reads the return log. They check that the agent did what was asked, made reasonable trade-offs, didn’t take a shortcut that bites later. They accept the card. The PR merges.
When all the cards in a release set are accepted, a human approves the Release and the CI/CD pipeline runs smoke/integration/regression/security checks every time before deploying and verifying the results.
The Engineer’s job shifts at the same time. Curly braces are not interesting anymore. Library version debates are not interesting anymore. What’s interesting: when did we last run a security scan? Is our token spend on the agent budget tracking? Are the agents making consistent architectural choices? Where do we need to add new context files to the repo because the agents keep getting something wrong? What’s the cost model telling us about which features are economically worth building?
The Engineer becomes the supervisor of a flock of coding agents. The strategic work that used to take a decade to develop the intuition for — economic thinking, security thinking, operational thinking — is now required of even first year Engineers, because there is no longer a tactical pile to bury yourself in.
Here’s the problem nobody talks about. None of the existing SDLC tools are built for this. I want my Product Owner living in Claude Desktop with a nerve center of MCP connections to All The Things. Every time someone sends in feedback we can set off research against the code base, the business plans and the market to generate Self-consistent, efficiently specified Objectives.
Jira was built for human ceremonies. Linear is faster but still assumes a human author on every issue. GitHub PRs assume the code was written by an authenticated user. Notion is a doc store. Asana is a task tracker. They all work fine on the near side of the chasm. None of them enforce the human-bookend pattern. None of them log a cryptographic chain of custody. None of them treat a coding agent as a first-class actor with claim-and-return semantics.
If you try to cross the chasm with the existing tools, you have two options. Option A: extend the existing tools with custom integration glue, hope your auditor accepts your homemade audit trail, hope your engineers don’t drift into shortcuts. Option B: don’t cross. Keep the turbocharger model. Watch the frontier move away from you in the windscreen.
Neither option is good. Option A is fragile and expensive. Option B is competitive suicide on an eighteen-month horizon.
We needed a different kind of tool.
We built one. It’s called PlanWright.
PlanWright is a Kanban board built around the human-bookend pattern. Product managers — or anyone with strategic input — synthesize chaos into Objectives, either by hand or even better, by talking to Claude Desktop with the PlanWright MCP server connected, and drop the resulting cards on the board. Coding agents (Claude Code, Cursor, whatever you use) claim cards from the scheduled column, plan, execute, open PRs against your GitHub repo, and return a structured log to the card.
Every transition is cryptographically signed and time-stamped. Who issued. Who claimed. What plan. What commit. Who accepted. When released. The audit trail is built in, not bolted on. Your SOC 2 reviewer can see exactly what happened on every card from inception to production.
It’s MCP-native. The PM uses Claude Desktop and the PlanWright MCP server to push objectives. The coding agent uses MCP to claim cards and return logs. The repo’s CLAUDE.md and context files get referenced by every card so implementation stays consistent. The whole loop runs end-to-end with humans only at the strategic and acceptance bookends.
It’s a tool you can use on the near side of the chasm right now — running it alongside your existing sprints — and keep using as you move to the far side. The pattern doesn’t change. The volume changes. Today maybe one in ten cards goes to an agent. In six months maybe half. In eighteen months maybe nine in ten. The tool stays the same. The audit log stays consistent.
PlanWright is the bridge to get you to a well Supervised Dark Factory with Industrial guard rails and Observability.
Three things, whether or not you use PlanWright.
Pick one project to dark-factory. Not your most critical system. Something with real stakes but not existential. Run the full pattern on it: PM-synthesized objectives, agent-executed implementation, human-bookended acceptance, full audit log. Learn what breaks. Learn what works.
Seed your repos for the transition. Start writing CLAUDE.md and architectural-intent docs into every repo. Make the context machine-readable. Even if you don’t deploy agents this quarter, the repos that have proper context will cross the chasm in a weekend. The ones that don’t will take six months.
Read the emerging standards. The audit and governance frameworks for AI-assisted SDLC are forming in real time. Read them. The teams that are aware of where the lines are getting drawn will be ready. The teams that aren’t will be retrofitting under deadline.
Eighteen months from now, the leading teams will be running lights-out development with full audit defensibility. They will ship at a cadence that looks impossible from where we sit today. Their Engineers will be doing higher-level work than their peers anywhere else. Their PMs will be operating as conductors instead of translators.
The teams that didn’t plan for the transition will still be writing twenty-page PRDs and wondering why their competitors are eating their lunch.
Pick the side you want to be on, but when you’re ready, join us on the other side with the bridge we just left for you.
Todd Merrill is the founder of Silverback Ventures and the operator behind the Velocity Process methodology for taking validated ideas to production in ten days. PlanWright is a Silverback Ventures product — reach out for early access at https://planwright.tools.
No posts

Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.