A service engineer used to diagnose unfamiliar faults by comparing symptoms, checking recent changes, and testing possible causes. An assistant now proposes the likely fault and a repair sequence. Most jobs finish sooner, and the engineer becomes skilled at applying the proposed fix. Months later, a case falls outside the familiar pattern. The suggested repair fails, and the team struggles to decide what to investigate next.
This does not establish that the assistant caused a loss of expertise. The underlying system may have changed, the fault may be unusually difficult, or the team may never have developed the required capability. It does expose a question that completion statistics cannot answer: which parts of diagnosis are staff still exercising, and which parts has the workflow stopped asking them to perform?
Cognitive atrophy is a metaphor for the possible weakening of underused skills, not a neurological diagnosis. The practical concern is whether people can still perform the judgments an organisation expects them to retain when routine work no longer provides the same opportunities to practise.
Identify the skill that is receiving less practice
Expertise is not a single ability that an employee either possesses or lacks. In fault diagnosis, it includes recognising patterns, generating alternatives, choosing discriminating tests, interpreting evidence, and knowing when a familiar explanation no longer fits. Automation can change each component differently.
The engineer may become better at navigating service information and following a safe repair sequence while doing less hypothesis generation. Calling that overall deskilling would hide both the gain and the possible loss. Name the capability the service will still need and examine how the revised work develops or maintains it.
A useful comparison begins with an actual case. Before the assistant, who decided which evidence to collect? After its introduction, does the engineer still make that decision, or mainly confirm that the proposed repair is available? Look at the decisions made during the task, rather than assuming that equal time on the job provides equal practice.
The distinction matters for training too. If the capability gap concerns selecting tests, another demonstration of the repair interface may not address it. The exercise needs to create an opportunity to choose between plausible explanations and observe what the selected test reveals.
Separate retention from learning that never happened
An experienced person failing a once-familiar task raises a retention question. A newcomer completing assisted work without acquiring the underlying method raises an acquisition question. Both can leave a team dependent on assistance, but their causes and remedies need not be identical.
Arthur and colleagues’ review of skill decay and retention examines trained skills and knowledge over periods of nonuse. It provides a research basis for considering retention, without supplying a single expiry period for every kind of professional judgment. Task characteristics and the conditions under which skill was learned and assessed matter.
A 2026 study by Shen and Tamkin examined developers learning an unfamiliar asynchronous programming library with and without AI assistance. The assisted group showed weaker understanding on the study’s assessments, while interaction patterns differed. That is evidence about learning in a particular task, not proof that established engineers lose their expertise through ordinary AI use.
For the service team, distinguish people who previously demonstrated diagnosis from those who have only completed assistant-guided repairs. A refresher may help the first group. The second may need a structured development path with supervised decisions and feedback before independent diagnostic responsibility is appropriate.
Recognition and explanation can overstate readiness
An engineer may recognise a correct diagnosis when it is displayed without being able to generate or test it independently. Likewise, a clear explanation can feel familiar even when the reader would struggle to use the principle in a new case. Those are reasons to examine performance directly, not to dismiss the value of explanations.
Ask someone to explain what evidence would distinguish two possible faults before showing the recommended answer. Then present a variation in which the familiar repair is unsuitable. The purpose is to assess whether the person can apply the underlying method when the surface cues change.
Assisted performance remains relevant. If the ordinary job includes an approved tool, competence includes using that tool well. The question is whether the organisation also depends on independent diagnosis, verification, or recovery. Assessment should represent those responsibilities instead of requiring unaided performance merely to recreate an older way of working.
This is connected to independent judgment in AI review, but the focus differs. Review sequencing concerns how a recommendation influences a present decision. Skill retention concerns what people remain capable of doing across repeated work and changing conditions.
Put judgment back into representative work
Preserving capability does not require making every routine task manual. It requires deliberate opportunities to exercise the decisions the organisation still needs. Some can occur in ordinary cases, while rare or consequential scenarios may need a controlled exercise.
For a selected fault, the engineer could record an initial hypothesis, identify a useful test, and explain what result would change the diagnosis. The assistant can then provide another view. A supervisor can examine the reasoning and outcome together, identifying which cues were informative and where the initial account was incomplete.
Keep exercises within the operating environment’s safeguards. A replay, simulator, or isolated test system may offer the required decisions without exposing customers or equipment to an avoidable fault. Where simulation omits important features, record what the exercise can and cannot establish.
HSE’s training and competence guidance distinguishes training from demonstrated competence and emphasises practice and appropriate reassessment, including infrequent activities. Its safety context calls for care in transferring requirements, but the basic design question is useful: did the activity create the capability the task requires?
Assess the capability the fallback actually needs
An organisation may expect staff to continue when an assistant is unavailable. Test that expectation as an operational scenario. Losing the tool can also remove source access, credentials, or a convenient interface, so failure in the exercise should not automatically be attributed to missing knowledge.
| Observation in a practice case | Question to investigate |
|---|---|
| Cannot suggest a first test | Has hypothesis selection been practised? |
| Knows the method but cannot reach records | Is the evidence path dependent on the tool? |
| Performs correctly but slowly | What recovery time does the service require? |
| Applies an obsolete procedure | Has the capability been updated for the current system? |
| Completes only familiar cases | Has practice included relevant variation? |
Use the results to design a realistic fallback. Perhaps a smaller group retains deep diagnostic responsibility while others recognise cases requiring escalation. That can be appropriate if coverage, response times, and access are sufficient. Describing every employee as a manual backup would be misleading if only a few people can perform the required work.
Give practice a place in workload planning
Practice uses time that could otherwise produce immediate output. If the team’s targets account only for completed jobs, supervised diagnosis can look inefficient even when it maintains a capability the organisation depends on. Make the retained capability and the time needed to support it explicit.
Evaluate practice by what people can subsequently do, including whether learning transfers to a changed case. Attendance and completed modules establish participation, while a performance exercise provides different evidence. Neither should be mistaken for a permanent guarantee of readiness.
Record the assistance available during each exercise. Completing a diagnosis after a supervisor names the likely cause establishes something different from selecting that cause independently. A development sequence can begin with guidance, then remove selected prompts as the learner demonstrates the relevant decisions. Keep ordinary access to necessary records where the real task requires it, so the assessment examines judgment rather than memory for information that competent staff would normally retrieve.
Watch for unintended effects. A required preliminary hypothesis can become a rushed form entry if the queue leaves no time to think. Supervisors need capacity to discuss reasoning, and staff need a way to admit uncertainty without pretending to know the answer. Otherwise the record can improve while the learning opportunity remains thin.
The capacity problem is developed in the economics of automated judgment. Here, the additional consideration is that today’s work also shapes tomorrow’s ability to check, diagnose, and recover.
Let obsolete skills retire deliberately
Some older methods will no longer justify maintenance. A retired platform may need only archival documentation, while a new operating model requires different expertise. Retaining every historical procedure would consume capacity and could encourage staff to apply knowledge that no longer fits.
Decide which capabilities remain necessary for the planned service, its exceptions, and its recovery arrangements. Update that decision after major changes to the system or the role of automation. Where a capability is being retired, identify what replaces it and whether the replacement has been demonstrated.
The aim is a clear account of what the organisation still knows how to do. Faster assisted work can be valuable, and AI can support explanation and practice as well as completion. Preserve the opportunities that develop the judgments still required, then test those judgments through representative work instead of inferring them from successful output alone.
