Questions
Answered in the first sentence.
Everything below is the short answer first and the mechanism second. Where something is not built yet it says so, because that is the one habit this product is sold on.
Does my source code leave my machine?
Not when you run it yourself. The command-line scan reads your code where it already is and uploads a report — findings, paths, line numbers and the graph — never the contents of your files.
There is a second way in, and it is the one that does send code: the GitHub App copies the commit to our analysis server, because a scan has to run somewhere and that way nothing is installed on your side. Which path you take is yours to choose, and the install page lists exactly what the App reaches.
The schema has nowhere for source to live. That is a property of how it is built rather than a promise, and a gate holds it on every field of every table.
What does MLReps actually give me?
A graph of your system read out of your code, and the answers computed from it.
Services, routes, modules, files, functions and the data stores they read, with the edges that connect them — and each edge marked as read or inferred, because an inferred edge drawn as a measured one is the product claiming to have seen something it reasoned about.
From that graph: what a change reaches before it is merged, where a performance problem is, where a credential was written into source, and how much of the repository could not be read at all.
Which languages can it read?
Run it yourself and it reads every language it has an adapter for, using the language server for that language. Use the hosted GitHub App and it reads Java, JavaScript, Kotlin, PHP, Python, Rust and TypeScript.
The adapters are language servers — the same ones your editor uses — so what MLReps knows about a language is what that server knows, rather than a parser we wrote and have to keep current.
Whatever it could not read is counted and named on the report. A language with no adapter is listed as unread, never silently left out of the total.
Is this an AI code reviewer?
No. It writes no review comments and does not post on your pull requests.
The product is the graph and what can be computed from it. A review tool reads the diff in front of it; MLReps reads the system the diff lands in, which is where the second question — what else does this touch — is answered.
Most teams who use one want both, and the comparison page says plainly where the line is.
We already have error monitoring. What is different?
Error monitoring watches software that is running; MLReps reads software that is written.
Nothing is installed in your application and nothing is collected from your users. The analysis is of the code, so it can answer a question before the code ships rather than after it breaks.
That also bounds what it can know: it cannot tell you what your traffic did last night.
Can somebody who does not write code understand it?
That is the test the interface is held to. A founder, a product manager or a new developer should be able to open a report and see what the project does and what needs attention.
Every screen leads with what is true rather than with what the screen is, and complexity is revealed as you go deeper rather than all at once.
The twenty public reports are the honest way to check that claim, because they are about projects you may already know.
What will it refuse to tell me?
Anything it did not actually measure — and it says so in place of the number rather than leaving the space blank.
A rule that could not run is reported as not run, never as a clean result. A region of your code the scan could not read is counted and named.
A count of what a change reaches is a floor, and it is labelled one. A ratio with anything unresolved in it can reach 99 and never 100.
What is not built yet?
Anything that depends on watching your software while it runs, the screen-to-API half of the architecture map,.
The guard process that answers your editor or coding agent while you work runs on macOS and Linux. It has not been measured on Windows, and on Windows the command line says so rather than starting something that will not work.
Saying what is not true yet is the habit this product is sold on, so the list is on the page rather than in a roadmap nobody reads.
Why is there an MLReps report on a repository you do not own?
Because the fairest way to show what this produces is to run it on code you can already read, and we would rather be checked than believed.
Those reports show architecture and performance findings in full. Security findings are shown as counts only — no file, no line, no detail — because a public page naming a weakness in somebody else's project is a page that helps the wrong reader first.
If you maintain one of those projects you can ask us for the detail, or ask for the page to be taken down, and we will do either.
Do you send my code to a model?
No. Every finding, every number and every edge on the graph is computed from your code by the analysis itself.
The rule it is built on is that the graph answers and the model only ever explains: a model may not create a node, an edge or a score, and may only speak about what the analysis already produced.
The one screen that used a model to phrase an answer is switched off, and the security page says what would be sent if it were ever switched on.
What does it cost?
A run of the analysis is charged once, and four things are never charged at all.
There is one page with the numbers on it, because a figure written on two pages is two offers to somebody about to pay.
Still deciding
- Reports on public repositories — the output, on projects you may know.
- How it works
- Compared with other tools
- The security posture
- What is kept, and for how long
- Run it on your own repository