A Pragmatic Approach to Working With AI Agents
August 11, 2026
In the past six months a clear pattern has emerged while improving my workflow. I have put it into a diagram to try to explain it.
The diagram is sliced horizontally into four parts.
The first slice is the four boxes, and each box represents some text. We go from a problem statement to a task spec, from a task spec to a PR, and at the end we review.
The second slice is which actor does what. There is a human and there are AI agents. The agents are split into several roles, and the diagram keeps that part fairly simple.
The third slice is the amount of time I spend on each stage. Most of it goes into the first two boxes, almost none into the implementation, and the rest into the final review.
The last slice is the guidelines I follow to keep myself in flow and to keep the quality up.
Context
Underneath all of the steps in the diagram there is a context layer. I use it to make sure that an agent starting from a clean slate knows everything it needs to know. I have written about that separately in A Pragmatic Approach to Context Engineering.
Problem to solve and creating the task spec
Usually I have some problem I want to solve. I write a problem statement and take it to an agent designed specifically for helping me with task speccing. I usually like an interviewing style.
If a topic comes up that is relevant and that I am not familiar with, I pause what I am doing and study the topic.
I also think a lot about creating tasks that are small enough to keep the PRs small. I aim for 50 to 75 logical additions, which is without boilerplate, test files and similar.
This is where I spend the most time.
Then it is time to create the task spec, and that sheds light on whether I defined the problem clearly or not. If the task spec gets the intention, that is a good first step. If it does not, that is usually a sign that the problem statement was not clear enough, and I go back and rewrite it rather than patch the spec.
If bad architectural decisions go into the task spec, bad architecture comes out of it. That part is obvious, but it is worth stating, because it is the reason this stage gets the most attention.
PR creation and AI review
This part is automated by an orchestrator that creates the PR and reviews it. I allow a maximum of three to five cycles, depending on the task.
During this I just go and do something else. Usually research, or writing the next problem statement.
Final review
This is the last step from me. After it the PR either goes to a colleague for review or gets merged, depending on the review rules in place.
I read the whole PR.
The final review is often straightforward, with not many changes.
When there are a lot of changes, it is usually because I realized something that I did not know during task speccing. Then I either fix it on the spot or redo the whole flow with a new task spec, depending on how bad it is.
Code comprehension
This does not solve code comprehension, at least not comparable with what I would have had if I had typed the code myself.
But it does give me a good chance of knowing the code and the problem area. For most of my tasks that seems to be good enough.
Review burden
To avoid breaking flow and running into huge reviews, I keep the PRs small and put the work into research and task speccing up front.
Dark code
Dark code is the term for lines of software that no human has written, read or reviewed.
Currently I have not seen evidence that dark code can work in larger code bases and bigger team environments. Therefore my workflow is heavy on knowing what goes in, and on knowing the problem area.