Engineering 1 min read
Designing an AI tool that never sees your code
Afara's backend never receives your source. We explain the architecture choices behind local analysis, and what we gave up to get there.
Afara Engineering, Engineering team
The first question every security team asks us is some version of “where does our code go?” We wanted the answer to be short: it doesn’t.
Commits, not the working tree
Afara reads commits, never your working tree. Uncommitted changes are never read or transmitted. That makes the input well defined (a commit ID is the same everywhere) and keeps half-finished work private by construction.
Your AI tool, on your machine
afara generate and afara compare don’t call an Afara model with your code. They run the AI coding tool you already use and already trust: Claude Code, OpenAI Codex CLI or Gemini CLI. It reads the repository in a read-only copy, on your machine, under whatever agreement you already have with that provider.
What comes back is a wireframe: nodes, edges and references to file paths and line ranges. That graph is what afara push publishes. The dashboard can link a node to GitHub at the compared commit, but it never stores the source.
Local state stays in .git
Per-repository state lives in .git/afara/: feature names and IDs, linked tickets, the commits already generated. Because it’s inside .git, it can never be committed by accident. The pre-push hook reads only that local record, so it adds no network call to git push.
What it cost us
Running analysis locally means we can’t batch work across customers or tune a single hosted model, and generation speed depends on the tool you have installed. We think that’s the right trade. The teams who most need to know what their code actually does are usually the ones who can least afford to send it somewhere.