Every other code review tool asks
"did this pattern appear before?"
Ripple asks "did this pattern cause an outage,
and where else is it hiding right now?"
Ripple detects dangerous code patterns in incoming GitLab PRs by checking whether that pattern has ever caused a real production incident in Dynatrace. When it finds a match, it fans out across every service simultaneously and opens targeted fix MRs, each grounded in the exact incident that proved why the pattern is dangerous.
Architecture
Four FastAPI microservices communicating via agent-to-agent HTTP calls, orchestrated by Google ADK with Gemini 3 Flash. Deployed on Cloud Run (London). Scanning and fixing overlap: the moment a service reports a hit, Fix Factory starts on it while remaining services are still scanning.
Three MCPs
incident history, real traces, service maps, root cause
codebase read/write, MR creation, fix precedent
institutional memory: scars, wins, patterns from past scans
How it works
Developer pushes a change. GitLab fires a webhook to Ripple with the diff.
Dynatrace MCP is queried for incidents matching the pattern. Gemini extracts the semantic risk and scores it 1–10.
12 scanner agents fan out across all services in parallel. Each agent hunts for the pattern in its assigned service.
For each hit, a fix agent generates a targeted patch informed by the real Dynatrace traces from the incident.
An evaluation agent checks whether the fix would have prevented the incident. If it fails, the fix agent iterates (up to 3×).
On pass: a fix MR opens in GitLab with the incident context embedded. MongoDB stores the outcome for future scans.
Institutional Memory
Confidence boost: +1. Subsequent scans on this codebase score similar patterns higher.
Risk adjustment: −2. When accumulated scars push a score below the configurable AUTO_FIX_THRESHOLD, Ripple switches from auto-opening MRs to showing Approve / Skip buttons on the dashboard tile.
Every merged fix is a Win; every rejected fix is a Scar. Subsequent scans query this history via vector search. Ripple gets more accurate with each run on the same codebase.
Observability
Ripple ships its own telemetry to the same Dynatrace environment it uses to observe your codebase.
Every pipeline run ships spans to Dynatrace via OpenTelemetry. The evaluated_on: incident_context attribute on each Fix Factory span proves the fix was validated against real incident data, not just technical correctness.
Demo Environment
The demo runs against PulseCheck, a real 12-service Python monitoring platform on GitLab.
Incident P-26053: ssl-monitor hung on a slow certificate check with no HTTP timeout. A 47-minute outage, £23,000 estimated cost. Ripple finds that same pattern across 8 of the 12 services and opens fix MRs before anything reaches production - the other 4 already have timeouts configured. The architecture is pattern-agnostic: the same pipeline works for any incident-grounded pattern: missing retry logic, SQL queries without indexes, race conditions in async handlers.
Competitor Analysis
Ripple sits at the intersection of AI code review, agent memory, and production observability. No existing tool occupies all three simultaneously.
Every competitor in this space lacks two things simultaneously: production observability data and autonomous action. Ripple is the only system that has both. ARGUS reviews the PR in front of it. Ripple reviews the PR, queries Dynatrace for the incident that proves why it's dangerous, then sweeps every service and opens fix MRs, all without human input.
ARGUS knows what broke before (from git). Ripple knows what breaking cost (from Dynatrace) and fixes it across every service automatically.
Your team wants thoughtful, multi-pass PR commentary with failure scenario simulation and reviewer-reaction learning. ARGUS is excellent at this.
You want a PR to trigger an autonomous sweep of your entire codebase and open targeted fix MRs grounded in a real production incident; not just a review comment.
GitMem is memory for the developer's AI assistant. Ripple is memory for the team's production system. Different layers, no direct overlap.
A solo developer or small team wants their AI coding agent to remember past decisions, mistakes, and architectural choices across sessions.
A team wants their PR pipeline to automatically catch patterns that caused real production incidents and prevent them from spreading across services.
Feature matrix
| Feature | ARGUS | GitMem | Ripple |
|---|---|---|---|
| Institutional memory | git + reactions | session scars/wins | only |
| Multi-pass review pipeline | |||
| Architecture & dependency tracing | static analysis | Dynatrace service maps | |
| Failure simulation | hypothetical | real incident replay | |
| Production cost quantification | only | ||
| Codebase-wide sweep | only | ||
| Autonomous fix MR creation | only | ||
| Feedback loop (MR outcomes) | reviewer reactions | scar/win | |
| Self-learning over time | |||
| Self-hosted |
Broader Market
| Tool | Memory | Sweep | Action | Prod data |
|---|---|---|---|---|
| CodeRabbit | ||||
| Greptile | read-only | |||
| Semgrep | ||||
| SonarQube | ||||
| GitHub Copilot | ||||
| Ripple |
- Production-grounded data from real Dynatrace incidents
- Codebase-wide autonomous sweep from a single PR
- Autonomous fix MR creation across all affected services
- Real failure replay: actual traces, not hypothetical simulation
- Quantified impact: "47-minute outage, £23k"
- Three MCPs: Dynatrace + GitLab + MongoDB
- Scar/win accumulation is live; retrieval quality improves with more scan history
- No PR diagram generation yet; planned, will use real DT traces
- No general code quality review; intentional scope, not a bug
- GitHub support not yet available; GitLab only today