Producers: You Won't Be Replaced by AI. You'll Be Replaced by Producers Who Know Claude Code.
A producer's guide to building your own replacement.
A producer using Claude Code can do the job of two or three producers. That gap is already opening.
The advantage goes to producers who use AI. The distance between them and everyone else is widening fast.
Claude Code turns Jira from an admin burden into an execution layer: epics, stories, labels, and fix versions generated programmatically from spec documents.
Institutional memory, decision trails, and spec-to-ticket sync can be maintained by one person where it previously required a team.
It was a Tuesday afternoon, and I was looking at a complete Jira epic hierarchy, properly labelled, with fix versions attached, Confluence links wired to every story, the whole thing triangulated back to a SQLite database that would let me push scope changes across sixty tickets in a single command. I had built it that morning. Built it from scratch: the spec infrastructure, the push script, the decision trail, the sanitation layer for external AI artefacts.
Three months earlier, something equivalent had taken me and two colleagues the better part of a week.
I sat with that for a while.
I want to be honest about where I was before this. I was not worried. I’d been a producer for thirty years. I’d seen a lot of things that were supposed to change everything, and most of them changed some things, incrementally, and the job kept going. The discourse around AI and jobs felt like the same pattern. Lots of energy. Lots of conference panels. The actual work stayed the same.
I was wrong, and I think I was wrong in a specific way worth naming.
The thing I kept evaluating was whether AI could do the producer’s job. Could it run a sprint? Could it manage stakeholder conflict? Could it make the call when two equally important things were both at risk and you had to pick one? I concluded it couldn’t, and I moved on.
The question I kept missing was whether a producer using AI could do the job of two or three producers. That’s a different question, and it has a different answer.
The question I kept missing was whether a producer using AI could do the job of two or three producers. That’s a different question, and it has a different answer.
The system I’ve built has two parts that interlock, and the interlock is the point.
The first part is documentation infrastructure. Everything lives in a single versioned repository. It syncs to the team wiki automatically. When a document comes in from an external AI tool, a sanitation layer reconciles it to project standards before it enters the system: terminology, formatting, cross-references, authorship. The reconciliation happens on ingest, not as manual policing after the fact.
Every open question becomes a structured decision card. The question gets answered, the rationale is recorded, and the trail is auditable. When something changes, the system knows which documents depend on which other documents. Requirements that haven’t been built yet still inform foundational design decisions, which is how you reduce rework rather than just managing it.
Process documentation lives alongside the product being built. When the team changes, or when I come back to something six weeks later, context survives. Decisions survive. The reasoning behind decisions survives.
The second part is Jira, turned from an administrative burden into an execution layer.
Tickets are generated from spec documents programmatically. The full epic-to-story hierarchy comes from the database in one command, with correct labels, fix versions, and Confluence links already attached. When a scope decision changes, say a screen moves from MS1 to Alpha, the fix version on every affected ticket updates in one operation. One operation.
Labels are load-bearing. Every ticket is tagged with domain, milestone, and doc type at creation. A developer can go from ticket to spec to wireframe in two clicks. When a PRD is accepted, its functional requirements can be parsed directly into Jira epics and stories. The loop from product intent to executable ticket closes programmatically. The database is the source of truth; the push script reads from it and writes keys back, so the database, Jira, and the specs stay triangulated at all times.
What I’ve described sounds like tooling. It is tooling. But the thing it represents is something else.
Producers have always spent a significant portion of their time on work that is necessary but not valuable. Maintenance. Reconciliation. Making sure the ticket matches the spec. Making sure the spec reflects the decision. Making sure the decision was actually recorded somewhere. Policing consistency across documents that were written weeks apart by people who no longer work here. Answering questions that had already been answered but weren’t findable.
That work is real. It consumes real hours. It requires real attention. And it adds no value to the product whatsoever.
I’ve been doing it for thirty years, and I’ve watched everyone around me do it too, and we all accepted it as part of the job because there was no alternative. The alternative was chaos.
That work is real. It consumes real hours. It requires real attention. And it adds no value to the product whatsoever.
There is now an alternative.
The hours I used to spend on reconciliation work are gone. The spreadsheet tracking which tickets needed updated labels is gone. The “let me check the latest version of that doc” conversation is gone. The “I need someone to help me generate all the stories for this epic” request is gone. All of that disappeared because I built a system, with AI, that makes those problems structurally impossible.
That’s the shift. The system is architecture, and architecture changes what a single person can maintain.
Here’s what that actually means for headcount.
I can currently maintain, with one person, what used to require a team to police manually. I can execute, in an afternoon, what used to require a week of coordination. I can absorb a scope change across the entire project in a single session that leaves a clean audit trail and updated tickets. I can onboard a new team member into full project context in a fraction of the time, because the context is structured and findable and current.
Studios are not going to look at this and think: great, we’ll keep the same number of producers and let them work on more interesting things. Some will. Most won’t. Most will look at it and think: we used to need four of these. Now we need two.
The arithmetic is simple. And the producers who end up on the wrong side of it will be replaced by someone like me, who spent a few months building something that didn’t exist before, and now does the work of a small team.
Studios are not going to look at this and think: great, we’ll keep the same number of producers and let them work on more interesting things. Most will look at it and think: we used to need four of these. Now we need two.
I didn’t build this because I saw it coming. I built it because I had a specific problem: project context evaporating at team transitions, spec-to-ticket reconciliation eating my Fridays, scope changes causing cascading inconsistencies I kept catching too late. I kept reaching for Claude Code to solve specific pieces of it, and the pieces kept connecting.
I was thinking about whether the push script was reading the right columns from the database. The implications came later.
The implications only became clear on that Tuesday afternoon, when I looked at what I’d built and tried to remember what I used to do instead, and realised that what I used to do instead involved other people.
I’m not early to this. I was actively late. I resisted it. I had reasonable-sounding arguments for why the job was safe and why the discourse was overblown. Some of those arguments were correct, in the narrow way that arguments can be technically correct while completely missing the point.
The thing that finally got through to me was a Tuesday afternoon, a complete Jira hierarchy I’d built before lunch, and a quiet realisation that the version of this job I’d been doing for thirty years had just changed permanently.
This is fantastic Rob. Any chance you could share a demo / example of how your system works and how you stood it up?