Balancing Thinking with Agentic Coding

A few months ago, Anthropic published a study on agentic coding that looked at the tradeoff between efficiency and comprehension. The findings weren't surprising: engineers who used AI finished faster but performed measurably worse on comprehension questions about the work they'd done. Engineers who didn't use AI took longer, but they understood what they'd built. So what? Does this even matter? It's an uncomfortable question. If you're running an engineering organization, do you care whether your engineers understand the work as long as it ships quickly? My answer is yes, at least for now, and for two reasons. The first is obvious. When something breaks, you want people who know where to look. Models can help. Point them at a Slack thread, a Datadog alert, a support ticket, and as frontier models improve, they'll handle more of this autonomously. But they don't always solve the problem. The scenario I don't want to be in: a production incident, a room full of engineers whose only move is to keep prompting Claude Code, and the model isn't getting there. Now imagine the API is down. You want people who actually know the code. The second reason is less obvious but more important. When the cost of producing code drops dramatically, what differentiates your software? One frame I've found useful: functional code versus fantastic code. Anyone with access to the same model can ship functional. Fantastic requires engineers who understand the product domain deeply, who have taste, judgment, and genuine comprehension of the problem they're solving. Without that, you're producing the same thing as everyone else.

---

I almost never write code myself anymore. The models are genuinely excellent at it. But I've built some habits specifically to keep from outsourcing my thinking along with the keystrokes. Work step by step. I have instructions in my CLAUDE.md that shape how I plan and work. We always start by understanding the problem: what does success look like, what are the constraints, how am I currently thinking about it. I have the model ask questions and we go back and forth, sometimes 5–10 turns, before any plan gets made. When the context feels solid, I ask for a plan structured in phases, with each phase explained in terms of how it fits the overall problem. Within each phase, file by file, with reasoning for each change. Then we complete one phase and stop. I review, ask questions, and only then move forward. It's slower. It's worth it. Ask a lot of questions. Drew Bent, head of education research at Anthropic, talks about AI fluency as a social skill, not just a technical one. That framing landed for me. Going back and forth with a model might feel strange at first, but "why did you do that?" unlocks more than you'd expect. Treat it like a conversation with a person whose reasoning you actually want to understand. Write it down. This one seems obvious in retrospect, thinking on paper has a long history, but making myself articulate concepts, draw them out, put them somewhere that makes sense to me is the single biggest thing I do to verify I actually understand what was built. Not just that it works. That I get it. Know your cognitive limits. I now run multiple Claude Code sessions simultaneously. For routine work or familiar codebases, this is fine. For complex problems or new domains, it becomes a liability fast. I have a finite amount of thinking capacity, and it's easy to breach the ceiling without noticing. The signal is exhaustion, mistakes, a general sense of frantic. I'm learning to be deliberate about how many hard problems I'm carrying at once. Obvious in theory. Genuinely hard to manage in practice.

---

The amount of ground you can cover with capable AI is remarkable. The product surface area that can be shipped is kind of astonishing. But the trap is real: skill atrophy in raw coding is probably fine-the models have lapped most of us (for sure me) there anyway. Cognitive atrophy is different. Thinking atrophy, handing over not just the keystrokes but the reasoning, will show up in the software and the product. Maybe not immediately, but it will show up and it will not be good.

Our thinking and understanding are the things worth protecting.