What vibe coding is
Andrej Karpathy named it in a post on X in February 2025: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." He described talking to a coding tool, accepting its changes and pasting error messages back until things worked.
The term spread fast and got wider. Microsoft Learn now defines it as "a form of AI-powered software development where the emphasis shifts from writing code line-by-line to describing the desired product experience in natural language." Simon Willison keeps the narrow meaning: "building software with an LLM without reviewing the code it writes", and separates it from AI-assisted programming where you review, test and can explain every line.
Both meanings share one thing. You describe intent in plain language, and a model turns it into working code. The person stops typing implementation and starts steering.
That shift opened software to people who never wrote code, and made experienced developers much faster at prototypes, new features and refactors. It also moved the hard part. Writing the code is no longer the bottleneck. Knowing what to build next is.
The vibe coding loop
Most vibe coding follows the same short cycle:
- Describe. You tell the coding agent what you want: a signup page, a pricing table, a quote builder.
- Generate. The agent writes or edits the code. You run it, look at it and fix what broke by describing the problem.
- Ship. You deploy. Real people start using the thing.
- Describe again. You decide the next change and go back to step 1.
The loop is fast. A feature that used to take a week can go from idea to production in an afternoon. The problem is step 4. Where does the next description come from?
For most builders the honest answer is a guess. A hunch, a request from one loud user, something a competitor shipped. The agent is excellent at building whatever you describe, and has no idea whether the last thing it built is being used.
Why measuring is the missing step
A coding agent can read your entire codebase. It cannot read your users. It does not know that half the people who start onboarding stop at step two, that nobody has opened the export feature since launch, or that the form you added yesterday is the only thing producing leads.
Without that information the loop has an open end:
- You keep building on top of features nobody uses. Every new prompt adds code, and code that is never used still has to be maintained.
- You fix the wrong problems. The bug you hear about is not always the drop-off that costs you the most.
- The agent repeats your assumptions back to you. It will happily build what you ask for. It will not tell you the last three things you asked for went unused.
Adding a measure step closes the loop:
- Describe
- Generate
- Ship
- Measure: see which features people adopt, where they drop off in your conversion funnels and which actions turn into leads.
- Feed back: give those results to the agent.
- Describe again, with evidence.
This is what we call the vibe coding feedback loop. The next prompt stops being a guess and starts being "feature X has low adoption and most people drop off before step 3, fix that first."
What "measure" means in practice
Page views are not enough. A vibe coded app needs to answer product questions, not traffic questions. Three kinds of measurement matter:
- Feature adoption. Group the events that mean "someone used this part of the product" into a feature, then see how many active users use it each week. This tells you what to double down on and what to remove.
- Conversion funnels. Define the milestones that lead to a result (signed up, created a project, invited a teammate, paid) and see how many people reach each one and where they stop. In Orwel these are called journeys, and milestones count in any order within the period, so a user who invites a teammate before creating a project still counts for both.
- Leads and conversions. Record the moment someone hands you their email, books a demo or pays, with the person identified by email so you know who they are.
Orwel is built around exactly this. The SDK autocaptures page views, clicks, scroll, forms and errors. Business events come from a semantic catalog of 257 ready event codes (signup, project_created, invite_sent, purchase and so on), plus custom codes you register. Feature adoption and conversion funnels are reports on top of those events.
How to add measurement to a vibe coded app
The trick is to let the agent do the instrumentation, but with rules, so it does it correctly the first time.
1. Give the agent the rules
Install the Orwel agent skill once:
npx skills add hyperlabs-ai/hyper-skills/orwel
The skill teaches the agent the SDK and its rules: read the key from an environment variable, init once on the client, use catalog codes for track(), identify users with an email, and await conversions before the form unmounts. If your tool does not support skills, put the same rules in your project instructions with the CLAUDE.md analytics template.
2. Ask for it in plain language
Then describe what you want measured, the same way you describe features. For example: "Install Orwel in this project, identify users when they sign in and record a lead when they submit the contact form." The vibe coding prompts page has ten copy-paste prompts for signup funnels, feature usage, lead forms and verification.
3. Test with a development key
Every Orwel workspace has a development key (orwel_dev_...) next to the production key. Use it in your local .env. Requests sent with it appear live in Dev mode, a request inspector that shows each request, what was accepted and why anything was rejected, with a suggested fix. Leads created with it are marked as test, and no notification emails or integrations run.
4. Feed the results back
Orwel runs an MCP server, so Claude, Cursor or another agent that supports remote MCP servers can query your workspace directly: leads, visitor sessions, conversions, campaign results and the issues Orwel detects, such as funnel drops. This is MCP analytics: the agent reads real usage before you write the next prompt. Setup details are in the Claude Code guide, the Cursor guide and the docs.
The full checklist of what to do and what to avoid is in vibe coding best practices.
Vibe coding tools and how measurement fits each one
Vibe coding tools fall into two groups. Coding agents that work inside your repository (Claude Code, Cursor, Windsurf) and app builders that host the project for you (Lovable, Bolt, Replit, v0). The measure step works with both. What changes is how you get the SDK in.
Claude Code and Cursor
Both work in your repo and both can use the Orwel skill and connect to the Orwel MCP server. See the step by step guides for Claude Code analytics and Cursor analytics.
Lovable
Lovable has its own install guide at /install/lovable. You paste one message into the Lovable chat; it installs the orwel npm package, calls orwel.init() once in src/main.tsx and wires identify plus an awaited conversion on your contact forms. The production key is public (it can send events, not read data), so it can live in the code there.
Bolt
Bolt builds standard web projects from a chat. There is no Bolt specific Orwel guide, so paste the install prompt from the install overview into the Bolt chat and pick the guide that matches the framework Bolt generated (for example React with Vite). Then verify in Dev mode as usual.
Replit
Replit's agent works on a real project with files and environment secrets. Pick the framework guide from /install, store the key as a secret using the variable name for that framework, and paste the install prompt into the agent. If your Replit project is plain HTML, use the script tag guide.
v0
v0 generates React and Next.js code. Follow the Next.js install guide once the project lives in a repo, with the key in NEXT_PUBLIC_ORWEL_KEY. The same install prompt works in the v0 chat if you keep building there.
Windsurf
Windsurf is a coding agent inside an editor, so the flow matches Cursor: give it the rules (skill or a rules file built from the CLAUDE.md analytics template), paste the install prompt and follow the framework guide from /install. Any MCP client that supports remote servers over streamable HTTP with custom headers can connect to the Orwel MCP server; check the docs for the configuration.
A short example
Say you vibe coded a small invoicing app. You shipped a quote builder, a client list and a CSV export. A week later you ask the agent, through MCP, how many leads came in and from where, and you open the Features report. The quote builder has steady weekly use. The export has almost none. Your signup journey shows most people create an account but few create their first quote.
The next prompt writes itself: "Most new accounts never create a first quote. Add a sample quote to the empty state and a two step guide. Keep the export as is for now." That is the measure step doing its job.