The technical patterns in the last nine chapters live inside teams, and teams are slow-moving things. The team conversations around agentic SDLC matter more than the technology choices — who reviews what, who gets credit, who is hired, how new engineers learn. Get these wrong and even the best technical practice produces a team that's miserable, slow, and quietly worse than the human-only version. Get them right and the technical practice compounds: tools amplify culture, culture amplifies tools.
This chapter is about the parts of the practice that aren't code. For tech leads, these are usually the higher-leverage decisions.
In a healthy agentic team, a meaningful fraction of PRs — sometimes a majority — are agent-authored. The reviewer is human; the author is an agent acting on behalf of a human. This sounds the same as human-authored review but isn't, because the review serves a different purpose.
Human-to-human review traditionally serves three purposes: catch bugs, share knowledge, and maintain consistency. With agents, the second purpose is partly gone — the agent doesn't learn from your feedback the way a junior would. The first and third get more important by contrast.
| Human attention on | Automated attention on |
|---|---|
| Did this do what was asked? | Style and lint |
| Does it match codebase conventions? | Test coverage |
| Any silent side effects? | Type checking |
| Is the scope correct? | Performance regression |
| Are there security implications? | Common bug patterns |
If your senior reviewers are spending time on style or coverage, you're paying a senior to do work a lint should do. Move the line. Reserve human attention for what automation can't catch.
For agent-authored PRs, three review checks become disproportionately valuable:
Don't use review as your test suite. If the only thing catching agent bugs is a senior engineer reading every diff, the practice doesn't scale. Tests, types, lints, and review-bot are the layers that catch the systematic stuff. Human review is for what those can't catch — and there's plenty of that, just not the routine bugs.
Agent-authored PRs tend to be larger and more frequent than human-authored ones. The reviewer's time bill grows. Two mitigations work:
The PR author summarises — even when the author is human-with-agent. A three-bullet "what this changes, what it doesn't, what to look at closely" at the top of every PR. Reviewers skim those and target their attention.
Review-bot does the first pass (covered in Ch. 06). By the time a human sees the PR, an agent has flagged the obvious issues, which the author has addressed. Humans focus on what the agent couldn't catch.
A new engineer joining an agentic team needs three things, in this order: confidence with the codebase, confidence with the agent, and the team's tacit norms about when to use which.
Old-school onboarding works. Pair them with a senior. Have them read the project prompt, decision log, and changelog you built in Ch. 08 — those are the artifacts that scale. Ship a tiny PR without agent help to internalise the shape of the codebase. The goal is to know what "normal" looks like before they let an agent define normal for them.
Pair them with someone who's comfortable in the practice. The first few agent-assisted tasks are best done watching someone good. The skill being learned isn't "how to use the IDE" — it's "when to interrupt, what to delegate, how to read a diff." All of that is faster shown than read.
Every team develops its own norms — "we never let the agent touch migrations," "we always have a human author the initial spec," "we don't merge agent PRs on Fridays." These norms aren't usually written down. Make a list during onboarding and add to it as the new engineer asks questions.
The "two-week, no-agent" rule. Some teams enforce that new engineers don't use agents for the first two weeks. The reasoning isn't ideological — it's that you can't tell when an agent is steering you wrong if you don't have your own baseline yet. Worth trying, even informally.
This is the question every team is figuring out in 2026, and most haven't landed yet. Three sub-questions worth answering explicitly:
Who is the author of an agent-assisted PR? The human driving the session. The agent is a tool; the human had the goal, did the review, made the calls. Git commit attribution should reflect that. Don't have your CI bot listed as author except for fully automated fixes.
Who gets credit for the work? Still the human. But the calculus for "amount of work" has shifted — shipping ten well-reviewed PRs in a week is real work, even when an agent did most of the typing. Performance frameworks that measure "lines of code" or "PRs shipped" need updating; they were already bad proxies, now they're terrible ones.
How do you measure "agent productivity"? You don't, not directly. Measure the team's productivity. If an engineer is producing more value with agents, that's reflected in their outcomes. Trying to isolate "what the agent did vs. what the human did" is a doomed exercise; the work is genuinely collaborative.
The frameworks that work tend to focus on outcomes — features shipped, bugs eliminated, regressions prevented, junior engineers leveled up — rather than activity. Activity metrics get gamed; outcome metrics get harder to game when agents are involved.
Five years ago, a senior engineer's value was largely in the things they could do that juniors couldn't — design a system, debug a hard concurrency issue, navigate a hostile codebase, mentor through code review. Most of those skills are still load-bearing. But the relative weight has shifted.
| Senior engineers do more of | Senior engineers do less of |
|---|---|
| Writing specs an agent can execute | Typing code on the hot path |
| Reviewing with sharpness | Hand-holding juniors through routine tasks |
| Owning the project prompt and decision log | Memorising codebase trivia |
| Building internal tools and workflows | Routine debugging |
| Setting the threat model |
The skills that distinguish strong candidates are tilting toward judgment-heavy ones. Coding interviews that test typing speed and syntax recall are even more out of touch than they were. Interviews that test design choices, review skill, and the ability to be wrong out loud — those have always been better signals, and they're more so now.
A practical change worth piloting: at least one interview round where the candidate uses an agent to do real work, and you watch. Not to test their tool fluency — to see how they think when typing isn't the bottleneck.
A team decides to "go all-in on AI" for a sprint. Everyone uses agents for everything. Output spikes; bugs in production spike a few weeks later. The post-mortem reveals that quality controls were skipped under velocity pressure.
What goes wrong: the agentic practice is most reliable when the team's existing quality controls (tests, review, observability) are healthy. Trying to scale agent usage faster than those controls can scale produces fragile output.
Fix: tie agent usage growth to the health of the supporting practices. If review queues are backing up, slow down. If test coverage is dropping, slow down. Throughput is meaningless without quality.
No shared project prompt. No team-level conventions. Each engineer has their own setup, prompts, workflows. The team's code becomes a patchwork that's locally optimised and globally inconsistent.
What goes wrong: agents amplify whatever you give them. Without shared conventions, they amplify inconsistency. Different engineers' work starts to feel like different codebases.
Fix: invest in shared infrastructure — project prompts, MCP servers, review-bot configurations. Treat the team's agent setup as a team-owned product, not personal config.
If you lead a team — formally or informally — these are conversations worth having explicitly rather than letting them happen by default:
One thing worth flagging, because it gets missed: knowing what to build didn't get easier with agents. Agents are accelerants on execution. They don't tell you which feature is worth building, which technical bet to take, which trade-off to make. That work — the work of figuring out what to do — is unchanged.
The implication: teams that were strong on execution but weak on judgment are now more obviously weak on judgment. The bottleneck moves. If you led such a team, the shift to agentic SDLC will be uncomfortable in a useful way — it will surface where the real constraints were.
The honest gut check. If your team's velocity tripled tomorrow, would the company be in a meaningfully better position? Or would you just be shipping more of the same uncertain bets? The first answer says the bottleneck was execution. The second says it was direction. Agentic SDLC mostly fixes the first. It can't fix the second.
Pick one of the "conversations worth having" and have it with your team this week. Even casually, over lunch. The conversation matters more than the answer.
Audit your performance framework. Does it measure things agentic SDLC would inflate (lines of code, PRs shipped) or things it doesn't (outcomes, judgment, quality of others' work)? Adjust one metric.
Try the "watch them use an agent" interview round on your next candidate. Note what they do that you wouldn't have, and what they don't do that you would have. The signal is dense; the bar gets clearer with each repetition.
Next chapter: Tooling — the honest tour. What's good in 2026, what's overhyped, what's worth paying for, and how to evaluate a category-defining product before signing a contract.
Sign in to join the discussion and post comments.
Sign in