The missing step in vibe coding: Verify what actually shipped

AI can build a working prototype in minutes. That doesn’t mean it built what you asked for.

The same problem that has long affected software development is showing up in AI-assisted coding: requirements get translated into something that looks right, get marked complete, and never get properly verified. The result can be missing functionality, incomplete logic, or a system that works differently from what was specified.

The answer is simple: verify what actually shipped.

That means defining how each requirement will be tested before the work begins, then checking the live result against that standard.

The same principle applies to vibe-coded tools, technical SEO fixes, and the results you report to clients.

AI can build it. You still have to verify it.

Use the AI. Prompt the prototype. Run the crawl in whatever tool you trust. None of that is the problem. The problem is stopping there and calling it done.

I think of that as vibe and verify: use the tools, but verify the result against a standard you set before you started.

Whether you’re shipping an AI visibility platform, running technical audits, or advising clients on how AI systems retrieve and cite their content, you’re making claims that someone else is going to rely on, often to spend money.

Ownership doesn’t come from running the tool or forwarding the ticket. It comes from being able to show that the result matches what you intended.

Dig deeper: How to vibe-code an SEO tool without losing control of your LLM

When ‘done’ wasn’t done

Earlier this year, I did something I should have done much sooner: an exhaustive, line-by-line audit of my platform’s code against the specification I’d written for it. Not a status meeting. An actual read of the code.

I found that a core component responsible for scoring and evaluating content trustworthiness was described in documentation, referenced in client-facing materials, and absent from production. Not partially built. Not buggy. Absent.

The root cause was almost mundane. I’d built working prototypes of that logic myself months before handing engineering off. They existed in files the whole time but were never ported into the live platform. The gap sat underneath eight months of status updates that never mentioned it.

I found another version of the same failure: something the backend computed was being reported to me as something the client received. Those aren’t the same claim. Once I asked whether the result actually reached the client’s eyes, not just the server, two more gaps turned up.

None of this was caught by asking, “Is it done?” It was caught by refusing to accept the answer without evidence.

That’s what changed how I write specifications. Every requirement now has a verification method attached to it, with a test I can run myself.

Why this matters beyond my own story

We’re now applying the same shortcut to software development through vibe coding: prompt an AI directly, skip the traditional developer handoff, and get a working product faster. But removing the handoff doesn’t remove the underlying problem. 

A vague specification handed to AI can produce the same drift as a vague specification handed to a developer. The AI just won’t necessarily flag the ambiguity or tell you something fell through the cracks.

Vibe coding is genuinely useful for mocking up a dashboard, visualizing a prototype, or testing an idea before you invest real money. But once customers depend on what you’ve built, the standard changes. You need someone who can make sure the end product is what you specified, not just something that looks right in a demo. 

Dig deeper: Inspiring examples of responsible and realistic vibe coding for SEO

---

An SEO audit isn’t a specification

You run a crawl in whatever tool you use. It flags a pile of issues: broken canonicals, missing hreflang, orphaned pages. You copy the output, paste it into a ticket, and hand it to the dev team. In your head, you’ve told them exactly what’s wrong and what to do about it.

Have you, though? The tool told you what it detected. It didn’t tell your developer why it matters, what “fixed” actually looks like on this specific site, or how you’ll verify the fix once it ships. A scanner’s flag isn’t a specification any more than a wish list is one. 

Not every flagged issue even deserves a ticket, which makes it even more important that the ones you do send are exact. If the ticket doesn’t say what to check, on what page, and with what expected result, you’ll get the same outcome I got: something gets marked “resolved,” and six months later, the issue, or a cousin of it, is still there.

Don’t forward the tool’s output. Translate it into your own specification, with your own verification step attached, before it ever reaches a developer.

Dig deeper: Why vibe coding is becoming an SEO advantage

Vibe and verify: A working checklist

Before you call anything “done,” run it against these four fields. Not a yes/no. If you can’t fill in a specific answer, that’s the finding.

Role	Problem, stated exactly	Solution, stated exactly
Developer, or the person specifying the build	What’s actually broken or missing, in the system’s own terms, not “this should work better.”	What specific change closes the gap, and what the finished state looks like in concrete, checkable terms.
Technical SEO finding	The actual mechanism, not the tool’s generic label. Not “page speed issue,” but which specific metric (TTFB, DOM content loaded, LCP, or a render-blocking script) on which specific URL, template, or scope.	The specific change at the right level (server config, template, page, or CDN rule), precise enough that two developers would build the same fix.
Client or exec reporting	The specific outcome you were hired to move, not the activity you performed.	The specific action that produced the result, traceable to a date and a change, not a general trend.
AI-prompted (vibe-coded) tool	The specific capability needed, precise enough that “looks like it works” and “works” would produce different answers.	What was actually built, and whether it matches that capability or something adjacent to it.

Role	Verification, stated exactly	Revenue or margin tie
Developer, or the person specifying the build	The test you’ll personally run against the live system, not the status update you’ll accept.	What this component’s absence or failure costs, in dollars, hours, or client trust, if never verified.
Technical SEO finding	The tool, metric, threshold, and recheck date, so “fixed” has a number attached, not a feeling.	The traffic, conversion, or crawl-budget cost this issue is actually causing, priced out, not assumed because the tool flagged it red.
Client or exec reporting	The source, in the client’s own analytics or accounting, not your dashboard, that confirms it happened.	What this is worth in the client’s own numbers: their conversion rate and margin, not an industry benchmark.
AI-prompted (vibe-coded) tool	The test run against real conditions, real data, and real load, not the demo path, reviewed by someone who can catch a failure.	What it costs if this fails in production: refunds, downtime, security exposure, lost trust, and whether that’s acceptable for something nobody verified.

When you’re reporting to a client, verification ultimately has to answer the question that matters most: Show me the ROI.

The industry itself is split on whether ROI is even the right frame for SEO. But the discomfort with ROI as a metric usually comes from not having verified the connection between the work and the outcome in the first place, not from ROI being the wrong question.

To the average executive, unverified SEO looks exactly like vibe coding that didn’t produce the promised result, indistinguishable from work that was never actually checked. Closing that gap means tying every claim to a number that connects to money:

• Instead of “we improved your ranking for 40 keywords,” show the traffic delta on those pages, then carry it one step further: What did those visits convert to in dollars, using the client’s own conversion rate and order value?
• Instead of “your technical issues are resolved,” show the re-run crawl and pair it with the revenue that was actually at risk.
• Instead of “your AI visibility improved,” show the captured citation and connect it to the bookings or form fills that came through the tracked link, priced the way a paid channel would be.
• Instead of a report full of activity, tie every line to the dollar or lead it produced, the same way a good SEO reporting framework should already be structured to do, and say plainly when a line produced nothing. An honest zero, priced out, builds more trust than 10 vague wins.

The verification isn’t complete until it’s converted into the same currency the executive is asking about: dollars in versus dollars out. That’s the literal answer to “show me the ROI”: Decide in advance what evidence would prove the money was made, then go get it.

Dig deeper: How vibe coding is changing search marketing workflows

Make ‘done’ something you can prove

Write specifications that describe evidence, not just outcomes. For every component, define the exact test that would prove it exists and works before calling it done.

Run that verification yourself, on a cadence, not just once at launch. When a gap appears, treat it as data about where the specification left room for drift, not as a failure of the person who implemented it.

The shift is from “Did you build what I asked for?” to “Show me the proof, in a form I defined in advance.” That doesn’t require replacing developers with AI or finding some mythical better class of developer. It requires writing specifications that can’t quietly go unbuilt without someone knowing.

Whether you’re handing work to a developer, an agency, or an AI tool, the fix isn’t simply finding better people. It’s tightening what you hand them in the first place.