Neo4j Live: Graph-Powered Code Debugging with GenAI

While large language models (LLMs) can write and analyse code, debugging real-world applications often requires more than smart autocomplete. Developers need tools that analyse the local code and understand the broader context – file structures, function relationships and data flows.

In this Neo4j Live session, José Domínguez, co-founder of Blar, walked us through how his team is using graphs to power a new kind of developer assistant: one that doesn’t just answer questions, but helps you find the root cause of bugs in your code.

You can watch the full session above.

From SQL to Graphs: Blar’s Journey

Blar’s story didn’t begin with code debugging. Originally, the startup focused on translating natural language questions into SQL. But the team quickly encountered a challenge: relevance.

They realised that semantic search often produced similar-sounding results that were technically incorrect. Graphs offered a more structured and contextualised way to model relationships, not just between data columns but also between concepts, people and workflows.

That same realisation led to a bigger idea: What if your codebase could be represented as a graph? Their pivot coincided with broader GenAI advances. Large Language Models (LLMs) like GPT-4 opened new possibilities but also exposed familiar weaknesses: hallucinations, lack of context and opaque reasoning.

Modelling Code as a Graph

In Blar’s system, the codebase is parsed and represented as a graph with nodes for packages, files, classes and functions. Edges represent relationships like:

CONTAINS (e.g., file contains a class)
CALLS (function calls another function)
IMPORTS
INHERITS and more

They use static code analysis, rather than LLMs, to build this graph deterministically, reducing hallucinations and preserving trust in the structure. Visualisation happens in 3D, allowing developers to zoom into individual files or pan across a repo. You can think of it like interactive VS Code, but where relationships are first-class citizens.

Debugging as Graph Traversal

Blar’s Code Base Agent acts like a developer colleague. You describe the problem – maybe a concurrency issue or a specific error message – and choose a starting point in your code graph. From there, the agent traverses the graph, exploring connected functions, inspecting relationships, and offering hypotheses about the root cause.

It’s not just about tracing an error; it’s about understanding why the issue exists in the first place. Rather than patching a bug with a quick fix (e.g., “check for NULL”), the agent helps developers reason through why the NULL appeared, offering a more systemic solution.

You can interact with this system in two ways:

Manual Debugging: Point the agent to a known issue.
Automated Debugging: Connect the system to tools like Sentry and let it react to live errors.

Each report generated includes:

Suspected cause(s),
A traversal log of which code parts were examined,
Hypotheses and, optionally, proposed solutions.

Beyond Debugging: Optimisation and Security

Once Blar had the graph infrastructure in place, expanding to other use cases was a natural next step. They now offer agents for:

Performance Optimisation: Suggesting improvements based on complexity analysis and graph position.
Security Analysis: Identifying issues like unprotected endpoints or unsafe SQL patterns.

These agents use the same traversal approach to understand how code behaves across files and functions. For example, an optimisation agent might explore all nodes touched by a POST request and suggest simplifications or refactors, complete with code diff suggestions.

Avoiding LLM Hallucinations

A recurring theme throughout the livestream was the risk of hallucinations when working with LLMs. Blar’s approach avoids fully autonomous code rewriting and emphasises developer-in-the-loop workflows.

Rather than automatically pushing code changes, the agent generates structured suggestions and leaves them to the developer to validate and implement. Developers can also interact with the agent’s reasoning by reviewing traversal paths and providing feedback.

This approach keeps developers in control while accelerating their understanding of unfamiliar code or complex bugs.

Real-World Example: Cross-Repo Debugging

In one example, the agent started with an error in Blar’s backend and traced it across repositories, eventually identifying the issue in their open source library. This was only possible because both repositories were modelled together in the same graph, allowing the agent to cross boundaries and maintain context.

José noted that such cross-repository reasoning would be very hard without a connected representation of the code.

Takeaways for Developers

Modelling code as a graph allows you to reason across the full structure of your application – files, functions, imports and dependencies – rather than treating code as isolated text.
LLMs are more effective with structure. Blar’s approach gives them a guided path to follow instead of relying solely on semantic similarity.
Debugging isn’t just fixing errors; it’s understanding them. Root cause analysis benefits from graph traversal far more than from isolated file inspection.
Avoiding hallucinations is critical. Blar uses static analysis for graph generation and treats LLM suggestions as advisory, not authoritative.
Graph-powered agents can generalise. Once a graph model of the code exists, the same agent framework can be adapted for performance tuning, security audits, and more.