i asked claude instead.

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

I will write a Slack message, reread it, decide I have not investigated enough, and delete it. Then I ask Claude.

Claude does not think the question is stupid. It does not 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 have 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 have involved another person. Now I can get surprisingly far without telling anybody that I am 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 had 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 have already opened three times and somehow failed to understand.

An agent removes all of this.

It is available at midnight. It will explain the same function again. I can paste an error, say "no bro, that is 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 did not 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 could not. The machine made it easier to work alone. It did not 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 am changing, which part of the system confused me, and which assumption I am 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 am 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 am near the boundary.

This matters more when working remotely. There is 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 did not 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 is 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 cannot assign a percentage to how much somebody trusted me, and I definitely cannot speak for their side of the relationship. I know that on my side it felt lower.

One question to Codex did not 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 would 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 are not magically correct. They forget things, defend decisions they made, and occasionally explain folklore that has not been true since 2021. The advantage is not 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 am 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 do not do this consistently. Sometimes I notice that the question needed a person only after the code exists and I am 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 had 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 am trying to read until I can own the result, not until I have 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 would start if it broke in production. If I cannot do that, the task is not done. The agent may be done. That is 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 is not 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 have finished my chai.

At that point, the limit is not tokens. It is 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 do not prove that either agrees with the product.

I am trying to pay most attention to the assertions, fixtures, negative cases, and boundaries. I want to know whether the test would have 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 has not 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 is 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 did not spend the previous hour inside the agent's reasoning.

6. What I am trying to change

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

The fix is not a ban on Claude or Codex. I am trying to change when another person enters the work.

These are guardrails I am 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 is cheap to inspect and reverse.

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

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

And I am trying to notice when I chose the agent because it was the best source and when I chose it because a person might make me feel slightly stupid.

That second feeling is useful information.

I want to stop the agent when I cannot summarise what it is 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 have 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 am trying to send the message

Claude is the easiest coworker I have ever had.

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

It also cannot trust me. It can disagree with my approach, but it cannot object as the person who may have to maintain the resulting system next year. It will not notice that I have 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 am trying to send it before I have all the answers.