The One-Line Bug That Convinced Me AI in Production Is a Product Job
A one-line config change killed every paid order on my busiest day. The real fix was a product decision, not a code one. What running AI in production actually takes.
There was one line in one service. temperature: 0.3. It had been sitting there for months doing nothing interesting, until the afternoon I swapped the model underneath it. Within an hour, every paid question routing through that service returned a 400 and died quietly. No crash. No alert. Just paying users getting nothing back, one at a time, on the busiest day the product had ever had.
The product is Astrika, an AI astrology app that answers questions from a real birth chart. Most people pay ₹49 for one question. That day a lot of them were paying at once, and I had picked exactly that moment to hot-swap to a newer model without re-tuning the prompt. Bigger model, better answers, what could go wrong.
Three things, all at once. The new model narrated more, so outputs that used to parse cleanly stopped parsing. It rejected a parameter the old model had quietly accepted, which is where my leftover temperature: 0.3 turned into a wall of 400s. And it asserted slightly different astrology, so my verification layer started flagging readings that were actually fine. None of it showed up in testing. All of it showed up with real money on the line.
Here is the part I want other PMs to sit with. That parameter was not a bug I wrote that day. It was a bug the model created by moving. My request didn’t change. The dependency did.
Your model is a dependency that ships breaking changes
That is the thing nobody warns you about. An LLM is a dependency that ships breaking changes without a changelog you’ll actually read. New versions reject old parameters. Old versions get deprecated on somebody else’s calendar. If your product treats the model as a fixed thing, you have built on sand and just haven’t felt the tide yet.
I spent two years shipping AI at MoneyLion, including putting live insurance offers inside Microsoft Copilot, and I still walked straight into this on my own product. Knowing the pattern doesn’t make you immune to it.
The other reason these things rot after launch is that the failures are silent. When a database call fails, you get an exception. When a model fails, you often get a confident, fluent, wrong answer, and nothing throws. The user just gets a bad reading, or a bad refund decision, or a bad summary, and you find out when they email you. Or, worse, when they stop emailing and quietly leave.
What the fix actually was
None of it was glamorous, which is sort of the point.
The engine now tries a chain of models instead of one. A 403 or 404 triggers a failover, while a 400 does not, because a 400 means my request is malformed and switching models would only hide my own mistake. Every reading passes seven deterministic checks before a user sees it, and the chart math runs on a local Swiss Ephemeris engine, not the model, because models are equally confident whether they are right or hallucinating a planet. There’s a smoke test I can run in one command before any deploy. And the users hit that day got an apology and free credits automatically, because trust in an AI product is mostly won or lost in the failure path.
But the tooling is downstream of the real shift, and the real shift is a product one.
The part that is actually a PM job
If you’re a PM moving into AI, your job is no longer to define a feature and ship it. Your job is to manage a probabilistic dependency that changes monthly, and to decide, in advance, what happens when it misbehaves.
Concretely, that means writing evals the way you used to write acceptance criteria. It means keeping an error budget for prompts, because prompts regress exactly like code does. And it means treating a model swap as a full release with regression testing, never as a quiet config change. I learned that last one the expensive way, in public, on a festival afternoon.
The same discipline held at MoneyLion, just at a different scale. When we put insurance offers inside Copilot, the engineering was honestly the smaller half. The larger half was proving the thing would behave predictably enough that a partner would attach their brand to it. Enterprise AI dies in procurement review for the same reason my solo product died mid-festival: nobody trusts a system that fails in surprising ways.
The feed rewards demos, and I get why. A screen recording of an agent booking a flight is fun to watch. But a demo only has to work once. Production has to work at 1am, during a spike, on a model version that didn’t exist when you wrote the prompt. The model itself is maybe a third of the actual product. I’m not fully sure about that fraction, but I’m sure it’s the minority. The rest is the failover, the verifier, the smoke test, and the apology email nobody sees until they need it.
I still don’t have proper persistent logs on Astrika, incidentally. It’s on the list. There’s always a list.