AI Changed What a Rewrite Costs
A Salesforce integration I had been avoiding for a year had files past two thousand lines. Rewriting it with Cursor produced a four-fold performance gain, and the interesting part is which half of that work was mine.
There is a category of system every architect recognizes. It works. It is important. And nobody wants to touch it.
Mine was a synchronization service between Salesforce and another enterprise platform. It moved records in both directions across a wide set of entities, maintained the relationships between them, and carried media files alongside the structured data. It had grown for years, one urgent requirement at a time, and it had reached the state where several files ran past two thousand lines.
It was not bad code written by careless people. It was reasonable code that had never been given permission to be reorganized.
Why systems like this survive
The argument against rewriting is always the same, and it is usually correct.
The system is load-bearing. The behavior encoded in those two thousand lines includes years of edge cases nobody wrote down: the record type that syncs differently, the relationship that has to be established before the parent exists, the media file that fails silently above a certain size. Some of that knowledge exists only as code.
So you estimate the rewrite, you multiply it by the risk of losing an undocumented behavior, and you decide to add one more conditional instead. That decision is individually rational every single time, which is precisely how you end up with a two-thousand-line file.
What changed this year is not that the risk went away. It is that the cost on the other side of the equation dropped enough to change the answer.
The plan was the leverage
I did not open the editor and ask for a better version.
I spent the first stretch of the work writing a plan: what the modules should be, where the boundaries belonged, which behaviors were contractual and which were accidents, and, separately, the specific optimizations I wanted in the new design. That last part mattered most, and I will come back to it.
Cursor's plan-first workflow suited this. Having the agent draft and hold an explicit plan before touching files is what makes a long-running change coherent rather than a sequence of locally sensible edits that drift. The plan became the thing I reviewed hardest, because a plan is small enough to read carefully and a ten-thousand-line diff is not.
That is the shift worth naming. The unit of review moved up a level. I was no longer reading every line as it was written; I was checking that the structure was right and then verifying behavior at the boundaries.
Where the four hundred percent came from
The result was a performance improvement of more than four hundred percent, and I want to be precise about the source, because the easy conclusion is the wrong one.
The model did not find those gains. I did.
The optimizations came from understanding the domain: how the sync actually batched, where round-trips were being made per-record that could be made per-collection, which relationship updates were ordered by necessity and which were ordered by accident, and how media transfer could stop blocking the structured path. Those are architectural decisions that require knowing what the system is for.
What the tooling changed was my ability to act on them. Ideas of that shape usually die in the estimate. Restructuring a batching strategy across a two-thousand-line file touches everything, and the work of carrying that change through consistently is the part that makes it uneconomical. That is the cost that collapsed.
So the honest framing is not that AI optimized my system. It is that AI removed the implementation tax that had been keeping my optimizations theoretical for a year.
What still had to be human
Several things did not move, and they are the ones I would emphasize to anyone attempting this.
Deciding what was contractual. No tool can tell you whether a behavior is a requirement or a bug that consumers have adapted to. That is a question about the business, and getting it wrong is how a rewrite breaks production quietly.
Knowing where to look for silence. The failure mode of a sync service is not usually a crash. It is a record that did not update, a relationship that did not form, an attachment that did not arrive. Verifying a rewrite meant checking for absence, and knowing which absences mattered required knowing the domain.
Holding the line on the structure. An agent working across a large codebase will happily produce something that works and is shaped slightly differently from what you specified. Every time I let a deviation through because it was locally reasonable, I paid for it later. The plan only helps if you keep enforcing it.
What I take from it
I have been skeptical of the claim that these tools change how software is built, mostly because the demonstrations tend to involve new code in small projects, which was never the hard part.
This changed my view, but not in the direction the marketing suggests. The gain was not in writing code faster. It was in making a class of work economically viable that had not been viable before: large, structural, behavior-preserving change to systems that already carry load.
If that holds generally, the interesting consequence is not that we will write more code. It is that the systems we have been carefully avoiding for years are now worth reconsidering. Every organization has a list of them.
The judgment about what to change, and what must not change, stays exactly where it was.