A senior engineer’s honest account of the moment AI productivity tools stopped being a superpower — and what I rebuilt after. Photo by Vitaly Gariev on Unsplash It started with a Teams message at 11:43 PM. “Hey — did you actually read through PR #117 before approving it?” It was from my teammate, our lead backend engineer. The kind of guy who notices when a variable name is one character off from what it should be. The kind of guy you don’t want asking that question. PR #117 was a service refactor I’d reviewed two hours earlier. I’d used Claude to scan it — flagging logic issues, checking edge cases, summarizing what changed. I had approved it in under four minutes. The code was fine. my teammate wasn’t asking about the code. The Productivity Trap Nobody Talks About There’s a version of this story that’s already been written a hundred times. AI makes you faster. You ship more. You review more. You close tickets like a machine. Your manager notices. Life is good. That’s the true version. And it’s also dangerously incomplete. What nobody tells you is that speed has a social cost in engineering teams. When you start moving 3x faster than your colleagues, you don’t just look productive — you look suspicious. You look checked out. You look like someone who isn’t actually reading the code. Because sometimes, you aren’t. I’m not confessing to being a bad engineer. I’m confessing to something more uncomfortable: I had optimized for output so aggressively that I had quietly stopped doing the parts of my job that weren’t measurable. The mentorship conversations I’d shortened. The PR reviews I’d skimmed. The architectural discussions I’d half-attended while Claude summarized them in a side tab. My metrics were pristine. My presence was hollow. What Actually Happened with PR #117 The PR itself wasn’t broken. Claude had correctly identified that the service behaved as intended, that edge cases were handled, and that the test coverage was acceptable. What Claude couldn’t tell me was that my teammate had been trying to get the team to adopt a new error-handling pattern for three weeks. He’d brought it up in two standups and left a comment thread in Chat. PR #117 was the first place he’d actually implemented it — quietly, to see if it would get noticed. I approved it without noticing. Not because AI failed. Because I had delegated the act of paying attention to a tool that doesn’t actually pay attention. It processes. There’s a difference. My teammate wasn’t angry. He was deflated. “I just assumed you’d seen it,” he said the next morning. “I was waiting to see what you thought.” That conversation cost me more than the four minutes I’d saved. The Reframe That Changed Everything Here’s the thing I had to accept: AI coding tools are force multipliers, not force replacements. A force multiplier makes your judgment faster. It doesn’t replace your judgment. The moment you start using it to avoid judgment — to skip the reading, the thinking, the noticing — you haven’t become more productive. You’ve become a faster version of absent. The engineers I’ve seen genuinely thrive with AI tools share one trait: they use AI to prepare themselves to engage more deeply, not to avoid engaging. They use it to pre-scan a PR so they can ask smarter questions — not so they can approve faster. They use it to draft a proposal so they can spend their energy on the debate — not the writing. They use it to summarize a codebase so they can understand the tradeoffs — not so they can pretend they already do. The output looks identical from the outside. The internal experience is completely different. And teams feel the difference even when they can’t name it. What I Changed (And What Actually Worked) I didn’t stop using AI tools. That would be like blaming a calculator for bad math. I changed three things: 1. I explicitly separated AI-assisted tasks from human-required tasks Some things I do with AI: first-pass code review, documentation drafts, boilerplate generation, test scaffolding, summarizing long threads. These are tasks where the goal is a correct output, and AI is faster and often more thorough than I am. Some things I do without AI, deliberately: architectural debates, 1:1s with junior engineers, final approval on anything that touches our core data layer, any conversation where someone is trying to show me something. These are tasks where the goal isn’t an output. It’s presence. 2. I told my team what I was doing This sounds uncomfortable. It was. I sent a message to the team channel explaining that I’d been using AI tools heavily for review tasks, that I thought I’d overdone it, and that I was changing how I used them. I was specific. I named the tools. I named the habits. The response was not what I feared. Three engineers replied that they’d been doing the same thing and feeling weird about it. We ended up having the most useful conversation we’d had in months — about norms, about what “review” actually means on our team, about where AI help was welcome and where it felt like a shortcut. Transparency about AI tool usage is still weirdly taboo in engineering teams. It shouldn’t be. The teams openly discussing it are the ones developing actual norms, instead of everyone quietly optimizing in isolation and slowly eroding each other’s trust. 3. I made “did I actually notice this?” a quality gate After every PR review, I ask myself one question before approving: Is there anything in here that I noticed — something specific, something my teamate or whoever wrote it was trying to do — that I can point to? If the answer is no, I go back and actually read it. This takes longer. My throughput on reviews is lower. My team trusts my approvals more. This is not a coincidence. The Numbers Don’t Show What You Broke I’ve been writing about the real-world gap between AI tool promise and team dynamics for a while now — including what happened when I let AI write, review, and deploy my code for a full week . That experiment taught me a lot about what breaks technically. The PR #117 incident taught me something harder: what breaks quietly, in the space between people. The sprint board never showed a flag. Velocity stayed up. Stand-ups were fine. What degraded was my teammate’s sense that his craft was being witnessed. That the three weeks he’d spent thinking about error handling mattered to someone. That wasn’t measurable. It was real. Productivity is not the same as contribution. And in a team, contribution is social. It’s the thing that makes someone feel like their careful pattern got noticed by someone who actually gives a damn. The tools are not the problem. We are the problem — specifically, the willingness to let the tools absorb the parts of the job that were never really about output in the first place. The Honest Bottom Line Use AI tools. Use them hard. They make you faster, sharper, and more thorough on the tasks where speed and thoroughness are what’s needed. But know the difference between tasks where the goal is the output — and tasks where the goal is you showing up. Your team can tell which one you’re doing. The code in PR #117 was fine. Make sure people know you actually read it. Before You Go If this resonated — especially the part about the gap between metrics and presence — I’d genuinely appreciate a follow. Next week I’m publishing: “Why I Stopped Letting AI Write My Commit Messages — And What That Decision Revealed About How I Think.” It’s more personal than this one. Drop a comment if you’ve had a version of this type of conversation. I want to know how your team handled it. I’ll reply to every one. My Team Caught Me Using AI to Merge PRs. The Code Was Fine. The Trust Wasn’t. was originally published in Artificial Intelligence in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.