Published: 2026-01-21 21:15
If you're writing code, chances are you're not building something brand new from scratch. You're working around old bugfixes, weird code from a guy you never met, and years of technical debt you don't even know exists. And when you whip out coding agents like Claude Code, OpenCode, or Codex, the output is overwhelming. Your eyes gloss over and you accept whatever changes the LLM suggested.
This is vibe coding and we don't do that here.
Call a sub-agent to do research and digging. Find patterns, environment variables, and anything else lurking in your codebase. Gather as much information from these exploratory sub-agents as possible.
Once they're done, they'll output their relevant findings to the main thread. You can use this output as part of your overall context for questions or further research. But here's the key: give the sub-agent a specific task. Don't tell it to "act like a senior engineer" or "data expert." That's a waste of time and context.
Do some upfront planning on your own. Then leverage these sub-agents to answer questions that fill the gaps in your knowledge about the decade-old codebase you're working in.
Once research is done, read everything you added to the markdown file. Take out anything that doesn't align with your vision for the fix. If something's unclear, spin up a new agent and ask for more information. Your end result should be a research document with all the details about the code you're about to edit.
Load your trimmed and refined research.md file into the agent's context window. Enter plan mode and ask it to build a plan using the research to assist. Spend more time here than you think you'll need.
Once the plan is made, read it and find any excuse to ask the LLM questions. If something is ambiguous, unclear, or doesn't exactly match the model in your mind, bring it up. You are accountable for the code the LLM produces. We must avoid wasted time fixing slop from the day before.
This reminds me of a quote attributed to an IBM presentation slide from 1979: "A computer can never be held accountable, therefore a computer must never make a management decision." I take this further with AI agents: because LLMs can never be held accountable, they must never make a decision without human agreement. It's on you to think, to choose, and to fully understand what code is going in and what code is coming out.
Take that plan and divide it into reasonable chunks of work. This isn't just for the LLM—though it does help. This is mostly for human review. Asking your coworkers to review thousands of lines of code changes in a single PR is terrible for everybody.
I use the Linear MCP server since my team uses Linear. With the plan, I ask the LLM to split the work into small chunks. The size is at your discretion, but I like good breakpoints where part of the work is complete and not tightly coupled with another chunk.
Once I have the plan chopped up, I have the agent use the Linear MCP to create tickets under a master ticket. This would be easier in Jira with epics—you'd create the epic then make all the tickets within it.
Now that the plan is divided, it's time to start. Begin a new session in Claude Code or your favorite agentic engineering tool. Enter plan mode and give the LLM the information to execute phase one.
Verify all changes are as you expect, then commit the work. Here's where stacked PRs come in: since phase two likely needs work from phase one, make a new Git branch from the phase one branch after submitting the PR for phase one. This lets you continue working while waiting for coworkers (or CodeRabbit) to review.
No need to wait around. This increases your output to match your ability to verify the LLM's code changes—not limit you to how long PR reviews take. If changes need addressed in a previous PR, switch branches, make the fix, and rebase up your stack.