The business risks of vibe coding & why spec-driven development is the answer

Why AI does not generate secure code

AI tools generate insecure code for a number of reasons. One of the major reasons is that the training data - the data that the AI is learning from in order to produce its outputs - may reference instances of code that are flawed.

AI code generation may not comply with a company’s internal coding practices, producing code that is consistent with the rest of the development team’s coding style. The code line may also feature security protocols and measures from outdated software applications, meaning that threat actors will have an easier time breaching the software.

Furthermore, it may import code from third-party libraries and frameworks that contain unresolved security vulnerabilities and compatibility issues, which will make the code incompatible with a full-scale production environment.

Five vulnerability classes most likely to reach production

Below are the most critical vulnerabilities to watch out for. They are in order of most severe to least severe.

1. Unsanitized input: Allows users to perform actions that directly or indirectly expose the software application to harm. Input sanitation cleans and filters harmful data before it reaches your server, database, and browser inputs.
2. Broken access control: When an authorization system fails to correctly determine who can and who cannot access a system, it allows threat actors to access, modify, and steal sensitive data within personal, business, and enterprise accounts.
3. Insecure data handling: When sensitive data, such as personally identifiable information (PII), tokens, and login information, is transmitted between and stored in systems without proper encryption measures.
4. Hardcoded credentials: When raw login details, such as passwords, usernames, and SSH keys, are embedded directly into the software’s source code, leaving it prone to malicious modification and theft especially when software versions are shared between developers, including Industrial Control Systems (ICS’s) and Internet of Things (IoT) environments.
5. Vulnerable dependencies: When AI-generated code features third-party libraries and frameworks without verifying the quality of the security measures present in them.

What the evidence shows

Research shows that AI-generated code is prone to producing more bugs and errors than human-written code. A December 2025 report from CodeRabbit analyzed 470 open-source GitHub pull requests. AI-generated code produced 1.7 times more issues than human-written code, along with 2.74 times more security vulnerabilities and 75% more logic and correctness issues.

AI-generated code produced through vibe coding techniques poses real-world risks, too. The vibe coding platform Loveable, valued at $6.6 billion with over 8 million users, was hacked and its sensitive information stolen in early 2026. The cause of the hack was due to a Broken Object Level Authorization (BOLA) flaw, which was flagged on March 3rd, 2026, but ignored by the company for 48 days before it took action.

The regulatory multiplier: When security failures become legal events

For businesses that operate in industries that handle high volumes of sensitive user information, such as finance, healthcare, and government, the risk of deploying AI-generated code is enormous. Such businesses must comply with regional data privacy and protection laws, including the GDPR in Europe and HIPAA in the United States. Security flaws in these industries pose significant financial and reputation risks - far beyond those of most other industries.

When operating in these high-risk industries, it’s important to consider the pros and cons of working with AI-generated code. It’s also important to partner with the right software development team, one that can deploy AI-generated code safely, efficiently, and in compliance with client guidelines and regulations.

How vibe coding accumulates debt faster

Vibe coding accumulates technical debt faster than human-written code because it prioritizes speed over quality.

Each time a developer pushes AI-generated code into production, they risk introducing code that lacks a contextual, architectural understanding of the environment in which the code will exist. This increases the risk of the code being incompatible and potentially dangerous to use in a real-world setting.

AI-generated code also typically does not come with comments or explanations on how the code was created. This means the onus falls on the development team to figure out the logic behind the code, resulting in a lot of time spent on guesswork.

How the black box codebase is a business continuity risk

A ‘black box codebase’ is a codebase that has been abandoned by its original developer. This usually happens when the developer who produced the code moves on to something else, as opposed to staying on board to maintain the code they created. This makes the resulting code difficult to maintain, as whoever is brought on board to maintain it is responsible for figuring out the logic behind the code.

And, if the original developer used vibe coding to produce the code, and if they left no comments and explanations behind, then the new team member must work backward in order to understand the logic behind the code.

As a result, the time and resources spent on understanding the context behind the AI-generated code can, in theory, be more expensive than having manually-written code with comments and explanations.

Developer skill atrophy: the long-term HR risk

As developers spend more time using AI to generate code, they gradually lose the ability to analyze and problem-solve the code they generate. This means they become less efficient at maintaining the very thing they build. This has direct implications on not just how development teams approach their work, but also on how hiring managers hire, train, and retain new talent.

IP and licensing risk with no clear legal answer

Below are just some of the many legal implications to consider when deploying AI-generated code into your systems.

Invisible compliance failures that remain hidden until audits

Companies that operate in regulated industries are required to comply with strict data privacy and security laws. These laws influence how these companies must collect, store, and dispose of sensitive data. Failure to do so can result in significant non-compliance fines and penalties. For example, minor GDPR violations may incur a maximum penalty of EUR 10 million or 2% of global annual turnover, whichever is higher.

Product scenarios that AI does not write code for

Below is a list of common business consequences that come with AI code generation in software development. This list ranges from most severe to least severe.

1. Network failure handling: When the AI fails to incorporate graceful degradation and retry logic into its codebase. This hinders the software’s ability to maintain limited functionality even when large portions of the software have been rendered inoperative. It also hinders the ability of a microservices architecture to remain reliable and stable.
2. Concurrent user load: A sudden influx of new users (beyond the initial user limit of the prototype period) can trigger race conditions, resulting in incorrect or unpredictable results due to multiple processes and threads trying to modify the same data at the same time.
3. Adversarial and edge case input: This occurs when the final product, which still contains code used in the prototype stage, is exposed to a real user, one who ends up performing an action that the development team did not anticipate. The result is user and attacker behavior that does not align with what the AI-generated code anticipated.
4. Resource exhaustion: AI-generated code is unable to sufficiently optimize memory usage and queries, resulting in slow loading times and frequent crashes. The problem becomes significantly worse as the data volume grows.
5. Error observability: AI-generated code fails to correctly perform instrument logging when failures occur, resulting in either non-existent or unusable diagnostic information.

The business cost when scaling hits these limits

When scaling hits its limit for software developed with AI-generated software, the following consequences can occur:

• Unpredictable cloud cost spikes: The sudden increase in user growth can lead to more insufficient queries, significantly increasing ongoing cloud hosting costs.
• Increased outage frequency: Outages are more likely to occur at crucial moments during the product’s deployment, including product launches, promotional campaigns, and periods of high press coverage.
• Emergency architecture costs outweigh original development costs: The cost of fixing problems present in the AI-generated code ends up costing more than using human-written code.
• Loss of customer trust: Customers are less likely to trust a company that deploys software in a broken, dangerous, or unsafe state, especially if such a launch leads to a catastrophic event like a major data breach.

Hidden cost stack vibe coding creates downstream

Below is a list, from most severe to least severe, of the hidden risks of the productivity illusion that vibe coding can create.

1. Security remediation: AI-generated code requires more rigorous reviewing and correcting than manually-written code.
2. Test coverage gaps: AI-generated code does not account for specific test cases and suites, of which these test cases must be written after the fact.
3. Debugging unfamiliar logic: In complex systems, developers risk spending more time deciphering AI output than they save generating it. This problem is exacerbated by the fact that AI-generated code usually does not come with comments or documentation.
4. Refactoring and architectural cleanup: AI-generated code must often be cleaned up to ensure compatibility with third-party tools and libraries, as well as complex architectural systems.
5. Onboarding overhead: The cost of training new talent to understand AI-generated code may be higher than having them maintain manually-written code.

Why teams systematically underestimate these costs

If developers using AI-generated code overestimate their own productivity, then it stands to reason that team leaders may be easily fooled by their own teams’ productivity claims. Therefore, project managers must be rigorous when evaluating their team’s performance, ensuring their claimed productivity actually matches their expected output.

What a specification is, and why it cannot be restructured from code

Source: Martin Fowler

A product definition, also known as a product specification, defines what a product must be. It also defines the type of constraints that the product must work with, and the state at which the product is “finished” before any code is written.

A specification cannot be restructured from code. That means the spec can influence the type of code that is produced. But only the spec can capture the business intent, technical requirements, constraints, and acceptance criteria. Therefore, the spec must be preserved as a permanent record.

At Orient Software, we use product specifications to record details like product summaries, business cases, user stories, and personas. These details enable us to accurately define the pain points we’re trying to solve, the challenges we may face along the way, and the audience expectations that we’re aiming to meet and exceed. In doing so, we have an ironclad document, one that we can reference during a project to ensure the final delivery meets your vision.

How to apply spec in a vibe coding workflow

Below is a step-by-step breakdown on how to incorporate spec-driven development into a vibe coding workflow. This involves going deeper than just submitting a vague request for an entire software application or feature. It involves giving the LLM a greater context behind a request, enabling it to deliver an outcome that more accurately meets user needs.

1. Write spec before prompting: Before typing a prompt like “Build X …”, spend at least 30 minutes on a spec outlining what X must do, what it must not do, what constraints apply, and what it means to be complete. This turns the process of submitting prompts from guesswork into calculated building steps.
2. Add the spec to your prompt, giving the AI context: Make the spec a core aspect of the prompt that you submit to the AI. Since the AI is receiving context beyond the surface-level request, it is more likely to generate code that accounts for architectural context, meaning it’ll more likely perform as expected outside of an isolated best-case scenario.
3. Validate output against spec: Instead of guessing whether the output meets the desired expectations, go deeper. Ask, “Does this meet all the spec requirements?”
4. Preserve the spec as a living document: Keep the document secure and easily accessible to those who may need it in the future, such as new developers (who did not generate the original code) who may be brought on to maintain and improve the code. They can then refer to the spec as a means to preserve the code’s original intent and functionality, while enabling them to scale in meaningful ways.

How spec-driven development directly resolves each business risk

Below is a useful table that you can reference to understand how spec-driven development directly solves unique business risks.

The main takeaway from this table is simple: SSD intervenes before generation, focusing on the only point where root cause correction is possible.