Who answers for the ticket?

For ten weeks in 2025, an AI agent could own a ticket in Linear.

Linear is the issue tracker a lot of software teams live in, and in May 2025 it gave agents a seat on the team. An agent got a profile, like a person. You could add it to a team, @-mention it in a comment and, the big one, put it in the assignee field. Devin would scope the issue and draft a pull request. ChatPRD would write the requirements.

Then Linear took the assignee field back. In a post on 1 August, Leela Senthil Nathan explained what the team had seen in the meantime. Agents were holding dozens of assigned issues with “no clear sense of who was behind them.” And when somebody disagreed with an agent’s work, nobody could tell whom to talk to.

The fix fit in one sentence: “issues can only be assigned to humans, and only delegated to agents.” So every issue an agent works on now carries two names. The agent does it. A person answers for it.

Project management has been answering “whom do I talk to?” since before it had a name. In 1917, with the United States newly at war, the Army’s Chief of Ordnance, General William Crozier, hired Henry Gantt as a production consultant. War orders had “jumped from hundreds to millions,” and typewritten tables couldn’t show anyone how far along they were.

So Gantt drew a chart. It set each order’s progress against what had been promised, day by day. Wallace Clark, who wrote the first book about it in 1922, says Crozier saw at once that it could help “to fix responsibility for action or lack of action.”

That’s still what the assignee field is for. One name, so you know whom to talk to.

Project managers do have a word for the split, to be fair. A RACI chart separates the person Responsible for a task from the one Accountable for it. But the trackers most of us live in kept a single assignee field, because on most tickets the person doing the work was also the one who answered for it.

On a growing share of tickets, that’s no longer true. In August, Linear said agents create half the work in its workspaces, up from 3% a year earlier. (Its own figure, counting work created, not issues.) On 28 October, GitHub’s Octoverse report said more than 40% of the pull requests opened on GitHub in September started from an agent’s first draft. In March it was 17%.

So what is a project manager for, when the doing gets cheap and the answering doesn’t? I think the history of the job answers that better than the forecasts do.

Gantt’s own charts were production records, filled in at the end of each day with what was promised and what got done. (The bars-and-arrows schedule that carries his name came later.) In shipbuilding, by one early account, the unit of progress was rivets driven. The chart’s first reader was the general.

Forty years later the same thing happened with more ink. In 1958 the US Navy’s Special Projects Office was building the Polaris submarine missile with about 250 prime contractors and more than 9,000 subcontractors. It introduced PERT, a network of tasks with three time estimates each. Polaris reached sea years ahead of schedule, and PERT got the credit.

The political scientist Harvey Sapolsky wasn’t so sure. In his 1972 history of the program, as MIT’s summary puts it, PERT was as much “a device to protect the program from external interference” as a way to run it. A 2012 study by Jonas Söderlund and two colleagues found it never played the role in Polaris that it’s usually credited with.

My reading is that PERT’s real audience was Congress and the rival services, who saw a well-managed program and left it alone. Being seen to manage mattered. To the people paying, it sometimes mattered more than the managing.

The same years brought the first part of the job a machine took over. Du Pont and Remington Rand worked out the critical path method on a UNIVAC in 1957, because planners were up against “the inability of unaided human beings to cope with sheer complexity,” as its inventors wrote in 1959.

So the job had three parts. Computing the schedule went to machines in the 1950s. Making the work visible to people who couldn’t see it, the job of every status report since Gantt, is going now.

In 2019 Gartner predicted that by 2030 AI would eliminate “80 percent of the work of today’s project management (PM) discipline,” and the press release names the work: data collection, tracking and reporting. People quote it as 80% of project managers losing their jobs. It never said that. And the tools are doing the reporting. Asana’s AI Teammates already summarise sprints and condense project data for leadership.

The third part is deciding, and answering for what got decided. It’s the part of Linear’s story that waited for a person. Once a status report costs nothing to produce, I think it’s also the part a sponsor is REALLY paying for.

The lines all run to one person

I did Fred Brooks’s arithmetic in an earlier essay: n people have n(n−1)/2 possible conversations, which is why adding people to a late project makes it later. Agents bend that arithmetic. They don’t need time to get up to speed, and they don’t talk to each other unless someone builds them to. So the lines don’t multiply between them. They all run to you, or to whoever answers.

The clearest evidence I’ve seen is a study presented this year at MSR, the main conference on mining software repositories. Researchers at Drexel University and Missouri S&T took 600 pull requests that coding agents had opened on popular open-source projects and that never got merged, and worked out why.

The biggest group, 38%, was abandoned. No human ever engaged with it in a meaningful way. Another 142, nearly a quarter, duplicated another pull request. Wrong code, the thing everyone worries about, accounted for 19, about 3%.

Abandoned: no human engaged228 · 38%
Duplicate of another PR142 · 24%
CI or test failure99 · 17%
Incomplete or non-functional28 · 5%
Unwanted feature24 · 4%
Incorrect implementation19 · 3%
Wrong task, branch, instructions or licence22 · 4%
Deleted or archived before analysisnot classified38 · 6%

Out of 600 rejected pull requests opened by coding agents. Shares are of all 600.

Ehsani and colleagues, “Where Do AI Coding Agents Fail?”, MSR 2026: agents such as Codex, Copilot, Devin, Cursor and Claude Code, on repositories with 100 or more stars.

I’d expect people to see some of that abandonment too, since maintainers have always ignored drive-by pull requests. Still, most of the agents’ work died because nobody had time to look at it, or because the same job got done twice.

Companies see it as waiting. LinearB, which sells engineering analytics, found that AI-generated pull requests in its customers’ data wait 4.6 times longer before anyone picks them up. DX found first reviews take 105% longer at companies writing lots of AI code.

In September, Asana asked 4,502 people in the US and UK how they work with agents. Among those using two or more, 46% said coordinating them takes more than a tenth of their working time, and over a third thought more than a quarter of their agents’ work is duplicated or overlapping. Asana sells coordination software, so I read that as a direction rather than a measurement.

Factories worked this out seventy years ago. Toyota’s kanban cards cap the work in progress, and John Little proved in 1961 why a cap works: the average time an item spends in a system equals the work in progress divided by the throughput. If the last station can only finish so much, piling more in front of it just makes everything wait longer.

In 2004 David Anderson tried that on a Microsoft maintenance team in Hyderabad. It had the worst service record in the company, and requests took five months or more. The first thing the team stopped doing was estimating. Then it limited the work in progress. Lead times fell to 12 days, according to a case study from the training company Anderson later founded.

The station that can only finish so much is now you, or whoever answers for the work. That’s where the limit goes. (Who teaches the reviewer? is about what that review is for.) The project-management version is simple. Count how many things one person can check this week, and stop handing out more than that.

Nobody can estimate this

Estimates were never great. Anthropic took about 1,000 tickets from open-source JIRA projects that had both a developer’s estimate and the time the work actually took, and the two correlated at 0.50. That’s people estimating their own work, with no AI anywhere. A correlation like that is fine for telling a big job from a small one. It’s not much use for filling a sprint.

Agents make it harder. I’ve written about METR’s trial before, the one where developers believed AI had made them 20% faster when it had made them 19% slower. The follow-up says more about planning. When METR tried again in late 2025, the experiment broke. Developers wouldn’t work without AI, 30% to 50% held back tasks they didn’t want to do the old way, and people running several agents at once couldn’t say how long anything had taken.

If a lab with screen recordings couldn’t time agent-assisted work, I wouldn’t trust a sprint planning meeting’s guesses about it either.

The people who invented the rituals have been saying so for years. In 2019 Ron Jeffries wrote, “I may have invented story points, and if I did, I’m sorry now.” (Only “a little sorry,” he added.) His advice was to pick a date and fill it with the most valuable work.

Basecamp’s Shape Up, from the same year, has the line I’d frame: “Estimates start with a design and end with a number.” Shape Up turns that around. You start from an appetite, a fixed amount of time you’re willing to spend, and let the scope move.

I think appetite is the planning unit that survives agents, with one change. What you’re budgeting now is the attention of the person who answers, plus the token bill.

Write the intent, not the steps

If that attention is the budget, the brief decides how much of it each piece of work will eat. And the best guide I know to briefing something that will act without you is 19th-century Prussian staff doctrine.

Helmuth von Moltke ran the Prussian army in wars where his armies marched days apart and the situation changed faster than orders could travel. In his 1869 instructions for senior commanders, he advised ordering no more than was absolutely necessary. Orders should get shorter and more general the higher up they come from, because the officer on the spot sees the change first.

The US Army still teaches it as commander’s intent. You state the purpose and the end state clearly enough that people can act without further orders once the plan stops matching what’s happening.

Anthropic learned a version of this in 2025. The lead agent in its multi-agent research system at first handed out one-line tasks, like researching the semiconductor shortage. One subagent covered the 2021 car-chip crisis, while two others duplicated each other on 2025 supply chains. The fix was a brief in four parts: an objective, an output format, guidance on tools and sources, and clear boundaries.

A day earlier, Cognition had published “Don’t Build Multi-Agents,” with a Flappy Bird clone split between two subagents. One built a Super Mario background. The other built a bird that neither looked nor moved like Flappy Bird’s.

The research on why multi-agent systems fail lists the same problems. In MAST, a Berkeley-led taxonomy, the biggest group of failures, roughly 44%, is design and specification: agents disobeying the task spec, repeating steps, not knowing when to stop.

The obvious fix is to write everything down, which is what spec-driven tools like GitHub’s Spec Kit and AWS’s Kiro do. The critics have already found the cost. When Birgitta Böckeler of Thoughtworks tried Kiro on one small bug, it produced 4 user stories with 16 acceptance criteria. François Zaninotto watched Spec Kit write 8 files and about 1,300 lines of text for a feature that shows the current date. The date! He called his post “The Waterfall Strikes Back.”

What worked, as far as I can tell, sits between the one-liner and the 1,300 lines. Anthropic’s four parts fit on a page, and so did Moltke’s orders. Both said what the work was for and where its edges were, and left the steps to whoever did it.

The catch is trust. Mission command assumes officers who trained together for years and understand the intent two levels down. Nobody has shown that agents do. So the person who answers still has to check what comes back, and the work lands in their queue again.

And you can’t get around that by putting an agent in the manager’s seat. In March, Cognition shipped Devins that manage other Devins. A month later it wrote that these managers tend to be overly prescriptive and to assume the agents under them know things they don’t. (So, like a lot of human managers.)

Anthropic’s Project Vend gave its AI shopkeeper an AI boss, Seymour Cash. He cut the discounts, but approved customers’ requests for refunds and store credit about eight times as often as he refused them. Anthropic’s conclusion was that a manager running on the same model as the worker shares the worker’s blind spots.

What a team looks like now

Teams were changing before anyone handed tickets to agents. In January 2023, Capital One eliminated about 1,100 roles in its “agile” job family and gave the work to engineers and product managers.

Management layers have been thinning since. Gallup found the average manager’s team grew from 10.9 people in 2024 to 12.1 in 2025, though the median is still about six.

I don’t think the deciding is going away, though. At AI Fund, one of Andrew Ng’s teams proposed a headcount plan with one product manager for every half an engineer. Silicon Valley’s old rule was about one to four. Ng told a Y Combinator audience in June 2025 that it was the first time in his life managers had asked him for “twice as many PMs as engineers,” and that he didn’t know whether it was a good idea. He meant product managers, not project managers, but it’s the same half of the job: deciding, and answering for the decision.

A field experiment at Procter & Gamble with 776 professionals found that one person working with AI matched a two-person team without it. And the job market hasn’t collapsed. Indeed’s index of US project-management postings stood at 117.8 on 23 October (February 2020 = 100). Software development stood at 80.8. The Bureau of Labor Statistics projects 7% growth for project management specialists through 2035.

The profession’s own body is betting on the answering half. At its summit in Detroit on 22 October, PMI launched a course on agentic AI for project professionals. It ends with each learner holding a working agent and “a one-page Stakeholder Brief” for handing it over. That’s a memo that explains an agent to the people who’ll answer for it.

The tools disagree about who answers, so check which way yours lean. Linear’s guidelines say an agent can’t be held accountable. Microsoft’s Planner Agent “will never mark a task as complete”: a person reviews its work and closes the task. Atlassian goes the other way and describes agents in Jira as accountable members of the team.

Gantt chart, US Army Ordnance1917
Does the workThe shop or contractor on the line
Answers for itThe same name: the chart was there to fix responsibility
Linearsince Aug 2025
Does the workThe agent, as a delegate
Answers for itThe human assignee. Its guidelines say an agent can’t be held accountable
Microsoft Planner Agent2026
Does the workThe agent, from its own bucket
Answers for itYou. The agent never marks a task complete
GitHub Copilot cloud agentsince 2025
Does the workThe agent, on a branch it created
Answers for itA reviewer. The requester’s own approval doesn’t count
Agents in JiraGA May 2026
Does the workThe agent, as an assignee
Answers for itThe agent, called an accountable team member; admins define done
monday.comMar 2026
Does the workThe agent, with its own account
Answers for itNot set by the product: an agent can open its own account, at a person’s price

a named person answers

Each tool’s rule as its documentation stated it in October 2026. The 1917 row is from Wallace Clark’s 1922 book.

The law, for now, sides with Linear. The EU AI Act requires anyone deploying a high-risk system to give its oversight to “natural persons who have the necessary competence, training and authority,” from December 2027 after this year’s delay. Workers are less sure. In an Asana survey last year, 39% said that when an agent makes a mistake, nobody is responsible, or they don’t know who is.

Five bets, and what would prove me wrong

A theory that only explains the past is cheap. So here are five predictions, how sure I am of each, and what would change my mind.

1. Every tracker splits the owner from the doer, and “done” stays a human click. Linear, Microsoft and GitHub already work this way.

How sure: it’s happening. What would prove me wrong: by 2028, the big trackers letting agents close their own work by default, with no named person on it.

2. Work-in-progress limits move to the person who answers. You’ll plan capacity in review hours instead of developer hours, because review is where LinearB and DX found the waiting.

How sure: fairly sure of the direction. What would prove me wrong: review waits falling while agent output keeps rising and nobody limits it. AI reviewers soaking up the load would count, and Tessl’s claim that 75% of its pull requests merge without a human correcting them is the case I’m watching.

3. Story points die, and appetite replaces them. Teams plan with a fixed budget of human attention and measured cycle times.

How sure: a hunch, in good company. What would prove me wrong: a study showing teams estimating agent-assisted work better than the 0.50 developers managed without AI, and planning with it.

4. The brief becomes the project manager’s main document: longer than a ticket title, much shorter than a spec. It states the intent, the limits and what done looks like, and leaves the steps to whoever does the work.

How sure: early signs. What would prove me wrong: heavy spec-as-source tools winning in ordinary teams by 2028.

5. Fewer coordinators, more people who answer. Roles that only coordinate keep folding into the people who build, while the roles that decide and answer hold steady or grow.

How sure: mixed. No job series separates coordinators from the people who decide, which is part of why I rate this low. The closest test I have is Indeed’s project-management index falling to software development’s level, around 80, by the end of 2027.

1Every tracker splits the owner from the doer
It’s happening (3 of 4 for evidence today)
Linear: issues are assigned to humans and delegated to agents. Microsoft’s Planner Agent never marks a task complete.
Would prove me wrong: By 2028, the big trackers let agents close their own work by default, with no named person on it.
2Work-in-progress limits move to the person who answers
Fairly sure of the direction (3 of 4 for evidence today)
AI-generated pull requests wait 4.6 times longer for review (LinearB). 38% of rejected agent PRs had no human engage at all.
Would prove me wrong: Review waits fall while agent output keeps rising and nobody limits it.
3Story points die, and appetite replaces them
A hunch, in good company (1 of 4 for evidence today)
Developers’ own estimates correlated with actual times at 0.50, before any AI. METR couldn’t time agent-assisted work.
Would prove me wrong: A study shows teams estimating agent-assisted work better than 0.50, and planning with it.
4The brief becomes the main document: a page, not a spec
Early signs (2 of 4 for evidence today)
Anthropic’s four-part brief; specification is the biggest failure group in MAST; Spec Kit wrote about 1,300 lines for a date feature.
Would prove me wrong: Heavy spec-as-source tools win in ordinary teams by 2028.
5Fewer coordinators, more people who answer
Mixed (2 of 4 for evidence today)
Capital One cut 1,100 agile roles in 2023. US project-management postings stand at 117.8, software at 80.8 (Feb 2020 = 100).
Would prove me wrong: Closest test: Indeed’s project-management index falls to software development’s level, around 80, by the end of 2027. No series separates coordinators from deciders.

Dots: how much evidence there is today, out of four.

The five bets. The sources are in the text above.

Write down who answers

The practical part fits on any board you already use. Add two columns:

Answers for it: ___ (a person, by name)
Can check this week: ___ (a number of items)

The first column is Linear’s rule, for whatever tracker you have. If the cell is empty, or it holds an agent’s name, that item has nobody to talk to. The second is your work-in-progress limit, and the person who answers sets it from what they can check in a week. When an item has no name in the first column, or the second column fills up, stop handing out work.

If that looks like RACI’s A with a kanban limit bolted on, it is. The difference is that agents make the A mandatory on every ticket, and one person’s week sets the limit.

A century after Crozier, that’s still most of the job: fixing responsibility for action or lack of action.

Try the two columns on this week’s board, and tell me in the comments which one was harder to fill.

Written by Hatim Rih

A thought to add?

A good question, another perspective, or something this made you think about. There’s room for it here.

Loading the conversation…