I’ve been noticing this for a few months now.
Jira, at least the way we use it today, often feels like it slows things down more than it helps. Not because it’s a bad tool, but because it’s optimised for a way of working that may no longer match how execution actually happens.
In larger organisations, Jira serves clear purposes: visibility, alignment, accountability, and coordination. Those are real constraints. But that doesn’t automatically mean, given how things have evolved, that it’s still the right default approach.
What We’re Doing#
A lot of time, alongside building the product, is spent preparing to build.
Writing tickets, structuring them, adding context, defining acceptance criteria, linking to epics, moving things across states none of this ships value. It makes work visible, but it also introduces overhead.
More importantly, it introduces a cognitive shift. You move from solving the problem to explaining it in a structured way for others. That context switch is expensive, and when repeated often, it takes a noticeable toll.
Why This Worked Until Now#
Execution used to be expensive. You couldn’t try things quickly, so you had to think, document, and align upfront.
Jira fits that world well. It reduces ambiguity before execution starts and helps avoid costly mistakes.
What’s Different Now#
AI agents are changing the economics of execution.
Brute-force coding and iteration are now fast and relatively cheap. The loop looks like this:
- Express intent.
- Get something working quickly.
- Evaluate and iterate.
Because of this, the bottleneck is no longer execution itself, but the human step of translating intent into a clean, structured ticket scoping it, formatting it, and fitting it into the system.
We’re still behaving as if execution is slow, when in reality it has become significantly faster. That gap is where the friction comes from, at least from what I can see.
The Part We Underestimate#
“Writing a ticket only takes a few minutes” sounds reasonable.
But the real cost is the interruption. You pause problem-solving to:
- Structure your thinking for others.
- Anticipate questions.
- Formalise something that may still be evolving.
These repeated shifts from building to explaining add up quickly and create a cognitive burden that’s easy to overlook.
A Different Model I’m Thinking About#
In a high-trust team, I would lean towards a different approach.
Start with intent. Someone expresses what needs to be done in a lightweight way (Slack, Teams, CLI). The work gets executed quickly, results are reviewed, and only then is it formalised.
Documentation still exists, but it happens after execution. The system captures what was done, why, and by whom. You retain traceability without blocking the start of work.
Where This Works (and Where It Doesn’t)#
This only works under certain conditions:
- Trust between team members.
- Shared context and understanding of goals.
- Strong engineering judgment.
Without these, structure is necessary. In that sense, Jira is not the problem it’s a solution to high coordination complexity.
But in small or highly aligned teams, especially with AI agents, that same structure can start to feel like unnecessary overhead.
Closing Thought#
In our current setup, Jira makes sense.
But if I were starting something new with people I trust deeply, I wouldn’t default to a ticket-first model. I’d optimise for fast intent-to-execution loops and let systems capture what happens afterwards.