theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems | Neeraj Deshmuk, Blitzy | Neo4J GraphSummit NYC 2026

Clips
More from theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems

Neeraj Deshmukh

Director of Engineering

Blitzy

play_circle_outline Hybrid Graph and Vector Context Engine Orchestrating Code-Generating Agent Fleets

play_circle_outline Knowledge graph as linchpin for autonomous software development

play_circle_outline Infinite context via synchronized knowledge graph linked to SCM

play_circle_outline Security, governance, compliance designed into agent/code processes

play_circle_outline Graphs vs vector search/relational DBs: capturing relationships at scale

Info

Neeraj Deshmuk, Blitzy | Neo4J GraphSummit NYC 2026

Neeraj Deshmukh

Director of Engineering Blitzy

search

John Furrier

>> Palo Alto Studio Connection, Silicon Valley and Wall Street. I'm John Furrier, co-host of TheCUBE, here with Dave Vellante, my co-host. Hello, I'm John Furrier, host of TheCUBE. We are here in New York City for GraphSummit NYC. Of course, we were at GraphSummit in SF a month ago, talking to the practitioners and the leaders and the partners of Neo4j and the ecosystem, growing community around graphs, knowledge layers, knowledge systems. Anything to do with data platforms and AI, whether you're hearing ontologies, context platforms, variety of different needs, but it's all doing the same thing, putting real-time low-latency data to AI software-enabled systems without changing the data. Neeraj Deshmukh, CEO, Director of Engineering, Bloqade. Congratulations on your funding. Welcome to TheCUBE here at

Neeraj Deshmukh

>> Capital

Neeraj Deshmukh

>> you. Excited to be here today. Yeah, this has been an amazing event. We're talking about knowledge layer for trustworthy AI. That's pretty much the bread and butter for us, using a knowledge layer for developing software autonomously at enterprise scale, which is what we do. And so it's been amazing to be here and be a part of this event.

John Furrier

>> I think you guys really represent the template for this whole agent thing because it's not just productivity for software development. You're making it autonomous, which means you have to know a lot of things. You have to know all the code bases and you got to have agents taking action. is that the right repo? Is that the right software supply chain? There's a lot going on. Explain the nuances of what you're doing.

Neeraj Deshmukh

>> I think when people talk about changing software autonomously, the biggest problem is not whether AI can write code. It's about does AI know or understand the system that it's writing the code for? And the reason that understanding is crucial is because I may be changing a line of code here, but it may have downstream impact somewhere far away. And your typical kind of coding agent tools are simply not capable of capturing that vast amount of context in a single session. Right. And so what we are trying to do is basically make sure that within our agent orchestration platform, where we have a large number of agents doing code generation on various parts of that codebase, all of them, each of them has access to the right information at the right time in the right place. So each agent knows exactly what part of the code they're supposed to modify and what are the downstream impacts of that, where do those code paths lead. And the reason I'm here today at Neo4j GraphSummit is because that knowledge graph is a graph, right? And so we—

John Furrier

>> it has relationships.

Neeraj Deshmukh

>> Relationships.

John Furrier

>> And code has relationships.

Neeraj Deshmukh

>> And code has relationships. Fundamentally, code is a graph because you think about, oh, we have modules, we have files, we have functions, we have objects, we have classes, variables. Each of these are entities that are related to each other. So even before you bring AI into the picture, a codebase is a graph intrinsically. And so when you use something like Neo4j to represent that, mirror that structure, it really helps us in encapsulating all of the information and then associate every node, every entity in that graph with the appropriate metadata, which we represent in vector form. And so the vector graph hybrid is basically what gives us that powerful knowledge representation.

John Furrier

>> Yeah, I'm smiling because anyone who's studied computer science and done any kind of compiler design, automata theory, state machine representation. It is graphs.

Neeraj Deshmukh

>> Yes, totally.

John Furrier

>> A node and an arc is a construct And by the way, you can recurse through graphs.

Neeraj Deshmukh

>> Yes.

John Furrier

>> And it's mathematical.

Neeraj Deshmukh

>> It's mathematical.

John Furrier

>> So you have a compatibility of AI, which is math, and GPUs take math data and process math. That is the fundamental lingua franca of AI.

Neeraj Deshmukh

>> True that.

John Furrier

>> That is the key.

Neeraj Deshmukh

>> Absolutely.

John Furrier

>> How much do you think people know about this? Because that makes the graph even more special. Because most of the data processing systems like CPUs process packets.

Neeraj Deshmukh

>> Yeah.

John Furrier

>> But I think convert data to math, math to math, whether it's NVIDIA or TPUs on Google, it's all the same. Math is math.

Neeraj Deshmukh

>> Math is math. And it's certainly, as you said, it's the language of science, it's the language of AI as well. I think a lot of people in the R&D community get that, right? They understand it. I think it's more, Like if you go beyond that, then you start saying, oh, yeah, that seems to be the buzzwordy thing right now. Like, oh, let's try a graph database here without truly understanding what kind of information you are trying to capture in that. Neeraj, this is a good point.

John Furrier

>> I want to just double-click on this. I think it's a notable insight we're riffing on. One is that NVIDIA was misunderstood by the mainstream market for many, many years. Anyone who was inside the Valley or in tech knew what was coming. They knew matrix multiplication, floating point, and the kind of math side of things was going to be big. And now everyone loves NVIDIA because the results, the results. You can't deny the results.

Neeraj Deshmukh

>> Yep.

John Furrier

>> Okay. Jensen flexing, he's a superhero now, flying from place to place. But now graphs are on a similar trajectory. What are some of those results? Because this is really fundamental because NVIDIA wasn't fake it until you make it. They actually had the real deal, graphs have the real deal, seeing it everywhere. What examples can you point to saying, look, this is the next thing and here's why?

Neeraj Deshmukh

>> Yeah, I think anytime you have a really complex relationship with a large amount of data where you are trying to model the variety of relationships and the extent of relationships within a single structure, a graph database is your friend. Oftentimes people don't have the understanding of the kind of data that they have, and that's the kind of relationship that they want to capture. But once they do, I think it's a no-brainer that you want to go with a graphical representation. For us, we are talking, we are in the software development business generating code autonomously. For us, the knowledge graph is the linchpin for everything that we do. And you can think of it like a human developer would do, right? you first understand the code that you want to work with.

John Furrier

>> Yeah.

Neeraj Deshmukh

>> And then you're going to use that knowledge to do additional work.

John Furrier

>> And what you guys are doing is interesting because it's not just Copilot code assistant, right? You're— and you're impacting projects. Yeah. End to end. And hallucinations, getting the wrong answer isn't right. It's like robotics. Again, safety comes up a lot in robotics. That's physical harm. You don't want your car to crash. And certainly any robot manufacturing to humanoids, there's a human danger involved physically. So there's a, life or death in getting the right answer. Financial transaction code that runs well or properly run, not maliciously. So there's a lot of consequences to not getting it right. Speak to the quality piece.

Neeraj Deshmukh

>> Absolutely.

John Furrier

>> And then we get to the ROI.

Neeraj Deshmukh

>> This is actually my favorite part of what Blitzy does. So we are a System 2 AI platform. What that means is there is a tremendous amount of attention paid upfront to planning, scoping, and validation. And validation is baked into pretty much every aspect of what we do. So the first step, of course, is that reverse engineering stage, creating that knowledge layer, right? That dynamic knowledge graph. But once you have that and now you want to do something with the code, and you specify what you want. You don't have to go into the chapter-and-verse detail, but a high-level description of what that target state looks like, what are the constraints, and what are your success criteria. Those are the three things that we absolutely need. And as clear and precise as you can be in specifying that is going to be really helpful. But we take that information and our agents will then use that knowledge of the existing code to come up with a spec, effectively what we call an Agent Action Plan for how we're going to turn that requirement into real code. All right. And how are we going to validate that? How are we going to test it to prove to you conclusively at the end of the process that this is actually what you are asking for?

John Furrier

>> Real validation.

Neeraj Deshmukh

>> Real validation. So this is a human-in-the-loop process. Once you approve that Agent Action Plan, then the agents go off and start coding. Every line of code that gets written is immediately tested. We build your code, we run your tests. If you have a CI/CD platform, if you have integration tests, if you have end-to-end tests, we can plug into those frameworks, we can run those as part of our code generation. And so something goes wrong, say a test fails, our agents go back to find the offending piece of code. They'll fix it, they'll rerun the test, and we keep iterating over that sometimes for days or weeks on end. So it's unlike, as you said, any Copilot or coding agent which will come back in a matter of minutes with a result. We are off to the races doing stuff for days or weeks on end, making sure that we are creating quality at scale for you, which is fully validated. And at the end of that process, when we return that pull request to you with maybe a fairly large chunk of code, we have already proven to you that we have done exactly what you had asked us to do. This is how we have validated it. This is how we have applied your success criteria and delivered on that.

John Furrier

>> Talk about the relationship of the graphs, the knowledge graph and the orchestration piece. I think that's an interesting tie-in.

Neeraj Deshmukh

>> Definitely.

John Furrier

>> Talk about the efficiencies and what's the alternative? If you didn't have graphs?

Neeraj Deshmukh

>> So if we didn't have the graph, then that entire knowledge of every agent needs to know the code that it is modifying, but not only what it's doing locally, but what impact it has. And in order to figure out what that impact is, without a knowledge graph, you're going to have to do searches. You're going to do either a vector search or a grep, which is what a lot of these coding agents do. And what that means is you are gonna run out of your token context very, very fast because if you have 100 million line codebase, just searching through all of that and keeping those results and processing those results and doing this over and over again, you're gonna hit your limits very quickly. You're gonna start compacting things, you're gonna start basically losing information in the process. And so this just doesn't scale. Your effective token context is about 200,000 to 300,000 tokens. That's about 20,000 to 30,000 lines of code. Anything bigger than that and you

John Furrier

>> are—

>> So you hit a ceiling, you're

Neeraj Deshmukh

>> cooked.

Neeraj Deshmukh

>> You're going to start degrading your

John Furrier

>> results.

>> Obviously, you've got context, right? And it's got, you can basically eliminate half the paths,

Neeraj Deshmukh

>> right?

Neeraj Deshmukh

>> With a graph, you know exactly what you're going to reach because you basically get to pick the point where you want to start with. And you know exactly what is accessible. And so you have that effective context. Every agent knows the context that it needs to and nothing else. So you've basically eliminated all of the wasteful storage from each agent's context memory and only given them the information that they need to know at the time that they need to know.

John Furrier

>> So for people that don't know graphs, think of it like doors. Each door has a bunch of paths. You hop down graphs, nodes, ARCs, right? So it just traverses the right

Neeraj Deshmukh

>> path.

Neeraj Deshmukh

>> just traverses the right

John Furrier

>> path.

>> exactly what to ignore, which is efficient.

Neeraj Deshmukh

>> Yeah, because those paths, those other things are simply not on its path, so it doesn't even have to go there,

John Furrier

>> right?

>> That's where the token savings comes in. That's because you don't have that overhead of walking down every path, that's the wrong path, and then coming back, reasoning, eliminate that

Neeraj Deshmukh

>> path.

Neeraj Deshmukh

>> So if you've got Cypher now, you save reasoning.

John Furrier

>> Exactly.

>> All right, so where do you guys go from here? Because now you're going to have the coding machine going. And people love— again, I think the coding was the key event that opened up the agents because search is great, retrieval, RAG is great for doing marketing copy with the chatbots. But when you get into work, yes, coding's opened the door for the enterprises that, whoa, we could actually do more.

Neeraj Deshmukh

>> Yeah.

John Furrier

>> So it's kind of spawned the agent revolution.

Neeraj Deshmukh

>> So there are a couple of things, right? One is you can go bigger. You don't have to break a big problem into smaller problems. Which is your kind of traditional SDLC and the sprint model that people use of like, oh, we start with epics and then go to user stories, to tasks, subtasks. You can actually deal with projects as whole entities and do them at once at scale. And you're accelerating your development.

John Furrier

>> That's very key. I want to stop there to explain that because that's a huge nuance. Forget the sprint in Agile, all projects at once. Explain that, because that's the big breakthrough.

Neeraj Deshmukh

>> Definitely. So because you're not limited by the context anymore, Every agent has infinite code context, so to speak, The necessity that you had of breaking a big project into smaller chunks goes away because the reason you did that was you couldn't handle that entire context upfront.

John Furrier

>> Yeah, you had to break it up. Now you don't need to, just go do it.

Neeraj Deshmukh

>> Just go do it, exactly. And because you have that planning and thinking built into it, you have the validation and testing built into it. You can be assured that what you are getting out of it, backed by that knowledge graph, backed by that whole knowledge of the existing system, you are actually getting something that is demonstrably correct, functional, tested and abiding by your enterprise guardrails of accountability, auditability, governance, compliance.

John Furrier

>> It's an AI software factory.

Neeraj Deshmukh

>> It is.

John Furrier

>> Basically what you're saying is. All right, so talk about what you guys mean by infinite context. So just walk us through an example of what people have to do to get there. Because by the way, that's the holy grail situation. Do I have to ingest all my code bases?

Neeraj Deshmukh

>> So now you gotta have one.

John Furrier

>> You gotta have all the projects ingested.

Neeraj Deshmukh

>> Yes. So step 1 is basically the ingestion and the reverse engineering. That's where we set up the initial version of the knowledge graph. But your code is not a static entity. People keep making changes to the code all the time. So we typically plug into the source control management system that you have, GitHub, GitLab, Bitbucket, ADO, whatever it is. And anytime the code changes, we detect that the code has changed, we will update the knowledge graph. So it's always current, it's always synchronized with the state of the latest code that you have and whether that code has been changed by Blitzy through one of our projects or by developers working independently doesn't really matter. You are always working with the latest copy, latest version of the knowledge graph.

John Furrier

>> And, and since the agents are watching everything, they're talking to each other.

Neeraj Deshmukh

>> We actually— the agents actually don't have access to any of the customer data directly. Right. So we access the code through basically the standard API functions for the SCMs that they provide. So the platform takes care of that and then it feeds that code piecemeal to the agents. And that way, again, the agents don't have full access to the code at any point. A lot of our customers come from highly regulated industries. They're very concerned about, hey, who's looking at our code? What are they going to do with it? And so we built Blitzy from the ground up for enterprise, keeping all of those regulatory compliance concerns in mind.

John Furrier

>> So it's a first principle for you guys.

Neeraj Deshmukh

>> It is absolutely security and governance. Security governance is the foundation for everything that we do.

John Furrier

>> What about explainability?

Neeraj Deshmukh

>> That too. That too. In fact, one of the artifacts that we provide to our customers at the end of the code generation is a report that actually outlines the information about what we did, why we did it, the action plan, the spec that I talked about earlier. That's one level of explainability. And then the project guide, the kind of finished report that we provide to our customers tells about, here is everything that we did, here is how we tested it, here is all the evidence for that test, and here are all the things that we did not do. And that may be because we didn't have sufficient knowledge. We maybe didn't have sufficient permissions to do things. But here is a list of remaining tasks that your engineering team now can come in and finish.

John Furrier

>> Got it. All right. So talk about graphs. People out there now, mainstream. I like that NVIDIA example we riffed on because it's kind of true. No one saw NVIDIA except for the people in the industry. But now it's the number one traded stock. It's on the board for options. The results are great. Graphs are coming mainstream and a similar thing. And people who have been doing it have been seeing amazing results. What's the bull case? Obviously there's a bull case for graphs. Why should people get on the graph train now? Because it's moving into IT, it's moving into all architecture of data platforms.

Neeraj Deshmukh

>> Yes, I think the most important reason is that data has become so complex and so large-scale that your traditional models for keeping track of what you have querying it and accessing it are simply not scalable enough. You go to a relational database, we were talking about this earlier today in Emil's keynote, he mentioned that, right? You go with a relational database today, you're going like 100, 200 levels deep into your queries. Those queries are simply not sustainable, right? Ditto with vector searches. Vector searches give you a similarity metric, but they don't capture relationships. So what you need is basically something that does both. It gets you in the right area for the similarity metric using a vector representation of your metadata, but then it has to have a graphical representation also to capture basically what the relationships are. And so this is what we do at Blitzy too. When the agent needs to know exactly what part of the code I have to change, the agent is saying, okay, well, get me to the vicinity of the code. I'm gonna do a graph search. I'm gonna then follow the relationships using my graph representation. And Neo4j makes this possible because it's a single database which captures all of this.

John Furrier

>> Neeraj, this is a super fun environment. anyone who's done software in the computer industry knows how hard it is. You're director of engineering. You used to probably do performance reviews of people. And, "Wow, your code's terrible. You got good code." So now are you grading the agents? How is, 'cause now you're getting into, this slop has been kicked around. There's a lot of bad code. I believe bad code always dies. So the whole SaaSpocalypse thing to me is ridiculous. They gotta innovate. But how do you evaluate the coding itself like you would a human? And then does the role of the engineer change? 'Cause obviously they're gonna not have to deal with all the work by coding, They're more engineering. That was the title when I graduated college was software engineer. That was the actual title. They're more engineering now than they are a developer. They're not developing anything. They're engineering. Talk about the evaluation of the agents and the role of the software engineer.

Neeraj Deshmukh

>> Definitely. So the good thing about agents is that they're really good at following instructions as long as those instructions are clear and precise. If you leave them to their own devices in terms of interpreting things, funny things happen. But that's not what you want. You want to be clear in terms of what you want and you have to be clear in specifying what you want. And once you do that, agents are really good at following up on that. So we typically provide clarity in terms of the coding standards, the code quality, like there are instructions built into the platform. Any customer of ours can also provide additional information in terms of like, hey, here are our requirements for what the code should look like or what the code should be doing. And so we certainly applied those on top of our own instructions. And like I said, every line of code that gets written is tested immediately.

John Furrier

>> Right.

Neeraj Deshmukh

>> And so we create ad hoc unit tests for all of the code that we're generating. We run functional tests, we run regression tests to make sure nothing existing is broken. And then we are also running the kind of large-scale testing based on the success criteria that you specified to make sure that we are actually delivering on what you wanted. And so all of these together make sure that the code quality is maintained. On top of that, we have agents who are watching other agents to make sure that they abide by the spec, the plan that we had created and approved by the human in the loop. And so that ensures that there is no drift or hallucination, because the moment you find an agent kind of going off course, the Sentinel agents, they're like, Nope. Yeah. Bad agent, you. Get back in line. Discard the work that you're doing. Start

John Furrier

>> again.

>> The agent for the agents.

Neeraj Deshmukh

>> Agent for the agents,

John Furrier

>> right.

>> Well, Neeraj, great to have you on. Love the insight. And again, I was joking with an engineer, they're like, we love the context platforms. Just keep the agents out of the Slack channels. They start playing the humans against each other. Final question for you here. What's going on here in New York City at GraphSummit? San Francisco is a very robust environment. What's the vibe in the room? What are some of the talks like? What did you learn?

Neeraj Deshmukh

>> It has been super exciting. For me, the revelation has been just the range of use cases and the diversity of applications for Neo4j, for the graph vector database. It's been amazing to see the energy in the room. Everybody's been super excited about what they're doing. How they can use graphs to improve their individual use cases. And also equally exciting is what's on the horizon for what's coming.

John Furrier

>> Yeah. And the GQL language is now a standard. That's interesting. That's going to be awesome. That's going to be a good way to kind of— define the tooling.

Neeraj Deshmukh

>> Definitely.

John Furrier

>> SQL kind of standard, but, that's kind of changing the game.

Neeraj Deshmukh

>> 100%.

John Furrier

>> Don't need to do SQL. The intent of actually doing a query changes.

Neeraj Deshmukh

>> Yeah, we actually, our agents are doing graph queries all the time. And so I love the fact that Cypher is a language that actually is very LLM friendly, but also the fact that if you create a malformed query for whatever reason, let's say an agent hallucinates or whatever, creates an incorrect query, you basically don't get a result when that happens. You only get a result for a correct query. So there is no question of the agents working off of made-up information or something false. You're always grounded in truth of what's in the knowledge graph.

John Furrier

>> Neeraj, thanks for coming on theCUBE. Congratulations on your success of the venture. Love the AI software factory. I think I made that term up.

Neeraj Deshmukh

>> We'll give you credit for that.

John Furrier

>> Yeah. NVIDIA will love it too, 'cause they love AI factories. Yeah, the infrastructure is expanding. AI infrastructure is booming, creating more supercomputing capability. The systems are getting smarter. It's distributed computing, which is a graph, by the way, nodes and arcs. So like AI factories, the edge is coming, all kinds of coding future. There's a ton of opportunity. Thanks for sharing that

Neeraj Deshmukh

>> insight.

Neeraj Deshmukh

>> I'm waiting for the t-shirt that says everything is a

John Furrier

>> graph.

>> Everything is a graph. Our brain is a graph, left, right brain, center, everything's coming together. This is theCUBE trying to keep up with the velocity of the data. And of course, our graph is we go to events, we interview people, we get the content, get the transcripts, scripts. We'll share that with you. Thanks for watching. I'm John Furrier, your host.

Neeraj Deshmuk, Blitzy | Neo4J GraphSummit NYC 2026

search

John Furrier

>> Palo Alto Studio Connection, Silicon Valley and Wall Street. I'm John Furrier, co-host of TheCUBE, here with Dave Vellante, my co-host. Hello, I'm John Furrier, host of TheCUBE. We are here in New York City for GraphSummit NYC. Of course, we were at GraphSummit in SF a month ago, talking to the practitioners and the leaders and the partners of Neo4j and the ecosystem, growing community around graphs, knowledge layers, knowledge systems. Anything to do with data platforms and AI, whether you're hearing ontologies, context platforms, variety of different needs, but it's all doing the same thing, putting real-time low-latency data to AI software-enabled systems without changing the data. Neeraj Deshmukh, CEO, Director of Engineering, Bloqade. Congratulations on your funding. Welcome to TheCUBE here at

Neeraj Deshmukh

>> Capital

Neeraj Deshmukh

>> you. Excited to be here today. Yeah, this has been an amazing event. We're talking about knowledge layer for trustworthy AI. That's pretty much the bread and butter for us, using a knowledge layer for developing software autonomously at enterprise scale, which is what we do. And so it's been amazing to be here and be a part of this event.

John Furrier

>> I think you guys really represent the template for this whole agent thing because it's not just productivity for software development. You're making it autonomous, which means you have to know a lot of things. You have to know all the code bases and you got to have agents taking action. is that the right repo? Is that the right software supply chain? There's a lot going on. Explain the nuances of what you're doing.

Neeraj Deshmukh

>> I think when people talk about changing software autonomously, the biggest problem is not whether AI can write code. It's about does AI know or understand the system that it's writing the code for? And the reason that understanding is crucial is because I may be changing a line of code here, but it may have downstream impact somewhere far away. And your typical kind of coding agent tools are simply not capable of capturing that vast amount of context in a single session. Right. And so what we are trying to do is basically make sure that within our agent orchestration platform, where we have a large number of agents doing code generation on various parts of that codebase, all of them, each of them has access to the right information at the right time in the right place. So each agent knows exactly what part of the code they're supposed to modify and what are the downstream impacts of that, where do those code paths lead. And the reason I'm here today at Neo4j GraphSummit is because that knowledge graph is a graph, right? And so we—

John Furrier

>> it has relationships.

Neeraj Deshmukh

>> Relationships.

John Furrier

>> And code has relationships.

Neeraj Deshmukh

>> And code has relationships. Fundamentally, code is a graph because you think about, oh, we have modules, we have files, we have functions, we have objects, we have classes, variables. Each of these are entities that are related to each other. So even before you bring AI into the picture, a codebase is a graph intrinsically. And so when you use something like Neo4j to represent that, mirror that structure, it really helps us in encapsulating all of the information and then associate every node, every entity in that graph with the appropriate metadata, which we represent in vector form. And so the vector graph hybrid is basically what gives us that powerful knowledge representation.

John Furrier

>> Yeah, I'm smiling because anyone who's studied computer science and done any kind of compiler design, automata theory, state machine representation. It is graphs.

Neeraj Deshmukh

>> Yes, totally.

John Furrier

>> A node and an arc is a construct And by the way, you can recurse through graphs.

Neeraj Deshmukh

>> Yes.

John Furrier

>> And it's mathematical.

Neeraj Deshmukh

>> It's mathematical.

John Furrier

>> So you have a compatibility of AI, which is math, and GPUs take math data and process math. That is the fundamental lingua franca of AI.

Neeraj Deshmukh

>> True that.

John Furrier

>> That is the key.

Neeraj Deshmukh

>> Absolutely.

John Furrier

>> How much do you think people know about this? Because that makes the graph even more special. Because most of the data processing systems like CPUs process packets.

Neeraj Deshmukh

>> Yeah.

John Furrier

>> But I think convert data to math, math to math, whether it's NVIDIA or TPUs on Google, it's all the same. Math is math.

Neeraj Deshmukh

>> Math is math. And it's certainly, as you said, it's the language of science, it's the language of AI as well. I think a lot of people in the R&D community get that, right? They understand it. I think it's more, Like if you go beyond that, then you start saying, oh, yeah, that seems to be the buzzwordy thing right now. Like, oh, let's try a graph database here without truly understanding what kind of information you are trying to capture in that. Neeraj, this is a good point.

John Furrier

>> I want to just double-click on this. I think it's a notable insight we're riffing on. One is that NVIDIA was misunderstood by the mainstream market for many, many years. Anyone who was inside the Valley or in tech knew what was coming. They knew matrix multiplication, floating point, and the kind of math side of things was going to be big. And now everyone loves NVIDIA because the results, the results. You can't deny the results.

Neeraj Deshmukh

>> Yep.

John Furrier

>> Okay. Jensen flexing, he's a superhero now, flying from place to place. But now graphs are on a similar trajectory. What are some of those results? Because this is really fundamental because NVIDIA wasn't fake it until you make it. They actually had the real deal, graphs have the real deal, seeing it everywhere. What examples can you point to saying, look, this is the next thing and here's why?

Neeraj Deshmukh

>> Yeah, I think anytime you have a really complex relationship with a large amount of data where you are trying to model the variety of relationships and the extent of relationships within a single structure, a graph database is your friend. Oftentimes people don't have the understanding of the kind of data that they have, and that's the kind of relationship that they want to capture. But once they do, I think it's a no-brainer that you want to go with a graphical representation. For us, we are talking, we are in the software development business generating code autonomously. For us, the knowledge graph is the linchpin for everything that we do. And you can think of it like a human developer would do, right? you first understand the code that you want to work with.

John Furrier

>> Yeah.

Neeraj Deshmukh

>> And then you're going to use that knowledge to do additional work.

John Furrier

>> And what you guys are doing is interesting because it's not just Copilot code assistant, right? You're— and you're impacting projects. Yeah. End to end. And hallucinations, getting the wrong answer isn't right. It's like robotics. Again, safety comes up a lot in robotics. That's physical harm. You don't want your car to crash. And certainly any robot manufacturing to humanoids, there's a human danger involved physically. So there's a, life or death in getting the right answer. Financial transaction code that runs well or properly run, not maliciously. So there's a lot of consequences to not getting it right. Speak to the quality piece.

Neeraj Deshmukh

>> Absolutely.

John Furrier

>> And then we get to the ROI.

Neeraj Deshmukh

>> This is actually my favorite part of what Blitzy does. So we are a System 2 AI platform. What that means is there is a tremendous amount of attention paid upfront to planning, scoping, and validation. And validation is baked into pretty much every aspect of what we do. So the first step, of course, is that reverse engineering stage, creating that knowledge layer, right? That dynamic knowledge graph. But once you have that and now you want to do something with the code, and you specify what you want. You don't have to go into the chapter-and-verse detail, but a high-level description of what that target state looks like, what are the constraints, and what are your success criteria. Those are the three things that we absolutely need. And as clear and precise as you can be in specifying that is going to be really helpful. But we take that information and our agents will then use that knowledge of the existing code to come up with a spec, effectively what we call an Agent Action Plan for how we're going to turn that requirement into real code. All right. And how are we going to validate that? How are we going to test it to prove to you conclusively at the end of the process that this is actually what you are asking for?

John Furrier

>> Real validation.

Neeraj Deshmukh

>> Real validation. So this is a human-in-the-loop process. Once you approve that Agent Action Plan, then the agents go off and start coding. Every line of code that gets written is immediately tested. We build your code, we run your tests. If you have a CI/CD platform, if you have integration tests, if you have end-to-end tests, we can plug into those frameworks, we can run those as part of our code generation. And so something goes wrong, say a test fails, our agents go back to find the offending piece of code. They'll fix it, they'll rerun the test, and we keep iterating over that sometimes for days or weeks on end. So it's unlike, as you said, any Copilot or coding agent which will come back in a matter of minutes with a result. We are off to the races doing stuff for days or weeks on end, making sure that we are creating quality at scale for you, which is fully validated. And at the end of that process, when we return that pull request to you with maybe a fairly large chunk of code, we have already proven to you that we have done exactly what you had asked us to do. This is how we have validated it. This is how we have applied your success criteria and delivered on that.

John Furrier

>> Talk about the relationship of the graphs, the knowledge graph and the orchestration piece. I think that's an interesting tie-in.

Neeraj Deshmukh

>> Definitely.

John Furrier

>> Talk about the efficiencies and what's the alternative? If you didn't have graphs?

Neeraj Deshmukh

>> So if we didn't have the graph, then that entire knowledge of every agent needs to know the code that it is modifying, but not only what it's doing locally, but what impact it has. And in order to figure out what that impact is, without a knowledge graph, you're going to have to do searches. You're going to do either a vector search or a grep, which is what a lot of these coding agents do. And what that means is you are gonna run out of your token context very, very fast because if you have 100 million line codebase, just searching through all of that and keeping those results and processing those results and doing this over and over again, you're gonna hit your limits very quickly. You're gonna start compacting things, you're gonna start basically losing information in the process. And so this just doesn't scale. Your effective token context is about 200,000 to 300,000 tokens. That's about 20,000 to 30,000 lines of code. Anything bigger than that and you

John Furrier

>> are—

>> So you hit a ceiling, you're

Neeraj Deshmukh

>> cooked.

Neeraj Deshmukh

>> You're going to start degrading your

John Furrier

>> results.

>> Obviously, you've got context, right? And it's got, you can basically eliminate half the paths,

Neeraj Deshmukh

>> right?

Neeraj Deshmukh

>> With a graph, you know exactly what you're going to reach because you basically get to pick the point where you want to start with. And you know exactly what is accessible. And so you have that effective context. Every agent knows the context that it needs to and nothing else. So you've basically eliminated all of the wasteful storage from each agent's context memory and only given them the information that they need to know at the time that they need to know.

John Furrier

>> So for people that don't know graphs, think of it like doors. Each door has a bunch of paths. You hop down graphs, nodes, ARCs, right? So it just traverses the right

Neeraj Deshmukh

>> path.

Neeraj Deshmukh

>> just traverses the right

John Furrier

>> path.

>> exactly what to ignore, which is efficient.

Neeraj Deshmukh

>> Yeah, because those paths, those other things are simply not on its path, so it doesn't even have to go there,

John Furrier

>> right?

>> That's where the token savings comes in. That's because you don't have that overhead of walking down every path, that's the wrong path, and then coming back, reasoning, eliminate that

Neeraj Deshmukh

>> path.

Neeraj Deshmukh

>> So if you've got Cypher now, you save reasoning.

John Furrier

>> Exactly.

>> All right, so where do you guys go from here? Because now you're going to have the coding machine going. And people love— again, I think the coding was the key event that opened up the agents because search is great, retrieval, RAG is great for doing marketing copy with the chatbots. But when you get into work, yes, coding's opened the door for the enterprises that, whoa, we could actually do more.

Neeraj Deshmukh

>> Yeah.

John Furrier

>> So it's kind of spawned the agent revolution.

Neeraj Deshmukh

>> So there are a couple of things, right? One is you can go bigger. You don't have to break a big problem into smaller problems. Which is your kind of traditional SDLC and the sprint model that people use of like, oh, we start with epics and then go to user stories, to tasks, subtasks. You can actually deal with projects as whole entities and do them at once at scale. And you're accelerating your development.

John Furrier

>> That's very key. I want to stop there to explain that because that's a huge nuance. Forget the sprint in Agile, all projects at once. Explain that, because that's the big breakthrough.

Neeraj Deshmukh

>> Definitely. So because you're not limited by the context anymore, Every agent has infinite code context, so to speak, The necessity that you had of breaking a big project into smaller chunks goes away because the reason you did that was you couldn't handle that entire context upfront.

John Furrier

>> Yeah, you had to break it up. Now you don't need to, just go do it.

Neeraj Deshmukh

>> Just go do it, exactly. And because you have that planning and thinking built into it, you have the validation and testing built into it. You can be assured that what you are getting out of it, backed by that knowledge graph, backed by that whole knowledge of the existing system, you are actually getting something that is demonstrably correct, functional, tested and abiding by your enterprise guardrails of accountability, auditability, governance, compliance.

John Furrier

>> It's an AI software factory.

Neeraj Deshmukh

>> It is.

John Furrier

>> Basically what you're saying is. All right, so talk about what you guys mean by infinite context. So just walk us through an example of what people have to do to get there. Because by the way, that's the holy grail situation. Do I have to ingest all my code bases?

Neeraj Deshmukh

>> So now you gotta have one.

John Furrier

>> You gotta have all the projects ingested.

Neeraj Deshmukh

>> Yes. So step 1 is basically the ingestion and the reverse engineering. That's where we set up the initial version of the knowledge graph. But your code is not a static entity. People keep making changes to the code all the time. So we typically plug into the source control management system that you have, GitHub, GitLab, Bitbucket, ADO, whatever it is. And anytime the code changes, we detect that the code has changed, we will update the knowledge graph. So it's always current, it's always synchronized with the state of the latest code that you have and whether that code has been changed by Blitzy through one of our projects or by developers working independently doesn't really matter. You are always working with the latest copy, latest version of the knowledge graph.

John Furrier

>> And, and since the agents are watching everything, they're talking to each other.

Neeraj Deshmukh

>> We actually— the agents actually don't have access to any of the customer data directly. Right. So we access the code through basically the standard API functions for the SCMs that they provide. So the platform takes care of that and then it feeds that code piecemeal to the agents. And that way, again, the agents don't have full access to the code at any point. A lot of our customers come from highly regulated industries. They're very concerned about, hey, who's looking at our code? What are they going to do with it? And so we built Blitzy from the ground up for enterprise, keeping all of those regulatory compliance concerns in mind.

John Furrier

>> So it's a first principle for you guys.

Neeraj Deshmukh

>> It is absolutely security and governance. Security governance is the foundation for everything that we do.

John Furrier

>> What about explainability?

Neeraj Deshmukh

>> That too. That too. In fact, one of the artifacts that we provide to our customers at the end of the code generation is a report that actually outlines the information about what we did, why we did it, the action plan, the spec that I talked about earlier. That's one level of explainability. And then the project guide, the kind of finished report that we provide to our customers tells about, here is everything that we did, here is how we tested it, here is all the evidence for that test, and here are all the things that we did not do. And that may be because we didn't have sufficient knowledge. We maybe didn't have sufficient permissions to do things. But here is a list of remaining tasks that your engineering team now can come in and finish.

John Furrier

>> Got it. All right. So talk about graphs. People out there now, mainstream. I like that NVIDIA example we riffed on because it's kind of true. No one saw NVIDIA except for the people in the industry. But now it's the number one traded stock. It's on the board for options. The results are great. Graphs are coming mainstream and a similar thing. And people who have been doing it have been seeing amazing results. What's the bull case? Obviously there's a bull case for graphs. Why should people get on the graph train now? Because it's moving into IT, it's moving into all architecture of data platforms.

Neeraj Deshmukh

>> Yes, I think the most important reason is that data has become so complex and so large-scale that your traditional models for keeping track of what you have querying it and accessing it are simply not scalable enough. You go to a relational database, we were talking about this earlier today in Emil's keynote, he mentioned that, right? You go with a relational database today, you're going like 100, 200 levels deep into your queries. Those queries are simply not sustainable, right? Ditto with vector searches. Vector searches give you a similarity metric, but they don't capture relationships. So what you need is basically something that does both. It gets you in the right area for the similarity metric using a vector representation of your metadata, but then it has to have a graphical representation also to capture basically what the relationships are. And so this is what we do at Blitzy too. When the agent needs to know exactly what part of the code I have to change, the agent is saying, okay, well, get me to the vicinity of the code. I'm gonna do a graph search. I'm gonna then follow the relationships using my graph representation. And Neo4j makes this possible because it's a single database which captures all of this.

John Furrier

>> Neeraj, this is a super fun environment. anyone who's done software in the computer industry knows how hard it is. You're director of engineering. You used to probably do performance reviews of people. And, "Wow, your code's terrible. You got good code." So now are you grading the agents? How is, 'cause now you're getting into, this slop has been kicked around. There's a lot of bad code. I believe bad code always dies. So the whole SaaSpocalypse thing to me is ridiculous. They gotta innovate. But how do you evaluate the coding itself like you would a human? And then does the role of the engineer change? 'Cause obviously they're gonna not have to deal with all the work by coding, They're more engineering. That was the title when I graduated college was software engineer. That was the actual title. They're more engineering now than they are a developer. They're not developing anything. They're engineering. Talk about the evaluation of the agents and the role of the software engineer.

Neeraj Deshmukh

>> Definitely. So the good thing about agents is that they're really good at following instructions as long as those instructions are clear and precise. If you leave them to their own devices in terms of interpreting things, funny things happen. But that's not what you want. You want to be clear in terms of what you want and you have to be clear in specifying what you want. And once you do that, agents are really good at following up on that. So we typically provide clarity in terms of the coding standards, the code quality, like there are instructions built into the platform. Any customer of ours can also provide additional information in terms of like, hey, here are our requirements for what the code should look like or what the code should be doing. And so we certainly applied those on top of our own instructions. And like I said, every line of code that gets written is tested immediately.

John Furrier

>> Right.

Neeraj Deshmukh

>> And so we create ad hoc unit tests for all of the code that we're generating. We run functional tests, we run regression tests to make sure nothing existing is broken. And then we are also running the kind of large-scale testing based on the success criteria that you specified to make sure that we are actually delivering on what you wanted. And so all of these together make sure that the code quality is maintained. On top of that, we have agents who are watching other agents to make sure that they abide by the spec, the plan that we had created and approved by the human in the loop. And so that ensures that there is no drift or hallucination, because the moment you find an agent kind of going off course, the Sentinel agents, they're like, Nope. Yeah. Bad agent, you. Get back in line. Discard the work that you're doing. Start

John Furrier

>> again.

>> The agent for the agents.

Neeraj Deshmukh

>> Agent for the agents,

John Furrier

>> right.

>> Well, Neeraj, great to have you on. Love the insight. And again, I was joking with an engineer, they're like, we love the context platforms. Just keep the agents out of the Slack channels. They start playing the humans against each other. Final question for you here. What's going on here in New York City at GraphSummit? San Francisco is a very robust environment. What's the vibe in the room? What are some of the talks like? What did you learn?

Neeraj Deshmukh

>> It has been super exciting. For me, the revelation has been just the range of use cases and the diversity of applications for Neo4j, for the graph vector database. It's been amazing to see the energy in the room. Everybody's been super excited about what they're doing. How they can use graphs to improve their individual use cases. And also equally exciting is what's on the horizon for what's coming.

John Furrier

>> Yeah. And the GQL language is now a standard. That's interesting. That's going to be awesome. That's going to be a good way to kind of— define the tooling.

Neeraj Deshmukh

>> Definitely.

John Furrier

>> SQL kind of standard, but, that's kind of changing the game.

Neeraj Deshmukh

>> 100%.

John Furrier

>> Don't need to do SQL. The intent of actually doing a query changes.

Neeraj Deshmukh

>> Yeah, we actually, our agents are doing graph queries all the time. And so I love the fact that Cypher is a language that actually is very LLM friendly, but also the fact that if you create a malformed query for whatever reason, let's say an agent hallucinates or whatever, creates an incorrect query, you basically don't get a result when that happens. You only get a result for a correct query. So there is no question of the agents working off of made-up information or something false. You're always grounded in truth of what's in the knowledge graph.

John Furrier

>> Neeraj, thanks for coming on theCUBE. Congratulations on your success of the venture. Love the AI software factory. I think I made that term up.

Neeraj Deshmukh

>> We'll give you credit for that.

John Furrier

>> Yeah. NVIDIA will love it too, 'cause they love AI factories. Yeah, the infrastructure is expanding. AI infrastructure is booming, creating more supercomputing capability. The systems are getting smarter. It's distributed computing, which is a graph, by the way, nodes and arcs. So like AI factories, the edge is coming, all kinds of coding future. There's a ton of opportunity. Thanks for sharing that

Neeraj Deshmukh

>> insight.

Neeraj Deshmukh

>> I'm waiting for the t-shirt that says everything is a

John Furrier

>> graph.

>> Everything is a graph. Our brain is a graph, left, right brain, center, everything's coming together. This is theCUBE trying to keep up with the velocity of the data. And of course, our graph is we go to events, we interview people, we get the content, get the transcripts, scripts. We'll share that with you. Thanks for watching. I'm John Furrier, your host.