Oh yeah, I've been using project tracker MCP for nearly hands-free planning-mode since NYE 2026.
And, it goes both ways. Code and back-and-forth prompting can write clarifying comments or update acceptance criteria with specificity. Likewise, agents can add comments for the handover log and, in the morning, pull comments for context.
I've even had the agents read/write sub-tickets, follow-on tickets, sub-tasks, etc. which can new reviewed and modified by myself and teammates in the larger planning context. It's a delight!
I'd say the headline is misleading. The message is in effect that (traditional, human-written) tickets are not prompts and things will go wrong if we treat them as such.
But because we will do so anyway, people should adapt and start to write their tickets like prompts.
It is very rare that I've come across a well-defined ticket. The most well-defined tickets were the ones I wrote myself, and even those had gaps because I wasn't typically the product owner.
It's the same story that it's always been, agents or not, that engineers need to be analysts and translate poorly defined criteria into something that's fit for purpose.
I agree. I think the poorly defined criteria that we have all gotten accustomed to is thanks to the many layers of the game of whispers that we've added in in organizations between the needs of the customer and the engineers.
Something I've been doing in my own organization, but also trying to help other organizations with, is getting engineers closer to the customers now that building and the time it takes to build is no longer the resource, which is scarce.
This has always worked like this. Let the person working on the ticket discover the implementation details, break it down into tasks, maybe delegate some after they’ve dipped their toes and know how to split it into sub-tasks better.
"Assign agents the biggest piece justifiable. I can summarize a product outcome or a feature in two lines. That’s what goes on the ticket. Let the agents figure out subtasks when the work is ready for review, not before. Once you break an initiative into technical issues upfront, the outcome gets lost and the focus shifts to minutiae."
This is not about the ticket being well defined, this is about the agent having the larger context of what you are trying to do
This resonates. We've been moving toward this with AI coding assistants, the ticket description IS the prompt. The better you write the ticket, the better the output. The missing piece is giving the AI agent enough context about your codebase conventions. Things like MCP servers that expose project-specific tools and rules help bridge that gap.
Oh yeah, I've been using project tracker MCP for nearly hands-free planning-mode since NYE 2026.
And, it goes both ways. Code and back-and-forth prompting can write clarifying comments or update acceptance criteria with specificity. Likewise, agents can add comments for the handover log and, in the morning, pull comments for context.
I've even had the agents read/write sub-tickets, follow-on tickets, sub-tasks, etc. which can new reviewed and modified by myself and teammates in the larger planning context. It's a delight!
I'd say the headline is misleading. The message is in effect that (traditional, human-written) tickets are not prompts and things will go wrong if we treat them as such.
But because we will do so anyway, people should adapt and start to write their tickets like prompts.
It is very rare that I've come across a well-defined ticket. The most well-defined tickets were the ones I wrote myself, and even those had gaps because I wasn't typically the product owner.
It's the same story that it's always been, agents or not, that engineers need to be analysts and translate poorly defined criteria into something that's fit for purpose.
I agree. I think the poorly defined criteria that we have all gotten accustomed to is thanks to the many layers of the game of whispers that we've added in in organizations between the needs of the customer and the engineers.
Something I've been doing in my own organization, but also trying to help other organizations with, is getting engineers closer to the customers now that building and the time it takes to build is no longer the resource, which is scarce.
> Assign agents the biggest piece justifiable
This has always worked like this. Let the person working on the ticket discover the implementation details, break it down into tasks, maybe delegate some after they’ve dipped their toes and know how to split it into sub-tasks better.
And of course, obligatory Shape up mention: https://basecamp.com/shapeup
the actual argument being made here:
"Assign agents the biggest piece justifiable. I can summarize a product outcome or a feature in two lines. That’s what goes on the ticket. Let the agents figure out subtasks when the work is ready for review, not before. Once you break an initiative into technical issues upfront, the outcome gets lost and the focus shifts to minutiae."
This is not about the ticket being well defined, this is about the agent having the larger context of what you are trying to do
This resonates. We've been moving toward this with AI coding assistants, the ticket description IS the prompt. The better you write the ticket, the better the output. The missing piece is giving the AI agent enough context about your codebase conventions. Things like MCP servers that expose project-specific tools and rules help bridge that gap.