How to avoid disaster when vibe-coding a billing engine — Andrew Garvin, Stripe

A coding agent can operate a billing API while misunderstanding the business model behind it. That is the problem Andrew Garvin, Metronome co-founder, brings to this demonstration with Stripe: getting a complicated billing system running quickly without turning setup mistakes into financial mistakes. The two products have different jobs. Stripe Projects provisions a Stripe account and supporting services through the CLI; Metronome supplies the usage-billing system the agent will configure.

Usage billing combines several kinds of work, each with its own consequences:

• Metering: API activity must enter the billing system as usage. Garvin describes Metronome’s experience metering calls for OpenAI and Anthropic, including work with both companies before they had revenue.
• Commercial rules: The same usage can interact with pay-as-you-go charges, credits, commitments, discounts, and sales-led offers. Counting activity supplies an input; the pricing arrangement determines what the customer owes.
• Spend controls: An agent can keep working and keep spending. Garvin proposes agent-specific wallets as one way to give customers controls over funds an individual agent can spend. This is a direction under consideration, rather than a wallet mechanism demonstrated here.

The risk grows when customers expect a coding agent to operate a deep product without learning its details. Metronome’s response is to improve the developer experience around that agent: supply guidance for the API, make failures easier to correct, and produce an environment in which the financial behavior can be inspected before real customers depend on it.

The live demonstration begins with Stripe Projects initialization and selection of Claude. Initialization does not immediately succeed; there is a short intervention before the project becomes ready. This distinction matters to the workflow: the natural-language billing request comes after the environment is initialized, rather than replacing that prerequisite.

The request is deliberately small: create a demo billing engine in Metronome that mimics Lovable’s pricing model. Garvin encounters this desire repeatedly in conversations with companies: use an existing business model to get started without first designing every pricing detail. Here, the recognizable starting point is prepaid credits with auto-recharge, a model suited to customers signing up and buying service themselves.

That short prompt sets a target for a much larger configuration task. The agent must translate the pricing idea into Metronome objects and create a demo account around them. The eventual result will need to show how usage changes a customer’s credits and invoice, rather than merely prove that an account exists.

Metronome’s portable, extensible skills files carry context for agents implementing the product and calling its API. Their purpose is practical: help an agent avoid setup mistakes and get a customer into a test environment with less friction. The one-sentence prompt works within that supplied expertise; it does not explain all of Metronome’s billing concepts by itself. 6:05

An error appears while the agent works. Garvin uses it to explain a second mechanism: deliberately verbose, clear errors give an agent information it can use to correct its actions. Skills provide guidance before a call; errors provide feedback after a call fails. The developer-experience team is looking for additional failure cases, especially during initialization and setup, where better feedback can guide recovery.

How do guidance and feedback fit together? The diagram separates the context that shapes an API attempt from the error information that can shape its correction. Making both available reduces the amount the agent must infer, although it does not transfer responsibility for the business rules to the agent.

The stopping point is explicit: this demonstration creates a sandbox and does not push it into production. Billing is business-critical and carries deep business logic, so Garvin recommends using coding agents to accelerate work into test mode while keeping a human involved. The tradeoff is deliberate. Faster setup is useful; unattended operation of the entire billing system is outside the intended workflow. 7:35

A useful billing sandbox also needs activity. The skills direct the agent to flow usage into Metronome so the resulting customer looks like one actually using a product. A provisioned customer or contract alone leaves the central behavior unexercised: what happens to charges and balances when usage arrives? Stripe Projects supplies the surrounding orchestration, using the CLI to engage Metronome and potentially other backend services through natural-language requests.

While configuration continues, the discussion turns to what “building for agents” actually means. Three roles create different requirements:

• Agent as product: A company sells an agent whose operation can run up a token bill. Metering helps the company account for that consumption in its pricing model.
• Agent as buyer: The Stripe Projects workflow has an agent procure an initial Stripe instance and additional backend services. Providers need their services to be discoverable and usable by an agent assembling an application. This includes business-to-business procurement as well as consumer-facing agentic commerce.
• Agent as user: An agent operates an existing software platform. This changes the relationship between the number of users accessing the platform and the amount of work the platform performs.

The third role puts pressure on seat pricing. If one agent operates an entire system, substantial value can pass through a single user identity. Charging for that identity may then capture little of the work being done. Garvin calls this “headlessness”: software remains useful even as an agent performs work that previously required people interacting with it directly.

HubSpot supplies the concrete commercial example. Garvin describes its move toward credits, beginning in EMEA with lower seat prices and an added credits model, as preparation for agents operating the system. This is his account of an ongoing transition, rather than a demonstrated result for every HubSpot customer. He also recalls an Andreessen demo day where all five presenting companies built sales-led agents to operate systems such as SAP and invoicing platforms—the kind of usage that can concentrate many workflows behind one platform user. 10:34

Credits do not settle every commercial question. The discussion moves from self-service prepaid credits and auto-recharge to enterprise offers: prepaid commitments, postpaid commitments, and arrangements for particular customers. Garvin describes coding-agent companies adopting commitment structures familiar from cloud service providers. That brings the billing problem back to its opening complexity: usage is one input to a negotiated commercial arrangement, and the engine must administer the arrangement as well as the usage.

Opening Metronome takes a little stage time: “I love all these demos where you’re just looking at people logging in.” Once inside, the human onboarding wizard is unnecessary because the agent has already configured the environment. The customer view contains a demo customer with populated lifetime spend. These values belong to the test environment, not to a real customer’s purchases.

The first inspection is the customer’s draft invoice. The pricing model reproduced here combines monthly auto-recharge with credits scoped to different kinds of usage. In Garvin’s explanation of this model, spending beyond those credits produces an invoice at the end of the period. That requires the engine to keep track of which credits can pay for which activity, as well as what remains chargeable after credits are used.

Follow the same customer through the visible change. The agent created a credit for the initial test period, then supplied usage that drew down the entire credit balance. Returning to the customer view reveals that inserted usage; returning to the draft invoice reveals the billing components associated with the model. Metronome makes the credit a first-class object, so the credit and its consumption can be inspected rather than being hidden inside an undifferentiated invoice total. 14:45

What relationship should a reviewer trace between usage, credits, and the invoice? The diagram follows the demonstrated drawdown and separates it from the stated rule for spending beyond credits. The observable result is a consumed test balance and an inspectable draft invoice; the recording does not establish the exact rates, recharge thresholds, or credit-expiration behavior needed to validate a complete production reproduction.

The invoice exposes four distinct components:

• Build credits: The credit component for build usage.
• Plan mode credits: A separate component for plan mode usage.
• Cloud credits: A component for cloud usage.
• AI gateway credits: A component for AI gateway usage.

Their separation is the useful detail. A reviewer can inspect the model’s different usage scopes instead of treating every credit as interchangeable. The original natural-language request named the model; the resulting sandbox makes its component structure available for examination.

The completed sequence is concrete: initialize a Stripe instance, create a Metronome instance through Stripe Projects, and ask the agent to configure a demo around an existing pricing model. From there, the work becomes testing and tweaking the model before bringing it into production. The agent has accelerated the path to something a human can examine: a customer, usage, credits, and a draft invoice with separate components.

The ending extends this pattern beyond billing. First determine whether an agent is the product, the buyer, or the user, because those roles create different pricing and integration requirements. Then give the agent enough procedural guidance to work effectively in a difficult environment. The combination matters: understanding the commercial role tells you what to build, while skills and useful feedback help the agent build a testable version.

Stripe Projects also becomes a place where providers can make their products discoverable to agents operating through Stripe’s system. Garvin closes with Vercel and Hugging Face as examples of providers working in that environment. Procurement, setup, and product-specific guidance meet in the same development workflow. For billing, its useful destination is a populated sandbox from which a person can decide what should happen when real usage and real money arrive.