Codebase onboarding is broken by design
Why reading documentation is a waste of time and how we're fixing the 'first week' friction.
By git11 Engineering · Sat Feb 28 2026 · 7 min read
The first week at a new engineering job is a tax on your sanity.
You show up, get your MacBook, and spend forty-eight hours fighting a broken README.md that hasn't been updated since 2022. Then comes the onboarding doc—a 15-page Notion graveyard of outdated architecture diagrams and 'TODO' comments.
We built git11 because we’re tired of watching brilliant engineers spend their first month asking where the auth logic lives.
The README lie
Every repository has a README.md. Most of them are lies.
Documentation is static; code is fluid. The moment a PR is merged, your documentation starts to rot. If your onboarding process relies on a human remembering to update a markdown file after refactoring a service, you’ve already failed.
Engineers don't want to read about the code. They want to know why services/payment-gateway.go is calling a deprecated internal API at 3 AM. No wiki explains the 'why' behind the technical debt.
We spent months interviewing leads at scale-ups. The consensus? It takes a mid-level hire three to six months to become truly productive. That’s a quarter of a million dollars in salary literally waiting for things to click.
Grep is not a strategy
You’re three days in. You need to add a field to the user profile. You start with grep -r "user_id" . and get 4,000 hits.
Half are in /tests, a third are in /migrations, and the rest are scattered across five microservices. This is where the friction lives. You don’t need a search tool; you need a map that understands intent.
Most AI tools try to write the code for you. They’re great at generating boilerplate but terrible at explaining the 50,000-line monolith you just inherited. Copilot is a better autocomplete. It isn’t a mentor.
If you ask a senior dev where to start, they’ll tell you: "Look at how we handle events in app/events/registry.ts, ignore the legacy stuff in old_events/, and then check the middleware."
That tribal knowledge is what we’re capturing with git11.
The context window problem
Current LLMs have a context window problem. Even with 128k tokens, you can’t shove a million-line repo into a prompt and expect a coherent answer about your dependency graph.
We’ve seen developers try to build custom RAG (Retrieval-Augmented Generation) setups using basic vector databases. They index every line of code, ask a question, and get a hallucinated mess because the model doesn't understand that index.js in the root is less important than the controller logic buried three levels deep.
Code isn't just text. It’s a graph.
If you don't understand the relationships between a React component, its custom hook, and the GraphQL query fueling it, you don't understand the codebase. You're just guessing.
Why we built git11
git11 doesn't just index your files. It maps your repo's mental model.
We built a system that analyzes your commit history, your PR descriptions, and your actual file structures to figure out what matters. When you ask "How do we handle rate limiting?", git11 doesn't just show you the RateLimiter class.
It shows you the Redis config, the decorator used on the API routes, and the specific PR where the infra team explained why they chose a sliding window over a token bucket.
We’re moving toward a world where 'onboarding' isn't a month-long process. It’s a ten-minute conversation with your repository.
Stop wasting senior time
The hidden cost of onboarding isn't just the new hire's time. It's the senior engineer's time.
Every time a new dev asks "Where is the database schema defined?", a senior dev loses their flow state. At three interruptions a day, your most expensive assets are basically running at 50% capacity.
Documentation should be generative, not manual. It should be queried, not read.
We built git11 to kill the 'onboarding buddy' role. Not because we hate people, but because humans are bad at being search engines. Let the machines handle the technical archeology. Let the humans handle the architecture.
If your repo is a black box, you’re losing money. Fix the map, and the developers will follow.