Vibe coding a real store on .NET

Vibe coding — building software by prompting an AI, reading what it wrote, and steering — is real, and it’s good. On .NET it’s especially good, because a strongly-typed backend gives the model guardrails to fail against. The catch is the part where a store takes real orders and real money. That’s where the vibes need a floor under them.

Why .NET suits it

A lot of vibe coding’s failure mode is confident nonsense that only blows up at runtime. Static types move that failure forward in time — the compiler catches a whole class of hallucination before it ships. When an LLM invents a method that doesn’t exist or passes the wrong shape, C# tells you at build time instead of at 2 a.m. in production.

Add EF Core’s typed queries, records for immutable data, and analyzers that flag sloppy patterns, and you get a language where the model’s mistakes are unusually cheap to catch. .NET 10’s fast iteration loop — hot reload, quick test runs — closes the feedback cycle that vibe coding lives and dies on.

Where it bites

Commerce is unforgiving in ways a to-do app isn’t. The specific places vibe-coded stores go wrong are predictable:

• Money math. Floating-point pricing, tax rounding, and currency handling are exactly the kind of thing an LLM writes plausibly and wrongly. Decimals and tested rounding rules aren’t negotiable.
• Retries and double-charges. A generated checkout handler that looks correct will happily charge a card twice under a network retry unless idempotency was designed in from the start.
• Auth drift. Ask an AI for “an admin endpoint” and you may get one with the permission check quietly omitted. Every privileged path needs a human to confirm the guard is actually there.
• Irreversible actions. Deletes and refunds generated in a flow state, with no audit trail, are how a fast afternoon becomes a bad week.

None of this means don’t vibe code. It means the risky primitives — money, auth, irreversibility — should live in tested, boring infrastructure that the fun, fast, generated code sits on top of.

The floor: build on a typed engine, not a blank file

The move that makes vibe coding viable for commerce is to not vibe-code the dangerous parts. Start from an engine that already has the money math, the idempotency keys, the RBAC, and the audit log written and tested. Then vibe code the things that are genuinely yours: the merchandising logic, the campaign rules, the custom PDP, the little internal tool.

When the foundation enforces the invariants, the model can’t violate them no matter how creatively it hallucinates. You get the speed on the surface and safety in the core. That’s a much better bargain than generating a payment flow from scratch and hoping.

Agents are just vibe coding’s logical end

If you squint, an agent calling your store’s tools at runtime is the same idea as vibe coding, moved from build time to run time — an AI taking actions against your system, needing guardrails it can’t bypass. That’s why the same properties keep coming up: typed contracts, idempotency, audit. Exposing those safely to a model is exactly what an MCP endpoint is for.

How Wardenclyffe helps

The Wardenclyffe AI Engine is meant to be the floor described above: the typed, tested core — pricing, carts, checkout, returns, RBAC, audit — so the code you generate on top can be as loose and fast as you like without putting orders at risk. It targets .NET 10 and ships OpenAPI generated from the code, so an assistant working in your repo has accurate contracts to reason about rather than guesses.

And because it’s source-available under BSL 1.1, you can read every line of the part you’re trusting with the money — which is the one place “just trust the vibes” is the wrong answer.