i asked claude instead.

I work remotely and hate asking questions I feel I should already know the answer to.

I'll write a Slack message, reread it, decide I haven't investigated enough, and delete it. Then I ask Claude.

Claude doesn't think the question is stupid. It doesn't have a meeting I might interrupt. It responds immediately, remembers enough of the repository to be dangerous, and lets me ask six increasingly confused follow-up questions without changing its opinion of me.

This is perfect for an introverted software engineer.

The uncomfortable part is that I've known this for a while. Every time I deleted the message and opened Claude instead, I knew I was choosing relief. I kept calling it efficiency.

I spend most of my day with Claude Code and Codex. They search repositories, explain systems, chase errors, write code, and review what the other one wrote. A few years ago, many of those activities would've involved another person. Now I can get surprisingly far without telling anybody that I'm stuck.

At first, this felt considerate. I was protecting my coworkers' focus. I was also protecting myself from the tiny embarrassment of asking something obvious.

The agent gave me the answer. I could feel my relationships at work getting thinner anyway.

My mistake was not using the agent. It was continuing to use it as an escape hatch after I'd noticed the cost.

1. The agent has no social cost

Asking a person for help has a price, even on a healthy team.

I need to decide whom to ask. I need to explain enough context without sending an essay. They may be busy. They may answer tomorrow. Worst of all, they may reply with a link I've already opened three times and somehow failed to understand.

An agent removes all of this.

It's available at midnight. It'll explain the same function again. I can paste an error, say "no bro, that's not what I mean," and continue without spending any social capital.

This awkwardness is common. A recent study of professional developers found that 51% now ask generative AI for technical explanations or debugging help instead of asking a teammate. Sixty-two per cent said it was easier to ask AI without fear of embarrassment. One participant gave the exact reason I recognise in myself: the question felt stupid.

The study didn't find a clean disaster. Developers said AI helped them stay focused. Straightforward questions went to the machine, leaving coworkers to discuss harder problems. Some teams had fewer interruptions. That sounds good because it often is good.

But the same study found another effect. Developers still wanted human contact, and 73% said coworkers provided alternative perspectives that AI couldn't. The machine made it easier to work alone. It didn't make working alone sufficient.

2. A small question does more than get an answer

Suppose I ask a coworker, "Do you know why this state lives in the host instead of the web app?"

I want an answer. The question also tells them what I'm changing, which part of the system confused me, and which assumption I'm about to make. They may tell me that the boundary is accidental. They may tell me that three years ago it prevented an incident. They may ask why I'm touching it at all.

If I ask Claude, I may get a detailed reconstruction from code, commits, and documentation. It can be excellent. Nobody else learns that I'm near the boundary.

This matters more when working remotely. There's no overheard conversation and no accidental glance at somebody's screen. Microsoft studied communication patterns across more than 61,000 employees during its shift to remote work. It found that groups became more siloed and that cross-group collaboration fell by about 25% from its pre-pandemic level.

That Microsoft study predates the current generation of coding agents. AI didn't create the problem. Coding agents fit into the gap with uncomfortable precision.

For years, Shopify has used the metaphor of a "trust battery." Tobi Lutke described trust as something that starts partially charged and moves up or down through repeated interactions. You work through a problem together. You do what you said you would do. The battery changes a little.

It's a metaphor, not an employee stat I want added to a dashboard. Still, it helped me name what felt off.

My trust battery did go down.

There was no fight and no dramatic loss of confidence. I spoke less. I shared work later. I gave people fewer chances to correct me while my ideas were still cheap. Coworkers increasingly saw the finished pull request instead of the uncertain thinking that produced it.

Then reaching out became harder because we had less recent practice working through things together. I can't assign a percentage to how much somebody trusted me, and I definitely can't speak for their side of the relationship. I know that on my side it felt lower.

One question to Codex didn't do that. Repeating the choice for months did.

3. The machine knows the repository. My coworker knows why it became this repository

Agents are good at questions whose answers exist somewhere.

Where is this value set? Which library owns this retry? What does this error mean? Has another service implemented the same pattern? Please read these eleven files because I'd prefer to keep the remaining years of my life.

I should reach for a person when the answer depends on memory, authority, or disagreement.

Why did we accept this trade-off? Is the requirement still true? Which team should own the state? If we make this easier for our service, who gets paged when it fails? Does this feature deserve to exist?

Code contains some of that history, but not all of it. Documentation contains less than we like to pretend. An agent can infer the missing pieces and present the inference in the same tone it uses for facts.

Coworkers aren't magically correct. They forget things, defend decisions they made, and occasionally explain folklore that hasn't been true since 2021. The advantage isn't that a person contains perfect context. The advantage is that a conversation can expose competing versions of the context.

The developer study found almost exactly this division. Seventy-one per cent would use AI for help implementing an algorithm. Sixty-five per cent preferred a coworker when clarifying business logic or requirements. When validating whether a solution made sense, the result was nearly split.

That split is where most of my work lives.

I'm trying to use the agent to prepare for the conversation instead of avoiding it. I can ask it to find the relevant code, recover previous decisions, and point out what I may have missed. Then I can send a coworker a smaller and better question.

I don't do this consistently. Sometimes I notice that the question needed a person only after the code exists and I'm preparing the pull request. By then, asking for input feels less like collaboration and more like asking somebody to approve a decision I already made.

The machine can lower the cost of reaching out. I'd used it to avoid reaching out altogether.

4. The code can be finished before I own it

After the agent writes the code, I can avoid a second uncomfortable thing: understanding all of it.

Should I read every line? Should I only inspect the plan? If the tests pass, can I move on? Once the diff gets large enough, "read all the code" stops being advice and becomes a guilty thought I have while scrolling quickly through 4,000 lines.

I'm trying to read until I can own the result, not until I've inspected every character.

I should be able to explain what behaviour changed, which assumptions the change relies on, how it fails, and which boundary it crosses. I should know where I'd start if it broke in production. If I can't do that, the task isn't done. The agent may be done. That's different.

The amount I need to read depends on what can go wrong. For a reversible UI cleanup, I can inspect the result, sample the diff, and rely on focused checks. For authentication, permissions, money, migrations, data deletion, or concurrency, I want to read every changed line and involve another person.

This isn't punishment for using AI. Human-written code deserves the same care. AI changes the economics because it can produce more code than I can responsibly absorb, then offer to review its own output before I've finished my chai.

At that point, the limit isn't tokens. It's attention.

5. I read the tests, especially when the agent wrote them

Tests make generated code feel safe. A passing suite gives the session a satisfying ending. The agent lists the commands it ran, adds a little green tick, and says the implementation is complete.

Sometimes it is.

But when one agent interprets the requirement, writes the implementation, and writes the tests, the implementation and tests can encode the same mistaken interpretation. The tests prove that the code and tests agree. They don't prove that either agrees with the product.

I'm trying to pay most attention to the assertions, fixtures, negative cases, and boundaries. I want to know whether the test would've failed before the fix. One way to check is to break the implementation deliberately and see whether the test notices. This is the software equivalent of putting smoke near a smoke alarm instead of admiring its green light.

I still accept the green light too easily. A long agent run ends with passing tests and a tidy summary, and some part of my brain wants the task to be over. Knowing about the trap hasn't removed it.

Even review aids deserve suspicion. In a controlled experiment with 86 Python programmers, participants judged correct generated assertions with 74% accuracy but incorrect assertions with only 49% accuracy. They reported similar confidence in both cases. Low-quality natural-language explanations could make their judgement worse while increasing confidence.

That study bothers me because explanations are precisely what agents are good at producing. A plausible explanation feels like understanding. Sometimes it's only a second generated artifact agreeing with the first.

For risky work, I want an independent source of truth. That may be a test written from the requirement before the implementation, a production trace, a deliberately broken input, or a coworker who didn't spend the previous hour inside the agent's reasoning.

6. What I'm trying to change

I still ask agents an unreasonable number of questions. I don't want to bring back the old ritual of being stuck for two hours to prove that I tried hard enough.

The fix isn't a ban on Claude or Codex. I'm trying to change when another person enters the work.

These are guardrails I'm trying to build, not a description of a system I already follow perfectly.

I still want to send these questions to an agent:

• Questions based on public technical knowledge.
• Repository searches and mechanical investigations.
• Basic questions I might otherwise avoid asking entirely.
• First passes that help me form a better question.
• Work that's cheap to inspect and reverse.

I'm trying to involve a coworker earlier when the answer depends on company history, an ambiguous requirement, or who'll own the result. Earlier is the part that matters. Showing somebody a polished diff isn't the same as letting them influence the idea.

I'm also trying to share useful things the agent finds. If Claude uncovers a surprising dependency or reconstructs an old decision, that context shouldn't die inside my private session. A short team message can turn private investigation back into shared knowledge.

And I'm trying to notice whether I choose the agent because it's genuinely the best source, or because asking a person might make me feel slightly stupid.

That second feeling is useful information.

I want to stop the agent when I can't summarise what it's changing, when the diff becomes larger than the attention I have left, or when the implementation and tests depend on the same unverified interpretation.

I still miss those stopping points. The agent keeps moving, and movement feels like progress. Sometimes I only recognise the limit after I've created a review problem for myself and everyone else.

The hardest rule is simpler. If another person will have to operate, review, or inherit the decision, they should hear about it before the pull request arrives.

I'm trying to send the message

Claude is the easiest coworker I've ever had.

It's patient, available, technically capable, and completely safe to look stupid in front of.

It also can't trust me. It can disagree with my approach, but it can't object as the person who may have to maintain the resulting system next year. It won't notice that I've quietly stopped talking to everybody else.

Sometimes the considerate thing is to ask the machine and protect a coworker's focus.

Sometimes I should send the Slack message.

I'm trying to send it before I have all the answers.