Scrum in the age of vibe coding: what still needs a team

Anyone who has watched a capable AI tool turn a sentence into a working screen will have wondered what a Scrum Team is for. If the code writes itself, where do the Sprints, the backlog and the review fit?

The honest answer is that they fit better than you might expect, because the parts of Scrum that are about typing code were always the small part. This post is largely opinion, labelled as such. Neither the Scrum Guide nor the SBOK says anything about generated code, so we'll say what the framework does cover, and where we are extrapolating.

What "vibe coding" means

The term appeared in early 2025 and has since been stretched to cover almost anything involving an AI coding tool. The sense in which it was coined was narrow: you describe what you want, accept what the tool produces, and stop reading the code. One widely read developer blog quoted the original description as giving in to the vibes and forgetting that the code even exists, and then argued for a stricter definition: "building software with an LLM without reviewing the code it writes."

That distinction matters because it separates two things people mix up. Using AI tools while you read, test and understand the result is ordinary software development with a faster typist. Not reading what you ship is a different practice with a different risk, and that is the one this post is about.

What gets cheaper, and what doesn't

Think of the work as four activities: deciding what to build, building it, checking that it works, and learning from real use. Generation tools make the second dramatically cheaper. They do little for the others.

• Deciding what to build is still a judgement about value, made by someone who knows the users and the business.
• Checking it works still takes attention, and now more of it per hour, because more code arrives per hour.
• Learning from real use still needs real users, and real users still take calendar time.

The Agile principles say that working software is the primary measure of progress. That sentence gets harder to satisfy in one way and easier in another: producing something that runs is trivial, and knowing whether it is right is not. A team that mistakes the first for the second is going fast in a direction nobody has checked.

Where Scrum helps

A Sprint Goal gives generation something to aim at. A tool will produce whatever you ask for. It can't tell you what is worth asking. The Guide describes the Sprint Goal as the single objective for the Sprint, with flexibility in the work needed to achieve it. That is a good fit for a world where the work is easy and the choosing is not.

The Definition of Done carries the weight. If more of the work is generated, the criteria that say a person has read, tested and understood it matter more. We go into this in the Definition of Done post.

Inspection is the whole point. Scrum rests on transparency, inspection and adaptation. A Sprint Review where stakeholders use the Increment is a kind of check that doesn't depend on who wrote the code. If what shipped is wrong, the review shows it, and the next Sprint can change course.

Short cycles limit the damage. The Guide caps a Sprint at one month. If an AI-assisted change was a mistake, a team on a one- or two-week cycle finds out within it, not at the end of a long project.

Where it strains

Planning to capacity. A team that estimates by how long coding takes will find its estimates wrong whenever a tool does the coding. Effort is still unclear, only in a different place: understanding, integrating and checking. Sprint Planning still works, but the conversation about what can be finished has to include review and testing time.

The Increment bar. A working demo built in an afternoon is a good way to learn something, and a poor candidate for an Increment. An Increment must be usable and meet the Definition of Done. A prototype that nobody has read, tested or secured is not that, however well it demos.

Accountability. The Guide says Developers are accountable for the quality of what they deliver. That doesn't change when a tool wrote the code. "The tool did it" isn't an answer to a stakeholder, and it isn't one the Developers can give each other either.

Understanding that quietly leaves. This is the quiet risk. If nobody on the team has read the code, then when it breaks, nobody can fix it quickly. A Scrum Master who notices that nobody can explain how a part works has found an impediment, even though nothing is visibly blocked.

What still needs a team

The case for the team isn't sentimental. It is that three of the things above are inherently social:

1. Agreeing what to build. A Product Owner ordering a backlog with a sponsor, a developer and a support person all asking for different things is a negotiation. A tool can offer options and can't be accountable for the choice. See the Product Owner role for what that accountability covers.
2. Agreeing what done means. A standard is only a standard if more than one person holds it.
3. Noticing. A person watching how the team works, not just the code it produces, can see when the review has become a rubber stamp, or the tests have stopped meaning anything.

None of that makes the tools unimportant. A team that uses them well will deliver more. The argument is only that the extra output needs more steering, not less.

A small test for your own team

If you want to find out where your team stands, pick one change that was largely generated and ask four questions. Who has read all of it? Who could explain it to a colleague without the tool open? What would fail if it were wrong, and has anyone seen that test fail? And how will you find out from a real user, soon, whether it was the right thing to build? The answers are rarely the ones a team expects, and they say more about its Definition of Done than any checklist does.

How to practise it

The judgement this post describes is about scope, what counts as done, and how fast feedback arrives, and it only develops by making the calls.