Vibe-coding commerce
AI coding agents are good now. The question is what to point them at: the layer where a mistake shows on the screen — the storefront, the landing page, the integration. A commerce engine is where prices are worked out, stock is promised and money changes hands, and its mistakes surface later, as money. Build that layer against an engine that already exists. GoCommerce is an open-source one, documented to the operation and written to be read by an agent.
The appeal
Ask a coding agent for a commerce API and you will get one: a catalogue, a cart, a checkout and a payment integration that compile, pass their tests and click through cleanly. That part is real.
The tests it wrote are the tests it thought of.
Commerce breaks in the cases nobody asked about: two requests at once, the same webhook twice, an order edited after its discount was applied, a gateway that answers after the order already exists. None of these is exotic. They just never come up in a demo, so they come up later — with real orders attached.
The two layers
A storefront is something you can look at, click through and throw away. An engine is a ledger with a state machine attached: when it is wrong, nothing on the screen says so. Keep the line between them clean.
Experience layer
A mistake here is visible: you see it in a browser, fix it and ship again.
Engine layer
A mistake here is silent: it surfaces weeks later, in a reconciliation or a refund.
The rule: vibe-code the layer where you can see a mistake. Build against an engine for the layer where you can’t.
A misaligned button is on the screen the moment it ships. An oversold unit, a discount rounded the wrong way or a refund paid twice turns up weeks later as money that is not where the books say it is, and the trail back to the cause is weeks old too.
Svelte Commerce’s GoCommerce connector is early, at 0.1.0: catalogue, cart, checkout and order lookup, not yet customer accounts or search. Svelte Commerce also runs against 26 other backends, and a GoCommerce storefront can instead be one you write against the API.
Side by side
Same agent, same prompts. The difference is what the agent is asked to invent. Nothing in the from-scratch column is impossible — it is work the engine column has already done and tested.
Checkout · with GoCommerce
One transaction validates the cart, re-prices it under a lock, reserves the stock and creates the order. Only after it commits is the payment provider called, so a slow gateway never holds a lock.
Send an Idempotency-Key and a retried request resumes the same order instead of creating a second. A price that moved or stock that ran out comes back as a per-line conflict for the storefront to show the shopper.
Checkout · from scratch
An agent will write a working checkout in an afternoon, and it will be right for the path you described. The work is in the paths you didn’t: a double-tapped Pay button, a price changed while the cart sat open, a gateway that times out after the order row exists.
Each has a known answer. Each is also another prompt and another test, and they tend to be found after launch rather than before.
Stock · with GoCommerce
On hand and reserved are held per variant, per location. Every movement is one statement that checks and changes under the same row lock, so two checkouts for the last unit resolve instead of racing — the second re-checks after the first commits.
Checkout reserves, a sale converts the reservation, a cancellation releases it, and every movement writes a row to a stock ledger in the same transaction.
Stock · from scratch
“Check the stock, then decrement it” passes every test that sends one request at a time. Overselling needs two at once, which a demo never does.
The fix is well known — row locks or conditional updates — but someone has to ask for it, and a second warehouse turns it into a routing question as well.
Promotions and price lists · with GoCommerce
A discount is a percentage, a fixed amount or free shipping, scoped to the order, products, collections or categories, with dates, a minimum and a usage limit claimed inside the checkout transaction. Price lists resolve by customer group, quantity and channel.
Integers throughout, one rounding per basket, and a discount can never exceed what it discounts. The edge today: one code per checkout, and automatic discounts are not applied yet.
Promotions and price lists · from scratch
Ten percent off is one line. Ten percent off two categories, above a minimum, until Friday, for the first hundred orders, on an order that is edited afterwards, is a string of decisions: round per line or per basket, what an edit does to the discount, who gets the last use.
An agent will make every one of those decisions. It will not always tell you it made them.
Payments · with GoCommerce
Nine payment modules — Stripe, Razorpay, Adyen, Paddle and five more — plus cash on delivery in the core. The Stripe module creates a PaymentIntent and hands the storefront its client secret; the Razorpay module creates a Razorpay order. The card is entered with the provider, not posted to your server.
In both modules a webhook marks the order paid only with a valid signature, and a repeated event cannot settle an order twice. A refund is recorded as pending before the gateway is asked, so two refunds cannot spend the same money.
Payments · from scratch
An agent will wire a payment SDK quickly, and usually reaches for the provider’s hosted fields — the right call. The risk is at the other end: an unverified webhook, a replayed one, the same event handled twice, an order marked paid on the browser’s word.
Each is a line of code. Missing any one of them ships goods nobody paid for, and a test suite written for the happy path will not notice.
The API · with GoCommerce
342 operations across the engine and its modules, every one in a published OpenAPI document that a running store serves at /docs. A rule in AGENTS.md says every served route must appear there.
An agent reads the contract instead of guessing from handler code. The admin panel uses the same contract, so there is no private channel it can call and your client cannot.
The API · from scratch
Without a contract that something enforces, each session names things its own way: total_price in one response, amount in the next, cents here and a decimal string there.
You can generate an OpenAPI file for a scratch-built API too. The discipline is keeping it true, and that is a habit, not a prompt.
Channels and B2B · with GoCommerce
Channels publish parts of one catalogue, each with its own price lists. Customer groups and quantity breaks give wholesale pricing, and scoped API keys let a buyer’s system order by machine. Marketplace vendors arrive pending and are approved or suspended.
The edges: channels scope publishing and price, not orders; there is no quotes or approvals workflow; vendor commission is recorded, not settled.
Channels and B2B · from scratch
The price function the agent wrote assumes one price per product and one storefront. Then a wholesale buyer wants their own prices, and a second storefront wants a different range.
Teaching a price function that assumed one kind of buyer about groups, quantities and channels is possible. It is also where the shortcuts of the first month tend to get paid for.
Every claim in the GoCommerce column can be checked in the repository: core/checkout.go, core/inventory.go, core/discounts.go, core/pricing.go, core/channels.go, core/orders.go, and the payment modules under ext/.
The agent’s toolkit
Don’t vibe-code an engine from nothing. When you do change this one — it is MIT, and changing it is expected — the rules are written down, the contract is published, and a test suite is waiting for the wrong edit.
/docs. A storefront agent’s first read.ReadOnly withholds the 10 that change anything.AGENTS.md — 14 rules, 4 agent notesMoney is integer minor units. A state change and its event commit together. No transaction is held across a network call.skills/ — 15 task guidesCheckout, discounts, inventory, orders, payments and the rest. An agent loads the one for its job instead of reading everything.| Read (9) | store_info, store_health, list_products, get_product, list_low_stock_variants, list_orders, get_order, list_customers, sales_report |
|---|---|
Change (10) — withheld under ReadOnly | update_variant_inventory, set_variant_price, create_product, update_product, create_discount, mark_order_paid, cancel_order, create_fulfillment, mark_order_delivered, refund_order |
The MCP endpoint inherits the admin’s authentication, so the store’s admin token is the agent’s credential. gocommerce doctor -json is the machine-readable health check: it exits non-zero when something is wrong, so it can gate an agent’s work without being parsed.
Honest take
Not every store needs an engine. These three rarely do.
A campaign page, a short product list and your payment provider’s hosted checkout. It runs for a month and is switched off. There is nothing to maintain, so there is little to get wrong.
A proof of concept to test demand or make a case. It is explicitly disposable, and nobody is going to reconcile its takings.
One product, one market, one currency, no discounts, stock you can count on your fingers. If the commerce logic fits on one screen, an engine may be more than you need.
Once there is real stock, a refund to issue, a discount with a limit or a second market, the engine is the part not to improvise. It does not have to be GoCommerce. It should be something written, tested and documented before your first order, not after it.
Where it stands
The argument above is about engines in general. This is about this one.
No store we know of runs GoCommerce in production yet.
It carries over 1,000 tests, a documented contract for every route and the engine behaviour described on this page — but not production mileage, which only time and real stores provide. Build on it deliberately, and test your own store against it before it takes real orders.
There is no hosted version, no paid tier and no support contract. You run it; help comes from the issue tracker and the Discord.
Svelte Commerce runs arialshop.com in production, against a different backend. Its GoCommerce connector is early, at 0.1.0, and no store we know of runs the pair in production. A GoCommerce storefront built on it, or written against the API, is the experience layer — exactly the work this page says to hand an agent.
FAQ
It can write one that works in a demo, and quickly. The argument here is about which mistakes you find, and when. A storefront bug shows on the screen the day it ships. An oversold unit, a discount rounded the wrong way or a webhook handled twice shows up later, in a reconciliation, as money that is not where it should be. That is the layer worth building against something written and tested in advance.
It can, and the repository is set up for it. GoCommerce is MIT and meant to be modified: AGENTS.md holds 14 architectural rules and 4 notes for AI agents, skills/ holds 15 task guides, and over 1,000 tests run against a real PostgreSQL to catch a wrong edit. The difference is between changing an engine whose rules are written down and whose behaviour is tested, and improvising one that has neither.
Yes, through an early connector — Svelte Commerce’s GoCommerce connector is at 0.1.0 and covers catalogue, cart, checkout and order lookup; customer accounts and search are not covered yet. Svelte Commerce also runs against 26 other backends, and a GoCommerce storefront can instead be one you write against the documented API. That is experience-layer work: visible, testable in a browser and easy to throw away, which is exactly the work this page suggests handing to an agent.
Not through an agentic commerce protocol: ACP, UCP and AP2 are not supported. The MCP module is for running a store, not shopping in one — it inherits admin authentication, and its 19 tools read and change orders, stock, products, prices and discounts. A buying agent can use the same public catalogue, cart and checkout routes a storefront does, and building that entry point is experience-layer work.
No store we know of runs it in production yet. It has over 1,000 tests and a documented contract for every route, but not production mileage. Treat it as something to build on deliberately, and test your own store against it before it takes real orders. There is no hosted version, no paid tier and no support contract; you run it.
GoCommerce makes no compliance claim. What its Stripe and Razorpay modules do is keep card entry on the provider’s side: the engine creates a payment with the provider and hands the storefront what it needs to finish it there, and neither module asks the engine to handle a card number. Your compliance position depends on your provider and on how your storefront is built — ask your provider what applies to you.
One command gives you GoCommerce, its admin and its OpenAPI contract on a machine you control. Hand your agent /docs and a storefront to build; leave the ledger to the engine.