How I built a Go CLI to parse 50k files in <10s and stop architectural drift

You know the feeling. You jump into a massive, legacy monorepo, and instead of writing code, you spend two weeks trying to figure out which microservice talks to what. The original architecture is either lost to "spaghetti dependencies" or hidden in an outdated Confluence document.

I wanted a tool to automatically enforce boundaries and map this out. The problem? Existing tools were either painfully slow (relying on regex) or used LLMs that hallucinated system relationships. I needed something blazing fast and 100% deterministic. So, I built Onboard-CLI.

What is Onboard-CLI?
Onboard-CLI is a local-first, standalone binary that maps your codebase's architecture and blocks dependencies that violate your established boundaries—before they ever hit a PR review.

You can check out the source code and try it locally:

The Tech Stack (and why I chose it)

1. Go for Concurrency
   I needed raw speed. Go’s concurrent worker pools allowed me to engineer the CLI to rip through massive codebases—analyzing over 50,000 files in under 10 seconds.

2. Tree-sitter for AST Parsing
   I completely avoided AI and regex. Instead, Onboard-CLI uses Tree-sitter to parse the Abstract Syntax Tree (AST) of the code. This means it maps the actual structural dependencies with 100% accuracy without ever executing the code.

How it works in practice
The workflow is designed to be completely invisible until you make a mistake:

Define: You define your architectural rules in a simple architecture.yaml file (e.g., "The UI component cannot directly call the Database layer").

Hook: The CLI runs as a local Git hook.

Enforce: If you try to commit code that violates the YAML rules, the CLI blocks the commit and shows you exactly where the architectural drift occurred.

Because it's a standalone binary, your proprietary code never leaves your local machine.

I need your feedback!
I am actively looking to break this tool and find its limits. Since I'm transitioning into the industry soon, getting real-world edge cases from senior engineers is incredibly valuable to me.

How does your team currently handle architectural decay?

Have you run into specific edge cases with Tree-sitter parsing?