A Project Management Playbook for AI Teams

A team where "done" doesn't mean what it means elsewhere

Picture a small AI-focused engineering team, five to eight people, building model-backed features inside a larger product: a summarization capability, an agent that automates a workflow, an internal eval pipeline that checks quality before anything ships. Some of this work looks like normal engineering, write code, open a pull request, merge it. Some of it doesn't: a prompt gets iterated a dozen times, an eval run either passes a quality bar or it doesn't, a fine-tuning experiment might just not work out at all.

A generic engineering board assumes "in progress" eventually becomes "done" in a fairly linear way. AI work doesn't always cooperate with that assumption. A card can sit in progress for two weeks not because anyone's stuck, but because the work is genuinely exploratory, and forcing it into the same tracking shape as a straightforward bug fix makes the board actively misleading about where the team's time is going.

This is a familiar bind for teams doing applied AI work: the tooling wants a clean pipeline, and a meaningful share of the actual work is closer to research.

Before: exploration and shipping blur together

The first problem is that "merged" doesn't mean the same thing for a model change that it does for a typical feature. Code can merge behind a flag while the actual model behavior is still being evaluated, which means a card marked "done" by the usual definition might represent work that's nowhere near ready for real users. Without a way to distinguish "code merged" from "eval passed" from "actually shipped to users," status conversations get vague fast.

The second problem is that this team is, more than most, a heavy user of AI coding tools themselves, and switching context between the chat tool they're using to write code and the board that tracks the work is real friction, done dozens of times a day. Every time updating a task means leaving the tool they're actually working in, some of those updates just don't happen.

The third problem is that evaluation results, why a particular prompt version was chosen, what an eval run actually revealed, tend to live in a notebook or a Slack message and get lost when the person who ran it moves on to the next experiment.

After: exploratory work is visible without being forced into the wrong shape

The realistic change here is that the team stops pretending exploratory work is linear just to fit the tool. A card sitting in "experimenting" for two weeks is honestly represented as exploratory, not misleadingly flagged as a stalled feature. When something does move to shipping, that transition, backed by a real merge, is a meaningful signal rather than a status someone flipped optimistically.

The friction of updating the board from inside a chat-based coding tool mostly goes away, because the MCP connection means the update can happen in the same place the work is actually happening. And when the next person picks up a related experiment months later, the eval results and the reasoning behind past decisions are on a wiki page they can actually find, instead of buried in someone's notebook history.