Would You Let an AI Agent Pick Up the Next Jira Ticket?

I saw an announcement from Atlassian recently that made me think about something software teams might have to get used to fairly quickly.

They've been working on what they call "governed agent loops". The idea is that an AI agent doesn't just help a developer write some code. It can find suitable work in Jira, pick up a ticket, make the changes, run the tests and raise a pull request for somebody to review.

Some of this is already possible. Jira can assign work to coding agents, and Atlassian is also working on ways of checking whether a ticket contains enough information before an agent starts working on it. The more automated version, where agents continuously work through suitable tickets, is still in early access.

It made me wonder whether I'd actually be comfortable letting an AI agent pick up the next ticket from a backlog and start working on it. I think there are already some types of work where I would, but the more I thought about it, the less the question seemed to be about whether the agent could write the code.

The ticket is rarely the whole story

I've worked in software delivery teams for a long time, and a Jira ticket can look perfectly reasonable until somebody actually starts working on it.

You read the description, look through the acceptance criteria and everything seems clear enough. Then somebody starts looking at the code and asks a question which leads to a conversation with the BA. QA remembers an edge case from a similar piece of work. Another developer points out that a different service depends on the behaviour we're about to change, or somebody realises there's an accessibility requirement that wasn't mentioned in the ticket.

That doesn't necessarily mean the ticket was badly written. Quite often it's just the point where a fairly simple description of a change meets the reality of an existing software system.

A lot of the information needed to make a good change doesn't live in Jira. Some of it is in the code, automated tests, documentation and architecture decisions. Other parts are simply known by the people who have spent time working on the system.

You also don't always know which bits of that information matter until somebody starts asking questions.

That's something an AI agent has to deal with if we're going to give it real development work rather than use it as a coding assistant.

Writing the code may not be the difficult part

Take a fairly ordinary change to an online form. We want to add autocomplete to a country field and the acceptance criteria say that somebody should be able to start typing a country name and select it from a list.

A coding agent could probably make a reasonable attempt at that quite quickly. It could find the relevant page, change the component, write some tests and raise a pull request.

There may be quite a lot behind that simple change though.

The service might have accessibility requirements around keyboard navigation and screen readers. There could already be an autocomplete component elsewhere in the application that should be reused. Some country names might need to map to different values before they're sent to another system, and there may be existing tests which cover behaviour that isn't obvious from reading the ticket.

A developer familiar with the service might already know some of that. Somebody less familiar would probably discover it as they worked through the change and started speaking to the rest of the team.

An agent needs a way of getting to the same information.

That's the part of Atlassian's announcement I found more interesting than the coding itself. Their approach is about giving agents access to more of the context around the work, including coding standards, architecture and previous decisions, while also putting permissions, review and organisational controls around what they produce.

Once agents start picking up real work, the problem becomes much closer to the one we already have when somebody new joins a team.

Would you give the ticket to a new developer?

Imagine a capable developer joined the team this week but didn't know the system yet. Could you give them the ticket and reasonably expect them to understand what needed to be done?

If they would immediately need to speak to three people before they could safely make the change, I'd be cautious about assuming an AI agent has everything it needs simply because the acceptance criteria look complete.

I don't think the answer is to turn every Jira ticket into a detailed technical specification either. That would create its own problems and we'd soon spend an unreasonable amount of time maintaining tickets.

The useful information needs to live in sensible places. Architecture decisions can be documented. Coding standards can be clear. Important behaviour can be captured by automated tests. APIs can have contracts, and decisions that are likely to matter again can be written down rather than disappearing into a meeting or a message thread.

Most good teams already try to do some version of this, but agents could make the gaps much easier to spot.

A ticket might only make sense because everyone currently in the team remembers a conversation from three months ago. An important design decision might still live mainly in the head of one developer. The automated tests might not explain the expected behaviour particularly well because everybody involved already knows how that part of the system works.

People tend to fill those gaps for each other. An agent won't necessarily know that there is a gap to fill.

Making more of that knowledge visible would help an agent, but it would also help somebody joining the team or returning to an area of the system they haven't worked on for a while. Preparing software for agents could therefore expose some fairly ordinary engineering improvements that were worth making anyway.

Faster coding doesn't necessarily mean faster delivery

There's another reason I'd be cautious about measuring the value of these tools simply by how quickly they produce code.

Most software teams aren't being held up because developers can't type quickly enough. Work gets delayed because requirements aren't clear, another team needs to make a change, somebody is waiting for an answer, a pull request needs reviewing, an environment isn't working or a decision hasn't been made.

Writing the code is one part of getting something into production.

DORA's research into AI-assisted software development is useful here. Developers reported improvements in areas such as productivity and flow as AI adoption increased, but that didn't automatically translate into improvements in delivery performance. Their research also found associations with lower delivery throughput and stability.

That doesn't strike me as particularly surprising.

I use AI in my own development work and there are tasks I can get through much faster than I could previously. If I produce a change twice as quickly and it then waits for somebody to review it, however, part of the time I've saved has simply moved somewhere else in the process.

If a whole team starts producing changes more quickly, that could mean more pull requests waiting for review, more changes competing for testing and more code moving through environments at the same time. If the requirements weren't completely understood in the first place, it could also mean more rework.

So if AI agents do start taking more work directly from our backlogs, I'd want to look at what happens to the whole delivery process rather than just how quickly each individual change is generated.

What would I actually give an agent?

I'd start with work that was small, well understood and easy to verify.

A dependency update is an obvious example. A straightforward test failure might be another. There will also be small application changes where the behaviour is well covered by tests and the surrounding code gives the agent most of the context it needs.

I'd still expect the agent to work within the same engineering controls as everybody else. Tests need to pass, security and coding standards still matter, changes need appropriate review and somebody remains responsible for deciding whether something should make it into production.

I'd then see what happened.

If an agent consistently handled that kind of work well, I'd be comfortable trying something a little more complicated. If it repeatedly needed information that wasn't available to it, I'd be more interested in understanding why than simply trying a different model.

I wouldn't currently give an agent free rein over a backlog and assume that anything marked ready for development was safe for it to pick up. But I can see myself being comfortable with an agent taking certain well-defined Jira tickets, making the change and raising a pull request for the team to review.

Before doing that, though, I'd probably spend at least as much time looking at the tickets, the codebase and the way the team works as I would choosing the AI agent.

That seems likely to tell us quite a lot about whether we're actually ready to use one.