How we moved from Jira + AI connectors to a single repo where humans and agents work from the same source of truth.
Part 1 of 2: The why. Part 2 walks through the operating model itself.
Almost every product tool I open lately is reaching for the same idea: put an AI copilot on top of the backlog. Jira has Rovo. ServiceNow ships agile story generation that claims to cut epic breakdown by around 80%. Linear, Azure DevOps, and the rest are adding a button that turns a fuzzy feature into a tidy stack of tickets.
That is genuinely useful. I do not want to wave it away.
The version I run into most these days is subtler. Plenty of teams now connect Jira to their AI assistant as an MCP connector (in Claude’s Cowork, for instance) so the assistant can read and update tickets for them. For a solo PM, that can feel like a small miracle. The assistant can summarize the board, draft updates, and move work along without the usual tab-hopping.
But the shape of the system has not really changed.
The tracker is still a second system the AI has to reach into over an API, one round trip at a time. Someone still has to keep that system in sync with the work. The integration layer did not disappear. It just got automated.
Which leaves a more interesting question sitting in the open:
If AI can generate the work, and read the work, do we still need the tracker to be the home of the work?
At Robots & Pencils we build AI products for enterprises, which means we have felt the gap between how these systems get built and how we were managing the building. On a recent enterprise pilot, I started an experiment: run delivery without Jira as the source of truth.
Generate the epics and stories from a skills pipeline. Let the whole team (PM, designer, engineer) work out of a Git repo where stories, sprints, and decisions are versioned markdown files.
The goal was not a tidier way for me, the PM, to manage a project from my own AI session. That would have been a nicer cockpit, not a better operating model.
The goal was to put the whole team on one source: the engineer in their editor, the designer in theirs, no connector in the middle, and nobody waiting on me to sync a board.
It worked well enough that it is quietly becoming how we deliver AI-native work.
This piece is the why. The next one is the how.
The tell: who’s doing the integrating
Jira makes the human the integration layer.
The work is there, but it is scattered into pieces: the ticket, the related tickets, the research doc, the decision from three weeks ago, the acceptance criteria that changed in grooming, the Slack thread nobody quite remembers.
Before anyone can move, someone has to stitch the picture together.
That was a reasonable deal when the only thing that could read a ticket was a human.
It’s a worse deal now.
The assistant doing more of the building can read the surrounding context, if the context is somewhere it can actually reach. When a story is a markdown file in the repo, the assistant can take in the story, the technical spec, the grooming notes, and the code itself in one pass, because they’re all just files in the same working surface.
Nobody has to describe the map. The assistant can follow the links.
Wiring the tracker into an AI assistant over MCP is still progress. It hands some of that assembly work to the assistant. But it also preserves the old shape: second system, API round trips, and a project record that has to be kept aligned with the place where the work is actually happening.
Repo-native delivery asks for a cleaner cut.
Move the artifacts to where the work and the AI already live, and the integration layer stops being a person.
What about Linear?
Linear is excellent. It is what a better tracker looks like: clean, fast, developer-friendly, with strong GitHub integration and improving AI. Plenty of teams, including parts of ours in the past, moved happily from Jira to Linear.
But even Linear is still a tracker. The work artifacts live in Linear’s database. The AI reaches in through integrations. Engineers still cross from the issue tracker to their editor and back. The fundamental shape, a separate coordination system sitting next to the execution environment, stays intact.
Repo-native delivery goes one step further. It asks whether we still need that separate system at all, once context is cheap and an assistant can read across stories, specs, decisions, and code in one pass. We are not trying to replace Jira or Linear with a nicer interface. We are moving the source of truth into the environment where the work, and the agents, already live.
What changes when the repo is the truth
The benefit I expected was speed.
The benefit that actually mattered was quieter seams between people.
The engineer felt it first. Their coding agent could open a story with the real acceptance criteria in context, not a paraphrase pasted into a chat window. That meant the agent built toward the definition of done instead of drifting toward a plausible interpretation of it.
Even better, the criteria became something the agent could check its own work against. The story was not just an instruction. It was the contract.
And the engineer never left the editor to find any of it. The story, the plan, and the reasoning sat beside the code, not behind another login.
Handoffs changed too.
A designer could drop an artifact and a one-line note into the story folder, and the next person’s editor would read it when they opened the story. No tagging. No “did you see my message?” No quiet dependency on someone remembering to move context from one place to another.
The same source also starts feeding many views. One status.md file can become the morning brief, the sprint risk log, the retro, and the stakeholder report.
You author once and query many ways.
That is where the repo has an advantage over the tracker. A tracker’s data mostly feeds the tracker’s own views. Repo data feeds anything a team can write a prompt for.
The query I lean on most isn’t a fancy one. Each morning, instead of asking the team what they did yesterday, I ask the repo.
Jira is a coordination layer. The repo is where execution happens.
The same assistant helping implement a story can also summarize sprint risk, trace dependencies, draft stakeholder updates, and explain why a decision was made.
When the same system can participate in both coordination and execution, the boundary between the two starts to look less inevitable.
That shift shows up in small ways at first.
The prompts we run do not stay prompts. A query used a few times becomes a skill. The skills, plus the repo structure and conventions, become a scaffold. And that scaffold is portable.
The next engagement does not begin with an empty Jira project. It begins from a template that already knows how stories, sprints, decisions, prompts, and ceremonies fit together. The operational cost of standing up a new project drops because the operating layer already exists.
That is what turns a workflow into a capability.
It also reframes the PM’s job.
When a skill can draft the stories, the PM’s edge moves upstream: framing the right epics, encoding judgment into the pipeline, and curating the context the whole team’s tools draw from.
The craft shifts from producing the backlog to designing the system that produces it.
The judgment was always there. Now it has somewhere explicit to live.
Maybe the bigger question is not how we teach our trackers to work with AI.
Maybe it is whether the work still needs a separate coordination system at all.
Was the tracker ever the right home for the work in the first place?
Ours moved into the repo, and it has not asked to move back.
