| 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. |
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.