DEV Community: Enhanciar AI

Enterprise AI search can't answer the only question that matters: "why?"

Enhanciar AI — Tue, 22 Sep 2026 16:53:17 +0000

Every company search tool demos the same way.

Someone types "what's our refund policy?", the AI returns a tidy paragraph with three source chips, the room nods, and procurement starts a twelve-week evaluation.

Now watch an actual engineer's Tuesday:

"Why is checkout rate-limited to 20 requests per second?"

That answer is not in a document. It's in an ADR nobody linked, a Slack thread from November that scrolled away, and one line in src/rate_limiter.py. The three facts only mean something together. Enterprise search finds the file. It does not find the reason.

This is the gap I want to argue about, because I think the whole category is optimising for the wrong question — and I say that as someone building in it.

The category solved retrieval and called it knowledge

Tools like Glean are genuinely good at what they were built for: company-wide search over hundreds of SaaS connectors, with SSO, admin controls and a sales-led contract. If you need one search box over Drive, Jira, Zendesk and Confluence, that is a real and hard problem, and they solved it.

But engineering questions have a shape those tools don't fit:

What a search tool optimises	What an engineer actually asks
"Find the document about X"	"Why is it built this way?"
"Summarise this page"	"What breaks if I change this?"
"Who wrote this doc?"	"Who would actually know?"
Documents ranked by relevance	Facts joined across code, chat, and tickets

The second column is not a retrieval problem. It's a graph problem plus a provenance problem. Ranking documents better does not get you there, no matter how good the embeddings are.

Three things I think the category gets wrong

1. A citation is treated as proof

Every one of these tools shows sources. Almost none of them check that the cited source actually supports the sentence next to it.

This is not a hypothetical. It's the single most common failure we hit: the model retrieves the right file and then paraphrases something the file does not say. The citation is "valid" — the document is real, the retrieval worked — and the answer is still wrong. Worse, the chip next to it makes the wrong answer more persuasive.

We ended up building a checker that re-reads every cited source and grades each claim supported / partial / unsupported / unverifiable, with a structural (free, AST-based) pass before the model-based one. The part that mattered wasn't the model. It was the rule that the checker may never say "supported" just because it couldn't run. If the oracle has no data or the key is missing, the claim stays unverifiable and the UI says what was not checked.

"Has a citation" and "is true" are different bars. Most tools ship the first and imply the second.

2. Confidence is mistaken for coverage

Ask any of these systems something genuinely undocumented and you get a fluent paragraph assembled from adjacent noise. Almost none of them say "nobody has written this down."

That's the honest answer surprisingly often, and it's actionable in a way a hallucination never is — because the next step is obvious: go ask the person who knows. A system that knows who touched that code and who ingested that repo can name them, ask them in Slack, and file the reply back into the wiki so the next person doesn't have to ask. Not knowing isn't the failure. Pretending not to notice is.

3. Humans are the only assumed consumer

Most of these products are a search box on a web page. But in 2026 the heaviest consumer of company knowledge isn't a person typing a query — it's the coding agent in your editor, which will otherwise guess.

If your company brain isn't reachable over MCP from Claude Code or Cursor, your agents are working from vibes while your humans get the good data. That's backwards: the agent is the one that will silently act on a wrong answer.

What this actually costs you today

The pricing model is the other tell. Per-seat enterprise contracts with inference bundled in mean:

you pay a markup on tokens you could buy yourself, and
the vendor is incentivised to answer every question, because "I don't know" looks like a product defect on a renewal call.

Bring-your-own-key flips that. If the user pays their own provider directly, the tool has no reason to pad answers, and a verification pass that says "this claim is unsupported" becomes a feature rather than an admission.

Where the enterprise tools genuinely win

I'd be a hypocrite to write about honest answers and then strawman the competition, so:

Company-wide, non-engineering search. If HR, sales and support all need one box over every SaaS tool, buy the enterprise suite. We don't do that and don't plan to.
Procurement-shaped orgs. SSO, DPAs, admin policy, security review, a name on a contract. That's real work and it's their work.
Zero-config. Managed models, no keys to think about. BYOK is a tax if nobody on your team wants to hold a key.

If all you need is one search box over every SaaS tool your company owns, this post isn't for you. If your hardest questions start with "why is this built this way", it is.

The test I'd apply to any of these tools

Before you sign anything, ask the tool one question you already know the answer to — something that required a decision, not just a lookup. Why is X configured this way?

Then grade it:

Did it give you a file and a line, or a document title?
Did it surface the decision — the ADR, the incident, the Slack thread — or just the code?
When you clicked the citation, did the source actually say what the answer claimed?
Ask it something genuinely undocumented. Did it say it didn't know, or improvise?
Can your coding agent ask the same question without a browser?

Most tools pass 1 and fail 3 and 4. That's the whole thesis of this post.

We're building Enhanciar around those five checks — a company brain for engineering teams, with every answer cited to file:line, every citation re-verified, and the whole thing reachable over MCP. It's waitlist-only right now.

I'm genuinely interested in disagreement on point 1: is an unverified citation better than no citation at all? I've argued myself into "no — it's worse, because it buys unearned trust." Tell me why I'm wrong.

Your AI cited a real file. It still lied to you.

Enhanciar AI — Tue, 22 Sep 2026 16:39:32 +0000

TL;DR — A citation proves a document was retrieved. It does not prove the sentence next to it came from there. We built Enhanciar to (1) force every answer to cite, (2) resolve each citation to a repo file and line, and (3) re-read the cited source and grade each claim supported / partial / unsupported / unverifiable. The interesting part is not the LLM — it's the free, deterministic checker that runs before the LLM, and the rule that the verifier must never say "supported" just because it couldn't run.

The problem nobody's RAG demo shows

Every "chat with your codebase" tool now prints little [1] [2] markers under its answers. Ask one of them "which service handles refunds for cancelled orders?" and you'll get a confident paragraph, a source link, and a warm feeling.

Then you click the link and the file doesn't mention refunds.

This is the failure mode we kept hitting when we tried to use these tools on real engineering teams: the model cites a real page and then paraphrases something the page does not say. Retrieval worked. The citation is "valid". The answer is still wrong, and the citation makes it more convincing, not less.

We wanted a tool an engineer could trust on their first day at a company — where "trust" means "I can click through and see the line that backs this sentence, or the tool tells me it couldn't find one."

Here's how we built it. It's three layers, and the order matters.

Layer 1 — Make citations mandatory and machine-parseable

We don't index raw files for Q&A. At ingest time we build a wiki: one Markdown page per meaningful unit (a service, a route, a module, a decision), each with frontmatter that records exactly which repo files the page was built from. Something like:

---
slug: entities/cart-service
sources:
  - src/services/cart.ts
  - src/routes/cart.ts
---
# cart-service
Handles cart mutation and checkout hand-off. Exposes `POST /cart/items` ...

## Dependencies
- [[entities/pricing-service]]

Answers are generated over these pages, and the model is required to cite them with wiki-style handles:

Refunds for cancelled orders are handled by the payments worker
[[entities/payments-worker]], which is triggered from the order
state machine [[flows/order-cancellation]].

We parse those handles out of the finished answer with a boring regex (we tolerate a § heading suffix and a trailing .md because models add them anyway, dedupe, and cap at 16). Every handle resolves to a page, and every page resolves to file(s) in the repo. So one hop from [[entities/payments-worker]] gets you to src/workers/payments.ts, and the AST index we build at ingest gets you to a line.

That's the "file:line" part. It's the easy part, and it's where most tools stop.

Layer 2 — Is the page itself true? (the ingest-side check)

Before an answer ever cites a page, the page has to survive a per-claim verification pass. We break each generated page into individual claims and adjudicate each one, cheapest oracle first.

Tier 1: the AST oracle (deterministic, free)

A surprising share of claims are structural:

"this file defines generateMetadata"
"this page depends on [[get-meta-details-service]]"
"it exposes GET /aboutUs"

We already extracted all of that with tree-sitter at ingest time. So these claims are settled by lookup — no model call, no API key, no tokens. If the AST says generateMetadata is defined at app/layout.tsx:42, the claim is supported with evidence {file, line}. If the symbol doesn't exist anywhere, it's unsupported.

Anything tier 1 can judge, tier 1 judges. Tier 2 never sees it. That's the whole cost story.

Tier 2: the LLM critic (costs tokens)

Prose claims — "this service handles refunds for cancelled orders" — have no structural handle. A model has to re-read the cited source and say whether it supports the sentence. It must return a quoted span and the line it was found at, or it doesn't get to say supported.

The verdict vocabulary

Every claim ends up with exactly one of:

Verdict	Meaning
`supported`	evidence found for the specific assertion
`partial`	something related found, but not what was asserted
`unsupported`	the cited source was checked and does not say this
`unverifiable`	nothing could check it — no citation, source gone, checker unavailable

unverifiable is load-bearing and is never a synonym for "fine". Early on, tier 1 had a bug where it reported every React hook in a repo as unsupported. The lesson stuck: if the oracle has no data, or the critic has no key, the claim stays unverifiable and the UI says what was not checked. Silently marking things supported because the checker broke would be the worst possible failure of the feature, so every "cannot judge" path returns unverifiable rather than a guess.

We tag, we don't delete

There was a real design fork here: drop unverified claims, or tag them? Tagging won. A wrong verifier that silently destroys real information is far worse than a wrong verifier that mislabels it — a tag is inspectable and reversible. So a page can carry a sentence flagged unsupported and you can see it, click through, and decide.

Layer 3 — Is the answer supported by the pages it cites?

Layer 2 settles "is this page true about the code". It does not settle the failure I opened with: the model cites [[cart-service]] while paraphrasing something that page doesn't say.

So we run the same checker a second time, with one substitution: for a wiki page the source is the repo file; for an answer the source is the wiki pages it cites. Same verdict vocabulary, same evidence discipline (quoted span + page + line), same extractor, same free oracle, same paid critic. It is deliberately not a second verification system.

Four properties, in the order they matter:

It never delays a token. Answers stream. Verification runs after the stream closes, from a separate request, and annotates the finished answer in place. Nothing is on the path between a question and its first word.
It flags; it does not retry. The obvious move is "retry on mismatch". A blind retry doubles latency and doubles spend on the user's own key to produce a second answer nobody has checked either. Annotating the sentence tells the reader exactly which claim to distrust, which is what the retry was trying to buy.
unverifiable ≠ unsupported. A sentence with no citation, a citation to a page that no longer exists, a page too large for the prompt, a checker that couldn't run — all unverifiable. Only "the cited page was read and does not say this" is unsupported.
Failure is silent and safe. No key, model error, rate limit, timeout, unparseable reply: the answer is already on screen and stays there, and the result says the check didn't run. Nothing is ever marked supported because the checker broke.

What it looks like from the outside

Ask through the MCP server (Claude Code, Cursor, Claude Desktop all work). Rendered here as plain text — the UI shows the same verdicts as badges:

> which service handles refunds for cancelled orders?

Refunds for cancelled orders are issued by the payments worker
[[entities/payments-worker]] ✅ src/workers/payments.ts:118
when the order state machine emits `order.cancelled`
[[flows/order-cancellation]] ✅ src/orders/machine.ts:64.
Partial refunds are not supported ⚠️ unverifiable — no cited page discusses partial refunds.

Two sentences are backed by a file and a line you can open. The third is honestly labelled: the model asserted it, nothing in the cited pages says it, so you don't get a green tick. That third line is the feature.

Things we got wrong on the way

Trusting the citation as proof. Our first version marked an answer "grounded" if every citation resolved to a real page. That's necessary and nowhere near sufficient.
Letting unverifiable collapse into supported. Any code path that returns a default verdict when something throws will eventually default to the wrong one. We made the default unverifiable everywhere and made "supported with no evidence record" impossible by construction.
Verifying inline. Putting the checker in the streaming path made every answer feel slow and bought nothing. Post-stream annotation is strictly better.
Output truncation masquerading as parser bugs. Days lost to "the ingest found 0 pages for this domain" — it was the model's thinking budget eating the output token budget. Worth a whole separate post.

Cost, honestly

Tier 1 is free forever. Tier 2 and answer-verification spend the user's own key (BYOK), once per page at ingest and once per answer if the flag is on — it's off by default precisely because it costs something, and the token counts come back with the verdicts so you can see what you paid for.

If you're building anything RAG-shaped for engineers: the citation is the start of trust, not the end. Re-read the source. Grade the claim. Say "I couldn't check this" out loud.

We're building this as Enhanciar — a company brain for engineering teams that answers with receipts. It's waitlist-only right now; if you want to try it on your repo, the link is on the site. Happy to answer questions about the verifier design in the comments.