The vibe coding feedback loop: describe, ship, measure, repeat

The short loop and its open end

The basic vibe coding loop has three moves. You describe a change, the coding agent generates it, you ship it. Then you describe the next change.

That last move is where most loops go blind. The agent knows your code. It does not know your users. So the next description is usually based on a hunch, a single piece of feedback or whatever you happened to notice. The loop is fast, but it is open: nothing that happens after ship flows back in.

The extended loop

The vibe coding feedback loop closes it with two extra steps:

1. Describe the change in plain language.
2. Generate the code with your coding agent.
3. Ship it to real users.
4. Measure what they do with it.
5. Feed back the results to the agent.
6. Describe again, this time with evidence.

Steps 4 and 5 are cheap if you set them up once. The measurement runs on its own after deploy, and the feedback is a query, not a report you have to write.

What "measure" means

Measuring a vibe coded app is not about traffic. It is about whether the product works. Three things answer that.

Feature adoption

A feature is a group of events that mean "someone used this part of the product". A Projects feature might be project_created plus a few other actions in the project view. Feature adoption is the share of your active users who triggered any of those events in a rolling window.

This answers the most useful question in a fast build cycle: of everything you shipped, what do people actually use? Orwel's Features report shows unique users, weekly usage and which features need attention. Each event code also has a tier (reach, activation, core loop, outcome, health) so you can see whether people get past first contact.

Conversion funnels

A conversion funnel, called a journey in Orwel, is a set of milestones that lead to a result. For a SaaS app: signup, onboarding_completed, project_created, invite_sent, purchase. The report shows how many people reach each milestone and where they drop off.

In Orwel the milestones count in any order within the period. Someone who invites a teammate before creating a project still counts for both steps. That is why milestones should be real progress (something was created, sent or paid), not page views or clicks that almost everyone hits. More on this in conversion funnels.

Leads and conversions

The third piece is who. When someone signs in, orwel.identify({ email }) ties the visitor to a person. When someone submits a form or pays, orwel.conversion() records a lead with its own score, intent signals and session history. Now "12 people reached the pricing step" becomes a list of people.

Feeding results back through MCP

This is the step that makes the loop agentic. Orwel runs a remote MCP server at https://api.orwel.io/mcp. You connect Claude Code, Claude Desktop, Cursor or another client that supports remote MCP servers with custom headers, using an API key that has the mcp scope. The server is scoped to the workspace that owns the key and needs an active subscription or trial.

Once connected, the agent can call tools such as:

• get_lead_analytics for totals, sources, score distribution, conversion rate and a 12 week trend
• get_conversions for recent conversion events
• get_visitors for recent sessions, anonymous or identified
• get_campaigns for ad campaign results over 30 days
• get_issues_and_signals for anomalies and funnel drops Orwel detected
• search_leads and get_lead to look at specific people and their sessions

So instead of opening a dashboard, copying numbers and summarizing them for the agent, you ask: "Check Orwel for conversions and detected issues in the last 14 days, then propose the next change." This is MCP analytics: usage data in the same context where the code gets written.

The Features and Journeys reports live in the dashboard. When the next change depends on feature adoption, read the report and paste the numbers into your prompt along with what the MCP tools returned.

The setup for each tool is in Claude Code analytics and Cursor analytics.

A worked example

Here is the loop on a small project management app built with a coding agent.

Describe and generate. You asked the agent to build projects, tasks and team invites. Before shipping, you used the prompts from vibe coding prompts to instrument it: signup and login with identify({ email }), project_created, invite_sent, and a purchase conversion with amount and currency on checkout. You tested everything with the development key and Dev mode showed every request as accepted.

Ship. You switched the production environment to the production key and deployed.

Measure. Two weeks later the signup journey shows that most accounts reach signup, fewer reach project_created, and very few reach invite_sent. In the Features report, Projects has healthy weekly use while Invites barely registers.

Feed back. You ask the agent, which is connected to the Orwel MCP server, to pull conversions and detected issues for the period, and you paste the journey numbers:

Orwel shows most new accounts create a project but almost nobody invites a teammate.
Pull the last 14 days of conversions and detected issues from Orwel to confirm.
Then look at the invite flow in this repo and propose the smallest change that makes
inviting a teammate part of creating the first project. Keep invite_sent firing once,
after the invite API call succeeds.

Describe again. The agent confirms the pattern, finds that the invite button lives three screens deep, and proposes an invite step right after the first project is created. You ship it, and the next cycle tells you whether it worked.

Notice what changed. The prompt names a measured problem, gives the agent the data, and keeps the instrumentation correct while the code changes.

Keep the loop honest

• Instrument where actions succeed, after the API call resolves, not on button clicks.
• Use catalog codes for track(). Unknown codes are rejected and never retried.
• Test every new event with the development key before it reaches production.
• Change one thing per cycle so the next measurement tells you something.

The full checklist is in vibe coding best practices.