From Writing Code to Directing and Reviewing Agents
Why directing agents and reviewing small stacked pull requests has become the actual engineering work, and why that process has to stay in the open.
Earlier this month I wrote about turning the repeatable work into a skill, which was about writing down the sequence so the agent can run it without a fresh briefing every time. This post is the shift underneath that work, because adopting the tools was the easy part, and the harder part has been changing what I think my job is once the agent is writing most of the code.
The temptation is to treat prompting as the new skill, as if the work is just learning how to ask. For me the real change has been moving off the line-by-line coding and into architectural oversight, where I instruct the agent to operate like a staff engineer inside a specific codebase while I keep the strategic steer. That sounds cleaner than it feels on a Tuesday afternoon, because the old muscle still wants to type, and the new muscle is reading, judging, and deciding what happens next.
If I keep measuring the day by how many lines I wrote, the agentic week looks empty even when a feature moved. The value now sits in the integration, the tightness of the feedback loop, and whether I still have a clear picture of the system while the agent is moving through it, since without that picture, speed is just a faster way to lose the plot. The other risk is overload, because you can generate more output in an afternoon than you can honestly review, and if you try to hold every file in your head at once you burn out on context switching. The way I have been keeping that in check is by making the unit of work small enough that I can stay in the reviewer’s seat without drowning.
Why the diffs have to stay small
Once you are working this way, the primary job is reading and reviewing output rather than producing the first draft. A massive one-shot generation looks impressive until you try to actually read it, at which point the subtle bugs hide in the volume and you are left rubber-stamping a black box or spending the evening reconstructing what the agent decided.
That is why I have been putting GitHub’s stacked pull requests into custom agent skills, forcing the work to land as a stack of small, readable PRs instead of one giant change. Each layer is a diff I can actually understand, and because the agent comes back almost immediately, I can sit in a tight loop as reviewer and QA, checking that the piece in front of me matches the standard before anything else in the stack moves.
The skill is doing the same job the App Store release skill does for Sittally, holding the process so I do not have to re-explain how to break the work down, open a stack, and wait for a person to look. I described that pattern in the skills post, and stacks are the version of it I want when the work is a feature instead of a version bump.
Review is how the agent learns the house style
Review in this workflow is not a one-way gate at the end, since every time I send back a note on a naming convention or a design pattern, that context stacks into the agent’s memory for the rest of the run, and often into the skill for the next one. Priming up front still matters, because I would rather the agent start as a staff engineer in this repo than as a clever intern with no taste, but the continuous feedback is what actually teaches it how we work.
Over time that cuts the review friction down, not because I stop reading, but because the generated code starts closer to the bar we already hold for production. The human stays in the loop the same way I have been arguing for on the management side, where the agent gathers and drafts, and I still decide.
More than one hat, on purpose
The part I did not expect to enjoy as much is how this flattens the delivery process, because when the agent is handling the boilerplate execution, I can move between assembling product context and edge cases, drawing system boundaries, inspecting diffs and directing fixes, and iterating on the UI, without each of those being a different week. The ClickUp skill I wrote about, the one that lets an engineer or a product manager start from the same task, is a version of that idea for the team, because the context both roles would have assembled sits in one place and the agent can carry the feature from there.
That is also the answer I have for people who worry that relying on agents will erode their coding muscle. The fear is real, especially for junior and mid-level engineers who still need reps, and I do not think the fix is to pretend we are not using the tools. The fix is to treat the work as reading, evaluating, and directing architecture, so proficiency looks like systems mastery instead of being the person who typed every character. You still have to know enough to catch a bad abstraction, and you get that knowledge by reviewing tightly, not by accepting a giant PR because it compiled.
Keep the process in the open
It is easy for this to become an isolated experiment, where each person has a private set of skills and a private sense of what works. My job as an engineering leader is to model the behavior in the open, sharing which skills we are building, where they fail, and how we want the agent primed, so the org evolves together instead of as a pile of silos.
That is especially true for the people who feel less capable the more they lean on an agent. Teaching someone how to prime, review, debug, and guide output is still teaching the craft, even though the lesson is now systems thinking and architectural oversight rather than syntax dictation. Encouraging people to contribute those skills and prompt patterns back into a shared place is how you onboard the next person without making them reconstruct the process from a chat history.
I am going to keep asking the agent to work in pieces I can actually read, and I am going to keep the confirmation in a person’s hands, because the speed is only useful if I still know what we shipped.