Agentic Development, Part 3: The Software Dark Factory

In less than two weeks, we built a complete system that would probably have taken a team of five or six developers five or six months.

It included the front end, back end, connectivity, authentication, and MCP integration.

The estimate is rough. Even the low end of it changed how I think about software production.

For the first time, the idea of a software dark factory feels credible to me: specifications enter, working software comes out, and humans no longer handle every implementation step.

The new limit is our ability to decide what the system should do and make those decisions explicit enough for the agents to execute.

The bottleneck moved from code to intent.

The workshop is becoming a factory

A physical dark factory can operate with very little direct human intervention. Nobody needs to stand beside every production step, and the machines do not care whether the lights are on.

Each software run may produce a different feature or application. What repeats is the production system: a specification enters; the system plans the work, builds the software, connects its components, and tests the result.

At lower levels of autonomy, the developer remains beside every step. They ask an assistant to write code, inspect it, correct it, and decide what happens next. The workshop has a faster tool, with the human still setting the pace.

The factory starts when the production system can read an explicit specification, plan the intermediate work, build the application, connect its components, test the behavior, and keep moving toward the objective.

Once that line works, development capacity feels almost absurd. The factory can supply more execution than an organization can productively use.

That exposes the real constraint: deciding, clarifying, and specifying what should be built.

The work before the factory starts

In Part 2, I described the specification as a control surface. In this workflow, it became the input to production.

Human attention moves to the beginning of each production slice. People work with AI around one shared context, writing and challenging the specification until the behavior, architecture, permissions, and approval points are explicit.

I currently use Spec Kit to structure this work. The framework can change. The operating principle is the useful part: humans and AI refine the same versioned specification before the run.

We answer a few questions explicitly:

• What behavior do we expect?
• Which constraints matter?
• Which architectural choices are already settled?
• Which intermediate checkpoints must the system pass?
• Which decisions may the factory make autonomously?
• Which decisions require human approval or an explicit waiver?

Every ambiguity left in the specification becomes a decision delegated to the machine. That delegation can be intentional, but it has to remain visible.

A developer can compensate for a vague ticket with years of company and product context. An autonomous run only sees the context that reaches it. The meeting nobody wrote down does not exist for the factory.

Put developers over the loop

Once the specification is ready, the agents handle the intermediate steps. The human monitors progress toward the objective, the checkpoints, and the failures.

Human interventions increasingly look like operations. An agent may reach a protected resource, lack a permission, or lose a connection. The developer inspects the interruption, decides whether the access is appropriate, and restores the line when it is safe to continue.

I think of the developer as being over the loop. The human remains accountable for the direction, operating conditions, and accepted result without manually controlling every action.

The physical factory analogy becomes very direct. When the line stops, the developer enters to locate the failure, restore the connection, or clear the equivalent of a paper jam.

Developers become responsible for the machine that produces the parts.

Juniors become factory technicians

The traditional career path started with small implementation tasks. Over time, a junior learned to handle larger components, make architectural decisions, lead a team, and eventually become a technical lead or architect.

The factory changes that starting point. The junior becomes closer to the technician responsible for the production line than the worker manually producing every part.

During design, a junior can become a context collector. Their job is to identify the intentions held by the company, product team, technical team, and other stakeholders, then help crystallize them into the specification.

They look for missing constraints, conflicting expectations, undefined behavior, and assumptions that exist only in someone's head.

During production, juniors can monitor the factory, investigate failures, diagnose interruptions, integrate minor specification updates, and propose improvements to the machine.

After production, they can verify that the software behaves as expected, adjust the specification, correct localized behavior, and keep the system coherent.

This may increase the technical knowledge expected from juniors. The worker who produces parts needs to know the operation. The technician responsible for the production line needs to understand the system.

The future junior may write less code manually while needing a stronger understanding of how software, infrastructure, permissions, data, and agents interact.

Seniors may have the harder transition

Many experienced developers built their identity around implementation, deep knowledge of the codebase, and control over difficult technical work.

An agent can change more code than any senior can realistically read. The natural reaction is to recover control through the diff.

Factory work asks for a different kind of attention:

• Planning and systems architecture.
• Detailed specification.
• Anticipating failures and collisions.
• Designing safe boundaries and acceptance gates.
• Delegating to systems when not every local decision can be inspected.

Those are technical responsibilities, although they may be far from the work that made someone love development in the first place.

The control problem becomes unavoidable at machine speed. If a senior insists on reading every line and reconstructing every local decision, their attention sets the maximum throughput of the factory.

Micromanagement is already expensive with human teams. Here it defeats the production model.

Senior value moves toward the system around the code: setting boundaries, detecting risk across the system, deciding which outcomes deserve deeper inspection, and knowing when to stop the line.

The hard skill is operating several loops without losing sight of their objectives.

The factory still needs a finishing line

The first output can be technically functional and still have rough seams.

The output may need a usability adjustment, expose an inconsistency between services, or satisfy the written requirement while missing the intended experience.

Some of this work will become automated. A human pass for integration, quality review, and final adjustment remains valuable while these factories are immature.

Every repair should improve the factory.

We are still learning how to operate the factory

We are early, and this model does not fit every software project today.

The model works best when the objective is clear, the environment is isolated, and success can be tested. The tools still change quickly, and autonomous execution remains uneven.

Legacy systems, safety-critical environments, and highly ambiguous product work need much tighter human control. Different components of the same product may also deserve different levels of autonomy.

The direction is already visible. The specification becomes the main control surface. Agents perform more of the production. Humans define the intent, establish the boundaries, monitor the system, manage exceptions, and improve the line.

More engineering work will move toward the factory itself: the specifications, permissions, scenarios, and recovery mechanisms that let agents keep producing.

The application becomes one output of that system.

That is where I see the developer's job going.

Read Part 1: The Bottleneck Is No Longer Code

Read Part 2: Making the Speed Useful

Cover: Adolph von Menzel's The Iron Rolling Mill (Modern Cyclopes), 1872–1875. Public domain image.