I spent 3.8 million tokens finding which service to change
Code: github.com/alexcpn/catalogify · uv tool install catalogify · MIT Take a monorepo with ninety microservices in it. A spec lands that will touch maybe three of them. Before anyone writes code, somebody has to work out which three, and on a repo that size that is most of the job. I wanted to know what it costs to let an agent answer that. So I did the obvious thing and gave it a map. There are…
An engineer used Graphify, a tool that parses code with tree-sitter and builds a queryable graph of symbols and call edges, to determine the costs of identifying which service in a large monorepo would be affected by a change. The tool took 706 files in 20 seconds for one service, producing a 14.5 MB JSON file with 3.8 million tokens.
The engineer realized that the first question of identifying which services are impacted should be separate from the second question of understanding the changes within a specific service. Graphify excels at the latter, providing a precise impact radius with just a few hundred tokens. However, the former question requires a more comprehensive understanding of the codebase.
The engineer built a markdown wiki with small files per service and typed frontmatter, linking to neighbors. For the same Kubernetes component, this generated 1.004 KB of markdown, representing 256,968 tokens. An alternative approach involved mining git history for revert commits, revealing hidden fixes and providing valuable insights.
The engineer believes that a better routing catalog should have two layers: one using markdown for quick, domain-specific knowledge and another running a graph query for in-depth analysis. Implementing this composite approach can be more cost-effective than using either method alone, especially as the number of services grows.
Written by urgent.news from Dev.to's reporting — not their text. Machine-written — may contain errors; check the original before relying on it.
