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?
codingdave•1h ago
Your two problems are not tech problems, they are leadership problems. I find it interesting that a CTO looks for a tech solution instead of a leadership solution.
That isn't meant to be a diss on you as a leader - everyone is new at it at some point, and there is a steeper learning curve than most people would ever imagine. And more learning at every step up the ladder you take.
Effective leaders can instill the values that make people do what is needed to make the business work, regardless of rules. You want to empower your teams to build the processes that work for both them and the business, not pigeon-hole 60 engineers across 10 products into an AI-enforced process.
Kapitsyn•1h ago
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?
codingdave•1h ago
That isn't meant to be a diss on you as a leader - everyone is new at it at some point, and there is a steeper learning curve than most people would ever imagine. And more learning at every step up the ladder you take.
Effective leaders can instill the values that make people do what is needed to make the business work, regardless of rules. You want to empower your teams to build the processes that work for both them and the business, not pigeon-hole 60 engineers across 10 products into an AI-enforced process.