Designs for Humans, Plans for Agents

There’s a thing you need to build. Maybe it’s in Jira. Maybe it’s in a Google Doc. Maybe it’s just rattling around in your head while you’re making coffee. If you’ve been using agentic coding for a while, you already know the routine.

You fire up Claude Code. You know better than to one-shot the feature, so you start working the problem with the agent. First comes the plan. You ask it to outline the implementation before touching code. Then comes the back-and-forth. You refine the approach. You question assumptions. You tighten scope. You work through trade-offs.

Eventually you tell it to start implementing. This is when the babysitting begins.

Turn by turn:
“Can I modify this file?”
“Can I run this command?”
“Should I refactor this?”
“Do you want me to update tests?”

Some permissions you’ve defaulted. Some it asks for every single time. Eventually, you land a PR and wait for review. If you’ve been doing this for a while, you’re probably running three sessions with Claude simultaneously. The PRs start piling up.

My team has been building remote coding agent capability, and it forced us to think really deeply about these workflows, the babysitting, and the PR reviews. A while ago, we realized we weren’t that interested in reviewing line-by-line diffs anymore – what we actually care about is the design. We tried to shift to reviewing the markdown plans, but in a RPI workflow, the plan is written for Claude, not people. I ended up having to use Claude to parse and poke the plans I was reviewing, and this took even longer! We decided to make a few strategic changes: shift the deep thinking and collaboration up-front, produce scoping and design documents for humans to review, and detailed implementation plans for a remote coding agent to execute.

The design is where humans collaborate. We use agents to help us arrive at the design, but human beings critique it. We debate it. We simplify it. We challenge assumptions. We pressure-test sequencing and trade-offs and operational concerns. Most importantly, we try very hard to keep the design readable – maybe 100–200 lines, and human-readable top-to-bottom. Because it turns out this is what I really want to review when a team is shipping large volumes of code, not the code-diffs. We are spending the most time reviewing the feature scoping and design documents. And now that these are intentionally created to be concise and human readable, they are much faster to review.

Once the design is agreed upon, we generate the detailed implementation plan for the agent. Now the workflow changes dramatically. I no longer need to sit there micromanaging an agent running locally on my laptop. I can hand the plan off to a remote coding agent running somewhere in the cloud and let it execute. The output is a traditional code-diff PR, and it is connected to all the context that matters: the top-level scoped outcome doc, the design (for this phase), the reasoning behind the decisions. Honestly, we just don’t spend a lot of time reviewing these remote agent PRs. We already have the remote agents act on anything they can automatically: merge-conflicts, bot review comments, CI failures. And the code base is opinionated and has a lot of guardrails for quality built into it: pre-commit hooks, test-coverage gates, linters, agent rules and code-review skills.

An important part of this process is breaking down the work into very small phases. The initial feature scoping document is where we determine the delivery phases, but we may break it down further in any of the phases’ design and plan iterations. I truly believe that there cannot be a PR that is too small, and this process favors small designs linked to a phase in the delivery of a feature. Anyone should be able to look at the PR request to review a design, immediately identify which phase it lands in of the larger feature, and then they have the context they need to give quality feedback. This also builds cross-linked artifacts for future-selves to go back and understand the thinking when we find issues and want to enhance features.

An interesting realization for me is that this doesn’t just feel like a software engineering workflow. It feels like a general workflow for knowledge work: Define outcomes → Define scope → Define phases → Research → Design → Implement. Then repeat. The implementation happens faster now, but the sequencing matters more than ever.

What we haven’t figured out yet is everything that happens after delivery. That’s still the old process, only AI-enhanced. Right now, this feels like the best use-case for running Claude Code on an engineer’s laptop. It’s incredibly good at helping debug real issues, and excels at revealing the connections across systems. This is where babysitting is necessary as I have Claude run the AWS CLI, tail logs, and look at the source code to debug issues quickly to solve pain.