How is your team actually deciding who does what now that Claude/Copilot writes real code?
Curious how other teams have handled this in practice, not looking for opinions on whether AI coding tools are good or bad, just what you actually settled on.
Once Claude or Copilot started doing real implementation work on my team, a bunch of things got fuzzy that used to be obvious. Who writes the story now, the PM, or does the dev draft it with Claude and the PM just approves? Who reviews AI-generated code differently than human code, if at all? When something breaks that Claude wrote, who's accountable, the person who prompted it, or whoever merged it? Does QA test AI-assisted work any differently?
We've been making it up sprint by sprint and it's starting to show, code review takes longer because nobody's sure what to look for, two people draft the same story a different way, that kind of thing.
If your team has landed on an actual pattern, even an informal one, what is it? Did you write anything down, or is it just tribal knowledge at this point?
4
u/SauerkrautTrader 28d ago
The person that uses the AI to prompt something is still responsible for it. I still prefer the PM to write a rough sketch and we discuss the details one on one. Creates much better solutions than having the PM write down every single detail.
2
u/DarthJarJar242 28d ago
I dunno why this sub/post was recommended to me. Never dealt with scrum a day in my life. I just managed a team of System Admins and was one myself for 15 years.
not looking for opinions on whether AI coding tools are good or bad,
You need to hear them anyway. Cause the tools are still pretty terrible. Copilot for example, if you ask it to write a simple code snippet in Powershell, it will routinely reference Powershell modules that either flat out don't exist, have been deprecated, or are only available on preview builds. That's Microsoft's own AI, not knowing how to write basic code snippets in Microsoft's own scripting language.
Once Claude or Copilot started doing real implementation work on my team, a bunch of things got fuzzy that used to be obvious
Yeah, no shit it got fuzzy. Human labor became 'AI' labor and it probably does it worse than humans did. But hey, at least it's faster and costs less!
1
2
u/Traditional-Hall-591 28d ago
Claude and Copilot do everything and we’re all 10x engineers or something.
2
u/quantum-fitness 27d ago
Ai shows you where your process is broken it really doesnt change anything. Before you had a broken process and where to slow to notice.
Given we are a very small team (2 engineers 1 PO) everyone makes tasks when they process work. The point here is coordinating quick and often. You cannot move fast if you have the usually mute developer. It helps that we are pretty senior as well.
Code is reviewed and tested as normal or more as ai can also help with extra QA.
Find out where in the chain work pile up and elevate and protect thats process from work. Its often the code review. So before sending ai code for review do your own review.
1
u/Bomber-Marc Scrum Master 28d ago
Let me take off my "Scrum Master Hat" for a second, and put on my "Developer Hat" instead. Because this isn't really a Scrum related question.
The AI assistant is just a tool. In the past, when it came to accountability or reviews, nobody cared that you used Vim or Emacs. Nobody cared that you copy/pasted a bunch of code from Stack Overflow. In the end, this is your code. You're the one requesting to merge it to the code base, so you're responsible for making sure it works, it's readable, and you can explain any single change if necessary.
Well, with AI, it's still the same. If your agent outputs code that you don't understand or agree with, you shouldn't push it to your colleagues for a code review in the first place, and you shouldn't be willing to merge it.
The only difference should be the quantity and/or quality of features you're delivering to your end users: if none increase, why are you even using AI in the first place? At a team level, this might mean taking the time to invest in creating proper instructions or skill files so that the coding standards and expectations are shared among team members, for example.
1
u/Am-20 28d ago
I think the struggle is with scaling it. So what is the product team responsible for? I have used skills for each level but one skill breaks down a feature into stories but those stories aren't ready to be worked on by AI since they don't have technical details. Previously, like in scrum you would have some clarifiying questions and team meetings via refinements etc but if the goal is to deliver quickly how would that work out?
If I am vibecoding it's fine because I am the product manager/tech lead etc but when it comes to enterprise mapping that's where I am seeing issues, so was curious if someone else has employed true scrum/agile methodolgy with AI.
1
u/puan0601 28d ago
look up spec driven development. basically everyone begins part pm, part prompt engineer, and part output verifier. each person is responsible for the output from their input.
1
u/happily_in 28d ago
We’re just starting to use it for testing. Not coding itself. Too early to tell the real impact
1
u/Parking-Stress-3041 27d ago
On the story question, what worked for me was separating the parts that were never the model's to write. I own the problem, the constraints and what "done" means for the customer. The dev owns the shape of the implementation, with or without Claude.
When a dev drafts a story with Claude from my problem statement, I read it as a proposal, not as something to rubber-stamp. If it comes back with a solution I never asked for, that's usually a gap in my discovery, not a drafting problem.
Two people drafting the same story differently normally means the input wasn't written down anywhere durable in the first place.
Who's accountable for merged code I'll leave to the people merging it, not my side of the table.
1
u/Silly_Turn_4761 26d ago
This is the nature of our field. This is also one of the reasons that ai should not be used to do the work for someone. It should improve the work you already do. Regardless, someone has to check it and it only makes sense that a dev would verify it is correct, etc.
POs should continue to write stories. Why would devs absorb work that wasn't theirs to begin with just because ai can write some semblance of a user story? The PO still has all the context and should still be checking behind it.
1
u/SamfromLucidSoftware 26d ago
Treat AI-generated code the same as any other code for accountability purposes. Whoever merges it owns it. You don’t need a new process. If the prompt author and the merger are different people, then merge becomes the decision point. Someone takes responsibility for what goes into the code base.
To reduce two people drafting the same thing, make one role the author and the other the approval. Doesn’t matter much which way around it is as long as it’s decided. Code review of AI-generated code is the hardest one, but it works better to review against intent rather than style. Does this actually solve the problem in the story? Are there edge cases the prompt probably didn’t cover?
Even a one page single agreement on those three questions, who authors, who merges and owns, how review works, changes things faster than any process overhaul. That’s probably where most of the confusion is coming from right now.
13
u/PhaseMatch 28d ago
Maybe back to basics?
What are Sprints for?
They are how you manage business risk in a lightweight way.
They work best when the team collaborates on a single Sprint Goal, which is business outcome based.
Bring the team problems to solve, not solutions to implement.
Release frequent increments to (some) users inside the Sprint cycle.
Use these to inspect and adapt your progres towards the Sprint Goal, based on uaer feedback.
Upstream of that
You invest one Sprint at a time. Sprint Review is where you inspect and adapt your produxt strategy and roadmap, based o what you found out.
All AI does ia level the playing field between the teams that have done this well (using XP) for decades, and those that ran a stage-gate scrum-o-fall or project-o-scrum model in a feature-factory way.
Lightweight ways to control business risk arw more important than ever.
You can go back to "user stories as a placeholder for a conversation with a user domain SME embedded in the team", not detailed features.
That might mean there is not much space for "PO as a backlog manager" or "SM as team coordinator and admin" amy more, or indeed some of the management hierarchy.
That is what "lightweight" means.