How Xint Code Reads a Large Codebase

Give one AI model an entire repository and plenty of time, and it tends to circle. It rereads the same files, chases the same leads, and if it hasn't found something early, more hours rarely help. Bigger codebases make that worse, not better.

We recently examined seven frontier and open-weight models to understand the changing economics of finding a 0day. When we examined the logs of the models that failed to find the target vulnerability, we found that more attempts did not lead to models getting closer — it meant repeating a wrong idea. Whether it was 5 hours or 24 hours of reasoning, over 96% of tokens consumed by the failing models was the model re-reading its own earlier work with only a small percentage dedicated to new thinking.

Xint Code is built to avoid that. It doesn't ask one model to hold the whole codebase at once. It splits the work.

Threat model first

Before looking for bugs, Xint Code reads the project the way a security reviewer would: what the software does, who can reach it, what data it holds, and how it's typically deployed. That threat model is what every later step is judged against, so a finding counts only if it matters in a realistic deployment.

Split the work

Instead of handing one model the entire repository, Xint Code breaks the code into small pieces and gives each piece its own agent, with many running in parallel. No single agent has to keep the whole codebase in view, so none of them end up going in circles.

Keep the connections

The pieces aren't analyzed in isolation. Each agent knows how its piece connects to the code around it, so a bug that only shows up across a boundary still gets caught.

Prove it

Anything an agent flags is checked against the threat model and has to be reproduced. What reaches the customer is a vulnerability with reproduction steps, not a weakness someone has to chase down.

What this means for a security team

Coverage holds up as codebases grow, because the work is split instead of stretched. And the findings are the ones that matter for how the software actually runs, each one with proof attached.