How airCloset Joined Two Knowledge Graphs to Make 46 Repositories Searchable

CTO Ryan Tsuji inherited semantic context for his code graph by joining it with an existing database graph, a pattern that sidestepped annotating tens of thousands of functions.

Ryan Tsuji, CTO at airCloset, built a unified knowledge graph from 46 separate code repositories. But the graph had an entry-point problem. Without a way to search it semantically, AI models were still forced to infer meaning from code, defeating the project's central goal: giving the model verified facts, not forcing it to guess.

The solution came not from the codebase, but from the database. A previously-built project for mapping the company's data schema provided the template and the context needed to make the code graph truly searchable.

A pattern proven on the database

Months earlier, Tsuji’s team had solved the same search problem for their database. The company’s data was spread across so many services that no single engineer understood the entire map. The team built db-graph, a tool that statically extracts schemas from ORM definitions and uses Google's Gemini to generate descriptions for each table.

These descriptions were embedded as vectors, making the entire database searchable via natural language. Tsuji reports this system now covers 21 schemas, 1,133 tables, and 10,815 columns. The core pattern was established: a static-analysis graph combined with AI-generated context enables natural-language semantic search.

Joining graphs to inherit context

The insight was realizing the code-graph already contained nodes representing database tables. These were boundary nodes connecting the application logic to the data layer. Instead of re-building semantic context for the code from scratch, Tsuji’s team could simply join the two graphs.

By linking the code-graph to the existing db-graph, the code graph automatically inherited the rich, AI-generated semantic context of the entire data model. Code that interacted with a specific table now had that table's full description and relationships attached. This single move provided significant semantic depth without requiring a single new annotation in the codebase.

The limits of a single join

This join solved the database context problem, but it did not address other boundary types. API endpoints, event triggers, and page-level entry points remained semantically blank. Static analysis alone cannot determine the business intent of an API call or a user-facing page.

Tsuji identifies the next step as adding intent directly into the code via annotations. This presents its own scaling problem. Asking engineers to retroactively annotate tens of thousands of functions across 46 production repositories is not a viable strategy.

What We'd Change

The playbook here is potent but has a critical prerequisite: the existence of a high-value, context-rich graph like db-graph. A team without this asset cannot simply replicate the "join" tactic. The more generalizable lesson is to first identify the system's core domain of knowledge, build a semantic map for it, and then treat it as a "context provider" for other, less-structured domains like application code. For many companies, this will be the database schema.

This strategy is also tailored for significant scale. Building and maintaining multiple joined knowledge graphs is a substantial engineering investment, appropriate for managing the complexity of 46 repositories. For a startup with a handful of services, this approach is likely over-engineering. The cost of building the tooling would exceed the value gained from the improved searchability.

Finally, the tactic is an incremental solution. It solved the most immediate "entry-point" problem by leveraging an existing asset. It did not solve the other three issues Tsuji identified in his first post, including node explosion and the need for custom parsers. The playbook is not a complete fix for AI code understanding, but a specific, high-leverage move to solve the search problem first.

Landing

The most effective way to add semantic meaning to a complex codebase may not involve analyzing the code itself. airCloset's approach was to find the most structured and context-rich part of their system, the database, and make it the source of truth. By linking the code to the data, the logic inherited meaning. This strategy of "context inheritance" treats different parts of a tech stack not as islands to be mapped individually, but as an interconnected system where context from one domain can be projected onto another.

The investor read

This playbook documents an internal tooling investment, not a commercial product. It signals a mature engineering organization (airCloset) building a technical moat to manage complexity at scale. The move from generic AI developer tools to proprietary, context-aware systems is where enterprise value is being created. For an investor, seeing a company build this kind of sophisticated internal platform is a strong positive signal about its technical leadership and ability to improve developer velocity. It's an investment in efficiency and scalability, demonstrating a focus on long-term operational leverage rather than short-term product features. This is a characteristic of a company built for durability.

Pull quote: “The core pattern was established: a static-analysis graph combined with AI-generated context enables natural-language semantic search.”