Don’t outsource the thinking

His arguments make sense, but I also recently came across research examining the influence of AI tools on how and why members of software engineering teams interact. Their finding was not surprising: of the 131 surveyed developers, 51% said they now ask GenAI for technical help they once would have asked a person, and 62% said it was easier to ask GenAI without fear of embarrassment. When a junior gets stuck now, their first move usually isn’t to message a senior on Slack. It’s to ask the agent. This is also the case in code reviews.

The purpose of code reviews was always knowledge sharing as much as it was a quality gate. What I see junior engineers do now is take the feedback and, without reading it closely, hand it straight to the agent to resolve. The part where they would have to understand how their work differed from what the senior expected disappears. It got passed from the reviewer to the agent, and the junior skipped the understanding. This isn’t really the junior’s fault.

They need the motivation and the space to do it differently, and the default pattern under delivery pressure is to push the thing out and worry about it later. The same research showed that developers turned to colleagues with questions about context (65% to clarify business logic or requirements, 50% for how something had been done before). Respondents were also aware of the trap that Berry’s approach was created to avoid: AI tends to hand back a single answer, compared to multiple perspectives a colleague surfaces and they kept seeking teammates for context-specific expertise, mentorship and plain social connection. The fix is almost mechanical: if you have to make a choice, you have to think about it. I do this in my own product thinking.

Most of it happens by bouncing ideas off Claude, but whenever something is complex, I make myself lay out a few options, trade them against each other and decide which direction to take.