Skill Shift, Not Job Cuts: What Developers Report About Working With AI

In practice, AI replaces no developers. It shifts their work. The new core task is control, and almost no one has organised it.

A great deal gets written about AI and developer jobs, mostly on the basis of studies from economics, consulting and HR. Useful, but they talk about the people affected. We asked them directly: in a survey run by the Python Software Association Germany, the PyCon DE community reported how their working day is changing with AI, and whether it is changing at all. 383 responses from the front line, collected in early June 2026, predominantly from experienced developers in Germany. The result contradicts the headlines: jobs are not disappearing, tasks are shifting, towards a level of control and accountability that hardly anyone has organised.

At a Glance

• Using AI is routine: 96 percent reach for AI tools at least several times a day, and a good one in five automates more than half of their routine tasks. Even so, across more than 1,200 free-text responses, not a single person reports concrete job cuts caused by AI.
• The work does not disappear, it moves: 68 percent name reviewing and curating AI output as a new task. Only 9 percent say no significant new tasks have emerged.
• The skill shift has a clear direction: domain knowledge (60 percent), architecture (56 percent) and requirements communication (48 percent) are gaining value, while the typing moves to the machine.
• The real gap is organisational, and it sits between departments: 71 percent say accountability for AI-induced defects is not defined and in practice lands on the individual developer. Fewer than one in three respondents has any formal evaluation.

We Asked the Front Line Instead of Talking About It

Most numbers about the future of developer work come from economic models, analyst reports or HR surveys. They are useful, but they observe the people affected from the outside. This survey turns the perspective around and asks the people who put AI tools to productive use every day what is concretely changing in their work.

We deliberately asked where the change has travelled furthest: in an experienced, AI-fluent Python community. If you want to know where a profession is heading, you do not look at the average, you look at the leading edge. And that is exactly where the picture comes out sharper than the headlines suggest.

The New Work: Reviewing, Curating, Steering

The most robust finding of the survey is the counter-list to automation. Asked which tasks AI has created, 232 of 343 respondents (68 percent) name reviewing and curating AI output. Next come writing prompts and instructions (48 percent) and preparing context for the tools (38 percent). Only 30 respondents see no significant new tasks at all.

That dispatches the first cliché: AI does not make work disappear. Even at near-universal adoption, with 96 percent using AI at least several times a day and a quarter using it "almost continuously", substitution happens at the task level, not the job level. What gets delegated is boilerplate, tests, documentation, research, refactoring, prototypes. What remains is not less work, it is different work. Across more than 1,200 free-text responses, nobody reports concrete job cuts caused by AI, only 4 percent experience their work as devalued, and 45 respondents say their teams are actually short of conventional developers.

The second cliché falls with it: that AI relieves pressure. 67 percent describe their AI-intensive working days as denser, more demanding, or equally demanding at higher output. 6 percent feel noticeably relieved. The productivity dividend exists, but so far it does not arrive in the team as relief. It arrives as raised expectations.

Development work is turning into review work. Skip the planning for it and you still get it: unbudgeted, invisible, and paid for out of the substance.

Skill Shift: From Producer to Accountable Reviewer

Put what respondents hand to the machine next to what is gaining value, and the actual picture of this survey emerges:

One detail stands out: nearly half do prompting as a new activity, but only a third rate it as a skill that raises their value. The community ranks context and domain competence above prompt craft, which confirms the hiring logic of the "domain expert with an appetite for experimentation" that I described after PyCon DE & PyData 2026.

Three exemplary profiles emerge from the data, depending on the field of work. Data engineers shift furthest towards subject-matter depth and business translation. Web developers delegate the most code production and become architects of generated code. ML engineers, the group with the deepest AI usage, most often build what everyone else lacks: evals, context pipelines, agent control. The eval engineer role is forming right now, visible in the data before it appears in job ads.

Trust Is Growing Faster Than Control

The most uncomfortable finding cuts across both camps in the jobs debate. Trust in AI output has recently risen for 58 percent. The control structures have not grown with it: 89 percent check AI output by manual review, but only 30 percent have a formal eval pipeline. 14 percent say they mostly go on gut feel.

And the accountability question is open: 71 percent say that when an AI-induced bug appears, liability is not explicitly defined, and in practice it rests with the developer who accepted the code. 11 percent have a documented framework with mandatory review, sign-off and audit trail. That takes down the third cliché, the one that treats AI adoption as primarily a technology problem. Asked for the biggest bottlenecks, respondents do not name the tools. They name unclear responsibilities (40 percent) plus security, data protection and the EU AI Act (36 percent). Neither is an engineering question. Both are organisational, and both arise exactly where the executive level, engineering and compliance meet.

The 59 incidents described show what that means in practice: silently changed scope, hidden code duplicates, proposals to delete production data despite guardrails. One respondent captures the underlying pattern:

"It happens fairly often when generating code that package versions are simply invented […] If you trust that blindly, you quickly end up in a spiral of hallucinations and debugging in completely the wrong place." (translated from German)

This is where the circle closes: the new review work exists today as individual heroics. It only becomes durable as a system, as a harness of evals, audit trail and governed release, the same pattern I described through trust boundaries in Agents in Production. Take quality assurance seriously as a critical function and you cannot leave it to one person's instinct, and certainly not let it drain away at a departmental boundary.

Rethink, Don't Replicate

These numbers are not a loss report. They are a design task. AI is not a faster tool for the old way of working. Map existing, paper-driven processes one-for-one into AI systems and you multiply their weaknesses instead of fixing them. The Economist recently described the pattern using India as its example: digitisation that merely rebuilds the paper process creates no efficiency, it creates chaos. The same holds for AI, only faster and more expensive.

What AI Makes Possible

AI takes the routine off experienced professionals: almost half automate at least 30 percent of their routine tasks. That frees capacity for what is gaining value, namely domain knowledge, architecture and judgement. The role rises from producer to accountable designer. New functions emerge, such as the eval engineer who builds the control infrastructure everyone benefits from. Treat AI as the occasion to recut processes and accountability, and you gain more than speed.

What Has to Be Navigated

The downside is real, but manageable once you name it. So far the productivity does not arrive as relief, it arrives as denser days and higher expectations. Trust is growing faster than control. And the new review and accountability work falls through the gap between departments. None of this is a reason to slow down. Each of it is a reason to design deliberately instead of letting the old organisation simply run on. How harness, evaluation and governance fit together architecturally is something I brought into one frame in The New AI Architecture in 2026.

For Decision-Makers, This Means

First: Governance as a Cross-Cutting Function, Not a Silo

The biggest bottleneck is not the technology, it is unresolved ownership, and it runs between departments. The executive level expects pace, the teams carry the de facto liability (71 percent), security and compliance sit alongside. Durable AI usage needs a shared accountability model across those levels: mandatory review, sign-off and audit trail, jointly carried rather than delegated downwards.

Second: Budget Control Work as Real Work

The new reviewing, curating and steering tasks appear in no velocity plan, yet they are real in 68 percent of the responses. Fail to price them in and you pay for them in exhaustion and lost quality.

Third: Convert Review Load Into Eval Discipline

89 percent manual review against 30 percent formal evaluation is not a quality concept, it is a bottleneck you can see coming. The most valuable investment remains your own versioned eval set, owned by the person who owns the subject matter.

Fourth: Sharpen Profiles, Don't Cut Jobs

The data gives no reason to cut developer roles. It gives reason to sharpen profiles: domain knowledge, architectural judgement, eval competence. Respondents report demand for conventional developers, not their end.

What these four points have in common is not a tool. It is a question of organisation. The data shows precisely where internal structures hold and where they grind: at the seams between the executive level, developer and data teams, security and compliance.

That gap does not close from inside a single department. It requires translation in both directions, from strategy into engineering and back. That only works with people who are taken seriously at every level, from the executive floor to the developer team and everywhere in between. This is exactly where I work: I connect these levels, put what AI actually delivers into perspective, and turn the new control work into governance that holds up day to day. If you want to know where your own governance gap is widest, the Boardroom-to-Code Session is the structured way in.

AI does not replace developers. It demands that work and accountability be rethought, and that is where the real opportunity lies.