You asked for a five-year forecast. You got one in about fifteen minutes: assumptions page, income statement, cash flow, balance sheet, formatted to something close to professional standards.
Three weeks later, you change the growth rate from 12% to 9%. Revenue moves. Gross margin moves. Operating expenses sit exactly where they were.
Somewhere in row 34 there is a number that should have been a formula. It was right when it was written. It is wrong now, and it has been wrong since the moment you changed the assumption, silently, in a file you have already sent to two people.
That is a hardcode, and it is the single most common way an AI-built financial model fails.
Why it is worse than a wrong number
A wrong number announces itself eventually. Someone recognises that the figure is implausible, or a total does not tie, or a ratio looks absurd.
A hardcode does none of that, because when it is written it is correct. The agent computed a plausible value for that position and wrote the value instead of the relationship that produced it. The row totals correctly. The statement ties. The formatting is consistent. Every test you would run by eye passes.
The failure is deferred to the next time an input changes, and the person who changes the input is usually not the person who would recognise the omission.
The Financial Modeling Institute demonstrated this in front of an audience of finance professionals, building complete five-year models live from a single prompt. Their summary of the problem is the one worth remembering: finding and fixing a hardcode buried in an otherwise coherent line takes hours, because the hardcode does not show to the eye.
This is measured, not anecdotal
Two independent evaluations, from institutions with no product to sell in this category, land on the same failure.
Columbia Business School's MBABench is built specifically to score the artefact rather than the answer: does the agent produce a workbook a managing director could open, read, challenge and edit. Across 206 tasks and more than 18 agents, the best agent scored 72.6 out of 100 on medium-hard tasks, against 92.4 on easy ones: performance falls away as soon as a task is more than a few chained calculations. Hardcoding is measured directly: one frontier model hardcoded roughly a quarter of its answer cells rather than pointing them at the calculation sheets, while its workbook still presented well.
Wall Street Prep's 2026 comparison of four tools on a three-statement build reached the same place from a different direction. Every tool beat a human on setup, 15 to 25 minutes against one to two hours. None beat a weak analyst on the finished model. Debt integration was not handled properly by any of them. Interest that should depend on a balance, which itself depends on the cash flow that interest feeds, got resolved with a plug rather than a real link. And the most dangerous category of error they found was the subtle one: individual lines wrong, totals correct.
One more detail from the FMI demonstration, and it is the one that should change how you work rather than how you feel. The same prompt, run twice, produced different results. On an unbalanced balance sheet, the tool could neither locate nor correct the gap, and one of the two assistants tested suggested the imbalance was acceptable to present.
What is actually going on
It is tempting to file this under "the model is not good enough yet". That reading predicts the problem disappears with the next release. It has not, across several releases now, and there is a reason.
A language model produces what a number looks like at that position. Writing =B12*(1+$C$4) instead of 1,340,000 is not a harder arithmetic problem, it is a different kind of problem: it requires holding the dependency graph of the model in mind and committing to a relationship rather than to a value. Values are local. Relationships are global, and they have to stay true for every future state of the model, including states nobody has described.
Which is why the failure shows up more on harder tasks, not less, and why it shows up across vendors rather than at one of them.
The claim that holds, and the one that does not. It is not true that AI cannot do arithmetic. Agents delegate calculation to tools routinely and get the right answer. Anyone arguing "the AI can't count" is making a claim that is easy to disprove and that discredits the real point. The real point is narrower: an agent does not reliably build and maintain the structure that connects the calculations, and does not reliably keep it intact when the model is edited later.
Confusing the two weakens the case. Keep them apart.
Seven things that work
Ordered by return on effort. The first three catch most of it.
1. Run the perturbation test, do not re-read the file
This is the highest-yield check in the list and it takes ninety seconds.
Change one driver by 10%. Growth, headcount, price, whichever one should ripple furthest. Then read the outputs.
- Anything that does not move and should have is a hardcode.
- Anything that moves absurdly is a broken link.
- Anything that moves by exactly the amount you changed and nothing else is a suspiciously shallow dependency.
Then undo it. This finds in a minute and a half what an hour of cell-by-cell reading misses, because you are testing behaviour rather than inspecting appearance.
Do it a second time with a different driver. Hardcodes cluster in the lines that nobody thinks of as drivers: working capital days, tax, other operating expenses, anything below EBITDA.
2. Make the assumptions block the only legal home for a constant
State this as a rule before generation, not as a correction after it.
Every number that is not derived from another number must live in the assumptions block and be referenced from there. No literal values anywhere else in the workbook. If you need a constant that is not in the assumptions block, add it there first and tell me you added it.
The last clause is the one that earns its place. Without it, the agent invents a constant, uses it, and does not mention it. With it, you get a list of what it needed that you had not specified, which is often more informative than the model.
3. Ask for the dependency before you ask for the number
Have the agent write the structure first, in prose or as a list, and confirm it before a single cell exists. What drives revenue. What drives each cost line. What the balance sheet ties to. Where cash comes from.
Reviewing ten lines of stated dependencies is cheap. Reverse-engineering them from four hundred populated cells is what costs you the afternoon. And an agent that has committed to a dependency in writing hardcodes noticeably less when it comes to implement it.
4. Run it twice and diff
Given that identical prompts do not reliably produce identical models, generate twice and compare. Cells that differ between the two runs are, by definition, cells where the agent had no principled reason for its choice. That is exactly the population you want to inspect, and it is usually short.
This is also the cheapest way to find out whether your prompt is underspecified. A well-specified structure produces two near-identical models. A vague one produces two different ones.
5. Never let it fix an imbalance
When the balance sheet does not tie, do not ask the agent to make it tie. It will find a way, and the way is a plug.
Ask it instead to locate the difference: which statement, which line, which period. If it cannot, that is information. A tool that cannot tell you where the gap is cannot be trusted to close it, and closing it invisibly is worse than leaving it open, because an open imbalance is at least an alarm.
6. Do a constants sweep before the file leaves
Before anything is sent, list every cell in the workbook that contains a literal number and is not in the assumptions block. In Excel, Go To Special then Constants over the numeric range gets you most of the way in a few seconds.
Every hit is either a legitimate input in the wrong place, or a hardcode. There is no third category. This is the check to run on a model you inherited, including one you inherited from yourself three weeks ago.
7. Keep the structure out of the generation step
The six checks above are hygiene. They reduce the rate. They do not change the underlying condition, which is that the structure is re-derived every time the model is touched.
The structural version of the fix is to hold the dependency graph somewhere that is not regenerated: a definition the agent reads and edits, rather than a workbook it rewrites. When the structure is an object rather than an output, a hardcode is not a thing that can be silently introduced, because there is no step in which the relationship is re-invented.
What does not work
Waiting for the next model. The failure has persisted across model generations and across vendors, and it tracks task difficulty rather than model quality. Planning around its disappearance is planning around an assumption nobody has evidence for.
Prompting harder. "Use formulas, not values" helps at the margin and stops helping quickly, particularly on the lines furthest from the ones you described. It is worth saying, it is not worth relying on.
Native spreadsheet access. Native access is not native competence. Putting the agent inside the file does not give it the structure of the file: the relationships still have to be written, cell by cell, and nothing in the grid holds them once they are.
What to do with an AI-built model you already have
If you are holding one right now and it is going somewhere that matters, three passes, in this order:
- Constants sweep. Every literal outside the assumptions block. Ten minutes.
- Perturbation, twice. Two different drivers, 10% each. Three minutes.
- Trace the three numbers that carry the conclusion. The valuation, the covenant line, the funding need. Follow each back to a named assumption. If the trail ends in a cell with no story behind it, you have found the thing you cannot defend in the meeting.
That is under twenty minutes and it catches the class of error that survives everything else. It is also the sequence I would run on a model built by a junior analyst, which is the point: the review is not different in kind, it is different in that nothing tells you where to aim. I wrote about why that undirected review is the real cost separately.
Where Layerz sits in this
Layerz holds a financial model as a structure separate from its data. The dependency graph, meaning what drives what, is a stored object. The values sit on top of it.
The practical consequence for this specific failure: an assumption is a node, not a cell. Changing it propagates by construction, because the relationship is what is stored and the value is what is computed. There is no generation step in which a relationship can be quietly replaced by the number it produced today. Claude drives the model from outside over MCP, so it edits the structure rather than rewriting a grid, and the change is recorded as a change.
The Excel export is a clean, standard workbook with live formulas, because a model that cannot be opened and challenged by the other side has not been delivered. That export is never paywalled, and your own model exports without a watermark.
None of which removes the review. The 63 senior modellers who said they would not trust an AI-produced model without human review were right, and they will still be right. What changes is that the review has somewhere to aim.
Further reading: Why Not Just Build It Yourself With AI? · AI Financial Model Generator: What These Tools Actually Produce · Can You Trust an AI-Generated Financial Model? What 63 Expert Modellers Say · The Verification Tax · How to Build a Financial Model with AI That Doesn't Drift · LLM Reliability for Financial Calculations: Statistics
Layerz keeps a financial model as structure separate from data, so an assumption is a node rather than a cell. Excel export is clean, standard, and never paywalled. Explore Layerz →
