"Vibe coding" became the tech industry's favourite phrase in 2025: building software by telling an AI tool what you want and accepting whatever comes back, without reading the code underneath. The term was coined for developers, but the behaviour is older and far more common in spreadsheets.

Anyone who has asked a chatbot to "write a formula that does this" and pasted the answer straight into a cell has done it. So has anyone who accepted a generated macro unread, or assembled a month-end model one AI prompt at a time.

The problem is not that AI-generated Excel is usually wrong. Much of it is impressively right. The problem is that it fails in ways that look exactly like success. A formula that quietly excludes the last 100 rows returns a number, not an error. A macro that works this month breaks next month. A query that refreshed yesterday fails today because a column was renamed. The workbook looks healthy and the errors flow straight into decisions.

This post explains how vibe coding shows up in Excel, what an undetected error costs, and how to rescue a workbook before its numbers reach a decision.

What Vibe Coding Is, and Why It Spreads

Vibe coding means describing an outcome in natural language, letting an AI write the code, and shipping it without a close read. It became a movement because it worked often enough to be addictive, and it was liberating for people who had never written code.

The same dynamic explains its appeal in Excel. The barrier to serious spreadsheet work is not arithmetic, it is syntax: nesting IF statements, choosing SUMIFS over SUMPRODUCT, absolute versus relative references, writing a loop in VBA. AI removes that barrier. You describe the calculation and a formula appears. For a business owner who needs a cash flow forecast by Friday, this feels like a superpower.

And it is a superpower for the parts of the task about recall. The failure is in the parts about context. A language model does not know that your data runs to row 601, that your dates are text, or that half your region names carry trailing spaces. It answers from the pattern of the question, not the reality of your workbook. When it is wrong, it is wrong quietly.

How Vibe Coding Shows Up in Excel

Four patterns account for most AI-built workbooks we see. Recognise any and the file needs scrutiny.

AI-Generated Formulas with Wrong Ranges

The most common failure is the guessed range. Ask an AI to sum sales for a region and it writes something like the formula in the table below. It is syntactically perfect. The data, however, runs to row 601, and the AI had no way of knowing that, so everything below row 500 is silently excluded.

Here is a worked example from a typical monthly summary. SalesData holds 600 records in rows 2 to 601: A Date, B Region, C Product, D Units, E Unit Price, F Revenue. The prompt: "Sum revenue for NSW for January 2026."

The corrected formula returns $528,900; the AI version returned $412,500. The $116,400 difference is not an error message, it is a missing region's January revenue.

Three lessons follow. A bounded range is a guess, so check it against the real data. Data quality issues such as text dates live in the data, not the formula, and an AI that has never seen the data cannot know about them. And a plausible number is only evidence that the formula executed, not that it is right.

VBA That Works Once, Then Breaks

The second pattern is the one-shot macro. AI-generated VBA runs flawlessly on the sample it was tested on, then the data changes shape and it fails with a runtime error or, worse, runs and does the wrong thing.

The typical failure is the hard-coded range. Generated VBA is full of fixed ranges like Range("A1:A100"), because the model picks a plausible one. When the data grows to 150 rows, the macro silently processes 100. One that deletes rows by fixed count deletes the wrong rows, with no undo after save. Sheet names are equally fragile: rename "Data" and a macro referencing Sheets("Data") fails on the first line.

The rescue rule is simple. Never run a generated macro on your only copy of a file, and never trust one you cannot roughly read. If it loops through rows or references a range, make sure the range is defined by the data, such as the last used row, not a fixed number.

Power Query Steps That Fail on Refresh

The third pattern is the pipeline that stops on refresh. Power Query is where AI help is most seductive, because M code is genuinely hard to write by hand. A generated query cleans, merges, and shapes beautifully on the day it is built.

Then next month's file arrives and the refresh fails, or worse, succeeds with silently wrong results. Usual culprits: a column renamed from "Sales Amount" to "Amount", a hard-coded path pointing at last month's folder, a removed column that later steps reference, a data type assumption that stops holding. The AI built the query from your description, not from the data's month-to-month behaviour.

Refresh errors at least force attention. The dangerous ones are silent: a merge matching fewer rows, a filter dropping a new category. Check row counts and totals against the source after every refresh.

Copied Answers Without Error Checking

The fourth pattern is the most human. The AI returns an answer, the user pastes it in, and moves on, because nothing errored. Real spreadsheet work includes a sanity check: does the total match the ledger, does the margin look like last month. Vibe coding skips that step.

The result is a workbook with no reconciliation cells, no cross-foots, no variance flags, and no link to anything outside the file. The model becomes its own authority, which a financial model must never be.

The Real Cost of an Undetected AI Error

A wrong formula in a small tracking sheet is a nuisance. In a model that feeds decisions it is another category. Consider a recent engagement: a business assembled a monthly management pack with AI-generated formulas. The cost of goods calculation referenced a range that stopped short of the full dataset, understating cost every month. The pack showed gross margin of 42 per cent; the correct figure was 31 per cent. For three months, pricing and discounting decisions were made against a margin that did not exist.

What made it dangerous was the absence of friction. The totals summed, the percentages looked healthy, the formatting was immaculate. The error was found only when the accountant reconciled the pack to the accounting system, a step most small businesses do not run monthly. By then the decisions were made.

That is the standard failure mode of an undetected AI error: not caught by an error message, but by a human with a reason to doubt the number. The cost is the decisions made in between. For the audit discipline that catches these errors, see financial model audits for decision-grade outputs.

The Rescue Workflow

When a workbook is suspected of being vibe coded, the rescue is a process, not a spot fix, and it follows the discipline of a financial modelling audit. Four stages, in order.

Step 1: Audit the Workbook

Copy the file first; you will make changes and need a reference point. Then audit in this order:

• Trace the precedents. Use Trace Precedents under the Formula Auditing ribbon on every key output cell. The reference chain shows whether the output uses the data you think it uses.
• Show the formulas. Toggle Show Formulas and read the model as text. Hard-coded numbers, bounded ranges, and mixed reference styles are visible here.
• Check ranges against reality. For every SUMIFS or lookup, compare the formula's range with the actual extent of the data. This catches the row-500 problem in minutes.
• Review the assumptions. Find every input the model depends on and ask whether it is visible, named, and sourced. Assumptions buried in formulas mean the model is not auditable.
• Reconcile to an external source. Tie revenue, costs, and cash to the accounting system or the prior period. A model that cannot be reconciled is a model in name only.

Step 2: Triage: Fix or Rebuild

Not every broken workbook needs a rebuild. Work through the findings and classify:

Patch when errors are isolated and the structure is sound; rebuild when they are systemic or the structure is the problem. A rebuild is cheaper than it sounds when the source data is intact.

Step 3: Fix or Rebuild with Proper Structure

Whether you are patching or rebuilding, apply the same standards:

• Separate inputs, calculations, and outputs. One assumptions area, one calculation block, one output area. No formulas mixed into data.
• Use Excel Tables for anything that grows. Structured references expand automatically and end range-guessing.
• Name the important things. Named ranges turn =B5*$B$12 into =Revenue*Margin, which is readable and harder to mis-edit.
• Standardise the data before calculating. Clean dates, trim spaces, and type columns in Power Query, then let formulas assume clean input.
• Add the checks the vibe-coded version lacked. A cross-foot total, a reconciliation cell, a variance flag beyond a set threshold.

Step 4: Document

Documentation is the final stage. A workbook that cannot be explained is the next audit's problem. Record the assumptions and their sources, the data sources, the calculation approach, and the version history, on an assumptions sheet or in a short note. Write it during the rebuild, not after.

Quick Patch or Professional Rebuild?

The patch-versus-rebuild decision deserves its own section, because it is where most rescues go wrong in both directions. Some workbooks are patched for years, accumulating layered fixes that make them worse; others are rebuilt when a two-hour patch would have done.

Two rules of thumb. If you cannot describe where the model's numbers come from, or if fixing one error reveals another, the structure has failed and the rebuild is the honest option. If the errors are isolated and the model is small, patch it and add the checks that were missing.

The professional judgement is not about writing formulas faster than an AI; it is about knowing which situation you are in and owning the numbers either way. A rebuild by a professional modeller takes hours, not days.

Preventing the Next Incident

Rescue is reactive; prevention is cheaper, and it does not require banning AI. It requires putting the checks back in.

• Validate at the point of entry. Data validation dropdowns for anything categorical, number formats for anything numeric. If a cell can only contain "NSW", "VIC", or "QLD", a trailing-space import error becomes visible immediately.
• Reconcile every period. Tie key totals to the source system each month. A reconciliation cell comparing the model's total with the ledger is the cheapest insurance a workbook can have.
• Run scenario tests. Change an assumption, a price, a cost, and confirm the outputs move sensibly. Test AI additions like hand-built formulas.
• Make formula auditing routine. Run Trace Precedents and Show Formulas over key outputs before the model is relied upon and after any significant edit.
• Keep an assumptions sheet. One place for every input, named, colour-coded (blue for input, black for formula), with source and date. It turns "what is this model actually doing" into a lookup, not a mystery.
• Review AI output before it enters the model. The rule is not "never trust AI"; it is "verify before you paste, and structure the workbook so verification is cheap". The more visible the assumptions and the more automated the checks, the less damage a bad formula can do.

The Takeaway

Vibe coding brought something genuinely useful to spreadsheets: describe a calculation and working syntax appears. The skill that matters now is not writing formulas from memory; it is knowing what to verify and how to verify it fast. The models that survive will be the ones whose owners kept the checks: ranges that match the data, totals that reconcile, assumptions that are visible, and structures a human can read. Build those in, and AI-generated content becomes an accelerator instead of a liability.

Related reading

• Comparing AI Tools for Excel Work: ChatGPT vs Copilot vs Gemini
• Using AI in Excel: Practical Workflows
• Building Resilient Excel Models: The INDIRECT Technique