Julien Reszka
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 straightforward: 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:
- which skills you build next
- whether you are the person who understands the system, or the one waiting to be told what it decided
Discussion
Yes, exactly this. My ticket queue halved this year and my anxiety doubled. I keep waiting to feel relieved and instead I'm refreshing job postings.
Same shape on my side. Fewer interruptions, more existential dread.
Yes. The skill I'm trying to build is judgment in ambiguous situations, the kind of thing the model still can't do reliably. Slow going but it's the only honest answer I've found.
Counterpoint: what if the anxiety is accurate? If your role is genuinely at risk, worry is the rational signal. It's telling you to act. Reframing it as a hard bug to debug is useful if it leads to action, but it becomes avoidance if you use it to feel calm while the situation actually gets worse.