AI coding tools such as Cursor have changed the way we think about software development. Code that once took hours to write can now be generated in minutes. Existing code can be analysed, refactored and translated into a different technology stack with help from AI.
So when an organisation decides to modernise a legacy application, the opportunity seems obvious. Give the AI coding tool access to the codebase. Explain the target architecture.
Let it handle much of the conversion work. The productivity gains can be substantial.
But there's a difference between generating code faster and completing a software modernisation project faster. In one client engagement shared with me by one of our senior AI consultants, the initial target was around 60–70% productivity improvement from AI-assisted legacy code modernisation.
After considerable effort, the team was achieving around 40% at the point described. These are observations from that engagement, not industry benchmarks or a final result. That's still a meaningful improvement, but it raises an important question.
Why is it so difficult to predict how much productivity AI will actually deliver? I think the answer goes beyond the quality of the coding tool. It has a lot to do with the way we approach the work, estimate the effort and learn to use AI effectively within an existing codebase.
The first few files can be misleading
When estimating a modernisation project, you can't usually convert the entire codebase before deciding how long the work will take. You need a way to establish a baseline. So you select a small sample of files, run them through Cursor, assess the output and measure how long the conversion takes.
Perhaps the results look promising. The AI understands the code, produces the new implementation and gets through the work considerably faster than the traditional approach. You now have a productivity figure.
The temptation is to use that figure to estimate the rest of the project. But a legacy codebase isn't always consistent. Different parts may have been written at different times, by different developers, using different conventions and approaches.
Some sections may be relatively straightforward, while others contain complex business logic, unusual dependencies or assumptions that aren't documented anywhere. The first sample may be representative of one part of the codebase without representing the whole. And that is where an apparently reasonable estimate can begin to drift.
You optimise for one coding style. Then you encounter another.
This is the part I find particularly interesting. Suppose the team starts by converting a particular type of code. The first attempt might not be particularly efficient.
The AI needs better instructions, more context and clearer guidance about the desired output. The team refines its prompts and project-specific instruction files. It establishes a better process.
The output improves, and conversion becomes faster. Then the team moves to code with a different structure, different dependencies or more complicated business logic.
The previous approach doesn't work quite as well here. The team has to investigate the new pattern, adjust its instructions, refine the context and test the output again. Another optimisation cycle begins.
This is why I don't think AI-assisted modernisation should be treated as a single, uniform conversion exercise.
You may optimise the process for one class of code, only to discover that the next class requires a different approach.
The productivity gains are real, but they may not transfer evenly across the codebase.
- Start with a coding pattern.
- Test AI-assisted conversion.
- Refine prompts and context.
- Improve output and productivity.
- Encounter a different coding pattern.
- Begin a new optimisation cycle.
- Test and validate again.
The hidden work is in the iterations
There is another important factor: quality assurance. It's tempting to think of AI-assisted coding as a simple sequence: Generate the code, review it, move on. In practice, the process can involve several iterations before the result is acceptable.
The AI generates an implementation and the team tests it. When something doesn't work as expected, the developer investigates, refines the prompt or context, and tries again. Further issues may emerge during testing.
In some cases, it may take four or five iterations to get the output where it needs to be. None of this is particularly unusual in software development. Iteration has always been part of the job.
What changes with AI is the balance of effort. The time saved generating the initial code can be partly offset by the time spent evaluating, correcting and validating the output. And the amount of iteration required may vary considerably between different parts of the same application.
This is why QA needs to be included in the productivity calculation from the beginning.
AI can reduce the effort required to produce code without reducing the effort required to prove that the code works.
For legacy modernisation, that distinction is particularly important. The objective isn't simply to produce a new implementation. It's to preserve the behaviour that matters while moving it into a different technology environment.
A result that looks right but changes an important business rule isn't a successful conversion.
The productivity calculation needs to include the learning curve
There's another piece of work that is easy to overlook: developing the instructions that help the AI work effectively with the codebase. Tools such as Cursor can use project-specific instructions and context to guide their work. Refining these files can improve consistency and reduce the need to explain the same things repeatedly.
Those instructions don't emerge fully formed. The team learns what the AI misunderstands, which conventions need to be explicit and which patterns require special handling. It then updates the prompts and context.
Over time, this accumulated knowledge can make the process more efficient. But that improvement takes effort, and the benefits may be specific to particular coding patterns or tasks. When the team encounters a genuinely different problem, some of that learning has to happen again.
This creates an important distinction between the productivity achieved once a workflow is well optimised and the productivity achieved while establishing that workflow. If an estimate measures only the former, it risks overlooking a substantial part of the actual project effort.
Why a single productivity percentage can be misleading
Let's return to the original expectation of 60–70% improvement. The problem isn't necessarily that this level of improvement is impossible. It may be achievable for certain tasks or sections of a codebase.
The problem is applying a small sample's result uniformly to everything that follows. Consider a hypothetical codebase containing three broad categories:
- Straightforward, repetitive code that AI can convert relatively consistently.
- Code that needs prompt refinement, additional context and repeated testing.
- Complex legacy logic that requires substantial investigation and careful validation.
These categories will not necessarily produce the same gains. The overall result depends on how much work falls into each and how much effort it requires.
A project with a large proportion of repetitive code may achieve a very different result from one containing complicated business rules and tightly coupled components. And the time spent optimising the workflow needs to be counted as well. This is why a productivity percentage isn't really a property of Cursor alone.
It's a property of the tool, the codebase, the process and the learning curve between them. Until those factors are understood, a single figure can create a false sense of precision.
A better way to estimate AI-assisted modernisation
I think this calls for a slightly different approach to estimating these projects. Rather than selecting two or three files, calculating a productivity improvement and extrapolating across the codebase, I'd start by understanding the different types of work involved. That doesn't mean every file needs to be examined individually before an estimate can be produced.
The initial sample needs to represent the variety of work the team will encounter. A more defensible approach would look something like this:
- Identify the major code patterns. Understand the different structures, conventions, dependencies and levels of complexity within the existing application.
- Select samples across those patterns. Test straightforward code, typical code and more challenging sections, rather than relying on a single convenient sample.
- Measure the complete conversion cycle. Include initial generation, prompt refinement, iterations, QA, testing, correction and acceptance. Measure the time to produce a working result, not just the first version.
- Record where optimisation is required. Identify which instructions or context improvements help, how reusable they are, and where a different coding pattern requires another approach.
- Estimate by category. Use observed results and the estimated distribution of work across the codebase to build a more realistic overall estimate.
- Keep validating the estimate as the project progresses. As new patterns emerge, update the assumptions rather than treating the initial productivity figure as fixed.
This approach won't eliminate uncertainty. No estimation method can do that completely. But it makes the uncertainty visible and gives the team a way to manage it.
It also creates a more useful conversation with the client. Instead of promising a single productivity percentage based on a small sample, you can explain what has been tested, what remains uncertain and how the estimate will evolve as more of the codebase is understood.
The 40% improvement is not the end of the story
One encouraging aspect of the experience shared by our senior AI consultant is that the process is still evolving. The team is learning more about the codebase, improving its instructions and refining its approach. That creates the possibility of further productivity improvements.
But I wouldn't assume that the gains will increase in a straight line. Some patterns may become much easier to convert as the team builds experience. Others may remain difficult because of their complexity or the amount of validation they require.
Productivity will evolve as the team learns, rather than the latest improvement applying everywhere. The 40% improvement observed in this engagement is already meaningful.
If the process becomes more efficient over time, that's an additional benefit. But it's better to build a realistic plan around what has been demonstrated than to base a project on productivity gains that haven't yet been achieved.
The bigger lesson extends beyond coding
This isn't just a Cursor issue. It's a broader lesson about adopting AI in real business environments. AI demonstrations tend to focus on the task the technology performs: generating code, summarising documents, drafting content or analysing information.
But businesses don't pay for an impressive demonstration. They need a reliable outcome. That means accounting for the work around the AI: providing context, integrating with existing systems, validating results, handling exceptions and improving the process when something doesn't work as expected.
The same principle applies whether you're modernising a legacy application or introducing AI into a document-heavy business workflow. The initial task may become much faster. The end-to-end process may improve substantially.
But the size of that improvement depends on everything required to turn the AI's output into something the business can actually use.
So, what should we expect from AI coding tools?
I think we should be ambitious about what these tools can achieve, but disciplined about how we measure the results. Cursor and similar tools can make a substantial difference to software development and legacy modernisation. The opportunity is real.
But a credible productivity estimate needs to account for the diversity of the codebase, the effort required to optimise the process, the iterations needed to achieve acceptable output and the testing required to establish that the result works. The question isn't simply how quickly AI can convert a few files. It's how quickly the team can convert the application into a tested, maintainable and reliable result.
That is the number that matters to the business, and it needs to be established through evidence.
AI can accelerate code generation. Turning that acceleration into predictable project productivity is a different engineering challenge.
That is where the real work — and the real opportunity — lies.