List of Project/Product you shouldn't build completely with AI
Here is the thing nobody says out loud in the vibe coding community.
A working demo is not a secure application. An application that passes your own tests is not necessarily safe to deploy. And a product built in a weekend using Claude, Lovable, or Cursor can look identical to a properly engineered system right up until the moment it isn't.
This article is not an attack on AI coding tools. Used well, they are genuinely useful for prototyping, scaffolding, generating tests, writing documentation, and helping experienced engineers move faster. The problem is a specific and increasingly common assumption: that because an AI-generated application runs, because users can log in, because data gets saved to the database, the application is ready to handle real money, real health records, real identity documents, or real critical infrastructure.
That assumption is wrong in ways that are not immediately visible and sometimes not visible at all until an attacker finds the gap.
The Number Behind the Concern
Veracode tested over 100 large language models on security-sensitive coding tasks and found that 45% of AI-generated code samples introduce OWASP Top 10 vulnerabilities, with Java showing a particularly high failure rate exceeding 70%.
CVSS 7.0+ vulnerabilities appeared 2.5x more often in AI-generated code than in human-written code. By June 2025, AI-generated code was adding more than 10,000 new security findings per month across studied repositories, a 10x jump from December 2024.
AI-assisted developers produce commits at three to four times the rate of their peers but introduce security findings at 10x the rate, creating a security debt that accumulates faster than it can be reviewed.
These are not edge cases. They are the baseline. A vibe-coded application that works perfectly in your testing environment has a roughly even chance of containing a serious security vulnerability that your testing never surfaced.
The reason is not that AI is careless. It is that AI models are trained on repositories containing both secure and insecure code patterns and reproduce them with equal confidence. If an insecure pattern, such as string-concatenated SQL queries, appears frequently in the training corpus, the model will reproduce it. The model does not know the difference between the patterns a security engineer would flag and the patterns they would approve. It knows what code looks like, not what secure code requires.
The Core Technical Problem: Working Is Not the Same as Secure
Before covering specific project categories, you need to understand the underlying failure modes clearly. These apply across every category below.
Authentication is not authorization. An application can correctly verify that a user is who they say they are and still let that user read another user's records. These are different controls. AI-generated code consistently conflates them. A login system that works perfectly can coexist with an API endpoint that returns any user's data when given that user's ID in the URL, with no check that the requesting user owns that record. This is called an Insecure Direct Object Reference (IDOR) and it is one of the most common vulnerabilities in AI-generated applications.
A database hosted by a reputable provider does not protect against application-layer flaws. Supabase, Firebase, and Neon are good products. They handle infrastructure security. They do not automatically correct flawed application logic or missing authorization checks in your code. A Supabase Row Level Security policy that was generated incorrectly can expose every user's data to every other user even though Supabase itself is working exactly as designed.
Passing your tests does not mean the application is secure. Security vulnerabilities are, by definition, cases that normal usage does not encounter. A test suite that verifies that users can log in, create records, and read their own data will pass perfectly on an application that also allows users to read anyone else's data by manipulating a single parameter.
The AI fixed the bug you showed it. That is not the same as fixing the vulnerability class. When you report a specific security issue to an AI tool, it typically fixes the specific instance you described. It does not audit every other place in the codebase where the same pattern appears.
Approximately 20% of AI-generated code samples reference packages that do not exist, a predictable hallucination pattern that attackers exploit through slopsquatting, registering the hallucinated names as malicious packages before developers install them.
Projects You Should Not Entrust Entirely to AI
1. Banking Applications and Digital Wallets
What they are: Applications that store, move, or manage money on behalf of users.
The specific risks: Transaction integrity failures where a transfer is debited from one account but never credited to another. Race conditions where two simultaneous requests both succeed against a balance that can only cover one. Authorization flaws where a user can initiate a transfer from an account they do not own. Reconciliation errors where displayed balances diverge from actual balances. Duplicate transaction processing where a retried request charges twice.
Misconfigured authentication flows frequently appear in generated backend logic, and in a banking application, a misconfigured flow does not just let someone access the wrong screen. It gives them access to someone else's money.
Banking applications require formal transaction modeling, atomicity guarantees, idempotency keys on payment operations, comprehensive reconciliation processes, penetration testing by qualified security engineers, and compliance with financial regulations that vary by jurisdiction. None of these come from a prompt.
AI is appropriate for: Generating boilerplate UI components, writing unit test scaffolding, drafting documentation. Not for: Core transaction logic, balance management, or anything touching actual fund movement.
2. Healthcare and Hospital Management Systems
What they are: Systems that store patient records, schedule clinical care, manage prescriptions, or integrate with medical devices.
The specific risks: Unauthorized access to patient records is not just a privacy violation. It is a HIPAA violation (in the US) or equivalent regulatory breach in other jurisdictions, carrying significant fines and legal consequences. An authorization flaw that exposes one patient's records to another patient could reveal HIV status, psychiatric history, medication details, or genetic information with life-altering consequences. An integrity failure in a medication management system could result in incorrect dosing or missed treatments.
AI-generated systems in this category need HIPAA Business Associate Agreements with every service provider, audit logging of all data access, strict access control by role and clinical relationship, and formal validation before deployment. A vibe-coded patient management system deployed without these controls creates liability for every breach, regardless of intent.
AI is appropriate for: Internal administrative tools with no patient data, generating documentation templates, writing test cases for non-clinical modules.
3. Payment Processors and Financial Transaction Infrastructure
What they are: Systems that handle card processing, ACH transfers, or payment routing between parties.
The specific risks: PCI DSS (Payment Card Industry Data Security Standard) compliance is mandatory for systems that handle cardholder data. A single AI-generated endpoint that inadvertently logs a card number or stores it without proper encryption creates PCI scope and liability. Beyond compliance, the attack surface on payment infrastructure is high because the financial incentive for attackers is immediate and direct.
Use Stripe, Paddle, or Dodo Payments as your payment processor. These are systems engineered by specialists with dedicated security teams. The mistake is building custom payment infrastructure with AI tools to avoid the per-transaction fee. The cost of a breach in this category is orders of magnitude higher than processor fees.
AI is appropriate for: Integrating with established payment processors through their official SDKs, generating webhook handler scaffolding, writing idempotency logic with human review.
4. KYC, Identity Verification, and Biometric Systems
What they are: Systems that verify user identity against government documents, capture biometric data, or screen against financial crime watchlists.
The specific risks: Identity verification systems handle the most sensitive category of personal data: government ID numbers, passport scans, facial biometrics, and financial history. An authorization flaw that exposes this data does not just create a privacy violation. It creates the data set needed for identity theft at scale.
KYC systems also carry regulatory obligations under anti-money-laundering laws in most jurisdictions. Deploying a vibe-coded KYC system without legal review of its compliance with local regulations creates regulatory exposure that can close a business.
AI is appropriate for: Integrating with established KYC providers (Onfido, Jumio, Veriff) via their official APIs. Not for: Building custom identity verification logic, storing biometric data, or making compliance determinations.
5. Cryptocurrency Wallets and Exchanges
What they are: Applications that store private keys, manage cryptocurrency balances, or facilitate trading between users.
The specific risks: A private key management error in a cryptocurrency wallet is catastrophic and permanent. Unlike a bank, there is no dispute resolution, no fraud reversal, and no regulatory protection for cryptocurrency losses. A single vulnerability in key generation, storage, or transaction signing can result in total loss of user funds with no recovery path.
Cryptocurrency exchange logic also requires formally verified matching engines, protection against wash trading, prevention of front-running, and careful management of hot and cold wallet separation. These are engineering problems that have been solved by specialist teams over years, not problems that can be generated from a prompt.
AI is appropriate for: Building read-only portfolio tracking tools that do not hold keys, generating UI for established wallet providers' APIs.
6. Stock Trading and Investment Platforms
What they are: Systems that execute trades, manage investment portfolios, or provide access to financial markets on behalf of clients.
The specific risks: Financial regulators in most jurisdictions require that trading platforms are operated by licensed entities and meet specific technical standards. Bugs in trading logic can execute incorrect orders, expose users to unintended positions, or in high-frequency contexts, contribute to market disruption. An authorization flaw that allows one user to view or modify another user's portfolio is not just a privacy issue. It is securities fraud.
AI is appropriate for: Generating reporting views with no trading capability, building interfaces that display market data from regulated data providers.
7. Large-Scale Multi-Tenant SaaS Databases
What they are: Applications serving multiple organizations from a shared database, where each organization's data must be completely isolated from every other organization's.
The specific risks: This is one of the most common failure modes in AI-generated code. Multi-tenancy requires that every database query, every API response, and every background job is filtered by the authenticated user's organization. A single missing WHERE clause, a single missing Row Level Security policy, or a single background job that processes records for all organizations exposes every customer's data to every other customer.
41% of AI-generated backend code includes overly broad permission settings, increasing attack surfaces. In a multi-tenant system, overly broad permission settings mean tenant data isolation fails silently until a customer notices they can see records that belong to a different organization.
AI is appropriate for: Generating the structural scaffolding of tenant isolation with mandatory human review of every data access pattern, writing test cases for tenant isolation, generating RLS policy templates that a qualified engineer then audits.
8. Enterprise HR and Payroll Systems
What they are: Systems that store employee compensation, tax information, performance records, and personal data, and that calculate and process payroll.
The specific risks: Payroll calculation errors are not just technical failures. They are employment law violations that can result in regulatory penalties. An authorization flaw that exposes salary information across an organization creates significant legal exposure and lasting internal damage. Payroll systems also integrate with tax authorities and banking systems, meaning errors propagate beyond the application.
AI is appropriate for: Generating reporting templates for internal review, writing test cases for calculation logic that a qualified payroll specialist then validates.
9. Election and Voting Infrastructure
What they are: Systems that record, count, or report votes in official elections.
This category requires no nuance. Official voting infrastructure must meet formal security requirements, undergo independent auditing, maintain verifiable paper trails in most jurisdictions, and be operated by qualified election administrators under legal oversight. No AI-generated code belongs in this category without formal security evaluation.
10. Police, Court, and Criminal-Record Databases
What they are: Law enforcement case management systems, criminal history databases, evidence management platforms, and court document systems.
The specific risks: An authorization flaw in a criminal-record database that allows a defendant to access their own active investigation record, or allows one law enforcement agency to access another's protected investigative files, can compromise investigations and endanger people. An integrity failure in evidence management creates chain-of-custody problems that can affect criminal proceedings.
These systems are also subject to significant legal requirements around data access, retention, and disclosure that vary by jurisdiction and cannot be inferred from a prompt.
11. Critical Infrastructure and Industrial Control Systems
What they are: Software that controls power grids, water treatment facilities, gas pipelines, manufacturing equipment, and other physical infrastructure.
The specific risks: A software failure in critical infrastructure is not a user experience problem. It is a physical-world safety problem. The consequences of a security vulnerability in a water treatment control system or an electrical grid management system can affect thousands or millions of people.
CISA's secure-by-design guidance specifically calls out critical infrastructure as requiring formal security requirements from the earliest stages of system design, not as a retrofit after deployment. AI-generated code in this category without formal safety validation creates unacceptable physical risk.
12. Medical Devices and Clinical Diagnostic Software
What they are: Software embedded in or connected to medical devices, or software that produces clinical outputs used in diagnosis or treatment.
The specific risks: In most jurisdictions, software that qualifies as a medical device is regulated by health authorities (FDA in the US, MDR in the EU). Deploying unvalidated AI-generated software in a regulated medical device context is a regulatory violation independent of whether the software works correctly. Clinical diagnostic software that produces incorrect outputs can directly harm patients.
13. Password Managers and Secrets Vaults
What they are: Applications that store and manage user credentials, API keys, and other sensitive secrets.
The specific risks: A password manager is a single point of failure for every credential a user stores. An encryption implementation error, a key management flaw, or an authorization vulnerability in a vibe-coded password manager does not just expose one password. It exposes all of them. The cryptographic requirements for secrets storage are specific and unforgiving. Using the wrong algorithm, the wrong key derivation function, or the wrong iteration count creates vulnerabilities that cannot be detected through functional testing.
Use an established secrets manager (1Password, Bitwarden, HashiCorp Vault) rather than building one with AI tools. The engineering that went into those products represents years of cryptographic expertise that cannot be replicated in a prompt.
14. Child Protection and Social-Services Databases
What they are: Systems used by child protective services, social workers, foster care systems, or similar agencies to manage cases involving minors.
The specific risks: These systems contain some of the most sensitive personal information that exists: records of abuse, neglect, placements, family histories, and contact restrictions. An authorization flaw that exposes this information to an unauthorized party can endanger children directly. An integrity failure that corrupts placement or contact-restriction records can have immediate physical safety consequences.
15. Insurance Claims and Credit-Scoring Systems
What they are: Systems that make or inform financial decisions about individuals based on their personal data.
The specific risks: Credit scoring and insurance claims systems are subject to anti-discrimination laws in most jurisdictions. An AI-generated scoring model that inadvertently uses proxies for protected characteristics creates regulatory and legal exposure that is difficult to detect and expensive to remediate. These systems also require explainability for their decisions under various regulatory frameworks, a requirement that an AI-generated black-box scoring function typically cannot meet.
16. AI Agents With Access to Privileged Company Systems
What they are: Autonomous AI agents that have been given credentials or permissions to act within company systems on behalf of users or the organization.
The specific risks: The OWASP Top 10 for Agentic Applications 2026 identifies prompt injection as a critical risk specific to AI coding agents. An AI agent with access to your email, your file systems, your code repositories, or your internal databases is not just a useful tool. It is an attack surface. A prompt injection vulnerability in an agent that has permission to send emails on your behalf can be exploited to exfiltrate information or take actions that appear to come from a legitimate user.
AI agents with privileged access require explicit permission scoping, audit logging of all actions, human approval gates for irreversible operations, and careful review of every data access pattern. Deploying an AI agent with broad permissions and no oversight is one of the highest-risk configurations in the current threat landscape.
The Dangerous Assumptions Behind Vibe Coding Failures
Several beliefs lead founders to deploy vibe-coded applications in categories where they should not. Each one is understandable and each one is wrong.
"The app works, so the code must be good." Working code and secure code are not the same thing. Security vulnerabilities by definition involve inputs and patterns that normal usage does not produce. An application that handles every test case correctly can simultaneously be exploitable in ways your testing never approached.
"The AI added authentication, so user data is secure." Authentication tells you who someone is. It does not control what they can access. An application with working authentication but missing authorization checks lets any authenticated user access any other user's data.
"The database is hosted by a reputable provider, so the application cannot leak data." Cloud database providers secure the infrastructure. They cannot secure your application logic. A Supabase Row Level Security policy that was generated incorrectly exposes data regardless of Supabase's own security posture.
"The AI fixed the bug, so the vulnerability is gone." AI tools fix the specific issue you describe. They do not audit every other instance of the same pattern in the codebase.
What You Can Safely Build With AI Tools
The answer is not to avoid AI tools. It is to use them for the right things.
Appropriate for AI-led development:
Marketing landing pages and static websites with no user data
Internal tools handling non-sensitive data with a small, trusted user base
Prototypes and demos used for validation, never deployed with real user data
Documentation generators and content management tools
Development productivity tools and code generators
Simple CRUD applications for personal use
Hobby projects, experiments, and learning exercises
UI components and design systems reviewed by an engineer before production use
Appropriate with engineering oversight:
SaaS applications where a qualified engineer reviews every data access pattern, authorization check, and dependency before deployment
Applications that use established payment processors through official SDKs rather than custom payment logic
Products that delegate identity to established providers (Auth0, Clerk, Supabase Auth) rather than building custom authentication
A Checklist Before Deploying Any AI-Generated Application
Before putting an AI-generated application in front of real users with real data, work through these questions honestly.
Authorization: Has every API endpoint been reviewed to verify it checks that the requesting user has permission to access the specific resource, not just that they are logged in?
Data isolation: If the application serves multiple users or organizations, has every database query been verified to filter results to the authenticated user or organization?
Secrets: Has every configuration file and git commit been reviewed to confirm no credentials, API keys, or tokens are hardcoded or committed?
Dependencies: Have all package dependencies been verified to exist and come from trusted sources?
Input validation: Does the application validate and sanitize user input on the server side, not only on the client?
Error handling: Do error responses return useful information to the user without exposing internal details, stack traces, or system information?
Encryption: Is sensitive data encrypted at rest and in transit? Were the encryption algorithms specified explicitly in prompts and reviewed by someone who understands cryptography?
Logging and monitoring: Can you detect unauthorized access attempts, unusual data access patterns, and application errors in production?
Backup and recovery: Is there a tested recovery process if data is corrupted or the application fails?
Regulatory requirements: Have the legal and regulatory requirements for the data the application handles been identified and confirmed to be met?
If any of these questions cannot be answered confidently, the application is not ready for production.
The Actual Role of AI in Software Development
AI coding assistants increase developer velocity dramatically. That is real and valuable. The right frame is not "should I use AI to build this" but "what is the appropriate human oversight for this application given what it does and what it protects."
A landing page with no user data needs minimal oversight. A payment processing integration with established providers needs an engineer to review the implementation. A multi-tenant SaaS product handling sensitive customer data needs a qualified engineer to audit every authorization boundary. A healthcare system needs formal security review and compliance validation.
AI tools do not change this calculus. They change how fast you can generate the initial code. The review, the testing, the threat modeling, and the architectural judgment required to make that code safe at a given risk level remain human responsibilities.
Building quickly is a feature. Shipping something insecure into a sensitive context because it was quick to build is not a feature. It is a liability.
The founders who use AI tools well are the ones who treat the generated code as a starting point for engineering rather than a finished product, who know which categories require human expertise that no current AI tool can substitute for, and who are honest with themselves about which category the thing they are building falls into.
That honesty is the part no AI tool can provide for you.
Sources referenced: Veracode 2025 GenAI Code Security Report; OWASP Top 10 for LLM Applications 2025; OWASP Top 10 for Agentic Applications 2026; Cloud Security Alliance / Endor Labs AI coding security analysis 2026; Cycode AI Security Vulnerabilities 2026; CSA Research Note on AI-Generated Code Vulnerability Surge 2026; CISA Secure-by-Design Guidance.