AI coding agents installed code nobody owned. The one move that builds trust with a team.
On August 27, 2026, Ars Technica reported that the coding agents Claude, Codex and Hermes had installed unowned code inside corporate networks, after 227 install commands were found in corporate documentation pointing at code with no owner.
The uncomfortable part of that story is not the agents. The 227 commands were already sitting in the documentation. The agents did what a diligent new hire does in week one: they followed the runbook. Every organization of any age carries code like this — dependencies whose authors have left, scripts nobody would claim, install lines that keep working right up until they don't. The agents did not create the orphans. They inherited them, obediently, at scale.
None of it is really about AI. Sooner or later somebody on your team finds the orphan. What that person does next is the whole subject of the trust question.
Why they ask it
A manager's output is the team's output, and nearly everything that determines it — pace, honesty in estimates, whether problems surface early or fester — runs on trust. The interviewer asks the question because most candidates answer it with values, and values are free. What they are listening for is a mechanism: evidence that you know trust is built in specific transactions, most of them uncomfortable, and that you can name the ones you use.
The sharpest version of the mechanism is this: trust accumulates when bad news comes from you first. Anyone can be transparent about good news. The team is watching what you do with the other kind, and so is your own leadership. The person who surfaces the unowned dependency before it breaks, in writing, with their name on it, is doing the concrete thing that "building trust" abstracts away.
The trap
The trap is the recital. "Transparency, consistency, doing what I say I'll do." Every candidate says some version of this, none of it can be checked, and it leaves the interviewer with nothing to grade.
The second form is the activities list: regular one-on-ones, skip-levels, team lunches. Those are venues, not evidence. Trust does not come from contact hours. It becomes visible only under load: on the day the news was bad, the mistake was near you, and saying so had a price.
The fix is to answer with one sentence of thesis and then one story in which telling the truth cost you something. If your answer contains no moment where honesty was expensive, you have described being agreeable, not being trusted.
Applying STAR-T
The question is general, but a strong answer lands in a story almost immediately. State the thesis, then prove it happened.
Situation. Make it concrete and inherited, so no one in the room is the villain. "Two months after I inherited the team, an audit of our deploy pipeline turned up a library in the release path with no owner: the author had left two years earlier, the source lived in a personal repo, and three services depended on it."
Task. Name the real choice. "I could patch around it quietly and look composed, or surface it and be the new manager who shows up holding problems. I decided the second one was the job."
Action. The mechanism, step by step. "I wrote it up in plain language — what it was, what would break if it vanished, what fixing it would cost — and sent it to my director before anyone asked. I described it as inherited without naming a culprit. Then I gave the team the plan in the open: fork it, take ownership, spend a sprint bringing it in-house. I carried the roadmap slip upward myself." Bad news, from you, first, with a plan attached.
Result. Trust has a measurable shape, and it is latency. "The dependency was owned and boring within a quarter. The larger result arrived later: engineers began flagging risks unprompted, and the next bad surprise reached me from my own team in minutes, not from an incident channel two days in."
Trade-off. "It cost a sprint of roadmap and some early polish; I looked slower in month two. I accepted that, because a manager who looks composed at the expense of the truth stays composed only until the truth arrives on its own schedule."
The follow-up that breaks weak answers
Two follow-ups do the damage here. The first is "how do you know it worked?" Weak answers reach for atmosphere: the team felt closer. Strong answers have a measurement: bad-news latency, the time between something going wrong and you hearing it from your own people. Watch that number fall over months and you are watching trust accumulate.
The second is "tell me about a time you lost trust." Candidates who answered with values freeze, because admitting a breach seems to contradict the recital. If your model of trust is transactional, the answer is available: name the moment, name the repair, and note the asymmetry: trust survives mistakes far better than it survives concealment.
Score your answer against the director’s bar
Q: How do you earn trust with a team?
Bank the story where the bad news came from you first, and rehearse it in L8 Loop until it sounds like the ordinary thing it should be. Try it free →