The metaphor you use for agentic software development decides where you think humans belong.
We started with a factory with the lights out. We ended up with a garden.
The term comes from manufacturing. When robots do all the work, nobody on the floor needs to see, so you can turn the lights out. Production runs around the clock, unattended.
Applied to software, it's a compelling picture: issues go in, agents plan, implement, review and merge, and working software comes out. We started our own agentic dark factory at Camunda in July 2025, and it is still growing.
The dark factory isn't a bad metaphor. It's an aspirational one, and it got a lot of people to take agentic development seriously. But it says three different things at once.
Show engineers a dark factory and some of them cheer. If your favourite Star Wars character is Darth Vader, it looks awesome.
Most people have a different reaction, even if they never say it: this looks hostile to me. Where do I fit into this? A metaphor that makes most of your engineers feel surplus to requirements is a bad way to bring them along.
The metaphor answers “what do the machines do?” It doesn't answer “what do I do?”
Proportions are a rhetorical rule of thumb, not survey data.
Factory thinking says that once the line is built, more robots means more output. In software, each change lands in the same codebase the next change has to live in.
Pour agents into an unstructured codebase and you don't get more product. You get an overgrown jungle that slows every agent down. Dark factories started at the same time as ours have stalled for exactly this reason.
| Factory | Software | |
|---|---|---|
| Product | Identical units of a fixed design | Every change is new |
| Output | Ships and is gone | Accumulates in the codebase |
| More workers | More throughput | More growth, and more entropy |
| Decay | Machines wear out | The product wears out the structure |
| Humans | Removed from the floor | Needed, but in a different role |
You don't assemble a tomato by hand. You prepare the soil, plant, water, and it grows. In the agentic SDLC, code is the same: agents grow it.
What gardeners do is build and maintain structure: beds, trellises, irrigation, paths. That's the human job in an agentic codebase too: architecture, boundaries, conventions, CI quality gates, type systems.
And it's collaborative, not lights-out. Gardeners are in the garden. They can see.
| In the garden | In the codebase | |
|---|---|---|
| 🌱 Plants | Code, grown by agents | |
| 🪴 Soil | Context: docs, conventions, examples | |
| 🪜 Trellises | Architecture and module boundaries | |
| 📦 Planter boxes | Modules that keep growth separate | |
| 💧 Irrigation | CI, quality gates, feedback loops | |
| ✂️ Pruning | Refactoring, removing half-finished work | |
| 🧑🌾 Gardener | Human: taste, judgement, structure | |
A trellis holds up a young vine. As the vine grows and fruits, the weight bends the trellis. Roots push through greenhouse walls. Nothing went wrong: growth itself wears down the structure.
Agents are local optimisers. Each change is reasonable on its own, and together they erode cohesion: duplicated logic, half-finished refactors, boundaries crossed one convenient import at a time.
The features are free. Sustained feature velocity is not. It comes from humans watching where the structure bends and fixing it.
The garden has a natural answer to “where do I fit?” Humans don't compete with the agents on growing code. They do the work growth can't do for itself.
That work needs engineering experience more than ever: it's taste and judgement about structure, applied at a speed no human could write code at.
Aim for autonomy and agentic speed. But treat the codebase as a living garden that agents grow and humans structure, because growth always brings entropy. Too careless and the weeds win; too careful and the competition does. Balancing the two is the engineering part, and the rest of these chapters are the gardener's tools.