21. February 2026
Software teams accumulate code the way cities accumulate buildings. One project at a time, one service at a time, one quick prototype that somehow became permanent infrastructure. Before long you have dozens or hundreds of repositories, and nobody has a clear picture of what’s actually there.
This is a surprisingly common problem. A new engineer joins the team and asks: “Which services are the big ones? What’s old? What language is everything written in?” The answers live in people’s heads, in outdated wiki pages, or buried across GitHub’s repository listings. There’s no way to just look at your codebase and see the shape of it.
That’s the problem codecity tries to solve.
Source code has physical properties – size, age, composition – but we almost never see them. We experience code one file at a time, through the keyhole of an editor window. We know intellectually that one service has 80,000 lines of Java and another has 3,000 lines of Go, but that knowledge doesn’t feel like anything. The numbers don’t create spatial intuition.
This matters more than it might seem. When teams lack an intuitive feel for their codebase, they make worse decisions:
What’s needed is something that makes the invisible visible – a way to see code the way you see a city skyline, where scale, age, and character are immediately apparent.
codecity renders your git repositories as buildings in a 3D city. The metaphor is deliberately physical:
The result is something genuinely useful: you can glance at the visualization and immediately know things that would otherwise require querying multiple APIs and assembling spreadsheets.
A tall, wide, blue building surrounded by short, narrow, orange ones? That’s your aging TypeScript monolith, surrounded by the newer Rust services the team has been migrating to. You didn’t need to read a document to understand that – you just saw it.
codecity offers two visualization modes, each answering different questions.
Repository View shows every repository as a single building. This is the skyline view – useful for portfolio-level questions. Which repositories dominate? What’s the language distribution? Where are the old-timers? You can sort, rotate, and zoom to explore the full landscape.
City Blocks View goes one level deeper. Each repository becomes a city block, and the directories within it become individual buildings inside that block. This reveals internal structure: is the code evenly distributed, or does one module contain 80% of the lines? Are there directories in different languages within the same repository? The block layout uses a bin-packing algorithm to create a natural grid, the way real city blocks fill available space.
Both views support hover tooltips showing exact statistics and click-to-drill-down navigation. The city is explorable, not just viewable.
Under the hood, codecity is a Rust backend paired with a Three.js frontend.
The backend uses git2 (libgit2 bindings) to analyze repositories. For each repo, it walks the source tree – skipping node_modules, target, .git, and other non-source directories – counts lines per file, maps file extensions to languages, and walks the commit log to find the oldest commit (which determines building height). When scanning a directory of many repositories, it uses Rayon for parallel analysis across CPU cores.
For GitHub repositories, codecity does a shallow clone followed by a full history fetch, so you can visualize any public repository without having it locally.
The frontend renders the city using Three.js with ambient and directional lighting, fog for depth, and shadow mapping. Taller buildings get procedurally generated window strips, giving them a skyscraper feel. Repository names appear as canvas-rendered 3D labels at the foot of each city block. Orbit controls let you rotate, pan, and zoom through the city.
The whole thing runs as a web application – point it at a directory on your filesystem, or give it a GitHub owner/repo path, and the city builds itself.
The moment the city renders, patterns jump out that would take significant effort to discover any other way:
Scale outliers become obvious. That one repository that’s quietly grown to 5x the size of everything else? It’s literally a skyscraper. You can’t miss it. In a list of repository names, it blends right in.
Language migration becomes visible. If your team has been gradually moving from JavaScript to TypeScript, the city shows it spatially – old yellow buildings in one part of the skyline, newer blue buildings elsewhere. The migration’s progress is visible at a glance.
Age distribution reveals itself. A city full of tall buildings with a few short ones scattered around tells a different story than a city that’s uniformly medium-height. The first is a mature codebase with occasional new projects; the second is a team that’s been consistently building at a steady pace.
Structural imbalance shows up in block view. When you drill into a repository and one directory dominates the entire block, that’s a signal. Maybe it’s fine – maybe that’s where the core logic belongs. Or maybe it’s an extraction candidate that’s been growing unchecked.
There’s a reason city planners use maps and architects use models. Spatial reasoning is one of the most powerful cognitive tools humans have. We evolved to navigate physical space, to judge distances, to notice things that don’t fit. When you represent abstract data spatially, you recruit those instincts.
Code metrics in a spreadsheet are data. Code metrics in a 3D city are understanding. The difference isn’t just aesthetic – it’s cognitive. You process the city in parallel, taking in the whole skyline at once, while a spreadsheet forces serial processing row by row.
This is particularly valuable in conversations. Pull up the city in a team meeting and suddenly architecture discussions become concrete. “We should consolidate these services” becomes “look, these five tiny buildings could be one medium-sized one.” “We have too much legacy code” becomes “look how many tall buildings there are compared to short ones.” Shared visual references make alignment easier.
codecity is open source and runs locally. The simplest path is Docker Compose:
git clone https://github.com/grahambrooks/codecity.git
cd codecity
docker compose up
Point your browser at the running instance, give it a path to your projects directory, and watch the city grow.
You can also analyze individual GitHub repositories without cloning them locally – just enter an owner/repo path and codecity handles the rest.
The project is at github.com/grahambrooks/codecity. It’s built with Rust and Three.js, supports Docker, Kubernetes, and Bazel deployments, and works on macOS, Linux, and Windows.
codecity is part of a broader interest in making software systems legible. See also codemap, which builds semantic knowledge graphs of codebases for AI agents. Both projects share the conviction that understanding code shouldn’t require reading all of it.