You should be reviewing code generated by llms for this kind of shit. Also scope your changes. All of this stuff is preventable if you're reviewing your code and having your llm review your code. You can setup skills for the review agent to use to look for these things.
Language choice is more often due to politics than practicality. Microsoft probably has some internal process for deciding on languages and "defaults" to typescript & C# since they have the most direct control over those languages.
Not OP, but I ported a legacy .NET WebForms application to Blazor. The actual code migration was completed over roughly a 48-hour period, followed by fairly extensive testing.
We were fortunate to already have a strong end-to-end test suite written in Python, so we could run the new application against the same tests and verify that the existing functionality was preserved. QA found around 20 bugs, which we fixed pretty quickly before launching.
After the migration, we also moved the application's authentication from Shibboleth to Entra OAuth and deployed it to our OpenShift infrastructure. We couldn't do that with the old WebForms application because our cluster doesn't have Windows worker nodes, so the legacy app had been stuck running on VMs. Getting it onto OpenShift gave us another operational and cost-saving benefit beyond simply modernizing the codebase.
I did this back in January, when the models finally became capable enough for this kind of work. I believe I used GPT-5.2 through Codex. Successfully completing this project is what finally got me fully on the AI bandwagon. I had used AI before, but mostly for smaller tasks like writing code, refactoring individual methods, or making isolated changes.
The application is now modernized, more stable, faster, and more functional than it was before.
I think the project worked as well as it did for two important reasons. First, I had deep domain expertise in both the application and its surrounding systems because I was the original developer. Second, our QA team's test suite was comprehensive enough to validate the functionality that actually mattered. AI dramatically accelerated the work, but there still needed to be someone who understood what the application was supposed to do and a reliable way to verify that the new implementation behaved correctly.
None of this means we couldn't have done the migration without AI. We absolutely could have. The difference is that AI made it possible to do it at practically zero cost in terms of engineering time and money compared with the alternatives.
We had wanted to move away from WebForms for years, but with the size of our team and the constant stream of new feature requests, there was never a realistic opportunity to stop development for months and focus on a rewrite. I estimate that doing the migration myself without AI would have taken at least six months to do properly. The other option would have been hiring a contractor, which I would estimate at $80,000 or more over six to nine months.
Based on my token usage, those roughly 48 hours of working with Codex to port the application cost about $150. Those were January prices, so I don't know what the equivalent cost would be today.
For me, that was the project that changed AI from something useful for assisting with individual coding tasks into something I saw as capable of fundamentally changing the economics of software engineering work.
I don't think ai can annihilate us from a misalignment issue but I think there exists a real risk of real world disaster caused by one of these poorly executed benchmarks. They don't seem to be too aware of what they're up to when they let them run for days and days and I could see a scenario like huggingface but for something that matters. Dumb ai is more dangerous than anything right now.
reply