Everyone is chasing the same thing right now.
Cheaper output. Faster output. Better output.
All from agents that write code, review code, ship code.
But here’s what nobody talks about.
The agent was never the bottleneck. The ticket was.
Give an agent a vague issue and it will do exactly what vague issues invite. It will assume. It will guess at intent and run with the guess.
You’ll only find out later. After the pull request. After the back and forth. After you’ve spent more time correcting the agent than you would have spent writing the issue properly in the first place.
This isn’t a new problem. It’s an old problem wearing a new coat.
Bad Tickets Were Always Expensive
Ask any engineering manager from ten years ago. A vague bug report cost hours. A clear one cost minutes.
The difference was never the developer’s skill. It was the clarity of what they were handed.
Now the recipient of that ticket is an agent. The cost of ambiguity didn’t go away. It just moved faster and multiplied.
An underspecified issue used to cost you one confused conversation with a teammate. Today it can cost you three or four wasted agent runs before anyone notices the drift.
What Open Source Already Figured Out
This is where I keep going back to WordPress and Drupal.
Two of the oldest, most battle tested open source projects on the internet. Both have spent nearly two decades refining one unglamorous thing.
Their issue templates.
Look at how WordPress core handles a bug report. Steps to reproduce. Expected behavior. Actual behavior. Environment details. Screenshots where relevant.
Nothing exotic. Just discipline, repeated thousands of times, until it became culture.
Drupal’s issue queue works the same way. A community of volunteers, often people who’ve never met, somehow ship a working CMS together.
Not because everyone is brilliant. Because the format of the issue does the thinking for them.
The template asks the questions before anyone has to ask. That’s the whole trick.
Why This Matters More Now, Not Less
You’d think AI would make specificity less important. The opposite is true.
A human teammate can tap you on the shoulder and ask what you meant. An agent rarely does.
It fills the gap with its best guess and moves forward with confidence. Confidence is not the same as correctness.
So the cost of a bad issue used to be a slow human. Now it’s a fast, confident, wrong agent.
That’s a worse outcome, arriving quicker.
What Leaders Should Actually Do
You don’t need a new tool for this. Jira, Linear, GitHub Issues, Notion, doesn’t matter.
What matters is the shape of what goes into it.
Steal from the open source playbook. Write down what “done” looks like before anyone opens an editor. State the constraint, not just the request. Separate what you know from what you’re assuming.
Then go one step further. Feed your agents the same issue templates that WordPress and Drupal have refined for years. Let your agents learn the pattern of a well written bug report the way a new open source contributor learns it, by seeing hundreds of good examples before writing their first one.
The Real Leverage
Everyone is optimizing the model. The prompt. The framework. The stack.
Meanwhile the actual leverage point sits somewhere boring.
A well written issue. A well written PRD.
Not exciting. Not something you’ll see trending on a timeline.
But it’s the difference between an agent that ships what you meant and an agent that ships what it assumed you meant.
Write the issue right the first time. Everything downstream gets cheaper.
Leave a Reply