Wan Shi Tong

Wan Shi Tong is a GitLab Duo AI agent that detects breaking changes across a monorepo before they merge automatically analyzing cross-service dependencies.

Comment

Inspiration

Every engineer on a large monorepo has lived through this: a developer makes what looks like a clean, isolated change. Code review passes. CI goes green. The MR merges. Then hours or days later production breaks. Five other services were consuming that shared API contract. Nobody saw it. Nobody could have seen it without reading every file by hand.

We wanted to close that gap permanently. Not with documentation. Not with a convention. With an agent that knows the entire dependency graph and acts on it automatically every single time a merge request is opened.

The name Wan Shi Tong comes from ancient mythology: a spirit librarian who maintains a library of infinite knowledge and knows the relationship between all things. That is exactly what this agent does for your monorepo.

What It Does

Wan Shi Tong is an event-driven GitLab Duo agent that eliminates breaking changes before they reach production. It operates as four coordinated capabilities:

1. Orchestrated Impact Analysis Flow
When a merge request is opened, GitLab CI automatically @mentions Wan Shi Tong. The orchestrated flow has two components:

  • Analyzer: Uses grep, read_file, and list_repository_tree to traverse the monorepo, extract change signals from the diff (API routes, function signatures, type definitions, config keys, event schemas), and identify every file with a real dependency on what changed—validating code context, not just string matches.
  • Reporter: Posts a structured comment on the MR with a severity-classified dependency table (breaking, risky, clear), applies the corresponding GitLab label via update_merge_request, and triggers a CI gate that physically locks the pipeline if the breaking label is present.

2. Auto-Fix Flow
For each affected project identified as breaking, the auto-fix flow determines the precise code change required, creates a new branch, edits the file, and opens a fix MR linked back to the original change. This happens autonomously, no human intervention required.

3. Changelog Agent
Generates structured, human-readable changelogs from MR history and knowledge base entries. Accelerates release note creation across all impacted services.

4. Chat Agent (Interactive Q&A)
Available in the GitLab Duo sidebar. Ask questions like:

  • "What depends on the POST /orders endpoint?"
  • "Check MR !42 for cross-service impact."
  • "Summarize the breaking changes in the last sprint."

Google Cloud Integration
Wan Shi Tong queries Google Artifact Registry (via Workload Identity Federation) to determine which version of each consuming service is actually deployed. If a service already runs the post-change version of the contract, severity is downgraded from breaking to informational. This is deployment-aware impact analysis, connecting code changes to runtime reality.

Engineering Insights Dashboard
A Python exporter streams GitLab metrics flow mentions, fix MR velocity, cross-project coupling scores, knowledge base growth into BigQuery. Engineering leaders visualize this data in a Looker Studio dashboard to identify technical debt hotspots and prioritize decoupling investments.

How We Built It

Agent Platform: All agents and flows are defined as YAML on the GitLab Duo Agent Platform and registered in the GitLab AI Hackathon catalog via a CI-validated tag push.

Demo Monorepo: Three Python FastAPI microservices (orders-api, users-api, inventory-api) share a common schemas.py contract. This is the blast radius test bed changing a shared field triggers the full Wan Shi Tong analysis cycle.

GitLab Tools Used:

  • get_merge_request, list_merge_request_diffs — diff extraction
  • grep, read_file, list_repository_tree — dependency search
  • create_merge_request, update_merge_request, create_merge_request_note — reporting and fix MR creation

Google Cloud Stack:

  • Artifact Registry — deployed version lookup via Workload Identity Federation
  • Cloud Run — microservice hosting
  • BigQuery — metrics storage
  • Looker Studio — engineering insights dashboard

Languages: Python (FastAPI microservices + BigQuery exporter), YAML (agent/flow definitions)

Challenges We Ran Into

Dependency signal extraction: Distinguishing real import dependencies from coincidental string matches required reading code context around each grep result, not just counting occurrences. The agent needed to reason about whether a match was a function call, an import statement, or a comment.

Severity calibration without overblocking: Flagging everything as breaking trains developers to ignore the agent. We built a three-tier severity model (breaking / risky / clear) and tuned the confidence threshold to reduce false positives without missing real regressions.

Deployment-aware analysis: Integrating Artifact Registry required Workload Identity Federation setup and handling the case where the registry has no version data (service not deployed yet). The agent gracefully degrades to code-only analysis when GCP data is unavailable.

CI gate without blocking legitimate fixes: The gate had to distinguish "this MR breaks downstream dependencies" from "this MR is the fix for a downstream dependency." We solve this by checking for a fix-mr description pattern that auto-fix flows inject.

Accomplishments We're Proud Of

  • Full autonomy, zero developer behavior change. The developer opens an MR exactly as they normally would. Wan Shi Tong appears on the MR, runs analysis, and if needed opens fix MRs in affected projects. The developer does nothing different. They simply get protected.
  • Deployment-aware severity. We are not aware of another hackathon submission that uses Artifact Registry as a live input to MR analysis. This closes the loop between code and runtime.
  • Institutional memory. Every breaking change detected is written to a knowledge base file (.wan-shi-tong/memory.md) in the repo. Future analysis gets smarter as the knowledge base grows.
  • Four coordinated agent capabilities on a single platform, registered in the public catalog, open-source under MIT.

What We Learned

  • Agents are most powerful when they respond to events, not questions. The CI @mention trigger is what makes Wan Shi Tong feel like a real teammate rather than a tool you have to remember to use.
  • The GitLab Duo Agent Platform's orchestrated flow model is genuinely well-suited for multi-step analysis pipelines. The two-component Analyzer → Reporter pattern maps cleanly to the platform's component architecture.
  • LLM-based code analysis needs grounding. Pure semantic search over large repos hallucinates. Combining grep (exact match) with read_file (context verification) and LLM reasoning (dependency classification) produces accurate, trustworthy results.
  • Deployment context changes the analysis. A "breaking" change in code is not necessarily a breaking change in production if the consumer is already on the new version. That distinction matters for prioritization and developer trust.

What's Next for Wan Shi Tong

  • Multi-project group support — When GitLab Duo flows gain access to cross-project tooling, Wan Shi Tong will extend impact analysis across separate repositories, not just separate projects in a monorepo.
  • Auto-assignment — Automatically assign the MR for downstream fix review to the owning team, based on CODEOWNERS.
  • Severity trend forecasting — Use BigQuery history to predict which services are accumulating coupling debt before it becomes a production incident.
  • IDE integration — Surface dependency impact in real time inside the editor, before the MR is even opened.
  • Green Agent extension — Track LLM token consumption per flow run and surface energy cost estimates in the Looker Studio dashboard (Sustainable Design angle).

Built With

Share this project:

Updates