What Leading Models Still Get Wrong

Three ways today's best coding agents miss unstated business rules, and why getting smarter won't be enough.

Coding agents are very good now. Give a strong model a clear task and a codebase, and it will find its way around, write working code, test it, and explain what it did. For a lot of work, that is enough.

So why bring anything else into the loop?

Because there is a specific kind of mistake these agents keep making, and it's the expensive kind. The code runs. The tests pass. The explanation sounds right. And the business is now doing something it didn't intend: advertising an old interest rate, charging tax it shouldn't, or pulling stock from the wrong product.

Over the past few weeks we ran the leading models (Claude Sonnet 5.5, Claude Opus 5.5, Claude Fable 5.1, and OpenAI's GPT-6.1) against ordinary change requests on business software, five attempts per model per task. These include a right-sized public repo and private synthetic codebases we built to resemble common customer estates. We went looking for one thing in particular: requests that depend on a rule the request never mentions. That is the everyday reality of working on an older system. Below are the ones every model missed, sorted into the three ways they missed them.

1. It never found the rule

The rule lives somewhere else, and nothing points to it.

Imagine a company that changes its return policy on the website but forgets the policy is also printed on the back of every receipt. Now the company states two different policies, and nothing connects the two copies.

Older business systems are full of second copies. A rate, a fee, or a limit gets written into one program, and years later someone writes it again into another, often in a different language, with no link between the two.

Example: A rate change that left the old rate on customer statements. We asked each agent to raise a savings account's interest rate from 4.10% to 4.30% in a bank's back-office system. Every agent found the rate table, changed it, and updated the tests. Not one noticed that the program that prints customer statements has its own hardcoded line advertising the old rate. 0 of 20 attempts caught it. Most never opened that program at all.

"The rate table is the single source for this rate … so nothing else needed editing."
— Claude Fable 5.1, in its summary of the change

Example: A late-fee increase that customers' bills still showed at the old amount. We asked agents to raise the minimum late fee on personal loans from $15 to $25. The fee is charged in one program. The bill that warns customers about upcoming fees calculates it separately, in another. Only 3 of 20 attempts ever opened the second program, and all three of those got it right. The other 17 never looked, and all of them got it wrong.

"Nothing else in the system hard-codes the $15 minimum."
— Claude Opus 5.5, in its summary of the change

These examples all tell a consistent story: the agents can do this work. When the information was in front of them, as in the three late-fee attempts that opened the second program, they handled it. They just had no way of knowing where to look.

2. It found the rule but didn't see that it mattered

The information was on screen, but it looked like background.

Imagine an employee working through a policy binder. They read a footnote that modifies the policy on the page above it. Instead of applying the footnote's correction, the employee ignores it.

That's the pattern we observed in agents on these tasks.

Example: A payment plan that ignored a signpost. In a utility billing system, we asked agents to show customers how many payments their plan would take. The agents worked in the system's Python code. The rule, a $14.50 minimum per installment, lives in its Java code.

The Python file the agents edited opens with a note saying the installment minimum isn't enforced there; it's enforced on the installment record on the Java side. 19 of 20 attempts had that note on screen. None followed it. None opened the Java code or ever saw the $14.50 figure, so a $100 balance (after a $25 down payment) came out as six payments of $12.50 instead of five of $15.

Example: A price estimate that matched a wrong charge. We asked agents to add a price estimate to an online store's checkout: subtotal, shipping, tax, and total, "exactly as the order would be charged." The store has a setting for whether to charge tax on shipping. The code ignores it and always taxes shipping, with a comment right above it saying so. Every attempt opened that file. 18 of 20 had the comment on screen. Three mentioned it. None fixed it. They all reused the existing checkout math, so their estimates matched the charge exactly, including the part the store's own setting says is wrong.

Every agent read "exactly as the order would be charged" literally, and that's a fair reading of the words. But it meant faithfully copying a bug: the store was charging tax its own settings said not to charge. A developer who knew the store would have flagged that the charge itself was wrong and fixed it at the source, so the checkout and the estimate both follow the setting. We counted an attempt as a pass only if it did that.

"Shipping, handling and tax lines then come from the same code the order uses."
— Claude Sonnet 5.5

Example: A stock check built on top of a stock bug. In the same store, we asked agents to add a "how many are left" check for a product. When an order is placed, the store deducts stock from the wrong product, because it looks up the item using the wrong ID. 0 of 15 attempts caught it. Ten never opened the code that does the deduction. Of the five that did, four flagged a different, smaller bug instead.

Spotting a problem like this means knowing what the business expects to happen, not just what the code says. That knowledge usually lives with the people who run the system, not in the code.

3. It found the rule and decided it wasn't its job

The agent saw the connection and judged it out of scope.

This is the most striking class, because the agent did everything right except the part that required knowing what the business actually wanted.

Example: An overdraft policy changed in one place and left in another. We asked agents to move the day an overdrawn account gets restricted from day 30 to day 45. The same 30-day policy also controls, in a second program, when the bank stops approving new charges on that account. Most agents found the second program. Most even mentioned it in their summary. Then they left it alone. 18 of 20 attempts left the two rules out of step, so the bank would restrict accounts on day 45 but start bouncing payments on day 31.

"The policy is about the account restriction only, so I did not touch the separate pay/return rule."
— Claude Fable 5.1

That's a reasonable reading of the request. It's also wrong, and the only way to know it's wrong is to know how the bank thinks about overdrafts. Someone who has run that system would know. The code doesn't say.

The scorecard

Each cell is successful attempts out of five. An attempt passed only if the change it shipped kept the business rule correct; spotting the problem in its summary without fixing it didn't count. Fable 5.1 wasn't run on the stock check. We chose these requests because the models struggled with them; this is a map of where agents get stuck, not an average score.

What closes the gap

In all three classes, the agent wasn't short on intelligence. It was short on information: where the second copy lives, which setting matters, how the business wants two policies to relate.

That's the gap CoreStory fills. It builds a lasting understanding of a system, its rules, where each one lives, and how they connect, and puts the relevant ones in front of the coding agent before it starts work. The late-fee results suggest why that helps: the three attempts that opened the billing program all got it right.

We've also tested this head to head with Claude Opus 5.5. Two online-store changes failed every time with Opus alone: a promotion discount that should have reduced the taxed amount (0 of 3 attempts), and a shipping cost that depended on package weight (0 of 6). On the discount, Opus noticed every time that tax was charged on the full price, and reported it as intended behavior.

With CoreStory set up the way we recommend, Opus got both changes right in every attempt (6 of 6 each). That setup connects CoreStory to the agent through MCP and has CoreStory write a spec for the request before the agent edits anything.

Why a smarter model won't close this on its own

Models will keep improving, and some of the specific examples above will eventually stop tripping them up. But the three classes have causes that don't go away as models get smarter.

The knowledge isn't in the code, and it isn't on the internet. How a particular bank thinks about overdrafts, why a utility set its minimum payment, which of two conflicting rules is the real one: that lives in policy documents, old tickets, and the heads of the people who run the system. Much of what you need to change a business system safely isn't in the code, and the specifics of your system aren't in any model's training data.

Checking everything, every time, is expensive. In principle an agent could trace every connection in a large system before every change. In practice that costs far more time and money than any one task justifies, so agents make judgment calls about where to look. The bigger and older the system, the more often those calls are wrong.

Some of it is a question of intent. The overdraft example wasn't a search failure. The agent found the rule and made a reasonable call. Getting it right meant knowing what the business wanted, and intelligence alone can't work that out from the code.

Those are the gaps worth bringing in help for. A better model makes the work around them faster. It doesn't make them disappear.

Want to try this experiment yourself? Get Shopizer on GitHub and analyze it with CoreStory.

FAQ

Would a better prompt have fixed this?

Sometimes, if the person writing it already knew where the second copy lived or how the two policies relate. That knowledge is exactly what these tests are about. The agents had to work without it, the way they usually do.

Why did you pick these requests?

Because the models struggled with them. We were looking for where agents get stuck, so this isn't an average score across all change requests.

Which tools did each agent have?

Each agent ran unattended in its maker's own coding tool: the Claude models in Claude Code, and GPT-6.1 in OpenAI's Codex CLI. Each had the standard built-in tools: reading and searching files, editing code, and running commands, including builds and tests. None had web access or any add-ons, and each worked on its own copy of the system.

What does the CoreStory setup involve?

CoreStory connects to the coding agent through MCP. Before the agent edits anything, CoreStory writes a spec for the request from its understanding of the system, including the rules the request touches. That spec is broken into one-rule tickets, and the agent works through them.

About these tests: The model comparison ran in October 2026, and the CoreStory head-to-head in September 2026. The online store is Shopizer, an open-source e-commerce platform, and both store bugs described above are in its public code.