Vibe Coding Has Reached Finance. It Needs a Reconciled Base Layer.

Someone on the FP&A team asked an LLM to build a churn dashboard. Twenty minutes later they had one: a working web app, charts, filters, a clean layout, deployed to an internal URL. Nobody wrote a spec. Nobody filed a ticket with engineering. It just exists now, and by Friday three people are using it to decide which accounts get a renewal call.

This is vibe coding, and it has quietly become normal in finance functions. An analyst describes what they want in plain English, the model writes the app, and the analyst iterates by describing what’s wrong until it looks right. For a one-off chart or a scratch calculation, this is a genuine productivity win: faster than opening a ticket, faster than building a pivot table by hand. The failure mode shows up later, when the same throwaway habit produces a tool other people start trusting.

The logic gets reviewed. The numbers never do

Here is the specific mechanism, and it’s worth being precise about it because “AI tools can be wrong” is too vague to act on. A vibe-coded finance tool has two layers: the logic the LLM writes (the churn formula, the aggregation, the chart) and the numbers that logic runs on (customer records, revenue figures, whatever gets pasted in or piped in from an API). Vibe coding is genuinely decent at the first layer: code that runs, renders, and does roughly what was asked is easy to eyeball-check, because you can see the chart update and it looks plausible.

The second layer gets none of that scrutiny. The LLM doesn’t audit where the input numbers came from; it trusts whatever’s in the CSV, the pasted table, or the API response, the same way it trusts whatever’s in a spreadsheet cell it’s asked to read. If the source figures are stale, half-reconciled, or subtly wrong, the app built on top of them will render that wrong number beautifully. A clean chart is not evidence of a correct number; it’s evidence that the code compiled. Nobody code-reviews the data the way they’d code-review the function, because the data isn’t code, it’s just an input the tool takes on faith.

That’s the exact seam where hallucinated or corrupted numbers enter production: not because the AI invented a figure out of nothing, but because nothing in the pipeline was ever asked to verify the figure it was handed. The tool looks rigorous. The number underneath it was never checked against a source.

A maturity line, and where reliability stops being optional

Not every vibe-coded tool needs the same bar. The risk tracks how far the output travels from the person who built it.

Stage	What it looks like	Who’s exposed if a number is wrong	Reliability requirement
Napkin math	One person, one question, thrown away after	Just the author, who has context	Low: exploration is the point
Reusable internal tool	Shared link, a team checks it weekly	A team that didn’t build it and can’t see the assumptions	Medium: someone will eventually act on a number they didn’t generate
Production workflow	Feeds a report, a forecast, a decision with money attached	Whoever signs off downstream, possibly a board or auditor	High: the number needs a traceable source, not a vibe

Most vibe-coded tools are born at stage one and nobody notices when they cross into stage two. There’s no deployment gate for “three people now check this every Monday.” It just happens, usually because the tool was genuinely useful and word spread. By the time it’s feeding a variance report at stage three, it’s still running on the same untraced inputs it had on day one: the code got more polished, the data underneath never got audited.

The mistake is treating this as a build-quality problem. It isn’t. A beautifully engineered dashboard on top of an unreconciled CSV export is still a beautifully engineered guess.

Why “just rewrite it properly” is the wrong instinct

The instinctive fix, once someone notices a vibe-coded tool has become load-bearing, is to hand it to engineering for a rewrite. That’s usually overkill and it kills the thing that made the tool valuable in the first place: an analyst can describe a change in a sentence and see it live in minutes. Force that through a sprint cycle and the tool stops getting maintained, which is its own kind of risk: now there’s a stale, unmaintained tool people still trust out of habit.

The tool’s logic was never really the problem. It’s readable, it’s fast to change, and the LLM is good at exactly this kind of scaffolding. What’s missing is underneath it: something that guarantees the numbers the tool is fed actually tie back to the ledger, the CRM, or the warehouse, wherever the real figure lives, instead of a snapshot someone exported three weeks ago and forgot about. Swap the data source, not the tool. The vibe-coded app keeps its five-minute iteration loop; the number it’s charting stops being a vibe.

This is a narrower claim than “rebuild your data stack,” and it matters that it stays narrow. Most of what these tools compute (a churn rate, a margin, a cohort split) is a straightforward aggregation once the inputs are trustworthy. The hard part was never the arithmetic. It’s knowing that the input number is the real one and not a stale copy, which is exactly the problem covered in more depth in why a spreadsheet is the wrong foundation for AI finance, the same silent-error mechanism, just with a spreadsheet as the trusted input instead of a vibe-coded app.

What “underneath, not instead of” looks like in practice

Concretely, a vibe-coded tool needs one thing added, not replaced: a query it can make, at build time or at runtime, that returns a number tied to a source instead of whatever’s sitting in a local file. That’s the shape of the fix: not a new UI, not a migration, a connection.

This is where Rexfin’s role in the stack is specific. Rexfin reconciles the accounting, banking, and warehouse data into one model that ties out to the ledger, and exposes it over MCP, so a vibe-coded tool doesn’t need its own data pipeline, an analyst doesn’t need to trust a paste from three weeks ago, and the LLM writing the tool’s logic can pull “current MRR” or “gross margin, last quarter” from a source that can show its work. The tool still gets built in an afternoon. The number it displays now has a citation behind it instead of a guess.

That’s also why the fix doesn’t collapse into “just let the code interpreter compute it correctly”: a deterministic calculator solves the arithmetic, not the provenance of what’s being calculated. Why “just use a code interpreter” doesn’t make AI finance-safe covers that gap directly: correct math on a wrong or untraceable input is still a wrong answer, just one that computed cleanly on the way there.

The takeaway

Vibe coding didn’t introduce a new risk to finance, it made an old one faster. Teams have always built ad hoc spreadsheets and one-off tools on data nobody re-verified; the difference now is that an LLM can spin one up in minutes and it looks polished enough to trust by default. The fix isn’t to slow the tool-building down. It’s to make sure that whatever gets built, at whatever stage of maturity, is pulling numbers from something reconciled instead of something exported.

If your team is already vibe-coding internal finance tools, and most are, whether or not it’s official, the question worth asking is where those tools get their numbers, and whether anyone could trace one back to source on request. For the broader pattern of AI producing confident, unsourced figures in finance, see the pillar on AI hallucinations in financial data. To see what a queryable, reconciled base layer looks like against your own data, book a demo.