What Everyone Gets Wrong About AI Coding Agents and the "Dark Factory"

In mechanical engineering, engineers use computer-aided design (CAD) tools that include a capability called parametric design.

With parametric design, engineers define constraints, parameters and relationships. From those, a digital representation of a part — or even an assembly of parts — can be generated to satisfy them.

Change a parameter or constraint and the CAD system modifies the digital model accordingly.

That’s parametric design.

That digital design can then be translated into the instructions required by computer-aided manufacturing (CAM) systems to make the parts and, ultimately, assemble the product.

Parametric design changed the role of the mechanical engineer in a way that I think has a striking parallel with how AI coding agents are changing the role of the software engineer. However, before we can talk about that, we first have to recognise this distinction:

Engineering creates the design. Manufacturing realises it.

This distinction is really no different for software engineering.

We have a tendency to talk about software development as though writing code is the act of constructing the product. We “build” products. We “build” features. Developers “build” software. But that’s not really what we’re doing.

It isn’t even consistent with the definition of the word “development”:

“the process in which someone or something grows or changes and becomes more advanced” — Cambridge English Dictionary

In mechanical engineering, the engineer doesn’t manufacture the product. They turn needs, intent and constraints into a representation of something that can be realised through manufacture.

Software engineering isn’t fundamentally different. We turn needs, intent and constraints into a representation of a system that can be realised.

That representation is code.

Source code describes the structure, behaviour, relationships and rules of the system. It is a digital encoding of the engineering design.

The fact that this distinction feels strange in software is understandable. Our tools have progressively collapsed the apparent distance between engineering and production.

An IDE lets us change some code and, seconds later, compile it, execute it and run tests against it. The feedback loop is so short — and everything that happens between code and execution so automated — that it feels like one continuous act.

We say “build” and sometimes mean writing code.

We say “build” and sometimes mean compiling and testing it.

Perhaps we use the former because our tooling has made the latter almost invisible.

And perhaps there’s something deeper going on too.

Software engineering has borrowed heavily from the language of manufacturing: builds, pipelines, production, deployment, lean, waste, flow, throughput. Those metaphors have been enormously useful. But use a metaphor for long enough and it starts to shape how you think about the thing itself.

Many have described software engineering as if it were manufacturing for some time. Somewhere along the way, perhaps that language conditioned us to think it actually was.

If we stop and think about it, even running software locally doesn’t necessarily mean we’ve manufactured the operational product. The closer mechanical-engineering analogy may be simulation. CAD software can run simulations to see how a product responds to stresses, loads, and more. It’s not the real product. It’s virtual.

The software running on a developer’s machine may be surrounded by mocks, fakes, stubs, test data and simulated external dependencies. We’re exercising the design to determine whether it behaves as intended before allowing that design to progress through the production system and interact with “the real world”.

For us, the extraordinary speed and fidelity of that feedback loop can make design and production feel like the same activity.

They aren’t.

The code isn’t the product. It’s the digital encoding of the engineering design.

And once you recognise that distinction, something else becomes apparent.

A dark factory in the physical world is so fully automated that there is no need for lighting. Its machines and robots don’t need light in the way human workers do, and can manufacture products on a production line with little or no human supervision.

There’s a lot of talk right now about AI enabling “dark factories” for software engineering: autonomous systems in which agents write software with progressively less human involvement. No inspection of the code; just specification in, working product out the other side.

But this is, again, conflating engineering with manufacturing. It puts AI coding agents on the wrong side of the factory door. Once you recognise that source code isn’t the working product, the analogy starts to look very different.

Source code is the digital encoding of the engineering design that defines how the product should work.

So where is the process that takes that design and turns it into the working product? We’ve had that for decades...

It’s our build — or CI/CD — pipeline.

A build pipeline takes our engineering design — the code — and compiles its various moving parts, assembles and integrates them, runs the resulting artefacts through automated tests and quality checks, packages them and, increasingly, deploys them.

Nobody needs to stand there watching this happen or, in a mature development environment, even initiate it.

A change in our code enters at one end and a tested, packaged, deployable — or even deployed — product emerges at the other.

That’s a lights-off production line.

That’s our dark factory.

If CI/CD is the manufacturing process, AI coding agents aren’t automating the factory. They’re changing the engineering process that feeds it. And this is where I think parametric design becomes a much more useful analogy.

When working with a coding agent, we increasingly describe what we need in terms of intent, constraints, behaviours, architectural rules and quality bars. The agent generates the code.

Like mechanical engineers using parametric design, we increasingly define the conditions within which a satisfactory encoding of the design can be generated.

There is, however, an important difference.

Parametric CAD is deterministic. Given the same model, parameters and constraints, it will produce the same design.

AI coding agents are not.

Give an agent the same intent and constraints twice and it may produce two different implementations. The code can be different even though the intended behaviour — the outcome we care about — is the same (hopefully).

So I’m not suggesting that AI coding agents are parametric CAD for software in any literal technical sense.

The comparison isn’t about how the technologies work. It’s about what they change.

Parametric design shifted mechanical engineers away from manually drawing every detail and towards defining the parameters, relationships and constraints from which a valid design could be generated.

AI coding agents are beginning to create a similar shift in software: away from manually encoding every implementation detail and towards defining the intent, constraints and quality criteria within which an acceptable implementation can be generated and validated.

• One produces a deterministic design from a defined model.

• The other can produce many candidate implementations intended to satisfy the same outcome.

But both move the engineer’s attention away from manually creating every detail of the representation and towards defining what that representation must achieve.

AI coding agents aren’t the software factory. They’re our parametric-design moment in software engineering.

Perhaps the most interesting consequence of AI coding agents is that they may force us to become clearer about where the engineering actually happens.

As agents take on more of the work of expressing a design as code, the engineer’s attention shifts.

Less effort goes into manually encoding every implementation detail. More goes into understanding the need, specifying intended outcomes with examples, establishing constraints, defining interfaces and invariants, making architectural decisions, determining how outcomes will be validated, and judging whether the resulting system actually satisfies the need.

In other words, the decline of hand-crafted code as the dominant activity doesn’t mean the disappearance of software engineering.

It changes the level at which the engineering happens.

Mechanical engineers have already experienced their own version of that shift. Parametric CAD didn’t make mechanical engineering more like manufacturing. It allowed engineers to spend less time manually producing the representation of a design and more time engineering it.

AI coding agents may do something similar for software — through a fundamentally different, non-deterministic technology. And perhaps that’s the irony in all this.

The rise of AI coding agents doesn’t make software engineering more like manufacturing. It may finally make the distinction between the two impossible to ignore.

It might even put the meaning of “engineering” back into “software engineering”.

The AI-augmented revolution isn’t the arrival of autonomous “software factories”.

That is the wrong metaphor.

The dark factory was already there — our CI/CD pipeline.

Instead, AI-augmented coding is our parametric-design moment for software engineering.

It’s not changing the fundamentals of engineering. It’s just changing the how the software engineer arrives at a design-encoding, ready for where the real factory work happens — in the build and deploy pipeline.

Share