Towards the dark factory: Autonomous, isolated AI agents in software engineering — Jeroen Soeters

◼">

Towards the dark factory: Autonomous, isolated AI agents in software engineering

July 4, 2026 · 10 min read

Late 2025 was an inflection point for AI in software development. Before that I spent most of my time writing code in an editor (vim of course, as God intended). I used AI mostly for auto-complete or generating small patches with the awesome avante plugin. After the release of Opus 4.5 the workflow changed completely: I switched to Claude Code and never looked back.

The human loop

On a high level my workflow looks something like this. I pick up a new task and kick off a brainstorming session with Claude, using the superpowers plugin. Claude writes a design spec, and I validate it across models by having Codex run an adversarial review of the design. I triage the findings and ask Claude to incorporate the ones worth acting on, and if the rework is substantive we rinse and repeat. Only then do I review the full spec myself. Once it holds up, Claude writes the implementation plan, and depending on complexity I either delegate the work to subagents or stay in the current session. Finished code goes through another cross-model review before I look at it myself, and then I either squash-merge the PR or send the agent back to fix what’s left.

This flow works well for substantive features that benefit from an interactive design session. But at a startup with a small team touching many different technologies, which an IaC tool does by definition, a lot of the work is death by a thousand cuts. Many tickets are tiny: change the severity of a log line, fix the JSON parsing of resource X, remove some temporary migration code. The design and implementation of these is trivial, and stepping through it with a coding agent feels mechanical, not something that should need a human.

Over the last few weeks I set aside a portion of my time to tackle this, and the result is what we now call our clanker infrastructure . Clankers are autonomous agents that do exactly the mechanical steps outlined above.

Building the machine that builds the machine

A clanker is built out of the same tools I use every day: Claude Code as the harness, a curated set of skills, various MCP servers, Codex for cross-model reviews. But instead of me orchestrating from the harness, clankers run on their own. They are triggered from our issue tracker and run headless in a container we control.

Every time a clanker does work we call this a turn. Proposing a design is a turn, opening a PR is a turn, answering a question is a turn. After each turn the clanker hands the baton back to a human. The container is disposable and nothing persists between turns; everything durable lives in our issue tracker and on the PR branch.

The control plane

We use Linear as our issue tracker. Linear is also the surface for our autonomous agent infrastructure. One of its features lets you provision app users through an OAuth app: workspace members that are @mentionable and assignable like anyone else, but backed by an app instead of a person. “Clanker” is one of these, and you hand it work exactly the way you’d hand work to a teammate, by assigning a ticket to it. Behind that single name is a fleet: every turn runs in its own fresh clanker, and many can be working in parallel.

This is what our Linear board looks like.

The board: Backlog → Design → Implementation → In Review → Done<br>When a ticket gets picked up from the backlog it first goes to “Design,” where the technical design gets worked out and a tech brief is produced and attached to the Linear issue. Only once that design is approved does the ticket move to “Implementation,” where the actual coding happens. Once the PR is up the ticket lands “In Review,” and once merged it moves to “Done.”

The column dictates what work Clanker will do. Assign Clanker in the “Design” column and it produces the tech brief; any blockers or decisions get escalated to the ticket owner, with Clanker commenting on the ticket and unassigning itself. Assign it in the “Implementation” column and it writes an implementation plan, delegates the coding to subagents, and opens a PR. From there you can also interact with Clanker through the PR, not just in Linear: request changes and it revises, approve and it merges the PR and moves the ticket to “Done.”

Assigning Clanker to a ticket<br>Another cool feature of Linear is agent sessions. Whenever an agent picks up work, it streams its thoughts and actions into a read-only thread on the issue, so you get a window into what’s happening inside the session.

The agent session thread: thoughts and actions streaming as the clanker works<br>The Agent Bridge

Between Linear and the agents lives a small always-on orchestration service we call the Agent Bridge. It is an ECS Fargate service, and it is what turns activity on a ticket into a running agent. When you assign Clanker to a ticket, or...