AI writes the code fast. The expensive question is what happens after something fails

AI coding agents can implement a change ridiculously fast.

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.

Take merge. Thee are millions (almost) reason it can fail:

IssueFlow already had a failure-reason vocabulary before this week. That lets me say things like:

That part is useful, but it is not the change I am excited about.

The harder question comes after recovery.

Suppose a merge conflict sends the issue to implementation for conflict resolution.

Do I send it through validation again? Security review? Code review? UI/UX review? Every single stage?

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.

When an issue enters IssueFlow, the workflow can route based on things like complexity, issue type, environment, priority, role, and other dimensions.

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...

Those facts do not exist when the issue first enters the workflow. But the agent that just handled that stage - knows!

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.

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:

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.

There is another case I run into more often than I expected: the issue should not continue at all!

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:

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.

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.

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.

I want the developer involved when the developer has something valuable to add.

The ideal path is not zero human involvement.

It is human involvement exactly where judgment changes the outcome.

The dynamic-routing mechanism is shipped. The efficiency improvement is still a hypothesis.

I want to measure whether it actually reduces:

If the workflow gets cheaper because I skipped useful evidence, that is not optimization.

The question is whether the path to that quality bar can get smarter as the workflow learns.

AI has made code generation fast enough that the expensive part is easier to see.

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?