The Question Your Teammate Never Heard

Suppose you’re changing how a payment request gets retried after a timeout. Ask a teammate for help, and they learn you’re working on the payment path before they give you an answer. Ask an AI assistant privately, and you can get the answer without anyone else knowing you’re there.

The difference matters even when the assistant is right. Getting an answer unblocks you. Asking a teammate also gives them a chance to recognize a conflict with something they’re changing. A private exchange leaves that opportunity out unless you bring the decision back to them.

In Anthropic’s December 2025 study of its own engineers and researchers, which included 53 interviews, employees described turning to Claude for questions they previously asked colleagues. Some reported fewer interactions and mentorship opportunities.

About half of the interviewees reported unchanged team collaboration patterns. Others valued having Claude handle routine questions while keeping the difficult, context-heavy ones for colleagues.

Those are employee accounts from one AI company, collected through a process the authors acknowledge was subject to selection bias. The study doesn’t measure a loss of team capability or connect AI use to incidents. It does document a change in who gets asked.

The risk we infer is that a team can keep getting answers while losing the occasions on which engineers learn what others are deciding. Fewer conversations alone don’t establish that loss. If a review or shared decision record gives affected colleagues the context they need, working privately needn’t leave them out.

Who gets credit for the explanation?

If you recognize engineers for closing their own work but treat helping a colleague understand it as time away from delivery, solving things privately becomes a sensible choice. AI makes that choice more available. The engineer gets unstuck without waiting for help, and the finished work has their name on it.

Under that rule, the engineer who stops to explain a constraint can look less productive than the one who moves straight to the next task. Give the next interesting project to whoever appears most self-sufficient, and you’ve reinforced the difference. Leadership can teach this through a pattern of assignments without ever announcing a policy against collaboration.

We call the resulting habit the solo reflex: solve privately, ship individually, leave shared understanding for later. It can spread without anyone deliberately hoarding knowledge. The engineer who explains a decision spends time now; the benefit goes to whoever has to change or operate the system after them. If that benefit never enters the performance conversation, the engineer has a reason to stop providing it.

The payment example has a concrete failure mode. As Stripe explains in its engineering account of safe retries, a charge can succeed even when its response never reaches the caller. In the design Stripe describes, the client attaches an identifier to the operation and reuses it on a retry. The server can then recognize the repeated request and return the earlier result rather than charge again.

Suppose the retry code starts creating a fresh identifier after a timeout. The server can now treat the retry as a new purchase, even though its duplicate-detection code hasn’t changed. The person editing the retry loop has changed a rule that both sides rely on.

An assistant with access to the repository and a recorded decision can help catch that mistake. It can only check against the context available to it. A teammate kept out of the discussion has a similar limit, but asking them exposes your plan and gives them a chance to compare it with their own. If that comparison happens only during a failure, someone has to reconstruct the reasoning as well as debug the code.

Make shared understanding count as delivered work

Code review already has a role here. A 2013 study of code review at Microsoft found knowledge transfer and increased team awareness among its benefits, alongside finding defects. Preserving that function gives review a purpose even when an assistant has helped check the implementation.

For a change that constrains someone else’s work, give the affected maintainer enough context to challenge the decision before it becomes their problem. In the payment example, that means agreeing on how a retry will be recognized as the same purchase and keeping that reasoning with the change.

Ask the maintainer to trace the case where the charge succeeds but its response is lost. Can they show where the retry keeps the original identifier, and which test checks that it doesn’t charge again? They can use the code, decision record, or an assistant. The useful evidence is being able to apply the constraint to their own work, rather than recite the author’s explanation.

These are familiar practices. The incentive changes when the engineer who makes that understanding possible gets credit for delivered work, rather than a thank-you followed by criticism of their personal ticket count. Include the handoff in the scope of the assignment. When assessing performance or choosing who will own the next shared-system change, ask what their colleagues can now do without depending on them.

Counting meetings, review comments, or documents would recreate the same mistake: visible activity standing in for useful work. A short comment that lets another maintainer apply the retry rule can be enough. A long walkthrough that still leaves them dependent on its author hasn’t finished the handoff.

That takes real engineering time. Use it where decisions constrain other people’s work, rather than requiring an audience for every syntax question. If a current decision record answers the question and the affected maintainers already understand the constraint, another meeting adds little.

Pick a recently changed critical path and ask the next maintainer to explain the decision it relies on, using the records they’ll actually have. If they have to summon the author to reconstruct it, put that unfinished handoff back into the work you recognize and assign. It belongs beside the feature that shipped.