Vibe coding: what happens after the demo?

Originally published in AI in Practice on LinkedIn on 18 October 2026. The build, test counts and release checks below describe my October 2026 implementation and the 17 October release.

“I built it in an afternoon.”

Okay… I’m going to need a bit more info than that. Those AI grifters are rife… 😅

Show me what happens to the information people put into it. Show me what you tested, and what the business owner is supposed to do when something breaks.

For me, the AI Bro Final Boss is the bloke calling it business-ready before he’s checked what he’s handing over. Business owners already under pressure shouldn’t have to become software engineers to work out whether they’ve bought something dependable.

In this edition of AI in Practice, I’m taking you through my own website, jamesmark.com.au, and the AI Decision Brief built into it. That’s the interactive tool where people share information about their business.

I use Claude and Codex to develop and refine that build, using Astro, React and Cloudflare. I’ll show you how I handle the information people submit, what was checked before and after release, and what those checks don’t prove.

And give the platforms some credit. Lovable, Replit, Emergent and Base44 can handle parts of this work. Their security features and defaults differ, so check what the platform handles and what remains your responsibility.

How I use Claude and Codex

I use the tools to extend what I can do and move faster. I still review the work myself and decide what needs closer attention before release. We can work at pace, but getting something out quickly shouldn’t mean skipping checks or leaving the customer to discover the problems.

I retain control of the accounts and release decisions, with credentials kept in protected storage and access limited to what each tool or service requires.

For my site and Decision Brief, Claude and Codex work from shared project files and requirements, with the source code held in GitHub. During the recent website redesign, Claude helped develop the design and brief, and Codex worked through implementation and checks against the existing site.

When a requirement changes, it belongs in those files. Otherwise, one tool can be building something the other has already helped replace.

My changes go through branches and pull requests, giving me a record of what changed and a defined set of changes to review. But putting everything into one enormous pull request makes that review harder.

That concern appears in IBM’s analysis of vibe-coding security risks. The Apiiro research it cites found AI-assisted developers producing more commits but fewer, larger pull requests in its enterprise sample.

I can also use one tool to challenge work produced with the other. Two AI tools agreeing still isn’t a test result.

And check what you give them to follow. Downloaded templates can contain instructions for coding assistants as well as code. Inspect those instructions before letting a tool follow them, particularly anything involving package installation or credentials. IBM’s analysis also discusses malicious instructions hidden in these files.

What happens to an AI Decision Brief submission?

On my site, Astro handles the content pages, React handles interactive features, and Cloudflare serves the application. My AI Decision Brief has a separate private backend and database.

That stack suited this build. I still need to understand its risks, test the controls and maintain it.

Take someone completing my Decision Brief and requesting a copy.

Before sending the full brief, the backend checks that the intended recipient address has been verified. The verification email contains no brief details.

Access to the saved brief has separate controls. Keeping a page out of search results doesn’t establish who is allowed to read it.

Names and email addresses are obvious examples of personal information. The answers someone gives about their business deserve attention too. Private information can end up in URLs, logs or tracking events if those paths haven’t been considered.

For my Decision Brief, I want to understand where people drop off. I don’t need their answers in analytics to measure that.

The implementation builds events from a restricted set of milestones and section names, separately from the questionnaire contents. Analytics requires the relevant consent, and advertising stays off in the questionnaire and results.

Elsewhere on my site, analytics and advertising have separate consent choices. The automated tests cover declining and withdrawing consent, checking the tracking behaviour behind those choices.

What I tested before release

A successful submission is one test case. What happens when the request is malformed, a service times out or someone presses Submit twice?

Can someone retrieve information they shouldn’t have? Does tracking remain off when consent is declined?

For my site’s 17 October release, the recorded results show 281 passing automated tests across the site and Decision Brief, including 32 in the privacy suite. They cover conditions including malformed input, submission failures and consent changes, using synthetic information and mocked services. Customer records shouldn’t become test data because they’re handy.

Those results don’t verify live email delivery. That requires a separate check.

This is where I’d push back on a supplier saying “the AI checked it”. Which checks ran? What did they cover? What happened to the findings?

A dependency scan, a source review and a penetration test examine different things. OWASP’s Application Security Verification Standard provides a framework for deciding which application controls to examine. Referencing that framework doesn’t mean a build has passed a complete assessment against it.

The checking should reflect the consequences. A disposable experiment and a system holding customer records deserve different treatment.

Performance and search on my site

Does my site load promptly on a phone? Do the buttons respond, or is the page moving around while someone tries to use it?

Those are the loading, responsiveness and visual stability concerns measured by Core Web Vitals.

For my website, the work included repeatable mobile and desktop Lighthouse comparisons, followed by changes to image delivery, font loading and layout behaviour.

Those Lighthouse results are lab evidence. I still need field data before claiming a real-user Core Web Vitals pass.

Backend capacity is a separate question. For an application expected to handle concurrent users, I’d also ask for response-time and load-test evidence. My Lighthouse results don’t establish that.

The public pages of my site also have checks for page titles and descriptions, internal links, canonical URLs and redirects. Sitemaps and indexing rules distinguish the pages intended for search from the private parts of the Decision Brief.

My site uses Schema.org structured data to describe the business, services and articles. That markup should match the visible content and be validated for its intended use. As Google explains, valid markup doesn’t guarantee a rich result.

“SEO-ready” needs more behind it than asking an AI to write a meta description.

What I checked after deployment

Before releasing changes to my site or Decision Brief, I review them in a protected preview. That includes mobile layouts, accessibility checks such as keyboard access, and form behaviour.

My GitHub workflow runs build and test checks. Deployment remains a separate decision.

My release record identifies both the deployed version and the previous production version. Recovery still takes planning, especially when stored information changes. Reverting code doesn’t automatically undo a database change.

After release comes production verification testing: checking that the intended version and important behaviour reached the live environment.

For that 17 October release, the recorded checks compared live pages and assets with the reviewed build. They also checked routes, redirects, metadata and security protections, including cache and indexing restrictions around private areas.

Those checks were read-only. They didn’t exercise every signed-in interaction or amount to an exhaustive security assessment. Those limits belong in my release record too.

Performance also warrants monitoring after release, when real usage can reveal problems the preview didn’t expose.

What I still own after release

I remain responsible for maintaining my site and responding when something fails. That includes reviewing access and ensuring retention commitments have working processes behind them. Any control that is still only planned should be recorded as planned.

Managed platforms can take care of parts of that work. Find out which parts, under which settings, and what remains with you or your supplier.

That’s what I want the buying conversation to get into. Ask whoever is delivering the application to explain where information goes, show the evidence for the important checks and identify who owns it after handover.

The same questions apply whether you’re buying a website, a customer portal or an internal tool. A convincing demo gives you something to examine. It doesn’t settle those questions.

Been handed an AI-built tool and unsure what was checked? Get in touch. We can review the evidence and work out what still needs testing before your business depends on it.

You don’t get to call it finished and leave the customer to discover what you skipped.