Most "AI code reviewers" summarize. They tell you what a repository looks like.
But thats not what technical due diligence is.
When anyone evaluates a repository, especially in early-stage startups they’re not asking:
“What does this repo do?”
They’re asking:
Where will this break?
Is this production-ready?
Is it deployable?
Is this observable?
Is this Secure?
What’s missing?
And what's the evidence behind any of those answers?
So I built a small, standalone tool to answer that question.
The Problem With Repo “Analysis”
Most LLM-based repo tools suffer from two problems:
They hallucinate.
They are non-deterministic.
You get confident language with weak grounding.
That’s fine for summaries.
It’s dangerous for due diligence.
If you’re evaluating a YC-backed startup, an open-source infra project, or even an internal platform team’s codebase you need something different.
You need:
Structured evaluation
Repeatable scoring
File-level citations
Confidence metrics
So I built exactly that.
What It Does
You run:
dda analyze <repo_url>
It produces a CTO-style report, a structured scorecard, file-level evidence references, and an inferred architecture graph.
The key design constraint:
Every claim must be backed by evidence.
If evidence is missing, confidence drops.
No silent assumptions.
The Architecture
The architecture is simple by design — clone, extract, score, verify, render. It's not trying to replace a human reviewer. It's trying to make first-pass review systematic so reviewers spend time on judgment calls instead of scavenger hunts.
What I Learned
Building this forced me to think about:
What “production-ready” actually means
How to formalize architectural judgment
How to design evidence-first systems
How to separate signal from narrative
The most interesting part wasn’t the code.
It was designing the rubric.
You realize very quickly:
Taste is hard to encode.
What’s Next
Version 1 focuses on:
Structure
Docs
CI
Deploy artifacts
Dependency signals
Next upgrades:
Timeout / retry detection
Kubernetes resource limits analysis
Backpressure patterns in Go
More granular reliability scoring
The goal isn’t to make a flashy AI tool.
It’s to make a systematic thinking engine.
Why I built it
Because every time I've evaluated a repo for an open source project I'm considering adopting, I end up doing the same manual archaeology. Grep for Docker files, check for CI configs, look for monitoring setup, scan dependencies. It's repetitive, it's slow, and the findings are trapped in my head or a messy doc somewhere.
I wanted a tool that does that work systematically and gives me evidence I can point to. Not vibes, not summaries actual file paths and concrete gaps.
If that sounds useful, I'm happy to share the repo or run it on something you're working on.