AI Tech Stack Migration: What Would Change My Mind

A successful exercise leaves the production commitment to be justified.

For an AI tech stack migration, I would not ask a team to replace a mature stack because an assistant handles course prompts better. A post on r/ExperiencedDevs describes that proposal: move an established C#/ASP.NET/Blazor Server/SQL Server stack to Python after better graduate-course prompting results. That is the author's account, not a demonstrated migration result. [1]

My bar would be accepted production changes that beat improved AI use in the existing stack enough to cover transition and support. Easier prompting earns investigation. It does not yet justify the rewrite.

If you are being asked to change your tech stack for AI, questioning the evidence should not make you the person against improvement. You should be able to welcome the experiment without volunteering your team for the replacement. The future maintainer deserves a reason that reaches beyond the exercise.

A course prompt cannot price an AI tech stack migration

Martin Fowler's Strangler Fig guidance asks what outcomes modernisation should achieve and describes transitional architecture that lets old and new systems coexist. Users still need changes during replacement. This is practitioner guidance, not proof that gradual migration always costs less. [2]

That is why I would separate permission to investigate a prompting difference, permission to try a bounded candidate-stack slice, and permission to replace the stack. Each needs its own approval, with room to stop or retain what already works. This is my proposed distinction, not a validated migration model.

A course exercise can provide a useful signal about that interaction. It cannot price the work of preserving the existing authentication requirement or tell me whether users will get the SQL Server behaviour they expect. Those would be questions for the replacement proposal, not claims about problems this team has.

Choosing that investment belongs with human responsibility in agentic coding, before delegating its implementation. Agreeing to investigate Python need not settle the investment decision.

For an AI tech stack migration, I would also want a fair alternative: the existing C# workflow given the same attention as the candidate.

I would compare against a better version of staying

Here is the AI-assisted software delivery comparison I would want: change one approval rule in an internal application replacing an Excel process. This is a proposed example, not an experiment I have run. Compare AI-assisted work in the retained C# stack, with better repository context and tooling, against a Python candidate. The example is not the Reddit team's application.

Neither language is the established winner here. These sources cannot establish a universal AI code-generation language choice or provide a controlled Python/C# comparison.

Both alternatives would owe the same accepted change. Keep the intended approval behaviour, authentication requirement and representative data fixed, with the same subject-matter expert assessing acceptance. Include the negative case: a user without the approval role must still be unable to approve.

Keep assistant and model conditions comparable where feasible, and record differences. Preparing better context for the retained stack costs work too. I would count it, rather than quietly give my preferred option free preparation.

Faster generation alone would not answer the delivery question. The Reddit author reports generation in hours or days, but expert review, testing and adoption in weeks or months. Those are their reported ranges, not a forecast for this comparison. [1] I would record hands-on work, rework and reviewer effort separately from elapsed waiting for the expert. Future support obligations need their own note. The question of what developers owe reviewers remains even when an assistant produces the change quickly.

Scepticism deserves the same discipline. METR marks its early-2025 productivity result out of date. In its February 2026 update, METR calls its follow-up an unreliable signal of current productivity effects, citing selection and time-accounting problems. Neither publication measures language superiority or migration value. I would not use an old slowdown headline to veto the candidate. [4] [5]

Before seeing results, the team should define its decision horizon and what advantage would make further commitment worthwhile. I would keep the stack if a better existing workflow removed the apparent advantage. A candidate that failed the same acceptance conditions would not earn approval on speed alone.

Repeatable gains across representative accepted changes could persuade me to go further. One convenient approval-rule change cannot establish that durability, let alone pay for making the old stack unnecessary.

A better slice still leaves a replacement decision

AWS's Strangler fig guidance, specifically for monolith-to-microservices modernisation, warns that a routing layer can become a bottleneck or single point of failure. It also names data-consistency concerns. These are examples of coexistence costs, not diagnoses of the Reddit team or reasons for it to adopt microservices. [3]

Back at the proposed approval rule, a Python candidate might satisfy its acceptance conditions while leaving other behaviour, integration and deployment untested. Somebody would still need to explain how the old component retires and who supports the replacement. A software migration business case has to address that remaining scope.

I value existing expertise for a specific reason: someone needs to recognise a changed assumption in that rule and explain an unexpected approval later. Familiarity helps only if it serves that work. An unfamiliar language is not automatically unmaintainable; the proposal needs a credible support owner.

That is a different question from keeping generated code inside architectural patterns. Maintaining a chosen architecture does not establish that choosing a replacement was worthwhile.

I would ask whether the accepted-change advantage survives a conservative account of transition and continuing ownership over the chosen horizon. An unknown support obligation cannot be entered as zero. A promising slice could lead to stopping, more investigation, or approval of a defined replacement scope. Some applications may offer no affordable separation boundary at all.

But coexistence can also cost more than finishing the replacement. That possibility deserves a fair hearing.

A small application could make the rewrite sensible

AWS explicitly allows that smaller applications with low complete-refactoring complexity may be more efficiently rewritten than migrated incrementally. It does not say every small application is cheap to replace. [3] Fowler's desired-outcomes framing also keeps the judgement on what the change should achieve, rather than allegiance to a migration pattern. [2]

The strongest objection to my preference is that AI could make an unfamiliar stack less costly to learn and change. These sources do not quantify that reduction. I would still want to give it a fair test. Familiarity alone would be a poor reason to reject a continuing advantage in accepted work.

These are the choices I would defend, not a scoring model:

For a proposed AI tech stack migration, I would want to tell its future maintainer why the switch was worth inheriting. Until the evidence supports that answer, my preference is to improve AI use in the known stack while investigating a credible alternative. Show a continuing accepted-change advantage that justifies the actual replacement, and I would support it. I do not know the Reddit manager's full case.

What evidence would make you approve the rewrite?

References