Jira’s AI Agent Loops Should Be Judged by the Work Developers No Longer Have to Do

Atlassian wants its AI to find coding jobs in Jira, the software teams use to track work, instead of waiting for someone to assign each job. Its agent loops feature would scan for clearly described, unassigned tasks and send suitable work to Jira Coding Agent to attempt a fix and run tests.

That is a sensible place to apply automation, but it also exposes a bad way to measure it. A backlog full of proposed fixes can look productive even when the team has acquired another job: sorting useful changes from plausible distractions. The feature should earn its place by reducing the effort required to finish worthwhile work. Counting the agent’s attempts would reward activity before anyone has established its value.

Announced September 10, agent loops are in private early access, with a waitlist. The intended output is a pull request: a proposed code change that someone can inspect before accepting it. For a team with a neglected backlog, the promising change is getting work to that review stage.

The bottleneck can move

Imagine a team with twenty small bugs and one engineer who understands the affected system. Giving an agent more of those tickets could increase the number of changes awaiting that engineer. It would not create more of the engineer’s attention. This hypothetical team improves only if the proposed fixes arrive with enough relevant explanation and evidence that reviewing them is substantially easier than preparing them.

That does not make automated preparation pointless. Investigating a well-described problem, locating the relevant code and running a useful test can remove real effort from a developer’s day. The opportunity is to package that work so another person can understand it quickly. A good handoff preserves the reasoning needed to assess the change without requiring the reviewer to reconstruct every step the agent took.

Jira already supports rules that trigger its coding agent when a work item meets chosen conditions. Atlassian’s documentation says that route opens a draft pull request and leaves review and merging to the team. The new loops add continuous selection of suitable work. IT Pro’s coverage describes the same backlog-to-review sequence.

Task selection becomes important for the same reason. An apparently small ticket may depend on an undocumented business rule. Another may describe a reproducible mistake with an obvious expected result. A system that attempts both indiscriminately can make itself look more capable while consuming more review time. Choosing the second task, and leaving the first alone, could be the more useful performance even if it produces fewer pull requests.

Consider a hypothetical small bug with clear steps to reproduce it. An agent could prepare a fix while a developer handles another task. But if the description misses the real cause, passing tests may still leave the original problem unsolved. The reviewer must check intent as well as code.

Passing the wrong test is still wasted work

In that bug example, a test is useful only if it captures the behavior that was wrong. A change could satisfy a newly written test while leaving the user’s complaint untouched. It could also fix the reported case by breaking a neighboring one. The developer’s job is to connect the proposed change to the intended behavior, rather than accept the mere existence of a green test result.

Atlassian’s product page advertises session histories, correction controls and visibility into stuck work. Those are useful things to demonstrate during early access. A record of what the agent did can help a developer understand a proposed change without reconstructing its entire attempt.

Session history could help with that connection if it answers specific questions. What did the agent believe was broken? Which part of the change addresses it? What result would disprove the proposed fix? A long transcript is not automatically an efficient answer. The useful record is the one that lets the reviewer find the decisive evidence without reading the entire conversation that produced the code.

The materials reviewed do not establish a measured productivity gain for these private loops. More proposed fixes could mean more useful output, or a larger review queue. The relevant result is correct work accepted per unit of developer effort, including time spent explaining tasks, checking changes and repairing mistakes.

There is a case for starting small

A narrow early deployment can be valuable precisely because it exposes the costs that a demonstration leaves out. A team could compare a familiar class of tasks before and after introducing the loop, including clarification, review and repairs. This would not produce a universal verdict about AI programming. It would answer a more useful local question: whether the tool gives that team time back on work it actually needs done.

My optimism about this feature rests on its modest endpoint: a proposed change that someone can inspect. That is a tractable place to improve the division of labor between an agent and a developer. But the target should remain completed, correct work. If Jira’s loops make the reviewer faster, they can be a genuine productivity tool. If they merely keep the reviewer busier, the backlog has acquired an enthusiastic new author rather than a solution.