Ryosuke Tsuji

The previous code-graph series was about reshaping a static analysis graph so AI could query it. The same kind of reshaping is needed on the observability side. This post walks through four axes — application / infrastructure / CI / LLM — and the deliberately different shapes each one ends up in. The design judgments worth calling out: computing Gemini cost client-side instead of from billing API, sending Claude Code OTel straight to BigQuery instead of Loki, and shipping CI logs via post-hoc pull instead of webhook push.

The biggest issue Part 1 left open was that AI couldn't reach the 46-repo codebase by natural-language query (the entry-point problem). This post is how I solved it — by reusing the pattern proven in db-graph (1,133-table semantic search), then layering minimal annotations only around boundary nodes. Covers the separate-branch operation that keeps engineers' daily workflow untouched, the SLO that protects the joins between three graphs, the SAME_ENTITY normalization, and the April–May trial-and-error timeline traced through real commits.

Top 7 Featured DEV Posts of the Week Cyberpunk cat RPGs and robot personalities ...

A static-analysis approach to unifying 46 repositories (37 air-closet-side + 9 mall-side) of legacy production code into one knowledge graph. Why simply 'letting AI read the code' isn't enough, why I had to chase down boundary nodes (API endpoints, DB tables, Event topics), how I dealt with framework and library diversity, and what 3 months of trial and error solved or didn't solve — looking back through actual git history.

Series Final. The four mechanisms covered across this series — knowledge graph, Auto Review, Self-Healing, Recurrence Prevention — plus the non-engineer-PR application that sits on top of them, all hang off a single conviction: AI isn't something to trust; it's something to design. The 'I don't trust AI to fill in the blanks for me' framing this lives inside isn't doubt about generation quality, but the clear-eyed acceptance that AI has no idea what context wasn't handed to it, and that 'ideal behavior with no spec given' is a fantasy. The starting point goes back to 2025, when I was trying to figure out how to make AI actually understand a large codebase — and ran into walls on both context window scaling (lost in the middle, attention dilution) and learning-based approaches (machine unlearning, destructive interference). GraphRAG + MCP became the way out: hand AI only the facts it needs, when it needs them, so it doesn't have to infer. From code-graph (which I burned two months on and threw away) to the current product-graph (cpg). This piece is the philosophy and the trial-and-error behind the whole series: harnesses confine where hallucinations are allowed to happen, design is translating principles into your own use cases, and Coverage 90% as a solo target breaks the implementation.

The Author Doesn't Have to Be an Engineer: How the Harness Holds Quality (Series Part 5) ...

Series Part 5. With the harness handling quality at the gate, the people closest to the requirements -- business-side managers, PMOs -- now open PRs to production directly, no engineer in between. Two recent examples (a deep root-cause fix and a +1,742 line feature build), the boundary of what they can and can't take on (anything on top of an existing stack vs. standing up new infrastructure), why it holds (the four mechanisms from Parts 1-4), and how the pattern carries over to consumer-facing services.

Series Part 4. Production alerts trigger AI investigation, fix PR, auto-review, auto-merge, auto-redeploy. The same fix PR is required to add a new Guide -- a lint rule, CI guard, type constraint, or guideline entry -- so the same anti-pattern gets auto-rejected from then on. 115 Self-Healing PRs merged in the past 30 days, and the quality gates compound over time.

Series Part 3. The common critiques of AI-assisted development -- 'review becomes the new bottleneck' and 'AI code drops the quality bar' -- largely don't apply when AI also does the reviewing. Full walkthrough of our pipeline: webhook -> cpg context -> AI review with [Graph]/[Doc]/[Impact] tags -> auto-fix by a separate AI -> re-review -> auto-merge -> parallel deploy. 769 PRs merged in 30 days, human review involvement per PR is near-zero.

Series Part 2: how we built cortex-product-graph (cpg) — a unified knowledge graph of code, docs, DB schemas, and infrastructure for the cortex AI platform. Build pipeline with JSDoc/Pulumi/docs as SSoT, plus the Runbook tool-design pattern that guides AI through the graph.

Minimal test fixture used by $slug.test.tsx. No headings, no tags — covers the null branches of TOC...

Series intro to cortex, airCloset's internal AI platform that auto-reviews PRs, self-heals ops, and lets non-engineers ship apps. Why harness engineering matters now.

Vector RAG and one-shot Graph RAG both flatten the search step. Agentic Graph RAG hands the graph to an LLM as an MCP and lets it traverse relationships iteratively.

MCP responses fill the context window fast. The parking pattern stores heavy payloads externally and returns only a key — about 90% token savings in production.

Non-engineers can build AI apps, but publishing safely is still gated by engineers. Sandbox MCP gives them a one-command path to deploy Web/API/DB/Cron with guardrails.

Measuring 'did that initiative actually work?' usually means manual SQL spelunking. We modeled initiatives × KPIs as a graph and let an LLM traverse it via MCP.

AI summaries aren't enough — context dies when a meeting ends. We pipe Google Meet recordings to Slack, transcribe everything, and make history queryable in natural language.

Overview of 17 MCP servers we built in three months at airCloset, covering DBs, infra, docs, project management, observability, CI/CD, and even non-engineer code edits.

Internal data lives across 15 schemas, 991 tables, 11 SQL DBs and 6 MongoDBs. DB Graph MCP lets Claude search and query the whole thing in natural language.