ryantsuji.dev — engineering / design / product

We spent a week going through our AI platform's cloud bill.

AI-driven development inflates CI cost on two axes at once: more runs, and more tasks you now want CI to do.

Every organization eventually faces the same design problem: keeping important information stored, current, and reachable at scale.

Part 1 laid out four monitoring axes (application / infrastructure / CI / LLM) and the shape each one ends up in.

The previous code-graph series was about reshaping a static analysis graph so AI could query it.

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).

A static-analysis approach to unifying 46 repositories (37 air-closet-side + 9 mall-side) of legacy production code into one knowledge graph.

Series Final.

Series Part 5.

Series Part 4.

Series Part 3.

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.

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

Vector RAG and one-shot Graph RAG both flatten the search step.

MCP responses fill the context window fast.

Non-engineers can build AI apps, but publishing safely is still gated by engineers.

Measuring 'did that initiative actually work?'

AI summaries aren't enough — context dies when a meeting ends.

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.