top of page
Value-Amplified-logo

AI Redrew the SDLC but Not the Team: What It Means for Teams

Writer: Dave West
Dave West
5 hours ago
5 min read

The agents have a lifecycle. Your team still needs one.



Google, AWS and Anthropic SDLCs for AI

Over the last few months, I've read three documents that each describe the software development lifecycle for the age of AI agents. AWS has its AI-Driven Development Life Cycle. Google has The New SDLC With Vibe Coding. And Anthropic has its 2026 Agentic Coding Trends Report, where one trend is titled "Single agents evolve into coordinated teams."


The team in that sentence is made of agents. What about people?


That isn't surprising. The companies redrawing the lifecycle are the ones building the tools, so the lifecycle becomes the delivery model. The assumption is that if you get the flow of work through the agents right, delivery will take care of itself.


I've written about two of these already. In August I argued that AWS's AI-DLC still needs human accountability. In September I said Google's new SDLC has a harness but not a team, and promised to make the full case for what a team framework adds. Anthropic's report is a good opportunity to do that.


Insights from each AI SDLC model

Each model provides some valuable insights into how to maximize productivity with these tools. Looking at each of the models:


  • AWS's AI-DLC replaces Sprints with Bolts, "shorter, more intense work cycles measured in hours or days rather than weeks." It also keeps humans involved through Mob Elaboration, "where the entire team actively validates AI's questions and proposals." Making the move from intent to work a group activity is a good idea.

  • Google's The New SDLC With Vibe Coding, by Addy Osmani, Shubham Saboo, and Sokratis Kartakis, offers a useful mental model: an agent is a model plus a harness. The instructions, tools, sandboxes, orchestration, and observability around the model are engineering you control. It explains why two teams using the same model can get very different results.

  • Anthropic's report describes how the engineer's job is changing: "being a software engineer increasingly means orchestrating agents that write code." It says human oversight "shifts from reviewing everything to reviewing what matters." It ends with a line I agree with: "The goal isn't to remove humans from the loop."

    The report also includes some customer examples. Augment Code finished a project its CTO had estimated at four to eight months in two weeks. TELUS teams are shipping engineering code 30 percent faster. These are customer results as reported by Anthropic in its own report, not independent studies, so they should be treated as indicators rather than proof. Even so, they are impressive.


What about the team?

All three describe in detail how work flows through agents: From intent, to specification, to code, tests, and deployment. None of them really answers three questions:

  • Who decides what's worth building?

  • Who outside the harness inspects the result?

  • How does the team get better at working together?

My earlier posts described these gaps for AWS and Google. The AI-DLC has no persistent Product Goal and no stakeholder review of a working Increment and it replaces the Retrospective with "continuous, real-time validation and feedback mechanisms" that it never defines. Google's paper runs to around fifty pages, and the word "governance" doesn't appear once.


Anthropic gets the closest. It says the human role includes "ensuring the system solves the right problems for the right stakeholders." I agree, but it is only one clause; it is given to the individual engineer orchestrating the agents, and there is no mechanism to make it happen.


This is not a new problem. We used to call it Water-Scrum-Fall, a fast, iterative middle with slow, traditional ends. Making the middle faster with agents does not speed up the ends. They just become the bottleneck.


I should be transparent here. I was the product manager for the Rational Unified Process, so I know how appealing a lifecycle built around artifact flow can be. I also remember what happened when organizations mistook it for a way of working. (Some of them are still recovering :-))


What a team framework adds

In The Speed Paradox Nobody Warned You About I argued that the individual was never the unit of delivery. The team is. It's the integration layer, where individual speed becomes collective value. Add a team of agents, and that's still true. A team framework adds three things that a harness does not.


Direction. The harness governs how an agent behaves. It can't tell you why the work matters. The Product Goal and Sprint Goal give humans and agents the same intent to work toward. If you lead engineering, think of the Sprint Goal as the spec your orchestration serves. Without one, a multi-agent system will happily parallelize work in directions nobody chose. In The New AI Operating Model I called that accelerating in an unknown direction.


Inspection from outside the harness. Harness engineering answers "is the agent behaving the way we configured it?" The Sprint Review answers a different question: "did we build the right thing?" Only people outside the harness can answer that: customers, product managers, compliance, the business. The Definition of Done is where the team documents its quality contract. The first item I would add is that someone on the team can explain and defend the code.


Learning. The harness improves the agents. The Retrospective improves the system, and the system includes the humans. Anthropic's own research highlights why this matters. In a December 2025 study of its own engineers (132 surveyed, 53 interviewed), people self-reported using Claude in about 60% of their work, yet said they could "fully delegate" only 0–20% of it. Everything else needs supervision and several were worried about losing the skills that supervision depends on. One said, "It's been sad that more junior people don't come to me with questions as often."


This is not a tooling problem. It is a team problem, and a better harness will not fix it.


Getting started

You don't have to choose between an agent lifecycle and a team framework. Use them together. If you're rolling out AI-DLC-style practices, here is where I would start:


  • Run Bolts and agent runs inside a Sprint, toward a Sprint Goal. Fast cycles are good, but they need a shared goal.

  • Make agent work visible in the Sprint Backlog. If the people affected can't see it, they can't inspect it.

  • Give every agent a named human owner. Accountability doesn't transfer to an agent, no matter how capable it is.

  • Review the working Increment with stakeholders, not agent output metrics. Lines generated and tasks closed tell you about activity, not value.

  • Put harness changes on the Retrospective agenda. Changing instructions, tools or hooks changes how the team works, so the whole team should inspect it.


None of this slows the agents down. It keeps them focused on what matters and helps humans keep the skills they need to supervise them.


The team is still our job

AWS, Google, and Anthropic have done valuable work describing a lifecycle for agents, and we should learn from all three. But they build tools, so they described the lifecycle of the tools. Designing the team that uses them is our job.


How is your team making agent work visible to the people who decide whether it mattered? I'd love to compare notes.


A note on how I wrote this: I used Claude to help with research, source checks, and drafting. The argument and opinions are mine.


Sources

Comments

Rated 0 out of 5 stars.
No ratings yet
Add a rating
bottom of page