Infinite Code Context: AI Coding at Enterprise Scale w/ Blitzy CEO Brian Elliott & CTO Sid Pardeshi

We believe we can get AGI type effects out of non AGI LLMs. And so, as folks are thinking about the impact of artificial general intelligence, they're talking about huge swaths of work being able to be done to provide economic value autonomously across domains. That's one amongst many definitions that is a moving target for defining AGI.

And so the core question is, can you achieve that output with the limitations and constraints of LLMs? We might be the most bearish on LLM capabilities as a pure standalone single LLM asset and the most bullish on the orchestration of those in long running complex systems.

there's so many, right? And being so forward on the limitations is what allows you to build something really powerful and really magical, right? So context is one, but there's a difference between a context window and an effective context window, right?

So as you start to eat into, let's say, 20%, 30%, 40% of a context window, there's a depreciation that occurs. Each model is a little bit different. There's lots of different ways to test this with self in house benchmarks.

But you start to lose intelligence and quality as you start to fill up even the advertised context window. The depreciation is a little bit different by even task type. So what you want to do is really effectively manage the amount of work and the type of work that you are loading into a context window while also pulling out anything that you don't need.

So that's like that's a more nuanced view on the limitations of a context window. The other limitations right are how many tools an individual agent can effectively call. It used to be that they could call zero tools, it could call one, two, or three, and then call eight or 10, right?

And then tool selection in the agent itself is also something that you really need to understand, steer, and give only the correct tool access to. You think of tool as calculator or a compiler or sort of like any outside entity that one is doing. And then, like lastly, it's maintaining long running intent of the human, right?

Or like intent of the machine or instruction, right? It's a byproduct of context management, but it sort of has to do with attention in general. And so if you can design a system that says, great, LLMs are a very, very cool probabilistic type of computer.

They have all these, you know, limitations at least when when leveraged as a single instance. And then if you can accept those limitations and then and then build the the harness or the cognitive cognitive architecture, you can you can really create something that can do AGI type effects.

let's put a pin in a point of of not to just use one family of models at all to do this, and we'll cover that in a second. And let's talk about how you sort of manage this information. Right?

So a context is serial, information is relational. Right? And so like that that email connects to that thing that you said in the Slack message.

Right? And those might be on different applications. And so the question is, what are the core relationships that govern this domain?

Right? So we put out a we put out a paper about domain specific context engineering, right? But what is what is core is context engineering is not general.

It is domain specific meaning there is a core set of entities that relate in certain ways inside of the domain of let's say personal life or work life. And so you have to first understand and define those relationships and then pair that with semantic understanding. Right?

And that is how you get closer to the context that might be important for any task while removing away the context that is not important for any task. That was like a very broad philosophy, but the idea that semantic clustering is sufficient really inaccurate.

How does that play out? I'm sure it's a know, again, it's an analogous thing. How does that play out in the context of a giant enterprise code base that you guys get your hands on?

Yeah. Well, the approach that you're taking on that personal project will be okay at first and then get worse over time. Right?

So you're at the personal project stage of like a slower mid market software application. So I say like, you can kind of just shove all the stuff in there and you'll get some approximately right results. Like Gates had this quote, like if you could schematize the world, like you can get a computer to do anything.

And so in your example, you're trying to schematize your life, right? In the example of code, you really are trying to schematize code and the relationships in code agnostic of language. So you can throw, in the case of a Bixie, you could throw a 5,100,000,000 line code base on it.

And because we have a deep relational understanding that we built first, it takes a few days of compute to build that. But a deep relational understanding that we understand first inside of that code base, that is the base layer that allows us to do large amounts of work, development work autonomously. In your example, you'd first schematize your life.

That might be dates, it might be months as a group, dates as a group, it might be other activities as a group that relate to other things. You first and foremost need to understand what are the core relationships that govern the domain. And we have done that in a very, very unique way with code.

So when an enterprise starts with us, they ingest their code. It takes a few days of compute and we then have a deep and novel approach on the category of knowledge graphs but like that's maybe not sufficient to explain how deep the understanding is so that in any line across a 100,000,000 line code base I can tell you exactly what is relationally relevant down to the line level so that when I generate code, I am injecting and pulling out the correct context just in time.

Totally. And so if you think about the even like ASTs, for instance. Right?

These are, like, one of these tools, like version specific language, specific abstracts and text trees. These are, a pre LLM worldview of understanding the relationships and meanings between a language and version of a programming language. So you can think of what we've invented as a, it's not an AST but resembles the characteristics of an AST from accuracy that is programming language agnostic designed for AI agent traversal.

Right? And so that was like a lot of words, but you think like, go like globals, classes, variables, functional relationships inside of an application. And so by having the traditional, I would say, programming language agnostic relationships on top of actually building and running the application, which we do as we create relationships, you're able to create a much deeper understanding.

I think one of the powers is you're really not able to get understanding unless you are building and running applications and putting that through the paces to understand everything from what you said on the left side which is like dependencies to how things are relating when they're running production and have like actual logs running and understanding those relationships. So, you can imagine the spectrum of compile time, run time, production at load items that, like, a a software development team might look at, and those ultimately form the base of the relationships that, that physically schematized enterprise code.

in their cloud environment. Like, let's see, to get started, like one of the reasons that takes it's not days you know, zero minutes to get started is it's getting your access to your environment, getting all the necessary keys so that you can spin up these applications and run them. But it's cool because like as you, when you get large scale code outputs from Blitzy, you'll also see like the QA that we did and like the screenshots of us, of an us, an agent like clicking through and running an application in production.

And so that happens both upon ingestion to make sure that we can run and build the application and then add cogeneration as we go through QA. We like running the application is core to getting high quality code because you need a recursive correction loop when not just something doesn't compel and compile and build, but it doesn't act in production how you're expecting it.

production application is, like, I'm sure it's not trivial in many, many cases. You need, like, you need to see the database. Right?

Like, in there there's there's, like, real implementation work. Right?

a sort of ready plan for how you would even do that. Right? A lot of applications, insurance for every reason of all places, like, they just really have no way to provide us these instructions.

And so, like, what we'll do, we'll go through this iterative approach, which provides value even in the approach where we will take the information in which they think it takes around the application. And then like, let's see, we'll find a limit case of not being able to do it. And then we'll like, hey, like, hey, we don't have access to this package.

And they're like, okay, well, had no idea dependent on that package. And so able to kind of go through this process of actually creating the correct build instructions for the application that's essentially been sitting somewhat dormant that they want to activate or move over into the more modern technology stack as a part of getting Blitzy to stand it up. So we've provided value just in implementation, I would say, but it does come with obviously challenges.

Like there's lots of old enterprises, for instance, like to build the application. It's not as if you're just writing a script or a package. Like it requires what would have typically been a human and dialog boxes popping up and putting information in.

But Blitzy is sophisticated enough to spin that up and then put in user creds and were in their IP to build an application that is like you know, that's how Windows applications were built back in the day. And so it requires a real build sophistication in the application to get this level of fidelity.

we essentially made a bet that the models were gonna get faster, way better than anybody in the market expected them to get better. And so we started building for a future universe that wasn't here when we were doing the all of the design and all of the work of this cycle. It's a there's no MVP of Let's see.

It's like an end to end platform experience. Right? And so those the world that we built for over the last three years and the world in 2025 essentially intersected.

Right? These things were gonna continue to get really, really good, and and we were correct. And so when you are building systems for an ever improving state of LLM intelligence, you wanna build the systems dynamically.

So when people talk about building harnesses, they are like, they're sort of like hard coding and codifying actions based on the level of like LLM intelligence and capabilities, right? And so those harnesses depreciate as LLMs get better and you know, the level of depreciation is tied to how hard coded your design is, let's say, and the rate of intelligence increase. And so everything that we do in Blitzy is dynamic design, meaning Blitzy's agents are generated dynamically just in time.

Prompts are written by other agents. Tool selection is assessed just in time by context injection. Right?

And then the the the whole planning process, right, that governs all of this is sort of chunked and revisited iteratively. Right? And so in this, like, as the models get better, like, it's just great for us.

Right? Like, we can we can more or less just do just do more and it's a config file to toss in a different LLM but because everything inside of the system is dynamic, we don't feel the depreciation that one would typically feel when they're like building harnesses in that and I would say, like the classical way that folks build harnesses today. Like, for instance, right?

Like as a new model comes out, new prompting instructions for that model come out. Our agents just reference the latest prompting instruction tied to their model and then that self writes a prompt for an agent that's injected. And so it doesn't matter that the prompt guidance changes for the next Gemini model.

We will just go reference that. We, the agent, will just go reference that as this dynamically writing a prompt for another agent.

think it's important that your evals map onto the real world as closely as possible. So if you think about most evals in the world, they are designed to be easy, very easy for the human to evaluate, right? Like very easy.

Because it's like, alright, well, like, here's a function and here's a here's a different version of that function and and this other version is more accurate. Right? But that is a local optimization on an exponential technology.

Right? And so our evals are a bunch of applications that we've built over the years that are of larger scale. Some of them, you know, started on open source and we built their own versions of private applications over the years.

And so we're testing Blitzy on executing what we ultimately want to be a 100% outcome. And we're seeing how close we get to that outcome with the new configuration of Blitzy. Right?

And so we might give it a million line. Maybe we'll give it like Apache Spark. It's like 1,300,000 lines of code.

We have a custom configuration of Apache Spark from previous previous projects that we've done personally in life. We'll give those instructions and we'll be able to see very quickly, like, how close did we get to a 100% completion with this adjustment. And it requires an extreme amount of taste because if you're not a 100% there, you don't get to a 100% of result, the 100% being like what you did as a human in a previous life to get that to a 100%, You're now saying like, is this 85%, 88%, 90%, 95100%.

It's a difference between functionally correct which like BlitSec can guarantee functional correctness like, hey, we passed every end to end test, we passed every integration test, we passed every feature test But it may not be the final version that you actually intended to put in production. And there's always a difference between functional correctness and intent. And so it's that taste that is required to really improve the system and provide that feedback on top of the traditional large scale evaluation.

This is why I think it is really, really hard to build these systems without the right longitudinal experience to understand what great technical design and great implementation from a software perspective is. Like, we always say Blitzy is the instantiation of if you had Sid work at the time of compute, my CTO and co founder, because he's instantiating his technical taste into the outcome in a way that is really, really impressive for the enterprise. Well, of course, they can specify their own taste and their own rules and the system will respect that.

But that is how we do evals, which is at scale at a very large point with a lot of taste involved.

What am I seeing him doing? You are looking at the final output but it's really you're looking at the logs, right? And so these are we use Langsmith for logs and tracing.

Shout out Langsmith, big fan of the Langchain guys. This is their tracing product. So as you look at Blitzy logs, like if you were to type them out in a piece of paper, right?

Like and I put it on a scroll that would scroll all way down to the end of the block. Right? The amount of agentic interactions that occur at runtime are absolutely massive, Right?

Where you have somebody injecting context, somebody writing a prompt, somebody writing code, somebody reviewing that code, somebody building the code, somebody doing, like, before and after, like, local pass to pass, fail to fail, and then it's like that's happening to get a piece of functionality out in the bigger system. Right? So as you see these agents interacting, it's a lot like looking at your engineers, have a technical discussion on what correct might look like.

Right? And so what you need to do is you need to look at the final output of the meta harness, right, like the pull request here, and then trace back in the system. I didn't like what happened here.

What happened in the system? Right? And how can I steer the system to dynamically be able to address this kind of instance in the future?

It's a completely different approach to to building software because the outcome is a little bit emergent in a way and you have to build the system to understand how to dynamically steer and validate to get to the right outcome.

Because that sounds like its own Yeah. Really, you try to be as algorithmic as possible. As you think about chunks of work being completed, the first step that we'll do after receiving a future state spec from the client, which is like our system will work with you to get a future state spec of what you want, that's a web application portion.

As that's sent off to do work, then you start off a planning process or Blitzy starts off a planning process and then it executes against that plan. And so each one of those planning steps and each chunk of work, planning, reading, testing, validating QA, and doing that repulsively repulsively is driven algorithmically to get to an outcome. And so it's tweaking the algorithms that govern the system to get to the right outcome.

kind of fuzzy semantic matching, or do you also avail yourself of that and kind of have, like, this is what we were able to find structurally that's relevant, and this is also maybe some other kind of relevant stuff that sort of fuzzy matched you might wanna be aware of. Yeah. You really wanna you wanna use both as a hybrid source of of truth.

Right? And and then when there's when there's conflicts, then you wanna, like you the system wanna explore much deeper and much further. Right?

And so it's important that these the issue with RAG as standalone a item is sometimes people will rely on the RAG abstraction layer as the source of independent truth. To answer your first question directly, you want to use both relational understanding and a semantic understanding and you want to pair those as agentic tools so that you can arm the agent to use these different tools to go and pull the right information but you wanna use these tools as an abstraction layer to go search the source of truth. Right?

And so this is where you don't wanna you don't wanna rely on the semantic match to pull out the truth. You wanna rely on the semantic match as a map or a legend against the actual source of truth. Go efficiently search, traverse, and find that, and then pull the source of truth into the context window.

Right? So it's really an efficiency search mechanism more than it is a a a storage of truth mechanism.

Yeah. So this is all about the mechanism of the request between yourself and the model. And so in the instance of like, I have a fuzzy idea somewhere between some, some, some mental neurons on what I might want, like, you might actually be doing the most efficient, efficient item by, by just going through and searching.

But if you think about completing work, right, in a workplace, work follows some sort of structure. Right? And so in in software development, it it follows a spec.

Right? And so therefore, like, you can express, and this is how people will do it. They'll express what they they're roughly trying to achieve with Blitzy.

It'll go look against the source of truth and it'll come back with a plan in the form of a future state technical specifications like what architects deal with all day to go do that work. Right? And so until you can provide the system, the right structure of output, it is unlikely from a system level to go and sort of do your bidding correctly.

And so then the question is like, how do you create the right interface experience to enable humans to enter with a fuzzy output, get confirmed on a structural strong output and then send that task off to the system versus the experience that you just described which is fuzzy input is sort of all you get, right? And so that some people use like chat for this, right? Which is like, I'm roughly thinking about this idea.

I think it's this thing tied back to this date. Then it can say, Oh, like is it any of these possible things that you want to go explore further? That's an intermediate abstraction layer ahead of the true deep search.

So it's all about creating an intermediate experience between the system of intelligence, the system of record, and then how you're sort of expressing that ask.

and kind of sanity check at that level. So it should have clarity basically on on exactly what it needs to be reading. That's right.

And what's what's super important is, like, the system, like, is capable of doing both steps. Meaning, like, I can provide you what I'm trying to do inside of my, like, 30,000,000 line trading system. Right?

And then you can come back and like, let's say come back in about an hour after you give it this, let's say like what a page of general instructions that you're trying to achieve on the code base. And it'll come back with a very in-depth implementation plan because you didn't think about like the edge cases or the services that it might touch, right? It's an the whole point is it's impossible for a human to grok everything that might affect.

Right? And so, like, that is sort of phase one of system interaction being like, hey, heads up, like human with limited human context window. Here is the plan that you said expressed against this enterprise code base.

And like, here's a bunch of things that we're gonna have to do to implement this that like maybe you did or didn't think of. By the way, if you wanna do this a different way, that's cool too. But like, let's let's assess and make those trade offs before we go off and write 100,000 or 1,000,000 lines of code.

And so that experience of leveraging system intelligence to generate a clear version of work is required as phase one in order to do like large volumes of work in phase two.

Yeah. And so maybe I'll start by saying how we recognize failure in our system and then maybe we can map it onto your own passion project here, Rich I love. Inside of the Blitzy system at runtime, we are doing as much work as we can autonomously.

You can think of it as spec and test driven development at the time of compute. And we'll retry and re loop and recursively go back and self improve between running the application and getting the featured outcome. But at a certain number of attempts, right?

We have to say, okay, we can't do this part, Right? And so we have a separate and independent evaluation system that figures out what the desired end state was, what the system was able to do, and then writes the doc for, men. Optimally we get to this end state, like this is the most likely path that we believe a human could do that the system can do.

So you need to sort of build these mechanisms, these systems, the system of work, the system of QA, the system of evaluation to operate somewhat independently so that when you get the output, as a part of the output, you also get the report on what the system failed to do. And we always call that, that's like the human completion part. And so getting these to be really accurate allows you to move with confidence.

And so for us, that's a project guy that says like, Hey, these functions or these parts of the application, we need your help. By the way, did all of this work. We passed all these tests.

Here's the QA and here's the screenshot. So you can feel good on that. Go review that code, but go spend your time on this part.

So if we map that onto yours, you would need to have, this is my intent, my intent, get some work, that work has QA involved or cursively ahead of it getting the outcome and also a separate system to evaluate and grade the effort of that. Both of those artifacts should come to you and both of those systems within your application should be independent in nature. Like a report card.

Give us a tour of the Model Zoo. Yeah. So we use the three major families of models in in Blitzy today, OpenAI, Google, and and Dropic.

The other ones are great and and maybe incorporated in the future for for different purposes. Right? But it's very clear.

The researchers, like, preferences are, like, somehow expressed in these models intelligences. And that they're very, very smart in sort of, like, different ways. And they're much, much smarter when you compare different families of models and have them review each other's work.

Right? And so if you take, like, if you if you took Opus and Sonnet from Anthropic and had them compare each other's work versus versus an OpenAI and Anthropic model, you're gonna get demonstrably better results by having a different family of models review or, you know, different different companies review work, at least in all of our our experience. Right?

And so that is super interesting. And it it changes every day, but, like, first pass code gen, like, Anthropic remains really, really strong. Structured output and code review, great results from OpenAI.

Like, by the way, what I say here will probably depreciate by the time the podcast even comes out. And Gemini has been better for long horizon work, task checking, task lists, keeping things progressing. Right?

And so that's, I don't know, date, time stamp this, like, towards the January, and I'm I'm almost certain that it'll probably change by by the February.

unfolds itself? Yeah, and you can think of an example of a dynamic algorithm rule would be like, you can pick the one that you think is best for this situation. And also, the reviewing agent must be one of these other options.

And so, we're not constraining the choice. We're sort of then constraining the selection of choices in the review model. That's an example of a sequence of steps used in validation that is dynamic in nature, not like you must use Gemini then you must use OpenAI for instance.

And then you asked about fine tuning, right? And so this is a fine tuning is a like a last mile optimization, I would say, and not a bet on dramatically better improved models. And so fine tuning is an expression of essentially, I can't get enough correct context engineering within the system and I can't get the right results.

And so, there's a place for it in the ecosystem but it's like as soon as you fine tune a model and the next one comes out and it is more raw intelligence, you're basically out of luck. And so we are much more bullish long term on what we call memory. And so you see a very shallow instantiation of this in tools like ChatGPT where it will start to sort of remember your preferences.

But there's a lot of memory that occurs in the enterprise environment. Right? And memory is another way to express both relational and semantic understanding, but with a lot more signal of truth.

Right? And so we very much believe that to get to a 100% autonomy within an enterprise workflow, you have to sustain memory of the actions of the best people and what they view as correct and then sort of store that in your instance in the enterprise's instance of the platform in this this in this situation, the enterprise instance of Blitzy. And that's how, like, even after the architect retires, that is the only one that knows, like, that system that enterprise itself has that IP in their instance of their AI system.

Long term memory, I don't believe, will be solved at the LLM level. So, LLMs have so much momentum beside them that, like, another architecture, even if it were to solve for this, like, will not get the level of intelligence required to to to execute what these systems need. Right?

And so the like, memory is a problem to be solved at the system and sort of like by system, like the application layer, the system layer. And that memory is sort of is application or sort of domain specific, like to what is important to remember in what instance. Right?

And so memory, right? You can think of even memory as all the way back to the traces, The Lang Smith traces, like a series of steps was actions. The series of steps were driven by decisions that you chose to put in context.

The decision to put something in context might change in the future based on what you've learned from the way the enterprise expressed work. Right? And so this is tying all the way back to your context management system.

Like, that's where you're storing memory and preferences based on actions, not based on not based on model weights.

breakthrough that It will certainly Like, I I hope for it. Like, I really do. And even, like, some some expression of memory in the model layer will will, like, ease the burden on the on the system layer.

Right? But when it's, like, how how much memory and like, to give you maybe a specific example, like, if you think about memory at at a enterprise code base layer, right? The things in which one needs to remember are extremely locally specific.

Right? And so a memory on an enterprise code base is not universal. So it's not use this payment provider service over this payment provider service even though my enterprise has nine.

It's, hey, when I when you interact with this cluster of context, you need to use this service even though to you they look relatively functionally equivalent. There's some organizational or contract reason in which you need to use this service. Right?

And so that is so local from a from a contact interaction perspective that impressing global memory at the model layer actually has severe limitations. And so the question is, how do you bifurcate global truths or global memories, which people instantiate with rules today to try to manipulate these models to do what they want. How do you instantiate universally true long term memory and the weights in the models because these are more brute force levels of intelligence while keeping locally contextual memory based decisions at the system or at the application layer.

got to be lost. That every problem I feel like is a search and compression problem at the end of the day. And you're trying to get rid of much as little loss at compression as you can and using search to try to minimize that.

But I think about search and compression like all day.

with LLMs who lack it. Sixth sense of, yeah, there's something here that I I kind of know I need to go, and I kind of know what I need to get. And if you were to look at, like, how Blitzy spends time as, like, the representation of the best cluster developers at inference.

We spend a huge amount of time in planning and system understanding and impact analysis, meaning like, let me really methodically think through this and then let me spend a lot of time figuring out everything else that this is going to affect. The code generation is relatively fast. And then a bunch of time on QA and validation and recursively improving the code based on what you're trying to achieve.

But writing a million lines of code is as fast as you can stream tokens. Our runs are as short as 12 as long as like a few weeks, it depended but it's a huge huge refactor, right? And so it's as you break that up, it is that wise developer motion of let me sit back, let me plan, let me think, let me think about everything this is gonna impact across the system and then let me implement as opposed to like the the junior dev which is which is just rocking code on on minute zero.

You could maybe characterize what that looks like and also what do you think the reasons are for it? I mean, some things, I guess, are just sequential. You got to plan before you can execute and so on.

But yeah, that's plenty of prompt. Take it from there. Nice.

Yeah. Good structure prompt there. So let's let's talk about parallelism and the limits of parallelism.

Right? And this is like, when you think about the work getting done at the system level, this is a a core topic understanding within the domain that you operate. We operate in enterprise software development.

What sort of work can be done in parallel versus sequential, because trying to do everything at once is a surefire way to get really, really bad results. Right? And so just like a an engineering, right?

Like an engineering team will like look at an epic, They'll break it down into tasks, and they'll realize which tasks depend on what. Really, that is a huge part of what is happening at the planning phase within Blitzy. We are deciding based on, like, software development fundamentals, like thing x depends on thing y.

Therefore, we have to get x to build, compile, and pass tests before even starting on thing two here. So we must do it in that sequence. Right?

And so that is what is for us happening at the planning stage, which is parallel versus sequential tasks that is just a software development problem set. Now in other domains, like there are there are other ways to think about, like, what can be done in parallel versus what can be done in sequential. But in engineering, it's it's very easy to grok, like, what is what depends on what in a sequence of work.

And therefore, we have a a system that algorithmically works through and assesses that. So that is that is the answer on on parallelism. Like, we wanna do it as high quality as possible, which means in the instance where the system is not entirely sure, it'll assume sequential in the instance where it is extremely sure that it is is parallel or do it in parallel.

Right? And so it's sort of like a a tolerance preference on quality, which will answer your first question, which is paying more to get better results. Right?

Our our thesis is, like, we will pay any incremental dollar. We will write any incremental algorithm. We will really do anything within the system to improve the quality of the code.

Right? All the way to fully autonomous and oppressed offer development as the goal for the company. And so, like, we we are not, in our our opinion, cost constrained because the other side of a pull request is human labor.

Right? And so like I would much rather have that human be working on problems that are on the edge, that are truly innovative, that are thinking about absolutely disrupting the way that they're applying technology to their business than I would have them spent on vanilla application development, just a regular annotation. They've already expressed their preferences vis a vis Blitzy on the technical design that they want implemented, and then they're handing off that work for us.

And every ounce of work between let's see, which we typically do 80% to 90% of the quantum of work and then we'll call out what we need the human developer to do. But in the vision of the company, remaining work, which is just traditional configuration, QA, that's a bug. That's a bug in the system towards the vision of the company because software developers are problem solvers.

Their engineers are problem solvers at day zero. And if we can have the world's smartest people working on problems on the edge, not worried about package incompatibility or QA, we've done a great service to humanity.

safe of a line in the sand has that proven to be for you? Yeah. If if we have to increase prices, we will.

That's like our our sort of going in point to, like, not in the act of contract engagement. Like like, if we if we have to dramatically increase computer, we can dramatically increase compute to get to a 100% autonomy. Like, we'll do that and our customers will sort of coast off of that in the sort of duration of their contract and then we'll have to right size it.

I'm not necessarily worried about the the gross day zero versus the value created day zero. So, like, yeah, it's an attractive business today. Absolutely.

That doesn't matter. What matters is the amount of value left to be created is so high that, like, if we close the gap from 80% of the work to be completed autonomously to 99% of the work completed autonomously in a year from now, like, the net new customers are gonna be so happy, more than happy, to pay more money because they're able to do so much more, right, with the same amount of people. And so as you think about really the delta of value creation that you're thinking about, and you always wanna just push as hard as you can on value creation because the market size for software development so 1,200,000,000,000.

0 in labor, but, like, that is an infinitely expanding market. Meaning, software is designed to fix the problems, productivity of of the customers. And if you're telling me that, like, we're out of problems to solve sort of with software, like, that that's where I don't sort of believe you.

And so our market size is capped by the problems that can be solved with software. The goal is to get to a 100% autonomy and in a way get to, you know, eighty, eighty five, 95%, which is incredibly and deeply valuable for the enterprise that wants to move incredibly fast. Like, they're thrilled with this, thrilled with this level of autonomy today.

And so you can't you can't let a short term pricing decision dictate the technology decisions when the value creation is so high.

The typical enterprise has very little documentation and very little test coverage. So those are the first things that we actually look to address with Blitzy. And the awesome part about this is by addressing documentation and test coverage with Blitzy, you actually automatically increase the effectiveness of all of the AI code gen tools that are in your stack, which like we highly recommend you have the the individual developer productivity tools as a part of that stack.

So you kind of get like super fast time to value as you're sort of getting implemented. Right? And so as you as you ingest a code base, there's opportunity to provide what documentation you do have.

What's super helpful here is like, if you have domain specific information, like domain as in like, I'm in finance. And when we say this in our code comments, like, this is roughly what it means. But there's an iteration process at ingestion where we're gonna provide you a spec of here's everything as we understand it today within your code base.

Everything that is everything will be technically accurate to what we can surmise technically, but they're the product portions, right, where we're expressing what you're trying to achieve there is where we'll have an iteration period where we'll say, here's the blank slate without any information, and now let's provide the system the information. And not by not starting at zero as in, tell us everything that we don't know. Well, like, here's what the system can technically understand.

Like, all of your dependency diagrams, all the variables are all classified technically correct. Now find out for what from a product perspective we should have as additional context, provide us that, and then we get off and running. Right?

And so that is the process to get to truth from a spec perspective. But you also have to remember that the spec is human readable abstraction of the truth. And because in context, we're always using the actual source of truth as in going back to the source code and pulling that into memory just in time, the spec can be like the product spec can be a little bit inaccurate at the end of the day if you are instantiating new like, if you're if you're moving from, like, c to rust, like, it doesn't necessarily matter if this thing in the spec, which is defined to be human readable, is exactly precise versus the fact that we can go and run the application and then mirror the exact effects on the other end in the case of a language translation.

When you're doing product development, which we do, like, I would say half of our businesses, large scale modernizations, refactors, of our businesses, the steady state product development acceleration, that's when you want to be a little more prescriptive and a little more precise because the system will be using your product expression from a sort of like, hey. We're doing this in finance to then go and make further decisions.

with It's no from go to pull request. It's from go to pull request. It would be an impossible task to try to insert a human into this process.

The way that you would do this with agents at scale, it just doesn't work. The only thing that stops, which is at the beginning of the process, is if we are missing an environment variable or something from a configuration perspective to actually build and run the application. And so you could find that out.

You could build, run, and then try to be adding some net new piece of functionality that actually calls a service that you you didn't need to run the initial application. And so in that instance, it'll notify the the customer in Blitzy that says like, hey, we need we need access to this service and this wasn't a part of implementation or setup. But from a sort of spec to pull request, it's all agents again.

Sort of has to be.

I mean, the point is, right, like, the system can't do something, like, it it goes on to the human report for the enterprise. Don't have to be a 100% off the gate. We pass unit tests, integration tests, end to end tests.

We sort of do all that, but there's whatever remaining work is a part of the ultimate report that goes out to be completed by the team. And like, that's an awesome that's an awesome use of lock code and awesome use of cursors. People pull that report down.

They go deep on whatever edge case that Blitzy could install. They get that ready to go into production. They go to QA.

They go to merge and then they start their next sprint with Blitzy. So the system is sort of designed to account for the fact that we wanna accurately do as much work as we can and then say, great. The human the human pickup is on the back end of this pull request.

Yes. It's typically items that we think were not captured in the testing strategy, right? And so maybe as like a double click in, right?

Anytime Blitzy touches any file, we're doing unit tests before and after. As we do clusters of context, we're doing clusters of work, we're doing integration tests between services. We're going to the end, we're doing end to end tests at the end.

And so there'll be some instances where, let's say, were like, oh, we passed, like, 73 of 75 tests and, like, for whatever reason, like, let's see what change things to fix item one, and it'll break item two. And it'll change things in item two, and it'll break item one. Right?

And so the system will say, great. Like, we're 73 out of 75 from an end to end testing perspective. These are the sort of files that we're undulating between back and forth.

And like you need to sort of go in as a human and figure out like where there is conflict between these two services because our system is sort of gone back and forth so many times. It's why, like, the task has hit an impossible one, which is kind of funny. You're like, oh, okay.

You're you're asking for two contradictory things in your spec, and and this is, one way to approve that when you're asking for opposite things. Sometimes it's configuration stuff. Sometimes it's just QA work.

And so as a part of the report, we'll break down the tasks remaining and the estimated hours to complete those tasks for the human teams and who would be responsible from a functional skillset perspective. So some testing strategy we didn't get to 100% that we can align on. And then some plan for code review and QA is really included in that, what we call final 20%.

have large customers that will get a Blitzy poll request. They still go through dual review PR strategy. Like, I I recommend that, like, whatever your QA process is, like, you should continue to do that for the foreseeable future.

But for anything else for regulation purposes, like, won't touch a line of Blitzy code, and and they'll press merge. And so those customers are unbelievable at expressing intent and doing spec driven development. For a large majority of customers that are not as far along that curve, what they'll do is they'll express intent, they'll get a spec, they'll get a code back, and then at the code step, they'll realize, Oh, I didn't consider this outcome even though it was maybe expressing the spec, like I'm moving so quickly.

And so we had to build with the product the ability to refine further from there from the Blitzy platform because people aren't used to today doing two or three months of work, making those decisions. You used to be able to get to month two and then figure out the nuance between month two and month three. And so you have the ability, once you get into the code, realize like, Oh, I didn't express this implementation the way that I would have preferred it.

And it was hard for me to really conceptualize what that would look like between spec and implementation. They can just go back and they can refine that existing pull request and let's say they can provide their updated guidance like, hey, I actually like on the implementation of this portion, like, I wanna use this approach and then it'll run for a much shorter amount of time and sort of adjust the existing PR to their preferences. This just has to do with existing patterns or behavior today.

But what we'll see is folks will go through this flow as they're getting familiarized with Blitzy and refine that larger amount of work once or twice. And then they'll naturally start to get really good at expressing their intent or identifying it at the spec stage because they are going through the muscle of basically being a systems level thinker, a systems level architect, and getting all of that implemented.

is fine. Cheaper is fine. But if you think about the instance that I walked through with the different end to end tests going back and forth failing as the code was like recursively going back, ran the application trying to fix it.

But like today, our system will just be like, those two things happened and like, go look at it, human. We're like, we're stuck. Right?

Like, if you had more raw intelligence, it could very prescriptively be like, hey, this is exactly why this is happening. Here's the trade off decision that you need to express to us. Which one of these routes do you wanna go from a trade off decision?

And I can go and implement that. Right? And so when the the trade offs themselves, which are sort of complex, can then be completed or understood by the model itself, like, it could then come back with two different pull requests.

Both of those with the end to end task fully passing, you're like, hey, I took trade off one here and trade off two here. And those are the only two logical trade offs that you could have made as opposed to, like, I couldn't solve this problem, like, over to the human. So we want more intelligence.

It is going to allow us to go further in situations and it'll allow you to be less precise at the spec stage or have to be so forward looking in your technical design.

I said we've gone pretty deep. I was going to have you join in if there were some nuggets you wanted to drop and add in here. But just as an introduction here, Sid was prolific inventor at NVIDIA.

He's been thinking about building large scale software systems since he was a little boy, actually. He's got great stories about taking computers apart and building software when he was a little kid. And he's really the inventor of a lot of the core technology here at the company being large scale context engineering system that unlocks the ability for us to understand 100,000,000 plus line code bases, long running computer orchestration systems.

Sid Purdeshy, welcome to the Cognitive Revolution.

vectors in which they would effectively fail for any given use case. And from a from an overarching perspective, like in information theory, they call this concept entropy, right, which is sort of the the the outcome of a probabilistic system is has high entropy in the in LMs or probabilistic systems. And so the goal of the or the the purpose of the system and application layer is to reduce entropy to get to reliable outcomes.

And so, like, the techniques in which we're describing reduce entropy to get closer to a desired truth.

And, Sid, maybe you could comment and I think it's worth with having Sid comment on the path from where we are today towards fully autonomous enterprise software development.