InRhythm founder and Chairman Gunjan Doshi recently published a piece on what he calls the AI-Driven Development Lifecycle — the argument that enterprise engineering organizations are confusing individual productivity gains with genuine transformation. It is a distinction that sits at the center of nearly every engineering engagement we are running right now, and it deserves a fuller treatment from an organizational standpoint.
The core observation is simple and, in our experience, almost universally accurate: most enterprise engineering teams have adopted AI generation tools. Very few have redesigned the lifecycle that those tools are now operating inside. The result is faster input into a system that has not gotten faster — and leadership teams that are reporting the wrong metrics as evidence of progress.
This is what we see on the ground, and what we believe any enterprise engineering leader needs to understand before the next budget cycle closes.
The Productivity Dashboard Is Lying to You
When a development team adopts AI coding tools and individual velocity climbs 30 to 50 percent, that number is real. The developer is genuinely more productive. The problem is that the metric is being reported as organizational progress when it is actually only stage-one progress — and it carries a hidden liability.
Faster code generation without equally fast validation infrastructure creates a backlog that is invisible on most dashboards. The security team is now reviewing more code. The architecture board has more changes to approve. The compliance function has more releases to certify. None of those functions scaled when the engineering team adopted Copilot. The bottleneck did not disappear. It moved downstream and became harder to see.
In regulated industries — financial services, healthcare, insurance — this dynamic is particularly acute. The cost of a compliance failure or a security incident in production does not shrink because the code was generated faster. It compounds. And the organizations that are measuring AI ROI only at the generation layer are building technical and regulatory debt at the same time they are celebrating productivity gains.
The first question any engineering leader should be asking is not “how much faster are our developers?” It is “how much faster is our release cycle?” If those two numbers are not moving together, the bottleneck has moved and the organization has not noticed.
Tool Adoption Is Stage One. Workflow Redesign Is the Work.
InRhythm has been building AI-native engineering practices inside enterprise organizations for the better part of three years. The pattern that separates the organizations making structural progress from the ones running what Gunjan calls “acceleration theater” comes down to one question.
The question is not “how do we use AI in our existing workflow?” It is “if AI is handling specification drafting, initial code generation, unit testing, and documentation, what does the workflow look like from scratch?”
That question produces a different answer. It requires rethinking who reviews what, how architecture decisions get made, what engineering ownership means when a significant portion of the code was generated by a model, and how teams are structured around capabilities that did not exist two years ago. It also requires conversations that most technology leaders are not yet having — with compliance teams, with security functions, with architecture boards that have process cycles designed for a pre-AI development pace.
The organizations InRhythm works with that are genuinely ahead are the ones that started with workflow redesign, not tool selection. They chose their tools second, after they understood what the new workflow required. The organizations that are stuck chose their tools first and are now trying to fit a new capability into an organizational structure that was not designed for it.
The System Is the Product
The third dimension of Gunjan’s framework is the one that most directly challenges how engineering leaders think about their own role. Individual developer productivity is a real metric. System speed is the strategic one.
A developer who is 50 percent more productive inside a system where architecture review still meets monthly, security certification still takes six weeks, and deployment still requires four manual sign-offs is operating inside a slow system. The individual improvement is real. The transformation is not. And when leaders report the individual number to their boards as evidence of AI-driven progress, they are building a credibility gap that will close at the worst possible time — when a competitor with a genuinely redesigned system starts shipping at a pace the dashboard-watching organization cannot match.
The leadership challenge this creates is not primarily technical. It is organizational. Redesigning the development system means changing processes that governance functions have ownership over. It means having direct conversations about which approval workflows are adding risk coverage and which are adding only delay. It means treating the engineering operating model as a product that needs to be actively managed and improved — not a set of inherited processes that exist because they always have.
This is where InRhythm focuses its advisory work: not at the tool layer, but at the operating model layer. The tools are a commodity. Every engineering organization has access to the same AI generation capabilities. The organizational discipline — validation infrastructure, workflow design, governance redesign — is what creates durable competitive advantage.
What This Means for Engineering Leaders Right Now
The organizations that will look AI-native in 2027 are making three investments today. They are building validation infrastructure that scales with generation speed. They are redesigning engineering workflows around what AI makes possible, not around what already exists. And they are treating their development system — not just their developers — as the unit of performance improvement.
The tools are already in your organization. The discipline is what remains to be built.