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 should be substantial. And they can be.
But there's a difference between generating code faster and completing a software modernisation project faster. A recent experience shared with me by one of our senior AI consultants brought that difference into focus. The expectation was around 60–70% productivity improvement from AI-assisted legacy code modernisation.
After considerable effort, the team was currently achieving around 40%. 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. If the sample suggests a 60% improvement, why wouldn't the overall project deliver something similar? The problem is that two or three files can tell you how quickly AI converts those particular files.
They don't necessarily tell you how quickly it can modernise the entire application. 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 the conversion becomes faster. Productivity starts to increase. Now the team moves to another part of the application.
The code follows a different pattern. The structure is different. The dependencies are different.
Perhaps the business logic is more complicated. The approach that worked well for the previous set of files doesn't work quite as well here. The team has to investigate the new pattern, adjust the instructions, refine the context and test the output again.
In effect, another optimisation cycle begins. Once that pattern is understood, productivity may improve again. Then the team encounters something different.
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. The team tests it. Something doesn't work as expected.
The developer investigates the problem, refines the prompt or context, and tries again. The next version improves, but another issue appears during testing. The process repeats.
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.
But those instructions don't necessarily emerge fully formed at the beginning of a project. The team learns what the AI misunderstands. It discovers which conventions need to be made explicit.
It identifies patterns that require special handling. It learns where the AI needs more context and where its instructions need to be more precise. Then it updates the prompts and tries again.
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 assuming that a result achieved on a small sample can be applied 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 some 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 productivity gains. Even if AI performs exceptionally well on the first category, the overall result depends on how much work falls into each category and how much effort the others require.
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.
It means the initial sample needs to represent the variety of work that the team will encounter. A more defensible approach would look something like this. 1.
Identify the major code patterns. Understand the different structures, conventions, dependencies and levels of complexity within the existing application. 2.
Select samples across those patterns. Test the AI-assisted process on straightforward code, typical code and more challenging sections, rather than relying on a single convenient sample. 3.
Measure the complete conversion cycle. Include initial generation, prompt refinement, iterations, testing, correction and acceptance. Measure the time needed to produce a working result, not just the time needed to generate the first version.
4. Record where optimisation is required. Identify which instructions or context improvements help, how reusable those improvements are, and where a different coding pattern requires a different approach.
5. Estimate by category. Use the observed results and the estimated distribution of work across the codebase to build a more realistic overall estimate.
6. 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.
And when a new type of code appears, the team may need to invest time in understanding and optimising the approach again. The sensible expectation is that productivity will evolve as the team learns, rather than assuming that the initial result or the latest improvement will apply everywhere. A 40% improvement 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 is a number we need to establish through evidence, rather than assume from the outset.
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.