Engineering + DevOps + AI
= AI-native SDLC.
For a week I operated a software factory. Agents run the full ticket cycle: plan, build, verify, code review. A deterministic harness enforces contracts, budgets and gates. A human makes two decisions per ticket: approving the plan and merging. This is the model Gartner calls a dark factory. Built and tested in practice here: the architecture, the real costs and what broke.
I built a working software factory: agents plan, build, test and run code review, while a human makes exactly two decisions — approve the plan and merge the PR. Over one week I pushed 50 tickets through it. This is the record of that experiment: the architecture, the numbers and what broke. I may be wrong in plenty of places — but I have the data.
Vibecoding and CLI harnesses are great. Six problems remain.
Claude Code, Codex and similar CLI harnesses are a genuine productivity leap; code really does get written faster. But “agent + prompt” works beautifully right up to the first serious incident. Below are six problems I know from practice, and the mechanism the factory answers each of them with.
No synergy between models
One model plans, writes and grades its own work. The strengths of every other model go unused, and the judge is a party to the case.
Non-deterministic control
Whether a change is fine is decided by… the AI — on a vibe, not a contract. The verdict can differ on every run.
Unpredictable costs, no hard gates
A session can eat any budget, and no quality gate stops work that is heading the wrong way.
Slop code lands in the repo
Because nobody has the time (or the appetite) to read and reject generated PRs. Quality runs on trust.
Wiring in external sources is painful
Task queue, project registries, CI, tracking — you can wire them into an agent session, but every seam is manual.
No room for local models
Compliance and costs say “on-prem”, but a typical agent session is welded to a single cloud CLI.
AI tools are everywhere. The business impact is nowhere.
I know this from both sides. Developers report writing faster with a copilot and that is genuinely how it feels. Leaders looking at speed-to-market see no difference. Gartner measured that divergence, and the result is one of the starker numbers I have seen in productivity research:
Because a copilot speeds up fragments of the work, but the process and the structure stay the same. Queue, handoffs, review, release: everything still waits on a human exactly where it waited before. Writing time shrinks; waiting time does not.
The key distinction this whole write-up rests on looks like this:
Every step still belongs to a human. AI shortens the steps themselves but never touches the waiting between them. That is why the leader sees no effect.
The human decides at the entrance and at the exit. In between, agents and a deterministic harness do the work. The structure of the process changes, so the change shows up in the results rather than only in how the team feels.
An autonomous SDLC execution unit: agents plan, build, test and package work under harness control. At the entrance sits the intake gate — an agent checks whether a request is fit for production and sends unclear inputs back to a human. At the exit, the inspection gate — a human reviews the output together with its evidence trail. Nobody walks the factory floor in between. Gartner sees four types of such factories: research, plan, implement and verify.
C.A. Swan, “Dark Factories, Run by AI Agents, Will Power the Zero-Friction SDLC”, Gartner, 26 May 2026 (G00855838). A dark factory is the operating unit of the target state Gartner calls the zero-friction SDLC.The shared control layer around the agents. It gives them the right context, limits their tool access, records every action and checks outputs against organisational standards. At Gartner it is built and governed by a central platform team so every factory runs on the same controls. Here it is deterministic code: verdict contracts, gates, budgets, routing and artefacts. This word comes back throughout the text.
My research question was simple:
How much of this model can be built today, on consumer CLI subscriptions — and where are the real limits?
How work flows through the factory.
Linear is both the queue and the control panel. A ticket enters the factory, an agent plans, a human approves the plan by dragging a card — and from that moment until the PR is ready, nobody sits at a keyboard.
This graph really runs — on the Mastra framework.
The factory is built on Mastra — an open TypeScript framework for agents and workflows. There are other options in this class; Mastra simply fit: workflows as a graph of deterministic steps, a human gate wired directly into the graph, and the run panel you can see in the screenshots.
Intake is deterministic code, and approve-plan is a human gate inside the graph — not a convention an agent can overlook; a plan without an unambiguous verdict ends as a hard BLOCKED.
Screenshot from the implementation · Mastra
The foundation of autonomy: a deep distrust of agents.
Deterministic code does git, CI, routing and budgets. Agents only think.
The factory commits, not the agent. An agent never touches git, never triggers CI, never manages branches. Everything that can be done in code is done in code — because code is predictable and an agent is not.
Fail-closed everywhere.
An agent’s verdict is a strict structural contract (a JSON block). A missing verdict or an ambiguous one means STOP, never guess. A review without an unambiguous LGTM means: there are comments.
Two human gates, zero auto-merge.
Control through kanban states, not a chat with a bot. Plan approval and merge — both decisions can be made from a phone: drag the card, /approve, /reject.
Isolation and scope.
A worktree per ticket. The builder’s changes must be a subset of the files declared in the approved plan. File reservations across tickets, a merge queue, and re-verify on every move of main.
Multi-engine with role routing.
Plan, verify, review and build can each run on a different model — routing per role, domain and project. Cheaper models wherever they suffice; zero dependence on a single vendor.
Economics built in from day one.
A per-ticket budget, a $/h circuit breaker, plan-reuse (“we do not generate a plan without a reason”) and full metrics per call: cost, time, first-pass — per stage and per model.
That last row matters more than the rest. In Gartner’s model an agent owns the intake gate and the only human gate sits at the exit. I keep an extra gate at the entrance because with a one-person team and 2026-era models I would rather pay a minute of attention for a plan than an hour for the cleanup. It is a deliberate step back from the target model, not an implementation of it.
The model that wrote the code never grades its own work.
Every role in the factory can run a different model — and that is a direct source of quality. The planner thinks broadly, the builder writes, the verifier and reviewer look at the result with fresh, foreign eyes — the same principle behind having a colleague review your code rather than yourself. The second decision: every engine is the vendor’s native CLI harness (Claude Code from Anthropic, Codex from OpenAI), not a bare API — the agentic loop, the tools and the repo handling are years of engineering tuned to a specific model, and I am not going to rebuild that myself. My harness orchestrates harnesses: contracts, gates and budgets on top, the vendor’s whole agentic engineering underneath.
On an ambiguous ticket the factory asks the author.
The cheapest moment to catch a mistake is before the first line is written. When the planner finds a ticket ambiguous, it asks the author numbered questions with options and a recommendation — instead of quietly picking the “most likely” interpretation. The answer comes back into the very same run. That is the intake gate in practice.
Question 1/1 · The ticket says “add data export”. It specifies neither the format nor the scope:
The control panel is an ordinary kanban.
The board states in Linear are the factory states. Dragging a card is a command: from “Plan awaiting approval” to “Build” means /approve. The entire control surface — gates included — fits in a phone.
I went with Linear, but it could just as well be whatever tool the team already manages tickets in. The principle matters more than the brand: zero new frontend for the business. The factory plugs into where the business already works — and surfaces gates, planner questions and run statuses right there. The ticket, the plan approval and the merge live in the same place as the rest of the team’s work.
Every run leaves a complete set of artefacts.
Plan, approval, builder log, verification verdict, review rounds, screenshots and metrics — per ticket, per run. When something goes wrong there is no “no idea what the agent did”. There is a folder.
Real structure · file names from the repo
What the factory delivered — in numbers.
Every dollar figure is the inference cost equivalent reported by the CLI on consumer subscriptions — not the project cost. I publish them because without specifics you cannot discuss the economics of this model.
- Inference cost equivalent ($ equiv.)
- What the same calls would cost at the model’s API list price. The factory runs on flat CLI subscriptions, so this is a consumption measure — it lets you model the economics before moving to API pricing and scale.
- Engine call
- One run of an agent in one role (plan, build, verify or review) for one ticket. A ticket usually consumes several calls once fix rounds are counted.
- Call success rate (e.g. plan 94/95)
- How many calls of a given role ended with a correct, contract-compliant result — no error, timeout or restart. The equivalent of a “first-pass” metric.
- Cost per ticket
- The summed cost equivalent of every call for one ticket — from the plan to the last review round, fixes included.
This section matters more than the wins.
None of this worked straight away. Below are real failures from the week of operations — each with the concrete mechanism built in response.
Semantic conflicts at 4+ parallel tickets
Two tickets green apart, red together: the changes did not collide in the files, they collided in the logic.
An oscillating review→fix loop
The reviewer demanded a change, the fix made it, the next round demanded the opposite. Round and round.
Zombie runs and hanging processes
A run lost its engine, the process hung for hours, the worktree stayed occupied.
Time budgets were killing slower models
A 5-minute limit on planning killed a frontier-class model mid-thought.
Most of this work is reliability engineering.
Prompts are a rounding error. The substance lives in the contracts, timeouts, queues, budgets and artefacts around the agents. And that is exactly what you cannot buy in a box — it is the difference between adopting a tool and owning a process.
- I am not saying “enterprise-ready”. This is a one-person experiment across two repos: a pilot PWA (50 tickets) and my own product (2 PRs). I only claim that the patterns — gates, contracts, fail-closed — are portable and the operational experience is real.
- The $ figures are the API equivalent reported by the CLI on consumer subscriptions, not the project cost.
- I am not claiming “no humans”. The human sits in two well-defined places, and that is the point.
What I would carry over into a large organisation.
Autonomous agents at enterprise scale: throughput up 20–30%, lead time down 15%, 70% of vulnerabilities remediated autonomously, test coverage doubled to 90%.
A small, blended team plus a spec-driven harness: the path from concept to working software went from weeks to days.
Start with one repeatable stream of work, not with a “transformation”.
A factory is repeatable work under the control of a harness, not a team structure or an application portfolio. One stream, measurable from the first ticket, tells you more than a year-long change programme.
The harness is a central product, built by one platform team.
Contracts, budgets, routing and artefacts built once, not N copies inside product teams. Gartner puts it more sharply: the harness is where governance lives, so duplicating it across teams duplicates the risk.
The competency profile shifts: spec-and-inspect.
Writing precise inputs and critically auditing outputs, closer to a security review than a code review. 51% of CIOs say skills evolution is outpacing what the talent market supplies, so this profile has to be grown in-house.
Measure from day one: cost, time, first-pass, per stage.
Without them you cannot tell adoption theatre from an advantage. These are exactly the numbers a copilot rollout never leaves behind, and the ones an enterprise needs to decide.
How could a model like this work in your organisation?
Waiting for decisions, manual QA and review disappear from the middle of the process. The human stays where they are indispensable: at the decisions. Every run leaves a full set of artefacts, so control does not cost you pace.
More output from the same models: frontier plans, fast codes, another one reviews. Two heads beat one — and every role runs at a rate that matches the task.
Role routing allows self-hosted models: lower inference costs and data that stays inside the organisation — the natural path for compliance.
A central control system lets you codify your unique software development process — and evolve it like a product, instead of inheriting someone else’s workflow from a tool.
If the copilot budget is spent and the business impact is nowhere to be seen — look in the process. That is exactly the problem I spent the last week working through first-hand.
The AI SDLC Readiness Sprint is 2–3 weeks of working together: you walk away with a readiness assessment, a harness architecture for your stack and a pilot plan for one stream of work.
- SDLC mapping and picking the stream of work for the pilot — repeatable and measurable.
- Harness and gate design for your stack: contracts, fail-closed, budgets, artefacts.
- Metric definition — cost, time, first-pass per stage, from day one.
- Pilot plan — or running the pilot with your team as stage 2.
Sources: the terms “dark factory”, “intake/inspection gate”, “harness”, “spec-and-inspect” and the Itaú Unibanco and Revvity cases come from C.A. Swan, “Dark Factories, Run by AI Agents, Will Power the Zero-Friction SDLC” (Gartner, 26 May 2026, G00855838). The Act I statistics: 2026 Gartner Software Engineering Survey (n=482), Gartner Developer Experience Assessment Survey (n=6538) and 2025 Gartner AI in Software Engineering Survey (n=299), via notes G00844726 and G00843105. All of it paraphrased rather than quoted. Gartner does not endorse or sponsor this experiment, and those surveys reflect their respondents rather than the market as a whole. The architecture, the code, the numbers from my own pipeline and the mistakes are mine.