Vibe coding, building applications through conversation with AI, can help prototyping. A working demonstration does not establish security or maintainability. Moving into production requires understanding data, permissions and recovery.
I'm not against vibe coding. I'm against the idea that understanding can be skipped. This article is a list of the mistakes I see most often, from clients who arrived with a "finished" app, and from course participants.
A working prototype is not proof of security. Watch for keys in source code, missing server-side validation, open permissions, no version control, blind acceptance of changes and untested backups. The studies below describe specific tests and datasets; they cannot determine the chance that an arbitrary AI-built application is vulnerable. A course can introduce the basics, but secure operation requires ongoing verification.
Why write about this now
Veracode's 2025 study tested over 100 models across four programming languages. 45% of code samples in that evaluation failed security tests. This is not the share of all AI-built applications or the state of every model in 2026.
GitGuardian's 2026 report describes a 3.2% secret-leak rate for Claude Code-assisted commits in 2025, compared with 1.5% across all public GitHub commits in its baseline. The second group is not exclusively human-written code. The association alone does not establish that the tool caused a leak; people decide which changes to accept and publish.
Both findings support reviewing the actual application, not assigning it a universal risk percentage. The seven mistakes below show what to check.
Seven mistakes and how to avoid them
- Keys in code keep secrets on the server and revoke any exposed key.
- Browser-only validation validate inputs on the server.
- Open database enable RLS or Security Rules and test access.
- No version control use Git and verify the rollback procedure.
- Blind acceptance of output read the diff and the error message.
- Prototype straight to production test permissions, abuse limits and backup restoration.
- Nobody can fix it know what runs where and who holds access.
Mistake 1: API keys and passwords right in the code
A secret API key placed in source code can reach a repository or a public browser bundle. Possible misuse depends on its permissions: it may enable paid API requests or access to data.
The right way: keep secrets on the server in a secrets manager or suitably protected environment variables. A variable embedded in a public browser bundle is not secret. Revoke exposed keys, replace them and investigate their use; deleting the file entry is insufficient.
Mistake 2: trusting the client, no server-side validation
Browser form validation helps users but does not replace server checks. Requests can be sent outside the form, with altered prices, roles or record identifiers.
The right way: validate inputs on the trusted server side. Calculate prices from a server catalogue or rule, not the client's submitted value. That catalogue may be a database or a server constant, as illustrated below. Check permission for the specific record on every protected operation.
Worked example: Invalid quantity leaves data unchanged
verified example test
| Test part | Captured value |
|---|---|
| Input | sku: MUG-01; quantity: -2; unitPrice: 1 |
| Server rule | quantity is an integer from 1 to 20 |
| Function response | status: 422 |
| Error | quantity: integer 1..20 |
| Order count after request | 0 |
Isolated validation example; the valid path uses server constant unitPrice: 590, not the input price.
Mistake 3: a database open to the world
Database rules must match the access path. Supabase uses PostgreSQL Row Level Security among its controls; Firebase provides its own Security Rules for supported services. These mechanisms are not interchangeable.
The right way: enable Supabase RLS on API-exposed tables and test anonymous, owner and other-account access. For Firebase, follow its Security Rules. Check privileged server access separately; client rules may not protect administrative SDK operations.
Mistake 4: no version control, "it worked yesterday"
Overwriting a single live version without history makes it harder to identify what caused a failure or return to working code. The number of earlier edits does not predict when a defect will appear.
The right way: use Git, record understandable changes and verify the rollback procedure. Source history does not replace database backups or service recovery. Before schema changes, also address compatibility during rollback.
Worked example: Restore a specific line from history
verified Git example
| Step | Record |
|---|---|
| 0f19e38 | Working enquiry button |
| 3378708 | Accidentally empty label |
| Restore | git restore --source=HEAD~1 -- button.txt |
| Result | buttonLabel=Odeslat poptavku |
The working file was restored; commit history remains. Local Git does not replace an external backup.
Mistake 5: blind acceptance and the "regeneration loop"
Two forms of the same mistake: accepting unchecked code and repeatedly requesting another repair without identifying the cause. Verify new packages, their origin and necessity. Keep reproduction steps and compare changes; regeneration count is not a quality measure.
The right way: small steps, read the diff after each one (at least roughly understand WHAT changed), and on an error, read the message first and send it to the AI with context, not "it doesn't work, fix it".
Blind acceptance versus a controlled approach
- Blind acceptance
- a new package without checking it
- unchecked code
- repeated "fix it" without finding the cause
- Controlled approach
- small steps
- the diff read after each one
- the error message sent to the AI with context
Mistake 6: thoughtless deployment, prototype straight to production
Before public deployment, check abuse controls, API costs, backups and separation of test data. A publicly reachable admin URL is not itself a security defect; the server must prevent unauthorized operations.
The right way: test unauthenticated access and signed-in accounts without the required role, abuse limits and backup restoration. Authentication does not replace authorization. Record results and operating ownership; inspection time depends on the application.
Mistake 7: being unable to fix the app when it breaks
A payment provider outage or external API change can disrupt a business process. Decide who diagnoses it, where logs are kept and how work continues if the repair takes time.
The right way: document what runs where, how data flows and who holds access. Verify that the responsible person can use that documentation to investigate a failure, restore service or obtain the necessary help.
Does this mean "don't do it yourself"? No.
Start with a small internal tool or a prototype using test data. Suitability depends on complexity, risk and available review. No one can promise that any business can replace custom development with one afternoon of AI work.
A vibe coding course can demonstrate the process through a concrete application; see the current offer for scope. I also provide company training. A course or demonstration is not security certification. For an existing tool, arrange a review based on its functions and data.
Summary
Vibe coding can speed up prototyping. Assess security through the actual architecture, permissions, secret handling and verification results. Veracode and GitGuardian used specific samples and methods; their figures cannot be transferred to an arbitrary application or recast as all AI code versus purely human code. Treat the seven areas above as the start of recurring review, not a promise of secure operation after one afternoon.
Sources and links
Primary sources checked on 2 October 2026. Figures describe the historical tests and datasets specified above.
- Veracode: 2025 GenAI Code Security Report, 45% failed samples in a specific evaluation
- GitGuardian: State of Secrets Sprawl 2026, Claude Code-assisted commits versus all public GitHub commits