Walk into almost any engineering team today, and the first thing you will notice is the quiet. The mechanical keyboard, that percussive symbol of the craft for half a century, has gone silent on a lot of desks. In its place, on many of them, is a small microphone held close to the mouth, and an engineer speaking softly into it.

The microphone has become the keyboard. That single change is the clearest sign of what a modern software factory looks like, because the work has turned conversational. Meetings between humans get captured as transcripts. Then the engineer sits down with an AI agent, and together they walk through the transcript, talking about what it means and how to implement it. Intent moves by voice now: meeting to transcript, transcript to conversation, conversation to specification, specification to code.

Instead of writing functions character by character, engineers are running multi-agent swarms, dispatching autonomous background coding sessions, and watching entire pull requests materialize in a few minutes: still vastly faster than human hands could type it, but running on a scale of minutes rather than seconds. Platforms with names like Factory, Warp, and Stripe Minions are no longer research experiments; they are churning out production code at industrial scale.

Wispr Flow is one of the companies doing really well out of this shift. It makes one specific translation easy: from spoken human intent into written software specification. Software factory teams took to it quickly. The bottleneck in those teams is no longer typing speed; it is how fast human intent can become something the machinery can build from.

Full disclosure: I’m using Wispr Flow right now to transcribe intent for the research in this article and the prose itself. When I say the work has become conversational, I’m describing my own desk. The interface changed. The questions did not.

The sixty-year-old dream of the software factory, which we traced in Part I through its early failures with Waterfall and Taylorism, has suddenly reappeared in silicon. But beneath the breathless venture capital pitch decks and viral product demos, a fierce battle is underway over what this new factory actually is, who holds the controls, and whether we are about to repeat every mistake our industry spent thirty years trying to fix.

This is the Present in our three-part series. Before Part III explores where these diverging paths could take us in five years, we need to look honestly at what is happening on the ground right now today.

Part I ended with the values our industry wrote down after two decades of expensive lessons. This part is where I hold them up against what is actually being built.

The Spectrum of Autonomous Ambition#

The phrase “AI software factory” is being used to describe several wildly different philosophies of work, mapping across what the industry recognizes as progressive levels of agentic engineering.

At the supervised end of the spectrum (Level 3 agentic workflows), human engineers remain in the active review loop. At Stripe, internal agents called Minions generate more than 1,000 merged pull requests every week. But as Stripe’s engineering team details, every single change runs inside an isolated development sandbox with deterministic linting and continuous integration, and every pull request must be explicitly reviewed and approved by a human engineer before touching production.

In the middle sits the orchestrated workflow model (Level 4 factories). Warp CEO Zach Lloyd recently declared that developers are shifting from product engineers to “factory engineers” who build and tune the machine that produces software. In Warp’s vision, success is measured by the percentage of changes shipped automatically and the dropping unit cost of delivery. Similarly, Factory’s platform connects external product signals into autonomous loops that plan, build, review, and monitor changes with gradual, task-specific autonomy.

And then, on the radical frontier, sit unattended Level 5 “dark factories.” In their published manifesto, StrongDM argues for a complete break with human software craft: a world of non-interactive development where humans write zero code and conduct zero code reviews. Instead, humans write only declarative specifications and behavioral scenarios, while automated validation harnesses execute the build, verify the invariants, and deploy the software without human intervention.

Yet veteran practitioners are pushing back against the entire industrial metaphor. In a thoughtful critique, Rob West argues that treating software development as an assembly line misdiagnoses the fundamental nature of the craft. When an organization treats coding as pure production, it creates intense pressure to convert fluid, evolving human requirements into prematurely rigid tickets, choking off the exploration and variation where true software design happens.

The Great Productivity Illusion#

Why is there such a massive gulf between the vendor demos and the lived experience of developers?

Because measuring software productivity has always been a trap, and AI tools have made the trap far deeper.

In early 2023, a widely cited randomized trial by GitHub and Microsoft tested 95 professional programmers building a basic JavaScript web server. As the study reported, developers using GitHub Copilot completed the task 55.8 percent faster than those working manually. It was an astonishing headline number that launched a thousand corporate AI adoption mandates.

But notice the fine print: it was a greenfield toy problem with an isolated HTTP server and no legacy dependencies.

When researchers put AI tools into real-world codebases, the story flipped upside down. In a rigorous randomized trial conducted by METR, 16 experienced developers were assigned 246 real maintenance and feature tasks across mature open-source repositories they had worked on for years. The result? METR found that developers using modern AI tools took 19 percent longer to complete tasks than those coding by hand, even though the developers themselves felt and believed the tools had made them faster!

When METR attempted a broader follow-up across 57 developers and 143 repositories, they reported that measuring productivity had become remarkably difficult: developers avoided tasks where AI struggled, and concurrent agent workflows completely scrambled traditional time-tracking metrics.

What is happening across entire codebases? A large-scale 2026 study in Mining Software Repositories analyzed 806 public GitHub projects using Cursor rules against 1,380 matched control repositories. The paper revealed a 28.6 percent surge in code volume, a 30.3 percent spike in static analysis warnings, and a 41.6 percent jump in code complexity.

Similarly, an in-depth empirical study across more than 10,000 developers at Meta published in ESEM discovered that while AI completions were associated with slightly fewer production incidents when carefully controlled, developers naturally restricted AI use to low-centrality, routine tasks. And a year-long longitudinal study of 182 open-source repositories published in 2026 showed that while agentic code merged quickly, it required substantially more corrective bug-fixing and carried significantly higher post-merge maintenance burdens.

At first glance, this looks like the classic Jevons Paradox in computer science: make generating code practically free, and you get flooded with an ocean of synthetic syntax that humans must now spend all their time reading, verifying, and maintaining.

But that overwhelming review tax is a symptom of early-stage AI adoption. In the early stages of agentic engineering, teams make the mistake of dropping AI into a single step of a legacy workflow: code generation. When you speed up the drafting step while leaving the rest of the software development lifecycle unchanged, you don’t eliminate the bottleneck. You just shove it hard to the right, piling an exhausting cognitive burden onto human code reviews, manual bug triage, and security sign-offs.

True software factory gains do not happen by accelerating one isolated step in a legacy pipeline. They happen when the entire delivery workflow is reimagined.

In the most advanced software factories running today, downstream tasks (reading code, running deterministic verification harnesses, checking security invariants, and diagnosing regressions) are also taken over by specialized agents within the factory machinery. This flips the classic Jevons Paradox on its ear. Instead of drowning engineers in post-coding verification, the mature software factory moves human judgment almost entirely to the front end of the lifecycle:

  • Defining what needs to be built and why it matters to real users.
  • Establishing architectural boundaries, constraints, and sequencing.
  • Crafting rigorous evaluation descriptions, invariant tests, and acceptance criteria.
  • Maintaining, tuning, and improving the factory machinery itself.

Inside that factory model, agents handle the internal execution, verification, and regression loops, while humans operate as architects, evaluators, and system stewards.

Gonzo ink illustration of a developer inspecting a paper strip under an amber lamp as a machine feeds more strips through a test gate.
When AI only accelerates code generation, the review bottleneck shifts downstream. True factory gains require reimagining the entire delivery loop.

Connecting the Dots: What DORA and DevOps Taught Us#

This is where our history from DevOps and the DORA research becomes our most valuable compass.

For over a decade, the DevOps Research and Assessment (DORA) team demonstrated that elite engineering performance is never about raw typing speed or lines of code. It is about delivery lead time, deployment frequency, change failure rates, and mean time to recovery.

When DORA investigated early AI adoption, they found that AI acts as a powerful organizational amplifier: it amplifies an organization’s existing strengths, but it equally amplifies its structural dysfunctions. High AI adoption increases delivery throughput, but without mature verification, it simultaneously drives up production instability. In surveys of over 1,100 Google engineers, DORA found that time saved drafting code was immediately redirected into the exhausting cognitive work of auditing, proofreading, and verifying agent outputs. Observational industry reports, like Faros’s 2026 study of 22,000 developers, called this “acceleration whiplash.”

While DORA has since stepped back from direct AI tooling research, it is crucial to recognize what those early findings actually were: they were not an immutable ceiling on productivity, but an explicit engineering specification for what next-generation software factories had to build.

Modern Level 4 and Level 5 factory architectures took that exact specification to heart. They realized that asking humans to manually audit thousands of lines of synthetic pull requests was unviable. Instead, they built automated multi-agent verification harnesses, deterministic test runners, mutation test suites, and continuous security scanners directly into the factory infrastructure to absorb that post-coding load.

Yet this brings us right back to the enduring lessons of DevOps. Automating the verification loop does not eliminate the need for sound engineering discipline; it heightens it. The factory’s automated evaluation gates are only as good as the constraints, invariants, and values that humans program into them. If an organization’s underlying culture values raw feature volume over systemic stability, a fully automated dark factory will simply generate unmaintainable architectural chaos at machine speed.

Revisiting Toyota: When the Machine Can Improve Itself#

For over half a century, the foundational axiom of manufacturing and software engineering was that machines cannot improve themselves.

That was the core philosophical premise of the Toyota Production System. In a world of purely deterministic machines (stamping presses, robotic welders, and C compilers), the machine only does exactly what it is wired or programmed to do. It cannot reflect, it cannot notice subtle waste, and it cannot invent a better way to assemble a door frame. Only human workers, actively practicing continuous improvement (kaizen), could discover how to improve the system.

Today, in the world of probabilistic AI agents, that bedrock assumption has quietly broken down.

Unlike deterministic tools, modern agentic loops can reason probabilistically across complex systems. In my own agentic engineering practice, I have repeatedly tasked autonomous agent loops with running iterative experiments to optimize software performance across explicitly defined KPIs. The loop generates hypotheses, writes candidate code, executes benchmark suites, verifies that no other metrics or invariant tests have regressed, and opens verified pull requests for changes that were never conceived or specified line by line by a human engineer.

These are improvements imagined by the machine, tested by the machine, proven by the machine, and accepted by the automated evaluation gates: delivering a measurably better, faster experience for human operators.

This is a profound conceptual inflection point. The machine is no longer merely the passive assembly line; it has become an active participant in kaizen.

Yet this raises an even deeper question. If the factory can not only build the software and verify the software, but also run experiments to improve the software, what is left for the humans inside the organization?

The answer brings us directly to the human experience on the ground.

The Cognitive Shift on the Ground#

What does this mean for the person sitting in the chair?

In a detailed workplace-shadowing study of professional developers, researchers found that engineers spent an average of 33.4 percent of their working hours prompting, steering, and checking AI agents. The study identified three distinct developer personas: Supervisors (directing high-level tasks), Delegators (offloading routine chores), and Learners (using agents as tutors). While developers used agents for technical syntax, they relied heavily on human colleagues for organizational context, architectural authority, and strategic alignment.

Meanwhile, a CHI study on developer agency highlighted growing friction between immediate sprint velocity and long-term career growth. Junior developers in particular face a dangerous trap: when AI tools do the initial problem-solving, juniors miss the formative struggle that builds genuine architectural intuition.

This was demonstrated experimentally in an Anthropic study of 52 junior engineers learning a new Python library. Engineers who relied heavily on AI to write the code scored 50 percent on an immediate comprehension quiz, compared with 67 percent for those who coded manually. Only those who actively used the model for conceptual explanation rather than blind delegation preserved their learning.

Yet workers themselves know which tasks are worth keeping. A 2026 CHIWORK study of 202 workers across 171 workplace tasks found that people eagerly delegate tasks they perceive as meaningless boilerplate, while fiercely wanting to retain control over consequential decisions that require context, empathy, and judgment.

The War of the Manifestos#

As the stakes become clear, the industry is fracturing into competing philosophical camps.

In 2024, thirty-five leading researchers published the Copenhagen Manifesto, demanding that generative AI in software engineering prioritize human agency, dignity, transparency, and lifelong professional growth.

In 2026, an AI-Native Large-Scale Agile framework proposed a hybrid future under the banner “Human intent, machine velocity,” combining intent-driven product teams with orchestrated agent execution and verification-first assurance.

Simultaneously, the Tandem Manifesto staked out a crucial governance boundary: human attention and context are scarce resources, agents must stop and escalate whenever they encounter consequential ambiguity, and human review depth must scale with the risk of the system.

On the other side stands StrongDM’s vision of total automation, betting that human review is fundamentally unscalable and that formal test harnesses should replace human oversight entirely.

Writing a manifesto is what practitioners do when the ground shifts under their feet: they stop, and they write down what they refuse to lose. It happened in Snowbird in 2001, and it is happening again right now.

The Decision at Hand#

We are standing at a historic fork in the road.

The software factory is no longer a theoretical debate about Henry Ford or Winston Royce. It is being built right now in our IDEs, our CI pipelines, and our repositories.

The central question facing every technology leader, engineer, and organization today is not whether agents can generate code. They can. The question is: Who gets to decide what the factory makes? Who holds the authority to stop the line when the system goes off the rails? And who is responsible for the humans living inside the machine?

The values from the past are the test now. When a team wires an autonomous pipeline into its delivery process, the honest question is bigger than whether the pipeline works. It is which values the pipeline protects, and which it quietly overwrites. Did the person closest to the problem keep the authority to stop the line? Is anyone still learning the craft? Does the recovered time come back to the people who saved it? A factory that cannot answer those questions is not a new era. It is the old experiment, running faster.

In Part III, we step into the future to imagine what happens if we get these answers right, and what happens if we get them wrong.