Ask HN: Is replacing an enterprise product with LLMs a realistic strategy?

8 points by chandmk 120 days ago | 6 comments

I’m looking for perspectives from people who have actually built or operated long-lived enterprise software.

Context (kept intentionally generic):

We have a mature, revenue-generating enterprise application that’s been in production for years.

Semi-technical leadership (with no engineering background) is aggressively considering spinning up a new product, built using LLM-driven tools (AI code generation, rapid prototyping, etc.), with the belief that:

modern AI tooling dramatically reduces build cost, LLMs are going to improve in the future

the new system is an attempt to replicate most of what an established competitor built over ~10 years

customers can optionally migrate over time (old system remains supported)

software-only product that aims to replace all of the current application's operational complexity with a goal to make it resellable product.

early vibe coded demos created with LLM tools are a good proxy for eventual production readiness

The pitch to ownership is that this can be done much faster and cheaper than historically required, largely because “AI changes the economics of building software.”

I’m not anti-LLM — I use them daily and see real productivity gains. My concern is more structural:

LLMs seem great at accelerating scaffolding and iteration, but unclear how much they reduce:

operational complexity

data correctness issues

migration risk

long-tail customer edge cases

support and accountability costs

Demos look convincing, but they don’t surface failure modes

It feels like we’re comparing the end state of a mature competitor to the initial build cost of a greenfield system

I’m trying to sanity-check my thinking.

Questions for the community:

Have you seen LLM-first rebuilds of enterprise products succeed in practice?

Where does the “cheap and fast” narrative usually break down?

Does AI materially change the long-term cost curve, or mostly the early velocity?

If you were advising non-technical owners, what risks would you insist they explicitly acknowledge?

Is there a principled way to argue for or against this strategy without sounding like “the legacy pessimist”?

I’m especially interested in answers from:

people who have owned production systems at scale

founders who attempted full or partial rewrites

engineers who joined AI-first greenfield efforts after demos were already sold

Appreciate any real-world experiences, success stories, or cautionary tales.

verdverm 120 days ago |

Your questions are very interesting and I'm not sure anyone knows. Some people are trying, others want to, I know one company that has gone back on the ai initiative because the ROI was not there.

What I would do is to express your pessimism lightly, or more like, "we are making these assumptions about a new technology we know little about" (pick just 2-3)

Then push hard to convince them to carve out little pieces to try out the supposed "AI changes the economics of building software." and other assumptions. Say something like "how can we validate these assumptions with the minimal effort/time/money, because I've seen some horror stories and not sure the hype holds up. I'm all for it if it works, but we just don't know and we need to chip away at that"

My personal take is that this idea they have will end poorly. I've worked hard and built custom agents to squeeze more out of them (my gem-3-flash is better than copilot with anything impo.), and my takeaway is two-fold (1) they can be both impressively good and unbelievably bad, even the very best models from any company (2) people are sharing their wins far more than the fails, like stonks, the outcomes you can find in the wild have bias. I know I delete a bunch of false starts, gonna be hard to automate this and not spend more than you would on a human, especially as the project grows. You are going to have to pay to load a bunch of context on every run just so the model can go from tickets in Jira to finding what/where needs to change, to getting actually relevant code changes, then making sure they work.

codingdave 120 days ago |

The biggest gotcha is that if existing products were developed over a decade or more, that is decade of iteration over details and customer feedback. You can see the final result, but not the rationale behind 10+ years worth of decisions and discussions. The LLMs are almost guaranteed to get something wrong without that context, which means you final product won't be competitive. Unless you understand the nuance of which features are table stakes vs. market choices vs. regulatory requirement or other such fixed functionality, you might spend all your energy building something that is not even viable.

That doesn't mean you cannot build a newer, better, competitive product. You surely can. But you need to build the understanding of the market yourself so you know when the LLMs go off the rails and get them back on track.

ap_aditipriya 116 days ago |

In my opinion, it is a little early to identify "success/failure" of LLM products just yet, especially Agentic. What we are seeing is the definition of hype, and maybe once that settles we will be able to see the reality a little better. From what I have seen, with the hype much less than early last years, is that customers are more cautious of just "AI labels" on product, but if it does solve a unique problem that was not possible to solve for earlier then its different. In your case, if you are saying that the company is trying to replicate a competitive product, just through Agentic, might not be a very good idea in the long run. Though it also depends on how they decide to build it further - i.e. start with replicating, but then a way bigger roadmap that your competitor couldn't catchup to just because they never built a base (because many are.

dapperdrake 120 days ago |

The attempt will be made.

Most of the rest comes down to inertia and path dependence.

The new lossier models are rarely an improvement over existing less lossy models. That is why there was an old style model in the first place. Putting in the work already had value. And it delivers value now.

lesserknowndan 120 days ago |

Title: spelling "replacing".