Developer, project manager, recruiter, business manager: four roles to reinvent now

AI doesn't transform every role the same way. For the developer, the shift toward generation, review and orchestration is already documented. For the recruiter, automation clearly touches sourcing and initial screening, without removing human accountability. For the project manager and the Business Manager, the shift is less measured: it's mostly inferred from the transformation of delivery and services companies' business model.

This is precisely why the "jobs of the future" catalogue should be avoided. The point isn't relabelling four functions. It's understanding which part of their value is becoming less scarce, what new accountability appears, and how to keep training competent professionals once AI takes over part of the work that used to teach them their craft.

In brief

• •The developer is gradually shifting from pure code production toward specification, orchestration, review, and accountability for the product's behaviour.
• •The project manager loses part of their administrative-coordination value once reporting, meeting minutes, and tracking become automatable. Their value moves up toward trade-off calls, delivery-system quality, and decision management.
• •The recruiter can delegate more sourcing, matching and prep work, but becomes all the more accountable for evaluation quality, bias, understanding potential, and the candidate experience.
• •The Business Manager is probably the one whose transformation is least documented, and yet one of the most structural for IT services firms: when production needs fewer days, mainly selling profiles and day rates becomes insufficient. They need to learn to sell a capacity, a proof, an asset, or an outcome.
• •In all four cases, the same shift appears: less value in standard execution, more in context, judgment, verification, and accountability. But this shift is neither uniform nor irreversible.

Reinventing a role doesn't mean erasing its title

Across a body of thirty companies selected for their organisational signals, 35 roles transformed or renamed and 29 new roles were counted in the context of the AI shift: the engineer turned agent orchestrator, the tech lead turned orchestrator, ops refocused on exceptions, or the augmented recruiter. But the sample isn't representative of the market, and titles vary widely from one company to the next.

The counter-example is instructive. At Lucca, six-to-eight-person teams stay structured much like before: AI is added to the work with no fundamental organisational overhaul. At Pennylane, AI blocks neither headcount growth nor strengthening domain expertise.

In other words, a role's transformation can precede the org chart's transformation, and sometimes never produce a new title at all.

This is also what the French IT services market's climate suggests. In July 2026, Numeum and Xerfi put the French IT services market at €34.6 billion, growing slightly at 1%. 58% of the firms surveyed say they're repositioning through automation and AI. AI-linked productivity gains are estimated in the study at 15% in 2025 and 22.3% in 2027, but Numeum stresses they remain hard to convert into margin.

It's in this gap, between technical productivity and organisational value creation, that the reinvention of these four roles plays out.

Developer: from code produced to behaviour guaranteed

This is the role for which the signals are, today, the most solid.

Anthropic, Doctolib, Stripe, Dust, Fleet and bsport all show, in different forms, a shift of work toward supervision and review. At Doctolib, the 600 engineers moved to agentic-first working in January 2026 after a year of pilots. Some orchestrate several agents in parallel. At Dust, the company said in early 2026 that around 70% of its code was written by agents, with large variation between engineers. At Fleet, its leader describes developers as "managers of an AI".

Gartner frames the same direction as a forecast, not an established fact: the firm estimates 90% of enterprise software engineers will use code assistants by 2028, and anticipates a shift from implementation toward orchestration, problem-solving, and system design.

But the shortcut "AI = more productive developer" remains dangerous. DORA concludes in its 2025 report that AI acts, first and foremost, as an amplifier of the existing system: it strengthens a well-structured organisation's qualities, but can just as well amplify its dysfunctions.

METR offers an even clearer counter-example. In a randomised experiment run in early 2025 among 16 experienced open-source developers completing 246 tasks on repositories they knew well, the developers given AI tools took 19% longer. METR explicitly states this result doesn't let us conclude AI slows down most developers. In February 2026, the organisation, in fact, considered it likely newer tools deliver larger gains, while judging its newer data too biased to properly quantify that progress.

What this proves: a growing share of code production can be delegated in certain mature environments.

What this doesn't prove: that producing more code equals producing more value, or that every developer saves the same amount of time.

The skills that gain value

A good augmented developer isn't simply the one who masters the latest generation tool. They need to get better at what AI can't work out on its own: architecture, domain knowledge, non-functional requirements, security, observability, tests, trade-offs, and understanding the whole system.

This shift can be framed as a move from producer to supervisor. In several cases, the new bottleneck becomes the quality of specs, evals, and review — a phenomenon especially well documented at organisations with a strong engineering culture, which can't be generalised as-is.

The metrics that need to evolve

A developer shouldn't be evaluated on the volume of code generated, or on how many agents they can run in parallel.

The useful metrics shift toward lead time to production, defects that escape into production, the rework rate, review time, the quality and coverage of tests and evals, the change failure rate, the ability to explain architecture choices, and the total cost of production and operations.

One possible path

0 to 3 months: learn to use AI without losing understanding of the code produced; check every significant change.

3 to 6 months: write better specs, acceptance criteria and tests before delegating.

6 to 12 months: become the owner of an entire flow, from request to deployment and observability, rather than a mere code producer.

Beyond that: specialise in architecture, reliability, security, the business domain, the platform, or orchestrating hybrid systems.

Seniority can no longer be equated with the number of lines someone can produce unaided, but it can't be reduced to blindly delegating to a machine, either.

Project manager: from work coordinator to delivery-system architect

For the project manager, methodological caution matters more: we have far less data establishing the emergence of a "new role" than for the developer.

The transformation here is mostly inferred.

A significant share of coordination work can already be automated or heavily assisted: summarising meetings, preparing minutes, consolidating status reports, updating documents, detecting dependencies, preparing certain action plans, searching for information within projects.

Consulting's general shift from production toward orchestration comes with a specific twist: with agentic AI, first-draft deliverables can arrive in one block, which changes the moment when critical thinking needs to be applied — hence the need to specifically train project managers who oversee junior professionals using AI.

Doctolib supplies another piece of the puzzle: the company made explicit which decisions the PM has to keep and which product builders can make when the decision is easily reversible. This isn't a generally applicable project-management model, but it shows automation forces decision rights to be formalised more.

The project manager doesn't disappear once coordination becomes automatable; they mainly lose value when they limit themselves to being the human layer carrying information between other people.

If an agent can collect statuses, flag a delay, and write the minutes, the human role needs to move up toward the questions the system can't answer alone: why is the project genuinely stuck? Which dependency should be eliminated rather than tracked? Which decision is needlessly waiting on three approvals? Which sales promise is incompatible with delivery's reality? Which risk needs escalating to the executive level? Which agent-generated output absolutely must not go into production?

The term "Agentic Delivery Manager" is sometimes used to describe this shift. It should be read as a forward-looking model, not a role already established on the market.

The new skills

The augmented project manager needs to understand AI well enough to know where it can act, but their edge probably won't lie in prompting.

They mainly need to improve at breaking a process down into tasks, decisions and exceptions; defining acceptance criteria; clarifying accountability; measuring a baseline and a result; managing agent-related risk; leading change; challenging technical delivery; and facilitating hard trade-offs.

The new metrics

The number of ceremonies held or how fresh the reporting is should count for less than time-to-first-value, the lag between a problem appearing and a decision, the age of blockers, the number of unnecessary handoffs, the rework rate, the exception rate, delivery stability, and how much of what's delivered actually gets adopted.

One possible path

0 to 3 months: automate your own administrative work while documenting what still deserves human intervention.

3 to 6 months: map a whole process, distinguishing production, decisions, verification and accountability.

6 to 12 months: run a project where humans' and agents' decision rights are explicit and success is measured by something other than schedule adherence.

The significant transformation, then, may not be "project manager → agent manager". It's more demanding than that: project manager → owner of the quality of the system that makes humans, technology and organisation work together.

Recruiter: from matching to judging potential

Recruiting is an interesting case because the line between what gets automated and what has to stay human is more visible.

At Fleet, an agent can screen around 200 LinkedIn profiles against a scorecard before a human steps in. At Lucca, AI matches a job spec's criteria against the elements of a CV, while the recruiter stays the decision-maker at every step.

Lucca now publicly describes its approach the same way: CV matching speeds up the screening, but the company recommends systematically topping the selection off with a human conversation, and stresses the quality of the criteria used.

These cases don't establish that every recruiter has to work this way. They do show, though, that part of the work that used to justify a lot of time — finding, comparing, summarising, ranking — can be heavily compressed.

The paradox, then, is obvious. The easier matching gets, the less matching can be the recruiter's differentiating value.

But the job doesn't reduce to comparing two lists of keywords. You still need to understand why a seemingly unrelated background could turn out relevant, spot potential, test motivation, understand the context behind someone leaving a job, gauge the ability to learn, win a candidate over, and help a manager clarify what they're actually looking for.

AI can even make this dimension more important: if everyone has similar tools for identifying the same profiles, the real edge shifts toward the ability to evaluate what the CV doesn't show.

The most important skill may become defining the need

A matching AI doesn't fix a bad scorecard. It executes it faster.

This is probably one of the most transferable lessons: when production gets very fast, input quality becomes more important.

The recruiter, then, needs to be able to challenge a request like "I want five years of experience with this technology", tell an essential skill apart from a learnable one, and understand the real role expected behind a title.

They become less a search operator than a designer of the evaluation process.

What to measure?

Time-to-hire remains useful, but becomes dangerous if it overrides hire quality a few months in, time-to-autonomy, retention, internal mobility, candidate-experience quality, assessment-method performance, and the diversity of the backgrounds actually hired.

A new type of interview

One reasonable consequence of this shift in roles is testing collaboration with AI itself more directly.

For a role that will use agents daily, a simulation could ask the candidate to work with an AI on a real problem, then explain what they delegated, what they checked, which errors they caught, what they refused to follow, and which decision they ultimately own.

This format remains a proposal, not a practice that's become standard. Its value is shifting the evaluation from tool mastery toward judgment in an augmented environment.

Business Manager: from placing resources to architecting value

This is probably the most important profile for IT services firms, and the one where facts and inference most need to be clearly told apart.

We don't have a study proving the Business Manager role is already becoming a "value architect". What is moving, though, are the economic conditions that used to justify part of the traditional role.

Numeum reports in June 2026 that day-rate staff augmentation is "increasingly challenged" by capacity, outcome, or shared-gain engagements. This publication is a summary of a forum bringing together around sixty sector leaders, not a representative study: it's a market signal, then, not proof that staff augmentation is disappearing.

A comparable tension exists in consulting: when AI reduces the effort certain output requires, value increasingly needs to be justified by impact, assets, judgment, or ongoing operation, rather than by the number of hours consumed.

The most cautious conclusion is that the day rate can stay a relevant contractual unit in many contexts, but becomes insufficient as the sole justification of value when a heavily automatable engagement needs significantly fewer days.

What this changes for sales

The Business Manager whose value mainly rests on three capabilities — landing a need, finding a CV, negotiating a day rate — is mechanically exposed once matching becomes automatable, the client itself has more information, an augmented team can deliver more with fewer days, and offers blend humans, agents, licences, usage, and recurring services.

The sales job then becomes harder, not simpler.

You need to be able to explain why a client should buy a modernisation capacity rather than four developers, how value will be measured, what risk is transferred to the provider, what responsibilities stay with the client, and what technology costs genuinely factor into the margin.

The Business Manager needs to understand production better

This is probably the deepest change.

Selling a human-plus-agent system with no understanding of how it works exposes the IT services firm to two opposite mistakes: promising unrealistic productivity, or handing the client the entire gain with no idea how to rebuild the margin.

Sales, then, needs to understand at minimum which work is genuinely automatable, where human review still applies, how quality is measured, what a baseline is, how much models, licences and operations cost, how a capacity or outcome engagement works, which client dependencies make a result hard to guarantee, and which assets stay the IT services firm's property.

The Business Manager, then, becomes less a seller of a quantity of work than the designer of a value-creation contract.

The metrics need to follow

If the company keeps paying its salespeople mainly on the volume of days placed, it will struggle to also ask them to sell smaller teams, assets, or subscriptions.

Over time, it becomes relevant to add to revenue and margin the share of recurring revenue, renewals, margin after AI and licensing costs, reusable-asset usage, account expansion, pilot-to-contract conversion, and the value actually delivered wherever it can be measured.

Four roles, one common transformation: accountability moves upstream

The cross-cutting reading reveals a more interesting shift than the debate over job cuts.

AI doesn't primarily eliminate these four roles. It attacks the part of each one that consisted of producing, coordinating, or matching standard information. Value moves up toward whoever defines the context, checks quality, settles the exceptions, and owns the result.

This thesis still needs challenging.

Why this thesis can be too simple

Not every organisation transforms. Lucca illustrates AI adoption with no fundamental team overhaul. Pennylane keeps hiring heavily and puts accounting expertise at the core of its product. Installing AI, then, doesn't automatically produce new roles.

Productivity gains are highly variable. DORA suggests reasoning about the organisational system rather than the isolated tool, while METR shows an AI tool can even slow certain developers down in certain contexts. It would be unwise, then, to rebuild an organisation on the fixed assumption of "30% extra productivity".

Some standard activities remain necessary for learning. A task can become economically automatable while staying pedagogically useful. This matters especially for developers and recruiters: if a junior no longer reads simple code, or never runs an initial screening again, how do they build the mental models that will let them later catch a bad AI answer? Experienced professionals hold reference points for spotting certain errors that younger ones haven't yet acquired.

Reinventing doesn't mean generalising. A developer on critical legacy systems won't evolve at the same pace as an engineer at an AI-native startup. An executive recruiter doesn't do the same job as a Talent Acquisition team handling thousands of applications. A Business Manager selling rare cyber expertise doesn't face the same problem as a salesperson placing standard developers on staff augmentation.

The right unit of transformation, then, isn't the role as a whole: it's the portfolio of tasks, decisions and responsibilities inside the role.

Self-diagnostic: is your role genuinely being reinvented?

For each of your key roles, answer the following twelve questions.

• •Have we precisely identified the tasks whose volume is shrinking with AI?
• •Do we know which tasks stay necessary for learning the job, even if they could be automated?
• •Have we defined what AI can produce alone, what a human needs to check, and what a human needs to decide?
• •Do our current metrics still reward an activity that's become largely automatable?
• •Have we identified the new skills genuinely needed, beyond mere "AI proficiency"?
• •Do our managers know how to evaluate the quality of work produced with an agent?
• •Can a junior still acquire the reference points needed to become a senior?
• •Do our career paths still match how the work actually gets done?
• •Does our hiring test judgment and learning ability, or mainly the role's traditional knowledge?
• •Do our salespeople understand the new delivery well enough to sell something other than resources and time?
• •Do we have a baseline that lets us verify AI genuinely improves lead time, quality, or total cost?
• •Could we simply explain to an employee what will make up their value in three years if half of their current tasks change?

If you answer "no" to more than four questions, the issue probably isn't adding a few AI training sessions anymore. It becomes necessary to revisit the role's very design: tasks, accountability, performance measurement, learning, and career trajectory.

In closing

Developer, project manager, recruiter and Business Manager aren't four doomed roles. They're four roles whose most repeatable part is becoming less sufficient to justify their value.

For the developer, the shift is already strongly visible. For the recruiter, it's taking clear shape around matching and evaluation. For the project manager and the Business Manager, it's still more of an organisational hypothesis: if delivery and sales models genuinely change, their responsibilities will have to change with them.

The risk would be waiting for job titles to change before starting to act.

Organisations are better served rebuilding tasks, metrics and career paths now, while accepting some of these hypotheses will need correcting as more data accumulates.

Optimising each link in the chain separately — the Business Manager who promises, the project manager who organises, the developer who produces and guarantees, the recruiter who builds human capacity — can produce a paradoxical organisation: highly efficient at delivering today, but unable to sell differently, control what it produces, or build its future experts. Successful transformation, then, isn't the one that automates the most tasks. It's the one that redesigns work, skills, metrics and learning paths all at once.