DEV Community: Enhanciar AI

How we stopped re-asking "where did we decide this?"

Enhanciar AI — Mon, 12 Oct 2026 06:07:25 +0000

Every team has a question that gets asked about once a week, in a slightly different form each time:

"Why do we retry this job three times and not five?"
"Who said we'd stop supporting the old export?"
"Didn't we already decide this in a call last month?"

Usually somebody did decide it. The decision is real. It's just sitting in a Slack thread, a ticket comment, a meeting doc or one person's head. So the team either re-argues it from scratch, or waits for that one person to come back from lunch.

Here's what actually helped us, roughly in the order we learned it.

1. Write the "why" next to the change, not in a separate doc

Separate decision docs are a lovely idea that nobody opens. What does get read is the stuff people are already looking at: the PR description, the ticket, the commit message.

So our rule is small. Any change that reverses or picks between options gets one sentence of "why" in the PR description, plus a link to wherever the argument happened. That's it. No template, no ADR folder to maintain.

2. Link the thread, don't summarise it from memory

When you summarise a long Slack discussion from memory, you lose the part that matters later: the objection someone raised and why it was overruled. A link to the actual thread keeps that. One sentence of summary, then the link.

3. Name the decision so it's searchable

"Fixed retry logic" is unsearchable six months later. "Retry max 3: payment provider rate-limits at 4" is something you can actually find. Put the noun people will type into search in the title.

4. Treat "who knows about X?" as a bug report

When someone asks "who knows how the billing sync works?", that's a sign the knowledge only lives in a person. We started answering those questions in a public channel, then pasting the answer, with links, into the ticket or README it belongs to. Every repeat question gets cheaper.

5. Close the loop with the follow-up

Finding the answer is only half the job. The question usually comes with a next step: reply to the customer, open the ticket, update the doc. If the answer and the follow-up live in different places, the follow-up quietly doesn't happen. Write the follow-up while the answer is still on screen.

What changed

Not a big process change. Mostly: fewer "quick calls" to re-decide things, new people asking the search box before they ask a person, and less "let me check with the one person who knows".

If you've got a habit that works for this on your team, I'd like to hear it in the comments.

We build Enhanciar, which does the searching part of this for you across Slack, Gmail, Notion, Drive, Jira and GitHub, with a link to where every answer came from: enhanciar.in

How I find what breaks before I change a Python function

Enhanciar AI — Thu, 01 Oct 2026 07:56:25 +0000

I've been bitten by the same bug more times than I'd like to admit. I change a "small" helper in a Python codebase, the tests I thought to run pass, and two days later something three modules away breaks because it called that helper in a way I never knew about.

grep helps a little, but it tells you where a name appears, not what depends on it. A name like charge or total shows up in comments, strings, unrelated classes and dead code. What I actually wanted to know before touching a function was:

Who calls this directly, and from which line?
Who calls those callers, a couple of hops out?
Which tests actually reach this code, so I can run those first?

So I wrote a small CLI that answers exactly that. It's called blastradius, it's MIT licensed, and it has no dependencies.

Install

pip install git+https://github.com/enhanciar/blastradius

You need Python 3.10+. It needs no API key and makes no network calls. Everything runs locally on your source code.

A tiny example

Say you have this layout. It's a simplified version of the tests/fixtures/shop fixture in the repo, and the output below comes from that fixture, so the line numbers differ slightly from the snippet:

# shop/money.py
def apply_tax(amount, rate=0.18):
    return round(amount * (1 + rate), 2)

# shop/billing.py
from shop.money import apply_tax

class Invoice:
    def total(self):
        return apply_tax(sum(self.lines))

def charge(invoice):
    return gateway.pay(invoice.total())

# shop/api.py
from shop.billing import charge

def checkout(cart):
    return charge(cart.invoice)

# tests/test_billing.py
def test_charge():
    ...

You want to change how apply_tax rounds. Run:

blastradius . shop/money.py::apply_tax

blastradius: 6 files, 11 definitions, 13 edges (0.00s)

Target: shop/money.py::apply_tax
  defined at shop/money.py:5

Direct callers (1)
  shop/billing.py:12                       Invoice.total  -> apply_tax

Transitive dependents (3, up to 3 hops)
  hop 2  shop/billing.py:15    charge  (via Invoice.total <- apply_tax)
  hop 3  shop/api.py:4     checkout  (via charge <- Invoice.total)
  hop 3  tests/test_billing.py:4     test_charge  (via charge <- Invoice.total)  [test]

Affected tests (1)
  tests/test_billing.py:4  test_charge

Summary: 1 direct, 3 transitive, 3 other files (2 non-test), 1 tests

That's the whole point. Your rounding change reaches checkout in your API layer, and test_charge is the test to run.

On a real repo

On psf/requests, asking about get_netrc_auth with --depth 2 parses 37 files and 787 definitions in about 0.08 seconds. It finds 5 direct callers, 14 transitive dependents (including Session.request), and 15 test functions that reach it. That's a much better list than "run everything and hope".

Useful flags

blastradius <repo> <target> [--depth N] [--json] [--exclude PATH] [--all]

The target can be a bare name (charge), a method (Invoice.total), a qualified name (src/billing.py::charge), or a whole file.
--depth sets how many hops out to walk. The default is 3.
--json gives machine-readable output for CI, editor plugins or coding agents.
The exit code is 0 if the target is found and 1 if it isn't. When it isn't found you get close-match suggestions.

You can also use it as a library:

from blastradius import build_graph, compute_impact

g = build_graph("path/to/repo", exclude=["vendor"])
report = compute_impact(g, "billing.py::charge", depth=3)

How it works

It walks every .py file and parses it with the standard-library ast module. It records definitions, calls and imports (including relative imports and aliases), then resolves each call in a fixed order:

self.x() on the enclosing class
explicit imports, then module.x()
the same file
a name that's unique in the repo

The key design choice is this: if a call is ambiguous, it is dropped, not guessed. I'd rather the graph miss an edge than invent one, because a fake caller wastes your time and erodes trust in the tool.

Then it does a breadth-first walk backwards from your target.

Limits (please read)

This is static analysis, so read the output as a strong hint, not proof.

Python only for now.
Dynamic calls are invisible. That covers getattr, callbacks passed as values, dependency injection, decorators that swap functions, and string dispatch.
Method calls on objects of unknown type (obj.save()) only resolve when the name is unique or imported. Common names like get and run are often dropped.
Inheritance isn't followed yet.
Tests only count if they reach the target through the call graph. Tests that go over HTTP or only through fixtures won't show up.

Why I built it

I'm building a bigger product (Enhanciar, a company brain that answers questions with links to sources), and "what does this change affect?" kept coming up. This piece is useful on its own, so I pulled it out and open-sourced it.

If you try it on your codebase, I'd love to hear where it got something wrong. Missed edges are the most useful bug reports. The repo is https://github.com/enhanciar/blastradius.

What do you use today before a risky refactor?

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.