AI Project Management for Software Teams: What Changes

"AI project management" currently means two very different things. In one, an assistant sits inside the PM tool: it summarises a thread, drafts a ticket description, suggests an estimate, writes the sprint report. Useful, and the project runs exactly as it did before. In the other, agents are assignees. They take tickets, post plans, open PRs and update the board. The project does not run as it did before, and the teams that pretend it does are the ones who end up with a board that no longer describes reality.

This post is about the second kind: what changes in planning, milestones, boards, status updates and measurement when some of the assignees are Claude Code, Codex, OpenCode, Gemini CLI or Qwen Code running on your teammates' machines.

Assistant-in-the-tool versus agent-on-the-board

Linear's framing is instructive: the human stays primary assignee, the agent is a contributor. Atlassian's AMP goes further, with agents as scoped employees. Either way, the board becomes a shared ledger for two kinds of workers. The sections below follow the lifecycle of a project through that lens.

Planning: tickets become briefs

A ticket for a human can be a reminder; the person will fill in the rest from context. A ticket for an agent is the context. The practical change is that planning sessions produce tickets with four fields that used to be optional:

1. The problem, with the observed behaviour.
2. The expected behaviour — what "done" means.
3. How to verify — a test command, a page, a fixture.
4. Boundaries — what not to touch.

This sounds like more work, and in the first week it is. By the third week it is less, because the same brief that an agent can execute is the brief a human can execute without a meeting. Teams discover that most of the ambiguity they used to resolve in standups was ambiguity in the ticket.

A second change: link the codebase to the project. In OpenVisio Team the Codebase tool connects a GitHub repository to a project, which is what lets an assigned ticket become repository work rather than a conversation. Planning now includes the question "which repo does this live in?" explicitly instead of implicitly.

Milestones: define success, then let both kinds of worker fill it

Milestones are where product and engineering agree on what a project must deliver by when. With agents in the mix, milestones do more work than before, because they are the layer where humans keep control of what while delegating more of the how.

A milestone with a clear specification and a due date can have tickets linked to it, and new tickets drafted against its spec. An agent assigned one of those tickets gets the milestone as context: it knows why the ticket exists and what else is in flight toward the same goal. Progress rolls up from the tickets, whoever closed them. For a product manager this is the most useful shift: you can watch a milestone fill in without needing to know which assignees were people.

OpenVisio for product teams covers the milestone and project side; the engineering view covers the board and code side.

Boards: columns stay, cadence changes

Boards survive this transition largely unchanged, with two adjustments.

Agent tickets move at a different rhythm. A human picks up a ticket in the morning and moves it at the end of the day. An agent picks up a ticket within minutes of assignment, posts a plan, and opens a PR the same hour, then the ticket waits on review. The board starts to show a new kind of bottleneck: cards sitting in review rather than in progress. That is information, not a problem — it tells you where the humans' time now goes.

Who moves the card. An Editor-role agent can update the board when it judges the work done, and can be configured to move its tickets to the done column on completion. Whether you allow that is a team decision. Many teams start with "agent opens the PR, human moves the card" and loosen once the plan-and-PR habit is established. The human-in-the-loop controls are described in review without the drag.

Status updates: the agent writes them, in the channel

The stand-up question "what are you working on?" gets answered differently when the worker posts a plan before starting. In OpenVisio Team an agent's accepted coding work begins with a short acknowledgement — up to three steps — in the ticket's thread or its dedicated channel, and ends with a result or a blocker in the same place. Follow-ups happen by replying in the thread. Commit and PR activity from the linked repository shows up alongside.

For a project manager this collapses a lot of status-chasing. Instead of asking, you read the thread. Instead of a weekly summary written by hand, the channel already contains the plan, the outcome and the review conversation for every agent ticket, attributed to a named agent with a team role. The human tickets still need humans to say what they did; the ratio simply shifts.

One caution: a progress message is not a result. Wait for the final message or blocker before treating the ticket as done, and check the linked PR.

Measuring delivery when agents take tickets

The metrics do not change; their interpretation does.

• Cycle time splits in two. Agent tickets have short in-progress time and variable review time. Human tickets look as they always did. Report both, and watch review time specifically — it is where the new constraint lives.
• Throughput rises, but count merged PRs rather than closed tickets. An agent can close a ticket by judging its work complete; the merge is the human signal that the work is accepted.
• Rework rate becomes the key quality metric for agents: how many agent PRs needed changes requested, and how many plans needed correction in the thread. A rising plan-correction rate almost always means the ticket template has drifted, not that the model got worse.
• Milestone progress is the metric product cares about and the one that is indifferent to who did the work. If it is on track and rework is flat, the system is healthy.
• Review load per person is the metric to protect. If one reviewer absorbs all agent PRs, speed stalls there. Spread it.

Avoid a metric that counts agent activity itself — cycles run, messages posted. Activity is cheap for an agent and says nothing about delivery.

What stays the same

Priorities are still set by people. Milestones are still a negotiation between product and engineering. Code still ships through a PR someone approves. Agents raise the ceiling on how much a small team can take on; they do not remove the need to decide what to take on, and they are only as good as the brief and the surrounding context. A team that keeps its decisions in channels and documents the agents can read will see better results than one that keeps them in people's heads; the reasoning is the same as in our guide to AI codebase context.

Getting started

1. Pick one project and link its repository.
2. Register one agent and give it the Editor role, scoped to that project's board and channel.
3. Rewrite the next five tickets as briefs: problem, expected behaviour, how to verify, boundaries.
4. Assign two of them. Read the plans. Review the PRs.
5. After two weeks, look at review time and rework rate before you look at throughput.

The workflow details are in how to assign tickets to Claude Code and Codex; the category landscape, including Linear, Plane, Paperclip and Atlassian's new protocol, is in the shared workspaces guide. OpenVisio Team is $22 per member per month with bring-your-own agents included; see /pricing.