The stress reduction argument for automation is straightforward: fewer tasks means fewer deadlines, fewer deadlines means less pressure, less pressure means less cortisol. The data does not cooperate. Workplace stress has risen alongside automation, not fallen, and the mechanism is not hard to find — automation does not eliminate uncertainty, it relocates it. When a machine takes over a task, the person who used to do it no longer worries about doing it badly; they worry instead about whether they are needed at all. The anxiety shifts from performance to existence, which is a worse trade. A programmer who ships bad code can fix it; a programmer who wonders whether their role survives the next model release has nothing to debug. The future does not have a ticket queue, and that is precisely what makes it harder to deal with. The response is not to fight automation but to treat the existential question the same way you would treat a hard bug: define it precisely, isolate the variable you can actually change, and work on that. What you can control is which skills you build next and whether you are the person who understands the system or the one waiting to be told what it decided.
Less Work, More Worry
Automation reduces stress at the task level and raises it at the existential level. The worry doesn't disappear — it just moves to harder questions.
Pick one skill adjacent to your current role that machines handle poorly — ambiguity, trust, novel judgment — and invest in it deliberately before your queue forces you to.
Post on X
