# Don't Rush to Give Agents Job Titles: Role Inertia in AI4SE Transformation

The Whiteboard Barely Gets Wiped Before the Job Titles Come Back

There’s a scene that plays out in almost every AI4SE workshop: the whiteboard has barely been wiped clean when someone raises a hand —

“So what does Dev still do? What about QA? What about EA? Does the Agent count as a third role?”

The motivation is usually good — people want to discuss how humans and AI can collaborate anew. The problem isn’t the intent, it’s the coordinate system: the discussion gets pulled straight back onto the old role-driven track. On the surface it’s about transformation; underneath, the question is still: how do we squeeze a bit of AI into each box on the old org chart?

This isn’t caution — it’s inertia. And inertia is very good at disguising itself as “pragmatism,” since redrawing a responsibility chart looks like “getting things done,” while rethinking collaboration end-to-end looks like “abstract theorizing.” Unfortunately, this wave of AI most often needs the latter.

Why Role-Driven Thinking Narrows Transformation

Role-driven transformation quietly narrows “redesigning collaboration” down to “how do old roles adapt to AI.” This has three consequences.

The field of view gets fragmented. Everyone thinks about “how do I use AI” from their own role’s vantage point: Dev thinks about completion and generation, QA thinks about automated testing, EA thinks about drawing architecture diagrams. Each part is reasonable, but the globally optimal solution never emerges — because no one is encouraged to think end-to-end. The team ends up discussing “how does my role change,” not “where in the delivery chain should a human hold the line, and where should an Agent push forward.”

The Agent gets demoted to “a third role.” Once it’s pinned down as “the one who writes code,” exploration, decomposition, acceptance, and cross-domain judgment get switched off in advance. A Coding Agent’s most valuable capability is often not any single line of completion, but its ability to switch between multiple working modes; pinning it to a job title first is like putting a blindfold on it before it starts. Worse, once it has a job title, people start evaluating it against that job’s KPIs — “how many lines did it write” — instead of asking “did it help the team reduce uncertainty.”

The old design becomes the ceiling. AI then becomes only an accelerator, not a restructuring force: however the work used to be divided, it just gets divided faster now. The effectiveness of the process is still bounded by the original RACI matrix and role walls — no matter how strong the model gets, it’s just running laps on the old design. DORA says AI is an amplifier; what an amplifier amplifies also includes whatever wasn’t good enough in your original collaboration design.

In one line: the tool changed, but the coordinate system didn’t.

Switching Coordinate Systems: The Expert Generalist

The Expert Generalist concept, proposed by Martin Fowler and others, speaks directly to this: the most effective colleagues are rarely narrow specialists pushed to the extreme, but people who can cross specialties, master fundamentals, learn quickly, and collaborate across domains. Specialization still has value; but “only being good at your own corner” is becoming a risk — especially now that LLMs can fill in a large amount of surface-level expertise, and what’s genuinely scarce is cross-domain judgment and learning speed.

Applied to AI4SE, the question can be rephrased as:

• For humans: ask less “how should we rewrite Dev’s job description,” and ask more “can this person switch perspectives across planning, implementation, and verification”
• For Coding Agents: don’t assign them a job title based on traditional development functions; they too should be designed as capability entities that can take part in many kinds of work, not “an intern who only knows how to write code”

This “full-role capability” doesn’t mean requiring every person and every Agent to do everything at once — that would be chaos, not integration. What’s actually needed is: the ability to switch, not locked in by a job label. Humans can go deep in one area but should be able to think across boundaries; Agents can be great at generation, but shouldn’t be designed to be barred from exploration and helping with acceptance. The curiosity, collaboration, customer focus, and preference for fundamentals that Fowler emphasizes apply equally to how we design “capability” for humans and for Agents: the constraints, tools, and context you give it determine whether it stays a narrow tool or becomes a genuine collaborator.

Only when both humans and Agents are cultivated and designed as Expert Generalists does the end-to-end process have a chance at a truly global optimum. Otherwise, the outcome first gets discounted by the old role design, and then AI “efficiently” amplifies that very discount.

Two Different “Roles” — Don’t Conflate Them

At this point, it’s important to reconcile this with another line of thinking on this site — otherwise readers might think we’re contradicting Planner / Generator / Evaluator.

	Job Roles (to be wary of)	Process Responsibilities (to be preserved)
Examples	Dev / QA / EA / “the Agent role”	Planner / Generator / Evaluator
Risk	Designing new human-machine collaboration with an old org chart	The same party both generates and self-evaluates, lacking an independent perspective
Correct usage	Break down role walls, cultivate Expert Generalists	Separate planning, generation, and acceptance by risk and evidence

What’s being opposed is “pinning humans and Agents to fixed job titles” — not “separating the responsibilities of planning, generation, and acceptance.”

The former is organizational inertia; the latter is engineering discipline. The Expert Generalist addresses “can everyone switch perspectives”; the three-role pattern addresses “within a single delivery, the key responsibilities must not blur into one.” The two aren’t in conflict — they’re constraints at different layers: capability should be integrated, responsibility should be clear; accountability still stays with humans, and that doesn’t change just because Agents get stronger.

Fewer “Role-Defining” Meetings, More “Handoff” Meetings

For managers driving transformation — and the frontline staff who get pulled into these workshops — here are three suggestions you can act on immediately:

1. Run fewer “role redefinition” workshops, and more workshops on “how humans and Agents hand off within an end-to-end scenario.” Change the whiteboard title from “New Responsibilities for Dev/QA/EA” to “How does evidence get handed off, from intent to a mergeable change.” The job chart can be filled in later; get the collaboration pipeline working first.
2. When evaluating humans and Agents, look at their ability to switch perspectives and their fundamentals — not whether their job titles are neatly aligned. Being able to read a Spec, break down tasks, verify results, and explain trade-offs is worth more than “title alignment.” Frontline staff can also ask themselves: am I guarding a job title, or guarding delivery quality?
3. Design capability toward integration; design accountability toward humans. Agents can take part in more steps; but responsibility for merges, releases, and incidents still rests with humans — consistent with the first principle of Agent Governance.

What AI4SE needs isn’t a prettier org chart, but a group of people — and a group of Coding Agents not pinned to fixed job titles — who can think about problems holistically as Expert Generalists. Otherwise, even the most advanced model is just running a little faster on the same old design.