A life insurance carrier portal gives you a price. It’s a specific number, down to the cent, for a specific applicant. There’s just one problem: the carrier would never write that policy. That number is the subject of this post. Not because it’s wrong, exactly, but because of how convincingly it’s wrong, and because of what happens when a team builds on top of it. And what happens further when an AI gets involved.

As I did in my What Actually Is Testing? post, I’ll show my end point now. Here’s my hypothesis:
Epistemic debt, comprehension debt, cognitive debt and intent debt are four names for one mechanism: plausibility accepted in place of the thing itself. Testing is the audit that re-rates that plausibility.
Let’s see if I actually end up there.
A Quoting Engine
I worked with a team building a quoting engine for life insurance agents. An agent enters details about an applicant and gets back a ranked list of carriers and prices. The application was written largely by AI, with developers directing it. The stakes for the agent are simple. Agents tend to offer the applicant whatever is listed first, so that first carrier and quote has to be right. If it isn’t, the agent’s commission is at risk, usually due to a chargeback. Agents being subject to chargebacks is one of the quickest ways to ensure they will not use your solution.
An operative claim in the industry is that roughly 10% of agents do really well and about 90% struggle or fail. In my experience, much of the difference comes down to one match: the best carrier, at a price the applicant will accept, that the carrier will actually write. The 10% tend to carry that knowledge in their heads. They just know which carriers balk at which conditions and medications. The 90% are still building that knowledge, and our customer base was largely that 90%.
I should be honest about that claim, though. It’s plausible and widely repeated, and I couldn’t properly source it. The retention figures I could find, from an Insurance Portal report of LIMRA data on Canadian career agents, put four-year retention at about 30%. And those numbers measure attrition, not its cause. So treat the 10/90 split as a belief the industry operates on, not a finding. A post about borrowed plausibility shouldn’t borrow any.
We called a failed match a false sellable: a quote shown as available that the carrier would not issue as quoted. It comes in two forms.
- Decline: the applicant has conditions that make them ineligible with that carrier.
- Re-rate: the carrier would cover them only at a worse class, so the real price is higher than the one shown, and the applicant walks away.
Our goal, as we first understood it, was “accurate quotes.” Hold on to that phrase.
Four Names for a Gap
Switching gears for a second here, the industry has noticed that something is off with AI-generated code, and it has been busy naming it.
- Comprehension debt. This is a term popularized by Addy Osmani: the gap between how much code exists and how much of it anyone understands. (The article Comprehension Debt in GenAI-Assisted Software Engineering Projects credits the term to Jason Gorman.)
- Epistemic debt. Sreecharan Sankaranarayanan, in Mitigating “Epistemic Debt” in Generative AI-Scaffolded Novice Programming using Metacognitive Scripts, uses this term for software a developer owns legally but not cognitively. Simon Wardley in On the question of debt lists it among four kinds of debt.
- Cognitive debt. Margaret-Anne Storey in From Technical Debt to Cognitive and Intent Debt uses this term for the erosion of a team’s shared understanding of a system.
- Intent debt. Also Storey’s term: the missing rationale that people and AI agents both need to work safely with code.
Each of these names a gap. What none of them quite does is explain how the gap gets produced, or how you would detect it before it gets called in. As a tester, and a quality specialist, that mechanism is what I’m after.
The Debt Was Always About Understanding
The popular reading of technical debt is messy code written as a conscious shortcut. That isn’t quite what Ward Cunningham meant when he introduced the metaphor. His point was that you ship code reflecting your current, partial understanding, and you repay the debt by refactoring as you learn. The debt is the lag between what you now know and what the code still says.
Peter Naur made a related argument in his 1985 paper “Programming as Theory Building.” The real program, he said, is the theory in the programmers’ heads. The code is a lossy expression of it.
So debt in software has always been epistemic. What’s changed is the direction. In Cunningham’s version, understanding ran ahead of the code. Now, arguably, the code runs ahead of the understanding.
Borrowing Plausibility
In Do Testers Understand Testing?, I played on a concept from Sabine Hossenfelder’s Lost in Math: we rarely falsify ideas, we “implausify” them. Her book’s larger argument actually runs the other way. With no new data to guide them, physicists let beauty and naturalness stand in for evidence.
I’ll call that move plausibilization. That’s my word, not hers. It means making something credible by means other than evidence.
The project I opened with did this in two layers.
Layer one: the sources. Our first fix was a golden data set built from a simple reading of carrier rate sheets. It ended up being broadly wrong. Next we tried the quoting engines on the carrier portals, which returned a quote every time. Then we found out why: the portals were designed largely not to deny anyone. They didn’t ask about health conditions or medications.
Then came the third-party vendors: BackNine, CSG and Insurance Toolkits, to name just a few. All of them gave numbers. The numbers differed, and only some returned class and tier, which is a different thing than price.
I don’t think any of these tools were wrong, necessarily. Instead, they answer slightly different questions. But every source returned a confident number, and none of them answered our question. Notice what was missing: eligibility and class. Those are exactly the two ways a quote goes false.
Layer two: the AI. The developers fed the AI each source as they learned about it. Wherever a source was silent, ambiguous or in conflict with another, the AI had to revise, assume, guess and extrapolate. And it could be very plausible about it.
So we had plausible code built on plausible sources. That’s a loan secured against another loan.
Now, to be fair, a human might have done exactly the same. The mechanism isn’t specific to AI. What AI changes is the speed, and the loss of the friction that used to force at least some understanding along the way.
One distinction before moving on. It’s a simplification to say all not-understanding is debt. Nobody on the team understood the compiler either. But someone does, and there’s a contract. The debt is the part where nobody, anywhere, holds the theory.
One Mechanism, Four Entries
If borrowed plausibility is the mechanism, the four labels are entries in one ledger. Each records the same shortfall in a different place.
| Label | Where the shortfall sits | In the quoting engine |
|---|---|---|
| Comprehension debt | Code volume vs. what anyone understands | Generated code grew faster than the developers could absorb it |
| Epistemic debt | The individual’s ability to correct the code | A developer couldn’t say which parts rested on a guess |
| Cognitive debt | The team’s shared model | Our model of the domain was still forming while the code grew |
| Intent debt | The recorded why | Decisions sat in the code that no one had made |
That last row deserves a closer look. One thing the AI presumed was that health questions and medications didn’t matter, because the carrier portals didn’t ask for them at all. Historians call this an argument from silence. And the silence wasn’t neutral. The portals left those questions out because they were built not to deny. The AI absorbed a sales-tool design choice as if it were a fact about underwriting.
In hand-written code, intent debt usually means a reason existed and nobody wrote it down. This is different. Nobody decided that health didn’t matter. The rationale isn’t lost. It never existed, and you can’t recover it by asking the author. Even worse, the debt hid itself. To catch that presumption you needed the domain theory, and the domain theory was the thing we were still building.
The System Implausifies Itself
Hossenfelder’s original sense of implausification is about what happens to a theory that keeps getting rescued. Each adaptation makes it more arcane, until people stop believing in it. No single result kills it. Software has its own version: the fix loop. We went from rate sheets to portals to vendors. Each step replaced one source of truth with another, all in the name of accuracy. Each step was locally reasonable. And we kept patching our system for each one.
So we started to interact with actual human beings, which, in this case, would be the agents. On the one hand, they would say that accuracy didn’t matter. On the other hand, they would show us where our system got it “wrong.” That sounds like a contradiction. It wasn’t. We were using the same word for two different things.
- We meant numeric accuracy: is the price close to the true price?
- They meant ordinal accuracy: is the right carrier listed first?
We had been minimizing price error on what was really a ranking problem. Being off by cents, or even dollars, is harmless until it changes the order. Then it’s the only error that counts. I’ve written before about the emic and etic in testing, and this was a textbook case: insiders and outsiders sharing a word and not its meaning.
Once we saw that, the AI’s presumption and the agents’ complaint turned out to be one failure that we could break down:
- Health conditions and medications are ignored.
- The applicant gets priced at a better class than they would actually receive.
- That carrier’s quote looks cheapest, so it ranks first.
- The carrier declines, or re-rates and the applicant refuses.
Ignoring health didn’t add small price errors. It reordered the list.
In my 2019 “Do Testers Understand Testing?” post, mentioned earlier, I told the story of Neptune and Vulcan. When Uranus misbehaved, astronomers adjusted an auxiliary assumption, proposed a new planet, and found Neptune. When Mercury misbehaved, they tried the same move and proposed Vulcan. It wasn’t there. The thing that had to change was the theory itself.
Every one of our patches was a Neptune move: swap the source, keep the framing. But this was a Vulcan problem. The framing, that accuracy means matching a price, was what had to go.
And the false sellable? That’s our green dashboard. Everything on screen says yes.
Testing as Audit
As I first started writing this post, I was tempted to say that testers have to act as epistemic creditors. But as I started typing that out, I realized that’s the wrong role. A creditor lends. The lender here is whoever accepts the plausible output in place of understanding.
The tester is the auditor: the one who refuses to take plausibility at face value and asks what backs it. The demand isn’t for proof. It’s for collateral, meaning evidence that is independent of whatever produced the claim.
This is also where I need to tidy up my own vocabulary. I’ve used “implausification” in two senses on this blog. In 2019 it meant what happens to a claim that keeps getting rescued, which is the sense in the previous section. In 2023 it meant something a tester does: continually reassessing how plausible a risk is as new information arrives.
Those aren’t the same thing, but I never made that distinction clear. In fact, I’m not sure I realized it until I starting treating this project as a use case. So, here in 2026, each is not treated as the same thing. Instead, each gets its own job. The first is a default signal: the system implausifying itself. The second is the audit: a person doing it on purpose, before the default.
Think about the 2008 financial crisis in the United States. There are three important bits of context to that time. Mortgage securities carried top ratings from agencies that were paid by the issuers. Some of those securities were built out of other securities. And the people who took the risk were not the people who ended up bearing it.
All three have a counterpart in what I’m talking about here.
- Issuer-paid ratings: a test suite written by the same model that wrote the code. The errors are correlated, so a green result isn’t independent evidence.
- Securities built from securities: layer two resting on layer one.
- Risk borne by someone else: the team and the AI did the borrowing. The agent pays on default.
And the chain doesn’t stop with the agent. Remember who our customers were. An agent in the 10% can look at the top slot and know it’s wrong. They hold the theory, and for them the tool is a convenience. An agent in the 90% can’t do that. For them, the top slot is the theory. So a false sellable passes the debt one step further down, to the person least able to audit it. The team borrowed plausibility from its sources. The agents borrowed it from us.
Our collateral ended up being real applications: what the carrier had actually decided in real cases. That evidence comes from the thing itself and not from someone’s model of it. It also gave us an oracle that measured what agents cared about. For a real application, did our system rank first the carrier that actually wrote the case, at the class it actually wrote?
Even that collateral had limits. When an application was denied, it often didn’t say why, because of PII concerns. So we had verdicts without reasons. We could validate against outcomes but not explain them. Mercury’s orbit told astronomers that Newton was off. It didn’t tell them why.
There’s a general lesson in that. Approvals reveal a class. Denials reveal almost nothing. But false sellables live on the denial side. Our evidence was thinnest exactly where our risk was highest. A good lesson for testers: check whether yours is too!
So the audit, as we found, never delivers proof. It delivers a plausibility rating that we could defend. That’s the point I made back in 2019: neither verification nor falsification is robust on its own. Implausification, done deliberately, is how you keep re-rating.
Paying It Down
All this being said, as most of us know, an audit reveals debt. It doesn’t repay it. Repayment comes in two currencies.
- Rebuild the theory. Someone has to actually understand how and why the thing works. That covers the first three ledger entries.
- Decide and record the why. Someone has to make the decisions that nobody made, and write them down. That covers intent.
For us, repayment was reframing the goal. We stopped asking whether the price was precise and started asking whether the right carrier was listed first. Once we did that we actually gained more agent trust to use the system. And the reason for that was because they became less concerned that we would give them the wrong “first sell” data thus putting their commissions at risk. That mattered most for the 90%. An agent who can’t audit the top slot themselves needs to be able to trust it.
There’s a tension worth naming. Naur argued that the theory can’t be fully captured in documentation. Storey’s remedy for intent debt is to document the rationale. I think both are right. Written intent is necessary but not sufficient. It doesn’t hand the next person the theory. It gives them a place to start rebuilding it.
Repayment also doesn’t have to cost the speed. In Sankaranarayanan’s experiment with 78 participants, one group used AI freely and another had to explain the generated code before integrating it. Productivity was comparable. But on a later maintenance task with no AI, the unrestricted group failed 77% of the time against 39% for the group that had to explain.
That’s the lesson for so-called vibe coding. Borrowing plausibility isn’t the sin. Every team does it. The question is whether anyone is auditing, and whether anyone ever pays.
Did the Experiment Land?
Back to the portal’s price that I started with. It was specific, confident, and produced by a system designed never to say no. An AI read that system’s silence as a fact. A team built on the result. An agent would have put it at the top of the list.
That’s borrowed plausibility, start to finish. And I think a variation of this problem happens in all cases where quality issues are systemic. More and more, that’s turning out to be cases where AI is used unreflectively. That said, the problem long predates AI. AI just gives it rapid pace and increased scale.
So, did I end up where I said I would?
Mostly. Comprehension, epistemic and cognitive debt fit the mechanism cleanly: each is understanding that was never earned because something plausible stood in for it.
Intent debt fits less cleanly. It may be better described as the thing that makes the other three unauditable, since an auditor with no stated intent can only confirm that the code does what it does. I’ll leave that open for now.
There’s a second experiment I owe a result on. As I said, my 2023 post opened with a hypothesis that named three methods: confirmation, falsification and implausification. The definition I actually arrived at by the end named only the first two. Implausification fell out along the way, and I didn’t notice.
This post is my argument for putting it back:
Testing is the act of continually reassessing the plausibility of risks based on new information determined through experiments, using confirmation, falsification, and implausification as methods of investigation and discovery.
The quoting engine shows why the third method earns its place. Nothing confirmed our quotes. Nothing cleanly falsified them either. What we could do was keep re-rating how much to believe them.
But notice whose belief that was. Testing isn’t about the tester’s beliefs. It’s about showing people what their beliefs are and where those beliefs seem to come from. If most of what we’re in this business for is identifying risk and surfacing it to others, then every borrowed plausibility in this story was a risk, because it was a belief with a source nobody had looked at. That makes testing, in large part, the work of showing people where, when, and to what extent their confidence is misplaced.