Should You Care That New Hires Ask AI Before the Team?

Which questions is it safe for a new hire to ask a model?

The ones where checking the answer costs less than getting it. A syntax question, a definition, a first draft of a regex, the shape of a standard filing: if the answer is wrong, the code fails, the search returns nothing, or a two-minute read catches it. Those questions were always cheap, and routing them to a model costs the team nothing it was actually getting.

The dangerous class is the mirror of that. Ask which questions only your team can settle and the list is short and specific: why the retry logic is deliberately wrong in one place, which client's contract has the carve-out, why the previous version of this report got pulled, what the reviewer rejects on sight. A model answers all of those fluently and from nothing.

What that split looks like in the work:

• Software engineering. "How do I write a migration in this ORM" is cheap: it runs or it does not. "Is it safe to backfill this column in place" is not, because the answer lives in traffic patterns and a bad deploy from March that nobody wrote down.
• Financial analysis. A model will define a normalization adjustment correctly. It will not know that this issuer changed segment reporting last year and the prior-year figure in the pack is on the old basis.
• Legal operations. Clause language is cheap. Whether your counsel accepts a mutual indemnity at that cap is precedent, and the precedent sits in a folder and in three people's memory.
• Marketing. Copy structure is cheap. Which claim compliance has already refused twice is not, and the model will write it back confidently.
• Healthcare revenue cycle. Denial-code definitions are cheap. Whether this payer pays on a corrected claim or requires a formal appeal is local, and the model does not know which payers you are contracted with.

So the rule is one line: route by whether the answer can be checked without a person. If the check is cheap, the model is a reasonable first stop and probably a faster one than you. If the only check is somebody's memory of what happened here, that question was never the model's to answer.

Is asking AI first a sign they're avoiding the team?

Rarely, and the data suggests a duller reason. It is a sign the cheapest channel changed. In a questionnaire of 1,000 Americans who had started a new role in the previous twelve months, 44% said they turned to AI first when they got stuck, ahead of asking a colleague at 25% and a manager at 20% ¹. The study calls itself non-scientific and exploratory, and its data was collected in October 2025. Read it as a direction, not a measurement.

What changed is the price of the question, not the loyalty behind it. Asking a person has always cost something: an interruption, a moment of looking like you do not know, a wait until they are free. The model costs none of that and it is awake at eleven at night. That trade shows up well beyond your team. After ChatGPT launched, activity on Stack Overflow fell by 25% within six months, measured against Russian and Chinese counterparts where access was limited and against mathematics forums where the model performs poorly, and the authors read their estimate as a lower bound ⁴. The decline was larger for the most widely used programming languages, and post quality did not measurably drop.

People do still route to a person for the things a person is for. In Stack Overflow's 2025 survey of more than 49,000 developers across 177 countries, asked what would still send them to another human in a future with advanced AI, the top answer was "When I don't trust AI's answers" at 75.3%, ahead of ethical or security concerns at 61.7% and wanting to fully understand something at 61.3% ³. The human channel is getting reserved for judgment, which is the same rule you want your new hire using.

The loyalty read also costs you something concrete. In that same new-hire questionnaire, 66% said they had used an AI-generated idea or response without disclosing where it came from ¹. A manager who treats asking the model as a small betrayal gets the same behavior with the receipts removed, and undisclosed use is use nobody can check. This is a different problem from never having learned to work without the tool, which is about missing fundamentals. This one is about a habit that is mostly rational and occasionally very expensive.

Why is this riskier in month one than in year five?

Because verification runs on knowledge a new hire does not have yet. A senior reading a confident wrong answer notices that it contradicts how the billing service actually retries, or that no client on that contract has ever been invoiced that way. Someone in week three reads the same paragraph and finds nothing to disagree with. The answer is plausible, and plausible is all they can currently assess.

The research points the same direction. In a survey of 319 knowledge workers who supplied 936 first-hand examples of using generative AI in real work tasks, higher confidence in the tool was associated with less critical thinking, while higher task-specific self-confidence was associated with more of it ². A new hire is low on the second and, having watched the model be right about everything they have so far been able to verify, high on the first. That is the worst corner of that chart to be standing in, and it is where onboarding puts people by construction.

The same study names the mechanism without euphemism: 58 of the 319 participants reported barriers to inspecting AI output, including not possessing enough domain knowledge to judge whether an answer was correct ². One month in, that describes nearly everything about your business.

And the failures that get through are not the obvious ones. In the same 49,000-developer survey, the most-cited frustration with AI tools was "AI solutions that are almost right, but not quite" at 66% ³. Almost-right survives a read by someone who does not yet know better, and it fails later, at the point where it meets your data, your customer or your reviewer. That is the shape behind candidates who demo brilliantly with AI and then struggle in month one, and behind juniors who can produce anything but cannot tell when it is wrong. See how Olive measures this.

What does good routing look like on an ordinary Tuesday?

It looks like a question that arrives already narrowed. Someone routing well does not ask you what a deferred revenue schedule is. They ask whether this contract's ramp counts as a modification, because the model gave two defensible answers and only your team's precedent settles it. The question carries what they tried, what it returned, and the one specific thing they could not check.

Four things worth watching, all of them visible in ordinary work rather than in a conversation about AI:

• The questions narrow. Early questions are broad because everything is unfamiliar. By week six the ones reaching you should be the ones no search resolves: precedent, exceptions, and why a thing is the way it is.
• They bring the model's answer with them. "The assistant says do X, but the runbook says Y" is the best single sign on this list. It means they checked, found a conflict, and brought the conflict to the person who can settle it.
• They tell you what they could not confirm. A caveat attached to their own work ("I could not confirm the restated 2024 figure") is worth more than a clean deliverable, and it is the habit that keeps working as they get more senior.
• The work survives contact with your records. Not whether it reads well. Whether the number ties to the system, whether the client name is the right legal entity, whether the query returns what the dashboard returns.

Two things look like tells and are not. A drop in total questions is ambiguous: it means either that they are routing well or that they have stopped asking anything at all, and only the shape of the remaining questions separates those. And a first draft that reads like a model wrote it says nothing about whether anybody checked it, because polish and checking are unrelated. What good AI use actually looks like is a set of acts, not a writing style.

Write the routing rule in their first week

Say out loud which classes of question belong to a person, and name the person. Two or three lines covers it: anything touching a customer commitment, anything where the team has a precedent the internet does not, and anything about to ship that nobody has read. Everything else is theirs to route however they like. A rule nobody stated is a rule nobody is breaking.

Then make asking cheap enough to compete with a text box. Name one person whose job it is to answer for the first month, and say it in front of the team so the new hire is not spending a favor each time. Put a standing fifteen minutes on the calendar rather than telling them the door is open: an open door still costs a decision to walk through, and a scheduled slot costs nothing.

Seed the check. Most local answers live in three or four places, usually the runbook, the deal folder, the ticket history and whoever was here in 2023, and a new hire who does not know those exist cannot consult them. One afternoon spent walking through where the local record lives converts a whole class of uncheckable questions into cheap ones, which is the only durable version of this fix.

Check at the boundary rather than over their shoulder. The first artifact that reaches a customer, a repository or a filing is the honest test, and it gets read against the local record instead of for polish: does the figure tie to the system, does the clause match the executed version, does the recommendation survive the one number nobody opened. Say in advance that this is the review, so it reads as a standard and not as suspicion.

And ask the routing question directly in the one-to-one. "What did you check yourself this week, and against what" has a good answer available, and the answers improve the moment people know it is coming. It also surfaces the honest version of the problem, which is sometimes that the last person they asked was short with them, and that is something you can fix this week. It settles the older question of whether training is enough or the work has to be checked afterwards too: a routing rule with no check at the boundary is training with nothing attached to it.

See the benchmarks >