Teams and Skills in an AI-Native SDLC
When an agent writes the first draft, the job of an engineer changes shape, and so does the way a junior engineer becomes a senior one. This page covers how roles shift, how skills still get formed, how to interview and upskill, and the people-side mistakes that quietly undo an otherwise sound rollout.
How Roles Shift
The job titles stay the same. The work inside them moves. Authoring a first draft gets cheap; deciding what to build, judging whether the draft is right, and keeping the system coherent do not. The AI-native SDLC and the productivity paradox both point at the same bottleneck: the scarce resource is no longer typing, it is verified understanding.
Individual contributors
Spend less time authoring and more time specifying, reviewing, and verifying. A good specification names the behavior, the constraints, and the test that proves it. A good review reads the diff for intent, not just syntax.
Staff engineers
Own the things every agent run depends on: the instruction files, the rules, the context, and the evals that catch a silent regression. Their leverage is the shared environment, not their own commits.
Managers
Plan around review capacity, not coding capacity. Agents can open more pull requests than a team can read, so the honest throughput limit is the number of changes people can verify well in a week.
Skill Formation and Junior Engineers
Juniors have always learned by writing a lot of code, getting it wrong, and having it reviewed. If an agent writes the first draft, the first two steps can quietly disappear. The question for a team is not whether juniors use agents, but whether the work still forces them to build a mental model of the system.
The best direct evidence is a randomized controlled trial published by Anthropic on 01-29-2026 (Judy Hanwen Shen and Alex Tamkin). It assigned 52 mostly junior software engineers a task in an unfamiliar Python library, with or without an AI assistant, then quizzed them on the concepts. The assistant group averaged 50% on the quiz against 67% for the hand-coding group, with the largest gap on debugging questions, and the speed gain was small and not statistically significant. The authors also found that how people used the assistant mattered: participants who asked conceptual questions, or asked for explanations alongside code, kept more of the learning than those who delegated the code entirely. The sample was small and the quiz measured understanding right after the task, not long-term retention, so treat it as a strong signal rather than a settled law.
Broader surveys point the same way without measuring skill directly. DORA's 2025 report found that most developers use AI at work and that stability still lags throughput, and the Stack Overflow 2025 survey found the top frustration is output that is "almost right, but not quite." Fixing almost-right output takes exactly the understanding that is hardest to build while delegating. Both are summarized in the research library.
Practices that keep learning intact
Deliberate practice
Give juniors scoped work where they must reach a working design before asking the agent to write it. Ask for explanations and alternatives, not only code.
Explain-the-diff reviews
The author walks a reviewer through an agent-written change line by line, and answers why it works. If they cannot, the change is not ready, whoever typed it.
No-agent katas
A regular, short, agent-free exercise: debug a failing test, trace a request through the code, or write a small module by hand. It keeps the underlying skills warm, like a pilot's manual flying.
Pairing
Pair a junior with a senior on the specification and the review, the two places judgment shows. Pairing on the spec teaches more than pairing on the typing.
Interviewing When Candidates Use Agents
Start by stating the tool policy honestly, in the invitation and again in the room. Either allow agents and say so, or forbid them for a named segment and say why. A vague policy tests who guessed the rule, not who can do the job. If the day job uses agents, an interview that bans them measures a different skill than the one being hired for.
Then assess what stays valuable when drafts are cheap:
- Spec writing. Give an ambiguous request and watch which questions the candidate asks, which edge cases they name, and how they define done.
- Reviewing an AI-written diff. Hand over a plausible diff with a planted flaw, such as a missed authorization check or a test that asserts nothing, and see whether it is found.
- Debugging. Present a failing system and watch how the candidate forms and tests hypotheses, with or without an agent in the loop.
- Judgment. Ask when they would not use an agent, what they would never merge unread, and how they would verify an answer they cannot check by eye.
An Upskilling Plan
Training works when it follows the work. A four-stage plan fits most teams, and it lines up with the levels in the maturity model and the phases in the rollout playbook.
Foundations
How agents work, what context is, where they fail, and the team's safety rules. Short, hands-on, on the team's own repository.
Specify and verify
Writing specifications, tests first, and reading diffs for intent. Practiced on real tickets with a reviewer.
Context and evals
For senior engineers: maintain instruction files, build evals, and run the learn loop so lessons reach the shared setup.
Teach others
Practitioners run the next cohort. Teaching is the best check that a technique is understood, and it spreads working habits faster than a mandate.
Cognitive Load and Review Fatigue
Reading code you did not write, at the pace an agent produces it, is tiring work, and tired reviewers skim. The mechanism is described in reviewer fatigue: a rising volume of plausible changes lowers the depth of each review until defects pass through.
Treat this as a staffing and workflow problem, not a discipline problem. Cap the number of agent pull requests in flight per reviewer. Keep changes small so a review fits in one sitting (small batches). Route low-risk work through automated checks and save human attention for the changes that earn it (risk-tiered review). Rotate review duty so the same people do not carry it every week. The Scrum and Kanban page shows how work-in-progress limits do the same job at the board level.
Measuring Developer Experience
Adoption counts say nothing about whether the change is working for the people doing it. Pair system metrics with a short, regular developer survey: how confident are people in the code that ships, how often do they feel they are learning, how heavy is the review load, and where do the tools get in the way. Capture a baseline before rollout, as Measuring Impact explains, and compare cohorts rather than individuals. Report the results to the team that gave them, and act on at least one finding each quarter, or the survey becomes noise.
People Anti-Patterns
Cutting junior hiring
The tell: The plan assumes agents replace entry-level work. The cost: No one is growing into the senior reviewers the model depends on in five years. Keep the pipeline, and change what juniors practice.
Measuring people by AI usage
The tell: Dashboards rank engineers by prompts, tokens, or accepted suggestions. The cost: People optimize the number, not the outcome. This is reporting adoption as the outcome applied to individuals.
Mandating tools without training
The tell: A license arrives with an order to use it. The cost: Shadow habits, uneven results, and the familiar tool-first rollout without guardrails. Pair every rollout with the plan above and the governance basics.
Where It Fits in AIDLC
People work runs through every phase. In Analyze and Ideate, specification skill is the main lever. In Develop, review capacity and learning-preserving practice decide whether speed turns into quality. In Launch, the verification habit decides what ships. In Curate, the survey and the learn loop turn experience into better rules. For a concrete walk through the phases, see the worked example; for the contrast with classical ML teams, see AIDLC vs the ML lifecycle. Older systems raise their own team questions, covered in AIDLC on Legacy Code.
Frequently Asked Questions
They can, depending on how they are used. In a randomized trial published by Anthropic on 01-29-2026, 52 mostly junior engineers learned an unfamiliar library with or without an assistant. The assistant group scored 50% on a follow-up quiz against 67% for the hand-coding group, and participants who asked conceptual questions kept more of the learning than those who delegated the code. The sample was small and measured short-term understanding, so teams should treat it as a reason to design learning in, not to ban the tools.
State the policy plainly up front, and match it to the job. If the role uses agents daily, allow them and assess what remains valuable: writing a specification from an ambiguous request, finding the flaw in an AI-written diff, debugging a failing system, and explaining when not to trust the output. If a segment forbids agents, say why, so the exercise tests a named skill instead of a guessed rule.
Capture a baseline before rollout, then pair delivery and quality metrics with a short recurring survey on confidence in shipped code, review load, learning, and tool friction. Compare cohorts rather than individuals, never rank people by AI usage, and act visibly on at least one finding each quarter so the survey stays worth answering.
Build the Team Around the Method
Tools change quarterly; the habits of specifying, reviewing, and verifying carry over. Start with the review layer, then the learning plan.