| ▲ | I built an AI reviewer that analyses code as a PM and a system architect(github.com) | ||||||||||||||||
| 3 points by Kapitsyn 5 hours ago | 3 comments | |||||||||||||||||
| ▲ | Kapitsyn 5 hours ago | parent [-] | ||||||||||||||||
Hi, I'm Vlad. For the past year I've been CTO at a fast-growing startup with 60+ engineers across 10 separate products, and here's why I ended up building this. Every product had the same two problems that slowed releases and piled up tech debt: - constant business-side changes and shifting scope mid-development - engineers taking initiative and quietly diverging from the agreed system design Neither gets caught by existing review tooling or Team leads cross-reviews, so this whole class of drift goes unflagged. We decided to build an AI linter that reviews code through two lenses: the PM's and the system architect's. The first version works as a scanner: - analyses a defined window of 30 / 60 / 90 days - pulls business context from GitHub/GitLab and Jira/Linear/Slack - runs on local Claude Code / Ollama as the LLM. Nothing leaves your machine - can generate a proposed fix for each mismatch it finds On our own projects it surfaced between 20 and 221 mismatches per 30-day window. We also ran it against an OSS project as a cold-start test and it found 5, though in that case the only business context available was public GitHub issues, so take that number with a grain of salt. In our internal tests, signal quality was around 96% (meaning the team accepted the finding as something worth addressing). That number almost certainly won't hold up on arbitrary codebases, which is exactly what I want to get data on. What I'd most like feedback on: if you run it on your own repo, how does the signal-to-noise ratio actually feel? | |||||||||||||||||
| |||||||||||||||||