Potpie AI

As we’ve evolved our approach to code understanding, we revisited some of our earlier design decisions. Our initial direction was graph-first. We invested in discovery, tree-sitter ASTs and tags, building an in-memory graph, and persisting it to graph DB. The goal was to construct a complete representation of the repository so models could reason over it reliably. That approach was structurally sound, but it introduced a clear trade-off. Before a user could ask their first useful question, they had to pay the cost of parsing, graph construction, and ongoing maintenance. In many cases, that latency and setup overhead were disproportionate to the value delivered in early interactions. At the same time, model coding capabilities improved exponentially. LLMs became better at gathering context through iterative queries, reducing the need for a fully precomputed global call graph for most tasks. We therefore made a pragmatic decision to rebalance the system. The focus shifted to minimizing time to first interaction while preserving the ability to go deeper when required. The current approach prioritizes searchability and instant readiness. The first phase completes within a strict startup budget. File inventory is done in a single pass without full AST cost, symbol extraction is lightweight, and fast text search using bi-gram indexing. This enables fast grep search over code without waiting for heavy enrichment. Richer capabilities follow on a stale-while-enriching model. AST-aware structural metadata, dense and ColBERT-style embeddings into Qdrant, and other forms of enrichment are built incrementally in the background. They become available as the system learns where deeper context is actually needed. Graphs continue to play a role, but in a narrower scope. They are used where relationships across components are genuinely complex. For a large class of problems, targeted grep-style steps across a few tool calls are sufficient, and a dynamically maintained global graph is not the most efficient default. We strive for a more balanced approach between upfront cost and realized performance where it allows immediate access to a repository, while still supporting deeper reasoning where it adds measurable value.

Potpie: a faster beginning, and nothing traded away for it Most tools will insist you to choose between speed and depth, but you can not get both. And certainly not on a repository of any real size. It is a persuasive little argument, and we have never been inclined to believe it. A repository of the sort you might actually work in, something on the order of 40,000 files, used to take us 47 seconds to parse. Today it takes 3. That is a 15x speedup, and a 94% reduction in the time an agent must wait before asking its first honest question. The numbers are the easy part to tell. The interesting part is underneath them. We did not earn that figure by making the system smaller or thinner or cleverer in the way tools are sometimes cleverer at the reader's expense. We rebuilt the retrieval layer around the way agents actually behave. An agent, upon meeting a new repository, does not draw up an architectural survey of it first. It searches. It looks for a name, a phrase, a familiar outline, and only then begins to reason. Potpie now answers that instinct at once, BM25 carries the weight it has always carried and then ColBERT style embeddings lend it meaning rather than just spelling. And the operation that has historically made teams nervous, the max similarity pass, now runs locally upon a quantised model, which trims roughly ~20% of LLM tokens and returns answers about ~30% faster without losing any of the precision. Faster setup. Better answers. No trade. From here, the work turns toward context aware graphs, and toward parsing that keeps its composure on genuinely large repositories.

Every insight Potpie delivers about your codebase starts with parsing. Our context engine builds a complete map of your codebase: its structure, its components, its relationships into a knowledge graph that agents can use to navigate and query code faster. Currently, it supports more than 15+ languages including python, typescript, java etc. We understand that parsing large repositories is inherently time-consuming, but it shouldn't slow you down. That's exactly why we rebuilt this critical functionality in Rust: to make understanding your codebase faster, without any performance compromise. Our benchmarks show approximately 30% faster parsing for repositories with 1M+ lines of code, with the performance gap expected to grow significantly for larger codebases. Looking ahead, we plan to introduce parallelization of the parsing pipeline to use multi-core threading for processing files simultaneously without Python's GIL constraints. This allows us to handle enterprise-scale repositories with sub-minute indexing times.

It’s been an exciting past few months at Potpie AI. 🚀 From early builds to real enterprise deployments, we’ve seen strong momentum across product, customers, and team. We’re now working with some of the most complex codebases out there and pushing the boundaries of how software gets built and maintained. 🪴 As we continue to grow, we’re hiring across multiple roles. If you’re someone who likes working on hard problems, cares about building things that actually work in production, and wants to be part of a fast-moving, high-ownership team, we’d love to hear from you. 🔗 Please apply using the link below: https://lnkd.in/gpVgKG7A We’re a close-knit team, we work deeply with our customers, and no two days look the same. If this sounds like your kind of environment, come build with us.

There is something that has been bothering us for a while now, and it is the way this industry measures whether an AI coding agent is actually any good. The standard benchmarks, HumanEval, MBPP, the ones everybody cites, they test whether an agent can write a sort function or solve a self-contained puzzle. Agents do very well on those, they score 90%, sometimes higher but what nobody mentions quite as often is that those benchmarks have been floating around in training data for years, so the scores tell you roughly as much as an exam result would if the answers had been pinned to the noticeboard beforehand. The moment you put the same agent in front of a real codebase, one where half the architecture is undocumented and the other half was documented by someone who left two years ago, it falls apart. Not spectacularly, which would at least be honest, but quietly. It gives you answers that sound perfectly reasonable and happen to be wrong. We have seen this enough times now that we decided to do something about it, which is how we ended up building three separate evaluation benchmarks for our agents at Potpie, one for QA, one for code generation, one for debugging, each designed to test the things that actually matter when code ships to production. The full methodology, all the details on how we select repositories, score across five dimensions, and what the patterns between those scores actually reveal, is in the blog. https://lnkd.in/diEXXc4S This is the first in a series on how we think about evaluation. There is, it turns out, quite a lot more to say on the subject... wait for the next part.

A few weeks back Yash wrote a piece for us arguing that compliance is architecture, not overhead. It struck a nerve. A number of people read it and said, it is essentially, fine but how does that actually work inside the codebase? Part 1: https://lnkd.in/dNF5zadN And that is a fair question, Yash wrote a follow up on this. And the answer is that most AI coding tools retrieve context in a way that makes compliance structurally impossible. The standard pattern, slice, embed, retrieve by similarity, has no concept of who is asking or what they are allowed to see. A developer asks how do we handle user sessions? and the agent, being helpful in the only way it knows how, pulls production secrets and internal security logic into the same answer as the readme, because both are semantically similar. and that is not a bug, that is how flat retrieval was designed.. one suspects nobody thought to give it a concept of clearance. This second post goes into what happens when you replace that flat pile of searchable text with a context graph, where every node carries permissions, every edge carries policy, and the agent can only traverse what the caller's role is authorised to see. Not because it has been asked to keep a secret, but because the secret does not exist in its reachable context. The full deep-dive covers semantic sandboxing, pre ingestion scrubbing, glass-box auditability for ISO 42001 and SOC 2, and what implementation actually looks like in practice. Part 2: https://lnkd.in/dFnmvsZp

The axios library, which is downloaded hundreds of millions of times each week and sits quietly inside more applications than most engineers would care to count, was hijacked. The maintainer's account was compromised, malicious versions (1.14.1 and 0.30.4) were published, and a Remote Access Trojan was slipped in through a hidden dependency. By the time anyone noticed, the damage was already spreading. We work inside enterprise codebases every day at Potpie. Our agents reason over code, trace dependencies, and operate in environments where a single bad package can compromise everything downstream. So supply chain security is not something we treat as optional. It is built into how we operate. Here is what we strongly recommend every engineering team do right now: Pin exact versions. Never use ^ or ~. "axios": "1.14.0" Run "npm ci --ignore-scripts" in CI/CD. Never plain npm install. Add these to your .npmrc: ignore-scripts=true min-release-age=7d Switch to pnpm where possible. It has stronger isolation defaults against exactly this class of attack. Enable SCA scanning (Socket, Snyk, or GitHub Advanced Security) on every pull request. Use a private npm proxy or registry for critical projects. We have already applied these controls across our own infrastructure and customer environments. Because the uncomfortable truth is that these incidents are no longer unusual. They are the new normal. And the teams that come through them intact are the ones that assumed, from the beginning, that every install could be hostile.

There is a rather persistent belief in the technology world that compliance is something you endure. A necessary unpleasantness, like a visit to the dentist, best scheduled infrequently and forgotten about as quickly as possible. We took a different view. When we built our compliance stack at Potpie, SOC 2, GDPR, ISO 27001, and ISO 42001, we discovered something that ought to have been obvious from the start: these frameworks are not paperwork. They are architecture. They are the reason unencrypted data flows get caught before they become breaches, the reason overprivileged service accounts get trimmed before they become headlines, and the reason your AI systems can be trusted with the sort of data that, frankly, deserves to be treated with some seriousness. The entire journey took six to eight weeks. Not because we cut corners, but because the frameworks, when approached in the right order, build on each other in ways that are almost elegant. SOC 2 does the hard operational work. GDPR slots in with surprising ease once that foundation exists. And the ISO certifications, both of them, become a matter of formalising what is already true rather than inventing something new. Yash wrote up the full story, what we learned, what surprised us, and why we think compliance should be designed into AI products from the very beginning rather than applied apologetically at the end. https://lnkd.in/dNF5zadN