Jira Was Built for Humans Writing Code. That Assumption Is Now Wrong.

Picture a ticket that reads “add retry logic to the payment service.” An agent picks it up, writes retries that compile, passes the unit tests, and opens a tidy pull request. At review, a senior engineer spots the problem in about four seconds: the new retries fight the circuit breaker already on that service, and the intervals stack badly against timeout configs on two downstream consumers. None of that was in the ticket. It was in the engineer's head.

A human assigned that ticket would have done the one thing the agent couldn't. They would have asked. Pinged the PM, scrolled back to the Slack thread where the circuit breaker came up, or just remembered the incident from last quarter. The ticket was never supposed to carry the answer. Its job was to point a knowledgeable human at it.

That is the assumption Jira runs on, and it held up for twenty years. It stops holding the moment the thing reading the ticket is an agent.

TL;DR

• A Jira ticket points at a specification; it doesn't contain one. The real context lives in Slack, Confluence, and people's heads. Humans fill the gap by asking around; agents can't.
• This is structural, not sloppiness. Jira's data model was designed for human UI rendering, as Atlassian's own documentation admits.
• Bolting AI on top (Rovo, MCP) gives an agent access to the tickets, not understanding of the project. “Write better tickets” helps a little, but under-specification is a property of language, not a discipline failure.
• The fix is a data model where context is structured for machine reading from the start. That's what we're building.

The ticket is a pointer, not a spec

Watch where the actual reasoning happens during an incident. A problem gets diagnosed across twenty messages in a Slack channel, with theories, dead ends, and the one comment that turned out to matter. Then someone files the Jira issue, and as incident.io puts it, “a thread of twenty messages diagnosing a problem stays in Slack. The Jira issue gets a one-line description.”

That pattern repeats on almost every ticket. The conclusion gets recorded; the reasoning that produced it lives somewhere else. Atlassian's own State of Developer Experience 2025 found that the single biggest drain on developer time is “finding information” scattered across tools, and that half of developers lose ten or more hours a week to work that isn't coding.

A human handles this without noticing. They read the stub, sense what's missing, and go find it. The ticket works for them precisely because it doesn't try to be complete; it trusts the reader to close the gap. Hand the same stub to an agent and the gap stays open.

The data model was designed for a human reader

This goes deeper than thin descriptions. The structure of a Jira issue assumes a human will interpret it. Take issue links — “blocks,” “is blocked by,” “relates to.” You would think those encode a relationship a machine could reason over. Atlassian's own developer documentation says otherwise:

“Whilst Jira issue links are bidirectional, the semantics of each direction is only interpretable at the user interface level and not at the API level… you should not apply any meaning to field names suggesting directionality.”

The meaning of a link exists for a person looking at the screen. To anything reading through the API — every agent, every integration — a link is a label with no semantics attached. Atlassian designed the relationship to be interpreted by a human, and said so.

The description field tells the same story. Jira stores rich text as ADF, a nested JSON tree built to render formatting in a browser. It is a clean, well-specified schema. It is also shaped for the browser, which is why an entire cottage industry of ADF-to-Markdown converters exists just so language models can read what a ticket says. The text of the ticket is encoded for a rendering engine, and the agent has to reverse it back into prose before it can even start.

None of this is a bug. Jira was built when every reader was a person, and for a person these choices are invisible. The links mean what you remember they mean. The description renders cleanly. The missing context is a Slack search away. The design target was a human, and the design is good at hitting it.

“Just write better tickets” doesn't scale

The obvious objection is that this is a discipline problem. Write fuller tickets, keep Confluence current, link things properly, and the agent gets what it needs. Teams have been trying to write better tickets for two decades. It is worth understanding why they never quite get there.

Under-specification isn't a habit you can train away. As one engineer put it, it is “a structural property of the interface between natural language and code.” Code has to specify every branch, type, state transition, and error path. Natural language names the happy path and trusts the reader for the rest. “Add authentication” compresses an enormous number of decisions into two words, and a person unpacks them from experience. The ticket can always be more complete, and it never will be, because the writer is a human relying on the reader being one too.

Bolting AI on top inherits the mess underneath

Atlassian's answer is Rovo: AI agents that read across your Jira and Confluence and act as “teammates.” The Atlassian MCP server gives outside agents the same reach. Both rest on the assumption that the bottleneck is access, that a model able to reach the data will understand the project.

Access was never the bottleneck. An agent pointed at your Jira through MCP can read every field, and it gets exactly what's there: stub descriptions, semantically empty links, and pointers to Slack threads it can't follow. Even sympathetic analysts covering Rovo's launch landed on the same caveat: the quality of the answers is capped by the cleanliness of the data underneath, and Rovo mostly lets you see the mess clearly rather than removing it.

Atlassian's CEO frames the AI era as “context multiplied by intelligence,” and argues that with models commoditized, the real moat is institutional memory. He's right about the equation. The trouble is the value of the context term when that context is shaped for human eyes. Multiply a smarter model by a hundred billion human-rendered, frequently stale connections and you get a lossy signal amplified: better fuel poured through the same leak.

What Jira gets right

Jira earned its position, and the case for staying is real. It runs the software process at a large share of the companies reading this. Its configurability maps to almost any workflow and audit regime, which matters enormously in regulated environments. JQL is a genuinely powerful query language. The marketplace is deep, and leaving it means giving up integrations that teams depend on. The cross-product graph Atlassian has accumulated holds connections no greenfield tool has on its first day.

If you run a large, settled org with a working Jira and no appetite to move, none of this is urgent. Jira is excellent software. It is excellent for an assumption that is quietly expiring.

The reader changed

Thomas Dohmke saw the same shift from inside the incumbent. He left the CEO seat at GitHub in 2025 and raised one of the largest seed rounds in dev-tools history to rebuild the stack, on the grounds that “the entire system, from issues to pull requests to deployment, was not designed for this new era of AI agents.” His framing of GitHub applies just as cleanly to Jira: it “was built for human-to-human interaction.”

For twenty years that was the right thing to build. Now a growing share of the reading, and the writing, is done by agents that carry nothing between sessions and cannot ask. The data model has to hold the context itself, structured so a machine can use it, with links that mean something to more than the eye.

Jira answered the question of its era well, and then the question changed. That's what we're building Codara to answer. If you want to see how, the product context chain is where it starts.