Rebuilding a legacy system from scratch takes 18 to 24 months. Regardless of the industry. But can it be done in only 6 months? That’s what our team was asked to do.
Years of tech debt were slowing down the system of a marketing platform and creating hurdles in onboarding top-tier customers. But the deadline was a steep ask. Without AI, meeting it was impossible. Our development team decided to make the system AI-native so that the platform stays future-ready.
As the team started to build, development picked up speed but at the same time revealed something far more intriguing: the bottleneck was not staying anchored where we expected it to. It was shifting.
UX faced it first. In 13–14 modules, design struggled to keep up with development. Engineers had bandwidth, but the screens were just not ready. Rather than wait, we kept momentum by creating interim screens ourselves. Once the design caught up, we updated them.
Then, the bottleneck shifted again.
Now it was QA’s turn to struggle in absorbing the volume delivered by development. The coding speed of engineers improved with AI tools, but that didn’t help manual testing. In fact, many AI-generated use cases stalled in production due to the delay in testing.
Taken together, these events showed us that making one part of the software delivery system more productive creates a procedural imbalance. We needed to increase the capacity of the entire system. Many organizations find the question this raises deeply concerning: how should a team treat the software delivery system when coding is no longer the bottleneck?
What is the AI productivity trap?
Cursor, Copilot, coding agents, and MCPs to boost software development have become the norm in most organizations. Their appeal lies in the immediate productivity gains they offer. Engineers benefit from the extra power AI brings in processes like generating, refactoring, debugging, and documenting code.
But does each stage of the SDLC experience the impact of AI the same way?
The answer is ‘no.’ That uneven influence impacts the entire SDLC. Faster coding triggers local productivity gains but introduces chokepoints for design, review, testing, and deployment. Achieving system-level productivity gains remains out of reach.
AI tools may triple coding speed and close more development tasks. But that doesn’t mean the organization is building software 3x faster. The additional output can create longer review queues, more testing work, more security checks, and increased waiting time for deployment.
This is the AI productivity trap. Localized gains in individual stages create the illusion of higher productivity, but the end-to-end delivery system sees little improvement in speed.
Most of the existing SDLCs revolve around human production rates. Adding AI tools to these systems without changing how these systems work will limit their impact. The system should evolve for AI to deliver its full value.
The bottleneck is unpredictable
Bottlenecks shifting continuously are just one part of the problem. The other is unpredictability. Pinpointing where the next constraint will appear in that SDLC or in the next project is a challenge. In one project, UX may struggle first; in the next, code review may falter.
A change in the distribution of capacity across the delivery system creates this unpredictability.
AI increases capacity in one stage → system capacity becomes uneven → work accumulates → the bottleneck moves.
The slowest or unchanged part of the SDLC holds AI back from delivering value. However, every stage cannot be made equally fast. Continuously identifying where work is accumulating and redesigning that part of the process is the only way to move forward.
In short, make the SDLC adaptive.
Measure delivery throughput to make the system adaptive
Developer productivity is always difficult to measure. When customer reception of software becomes more important, lines of code, commits, tickets closed, and story points fail to provide an accurate picture. AI makes these benchmarks even less useful.
With AI, engineers can generate more code in less time. But does that volume add any value? The volume may pile up review work, add more tests and security checks, and increase maintenance without improving the product at all.
Companies should focus more on measuring idea-to-production cycle time and the system metrics behind it. Parameters should include waiting time in design, pull-request review time, testing time, rework, deployment frequency, and defects escaping into production.
Based on these measures, the exact location of the constraint can be identified. A growing design queue may indicate a gap in speed between development capacity and UX. Adding these measurements to the feedback loop will make the system more effective at locating constraints. Once they are exposed, the process can adapt.
Coding activity alone should not be the decisive factor in measuring AI’s productivity gains. Delivery outcomes should drive decisions.
AI-native development can move the needle
Most organizations follow AI-assisted software development. Teams use AI in silos for localized gains: developers write code using copilots, QA teams generate test cases, and engineers review pull requests.
AI-native software development works on a totally different assumption. Here, the focus is on changing the lifecycle. The delivery system is designed as follows:
SDLC redesigned around AI capabilities → AI embedded across stages → Automate repetitive work and gates → Reserve human judgment for where it adds value → Throughput improves
A system doesn’t become AI-native just by implementing AI across stages if it still follows the same sequential stages, queues, and handoffs. AI-native development benefits from these underlying system changes and becomes effective when the workflow is redesigned around the new scope that AI creates.
5 changes in SDLC to become AI-native
1. Move AI upstream
Coding is often the first stage where teams deploy AI for immediate, visible productivity gain.
But AI can start impacting development much earlier. Decision-making can benefit from AI by removing ambiguity in requirements that can initiate unnecessary implementation, redefining weak user stories to prevent rework, and improving architectural decisions before teams start coding when changes are less expensive. These improvements become possible as AI creates more opportunities to challenge requirements, navigate through scenarios, identify dependencies, break down tasks, compare architectures to determine the best one, and come up with technical specifications.
There’s a downside as well. When AI increases capacity, it also inadvertently increases the speed and scale at which bad decisions can spread. This makes the quality of inputs a priority. Building the wrong thing three times faster doesn’t make the team three times more productive.
2. Automate the gates around development
An increase in implementation creates a need for more capacity to absorb the additional work. Automating gates can help.
Take code review, for instance. Routine reviews often consume most of a senior engineer’s bandwidth. An increase in coding speed piles up review tasks and leaves the engineer with little time for other, more relevant work. Automated checks for formatting, coding standards, bugs, common security issues, exposed secrets/API keys, release readiness, and other deterministic problems can remove routine review work. With roughly 80% of review work automated, a senior engineer can focus more on strategic decisions.
The same logic applies to testing. AI can help generate test cases, but manually executing those tests moves the constraint from development to QA.
With AI in the fold, senior engineers can redirect their attention to more pressing matters like architecture, unusual edge cases, business logic, risk, and decisions where judgment matters.
3. Turn engineering knowledge into context AI can use
Implicit knowledge makes experienced engineers more valuable. They have spent months or years implementing and reviewing code, learning which architectural patterns to follow, which libraries are approved, which technologies are prohibited, how APIs should be structured, what security requirements apply, and other important details. AI’s increased execution capacity makes it more dependent on what these engineers know. It can also complicate human knowledge transfer.
Making tacit knowledge explicit also improves how knowledge transfer takes place between engineers. This knowledge can become context for both engineers and AI. But AI needs the information in a readable form. That makes rule files, coding standards, architecture guidelines, design systems, repository documentation, reusable prompts, and selected MCPs part of the engineering system. Traditional documentation that only explains what to do isn’t enough. AI must also know what not to do. Negative constraints are just as important for AI as explicit instructions.
For instance, telling an AI system that a project uses Tailwind may not stop it from using another UI framework. An explicit instruction not to use any other framework is equally important because it removes ambiguity.
This implicit knowledge should be structured to provide context for both engineers and AI. Making it explicit and defining negative constraints both require a broader organizational shift.
4. Redesign engineering roles around judgment
AI can outpace engineers in producing implementations, refactoring code, generating tests, performing routine checks, and exploring approaches. Experienced engineers should reserve more of their bandwidth for decomposition, architecture, trade-offs, validation, integration, exception handling, and consequential technical decisions. Brownfield projects particularly require respect for existing architecture, databases, production behavior, and testing requirements.
But this doesn’t mean engineers should not work directly with AI. Prompting is crucial. Redesigning workflows should place more importance on skills that provide the right context for AI and assess what AI can deliver.
5. Build continuous learning into the engineering system
Models, coding agents, MCPs, and context-management techniques are either getting upgraded or replaced continuously. These changes affect the development process. Organizations should find a way to measure the impact.
As part of this initiative, small teams can experiment with new capabilities, capture and share common patterns, update rule files, and standardize successful workflows. They can remove those tools when the context or complexity they introduce becomes more overwhelming than their value. The team should turn experiments conducted by individuals into shared capabilities.
These teams can also help the delivery system continue to adapt. After improving one step, they can move on to identifying where the constraint moves next and respond accordingly. This makes AI adoption more of a continuous engineering discipline.
What this looked like in practice
Let’s return to the modernization project we started with.
The changes I am suggesting here are not theoretical. We made them to ensure we met deadlines without compromising quality. We integrated AI to increase our development capacity so we could rebuild millions of lines of code and replace a monolithic platform burdened with technical debt. But features still had to ship at the same pace because new customer onboarding depended on them.
AI did what we expected it to do. It helped reduce the timeline from 24 months to six.
But the path was not this simple:
Development gets faster → the project finishes faster.
It was more like
Development capacity increases → Constraint surfaces: UX → process adapts and engineers help bridge the design gap → Constraint moves: Manual QA → test automation expands → Overall delivery accelerates
We could have asked our engineers to wait until the designs caught up. But that would have been disastrous for the deadline. It was a spur-of-the-moment decision to ask the team to create some screens based on its understanding and revise them as UX caught up. The team’s adaptability to emerging needs made this possible.
Then QA got stuck. It was time to adapt again. AI helped engineers and testers create better test cases quickly, but manual testing became the bottleneck. It simply could not absorb the volume of changes being produced. We had to automate testing to preserve the speed gained earlier in the lifecycle.
We realized speed alone was not enough. As AI took on more implementation work, it needed access to the engineering knowledge to guide decisions. This prompted us to ensure that implicit knowledge became explicit. AI becomes little more than a fancy term when it is unaware of coding standards, architecture patterns, approved technologies, security requirements, and negative constraints.
This was the pattern throughout the development. We didn’t just optimize AI usage. Every increase in capacity changed the balance around it and created a new need somewhere else. We just kept adapting the engineering system to match those changes.
The pattern is likely to repeat as AI capabilities improve. Engineers in AI-native teams need to keep looking for the next constraint and redesign the process around it.
SDLC is constantly changing
AI’s impact across the SDLC is now quite evident. It has reduced the amount and type of effort required for each stage, but not at the same rate. This lack of uniformity in capacity is causing some friction.
SDLCs were historically centered around human effort, where the time spent on requirements, design, implementation, review, and testing was considerable. That helped organize the work for those stages. AI has changed that distribution of capacity. SDLCs built around past constraints can become constraints for the future.
Adding AI tools to an otherwise unchanged SDLC may trigger some local gains, but a system-wide improvement requires a change in the SDLC itself. Without that, improving delivery across design, review, testing, deployment, and engineering practices is next to impossible.
A change in the SDLC means new workflows, more automation, the integration of engineering knowledge that machines can read, more involvement of senior engineering judgment in strategic decisions, better system-level metrics, and a continuous learning engine to understand AI tools and how they can further fine-tune the SDLC.
These changes will make the delivery system more adaptive to emerging constraints and shifting capacities. Organizations that continually redesign their software delivery around those shifts will deliver faster, more reliable outcomes.
