Avi Cavale, founder of Quarterback, the AI development platform that learns how teams build, says new hires struggle not because of skill gaps but due to missing organisational knowledge, exposing a growing challenge that AI tools have yet to solve.
We hired an engineer last month. Excellent resume. Strong systems background. Passed all the interviews. And for the first three weeks, she was operating at maybe 20% of her capability.
Not because she can’t code. She’s a better programmer than most of the team. But she didn’t know that the billing service has its own database because of a cascading failure we had in March. She didn’t know that the auth module was rewritten six months ago and half the Stack Overflow answers she found referenced the old implementation. She didn’t know that there’s a subtle coupling between the notification queue and the payment webhook handler that causes silent failures if you change one without changing the other.
She didn’t know any of this because it lives in people’s heads. And every AI tool she opened started from the same zero she did.
The invisible tax
I’ve been paying more attention to onboarding costs lately, and the numbers are worse than I expected.
It’s not the direct costs – those are obvious. It’s the distributed costs: the senior engineer who spends 30 minutes explaining the deployment pipeline. The tech lead who answers the same architecture question for the fourth new hire this year. The PR review that takes three rounds instead of one because the new person didn’t know about a convention that’s in nobody’s head but the three people who’ve been here since the beginning.
For a team of twenty with four hires a year, I estimate we lose 2-3 engineer-months annually just to knowledge transfer. Not in salary – in lost output from both the new engineers ramping up and the existing engineers slowing down to help them.
And it resets every time. Every new hire starts the same journey. There’s no compounding.
Why current AI tools don’t help
I had this realization while watching our new engineer use Claude Code on her first week. She asked it to ‘help me understand how payments work in this system.’ The AI read the code and gave a structural answer — these files exist, this function calls that function, here’s the class hierarchy.
Technically accurate. Completely useless for actually understanding the system.
It couldn’t tell her that the retry logic was changed last quarter because of a specific production incident. It couldn’t tell her that the team prefers idempotency keys over at-most-once delivery. It couldn’t tell her who to ask about the legacy reconciliation module. It didn’t know any of this because it doesn’t have organisational memory. It just reads code.
A ramped-up engineer who already understands the system asks the AI to ‘refactor the payment retry logic’ and gets great results. The AI can do the mechanical work. But it can’t bridge the knowledge gap for someone who doesn’t yet understand the system. And that gap is where all the ramp time lives.
What it could look like
I keep imagining what her first week would have been like if the AI had organisational knowledge. Not just code – the decisions behind the code, the patterns the team uses, the errors they’ve encountered, and who knows what.
She asks ‘how do payments work here?’ and gets:
The architectural overview – auto-generated from the repo, kept current. Three key decisions the team made: why Stripe over Adyen, why a separate billing service, why webhooks over polling. Two known error patterns: the idempotency edge case under high load, and the webhook signature that breaks in staging. Who the domain experts are – two senior engineers for the core flow, one for the legacy reconciliation module.
What work was done recently: a pricing change last month, a webhook migration the week before, a load test the previous sprint.
She didn’t read a wiki. Nobody scheduled an onboarding session. The AI provided the equivalent of a month of tribal knowledge transfer in one response – because the system had been capturing that knowledge from every engineer’s sessions for the past year.
The bus factor
Here’s the scenario every engineering leader dreads: the one person who understands a critical system gives their notice.
We’ve been here. It’s terrifying. You scramble to schedule knowledge transfer sessions. You ask them to write docs (they won’t finish in time). You hope the replacement can figure it out from the code.
I’ve been thinking a lot about what this looks like when the AI has been capturing knowledge continuously. Every session the departing engineer had – every decision they made, every pattern they explained, every bug they fixed – exists as structured knowledge. It doesn’t walk out the door with them.
It’s not a complete replacement for their expertise. But the difference between ‘the code and nothing else’ and ‘the code plus hundreds of structured knowledge items covering decisions, patterns, and context’ is the difference between a three-month recovery and a three-week recovery.
Why this only works with compounding
You can’t solve onboarding with a static knowledge base. Wikis and architecture docs are snapshots that start decaying the moment they’re written.
You solve it with a system that compounds. Every conversation adds to the knowledge base. Every decision is captured. Every pattern is recorded. The system gets richer every week, automatically, without anyone maintaining it.
A new engineer six months from now has access to everything the team learned in those six months — plus everything before. Their AI is as informed as the most senior person on the team, from their very first session.
That’s not a faster coding assistant. That’s a fundamentally different onboarding experience. And it only exists if the AI remembers.
