My view on software rewrites has changed because of AI.
The quality of AI output isn't determined solely by your prompt.
It's determined by what the model already knows from training data, and the context you give it to work with.
For coding tasks, most of that context is the codebase.
Popular tech stacks have an AI advantage because the model has seen millions of examples, including published sources.
The opposite is true for proprietary languages and private frameworks, with inconsistent patterns - these have to be taught - mostly using the limited context window available to models.
Compare these two workflows:
Read the feature specification.
Read a codebase with clear, consistent, well-established patterns.
Generate the implementation.
Versus:
Read the feature specification.
Read an inconsistent codebase with proprietary/legacy languages and historical baggage.
Read additional examples and documentation.
Generate the implementation.
In the first workflow, the codebase has established patterns the model easily understands. In the second, the model spends effort inferring them before it can solve the problem.
More context means more tokens, more prompting, more variance, and generally lower-quality output - aka cost.
A rewrite isn't just an opportunity to modernise your technology stack - it's an opportunity to rebuild your codebase around clear, consistent patterns that play to AI's strengths instead of fighting them.
You could either be using AI to solve the problem, or you could spend the time trying to get AI to learn your language first.
That lost time is your competitors' advantage, and the gap is not just speed - it's output quality.
I think this changes the economics of software rewrites.