
The problem Developer onboarding is one of the most expensive workflows in software, and one of the least measured. A new engineer joining an unfamiliar repository spends days on archaeology before their first meaningful commit: tracing how a request enters the system, working out which module owns which state, and discovering conventions that exist only in a senior engineer's head. The README is usually a version behind. The architecture diagram, if it exists, describes a system that no longer looks like this. Meanwhile a senior engineer answers the same questions repeatedly, and early pull requests bounce back for rework because the newcomer touched the wrong layer or duplicated an existing utility. Generic AI assistants make this worse before they make it better. Asked how a codebase works, they produce fluent, confident prose with no way to check it. A newcomer cannot tell a correct answer from an invented one, so they either trust it and break something, or ignore it and go back to reading. The solution OnboardPilot turns a public GitHub repository into a verified onboarding map in under a minute. The user pastes a repository URL. OnboardPilot assembles a bounded, ranked context from the real source — documentation, manifests, entry points and shallow core modules, with dependencies, build outputs and binaries excluded — and fans that single shared snapshot out to five specialist agents running in parallel: Architecture Mapper, Entry-Point Detective, Convention and Risk Radar, First-Task Generator, and Ramp-Up Planner. The report answers the questions a newcomer actually has: what is this system, how does execution start, what are the house rules, where are the landmines, what can I ship this week, and what is the shortest verified path to my first merged pull request. Results stream live, so each section appears the moment its agent finishes. What makes it different First, every claim cites the file it came from, rendered as a chip that opens that file on GitHub, plus an evidence index. No evidence, no claim. Second, agents must declare what they could not determine, so the report ships with an honest gaps section: knowing what to ask is half of onboarding. Third, the ramp-up plan uses self-verifiable checkpoints, not reading lists. Fourth, all five agents reason over one identical context snapshot, so their conclusions agree instead of each inventing private facts. Finally, the report exports as ONBOARDING.md, which can be committed next to the code so the next newcomer never has to ask again. Impact The manual equivalent takes hours to days; OnboardPilot produces its map in under a minute and regenerates it whenever the code moves. It does not replace the conversation with the team. It removes the reading work before that conversation, so the conversation starts at a much higher level.
27 Sep 2026