I've been asking AI a lot of questions lately about where software teams are headed. Not because I think AI has all the answers — but because I find the conversation clarifying. When you push on a framework hard enough, the assumptions underneath it start to show.
I asked Claude a question that's been sitting with me: how would Anthropic define high-performing software development teams in the future? The answer referenced their own 2026 Agentic Coding Trends Report and framed something I hadn't quite heard said so directly before: the shift isn't just about tools. It's a paradigm shift — the third one in modern software development — and it changes what "high-performing" means at a fundamental level.
Three paradigms, three definitions of performance
Each major paradigm in software development came with its own definition of what a good team looks like. Understanding that pattern helps make sense of where we are now.
| Era | Primary loop | What "high-performing" meant |
|---|---|---|
| Waterfall | Sequential stages, document-driven handoffs | Thorough planning, clear specs, predictable delivery |
| Agile | Short iterations, continuous feedback | Velocity, adaptability, shipping working software often |
| Agentic | Orchestration, automated implementation, human verification | Judgment quality, verification discipline, knowing what not to delegate |
The agentic shift is real and already underway. Engineers increasingly direct long-running systems of agents that handle implementation — writing code, running tests, generating docs, scaffolding pipelines — while the human's job moves to setting direction, designing the right checks, and verifying that what came out is actually what you wanted. Performance stops being about who writes the most code and starts being about who directs the most effectively.
"High performance shifts from 'who codes fastest' to 'who directs and sequences agent work best.'"
One person, the full SDLC
The follow-up question I asked was about what this means for the software development lifecycle itself. If agents can handle implementation across every stage — research, design, development, testing, deployment, monitoring — does that mean one person can now effectively do all the jobs?
The honest answer is: mostly yes, with one important caveat baked in.
A single person directing several specialized agents can plausibly cover research through deployment in a way that used to require a cross-functional team. The coordination overhead between "roles" drops when the roles are agents you're steering. That's genuinely new. But the person's actual bottleneck skill shifts entirely to judgment, verification, and knowing which 20% you can't delegate.
There are stages where agent delegation hits its limits. User interviews and UAT — talking to real users, reading a room, judging whether "acceptance criteria" actually reflect what a customer needs — these are trust-and-judgment tasks, not implementation tasks. The same goes for production incident response, cost tradeoffs under pressure, and architectural decisions with long-term consequences. Agents can surface options. The judgment still has to be yours.
The more accurate framing isn't "one person can do all the jobs." It's: one person can direct all the jobs — with agents doing the heavy lifting inside each stage, and that person's value concentrated entirely in the judgment calls agents can't make alone.
Verification isn't new to us
Here's the part of this conversation that hit differently for me as a quality engineer.
Anthropic's framing of "verification as the core skill" — the idea that the modern engineer's job is defined by high agency, accountability, and tight feedback loops rather than manual output — is being talked about as a new paradigm. And in many ways it is. But for quality engineers, it describes the job we've always had.
Quality engineering has never been primarily about writing test cases. It's been about knowing what matters, knowing when something is actually done well, and knowing how to design systems that catch the right things before they become expensive problems. The skill was always judgment and verification. The rest was craft in service of those things.
What the agentic era does is make that skill the defining skill for everyone on a software team — not just the people in quality roles. That's a meaningful shift. And it means quality thinking — the instinct to ask "but have we actually verified this?" — is no longer a specialty. It's the job.
Five years out
I pushed the conversation further: if waterfall to agile was a recognizable paradigm shift with a name, what's this one called, and where does it lead?
The term that's stuck is agentic engineering. And five years out, a few things seem like reasonably confident extrapolations rather than speculation:
Team size stops being the throughput metric. If one person can already direct research-through-deployment with agent help today, in five years the constraint isn't headcount — it's how many decisions a person can credibly verify and stay accountable for. High-performing teams get measured by outcomes and judgment quality, not velocity or sprint points.
Agents become first-class team members with defined roles. Retros and planning may look like: which agent handled which stage, where did verification catch something, where didn't it. The orchestra-conductor model — one engineer, several specialized agents with distinct jobs — formalizes into something with actual handoff protocols. The way Scrum formalized standups and sprints.
New failure modes become the thing teams are evaluated on. A "high-performing team" in five years is defined less by shipping speed (that's assumed table stakes) and more by how well they've engineered their guardrails — eval design, staged rollout discipline, rollback readiness — because the cost of an unverified agent mistake scales with how much autonomy it had.
The human skills that matter shift toward what agents are worst at. Talking to users. Making judgment calls under ambiguity. Architectural taste. Knowing what not to build. Ironically, this could make product sense and communication more valuable relative to raw implementation ability than at any point in the agile era.
From the conversation
"The human skills that matter shift toward things agents are worst at: talking to users, making judgment calls under ambiguity, architectural taste, and knowing what not to build. Ironically this could make product sense and communication more valuable relative to raw coding ability than at any point in the agile era."
What this means for how we build teams now
We're in the transition period. Most teams are still optimizing for the agile era while operating increasingly in agentic conditions — and the mismatch creates its own kind of waste. Measuring engineers by lines of code or ticket velocity when their actual value is in directing and verifying agents is like measuring agile teams by how detailed their specs are.
The teams that perform in the agentic era are the ones that retrain their intuitions now: toward verification discipline, toward user judgment, toward the clarity of knowing which 20% still needs a human. That's not just a technical capability. It's a way of thinking about what your job actually is.
For me, it connects directly to how I think about quality. Quality was never about finding bugs. It was about building systems — and people — that are less likely to produce them. The agentic shift doesn't change that definition. It just makes it more urgent, and more universal.
High-performing teams in this era will be the ones who understood verification as a discipline before the agents arrived — and extended that discipline to everything the agents now do on their behalf.
This piece was researched and shaped in genuine partnership with Claude, Anthropic’s AI. Tania names this collaboration intentionally — because meaningful AI partnership is worth acknowledging, not hiding.