I ask my coding agent to make a change. A few minutes later, it proudly presents me with code.
Beautiful. Sometimes genuinely impressive.
And then comes the part nobody puts in the demo.
Was that actually the change I wanted? Does it work outside the agent's imagination? Who checks it? And when an unhappy client calls, am I supposed to give them GitHub's phone number? I wanted the text to be more flowing, but didn’t expect a waterfall animation of letters…
The agent wrote the code. Great. Who owns everything that happens around it?
This is not a theoretical question for me. Before building IssueFlow, I spent a ridiculous amount of time glued to the IDE, chasing agents, checking their work, and figuring out what they meant to do next. Coding was becoming the easy part. I was the unpaid traffic controller. Without the whistle.
“Improve the onboarding flow.” Sure. Which part?
I got plenty of requests like that from testers.
“Improve onboarding.”
Helpful. Like handing a mechanic the keys and writing “Makes a funny noise” on the repair ticket. Great. Which noise? Engines aren't exactly famous for their silence. I'd probably check whether the radio was tuned to the comedy station first.
Which screen? What's confusing? Is something broken? What would a better experience even look like?
I often knew the person who reported it, so I could mostly guess what they meant. But then I had to open the page, recreate the experience, and translate the request into something a coding agent could actually work with.
Agents are fantastic at suggesting answers to vague questions. Sometimes they suggest fourteen answers, a product strategy, and a motivational speech you didn't ask for.
But if we don't know where we're going, producing code faster just gets us lost with better acceleration.
I don't need a five-page requirements document to change a button. I need to know which button, why we're touching it, and how we'll recognize that we fixed the right problem.
The agent can code. Can it make the decision?
Let's say the agent finds two perfectly reasonable ways to implement something. Both compile. Both pass tests. One changes how the product behaves.
Should it pick one and hope I like surprises?
Some questions are the agent's homework. In one of my own IssueFlow workflows, an agent got stuck because Jam credentials were missing—even though there was no Jam link in the issue. Apparently, the agent had developed its own very dry sense of humor: it was about to send a human off to fix access to a tool nobody needed.
Before waking up a human, maybe check whether the thing you're panicking about is even relevant. My dog understands the difference between the doorbell rang and we need to open the door. Most of the time.
But sometimes the choice actually belongs to a person. Maybe it changes the user experience, the scope, or a trade-off only the product owner can settle. Like a table scan that could add $200 to the cloud bill. That is a surprise I'd prefer to approve in advance.
That's a good reason to stop. Just come with the options and context. Don't show up with “I need guidance” and expect me to conduct a full archaeological dig through the agent's transcript.
A human approval gate should carry a decision, not simply move the burden to someone with a pulse.
And then the code is “done”
Here's my favorite part.
The agent announces something like: “Task completed successfully. Production ready!”
Excellent. Did it test the behavior the client complained about? Did the review find another issue? Did the integration actually work? Are we ready to ship?
Sometimes “done” means “I finished typing.” I also finish building things from LEGO. That doesn't mean the dinosaur has all its legs.
Tests, reviews, recovery, and release decisions aren't decorations we hang on a pull request afterward. They're part of delivering good software.
And “try again” is not always a recovery strategy. If the agent keeps repeating the same mistake, giving it more tokens is like asking someone who took a wrong turn to drive faster.
We should know what failed, what needs to happen next, and what information the next attempt needs. Otherwise I become the person carrying the entire workflow in my head—which was exactly the job I was trying to stop doing.
I don't want to babysit agents. I want to own the work.
There's an important distinction here.
I don't want to approve every comma, ask for a status update every three minutes, or supervise an AI version of a school field trip.
I do want to know what we're building, who or what is handling each step, where human judgment matters, whether a failure has been dealt with, and what evidence says we're actually finished.
That is the problem I am trying to address with IssueFlow: a delivery workflow where stages, routes, human decisions and recovery are explicit, rather than invented on the fly by whichever agent happens to be holding the keyboard.
I'm not claiming that this magically eliminates defects or cuts delivery cost by some spectacular percentage. I'd want real evidence before saying that. And if it takes another ten dashboards to prove the workflow is working, we've probably created a new problem.
So who owns the rest?
Not every decision needs a human. And not every decision should be quietly delegated to an agent either.
The builder still owns the outcome—even if an agent writes the code, another reviews it, and a third writes an enthusiastic summary of how well everybody did.
The trick is letting them do useful work without losing track of the actual job.
In IssueFlow, I define the prompts, the guides, and the boundaries for when an agent should wake me up—and when it should let me enjoy the new game on my phone.
I eventually built myself a three-stage escalation ladder, with me at the top. By the time an issue reaches me, I want to know what happened, what the options are, and what decision I actually need to make.
I don't need another agent telling me it's confused. I already have enough confusion of my own.
The point isn't to make the agents think exactly like me. It's to let me stop thinking for all of them.
Top comments (0)