Do you consider yourself hands-on if you mostly send instructions and review agents?

Lately, I have been asking myself this question more often.

As my agents code more, I feel myself drifting away from the keyboard. Not because things slow down, but because they speed up. Delivery is faster than it has ever been, and the value is obvious. Still, something feels off. I am less hands-on, and more of a supervisor of a squad of agents.

At first, reviewing changed files felt like the right answer. It felt responsible. It felt like control. But over time, I realized that keeping up with diffs is no longer enough to truly understand what is going on. The pace amplifies a deeper issue. Reviewing files does not automatically translate to understanding impact.

In the past, hands-on work was my main way to build context. Measuring and listening to the team still matter, but writing code myself gave me a deeper sense of how things actually fit together. Today, even as coding becomes more hands-off and token-driven, I still find myself opening Neovim from time to time. Swimming in the mud, struggling to understand why an if statement is not 5 lines below, helps me learn deeply. Editing code forces me to confront assumptions, understand decisions, and uncover gaps and edge cases that are easy to miss otherwise.

One trap I actively try to avoid is focusing only on the files that changed. Reviewing diffs creates a false sense of understanding what is going into production. Code changes impact far more than the lines that appear in a pull request.

The real questions usually live elsewhere. What parts of the system will be indirectly affected? Which assumptions does this change rely on or quietly break? What release processes does this introduce or bypass? Often, the most important files to think about are the ones that were not changed at all.

Helping teams reason about this kind of impact requires more than just looking at code. Tools can help, but for them to be truly effective, they need context beyond the diff. Context across the codebase, the system, the product, and how it is actually used. They also need humans in the loop to provide intent, judgment, and direction. This combination is what allows teams to reason about change with confidence, even as delivery accelerates.

Because of this, I do not see hands-on and hands-off coding as opposites. I plan to keep both in my arsenal. Each has its own strengths. Hands-on work gives me deep context, helps me understand pitfalls and pain points, and allows me to technically unblock, brainstorm, and fix production issues with the team when needed. And maybe just as important, I genuinely enjoy it.

At the same time, I am starting to appreciate the power of interfaces more than ever. As reviewing changes takes more bandwidth, interfaces become critical for creating high-quality context. When done right, they compress complexity, make change easier to reason about, and enable better decisions.

This is where building strong tools and interfaces for engineering workflows becomes critical. They help shift the focus from reviewing changes to understanding impact and outcomes. They also allow you to deep-dive into the areas you find important or simply interesting, whether that is tracking significant changes, exploring feature requests, incidents, bugs, and support tickets, or dogfooding what you build, in four letters: SDLC.