Traditional roles: dev, QA, PM

The traditional engineering team organizes work into three primary roles: developers who write code, QA engineers who test it, and product managers who translate business requireme

·Traditional roles (developer, QA, PM) with no AI-specific responsibilities
·Senior developers spend significant time debugging AI-generated code

·Team is open to experimenting with AI-assisted workflows
·At least one person informally champions AI tool usage

Evidence

·Job descriptions showing traditional role definitions
·Code review comments showing seniors correcting AI-generated patterns

What It Is

The traditional engineering team organizes work into three primary roles: developers who write code, QA engineers who test it, and product managers who translate business requirements into specifications. Each role has a clear scope, a distinct skill set, and a handoff protocol to the next. Developers own implementation. QA owns quality assurance and sign-off. PMs own the backlog and requirements. This structure evolved over decades and works reliably at low-to-medium AI adoption.

The handoff model is the defining characteristic of traditional role structure. Developers receive a spec from PM, implement it, and hand it to QA. QA validates against requirements and returns bugs to developers. This linear flow creates predictability but also creates queues. Work waits at each handoff point, and the bottleneck shifts between roles depending on team composition and sprint load.

Within this structure, individual experience is the primary productivity variable. Senior developers are faster and make fewer mistakes than junior developers. Experienced QA engineers find more bugs than new ones. Strong PMs write clearer specs. The organization invests in hiring, mentorship, and career growth as the main levers for improving output. AI tools, if used at all, are informal and individual - a developer using GitHub Copilot autocomplete here, a PM using ChatGPT to draft a spec there.

The critical limitation of traditional role structure in an AI-enabled world is not that the roles are wrong - it's that they were designed for human-speed, human-scale work. When AI agents can write code, run tests, and generate documentation, the handoff model becomes a constraint rather than a structure. QA becomes a bottleneck when developers can generate ten times the code volume. PMs become translators in a world where requirements can be directly fed to agents. The roles don't disappear, but their scope and proportion must change fundamentally.

Why It Matters

Understanding traditional role structure is the baseline for measuring and planning AI adoption progress:

Identifies what will change - the three-role model predicts exactly where AI will create pressure: developer output rises first, then QA capacity becomes the bottleneck, then PM bandwidth for spec quality becomes the constraint
Sets the baseline for productivity measurement - before AI tooling, teams have well-understood velocity metrics per role; this baseline makes AI productivity gains measurable rather than anecdotal
Explains resistance patterns - QA engineers resist AI-assisted testing because it changes their value proposition; PMs resist agent-readable specs because they require different communication skills; understanding the traditional role makes the resistance understandable and addressable
Defines the transition path - you cannot skip from traditional roles directly to L4 or L5 team structures; the maturity path goes through champion, context engineer, and platform engineer before reaching agentic engineer
Anchors hiring and career conversations - developers joining a team in L1 role structure need to understand that their job description will evolve; organizations that don't acknowledge this lose people who want to grow faster than the org is moving

Getting Started

Document your current role structure explicitly - map who does what today: who writes code, who writes tests, who reviews PRs, who manages requirements, who maintains CI/CD. This is your L1 baseline. Most teams have never written this down clearly.
Measure per-role throughput - how many story points does each developer produce per sprint? How long does QA take per ticket? How many back-and-forths happen between PM and dev on requirements? These baselines make future AI impact measurable.
Identify the first pressure point - in most teams, developer velocity rises first when AI tools are introduced, which creates pressure on QA capacity. Identify who will become the bottleneck when developer output increases 30-50%.
Survey informal AI tool use - ask your team what AI tools they already use individually. Most L1 teams have 20-40% of developers using some form of AI autocomplete informally. Inventory this before formalizing.
Brief HR and hiring managers - the traditional job description for "software developer" doesn't include AI agent supervision skills. Flag that job descriptions, leveling criteria, and interview processes will need to evolve as the team moves up the maturity curve.
Create a role evolution roadmap - sketch what each traditional role looks like at L2, L3, and L4. QA at L4 is not "runs more tests" - it's "designs test strategies for agent-generated code." PM at L4 is not "writes more specs" - it's "writes agent-readable requirement structures." Make this concrete and share it with the team.

Tip

Don't position traditional role structure as "wrong" or "outdated" when communicating internally. Position it as "the foundation we're building on." Teams that feel their existing skills are being discarded resist change. Teams that feel their existing skills are being extended embrace it.

6 steps to get from here to the next level

Common Pitfalls

Assuming roles are fixed. The biggest mistake at L1 is treating traditional role structure as permanent. QA engineers who are not introduced to AI-assisted testing early enough will find their skills depreciating faster than they can adapt. The time to begin role evolution conversations is at L1, not L3 when the gap is already painful.

Measuring only developer productivity. When AI tools are introduced and developer output rises, organizations often celebrate the productivity gain without noticing that QA has become a bottleneck. The traditional role structure creates a natural imbalance when only one role is augmented. Measure the full pipeline, not just the first stage.

Underestimating PM's role in AI readiness. Product managers who write vague, conversational requirements create problems at every maturity level - but the problem becomes acute when agents need to act on requirements. PM is often overlooked in AI tooling discussions because "they don't write code." In practice, PM spec quality is one of the most important variables in agent effectiveness.

Letting AI adoption be developer-only. When only developers adopt AI tools and QA and PM remain in traditional mode, you create role tension. Developers feel slowed down by QA queues. QA feels overwhelmed by increased code volume. PM feels disconnected from a faster development process. Adoption needs to be coordinated across all three traditional roles, even if the first tools are developer-focused.

Missing the culture signal. Traditional role structure embeds specific assumptions about who is responsible for quality (QA) and who is responsible for requirements (PM). When AI agents start producing code, these assumptions get challenged: who is responsible for agent-generated code quality? Who is responsible for the quality of agent instructions? These are culture questions that need explicit answers, not just process changes.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob runs a team of twelve: eight developers, two QA engineers, and works closely with two PMs. The team delivers consistently but velocity has been flat for two years. He's heard that AI tools can improve productivity but hasn't made any formal moves yet - a few developers use Copilot individually but it's not standardized or measured.

What Bob should do: Bob should start by documenting the current state with precision: draw the actual workflow map, measure the actual cycle times, and inventory the informal AI tool use. This is not a bureaucratic exercise - it's the baseline that will let Bob demonstrate concrete improvement when AI adoption begins. The documentation exercise itself often surfaces inefficiencies: requirements that get revised three times between PM and dev, QA sign-off that takes 48 hours because of queue management rather than actual testing time. Bob should share the baseline with his team and frame the next six months as "let's figure out where AI tools can improve each of these specific pain points." This is more compelling than "we're going to adopt AI" - it's a concrete problem-solving exercise with measurable outcomes.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah has been asked to lead the AI tooling initiative for the engineering organization. She's looking at a landscape of 40 developers, 8 QA engineers, and 6 PMs across four teams - all operating in traditional role structure with ad-hoc AI use. She needs to create a transition plan that doesn't create role anxiety or organizational disruption.

What Sarah should do: Sarah should run a role impact assessment before recommending any tooling. For each traditional role, map: what will AI tools change about this job in the next 12 months? What new skills will be needed? What existing skills become less central? Present this to each role group honestly - QA engineers need to know that AI-assisted testing will change their job, not eliminate it, but the nature of the work shifts from manual test execution to test strategy and agent supervision. PMs need to know that writing agent-readable requirements is a skill they'll need to develop. Sarah should build the transition plan around skill development paths, not just tool adoption targets. This frames AI adoption as a growth opportunity for every role rather than a threat to some roles.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor is one of the eight developers on Bob's team. He has been using GitHub Copilot and Claude for six months and has a clear sense of what works and what doesn't. He's seen his individual productivity increase but also feels frustrated that the QA queue and vague PM specs limit how much of that productivity actually reaches production.

What Victor should do: Victor should make the system bottleneck visible. He should track his own cycle time carefully: how long does he spend implementing? How long does the PR sit waiting for QA? How many clarification rounds does he have with PM per ticket? This data, presented to Bob, makes the case for expanding AI adoption beyond just developer tools. It also frames Victor as a thoughtful systems thinker rather than a developer who just wants faster tools. Victor is positioned to become the AI champion (L2) precisely because he can see the full pipeline, not just his own slice of it.

What Victor should do - role-specific action plan