> ## Content Index
> Fetch the complete content index at: https://nnutshell.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Blitzy says it handles 100M-line codebases by limiting each agent's context
- URL: https://nnutshell.com/blitzy-says-it-handles-100m-line-codebases-by-limiting-each-agents-context/
- Published: 2026-10-25T22:12:43.000Z
- Updated: 2026-10-25T22:12:43.000Z
- Description: Blitzy field CTO Joe Burn argues autonomous agents can modernize legacy code at enterprise scale, with humans setting direction and compute doing the work, in a sponsored interview.
- Author: Admin
- Tags: Joe Burn, Sid Pardeshi, Blitzy, Agentic AI, Developer Tools, Enterprise SaaS, Cybersecurity, #rec-2026-10-02

*Recorded 2 October 2026 · 25 min*

Joe Burn, field CTO at Blitzy, makes a specific architectural claim: enterprise-scale code generation does not depend on ever-larger context windows. Blitzy ingests a codebase into a knowledge graph, keeps each agent's context small, and relies on thousands of agents looping until tests pass. Burn says this lets the platform work on 100 million lines of code and run autonomously for as long as 30 days.

The interview is a sponsored segment, and nearly every performance claim, including a 5x speedup, comes from Burn himself. The tension is between autonomy and accountability. The build is autonomous, yet humans must still write large prompts and approve plans. Burn concedes that code readability, trust and any one-year forecast remain unsettled.

1. **Knowledge graph as memory** — [▶ 2:25](https://www.youtube.com/watch?v=vdmndsbyLNA&t=145s&ref=nnutshell.com)  
Blitzy first reverse-engineers existing code into a knowledge graph, which Burn describes as a combination of a vector and a graph database. Thousands of agents trace every call, file, dependency, CVE and piece of dead code, and a tech spec is generated from the result. Build agents query the graph rather than pass context between one another, which Burn says gives effectively infinite context and lets each agent's window be optimized. He contrasts tools that stop at 10,000-100,000 lines with Blitzy's 100 million, and claims builds roughly 5x faster than a team. These are company claims, offered without benchmarks.
2. **Plan as contract** — [▶ 4:46](https://www.youtube.com/watch?v=vdmndsbyLNA&t=286s&ref=nnutshell.com)  
Humans stay in the lead by entering a prompt, such as COBOL to Java, specifying environment, architecture, features and tests. Blitzy converts it into an agent action plan that Burn calls a contract, and delivers a PR of tested, validated code. Asked about trade-offs, Burn says there are none, then adds that teams must rethink the software development life cycle because design, architecture, build, test and validate collapse into one step. His evidence is customers who run old and new systems side by side, with financial-institution results matching down to the penny. This is anecdotal, with no figures given.
3. **Beyond modernization use cases** — [▶ 7:38](https://www.youtube.com/watch?v=vdmndsbyLNA&t=458s&ref=nnutshell.com)  
Blitzy targets companies of roughly 250 people or more, ideally ones that have already tried agentic development, because jumping straight to Blitzy from zero is hard. Burn says some customers do not want to modernize at all. Product people use the platform to understand spaghetti code, assessing the blast radius of a change or the impact of altering a feature on the rest of the application. Editorial inference: the graph's value as a comprehension tool stands apart from code generation, and it asks customers to trust less autonomous output.
4. **Readability gives way to testing** — [▶ 9:52](https://www.youtube.com/watch?v=vdmndsbyLNA&t=592s&ref=nnutshell.com)  
Burn calls readable code good because trust matters when a platform can run for 30 days with no human intervention, but says it is becoming less important. His example is a monolith owner handed a technical spec that can run to several hundred pages and unwilling to read it. The alternative is to have Blitzy refactor or build something and test it. Burn's summary is that the proof is in the pudding. Editorial inference: trust shifts from inspecting code to verifying behavior, making test quality the binding constraint.
5. **Small windows, many agents** — [▶ 13:08](https://www.youtube.com/watch?v=vdmndsbyLNA&t=788s&ref=nnutshell.com)  
Burn says agent efficiency degrades once a context window passes roughly a third full, and that compaction, where earlier material is summarized, is where hallucinations begin. Blitzy's technical co-founder Sid Pardeshi's team therefore uses only part of each window and spawns new agents at that point, backed by the graph. Thousands of agents run thousands of loops, and no PR ships until tests pass; failing tests trigger fixes. This explains the long runs, and Burn says the platform leans on compute. It also draws on models from OpenAI, Anthropic and Google, so model gains flow through.
6. **Autonomy has human bookends** — [▶ 15:15](https://www.youtube.com/watch?v=vdmndsbyLNA&t=915s&ref=nnutshell.com)  
Burn expects the human role to shrink over the next year and prompting to simplify; today an enterprise-scale application does not start from a two- or three-line prompt. Pressed on how this squares with fully autonomous runs, he distinguishes build and test, which are autonomous, from specifying what the business wants and keeping people accountable. He declines to forecast further, noting that a year ago he would not have said Blitzy was real. The boundary between autonomous and human-directed work is still moving, by his own account.
7. **Containment by architecture** — [▶ 18:46](https://www.youtube.com/watch?v=vdmndsbyLNA&t=1126s&ref=nnutshell.com)  
Asked about rogue agents, Burn says Blitzy has seen no incidents because the platform is architected as ingest-only inside a container, so agents cannot escape and see only what customers provide. He calls escape physically impossible, but says some mechanisms are IP, so the claim cannot be assessed. His remark that Blitzy does not pull real code in is unexplained alongside ingesting customers' legacy code. Separately, proactive insights flags CVEs, judges whether each is reachable given the architecture, and batches autonomous fixes.

Blitzy's central claim is that scaling autonomous coding to enterprise codebases is a memory-architecture problem rather than a model-size problem. Joe Burn, the company's field CTO, says the platform first reverse-engineers an existing codebase into a knowledge graph, which he describes as a combination of a vector database and a graph database. Thousands of agents trace every call, file and dependency, and flag CVEs and dead code. Build agents then consult that graph instead of passing context to one another. Burn contrasts this with tools that top out at 10,000-100,000 lines of code. Blitzy, he says, is built for 100 million.

The mechanism is counterintuitive. Burn says agents lose efficiency once they fill more than about a third of their context window, and that hallucinations begin when they reach compaction, where earlier material is summarized. Blitzy's founders responded by using only part of each window and spawning fresh agents when they hit that point. The graph makes this workable, since a new agent can recover what it needs without inheriting a bloated history. Editorially, the claim of infinite context is better read as externalized memory than as a literal window size. Scale then comes from compute: thousands of agents run thousands of loops, and no PR ships until tests pass.

That makes testing the real arbiter, and Burn's comments on readability show it. He calls readable code good because trust matters when a system can run for 30 days without human intervention, but says it is becoming less important. His example is a monolith owner who will not read a spec running to hundreds of pages. The customer's alternative is to have Blitzy refactor or build something and then test it. Burn puts it as the proof being in the pudding. Customers reportedly run old and new versions side by side, and he says he has seen financial-institution results match down to the penny. That is one person's anecdote, with no figures attached.

Humans remain in the process, but in a different role. They write the prompt, the environment, the architecture, the features and the tests, and Blitzy turns these into an agent action plan that Burn calls a contract. At enterprise scale, he says, this is a considerable prompt rather than two or three lines. Autonomy is bounded to build and test, while specification and accountability stay with people. Burn expects human effort to fall over the next year, but declines to forecast further. Asked about trade-offs, he says there are none, then says teams must rethink the software development life cycle. Editorially, that rethinking is itself a cost.

The use cases extend beyond modernization. Burn says the sweet spot is companies of roughly 250 people or more that have already experimented with agentic development, since going from zero to Blitzy overnight is hard. Some customers want only comprehension: product teams use the graph to gauge the blast radius of a change without altering the code. That arguably offers a lower-risk entry point, because understanding a system does not require trusting autonomous output. Burn also frames the broader promise against consulting firms that promised modernization and, four years and $25 million in, had not delivered. That comparison is his assertion, not evidence.

The interview's limits are material. It is a sponsored segment, and the headline numbers, a 5x speedup, 100 million lines and 30-day runs, come from a Blitzy representative without benchmarks or named customers. The security account follows the same pattern. Burn says the ingest-only, containerized design makes agent escape physically impossible, but acknowledges that some mechanisms are IP and cannot be described. His statement that Blitzy does not pull real code in sits awkwardly beside a product built to ingest customers' legacy code, and the exchange does not resolve it. The proactive insights feature, which checks whether a CVE is reachable given the architecture, sounds useful, but no data accompanies it.

The most consequential gap is validation. The host's example is a roughly 70-year-old COBOL airline booking system. The graph can show what the code does, and tests can confirm that new code matches it. Yet Burn says owners of such monoliths often do not know what their systems do and will not read the spec. If readability fades and specs go unread, accountability rests on the tests and the human-approved action plan, both written by people with limited visibility into the system. How well that holds up is untested in this conversation.

**The open question.** Can test-driven validation stand in for human understanding when the system being replaced is poorly understood? The host's example is a roughly 70-year-old COBOL airline booking system. Burn's evidence is an anecdote of financial-institution results matching down to the penny. He also says customers often do not know what their monoliths do, and that they will not read a spec running to hundreds of pages. If tests and the human-approved action plan are the only remaining safeguards, the quality of those human inputs becomes the central risk, and nothing in the interview shows how it is measured.

Watch the full video at [https://www.youtube.com/watch?v=vdmndsbyLNA](https://www.youtube.com/watch?v=vdmndsbyLNA&ref=nnutshell.com).