Jupp Stüger

article

The Deskilling Problem

How AI-assisted software development can erode the reasoning, diagnostic, and epistemic capabilities on which engineering depends.

AI-assisted software development deteriorates engineering capability.

The problem at the heart of this statement predates generative AI. In 1983, Lisanne Bainbridge described the irony of automation: as systems automate routine operation, humans become less involved in normal work but more important during failures, precisely when hands-on experience matters most. Software development may now face the same paradox. The risk here is not that developers forget syntax. It is that we redesign development so that humans stop performing the cognitive work - investigation, modelling, diagnosis and judgement - through which engineering expertise is built and maintained. AI can remove enormous amounts of low-value effort. But it can also remove the experience that makes engineers capable of understanding and recovering the systems they are responsible for.

Using AI more is therefore not necessarily the problem. What matters is which parts of the cognitive process it replaces.

Scenario

Let us consider an eight-person team maintaining a mature B2B application. Java, React, PostgreSQL, several integrations, incomplete documentation and years of accumulated business rules. A developer receives a requirement:

Allow a customer account to have several billing contacts while preserving the existing invoicing workflow.

Without an agent, the developer themselves would have to trace the existing model, invoicing flow, database constraints, integrations and implicit assumptions before deciding what to change. With a capable coding agent, the workflow can become:

Requirement → agent investigates → agent proposes design → agent implements → agent writes tests → developer reviews → merge

Nothing here is necessarily irresponsible. The software may even be good. But something has changed. The developer receives a mental model rather than constructing one. Understanding an explanation is not the same cognitive activity as constructing understanding from evidence.

Risks

Bainbridge’s insight was that automation changes the human role and can remove the very experience people later need when automation reaches its limits. In software development, automation creates two related risks.

Distance from the system

Developers search, trace, experiment and encounter surprises less often. An agent increasingly answers: “Why does the system behave this way?” before the developer has constructed the model themselves. Repeated across hundreds of changes, this creates structural distance between engineers and the system they own.

This distance is not unique to AI. Engineers inheriting an unfamiliar system already face it and may need substantial time to read, trace, draw, ask questions and revise their understanding before they can safely change it. The additional risk with AI is that it can make it easier to act before that distance has actually been closed.

Review-capacity overload

AI can generate change much faster than humans can meaningfully comprehend it. A team’s available attention does not scale just because code generation does. Without deliberate limits, the rate of change can outpace the team’s capacity to understand it. Review then shifts from “I understand why this works” to “The tests pass” and eventually to “The agent says it is covered.” Human review still exists procedurally, but its epistemic purpose has weakened.

A human review is only a meaningful safeguard if the reviewer has enough of a system model to judge the change in the first place.

Emerging research already describes a shift towards supervisory engineering work: directing, evaluating and correcting AI-generated output rather than creating it directly (Vella & Blincoe, 2026).

Types of deskilling

Not all deskilling matters equally. Mechanical deskilling, remembering fewer commands, APIs or pieces of syntax, is usually not all that important. Procedural deskilling, less practice with debuggers, SQL, logs and development tools, matters some, but procedure is not reasoning. Reasoning deskilling, less practice decomposing problems, modelling domains, forming hypotheses and establishing causality, is serious. Epistemic deskilling, losing the ability to answer “How do we know this is correct?” and replacing it with “Does this look plausible?”, is the critical one. Plausibility is one of generative AI’s strongest properties. Research on automation bias shows that even experts can over-trust automated recommendations, while a CHI 2025 study found greater confidence in generative AI associated with less reported critical-thinking effort (Parasuraman & Manzey, 2010; Lee et al., 2025).

Scenario

Let us return to the billing system. Several years of AI-assisted development have passed. Then an intermittent invoicing failure appears involving asynchronous events, caching, retries and an old integration. The agent offers several plausible explanations. Generating hypotheses is easy. Establishing which explanation corresponds to reality requires reconstructing system behaviour from incomplete evidence, finding contradictions and designing experiments that distinguish one explanation from another. This is exactly where deskilling becomes operationally dangerous: the team’s competence has become conditional on the AI being right.

And, increasingly, on the AI being available. If the team can no longer investigate independently, an outage, licensing issue, policy change or vendor restriction becomes more than a tooling inconvenience; it becomes an engineering capability problem.

And there are two ways that capability can disappear. A senior engineer with fifteen years of experience already has a reservoir of broken deployments, bad abstractions, race conditions and integration failures to draw upon. AI can initially make that engineer extraordinarily effective because they recognise when generated output smells wrong. But expertise is not permanent capital. Skills that are rarely exercised can become less fluent. A junior developer faces the opposite problem. If their normal experience consists of generated analysis, implementation, tests, hypotheses, and explanations, they may never accumulate the experience that produced senior judgement in the first place. The learning sequence matters:

attempt → consequence → surprise → investigation → revised hypothesis → understanding

AI can accelerate that loop. It cannot safely eliminate most of it while we assume the same higher-order judgement will somehow emerge. Existing senior expertise may hide both problems for years. Then experienced engineers leave, or discover that their own diagnostic instincts have grown rusty. Deskilling becomes a capability-retention problem, a succession problem and ultimately a bus-factor problem.

Upward skill movement

There is an obvious counterargument to all of this. If AI handles implementation, developers can simply move towards more valuable work: architecture, problem framing, verification and product understanding. There is of course some truth in this. Technology has always made skills obsolete. The important distinction is which skills disappear. Losing syntax recall is mechanical deskilling. Few organisations should care.

AI replacing Google or another search mechanism is a similar case. It may simply make information retrieval faster while the developer still interprets the information, constructs the model and makes the decision. Replacing search is not the same as replacing understanding.

But if delegation absorbs problem decomposition, hypothesis formation, diagnosis, architectural reasoning and deciding what constitutes evidence, automation has reached the reasoning and epistemic layers. Those higher-order capabilities are themselves compressed experience built through lower-level encounters. Some skills should move upwards. The danger begins when the experiences required to develop the higher skills disappear as well.

Organisational trap

Leadership may see an entirely different story. Tickets completed rise. Lead time falls. Code output increases. But meanwhile harder-to-see properties may move in the opposite direction. System understanding declines, diagnostic practice declines, change comprehension declines, dependence on a small group of experts increases. Early research already shows versions of this asymmetry. Strong perceived productivity can coexist with worsening aspects of developer experience, while increased contribution volume can shift additional review and maintenance work towards experienced engineers (Vella & Blincoe, 2026; Xu et al., 2025). Output is visible immediately. Capability erosion often becomes visible only when capability is needed. That creates a collective-action problem. A developer who delegates aggressively may finish faster and be rewarded. But if everyone optimises this way, the organisation gradually consumes a shared resource: human engineering capability. The solution therefore cannot be telling individuals to “use AI responsibly”. Capability has to be protected structurally.

That also means allowing time for research, explanation, pairing and deliberate learning even when AI could produce an answer faster. Otherwise the incentives of daily delivery will work directly against the capability the organisation is trying to preserve.

Safeguards

Setting a goal of preserving difficulty for its own sake would be nonsensical. AI should remove boilerplate, repetitive transformations and other work where friction adds little value. But it should not remove the learning process.

That learning process is not incidental overhead. It is part of how engineering capability is produced.

Rule #1: Model the problem before delegating it

For non-trivial work, humans should first establish the behaviour being changed, current system understanding, constraints, assumptions, and likely failure modes. A short spike, design note, or conversation is enough. The important part is that humans construct the problem model before asking AI to solve it.

Rule #2: Treat comprehension as a change-size constraint

If the responsible engineer cannot explain a generated change and its important consequences, the change is too large or insufficiently understood. Small PRs, incremental implementation and collaborative review become AI safety mechanisms.

Rule #3: Separate generation from proof

Avoid a closed loop. AI should participate throughout the workflow without owning implementation, verification and verdict simultaneously.

Not: AI implements → AI tests → AI reviews → AI explains correctness

But: AI proposes → human defines what must be true → evidence tests those claims → peer challenges assumptions

Rule #4: Preserve diagnostic practice

For difficult problems, use a loop like:

observation → human hypothesis → AI alternatives → experiment → evidence → revised model

AI broadens the investigation rather than replacing it. Pairing allows less-experienced engineers to reason alongside seniors while AI assists both.

Rule #5: Expose people to hard work

Do not let production incidents, architectural decisions and difficult debugging become the exclusive domain of seniors plus agents. Developing future senior engineers requires accepting slower delivery today.

Rule #6: Assess capability, not AI adoption

Do not optimise token usage, percentage of AI-generated code or number of AI-assisted tasks. Instead ask:

  • Can multiple people explain critical system behaviour?
  • Can the team diagnose novel failures?
  • Are juniors progressively capable of harder problems?
  • Does review find conceptual mistakes, or merely confirm that tests pass?

These are deliberately not another dashboard. Engineering understanding is demonstrated through behaviour, not conveniently reduced to a KPI. Existing practices like spikes, pairing, code review, incident analysis and retrospectives are enough to embed these safeguards. The question to return to again and again is simple: “Is AI removing waste, or removing understanding?”

Signs

Deskilling should be detectable before a crisis. Watch out for:

  • engineers merging changes they cannot explain without consulting the agent
  • large generated changes accepted mainly because tests pass
  • debugging beginning with AI conclusions rather than observations
  • juniors resolving many tickets but rarely tracing complex behaviour
  • difficult incidents repeatedly requiring the same few senior engineers
  • growing difficulty distinguishing “the AI found this” from “we established this”

Solution

None of what has been put forward here requires the abandonment of AI or even using less AI. It requires using it differently where human reasoning matters.

AI can even accelerate upskilling when used this way. A developer can form an idea first, then use AI to find information, challenge assumptions, expose alternatives or refine the model rather than asking it to supply the final understanding.

Instead of prompting “Design this subsystem!”, try “Here is our model. Challenge it. What assumptions are we missing?” Instead of “Explain this code to me!”, try “Ask me questions that expose gaps in my understanding.” Used this way, AI becomes a cognitive scaffold, not a substitute for cognition.

Scenario

Let us return to the billing system one final time. Another strange invoice appears. The coding agent produces an explanation. The important question is not whether the team uses it. They should. The important question is whether they remain capable of asking:

  • “Why does our system behave this way?”
  • “How do we know this explanation is correct?”
  • “What would we do if the AI were wrong?”

Those questions depend on a learning process that must continue even when a faster answer is available. Hard thinking, investigation and critical challenge are not inefficiencies to be optimised away when they are the very activities through which the capability to answer those questions is built.

If an AI-assisted engineering organisation can still answer those questions, automation has likely augmented its capability. If those questions become progressively harder while throughput continues to rise, the organisation may not have created a more capable engineering system. It may simply have borrowed productivity against its future competence.

References