From individual coding agents to governing the entire software-development process.
It wasn't that long ago that we were impressed when AI could complete a few lines of code.
Now coding agents can do a hell of a lot more.
They can investigate issues, propose designs, implement changes, write tests, review code, and prepare pull requests.
We can run multiple agents, use subagents and skills, connect tools through MCP, and automate tasks that used to require constant interaction.
That's pretty awesome!
But is this where the story ends?
I don't think so.
In fact, after nearly six months of building an orchestration system for my own development work, I think we're entering another stage in the evolution of AI-assisted software development.
And surprisingly, the next big challenge isn't necessarily writing better code.
It's managing everything that happens around it.
The problem with having several capable agents
I started using AI coding agents on real software projects, and I tried anything that was available at the time: Cursor, Windsurf, Claude Code, Kiro, Codex, JetBrains, Copilot, you name it. Now I work mostly with Claude Code.
Eventually, the agents became capable of doing much more of the implementation work, but I was still coordinating the process, attached to the chat all day long.
Which agent is working on which GitHub issue?
Which issues depend on another issue being completed first?
Can two agents work concurrently, or are they going to collide over the same resources?
Did the code review fail because the implementation was wrong, or did CI fail because of an infrastructure problem?
Does the design need another round? Is the PR ready to merge? What happens after deployment?
And... where do I actually need to make a decision?
I was becoming the glue holding everything together.
So I figured I'd automate that coordination.
I thought a week or two should probably do it.
Yeah right :)
Nearly six months later, I'm still refining what became IssueFlow.
The interesting part wasn't just connecting coding agents to GitHub.
The difficult part was managing a development process that doesn't always follow the same path.
A development workflow isn't a straight line
Consider a relatively ordinary development issue.
It might need requirements analysis, design, design review, approval, implementation, code review, testing, merging and deployment.
Sounds straightforward, doesn't it?
Until something doesn't go according to plan.
For example:
A design review may find a problem and send the work back for revision, or rely on code that was not comitted yet.
A test failure may require implementation rework, and sometimes redesign.
A CI infrastructure failure should not necessarily send the coding agent back to rewrite perfectly good code. Sometimes GitHub was down, or I simply ran out of budget.
An issue may depend on another issue, perhaps in a completely different repository.
Two issues may be ready to run but require exclusive access to the same resource.
And some decisions genuinely belong to a person.
For example, I don't want an agent independently deciding to change an important domain model, redesign a critical user experience, or choose a new architectural pattern without involving me. Or worse - get a $2,000 bill increase from AWS.
I use DDD and CQRS, and some of those choices have consequences well beyond the immediate GitHub issue.
But at the same time, the goal isn't to interrupt me constantly.
It's to involve me where judgment matters, with the context I need, while letting the mechanical work continue without me.
What this looks like in practice
The following is a real workflow from my IssueFlow development environment.
The full workflow is admittedly complicated, and it was not created i one day either.
That's part of the point.
Software development is complicated. Coding agents help with individual activities, but the process connecting those activities still needs to be managed.
Here's a smaller section of that same workflow.
Notice the distinction between design review and design approval.
Design review examines the proposed approach.
If it finds a problem, the workflow can route the work through design rework rather than blindly continuing.
Then there's the human gate.
I get to decide whether the design meets my expectations before implementation proceeds.
I don't need to be attached to the agent's chat while it performs the other steps.
And this is just one part of the workflow.
From coding-agent orchestration to a development control plane
This led me to think about AI development in a whole different angle.
We started with AI assisting developers in writing code.
Then we moved toward agents that could complete tasks.
Now we have multiple agents working concurrently, with increasingly sophisticated tools, skills and automation.
I think the next layer is about managing the entire AI-powered development process, across agents, repositories, issues, machines and people.
This isn't just about running agents in parallel.
A development control plane needs to manage several things together.
Dependencies and concurrency
An epic may contain issues spanning multiple repositories. Some can run independently. Others must wait for prerequisites. And concurrency isn't only about how many agents are available. It's also about whether the work can safely happen at the same time, avoiding unnecessary merge conflicts.
In IssueFlow, dependencies and concurrency rules are explicit parts of the coordination model, including mechanisms for controlling access to shared resources.
Dynamic routing based on what actually happened
Not every issue requires the same stages.
Issue type, complexity and the evidence discovered during execution can affect what happens next.
A successful stage might advance the workflow.
A failed review might trigger rework.
An infrastructure problem might require recovery rather than another implementation attempt.
A situation that automation can't safely resolve can be escalated to a person.
The point is to make those decisions part of the managed process, instead of expecting the developer to notice and coordinate every transition.
Agents and processes working together
Not everything in a development pipeline needs another LLM call.
Some steps require reasoning or judgment. Others are deterministic operations.
A workflow should be able to combine both.
IssueFlow supports AI-agent frameworks alongside process executors. In my current environment, Claude Code handles agentic work, while other executors handle operations such as source-control merging and workflow utilities.
The development process decides what should happen. The appropriate executor performs the work.
Human gates where they matter
I don't believe the objective should be removing humans from software development.
I want to remove the mechanical coordination work while preserving the decisions that affect product intent, architecture, quality and user experience.
And the right human gates aren't always the same for every issue.
A small documentation change and a major domain-model redesign should not necessarily follow identical approval paths.
That's why I want the workflow to make human involvement explicit and configurable.
Visibility, measurement and learning
There's another part of the problem that becomes important when agents are doing more of the work.
How do we know whether the development process is actually improving?
IssueFlow provides visibility into execution, waiting time, failures, throughput and token consumption.
That helps me investigate bottlenecks and adjust the workflow based on evidence.
If an agent spends unnecessary time repeating a step, I want to know.
If a stage sits waiting, I want to understand why.
If I change the routing or configuration, I want to be able to evaluate whether the result improved.
IssueFlow also supports a learning process where agents can propose lessons from their work, while I retain control over which lessons become ongoing rules.
I don't want every mistake to become another permanent prompt instruction nobody reviews.
Keep your agents. Add management around them.
One of my important design goals was not to disrupt the development environment I already had.
I didn't want to replace GitHub, change my IDE, rewrite my prompts, or introduce a new coding-agent subscription.
IssueFlow adds an orchestration and control layer on top.
I can continue using my existing tools and workflows.
I also don't have to be sitting in front of the workstation running the agents.
I regularly access the IssueFlow portal through a browser to monitor progress and intervene when needed.
And because IssueFlow supports MCP, my existing coding agent can help inspect, dispatch and manage workflow operations through its authorized tools.
In other words, the coding agent can also become an interface to the development control plane.
Is this where agentic software development is heading?
I think so.
And one of the reasons is that coding-agent platforms themselves are investing in more automation, coordination and centralized management.
To me, that supports the direction of the evolution.
I'm not arguing that those platforms cannot orchestrate work. They can, and they're improving quickly.
Nor am I claiming that IssueFlow is the only possible solution.
What I'm suggesting is that managing the development process is becoming a problem in its own right, rather than just another feature of an individual coding session.
And that's the problem I've focused on with IssueFlow.
I've used it to develop IssueFlow itself and Aligned On Purpose, a five-repository leadership alignment platform with augmented AI.
It works for my development process, and I use it every day.
But there's still a question I can't answer based only on my own experience:
How well will this approach work for other developers, with different projects, coding agents and ways of working?
That's what I'm trying to find out now.
If you're building real software with AI coding agents, I'd genuinely like to hear how you manage your development process today.
What happens after an agent finishes its task?
How do you manage dependencies, code reviews, failed checks, deployment and human decisions?
And how much of that coordination still depends on you?
I'm also looking for developers willing to test IssueFlow on their real workflows. I'll personally help with onboarding and would value candid feedback about what works and what needs improving.
You can learn more at https://www.issueflow.cloud.
Or just tell me how you're solving the problem. I'm interested in both.
This article expands on my original Substack post, AI Agents Can Write, Test and Review Code. Now What?.
Top comments (1)
Your distinction between a failed review and a CI infrastructure failure is exactly why I write my assumptions down before a run now — literally an 'Assumptions:' line at the top of the brief. If the run goes sideways, the first thing I check is which assumption was wrong. Most debugging time used to go to assumptions nobody had ever said out loud.