Vibe Coding a Configurator: Why the Demo Isn't the Product

Vibe coding (even if I hate that word) is the great magic trick of 2026. You type a prompt, and thirty seconds later there is a product configurator on your screen. Buttons work. Prices appear. Someone in the meeting says "wait, we paid how much for our last CPQ project?"

I have spent over twenty years building and rescuing CPQ implementations, and I will admit something: the first time I vibe-coded a configurator myself, I was surprised. It really is that good. So I want to be honest about both halves of this. The magic trick is real. And the gap between that demo and a configurator you can run a business on is also real. It is just not where most people think it is.

The diagram everyone is sharing

There is a graphic making the rounds (credit to Andreas Horn) showing two cylinders. On the left, what demos look like: Frontend plus Backend. On the right, what enterprise production requires: a tall stack of hosting, CI/CD, security, rate limiting, monitoring, rollback, audit and compliance. Several CPQ vendors have picked it up to argue that vibe-coded configurators are toys, and that years of platform engineering are the moat.

They are half right. A configurator that falls over when two hundred dealers quote at the same time is not a product. Audit trails matter. Version control matters. I have no argument with the stack.

My argument is with the conclusion. Here is the uncomfortable truth about that right-hand cylinder: almost every layer in it is rentable. Hosting, CI/CD, caching, monitoring, rate limiting. This is commodity infrastructure in 2026. A funded startup buys the entire stack off the shelf in a quarter. If that stack were the moat, there would be no moat.

The layer missing from the diagram

The question that actually decides whether a configurator survives contact with a manufacturer is not "does it scale?" It is this: can the quote be wrong?

Not "can the server crash." Can the system produce a quote for a product that cannot be built, at a price that cannot be honored, with a bill of materials the factory will bounce back three weeks later?

That failure mode has nothing to do with infrastructure. I have seen it on twenty-year-old enterprise platforms with every audit checkbox ticked. A rep finds an option combination nobody has tried before, the UI happily accepts it, the price looks right, and the factory discovers at the BOM stage that the machine cannot physically exist. Every layer of the production stack was running perfectly that day. The quote was still a lie. I remember the phone call, and I remember that nobody on it cared one bit about our uptime.

Vibe-coded configurators fail this test by construction. When an LLM generates your configuration logic as code, the rules are whatever the model happened to write that day. There is no separate source of truth about what can and cannot be combined. The code is the truth, and nobody has verified it against the product. It works perfectly in the demo because the demo only walks the happy path.

But, and this is the part the incumbent framing skips, legacy platforms do not pass this test because of their stack either. They pass it, when they pass it, because of a constraint model: the unglamorous layer where someone encoded the physics and policy of the product, and an engine that refuses to output anything that violates it.

The real dividing line

So the market is not split into "slick demos" and "production stacks." It is split by where the correctness guarantee lives.

No guarantee. Vibe-coded and pure-LLM configurators. Fast, impressive, and structurally unable to promise that a quote is valid. Fine for a prototype. Not fine for a promise to a customer.

Guarantee in the legacy engine. Traditional CPQ. The constraint logic is sound, but it is buried in a platform that takes months to implement and speaks in forms and wizards. The guarantee is real; the cost of reaching it keeps most manufacturers out.

Guarantee in a solver, intelligence in an LLM. The third position, and after a year of experimenting, the one I personally believe in. Let a large language model do what it is good at: conversation, reasoning, understanding "I need a fire truck for a city with narrow streets." And let a symbolic constraint solver do what it is good at: enforcing hard boundaries. The LLM is the car; the solver is the guardrails. Every selection is checked against the model, so a quote that violates the product's dependencies cannot exist, no matter how confident the LLM sounds.

Ask any manufacturer which failure they fear more: a slow page, or a signed quote for a machine that cannot be built. I have asked that question in a lot of meeting rooms. Nobody has ever picked the slow page.

What to ask an AI-native configurator vendor

If you are evaluating anything in this space, skip the infrastructure theater and ask three questions.

"Show me the quote that can't be produced." Ask the vendor to demonstrate an invalid combination being refused. If everything is always possible, nothing is guaranteed.

"Where do the rules live?" In generated code, in prompt instructions, or in a constraint model the AI must obey? Only the last one survives the option combination nobody tested.

"What happens when the product changes?" New option, new dependency, changed price list. If the answer involves regenerating an application, you have a prototype pipeline, not a product.

The honest conclusion

Vibe coding did not make configurators trivial. It made frontends trivial, and in doing so it exposed where the value in CPQ actually lives. Not in the stack, which you can rent. Not in the UI, which you can prompt. In the model of your product: what exists, what combines, what it costs, and the engine that makes those rules unbreakable.

Demos will keep getting more spectacular, and I will keep enjoying them. But grade them on the boring question: can this thing quote something wrong? Everything else is negotiable.

Vibe coding and CPQ: FAQ

Can you vibe code a product configurator? Yes, for a prototype. Prompt-built configurators are excellent for validating UX and getting internal buy-in. What they lack is a correctness guarantee: nothing prevents them from quoting invalid combinations, because the configuration logic is generated code rather than a verified constraint model.

Why do AI configurators fail in production? The most damaging failures are not about performance, they are about validity. A configurator fails a manufacturer when it produces quotes for products that cannot be built or prices that cannot be honored. Preventing that requires a constraint model and a solver, not just production infrastructure.

What is the difference between an LLM configurator and a constraint-based configurator? An LLM configurator generates answers from language patterns and can hallucinate invalid combinations. A constraint-based configurator checks every selection against a formal model of the product. The strongest current architecture combines both: the LLM handles conversation and reasoning, the solver enforces validity.

Is enterprise infrastructure the moat for CPQ vendors? Less than it used to be. Hosting, CI/CD, monitoring and rate limiting are largely commodity services in 2026. The durable differentiators are domain-specific: the constraint model, ERP-synced pricing, buildable BOMs and the accumulated knowledge of the product itself.