Splitting tasks by machine strength erodes the operator skill the next incident needs

"Functional allocation by substitution" happens in a planning document, before any code exists. You list the tasks. You give each one to the pipeline or to the on-call engineer, according to which is better at it. Human factors research calls the underlying belief the "substitution myth": the assumption that automation can replace human functions without altering how the system or the human work operates ^[10]. The formal version is HABA-MABA, short for Humans Are Better At and Machines Are Better At, which treats each side's strengths as fixed and system design as the job of allocating tasks accordingly ^[11].

Sidney Dekker and David Woods argued against the approach in Cognition, Technology & Work in 2002 ^[12]. Their objection is that automation does not simply absorb existing tasks; it transforms the human work around it and creates new tasks, roles and challenges ^[13]. The changes are qualitative and unpredictable ^[14]. The neglected item is coordination: designers who assume substitution overlook coordination needs and miss how the work is actually adapted in practice ^[15]. The misconception came out of studies of automated cockpits, where the primary error was the assumption that automation should replace the work humans do ^[9].

InfoQ applies that literature to software, looking at tools built to operate independently of people, including CI/CD deployment pipelines and Kubernetes pod auto-scaling ^[16]. The author's stated interest came from stories told by people in SRE and incident response, and from watching AI take over tooling and products ^[17]. The reported finding is that automation shows up in incidents in counter-intuitive ways, impeding resolution or complicating the human response ^[4]. The design consequence is narrower and more useful: dividing work strictly into what automation handles and what humans handle shapes the system so that incidents get harder to resolve ^[5].

Automation degrades knowledge and skill acquisition and retention in unanticipated ways, because operators have less experience with the systems that automation is meant to run ^[6]. The engineer who takes over is therefore least practised on the component that just failed.

Knight Capital Group is the article's opening case. An update released on 1 August 2012 lost the firm $460 million in twenty minutes, about $23 million a minute, and severely hit the valuations of numerous other companies ^[1][3]. By the next day the company's value was down seventy-five percent, and it was acquired at a fraction of its original value and eventually dissolved ^[2]. More than a decade on, according to the article, beliefs about automation have not evolved as the industry moves toward AI, partly because of a notion that AI addresses the limitations of traditional automation ^[18][19].

These are presented as takeaways from the author's research, and the article does not describe the incident sample or the method behind them ^[21]. The design direction it offers is cognitive science, specifically Joint Cognitive Systems principles, applied to tools that incorporate or rely on automation ^[7], with automation built to augment human work instead of replacing it ^[8]. In my view the usable test is smaller than the theory: whether an operator who has not touched the system for months can read what the automation did and finish the job by hand.