I am a beginner developer, and for Graph Hacks 2026 I built RippleMind AI: a small tool that answers one question before you change some code: what else might break?
Code: https://github.com/lakshulakhera-hubtech/ripplemind-ai
The problem
Software is a web of connections. A login service is used by a payment service, which is used by a checkout workflow. If you change the login process, the checkout can be affected too, and nobody remembers that chain. Tables are bad at this. Graphs are made for it.
The idea
You pick a component, describe your change, and RippleMind shows:
- direct and indirect dependents, each with the exact path that explains why
- the owner team of each affected component
- tests worth running, sorted by how close they are to the change
- related incidents (all synthetic, clearly marked)
- a graph picture and a downloadable report
The graph model (in FalkorDB Cloud)
Nodes: Component, Team, Test, Incident.
Relationships:
-
(A)-[:DEPENDS_ON]->(B)means A needs B (Component)-[:OWNED_BY]->(Team)(Component)-[:TESTED_BY]->(Test)(Component)-[:AFFECTED_BY]->(Incident)
My demo data is fictional: 14 components, 15 dependency edges, 11 tests and 5 incidents.
The one query that does the heavy lifting
MATCH p = (a:Component)-[:DEPENDS_ON*1..5]->(c:Component {name: $name})
RETURN a.name, a.kind, length(p), [n IN nodes(p) | n.name]
ORDER BY length(p), a.name
*1..5 means "follow DEPENDS_ON for one to five steps". One short query gives me direct and indirect dependents, and the path itself, which becomes the explanation. For Login Service it finds 4 direct and 4 indirect dependents, for example Checkout Workflow -> Payment Service -> Login Service.
Without the graph, this app has nothing to show.
Verified facts vs inferred risks
I did not want the app to present guesses as facts. So the result page has two clearly separated parts:
- Verified from the graph: things that come straight from query results.
- Inferred risks: a simple rule-based score (how close the dependency is, whether a past incident is linked, how many paths lead there). It is a heuristic, and the page says so.
Testing
Before running the app, I worked out the expected numbers from the seed data, with Claude's help. Then I compared them with what the app showed:
| Changed component | Direct | Indirect | Tests | Incidents |
|---|---|---|---|---|
| Login Service | 4 | 4 | 10 | 5 |
| Payment Service | 1 | 0 | 2 | 1 |
| Checkout Workflow | 0 | 0 | 1 | 0 |
| User Database | 2 | 8 | 10 | 5 |
All four matched. I did not write automated tests, and I did not test database failures or graph changes after seeding.
What I learned
- Connection details are not on the main instance page. I found the host and port on the Connectivity tab of FalkorDB Cloud.
- Passwords must never go into public code. I kept mine in a local .env file and added it to .gitignore so it was not uploaded to GitHub.
- The direction of a relationship matters. In my graph, "A depends on B" ... In my graph, "A depends on B" is an arrow from A to B, so to find what breaks I follow the arrows backwards from the changed component.
Limitations
- The data is fictional, and so are the incidents.
- The text of the change you type is saved in the report but is not interpreted. This is a graph-driven analysis tool, not an LLM chatbot.
- The risk score is simple.
- The app runs locally. There is no live deployment.
AI disclosure
I built this with help from Claude (Anthropic), which generated most of the code and guided me step by step. I set up the FalkorDB Cloud instance, configured the credentials, ran the seed script and the app, andI built this with help from Claude (Anthropic), which generated most of the code and guided me step by step. I set up the FalkorDB Cloud instance, configured the credentials, ran the seed script and the app, and compared the app results with expected numbers that Claude and I worked out from the seed data. I did not write the code from scratch. I did not write the code from scratch.
Thanks to WeMakeDevs and FalkorDB for the hackathon.
Top comments (0)