The fatigued engineer: The modern day DevSecOps human risk stack

Traditionally, human risk management focused on phishing, password hygiene and general employee "awareness" problems which training could somewhat quantify, measure and improve. But in modern DevSecOps teams where the world is increasingly saturated with autonomous and cognitively aware tech and ever-increasing customer demands, the risks have compounded and is more obscure.

Key human risks today are systemic and not just an individual part or component. Siloed structures that obscures handoffs, communication breakdowns under over-committed priorities, cognitive overload and fatigue, fear-driven paralysis, psychologically unsafe environments that silences dissent, insider threats born of desperate shortcuts (not malice), and now – overreliance on AI/LLM tools, are now all part of the problem.

The evolution is stark. Yesterday’s risk was a developer ignoring or blindly suppressing a warning. Today’s risk is a tired engineer sifting through AI-generated override because "the LLM said it’s safe" – without realizing the model was trained on data that never saw your specific architecture. AI compounds this: when a tool can be given permission to act (auto-rollback, auto-patch etc.), a single pressured "yes" by the engineer can trigger an irreversible series of events. Add in increasingly tight deadlines and the human brain defaults to risky, fast and biased heuristics. 

But not all hope is lost. Though a fundamental shift is needed: from blaming humans to designing for pressured humans. 

Mitigations enriched from my experience working with DevSecOps teams: 

"Silos & unstructured communications": I’ve seen teams lift their working rhythm by blending baked-in security decisions when crossing "Dev to Sec to Ops" into pre-approved categories and build patterns. With more detailed solutions requiring deeper inspection. Freeing up more time to focus on more complex problems. 

"Cognitive overload & fatigue": in several instances, we witnessed teams who added in a 'flag' or indicator in their pipelines or work management systems to combat high workloads for their engineers to achieve greater sustainability. 

"Pressured behaviour": Devs under pressure will always take the path of least resistance. So making sure the safe (or paved) path is as frictionless as possible yields the best results for continued adoption and significantly de-risks the choices made under pressure. 

"Psychological safety & fear": The best teams I’ve observed ran "no blame" post-incident reviews, just a simple mapping of "what were you thinking / doing in this situation?" Fear drops significantly when leaders demonstrates empathy for mistakes made in high-pressured and time-sensitive situations and creates a safe ecosystem for sharing. 

"AI reliance": Introducing more safeguards and guidelines around responsible AI use encourages a more secured and seamless adoption of the capability in the pipeline. 

The shift is not technical. It is cognitive and cultural. Pipelines must see and show fatigue. Leaders must model sustainable behaviour and managing expectations. AI must be treated as a junior, fallible assistant – not an oracle, where the fundamental basics of an engineer still needs to be mastered. With that, we can thrive in the face of technological disruption, not just survive it.