Your codebase, in a form a new engineer can ask questions of.
DevGuide reads your repositories and your documentation and turns them into answers, with the file and the line attached.
It is in development. If onboarding engineers is expensive enough for you to want it early, we would like to talk to you about it.
A new engineer has three sources, and none of them is good.
Every team solves this the same way, by spending a senior engineer on it, and every team pays for it again the next time somebody joins.
What it does
Ask a question in plain language and get an answer built out of your repositories and your docs, with citations back to the file and the line. If it cannot support an answer, it says so rather than inventing one.
A guided checklist that walks a new joiner through access, environment, first build and first change, and tracks where they actually got to, so their lead can see it without asking.
DevGuide builds the service graph from the repositories: what calls what, what owns which data, and where the edges of each service actually are. Per project, rebuilt as the code moves.
It reads the codebase and extracts the conventions the team already follows: naming, structure, error handling, testing. A new engineer writes code that looks like everyone else’s in week one.
The end-to-end flows a user can take, derived from the code that implements them. The fastest way to learn what a system does is to see what it lets people do.
An AI-guided deployment readiness pass over infrastructure-as-code, container registries and multi-image workloads. The gap list, before the deploy rather than after it.
How it starts
Two halves of the same idea.
Prolens does this for the business: signals, evidence, decisions and what they turned into. DevGuide does it for the system those decisions get built into. They connect: what DevGuide learns about the codebase can be posted back to Prolens, so a decision and the code that implements it stop being two unrelated records.
You do not need both. DevGuide stands on its own.