AI coding agents can produce applications that look finished long before they are ready for production. The failure is not bad code. It is incomplete verification. A working application can pass every visible test while leaving security, persistence, authorization, and deployment properties uninspected. This 15-point checklist forces inspection before any production claim is made.

What Vibe Coding Actually Misses

The verified research does not establish that vibe coding inherently produces bad software. It establishes something more precise.

Empirical research on real-world vibe-coded applications has found recurring security weaknesses including placeholder logic, insufficiently filtered input and secret exposure. The research links these patterns to AI-agent memory loss, locally optimized objectives and incomplete security knowledge. A separate benchmark study found that an agent-generated solution can be functionally correct while still being materially less secure.

That distinction changes how AI-generated applications must be audited.

A page loading successfully does not prove authorization is enforced. A successful database write does not prove persistence will survive redeployment. A passing development preview does not prove production Secrets exist. An article visible in a browser does not prove its canonical URL, robots directives, metadata, structured data or server-visible HTML are correct. A deployed application does not prove it can be rolled back.

The Anti-VibeCoding standard exists to force those questions before "done" becomes a production claim.

The Execution Loop: Inspect Before You Implement

One of the most reliable ways to create new problems with an AI coding agent is to issue implementation instructions before the agent understands the existing architecture.

Tell an agent to "add rate limiting," and it may install a second limiter even though one already exists. Tell it to "switch to PostgreSQL," and it may replace an appropriate datastore for no valid reason. Tell it to "use Next.js for SEO," and it may destroy a working rendering architecture because it interprets the instruction literally.

The correct production loop therefore begins with inspection. For every control, the sequence is:

DETECT what currently exists. CLASSIFY whether the existing implementation is valid, incomplete, inapplicable or unsafe. PRESERVE unrelated working functionality and valid existing architecture. REMEDIATE only confirmed gaps that can be safely corrected. VERIFY the result through tests, builds, runtime checks or direct inspection. REPORT what was found, what changed, what was preserved and what still requires human attention.

That is the difference between using an AI agent as a code generator and using one as a production-audit participant.

The 15-Point Vibe Coding Production Checklist

1. Discoverability and Rendering

For important public pages, verify the canonical URL, robots and index directives, correct HTTP status, page title, meta description, crawlable internal links, article dates, author identity, representative image metadata, XML sitemap inclusion and meaningful public content in the delivered HTML. Google can crawl, render and index JavaScript. The production question is not whether SSR was used. It is whether critical content can be reliably discovered without depending on a fragile client-only rendering path.

2. Semantic HTML and Structured Data

Semantic HTML improves accessibility, maintainability and machine interpretation. For publication surfaces, JSON-LD structured data should include NewsArticle or Article, Organization, Person for authors, headline, description, datePublished, dateModified, author, publisher, mainEntityOfPage, the canonical URL and a representative crawlable image. Valid structured data does not guarantee rich results. OpenGraph and social-card metadata help distribution. They are not ranking mechanisms.

3. Secrets Management

Replit development Secrets and production Secrets are separate concerns. A value available in the development workspace does not automatically exist in the published deployment. A production secrets audit must verify that server secrets never enter the frontend bundle, secrets are not serialized into client-visible state, secrets are not returned through APIs, secrets are not embedded in generated HTML, secrets are not printed to logs, secrets are not committed to version control, and production Secrets are explicitly configured in the published environment. A green development preview is not evidence of a correct production secrets configuration.

4. Input and Output Security

Input validation, output encoding and sanitization solve different problems. They are not interchangeable. For any application receiving external input, inspect schema validation, output encoding, HTML sanitization where rich HTML is accepted, parameterized database queries or safe ORM behavior, CSRF protection where browser credentials auto-attach to state-changing requests, request-body limits, file-upload restrictions where uploads exist, SSRF protections where the server fetches arbitrary URLs, and Content Security Policy. HTML sanitization does not prevent SQL injection. CSRF protection applies conditionally based on how authentication architecture works.

5. Persistent Data Architecture

A production application must not depend on mutable process memory or local runtime files as its authoritative datastore when the deployment model can restart, replace or horizontally scale processes. Replit Autoscale deployments can scale to zero when idle. A production persistence audit must inspect the managed persistent datastore, environment-driven connection configuration, schema migrations, transactions, database constraints, unique indexes, foreign keys where appropriate, connection handling, backup strategy, restore process, retention, deletion behavior and idempotency for repeated writes. Persistence must survive deployment replacement, process restart, horizontal scaling and failure.

6. API and Resource Boundaries

A single universal rate limit is not sufficient for every endpoint. Login endpoints, password-reset endpoints, expensive search queries, write endpoints, image uploads, public reads and costly external API calls carry different costs and threat profiles. Rate and resource controls must be endpoint-aware, cost-aware and identity-aware where authentication exists. If an application runs across multiple instances, an in-memory rate-limit counter on one process does not represent activity on the others. Determine single-instance versus horizontally-scaled deployment before selecting counter storage.

7. Regression and State Completeness

An AI agent can satisfy the current request while silently damaging something that existed before the request entered its active context. TypeScript does not solve this problem. A regression-control layer must include unit tests, integration tests, critical-route end-to-end tests, regression tests, build-time type checking, linting and an explicit no-silent-deletion rule. Every agent modification must begin by identifying what currently works, preserve unrelated functionality, and run the full verification suite after modification. AI agents should never be permitted to interpret "clean this up" as authorization to delete functionality silently.

8. Error Handling and Observability

Users must receive controlled errors that do not expose sensitive implementation detail. Operators must receive enough internal information to diagnose the actual failure. These are different requirements. A production observability layer includes structured logs, request correlation IDs, error tracking, latency metrics, database failure monitoring, authentication events, security events, uptime monitoring, alerts and deployment-version identification. Logs must never become a second secrets database. Do not log passwords, access tokens, API keys, full sensitive payloads or unnecessary personal information.

9. Performance and Caching

Converting everything to WebP is not a production-performance strategy. A stronger audit asks whether media and caching behavior match how the application is actually used. Inspect image sizing, modern image formats, explicit dimensions to reduce layout shift, lazy loading for below-the-fold media, treatment of the primary LCP image, aggressive caching for immutable hashed assets, appropriate caching rules for HTML, appropriate caching rules for APIs, freshness behavior and cache invalidation. An article page, an API response and a hashed JavaScript asset must not automatically share the same caching strategy.

10. Health and Lifecycle Management

Liveness answers whether the process is alive. Readiness answers whether the process can currently serve traffic safely. Startup answers whether initialization has completed. These states must not be collapsed. A temporary database failure should not cause a liveness system to repeatedly restart a process that is otherwise functioning. The application must also handle SIGTERM, SIGINT, graceful shutdown, in-flight requests where appropriate, connection cleanup and dependency degradation.

11. Authentication and Authorization

Authentication answers who the user is. Authorization answers whether that user may perform a specific action. These are different questions. A logged-in user is not automatically permitted to edit an article, delete content, view unpublished material, access another user's object, change roles or invoke administrative actions. For every protected action, the sequence is: authenticate identity, authorize the action, validate object ownership or scope, then execute. Authorization must be enforced server-side. Hidden buttons are not authorization. Frontend route protection is not authorization. A user who cannot see a button may still be able to call the underlying endpoint.

12. Browser Security Policy

HTTP response headers reduce exposure to browser-based attacks. Where relevant, inspect and configure Content-Security-Policy, frame-ancestors or equivalent clickjacking defense, Referrer-Policy, X-Content-Type-Options, permissions controls, HSTS after HTTPS deployment is stable and secure cookie attributes. These values must not be copied blindly from a generic template. Content Security Policy must match the actual assets, domains and third-party services used by the application. An overly permissive CSP defeats its purpose. A blindly restrictive CSP can break the site.

13. Software Supply Chain

Supply-chain security is one of the largest blind spots in AI-generated software. Inspect dependency versions, lockfiles, known vulnerabilities, unused dependencies, untrusted packages, package scripts, build outputs, public .env artifacts, source maps, debug artifacts and generated deployment artifacts. A coding agent must not add an arbitrary package merely because it conveniently solves the current task. Every dependency creates additional attack surface, maintenance burden and upstream trust. The 2026 VibeGuard research prototype was built specifically because AI-built applications can fail not only in source code but also in packaging and artifact hygiene.

14. Backup, Restore, Migration and Rollback

Persistence is not recoverability. A database can survive a restart and still be destroyed by a bad migration, operator error, buggy application logic, account compromise or a destructive deployment. Before an irreversible change goes live, the production team must be able to answer: can the database be restored; has restore behavior actually been tested; can the application version be rolled back; can the migration be rolled back; if rollback is unsafe, is there a forward-fix plan; is the source code in remote version control; can the exact deployed version be identified; is the database schema version identifiable for that deployment. Never deploy an irreversible change without knowing the recovery path first.

15. Automated Testing and Release Verification

This is the final control because it converts the checklist from instructions into evidence. Functional correctness and security correctness are not equivalent in AI-generated software. Before declaring production readiness, require evidence that the production build succeeds, type checks pass, tests pass, critical routes return expected HTTP status codes, public article HTML contains actual article content, robots endpoints resolve, sitemap endpoints resolve, structured data validates, unauthorized requests fail, malformed input is rejected, server secrets are absent from the client bundle, health endpoints behave correctly, error responses do not expose stack traces, database persistence survives a restart or redeploy scenario, production configuration is present, deployment logs have been checked and the live production URL has been tested directly. Do not certify production readiness from the development preview.

The Free Copy-and-Paste Replit Audit Prompt

The following prompt is provided as a public POPR resource. It is written as an audit-and-remediation instruction, not an implementation command. It cannot make an application enterprise secure. It cannot prove the absence of vulnerabilities. It does not replace OWASP ASVS, penetration testing, human code review or professional security assessment for high-risk applications. Its purpose is practical: force the coding agent to inspect the architecture, preserve valid existing systems, identify production-readiness gaps, remediate what it can safely remediate, verify the result and produce evidence before declaring the application finished.

You are conducting a production-readiness audit of this existing application.

Do not assume the current architecture is wrong. Do not rewrite the application merely to satisfy this prompt. Do not replace frameworks, databases, authentication systems, deployment architecture or working infrastructure unless inspection proves the existing implementation cannot satisfy the required production property.

Your execution loop for every control is: DETECT, then CLASSIFY, then PRESERVE, then REMEDIATE, then VERIFY, then REPORT.

For every control: detect what currently exists; classify it as adequate, incomplete, unsafe, not applicable or unable to verify; preserve unrelated working functionality and valid existing architecture; remediate only confirmed gaps that can be safely corrected; verify the result through tests, builds, runtime checks or direct inspection; report what you found, what changed, what was preserved, what passed, what failed and what still requires human attention.

Do not declare this application production-ready until the verification phase is complete. Do not claim that passing this audit proves the absence of vulnerabilities. Do not claim that this audit replaces professional security review, OWASP ASVS verification, penetration testing or human code review.

Apply the fifteen controls from this standard in sequence, completing DETECT through REPORT for each before proceeding to the next.

When finished, return a production-readiness report with these sections: architecture detected; controls already valid and preserved; controls remediated; files changed; dependencies added or removed; security findings; SEO and discovery findings; testing evidence; production deployment evidence; recovery and rollback status; remaining unresolved risks; human-review items; and final status.

Final status must be exactly one of: PRODUCTION READY WITH VERIFIED EVIDENCE, PRODUCTION READY WITH DOCUMENTED LIMITATIONS, or NOT PRODUCTION READY.

Do not use the first status unless every applicable release-gate control has evidence. If something cannot be verified, say UNVERIFIED. Do not infer success from absence of an error.

The POPR Newsroom Case Study: Running the Checklist Live

On August 12, 2026, POPR Technologies ran this checklist against its own production Newsroom at poprnewsroom.com. The following findings are real results from that live audit, not simulated output.

Architecture detected: Eleventy static site generator, deployed on Replit Autoscale, served at poprnewsroom.com with a verified custom domain and HSTS-enforced HTTPS. The production serving layer is a lightweight Node/Express server that builds the Eleventy output and injects HTTP security headers on every response. No database, no user authentication, no API endpoints.

Controls not applicable to this architecture: Control 4 (Input/Output Security), Control 5 (Persistent Data Architecture), Control 6 (API and Resource Boundaries), Control 10 (Health and Lifecycle Management) and Control 11 (Authentication and Authorization) were classified as not applicable. A static publication site has no server-side inputs, no mutable state, no API endpoints and no user identity model. Installing technology to address controls that do not apply to the architecture would be its own form of vibe coding.

Control 1: Discoverability and Rendering. The audit confirmed 60 pages building cleanly, all with correct canonical URLs, robots directives permitting all crawlers, robots.txt and sitemap.xml resolving at the production domain, NewsArticle structured data on all articles and meaningful semantic HTML in all delivered pages. Result: PASS.

Control 2: Structured Data. The build validation suite ran structured data inspection across all 60 pages and confirmed zero errors. NewsArticle, FAQPage and BreadcrumbList schema are in place across the article inventory. Result: PASS.

Control 3: Secrets Management. A pattern scan of the built dist/ directory flagged two files. Both contained the word "password" as editorial content inside published journalism about an AI agent misusing a real organization's credentials during a capture-the-flag evaluation. Neither file contained actual credentials, API keys or session tokens. No .env files, no source maps and no debug artifacts were present in the build output. One genuine finding: a stale .txt.txt artifact from a prior build cycle had persisted in the dist/ directory because the build command did not clean the output directory before rebuilding. The file was removed and the build command was updated to run rm -rf dist before every build, preventing recurrence. Result: PASS after remediation.

Control 7: Regression and State Completeness. The Newsroom build validation suite covers link integrity across all 3,472 internal links, structured data validation across all 60 pages and desk-slug validation across all 32 articles. All three checks passed. Result: PASS.

Control 9: Performance and Caching. All hero images are processed to 300 DPI at 1,536 by 1,024 pixels before publication. Explicit width and height attributes are set on all hero image elements, eliminating layout shift. The primary LCP hero image uses loading="eager" to avoid harmful lazy-loading of the largest contentful element. Result: PASS.

Control 12: Browser Security Policy. The live site confirmed HSTS at max-age=63072000; includeSubDomains, provided by the Replit platform. The initial audit found no Referrer-Policy, Content-Security-Policy, X-Content-Type-Options or X-Frame-Options on production responses. Referrer-Policy and Content-Security-Policy were added via HTML meta http-equiv tags, which browsers honor for these controls. X-Content-Type-Options and X-Frame-Options cannot be enforced from a meta tag and require the HTTP layer. To close this gap, the Newsroom production serving layer was migrated from Replit static hosting to a lightweight Express server that injects X-Content-Type-Options: nosniff and X-Frame-Options: SAMEORIGIN on every HTTP response, including static assets. All five applicable controls are now confirmed on live production responses. Result: PASS.

Control 13: Software Supply Chain. The Newsroom has one development dependency: @11ty/eleventy ^3.0.0, and one production dependency: express ^5.2.1 for the production serving layer. The pnpm lockfile is present and current. No untrusted packages, no unnecessary package scripts, no source maps in the build output and no public environment files were found. Result: PASS.

Control 14: Backup, Restore, Migration and Rollback. The full application state is the source code. A complete rebuild from source at any checkpoint produces an identical site. Replit's checkpoint system provides versioned snapshots of the codebase. No database migrations exist and no irreversible changes require separate rollback planning. The recovery path is: restore to a prior checkpoint, run the build command, deploy. Result: PASS.

Control 15: Release Verification. The production build confirmed clean at 60 pages with zero structured data errors, 3,472 valid internal links and all desk-slug validations passing. The live poprnewsroom.com domain returned HTTP 200 on the homepage, sitemap.xml and robots.txt. Structured data validated at zero errors. No secrets found in the build output. The development preview was not used as the verification target; the published production URL was tested directly. Result: PASS.

Final status of the POPR Newsroom case study: PRODUCTION READY.

All 15 applicable controls passed with verified evidence. The earlier limitation on HTTP security headers was closed by migrating the production serving layer from Replit static hosting to a Node/Express server that injects X-Content-Type-Options and X-Frame-Options on every response.

Why "Verify" Changes the Entire Workflow

An ordinary AI coding request ends when the requested functionality appears.

A production audit does not end there.

If the task says "add authorization," the agent can add authorization code and declare completion. If the task says "prove an unauthorized user cannot perform the protected action," the standard has changed. If the task says "configure production Secrets," the agent can add environment-variable references. If the task says "verify that the deployed production environment contains the required Secrets and that none appear in the public bundle," the standard has changed again.

The same distinction applies throughout the application. Do not merely create a sitemap: resolve the production sitemap. Do not merely create tests: run them. Do not merely create error handling: trigger an error and inspect the public response. Do not merely implement authorization: attempt unauthorized access. Do not merely add structured data: validate the generated structure.

The Anti-VibeCoding standard is therefore not primarily a list of technologies. It is a shift from implementation claims to verification evidence.

The 15-Point Quick Checklist

Before calling an AI-generated application production-ready, verify:

  1. Discoverability and Rendering: public content, status codes, canonicals, robots, sitemap and rendering behavior are correct.
  2. Semantic HTML and Structured Data: semantic architecture and applicable Article, Organization, Person or other schema have been inspected and validated.
  3. Secrets Management: production Secrets are configured, server secrets are absent from client output and credentials follow appropriate separation and least privilege.
  4. Input and Output Security: validation, encoding, sanitization, parameterization, CSRF, SSRF, request limits and CSP are handled where applicable.
  5. Persistent Data Architecture: authoritative state survives restart, deployment replacement, scaling and failure.
  6. API and Resource Boundaries: rate limits and resource controls reflect actual endpoint risk and deployment topology.
  7. Regression and State Completeness: existing behavior is preserved and unit, integration, end-to-end, type and regression checks exist where appropriate.
  8. Error Handling and Observability: errors are safe publicly and useful internally, with monitoring rather than logging alone.
  9. Performance and Caching: images, caching, freshness, invalidation and LCP behavior match the application's real content architecture.
  10. Health and Lifecycle: liveness, readiness, startup and graceful shutdown behavior are separated appropriately.
  11. Authentication and Authorization: identity, permissions and object-level scope are enforced server-side.
  12. Browser Security Policy: appropriate CSP, clickjacking protection, referrer policy, MIME protection, permissions, HSTS and cookie controls are configured.
  13. Software Supply Chain: dependencies, lockfiles, vulnerabilities, source maps, debug artifacts and generated deployment files have been inspected.
  14. Backup, Restore, Migration and Rollback: the team knows how to recover data and code before irreversible changes are deployed.
  15. Automated Testing and Release Verification: production build, tests, security behavior, SEO behavior, persistence and the actual published URL have been verified.

Common Questions

What is vibe coding's main production risk?

The verified evidence does not establish that AI-generated code is inherently bad. The core problem is that coding agents optimize visible task completion while leaving security, persistence, authorization, deployment, recovery, supply-chain and failure-handling properties unverified.

Can an AI-generated solution work correctly and still be insecure?

Yes. The sealed research includes benchmark evidence distinguishing functional correctness from security correctness in agent-generated software. A solution can pass every visible test while still being materially less secure.

Does a React application need SSR to appear in Google?

No. Google can crawl, render and index JavaScript. For critical public content, SSR, SSG or other robust rendering strategies can reduce dependence on client execution, but server-side rendering is not universally mandatory for search indexing.

Do Replit development Secrets automatically become production Secrets?

No. Development and published deployment configuration must be treated separately. Production Secrets must be explicitly configured, and missing production variables can break database connections, authentication and external APIs.

Should a production application use local files or process memory as its authoritative database?

Not where state must survive deployment replacement, restart, scaling and failure. Replit Autoscale deployments can scale to zero when idle, making process-local state unsuitable as durable storage. Persistent authoritative data requires a managed database with environment-driven configuration.

Is one health endpoint enough for production?

Not necessarily. The verified architecture separates liveness, readiness and startup because a process can be alive without being ready to serve traffic. A temporary database outage should not automatically cause a liveness check to restart a functioning process.

Is authentication enough to secure an application?

No. Authentication identifies the user. Authorization determines whether that user may perform a particular action. Protected operations must enforce both server-side. Hidden buttons and frontend route guards are not authorization.

Does a persistent database mean the application has backups?

No. Persistence and recoverability are different production properties. A database can survive a restart and still be destroyed by a bad migration, operator error or destructive deployment. Backup, restoration, migration safety and application rollback require separate verification.

Does passing this checklist prove an application has no vulnerabilities?

No. The checklist is a practical AI-agent production-hardening layer. It does not replace OWASP ASVS, penetration testing, code review or professional security assessment for high-risk systems.

What is the core POPR execution loop for production audits?

DETECT, then CLASSIFY, then PRESERVE, then REMEDIATE, then VERIFY, then REPORT. The agent must inspect before implementing, preserve valid existing architecture, remediate confirmed gaps and produce verification evidence before declaring completion.

Evidence Status

CONFIRMED: Real-world vibe-coded applications exhibit recurring security weaknesses in empirical research, including placeholder logic, insufficiently filtered input and secret exposure.

CONFIRMED: Functionally correct AI-generated software can still be materially less secure, per benchmark research distinguishing the two properties.

CONFIRMED: Google can render JavaScript, meaning client-side React is not automatically invisible to search engines.

CONFIRMED: Server-rendered, statically generated or robust hydrated architectures provide stronger discovery paths for critical content without making server-side rendering universally mandatory.

CONFIRMED: Replit development and published production configuration can differ, including Secrets behavior.

CONFIRMED: Input validation, output protection, server-side authorization, error handling, logging, security headers, supply-chain controls and least privilege are established application-security practices anchored by OWASP ASVS 5.0.

CONFIRMED: Liveness, readiness and startup represent distinct runtime states in established container-orchestration architecture.

CONFIRMED: Persistence and recoverability are different production properties. A durable database does not itself prove backup or restore capability.

CONFIRMED: Release verification must require evidence rather than implementation assertions.

PLAUSIBLE POPR ANALYSIS: AI coding agents disproportionately optimize visible requested functionality over architectural invariants not represented strongly in the active task context.

PLAUSIBLE POPR ANALYSIS: A reusable audit prompt can improve AI-generated application quality by forcing inspection and verification before the agent declares completion.

NOT ESTABLISHED: That one universal prompt makes any application enterprise secure.

NOT ESTABLISHED: That passing this checklist proves the absence of vulnerabilities.

NOT ESTABLISHED: That SSR is mandatory for every SEO-capable website.

NOT ESTABLISHED: That Next.js is required for production websites.

NOT ESTABLISHED: That PostgreSQL is the correct database for every project.

NOT ESTABLISHED: That installing specific libraries automatically makes a security control effective.

POPR Books — Disclosure: the two titles below are published by POPR Books, a POPR Technologies imprint. This Newsroom article and these books share the same subject matter. POPR editorial listed them here on that basis alone.

The AI Founder's Guide to Vibe Coding Production-Ready Apps by Pop Buchanan is a 50-step playbook for turning AI prototypes into secure, App Store-ready and scalable tech companies. It takes the production-readiness standard in this article into the commercial and architectural decisions founders face after verification.

The Replit Gap examines what effort-based billing, Agent modes and Plan mode actually cost the vibe coder in 2026. The 28-page PDF makes Replit's platform economics visible before the costs arrive.

Sources

[1] arXiv. June 2026 empirical research examining vulnerability patterns in real-world vibe-coded applications and AI-generated software.

[2] Separate benchmark research examining functional correctness versus security correctness in AI-agent-generated code.

[3] VibeGuard. 2026 research prototype examining packaging and artifact hygiene in AI-built software.

[4] Google for Developers, Search Central. JavaScript SEO documentation, rendering guidance, Article and NewsArticle structured data documentation and News sitemap guidance.

[5] Replit Documentation. Deployments, production configuration, Secrets, Autoscale behavior and deployment troubleshooting.

[6] Kubernetes Documentation. Liveness, readiness and startup probe architecture.

[7] OWASP Foundation. Application Security Verification Standard 5.0.0. Released May 2025.

[8] OWASP Cheat Sheet Series. Input Validation, Injection Prevention, Cross-Site Request Forgery Prevention, Content Security Policy, Error Handling, Logging, Authorization, Access Control and Software Supply Chain Security guidance.

[9] Next.js Documentation. Metadata API, JSON-LD, image optimization and SSR/SSG rendering architecture.

[10] POPR Technologies Inc. The Anti-VibeCoding Standard: A Production Readiness Audit Protocol for AI-Generated Applications. KG-VIBE-001, Final Sealed, August 12, 2026.