Graph-Native Predictive CI: How RippleCI Cuts Build Times by 68% with FalkorDB

When CI Becomes a Developer's "Purgatory"

Running a 45-minute pipeline for a three-line fix is a torment nearly every engineer has experienced. You change one internal helper function, push the commit, and then wait nearly an hour while hundreds of unrelated test suites run just so you can merge the PR.

To escape this trap, teams often turn to naive file-path heuristics — running only test_<filename>.py. But this introduces disastrous blind spots: when a subtle change in auth/tokens.py breaks the indirect caller billing/handlers.py three hops away, file matching completely fails to notice. In an empirical study, the RippleCI team found that file-matching heuristics miss over 33% of real regression failures.

This is exactly the problem the open-source project RippleCI aims to solve: a graph-native predictive CI engine, a CLI developer tool, and also a Model Context Protocol (MCP) server built on FalkorDB. Its core proposition is to use a graph database's linear algebra engine to compute multi-hop change blast radius in 15 milliseconds, cutting CI runtime by 68% while mathematically guaranteeing 100% fault recall.

The Core Insight: Code Is a Graph, Not a Flat File System

Files and directories are merely artifacts of how humans organize the file system. Execution flow does not care about folder boundaries — it cares about symbols, call chains, inheritance hierarchies, and test assertions.

Rather than treating the codebase as raw lines of text, RippleCI parses Python source files into an abstract syntax tree (AST) property graph. The entire pipeline runs as: Git commit diff lines → AST dependencies synced to FalkorDB → multi-hop blast radius computation → machine-learning regression prioritization → bounded AST verification.

FalkorDB Property Graph Schema

Inside FalkorDB, the software graph is modeled as fine-grained nodes and edges:

• Nodes: File (with path, line count, change frequency score), Class, Function (with async flag, start/end line numbers), TestCase (with historical duration, flakiness rate)
• Edges: File-DEFINES->Class|Function, Function-CALLS->Function, File-IMPORTS->File, TestCase-TESTS->Function|Class

The key to this schema is that it turns "who calls whom" and "which test covers which symbol" into first-class citizens, rather than approximate relationships guessed from text.

Abstract Syntax Tree (AST) is a tree-like representation of source code's syntactic structure: each node represents a syntactic construct (such as a function definition, an if statement, a binary operation, or a variable reference), edges represent nesting relationships, and nodes carry positional information such as start and end line numbers. The AST discards semantically irrelevant details like comments, whitespace, and formatting, keeping only the program's structure, which is why compilers, linters, code formatters, and static analyzers commonly use it as an intermediate representation. Merging the ASTs of multiple files and adding cross-file call, import, and test coverage edges yields a property graph — where nodes and edges carry key-value properties (such as whether a function is async, or a test's historical duration). This is precisely why RippleCI can turn "who calls whom" and "which test covers which symbol" into precisely queryable relationships rather than textual approximations.

Why FalkorDB Is "Irreplaceable"

When a commit modifies 10 lines of code, computing "what might be broken" requires recursively tracing upstream and downstream callers. This is a direct test of a database's traversal capabilities.

The authors provide a clear comparison of several approaches:

• Relational SQL (Postgres/MySQL): Performance collapses under recursive JOIN cascades and CTE traversals of arbitrary depth.
• Vector databases: Non-deterministic. Embeddings approximate semantic similarity but cannot tell you whether function A strictly calls function B.
• Traditional graph databases (e.g., Neo4j): Heavy JVM runtime, slow cold starts, high memory footprint — unsuitable for developer CLI tools.

FalkorDB addresses each of these constraints one by one. First, GraphBLAS matrix operations represent the adjacency graph as sparse matrices, translating Cypher path queries into linear algebra matrix multiplications, completing multi-hop reachability queries in single-digit milliseconds (<15ms). Second, it is built on the Redis protocol with no JVM overhead, accessible as a lightweight service over the standard Redis wire protocol. Third, declarative Cypher lets complex reachability and shortest-path queries be expressed in just 5 lines of code.

GraphBLAS is an open specification for expressing graph algorithms as sparse matrix operations. Its core idea: a graph's adjacency relationships can be written as a sparse matrix A, where A[i][j] being non-zero means there is an edge from node i to node j. Thus "which nodes are reachable within k hops from a starting point" is equivalent to repeatedly multiplying A and accumulating over the Boolean semiring, i.e., A ⊕ A² ⊕ A³. Such operations can be executed highly in parallel and cache-friendly, with complexity scaling with the number of edges rather than node pairs. FalkorDB uses this layer to translate variable-length path queries in Cypher into matrix multiplications, so that multi-hop reachability queries consistently land in the millisecond range, rather than degrading sharply with depth as recursive JOINs do.

Tracing a Three-Hop Blast Radius in 15 Milliseconds

When analyzing Git diffs, RippleCI maps changed line numbers to specific AST symbol IDs, then queries FalkorDB using native variable-length Cypher traversals. The query starts from test cases and traces backward 1 to 3 hops along TESTS|CALLS edges, returning test IDs, names, and historical durations, sorted by shortest graph distance and duration.

In under 15ms, it extracts three tiers of results: Hop 1 are tests that directly execute the changed function; Hop 2 are tests covering upstream functions that call that function; Hop 3 are transitive integration tests touching downstream services that depend on the changed interface.

This precisely fills the blind spot of file heuristics — indirect consumers are no longer missed.

Blast radius is borrowed from the incident and security domain, referring to the maximum scope of impact a change may cause. In the code context, it answers: after modifying symbol S, which upstream callers, downstream consumers, and tests may fail as a result. Computing it requires reverse reachability queries on the dependency graph — starting from the changed symbol and traversing backward along CALLS, IMPORTS, and other edges. The emphasis on "three hops" is because empirical evidence shows the vast majority of real regressions occur within limited transitive depth; limiting depth to 1–3 hops covers indirect callers while avoiding the noise and cost of full-graph traversal, enabling queries to complete within a fixed budget.

Multi-Signal Test Prioritization

Knowing which tests might fail is only the first step. The second is scheduling them under a tight CI budget — for example, "give me the safest test plan that finishes in 180 seconds."

RippleCI scores candidate tests with a multi-signal Pareto-optimal ranker that combines four factors: shortest topological graph distance (computed by FalkorDB, closer is higher priority), Git change frequency recency (frequently changed code has higher defect density), historical execution duration (faster tests give failure signals sooner), and a test flakiness penalty (suppressing noisy intermittent failures).

The value of this design is that it doesn't simply "run all related tests" but makes explicit trade-offs among risk, speed, and signal-to-noise ratio, spending CI budget where it matters most.

Counterfactual Mutation Verification: Testing "the Tests Themselves"

How do you ensure the prioritized test suite actually catches regressions? RippleCI's answer: test the tests.

It includes a built-in counterfactual AST mutation engine. Before allowing a build through, it injects bounded AST mutations into the changed code: flipping comparison operators (> to <=, == to !=), mutating return values (True to False or None), and shifting boundary conditions (+1, -1). It then runs the selected test plan against this mutated code. If 100% of synthetic mutants are killed, release safety is empirically proven.

This step turns "prediction" into a "verifiable guarantee," and is the source of confidence behind its bold claim of 100% recall.

Mutation testing is an empirical method for evaluating test suite quality: inject small, semantically meaningful changes (called mutants) into the code under test, then run the tests. If a mutant causes at least one test to fail, the mutant is said to be "killed," meaning the tests can detect this kind of defect; if all tests still pass, the mutant "survives," exposing a blind spot in the tests. Mutation score (the proportion of killed mutants) is therefore a stricter metric than line coverage — high coverage only means the code was executed, while a high mutation score means the assertions are truly effective. RippleCI repurposes this as a pre-release self-check: attacking injected mutants with the selected prioritized test plan, using 100% mutant kill rate as empirical evidence for its recall guarantee.

MCP Integration for AI Coding Agents

AI coding agents (Cursor, Claude Desktop, Windsurf) are writing massive amounts of code, but they have a fatal weakness: context blindness. When an agent edits a file, it doesn't understand what this breaks in the rest of the repository.

To address this, RippleCI includes a native MCP server (ripple mcp serve). A single terminal command connects it to a local AI editor — for example, ripple connect cursor automatically detects and configures the Cursor IDE, or ripple connect claude connects to Claude Desktop.

Once connected, AI agents get several dedicated tools directly within their context window: ripple_trace_blast_radius (trace downstream dependencies before editing), ripple_prioritize_tests (recommend the minimal verification test set for generated code), ripple_verify_mutations (check whether AI-generated tests are superficial), and ripple_query_graph (letting agents query the FalkorDB graph directly with Cypher).

This means AI agents shift from "blind editing" to "understanding the impact surface before acting," embedding graph queries into the agent's reasoning loop.

Benchmark Data: 5,000+ Synthetic Mutants

The authors benchmarked by injecting over 5,000 synthetic mutation faults into a real Python codebase.

Strategy	CI Test Duration	Mutation Fault Recall	Escaped Defect Rate
Full suite execution	48m 12s (100% budget)	100.0%	0.0%
Naive file heuristic	3m 24s (7% budget)	66.7%	33.3% (severe risk)
RippleCI (FalkorDB)	15m 18s (31.7% budget)	100.0%	0.0% (zero escapes)

The key result: RippleCI cuts CI execution time by 68.3% while maintaining 100% fault recall. By contrast, the file heuristic uses only 7% of the budget but misses a third of failures — that "saved time" is essentially traded for risk.

Getting Started and Takeaways

RippleCI is open source and can run locally or in CI pipelines. The basic flow is to clone the repository, run the zero-dependency standalone diagnostic ./ripple doctor, index the repository into FalkorDB with ./ripple index, and connect to Cursor or Claude Desktop with a single command.

The authors' conclusion from building it: GraphBLAS-powered graph engines are the future of developer tools and agent workflows. Running millisecond-level Cypher queries directly inside a developer CLI or an agent's reasoning loop transforms static analysis from a slow batch job into an instant, interactive feedback loop.

For teams struggling with CI duration and AI agent context blindness, this project's approach is worth learning from: rather than optimizing at the file level, model code as what it truly is — a graph.

One-line Summary

RippleCI uses AST property graphs and FalkorDB matrix operations to compute change impact in 15 milliseconds, speeding up CI by 68% with zero missed detections.

Paragraph Summary

The article introduces the open-source project RippleCI: a graph-native predictive CI engine and MCP server. It points out that naive file-path heuristics miss over 33% of real regression failures because execution flow does not follow folder boundaries. RippleCI parses Python source into an AST property graph stored in FalkorDB, using GraphBLAS sparse matrix operations to complete multi-hop blast radius queries in 15 milliseconds; it then schedules tests with a multi-signal Pareto ranker combining graph distance, change frequency, historical duration, and flakiness; and it validates the test suite's own effectiveness before release via a counterfactual AST mutation engine. A built-in MCP server lets AI agents like Cursor and Claude Desktop query the impact surface before editing. Benchmarks show it cuts CI duration by 68.3% while maintaining 100% recall.