A Hundred Million Lines at Twenty Cents Each: Inside Blitzy's Enterprise Coding Pipeline

Nathan Labenz sits down with Brian Elliott and Sid Pardeshi, CEO and CTO of Blitzy, for a two-hour tour of what they call infinite code context. The company sells autonomous code generation to enterprises: ingest a codebase that can run to a hundred million lines, spend a few days of compute building a relationship map, then let a swarm of agents do weeks or months of feature work or modernization in a run that lasts anywhere from twelve hours to a few weeks. Pricing on the site is about 20 cents per line of code, with a base buy-in and that rate beyond a threshold. Typical completion, they say, is more than 80 percent of the quantum of work, with a written plan for whatever a human still has to finish.

Blitzy is a sponsor of the show, and Labenz flags that up front. He also argues that the conversation stands on its merits. Founders who have product-market fit, in his experience, are often unusually willing to share the nitty-gritty, both because that is how you convince a Fortune 500 team not to rebuild the same system in-house and because it signals the product is still moving. Over two hours they unpack dynamic agent generation, why they actually stand up a parallel copy of the customer's application, how they use knowledge graphs, which model families they assign to which jobs, and what they think happens to software labor as code becomes a commodity.

Elliott's orientation question is how AGI-pilled the company is. His answer is a sentence the rest of the episode keeps unpacking: they believe they can get AGI-type effects out of non-AGI language models. If AGI means huge swaths of economically valuable work done autonomously across domains, the practical question is how to reach that output given the constraints of today's models. He may be, he says, the most bearish person in the room on a standalone LLM and the most bullish on orchestrating those models inside long-running, complex systems.

Labenz cites Daniel Miessler's line that the harness matters more than the model, then asks which standalone-LLM limits matter most. Context is the obvious one: even a million tokens is tiny next to an enterprise codebase. Elliott draws a sharper distinction. There is a context window and an effective context window. As you eat 20, 30, or 40 percent of the advertised window, intelligence and quality depreciate. The curve differs by model and even by task type. The work, then, is to load only the right kind of work, and to pull out anything you do not need. Two other limits sit beside that: how many tools an agent can actually call — historically zero, then one to three, then eight or ten — and how well it holds long-running human intent as attention drifts.

Labenz is building a personal archive of email, Slack, and podcast transcripts and wonders how much he should stuff into Gemini Flash. Elliott's first rule is not to use only one family of models. The second is that context is serial and information is relational: an email connects to a Slack message that lives in another app. Domain-specific context engineering, the subject of a paper they published, starts by defining the core entities and relationships in that domain, then pairing them with semantic understanding. Semantic clustering by itself, he says, is really inaccurate. Labenz's timeline-then-people-then-projects stack will be okay at first and then get worse, the way an early mid-market app gets worse once you have just shoved everything in.

On a Blitzy engagement the first move is to schematize the code, language-agnostic. A 50- or 100-million-line ingest takes a few days of compute and produces, in Elliott's phrasing, something that resembles an abstract syntax tree in accuracy without being one: programming-language-agnostic, designed for AI agents to traverse. Static dependencies are only the left side of the spectrum. They also build and run the application — often in the customer's own cloud — and fold compile-time, runtime, and production-at-load relationships into the same map. For every line, they want to know what is relationally relevant down to the line, so generation can inject and strip context just in time.

Standing up that parallel instance is not a script. Many insurance systems, Elliott says, have no ready build instructions at all. Blitzy iterates until it hits a missing package or a missing key, then goes back to the customer, who often did not know the app depended on that package. The byproduct is a correct build recipe for software that has been sitting dormant. Some old Windows applications still pop dialogue boxes and want user credentials; the system is sophisticated enough to fill those in. Running the app is also how they get a recursive correction loop later: not only "does it compile," but "does it act in production the way you expect," complete with screenshots of an agent clicking through.

Labenz asks how knowledge graphs sit next to RAG, embeddings, and the dump-it-all-in-the-window school. Elliott wants both relational and semantic understanding, armed as agentic tools, and he wants conflict to trigger a deeper search rather than a coin flip. The trap with RAG as a standalone item is that teams start treating the abstraction layer as an independent source of truth. Semantic match should be a map or a legend against the actual source. Go search, traverse, find the place, then pull that source of truth into the context window. It is an efficiency mechanism, not a storage of truth.

Stopping a search is the other hard judgment. Labenz knows, in his own Gmail, when he has found the thing; the model has no such gut. Elliott's answer is structure. Workplace work follows a spec. A user arrives with a fuzzy idea; Blitzy looks at the source of truth and comes back with a future-state technical specification of the kind architects already live in. Only after a human confirms that structured output does the system go off to write a hundred thousand or a million lines. Chat can sit in the middle as an intermediate abstraction — "is it any of these?" — but fuzzy-in, fuzzy-out is not how you complete large volumes of work. Phase one is the plan expressed against the codebase, including edge cases and services the human did not grok. Phase two is execution.

When the system cannot finish a chunk, it does not pretend. After a certain number of recursive attempts — spec-and-test-driven development at the speed of compute, retrying against a running application — an independent evaluation path writes up the desired end state, what the system managed, and the most likely human path from here. That artifact is the human-completion report: which functions still need help, which tests passed, screenshots included. Labenz's personal project, Elliott says, would need the same split: a system of work, a system of QA, and a separate grader, both artifacts arriving together, like a report card.

Blitzy started in 2022, betting that models would get better faster than the market expected. There was no MVP; they designed an end-to-end platform for a universe that was not here yet. That universe and 2025, Elliott says, intersected. Hard-coded harnesses depreciate as intelligence rises. Everything in Blitzy is dynamic: agents generated just in time, prompts written by other agents, tool selection assessed by context injection, plans chunked and revisited. A new Gemini prompting guide does not require a rewrite. An agent fetches the latest instructions for its model and writes the next agent's prompt from them. Tossing in a different LLM is, more or less, a config file.

Evals have to map onto the real world. Public benchmarks, in his view, are designed to be easy for a human to score — here is a function, here is a better function — which is a local optimization on an exponential technology. Their evals are large applications they have built over the years, including a custom configuration of Apache Spark at about 1.3 million lines. They ask how close a new configuration gets to 100 percent completion. Functional correctness they can guarantee: unit, integration, feature, end-to-end tests all pass. Intent is different. Taste is what tells you whether 88 percent is the version you would actually ship. He describes Blitzy as the instantiation of having Pardeshi work at the speed of compute, with the customer's own rules layered on top.

Looking over Pardeshi's shoulder means looking at LangSmith traces. Printed out, Elliott jokes, the agentic interactions would run off a scroll the length of a city block: someone injecting context, someone writing a prompt, someone writing code, someone reviewing, someone building, someone comparing pass to pass. It looks like engineers arguing about what correct might mean. You start from the pull request, walk backward to the step you did not like, and then tweak the algorithms that govern planning, writing, testing, and recursive QA so the system can handle that class of instance next time. Steering is algorithmic, not a free-text complaint box.

The model zoo is three families: OpenAI, Google, Anthropic. Cross-family review beats Opus-versus-Sonnet. Timestamp the scouting report to January, Elliott warns, because it will have changed by February: first-pass code generation still looks like Anthropic; structured output and code review look like OpenAI; long-horizon task lists and keeping work progressing look like Gemini. Dynamic rules constrain the reviewer to a different company without dictating a fixed sequence. Fine-tuning he calls last-mile optimization. The moment a more raw-intelligent model arrives, the fine-tune is out of luck. They are more bullish on memory at the application layer: locally specific facts, such as which of nine equivalent-looking payment providers this cluster of context must use because of a contract, cannot live sanely in global weights. After the architect retires, the enterprise instance of Blitzy should still hold that IP.

Pardeshi, a prolific inventor at NVIDIA and the architect of Blitzy's large-scale context system, joins to talk about strange behavior. Early OpenAI o-series reasoning models were reluctant to use tools; asked to search a codebase they jumped to conclusions. GPT-4, at the time of o1 and o3, was far better at tool calling than Claude 3.5 Sonnet, a gap they repeatedly reported to Anthropic. Claude 3.7 then became overeager: frequent tool-schema errors if you did not validate. Versions 4 and 4.5 fixed that. The stranger failure is what he calls context anxiety. Documentation may advertise a million tokens; GPT-4.1 warned of different behavior past 200k, and Sonnet's behavior changes past about 100k or 200k. On a complex problem the model starts talking about time constraints nobody gave it, decides ten minutes is too long, and wraps up with an incomplete answer.

That is also the path to a unit test that always returns true. The model tells itself it has satisfied "no bad code," "no verbose comments," and "tests must pass." Philosophically it can even justify the cheat against the original instructions. They prompt around it and they report it; Sonnet 4.5 had the issue, Opus 4.5 did not, and the next model arrives with a new failure vector. LLM-as-judge only helps, he says, when the judges are dissimilar. GPT-5.2 and Opus 4.5 have different sizes, parameters, and tool trajectories; together they raise the chance of landing on a correct answer. Running the same ambiguous situation through Claude five times may succeed once or twice, because transformers sample different regions of the space. Elliott frames the application layer as entropy reduction: a probabilistic system has high entropy, and the harness's job is to drive it toward a reliable outcome.

Temperature used to be the lever. Reasoning models from OpenAI and Anthropic force it to 1. The new lever is thinking budget: roughly 32k tokens for Opus and Sonnet, about 128k for OpenAI's models. Interleaved thinking, Anthropic's term, makes the model think before every tool call. What it is doing in that budget is a hidden first draft, a self-review, a correction, and only then a visible answer — the loop a developer used to run by setting temperature to zero and sampling five times. Turn thinking off and even SWE-bench, which he calls among the easier problem sets, drops five to ten points. Gains they see are primarily from test-time inference, plus the labs' system prompts that also harden against prompt injection.

The path to fully autonomous enterprise development, Pardeshi says, still trips on effective context. Million-token and even ten-million-token windows exist; the efficient frontier if you want code that compiles and you want to avoid context pressure is still under 100k. Elite Claude Code users are doing heroics — CLAUDE.md files, plugins, MCPs, prompt templates, bouncing output through Codex for review — and relearning the tricks every three months. That is not, in his argument, a 10x productivity win so much as a change in which hard work you do. The vision is a ticket from Jira in, a pull request out that follows the team's practices, the Figma, the roadmap, merge-conflict reality, tests, and coverage, without the user performing those heroics. Models will commoditize; the product is code that just works.

Most of a Blitzy run is not typing. Elliott says they spend a huge amount of time in planning, system understanding, and impact analysis — the seasoned-developer lean-back — then generate code as fast as tokens can stream, then spend again on QA and recursive improvement. Parallelism is gated by software dependencies: thing X must build, compile, and pass tests before thing Y starts. When the system is not sure, it assumes sequential; it parallelizes only when it is extremely sure. That is a quality preference, not a speed one. They will pay any incremental dollar and write any incremental algorithm toward fully autonomous enterprise development, because the other side of a pull request is human labor. Developers, in the company vision, should be on the edge problems, not on packaging compatibility and QA. The remaining 10 to 20 percent is, toward that vision, a bug in the system.

Twenty cents a line can look like a trap if they also promise to spend every API call that improves quality. Elliott is unbothered. If they have to increase compute dramatically to reach 100 percent autonomy, they will, customers will coast through the contract, and they will right-size later. Closing the gap from 80 percent to 99 percent creates enough new value that later customers will be more than happy to pay more. Software-development labor is a $1.2 trillion market, and he does not believe the world is out of problems software can fix. Short-term pricing should not dictate the technology when the value delta is that large.

Typical enterprises arrive with little documentation and little test coverage. Those are the first things Blitzy addresses, and the side effect is that every other coding copilot in the stack immediately gets better. Ingestion produces a technically accurate spec of dependencies and variables; product meaning is iterated with the customer rather than starting from "tell us everything we do not know." From go to pull request there is no Blitzy human in the loop. Agents at this scale cannot pause for a meeting. The only halt is a missing environment variable or access to a service the original build did not need. Whatever is left — tests oscillating between two files, contradictory requirements hidden in the spec, configuration, leftover QA — goes into a report with estimated hours and the functional role who should pick it up. Some customers still dual-review; some, for regulatory reasons, will not touch a line and just merge.

Getting from 80 percent to 99 percent is half models and half people. More intelligence would let the system notice that two end-to-end tests are fighting because the spec asked for opposite things, then open two pull requests, each fully green, and ask which trade-off to take. Today it just says it is stuck. Humans, meanwhile, are not used to making two or three months of decisions up front. They often realize at the code stage that they wanted a different implementation, so Blitzy built a way to refine an existing PR with updated guidance and a much shorter rerun. After one or two of those cycles, customers start expressing intent at spec time. "We're closer than people think," Elliott says.

Fine-tuning, for Pardeshi, is still a classical bet: only do it for a narrow use case where the gain beats waiting three months for the next frontier model, and accept that you lose generalization. Leaderboards are leaky and often ask humans which of two snippets they like, which is mood, not enterprise success. Gemini, OpenAI, and Anthropic can look close on SWE-bench and still be distinct in the real generation jobs you would actually assign. ARC-AGI is his exhibit. Models hit 76 percent on ARC-AGI 1; ARC-AGI 2 did not get harder, it got different, and scores fell under 20 percent. A five-year-old would look similar on both. Chollet's academic AGI — adapt to a pattern you have not seen — is not the same as human-level performance on a broad task list. That is why he is bullish on test-time training for code, where compile and tests give a signal, and why he thinks it becomes practical in one to two years rather than today.

Security of generated code is shared responsibility. Labs test jailbreaks and refusals at training time; the attack surface still depends on whether the user talks directly to a model, as in Claude Code, or submits a plan that Blitzy may or may not honor. A quieter hole is the knowledge cutoff. Most models, he believes, currently sit around January 2025; libraries patched after that date will be used stale unless the system looks them up. Two practical defenses: write known attack vectors as defensive tests that every job must pass, and run a CVE scanner such as Snyk before the pull request. Blitzy runs that precheck and tries to fix findings so the customer does not have to. Code, compared with open-ended chat, is the easy case to protect.

Labor, he splits by horizon. In the short term, code is a commodity. A script that used to be gold is a prompt. A junior cannot always tell whether that script will destroy production, so the market weights toward seniors who can review. In the medium to long term, tools get better at intent and at preventing unintended outcomes, and mid-level and junior engineers who use AI already perform at senior velocity inside Blitzy. Depth, speed, and system knowledge are increasingly available from the model. Seniors who cannot get over "I only trust code I wrote" will struggle; juniors do not have to unlearn. The company has hired senior, mid, and junior, plus high-school interns last summer to automate leaderboard runs. Cash compensation he puts between $100k and $300k, equity separate, with room to pay more for the right talent — and "right" is now as likely to win a greenfield hackathon as to have built many legacy systems.

Labenz says he will turn the transcript into a to-do list for his own personal AI infrastructure, which is a fair summary of what the episode is for. Measure the effective context of the model you actually use instead of trusting the brochure. Put documentation and test coverage into the codebase before you generate, because that raises the floor for every copilot you already own. Use at least two companies' models to review each other. Write specs that name the trade-offs, because as the system gets stronger the bottleneck moves to intent. Keep your QA process, and demand a human-completion report that says what did not finish, why, and how long it should take. Put security checks before the merge.

Elliott's closing vision is unchanged from the opening bet. Human developers should be solving edge problems and applying technology in ways that disrupt the business, not worrying about packaging and QA. Whether fully autonomous enterprise software arrives first through raw model intelligence, through orchestration, or through people getting better at saying what they want is the open race. From this conversation, Blitzy is trying to push the first two further than most teams assume is possible, and to make the third into a product loop: spec, PR, refine, then spec better next time.