From Vibe Coding to Production: Why AI-Built Software Starts with CI/CD and Infrastructure as Code

Over the past two years, "vibe coding" has gone from a joke to a business model. Describe what you want, let an AI assistant generate the code, click deploy. The demo works. Investors nod. Customers sign up.

Then reality arrives. A customer's security questionnaire asks where personal data is stored. An auditor asks who approved last Tuesday's database change. Traffic triples and the single database instance falls over. Someone discovers that the entire user table was readable by anyone with a browser.

At AVS IT, we use AI every day to write code faster. But we don't start with the code. We start with the pipeline and the infrastructure that the code will live in. This post explains why.

The vibe-coding trap: fast to build, fragile to run

AI writes code that works. It does not, by default, write code that is secure, auditable or built to scale. Those properties come from the system around the code, and a solo builder working prompt by prompt rarely builds that system.

The numbers back this up. In its 2025 GenAI Code Security Report, Veracode tested over 100 large language models on 80 coding tasks. The generated code contained an OWASP Top 10 vulnerability in 45% of cases, and security quality was not improving as models got better at syntax (Veracode).

The Supabase example

Supabase is an excellent product. It is also the backend that AI app builders such as Lovable and Bolt provision by default, and one that general-purpose AI coding assistants frequently suggest. That popularity makes it the clearest illustration of the problem.

In a typical AI-generated Supabase app, the browser talks directly to the Postgres database using a public "anon" key. There is no backend server checking permissions. Row Level Security (RLS) policies are the entire security model. If RLS is off, or the policies are wrong, the public key opens the whole table.

That is exactly what a 2025 investigation found. In March 2025, Matt Palmer and a colleague at Replit, a Lovable competitor, scanned 1,645 apps listed on Lovable's public showcase. They found 303 exposed endpoints across 170 projects, about 10% of the apps, leaking data such as emails, phone numbers, payment details and API keys (Palmer's statement). The issue was published on 29 May 2025 as CVE-2025-48757, with a CVSS 3.1 score of 9.3 (critical) in the CVE record (NVD).

Lovable disputes the CVE, arguing that each customer is responsible for protecting their own application's data. Palmer argues the platform's defaults produced the problem at scale. Either way, Supabase itself was not breached, and nobody needed a clever exploit. The generated apps simply shipped without access rules that anyone had checked.

What else typically gets skipped

Secrets in the wrong place: API keys committed to the repository or shipped in front-end bundles.
One environment: development, testing and production share the same database, so a test script can wipe real customer data.
Click-ops infrastructure: settings changed by hand in a dashboard, with no record of who changed what or why.
No tests, no review: the AI said it works, the page loaded, ship it.
No exit plan: no backups tested, no idea how to rebuild the stack if the account is lost or compromised.

Our approach: the pipeline comes before the first feature

On every AVS IT development project, the first deliverable is not a screen. It is a repository, a deployment pipeline and infrastructure described as code. Only then do we let AI generate features, and every line it writes flows through that system.

Infrastructure as code from day one

Every database, bucket, network rule, DNS record and access policy is declared in version-controlled files (mainly AWS CDK or Pulumi), never clicked together in a console. This gives our clients three things a vibe-coded app cannot:

Reproducibility: we can rebuild the entire environment from scratch, in another region or another account, in minutes.
Traceability: every infrastructure change is a reviewed commit with an author, a date and a reason.
Consistency: development, staging and production are built from the same definitions, so "it worked on staging" actually means something.

It also changes how we use AI. CDK and Pulumi describe infrastructure in real programming languages such as TypeScript and Python, which AI assistants write well. When the infrastructure is code, AI can propose changes that we review as a diff, instead of a human or an AI quietly flipping switches in a dashboard.

A CI/CD pipeline as the only road to production

Nobody, human or AI, deploys from a laptop. Every change follows the same path:

A developer (often working with an AI assistant) opens a pull request.
Automated checks run: linting, unit and integration tests, type checks.
Security scans run: static analysis, dependency and licence checks, secret detection, infrastructure policy checks.
A human reviews the change and approves it.
The pipeline deploys to staging and runs smoke tests.
Promotion to production is explicit, logged and reversible.

The result is that AI speeds up step 1 without letting anyone skip steps 2 to 6.

Guardrails that make AI-generated code safe to ship

We treat AI output like code from a talented but brand-new team member: fast, often right, never trusted blindly. The guardrails are automated, so they apply to every change without slowing anyone down.

| Risk with AI-generated code | Guardrail in our pipeline | | :------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | | Database tables left publicly readable (the Supabase RLS case) | Schema checks that fail the build if any exposed table lacks RLS or a policy, plus automated tests that try to read data as an anonymous user | | Secrets committed or bundled into the front end | Secret scanning on every commit; secrets stored in a vault and injected at deploy time | | Vulnerable or hallucinated dependencies | Dependency and licence scanning; packages pinned and pulled only from trusted registries | | Insecure code patterns (injection, XSS, weak crypto) | Static analysis on every pull request, with blocking rules for critical findings | | Risky infrastructure changes | Policy-as-code checks on CDK and Pulumi changes before deployment (public buckets, open ports, missing encryption) | | Code nobody understands | Mandatory human review and tests written alongside the feature |

Take the Supabase example. In our setup, the database schema and its RLS policies live in migration files in the repository. A pipeline step checks that every table in an exposed schema has RLS enabled and at least one policy. A test suite then calls the API with the public key and asserts that private data is refused. If an AI assistant forgets RLS, the build goes red long before a customer, or an attacker, notices.

Compliance by design, not by panic

For European businesses, compliance is not optional, and it cannot be bolted on after launch. A pipeline-first approach turns compliance from a scramble before an audit into a by-product of everyday work.

GDPR, data protection by design (Art. 25) and security of processing (Art. 32): encryption, access control and data location are declared in code. If personal data must stay in the EU, the region is fixed in the infrastructure definition, not left to whatever default an AI assistant picked.
NIS2 and supply-chain expectations: more Belgian organisations now fall under NIS2, and they increasingly ask their suppliers to prove their security practices. A documented, automated pipeline is exactly the evidence they look for.
Audit trails for free: every code and infrastructure change has a pull request, a reviewer, test results and a deployment log. When an auditor or a customer's security questionnaire asks "who changed this and when?", the answer is a link, not a guess.
Separation of duties: the person (or AI agent) who writes a change is not the one who approves it for production.
Recoverability: backups and disaster recovery are part of the infrastructure code and tested, so continuity commitments in your contracts are backed by something real.

This matters commercially as much as legally. Enterprise customers will ask for it during procurement, and "we built it quickly with AI" is not an answer that passes a vendor security review.

Built to grow, not just to demo

A prototype only has to work for one user on one afternoon. A product has to work for thousands of users, for years, while the team around it changes. We make a handful of decisions early that are cheap on day one and very expensive to retrofit later.

Environments that mirror each other: separate development, staging and production, built from the same code, so you can test a change against realistic conditions before customers see it.
A real backend where it matters: direct database access from the browser is fine for some use cases, but business rules, multi-tenant isolation and sensitive operations belong behind an API that enforces them.
Scaling designed in: managed and serverless services where they fit, stateless application layers, queues for heavy work, and capacity that grows with load rather than with heroics.
Observability from the start: logs, metrics, alerts and error tracking wired in from the first deployment, so problems are visible before they become incidents.
No lock-in by accident: because everything is code, moving a component to another provider is a planned project, not an archaeology dig.
A team can take over: documentation, tests and a readable history mean the project does not depend on one person, or on one long chat with an AI.

None of this slows AI-assisted development down. It is what lets us keep moving fast in month twelve, when a vibe-coded app is often being rewritten.

Speed and solidity are not a trade-off

AI has made writing code cheap. It has not made running software safely any cheaper, and it has made skipping the hard parts much easier. The real competitive advantage is no longer how fast you can generate an app, but how confidently you can put it in front of customers, auditors and investors.

At AVS IT, we combine both worlds. Our developers use AI assistants every day, and our background as a managed service provider means we think about security, operations and compliance before the first line of code. Every project starts with infrastructure as code and a CI/CD pipeline, so speed never comes at the cost of control.

Already have an AI-built prototype? We can audit it, harden it and move it onto a production-grade pipeline, without starting from zero. Starting something new? Let's design it properly from day one.

Contact our team to talk about your project.