Why the Software Development Lifecycle Is Now an MLOps Problem

The conventional MLOps conversation has always centred on the same set of concerns: model versioning, feature stores, serving infrastructure, and drift detection. Those problems are real and unsolved in many organisations. But a more structural disruption is underway, and it is happening at the process level rather than the infrastructure level. As coding agents become capable enough to own meaningful portions of the development loop, the assumptions that underpin how software is specified, reviewed, and governed are breaking down faster than most engineering organisations have acknowledged.

The Dev Loop Is Compressing, and That Changes Everything

The traditional inner-outer development loop gave engineers a natural set of checkpoints. A developer wrote code, ran local tests, pushed to a branch, waited for CI, and received feedback before anything reached production. Each stage created friction, and that friction was doing governance work that nobody formally credited it with.

Coding agents compress that loop significantly. An agent can generate, test, and propose a pull request in minutes. The friction that previously forced deliberation is reduced, which means the governance work it was doing needs to be made explicit and moved elsewhere.

This is not a tooling problem in the narrow sense. It is a process architecture problem, and resolving it requires the same kind of systematic thinking that MLOps applied to the model lifecycle.

Specification Is Now a First-Class Engineering Artefact

When a human developer misunderstands a requirement, the feedback loop is conversational and fast. When a coding agent misunderstands a requirement, it can produce syntactically correct, test-passing code that is wrong in ways that only surface at integration or in production. The failure mode is silent and structurally plausible.

This changes the economics of specification work. Organisations that treat requirements as informal inputs to a development process will find that agent-assisted workflows amplify ambiguity rather than absorb it. The specification becomes the primary control surface for what the agent builds.

This is the point at which MLOps thinking becomes directly applicable. In model development, the training objective and evaluation criteria are treated as engineering artefacts with versioning, ownership, and review gates. Software specification needs to be treated with the same discipline when agents are doing the building.

Code Review Moves to the Critical Path

In a conventional team, code review is important but rarely the binding constraint on delivery velocity. With coding agents generating high volumes of plausible code quickly, review becomes the bottleneck and the primary quality gate simultaneously.

The implication is structural. Review processes designed for human-paced contribution rates will not hold under agent-assisted throughput. Engineering leaders who have not redesigned their review workflows for this volume are already accumulating a governance deficit, even if their delivery metrics look healthy.

Companion piece to our broader work on agent-assisted code quality. See Agentic Code Review in Production: Research Guide for research-backed analysis of where multi-agent review pipelines succeed and where they fail.

Agentic code review offers a partial solution, but it introduces its own governance questions. A multi-agent review pipeline is itself an AI system, which means it needs evaluation criteria, failure mode analysis, and operational monitoring. The MLOps discipline of treating AI components as systems that require ongoing measurement applies directly here.

Testing Assumptions Are Built for a Different Author

Most test strategies in production engineering teams are built around the assumption that a human wrote the code and that the test suite catches what humans typically miss. Coding agents have different failure distributions. They tend to produce code that passes unit tests but violates architectural constraints or introduces subtle semantic errors that integration tests were not designed to surface.

This means test coverage metrics that looked adequate for human-authored code can be misleading in agent-assisted pipelines. The coverage number stays the same, but the risk profile of what is not covered shifts in ways that are not visible in the dashboard.

Addressing this requires rethinking what the test suite is actually measuring. Teams need to add evaluation layers that are sensitive to the specific failure modes of generated code: constraint adherence, interface consistency, and behavioural correctness at the system boundary rather than the function level.

Governance Needs to Operate at the Process Level, Not Just the Model Level

The MLOps discipline emerged because organisations discovered that deploying a model without operational infrastructure led to predictable failures: drift, degraded performance, and no visibility into root cause. The same lesson is now arriving for agent-assisted development, but the unit of governance is the development process rather than the model.

Engineering organisations need audit trails for agent-generated changes, ownership models for specification artefacts, and escalation paths for cases where agent output conflicts with architectural intent. These are not new categories of concern, but they require new institutional infrastructure to address.

The organisations that will manage this transition well are those that treat it as a systems engineering problem rather than a tooling procurement decision. The question is not which coding agent to deploy. The question is what process architecture makes agent-assisted development auditable, correctable, and aligned with engineering standards over time.