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.
Hi, I'm Ryan, CTO at airCloset.
This post is about unifying a production codebase spanning 46 repositories across multiple services into one knowledge graph, using static analysis.
Internally we call it code-graph, and I built it between January and March of this year.
Three things I want to write down:
Why "just letting AI read the code" isn't enough, and why I had to chase down the connections that cross repository boundaries
The biggest issue Part 1 left open was that AI couldn't reach the 46-repo codebase by natural-language query (the entry-point…
I've spent the last several months building ANIMUS, an autonomous system in Rust that gives a local...
Introduction: Why context windows are expensive and why static folder indexing fails to capture...
Every developer working with LLMs on a large codebase eventually hits the same wall: context windows...
One of the strangest workflows in modern software development looks like this: Ask ChatGPT a...
It was 2 AM on a Tuesday, and I was staring at a function I had never seen before. The codebase had...
