“Vibe coding” has been discussed so much over the past half year that the phrase now carries two opposite meanings.

Some people see it as liberation: no need to think through every layer of architecture, no need to write so much code, just describe the idea to AI and something runnable appears on screen. Others see it as danger: the code seems to run, but every boundary has holes, and two weeks later nobody dares to change it.

I think both judgments are right. They are simply talking about different stages.

If vibe coding means “I do not read the code at all, and whatever AI writes is the system,” then it is indeed dangerous. If it means “I use AI to quickly turn an idea into an operable product experiment,” then it is very valuable. The key difference is not which model you use, and not how shiny the editor looks. The key is whether real data, real users, and a real delivery path are part of the process.

This article uses a concrete example: suppose we want to build a weekend outdoor-activity decision assistant. It does not start from financial data. It uses QVeris capabilities such as weather, air quality, and public data to help users decide whether a city is suitable for running, cycling, camping, or taking children outside on the weekend.

This is not a grand product, but it is a good vibe-coding case. It sits right on top of several real questions: where the data comes from, whether an AI-generated page can be trusted, how a prototype becomes a product, how engineers can take it over, and how quality should be measured.

First, Define the Term

When vibe coding first became popular, it described a loose development style: humans describe intent in natural language, AI generates a lot of code, and humans mostly try it, give feedback, and steer the direction. As the phrase spread, its meaning became blurry.

I prefer splitting it into three layers.

The first layer is generating code. This is the shallowest part. Asking AI to write a page, an API, or a script is no longer surprising.

The second layer is generating a runnable product fragment. This is more demanding. It must connect to real data, run through a complete path, and let users feel value after a few clicks.

The third layer is generating assets that the engineering system can absorb. It does not need to reach production quality immediately, but it must have clear inputs and outputs, data contracts, test samples, failure boundaries, handoff documentation, and a next-step refactoring path.

Most failed vibe-coding attempts get stuck between the second and third layers. The prototype appears quickly and demos well, but once it needs to connect to an existing product, be handed to engineers, calculate cost, implement permissions, or handle exceptions, it falls apart.

Better vibe coding is therefore not better prompting. It is putting productization constraints into the prompt earlier.

Why the Case Needs Real Data

Vibe coding without real data easily becomes a UI exercise.

Ask AI to build a weather assistant, and it can quickly generate a polished page: sunny icons, temperature cards, line charts, and recommendation copy. But if all the data is mocked, the page has no product judgment. The hard parts are not drawing cards. They are questions like:

• What time granularity does the weather forecast have?
• If weather and air quality conflict, which one has priority?
• How do city names, coordinates, and administrative regions map?
• When data is missing, do we degrade, warn, or hide the section?
• Should recommendations be conservative or aggressive?
• Will users make real decisions because of a sentence like “good for cycling”?

These questions only show up when real data is connected.

This is where QVeris becomes useful. It is not only a source of financial data. Its public capability categories include Science, Health & Public Data, Weather & Environment, Media & Creative, IoT & Industry, and more. Science, Health & Public Data covers areas such as public statistics, open government data, weather and environment, and life sciences. Weather & Environment includes weather forecasts, air quality, meteorological reference data, space weather, and earth observation. These data directions are a strong fit for non-financial vibe-coding scenarios.

In other words, a real case does not have to be a stock-analysis assistant. It can also be:

• city outdoor-activity advice
• community air-quality alerts
• public-data trend dashboards
• medical literature or drug-information organization
• IoT device-status observation
• content-creation material workbenches

What these scenarios share is that data matters more than the page, judgment matters more than animation, and exception handling matters more than a demo screenshot.

A Small Case: Weekend Outdoor Activity Assistant

Let us define a very specific product.

The user enters a city, date, and activity type: for example, “Beijing, Saturday morning, take children to the park.” The system returns:

• whether going out is suitable
• major risks, such as rain, wind, heat, or air quality
• recommended time windows
• alternative activities
• data source and update time
• uncertainty notes

The easiest vibe-coding prompt would be:

Build me an outdoor activity recommendation website.
Users enter city and activity type.
Show weather, air quality, and a recommendation.
Use React and make the page look good.

This prompt may produce a page, but it is unlikely to produce a product.

A better prompt should start from data and decisions:

We are building a minimal prototype for a "weekend outdoor activity decision assistant".

Target users: urban families, runners, and cyclists.
Real data: search and call QVeris capabilities for weather forecast, air quality, public geography, or city reference data.
Inputs: city, date, time window, activity type.
Outputs: suitability score, recommended time window, risk factors, data update time, and reasons why the system cannot decide.

Do not write UI yet.
First design the data contract:
1. JSON schema required by the frontend
2. Data capabilities required by the backend
3. Degradation strategy when each field is missing
4. Three reproducible test cases
5. Minimal cost estimate

Generate code only after this is confirmed.

The core of this prompt is not “please write code.” It is “help me compress a product problem into a data contract and verification samples.” Once that exists, the code has an anchor.

Good Vibe Coding Starts With a Data Contract

I increasingly dislike asking AI to generate a page first.

Pages are too easy to trust. Modern frontend component libraries look good enough that a product with no real logic can still resemble a fundraising demo.

A steadier order is:

1. clarify the user decision
2. clarify data sources
3. clarify inputs and outputs
4. clarify failure boundaries
5. clarify acceptance examples
6. then build pages and APIs

For the outdoor assistant, the data contract can begin like this:

{
  "city": "Beijing",
  "activity": "family_outdoor",
  "time_window": "2026-07-04 09:00-12:00",
  "score": 72,
  "recommendation": "Going out is acceptable, but avoid the hottest period around noon.",
  "risk_factors": [
    {"type": "temperature", "level": "medium", "reason": "Temperature rises quickly late in the morning"},
    {"type": "air_quality", "level": "low", "reason": "Air quality risk is low"}
  ],
  "data_freshness": {
    "weather": "minute-level or hourly, depending on upstream data source",
    "air_quality": "depends on monitoring-source delay"
  },
  "fallbacks": [
    "If air quality is missing, return weather-only advice and mark confidence as lower"
  ]
}

This JSON is itself the core asset of the vibe-coding exercise. The frontend can render from it. The backend can design an API from it. Tests can assert against it. Product discussion can evaluate whether it matches user expectations.

Without this contract, no amount of AI-generated code is more than a temporary pile.

Where QVeris Fits

In this case, QVeris is the data base layer, not a UI component.

It can do three things.

First, capability discovery. Developers do not need to know the exact API in advance. They can start by searching natural-language capabilities such as weather forecast, air quality, open city data, or geographic reference data, then choose appropriate tools from the candidates.

Second, capability inspection. During prototyping, do not rush into calls. Read tool descriptions, parameters, pricing, latency, data coverage, and sample parameters. Many vibe-coding failures happen because AI invents a parameter that does not exist, or misunderstands a response field.

Third, capability execution. When real calls happen, save the outputs as fixtures. After that, no matter how UI or models change, you have real data samples for regression.

That is why vibe coding with data differs completely from vibe coding a UI. The former leaves assets behind. The latter often leaves pretty code that nobody wants to inherit.

Turning Prototype Cost Into Product Value

The biggest attraction of vibe coding is speed.

But there are two kinds of speed: seeing something quickly, and quickly knowing whether something is worth continuing. The second one saves real money.

For a prototype to become a product faster, it should leave at least four assets:

Asset	Why it matters
Data contract	Product, frontend, backend, and testing discuss the same object
Real fixtures	Demos no longer rely on the model improvising every time
Failure cases	Engineering knows the boundaries before hardening
Cost ledger	Product can decide whether it fits free trial, pay-per-use, or bundled plans

For the outdoor assistant, the cost ledger does not need to be perfect at first, but it should answer:

• How many capabilities does one recommendation call?
• Which calls can be cached?
• Can requests for the same city and date be reused?
• Can free users see a simpler version?
• Do paid users need higher update frequency, longer windows, or more activity types?

If none of these is recorded during prototyping, productization becomes painful. You are not improving a demo. You are rediscovering what the demo actually did.

Connecting With Existing Products

A vibe-coded artifact should not immediately be imagined as an independent product.

A more realistic path is to treat it as a pluggable capability inside an existing product.

The outdoor assistant could be integrated in three ways:

• a small website page to validate search traffic and user dwell time
• a card inside an existing app that gives daily advice
• an Agent tool callable by other products through an API

These three paths have very different engineering requirements.

For a page, the focus is interaction, SEO, share images, and load speed. For an app card, the focus is API stability, on-device caching, rollout, and analytics. For an Agent tool, the focus is schema, error codes, idempotency, call cost, and explainability.

So a vibe-coded artifact should avoid being “only a page.” It should be decomposed into:

• data adapter: calls QVeris capabilities
• decision engine: turns weather, air quality, and activity type into advice
• api contract: provides stable output to frontend or other products
• ui layer: renders the result
• fixtures and tests: support regression

Only then does it have a chance to enter an existing product without being moved as one fragile lump.

Working With Product and Engineering Teams

AI prototypes easily create misunderstanding inside a team.

Product people see “it already works.” Engineers see “it is not shippable.” Both are right. They are looking at different layers.

A better handoff after vibe coding is a short package, not just a repository link.

The package can include:

1. Which user problem this prototype solves
2. Which flows are real and which are mock
3. Which real data capabilities were called
4. Approximate cost per use
5. Known failure cases
6. Which code can be kept and which should be rewritten
7. Minimal engineering hardening checklist before launch

The more honest this document is, the more willing engineers are to take over.

The worst framing is “AI already finished 80 percent.” Often the truth is: product exploration is 80 percent done, but production engineering is 20 percent done. That is not bad. It just must be stated clearly.

How Engineers Should Take Over

Engineers taking over vibe-coded work should not start by complaining about style.

A more useful order is deciding what is worth keeping:

Layer	Handoff strategy
User flow	Keep it if the path makes sense
Data contract	Stabilize it first if fields are reasonable
Fixtures	Add real-call fixtures to tests
UI components	Keep or rewrite based on quality
State management	High risk, usually needs review
Auth, billing, permissions	Do not trust prototype code
Error handling	Must be redesigned deliberately

One practical method is to build a “prototype shell.”

Put the vibe-coded artifact into an isolated directory or separate service. Write end-to-end tests to freeze current behavior. Then replace internals gradually. Engineers are no longer refactoring uncertain code with bare hands; they have a boundary.

For the outdoor assistant, the first engineering day should not be a full rewrite. A better sequence is:

1. keep three real fixtures
2. stabilize the input and output of /api/outdoor-advice
3. write 5 to 10 boundary tests
4. wrap QVeris calls in an adapter
5. move recommendation rules out of UI components
6. then discuss framework, component library, or deployment changes

The handoff cost becomes much lower.

How to Measure Vibe-coding Quality

Do not measure only whether it runs.

Running is the minimum. Better quality metrics should cover product, data, engineering, and collaboration:

Dimension	How to quantify it
Product validity	Can users understand the problem in 30 seconds
Data realism	Share of real data on core pages, with mock data clearly marked
Reproducibility	Fixed inputs, fixtures, and test commands
Cost visibility	Estimated data-call cost per use
Explainable failure	Missing data, API failure, and model uncertainty produce reasons
Handoff readiness	A new engineer can run it and locate the main flow within half a day
Integrability	Stable API exists, not only page state
Evolvability	Business rules are separate from UI components

If I had to choose only three, I would choose:

• real-data ratio
• reproducible tests
• handoff notes

These three separate toy prototypes from product experiments.

Prompts Should Be Staged Too

Many people write vibe-coding prompts as one-shot wish lists.

For example:

Build me a complete website.
Make it beautiful.
Include login, payment, analytics, and deployment.

This can work, but it encourages AI to generate too much unreliable code at once.

A better approach is staged prompting.

Exploration:

Do not write code. Break this idea into user flows, data needs, risks, and a minimal validation experiment.

Data:

Based on searchable QVeris data capabilities, list the capability types, input parameters, response fields, caching strategy, and failure degradation this product needs.

Prototype:

Implement only one end-to-end happy path. Do not add login, payment, or complex state management. Include fixtures and a test command.

Handoff:

Review the current prototype. Mark which code can be kept, which must be rewritten, and generate an engineering takeover checklist.

Launch:

List pre-launch blockers around permissions, billing, observability, error codes, caching, idempotency, and data compliance.

After prompts are staged, AI stops being only a code generator. It becomes an always-available product-engineering partner.

Treat AI-generated Code as Research Before Treating It as Debt

Some engineers dislike vibe coding, and for good reason: they have seen too much bad AI-generated code.

But I do not think all AI-generated code should immediately be treated as technical debt. More accurately, it starts as a research asset.

Traditional research often stays in documents, competitor screenshots, and meeting notes. Vibe coding can turn research into something clickable, callable, and testable by users. Its value is not “the code is already done.” Its value is “we know earlier whether this direction has a chance.”

Of course, once the team decides to continue, the mode must switch.

From that moment, the rule changes from “see the effect quickly” to “make the system maintainable.” That means:

• data sources must be stable
• schemas must be frozen
• error codes must be explicit
• tests must be added
• costs must be accounted for
• monitoring must be connected
• code must have owners

If the team accepts this switch, vibe coding is not a source of chaos. It is an accelerator for product exploration.

Closing

When I decide whether a vibe-coding project is worth continuing, I do not look at how polished the page is, or how much code AI wrote.

I look at three things.

First, whether it uses real data. Without real data, many judgments are fake.

Second, whether it leaves reproducible assets. Without fixtures, tests, and data contracts, a demo starts losing value as soon as it ends.

Third, whether the engineering system can absorb it. If it cannot be handed off, cannot connect to an existing product, and cannot explain cost or failure boundaries, then speed only produced a disposable demo.

So my answer to “how to vibe code better” is not romantic:

fewer wishes, more contracts; less showmanship, more real data; less “AI has already finished it,” more “this idea has been validated to the point where engineering can take it over.”

That is where vibe coding can genuinely change how software is developed.

References

• Simon Willison: Not all AI-assisted programming is vibe coding
• Addy Osmani: Vibe Coding: The Future of Programming or Just a Fad?
• QVeris public capability explorer: Capabilities summary, Categories

WeChat

Follow ZiCode on WeChat

If this post was useful, you can follow later updates on WeChat as well.

X / Twitter

Follow @ax2_zicode

Faster technical notes, short thoughts, and new-post alerts are posted on X.

X Open X Profile @ax2_zicode