AI coding agents can implement a change ridiculously fast.
That's cool.
But the party is not over yet.
In my own IssueFlow workflow, implementation is only one stop. A normal production path can still include validation, security review, code review, UI/UX review, documentation, merge, merge validation, E2E against the deployed code, and cleanup.
And before implementation, there may already have been design, design review, and a human design approval.
This was not imposed on me. I built it this way on purpose. Fast code is nice. Code that is actually what I meant, fits the architecture, follows the standards, survives the real product, deploys correctly, follow my crazy quality requirements, and does not create the next fire is nicer.
The problem is what happens when one of those stages turns red.
“It failed” is not enough information
Take merge.
Thee are millions (almost) reason it can fail:
- A merge can fail because there is a real conflict.
- It can fail because CI is red.
- It can fail because a required check never ran.
- It can fail because GitHub is rate limiting us, a runner is having a bad day, or the infrastructure is unavailable.
Those are very different problems.
IssueFlow already had a failure-reason vocabulary before this week. That lets me say things like:
- merge conflict → resolve the conflict (back to implementation)
- real validation failure → rework the code (back to implementation)
- checks timeout → retry the merge
- infrastructure fault → wait/retry instead of rewriting code
- design no longer fits → go back to design.
That part is useful, but it is not the change I am excited about.
The harder question comes after recovery.
The harder question comes after recovery
Suppose a merge conflict sends the issue to implementation for conflict resolution.
Great. The conflict is fixed.
Now what?
Do I send it through validation again?
Security review?
Code review?
UI/UX review?
Every single stage?
Well, sometimes the answer is yes.
But! Sometimes that is just burning time and tokens to prove something we already know. And that is where it hits my sleep time and my pocket.
The same thing happens with a security finding.
Imagine security review says a dependency needs to be updated. The agent updates the library.
Do I need to re-check product intent?
Probably not if the product behavior did not change.
Do I need security and affected tests again?
Absolutely.
Or maybe the rework touched only test code. Does that invalidate the UI review that already passed? Maybe not.
A failure reason tells me why the stage stopped. It does not necessarily tell me which parts of the remaining workflow still add evidence.
Static workflows know a lot at the beginning
When an issue enters IssueFlow, the workflow can route based on things like complexity, issue type, environment, priority, role, and other dimensions.
That is already useful.
A chore does not need the same path as a large feature. An epic child does not need the same entry path as a standalone issue. A production lane can demand more validation than another lane and deployment is different.
But software has an annoying habit of teaching us things after we start. I know this problem since the 90's...
- Implementation may discover that the approved design no longer fits the current codebase.
- A backend-looking change may turn out to affect the UI.
- A security fix may change only a dependency.
- A rework pass may touch only tests.
- A merge problem may turn out to be nothing more than GitHub having a bad afternoon.
- Or an issue may simply have gone stale because the product moved on.
Those facts do not exist when the issue first enters the workflow.
But the agent that just handled that stage - knows!
Let the workflow learn while it runs
I recently added a mechanism to IssueFlow that lets a stage set or change a routing dimension while the issue is already running.
That new dimension becomes part of the routing state for the issue.
Later routing decisions can use it.
That sounds like a small detail, but it changes how I think about recovery.
The stage is not inventing a new workflow. The allowed dimensions, values, routes, and stages are still defined by the workflow owner.
The difference is that the workflow can now update its understanding of the work when new evidence appears.
So the system can distinguish between:
Why did this stage fail?
and:
What did we learn that should change what happens next?
That second question can shorten the route.
It can also make the route stronger.
If implementation discovers unexpected UI impact, I may want to add a UI/UX review that was not previously relevant.
If the design has gone stale, I may want to go all the way back to design and approval.
If a dependency was updated after a security finding, I may want security and affected validation again, but not product-intent review.
The goal is not “skip more stages.”
The goal is:
Run the stages that still add evidence.
Sometimes the correct route is no route at all
There is another case I run into more often than I expected: the issue should not continue at all!
- An issue can become stale.
- Another change may already have solved it.
- The original requirement may no longer fit the product.
- Or it may turn out to be outside the scope of what this workflow should do.
That is why IssueFlow has NOT_NEEDED as a first-class outcome in addition to PASSED and FAILED.
A NOT_NEEDED result can carry reasons such as:
- superseded
- obsolete
- already done
- out of scope
That matters because “failed” means the intended work still needs to happen but something stopped us.
“Not needed” means continuing the work may itself be the mistake.
Sending a superseded issue back through implementation is not recovery.
It is just a very sophisticated way to waste money.
This is mostly an efficiency problem for me
I am building all of this because the economics started bothering me.
The code itself can be produced very fast.
Then I watch the rest of the machine spend time validating, reviewing, retrying, waiting, rebuilding context, and occasionally asking me questions where my contribution is approximately zilch.
At one point my rough mental split felt close to 50/50: creative implementation effort on one side, validation/recovery/administration on the other.
That is not a benchmark. I am now measuring it properly.
But it was enough to make me ask whether the workflow was doing too much work simply because that was the path it had always taken.
And yes, there is a token bill attached to that.
Some days I look at the wasted retries and think I could probably buy another computer if I could just get back the money spent proving the first computer did not need to do anything.
Human attention is part of the routing problem too
I like building software.
I do not particularly enjoy babysitting a merge job because GitHub decided this was a good moment to have a bad day.
And, given the choice, I would rather spend that time with my wife.
That does not mean I want humans removed from the process.
Quite the opposite.
I want the developer involved when the developer has something valuable to add.
Bring me in when:
- the design no longer makes sense
- product intent is ambiguous
- a security trade-off needs judgment
- the UI behavior is questionable
- a risk decision needs an owner
- or the issue may no longer be worth doing.
Please leave me alone when:
- the runner needs a retry
- GitHub is rate limiting us
- a known recovery pattern has already been codified
- or the system already has enough evidence to choose the next safe step.
The ideal path is not zero human involvement.
It is human involvement exactly where judgment changes the outcome.
What I want to measure next
The dynamic-routing mechanism is shipped.
The efficiency improvement is still a hypothesis.
I want to measure whether it actually reduces:
- repeated stages after narrow rework;
- total agent tokens per accepted change;
- elapsed time from implementation to accepted result;
- retries by failure category;
- validation/administration share of total spend;
- and low-value developer interruptions.
And I need to watch the other side too.
If the workflow gets cheaper because I skipped useful evidence, that is not optimization.
That is just a cheaper bug.
The quality bar stays.
The question is whether the path to that quality bar can get smarter as the workflow learns.
The question I keep coming back to
AI has made code generation fast enough that the expensive part is easier to see.
It is not always writing the code.
It is deciding what to do with the evidence that arrives afterward.
Retry?
Rework?
Redesign?
Repeat validation?
Add a review?
Skip a review whose evidence is still valid?
Stop because the issue is no longer needed?
Or bring in a developer because this is finally the point where human judgment matters?
Now I have a new level of freedom and need to experiment and optimize, so the question i am asking myself is:
When one of the agent stages fails, which parts of the remaining path still add evidence?
Top comments (0)