Manoj Mishra, Chief Technology Officer, Deloitte Human Capital.

getty
A development team ships a working feature in a day. The demo lands well. The product owner signs off. Six months later, three engineers spend two weeks untangling it. The velocity was real. So was the cost. This is the central paradox of agentic development. It doesn’t eliminate technical debt; it industrializes it.
We’ve spent the last two years celebrating how fast AI coding tools let teams move. The right question—the one most engineering leaders aren’t asking yet—is what we’re leaving behind at that speed.
Agentic Development Changes The Debt Equation
Traditional technical debt accumulated at human speed. One skipped code review. One architectural shortcut taken under deadline pressure. One naming convention quietly ignored. It was slow, traceable and—in most cases—something a senior engineer could walk back through and explain.
Agentic tools break that ceiling entirely. Code now accumulates across multiple agents, running in parallel, with no shared memory of decisions made five minutes ago in a different context window. Each agent is locally coherent. The codebase, collectively, is not. What you get isn’t bad code in the traditional sense—it compiles, it runs, it passes the test suite. What you get is a system that works in five different ways simultaneously, none of which were designed to coexist.
This is a fundamentally different category of problem. Debt at machine speed doesn’t just accumulate faster. It compounds differently. Inconsistencies multiply through the codebase before any human has a chance to observe them. By the time a pattern is recognized as problematic, it’s already been replicated a hundred times.
Why Traditional Governance Collapses Here
The governance mechanisms most engineering organizations rely on were designed for human-paced output. Code reviews assume a reviewer can keep up. Architecture standards assume developers read them. Documentation assumes someone wrote it before the feature shipped. Peer collaboration assumes people are working in close enough proximity to notice when something drifts.
In an agentic environment, every one of these assumptions breaks. The review queue becomes a bottleneck within days. Architectural standards, however well-intentioned, are not machine-readable in the way they’d need to be to constrain a model generating code at scale. Documentation doesn’t exist yet for patterns that were invented this morning by an agent that no longer has context from yesterday.
The instinct is to throw more process at the problem. More reviews. Stricter checklists. Bigger architecture guilds. That instinct is wrong. You cannot manually govern what machines produce at machine speed. The old playbook doesn’t just underperform here—it actively creates a false sense of control while debt continues to accumulate underneath it.
Architecture As A Living, Queryable Artifact
The first thing that needs to change is how organizations record architectural knowledge. Most enterprises store decisions as outcomes in a diagram in Confluence, a pattern in a style guide or a convention in a README last updated in 2022. Agents can’t use any of that effectively because outcomes without rationale are instructions without context.
What’s needed instead is architecture as a living, queryable knowledge graph. Decisions recorded with their reasoning, their constraints, their tradeoffs and their expiry conditions. A system where an agent generating a new service can interrogate: Why does the authentication layer work this way? What were the alternatives considered? What breaks if this pattern isn’t followed? When was this decision last reviewed?
This is not a documentation problem. It’s an architectural epistemology problem. The knowledge exists inside the heads of senior engineers and in the archaeology of pull requests. The work is externalizing it in a form that machines can consume at generation time—not as static context fed into a prompt, but as a queryable system that constrains and informs what agents build.
Pipelines As Continuous Conformance Engines
The second shift needs to happen inside CI/CD pipelines. Today, they build, test and deploy. In an agentic development environment, that’s insufficient. Pipelines need to evolve into continuous conformance layers—systems that evaluate the intent and coherence of generated output, not just its functional correctness.
Concretely, this means LLM-as-linter: models that evaluate generated code against architectural fitness functions, not just syntax rules. Policy-as-code that checks whether a new service introduces inconsistency with established patterns. Automated detection of drift—not just bugs, but structural divergence from the system’s intended design. Debt gets caught at the seam, before it propagates.
This reframes what a pipeline is for. It’s no longer just a quality gate—it’s the primary governance mechanism for an environment where human review can’t scale. The pipeline becomes the institutional memory that enforces what no individual reviewer can hold in their head across ten parallel agents working simultaneously.
The Intent Layer: A New Engineering Discipline
Underneath both of these shifts is a more fundamental transformation. For decades, engineering governance lived implicitly inside senior engineers. Their judgment—expressed through code review comments, architecture sessions, hallway conversations—was the system that kept codebases coherent. It was human, slow and imperfect. But it worked because it was continuously applied by people who understood why decisions were made.
Agentic development makes that implicit governance layer obsolete. Not because senior engineers stop mattering—they matter more than ever. But because their judgment now needs to be externalized, formalized and made executable. That’s a new discipline: owning the intent layer. Defining what the system is supposed to be, encoding it in a form machines can enforce and continuously refining it as the system evolves.
The organizations that govern agentic development effectively won’t be the ones with the strictest review processes or the longest checklists. They’ll be the ones that invested in making engineering judgment executable—architecture as a queryable artifact, pipelines as conformance engines and architects who spend less time reviewing code and more time defining the rules that govern how code gets written.
Faster code was never the hard part. Software Engineering autonomy is the discipline we haven’t built yet.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?

56 minutes ago
3













English (US)