Vibe-Coded Finance Apps Are a Security Problem

There is nothing inherently wrong with using AI to write software.

Professional engineers use AI coding tools every day. They can accelerate boilerplate, documentation, refactoring, test generation, debugging, and exploration.

The problem starts when generating code is mistaken for engineering software.

That distinction matters everywhere. It matters considerably more when the application handles money.

A working demo is not the same thing as a secure financial system.

What “vibe coding” actually means

The term “vibe coding” is commonly used for a development style in which someone describes what they want in natural language, lets an AI coding agent generate much of the implementation, and validates the result primarily by running the application rather than understanding and reviewing the generated code.

There is nothing wrong with experimentation.

The problem is when that workflow becomes the entire engineering process.

A recent state-of-the-art review describes vibe coding in essentially these terms and finds that early evidence shows uneven task-level capability, weak fault detection, hard-to-audit documentation, and security problems in deployed applications. ¹

That does not mean “AI-written code is always insecure.”

It means:

AI generation does not remove the need for engineering judgment.

Why finance is different

Imagine a vibe-coded todo application.

A bug might make a task disappear.

That’s frustrating.

Now imagine a finance application with the same development philosophy.

A bug could cause:

• one household to see another household’s transactions;
• a user to access another person’s account;
• a private budget to become visible;
• an expense split to be calculated incorrectly;
• credentials to be exposed;
• sensitive data to appear in logs;
• or an authorization check to be missing.

Those aren’t cosmetic defects.

They’re failures of the system’s security model.

A pretty dashboard proves almost nothing

Modern AI coding tools can generate an impressive interface extremely quickly.

You can ask for:

Build a beautiful budgeting application with authentication, household sharing, expense splitting, charts and goals.

The result may contain all the visible pieces.

But serious engineering questions remain:

• Who can access each record?
• How is household membership enforced?
• Can a user manipulate an object identifier and retrieve another household’s data?
• What happens when membership changes?
• Are database constraints enforcing financial invariants?
• How are secrets stored?
• How are migrations handled?
• What happens during concurrent updates?
• How are backups restored?
• What gets logged?
• How are dependencies patched?
• What happens after a security incident?

A screenshot cannot answer those questions.

Recent research is already finding the gap

A 2026 systematic study of real-world vibe-coded applications found that security vulnerabilities can arise not only from insecure generated code but also from flawed architecture. The authors built a corpus of applications generated with popular AI agents and combined automated analysis with human validation. ²

A separate 2025 benchmark found that AI agents can produce code that is functionally correct while still containing security vulnerabilities, and concluded that current agents struggle to produce software that is both correct and secure. ³

A 2026 twin-prompt study is particularly instructive: adding explicit security requirements reduced the number and severity of confirmed findings in a small set of generated applications, but the authors also found a severe issue through manual testing. They explicitly caution that the study is preliminary because the corpus is small. ⁴

That last point is important.

The research does not prove that every AI-generated application is dangerous.

It demonstrates something more useful:

Security does not reliably emerge just because an application works or because a prompt mentions security.

AI-assisted engineering is different

There is an important distinction between these two workflows.

AI-assisted engineering

Requirements
    ↓
Architecture
    ↓
Threat model
    ↓
AI-assisted implementation
    ↓
Code review
    ↓
Automated tests
    ↓
Security testing
    ↓
Deployment
    ↓
Monitoring

Vibe-only development

"Build me a finance app"
          ↓
        AI
          ↓
     Looks good
          ↓
        Ship

The first uses AI as a tool. This is the approach Household Saga uses⁵.

The second uses AI as a substitute for much of the engineering process.

That is the line we care about.

Financial software needs an engineering backbone

Consider household expense sharing.

A user pays €300 for a shared expense. The household uses a 60/40 split.

The application needs to represent:

Person A: €180
Person B: €120

That sounds trivial.

But then consider:

• What if the currency has fractional-cent rules?
• What if the expense is edited?
• What if one member leaves the household?
• What if two people edit it simultaneously?
• What if the settlement is already recorded?
• What if the same request is submitted twice?
• What if a user tampers with the split percentages?
• What if a user can access an expense by changing its ID?

The arithmetic is easy.

The engineering around the arithmetic is not.

Security is not a feature you bolt on at the end

NIST’s Secure Software Development Framework guidance for generative AI emphasizes secure development practices throughout the software-development lifecycle. ⁵

That aligns with the broader lesson from security research:

Security is a system property.

It comes from architecture, permissions, validation, testing, monitoring, dependency management, deployment controls, and operational discipline.

An AI-generated authentication page is not authentication architecture.

An AI-generated “private dashboard” is not proof of data isolation.

A green checkmark from a code assistant is not a penetration test.

Household finance makes authorization especially important

A household finance application has an unusual privacy boundary.

People may want to share:

• rent;
• groceries;
• utilities;
• vacations;
• subscriptions.

But they may not want to share:

• salary;
• personal savings;
• personal purchases;
• personal financial goals.

That means “shared household” cannot simply mean “everyone sees everything.”

Household Saga is built around this distinction: personal budgets remain personal while shared expenses and household goals can be managed collaboratively. ⁶

That requires explicit access boundaries.

And access boundaries require engineering.

The right conclusion isn’t “don’t use AI”

The wrong lesson from vibe-coding research would be:

AI coding is bad.

The more useful conclusion is:

AI coding is powerful enough that engineering discipline matters more, not less.

AI can help experienced teams move faster.

It can help prototype ideas.

It can help write tests.

It can help explain unfamiliar code.

It can help automate repetitive work.

But someone still needs to be responsible for:

• architecture;
• threat modeling;
• security;
• data integrity;
• testing;
• operations;
• and the consequences of failure.

Especially when money is involved

If a generated marketing website has a bug, you fix it.

If a financial system has an authorization bug, you may have a breach.

If a game has an incorrect score, users complain.

If a budgeting system calculates a balance incorrectly, people can make real decisions based on false information.

The consequences are different.

That means the engineering standard should be different too.

What we believe

At Household Saga, we are enthusiastic about AI.

We use it where it makes sense.

But we don’t believe that “AI-powered” is a substitute for an engineering foundation.

Our approach is deliberately boring in the places where boring is good:

• structured financial data;
• explicit permissions;
• deterministic calculations;
• conventional application logic;
• privacy-conscious design;
• testing and validation;
• and AI as an optional assistance layer.

The AI can help.

The system still has to be engineered.

The takeaway

The most dangerous phrase in financial software may not be:

This app uses AI.

It may be:

Don’t worry, the AI built it.

AI-assisted development can be a tremendous productivity tool.

But if you are trusting an application with your financial life, ask a harder question:

Who engineered the parts that aren’t visible in the demo?

Read more

• AI Is Not Your Financial Advisor: The Limits of LLMs for Budgeting

References