Try this with whatever tool you use. Ask it about a function that doesn’t exist in your codebase. Make up a plausible name.
Most of them will tell you about it.
You will get a confident paragraph, in the same register and roughly the same length as the answer you got ten minutes ago about something real. Nothing in the reply marks the difference between read and invented.
That is the whole problem, and it is a design decision rather than a model limitation. If confident and correct look identical, you have to check everything. A tool you have to check completely hasn’t saved you any time, it has just moved the work.
Not knowing is an answer
When our system cannot see something, it says so, and it says so as an answer rather than an error. There is no evidence here. That is more useful than a guess because it tells you where to look next instead of sending you somewhere that was never real.
One distinction we are careful about internally. A refusal is not a denial. If we cannot verify a function exists, we have not told you it is absent. We have told you we have no evidence either way. That is a fact about our view and never a fact about your code, and the day we blur those two is the day we start lying while technically saying true things.
Nobody ships this because it demos badly
Every abstention is a visible moment where the product does not do the thing. In a thirty minute sales call that is death, and the incentive to fill the silence with something that reads as competence is enormous.
We think the incentive is backwards and that it explains why trust in this category is so thin. You cannot build on something that is never wrong out loud. The first time it fails quietly you stop believing all of it, including the parts that were fine.
What it costs us
We lose the demo where everything has an answer. Fine. What we get is that when we do answer, you do not have to go behind us and check, and that is the only version of this that is actually leverage rather than a second job.