DEV Community

Cover image for Sauna-Driven Development: Five Shifts in How Work Happens
The Long Run
The Long Run

Posted on

Sauna-Driven Development: Five Shifts in How Work Happens

I'm sitting in an infrared sauna reviewing architecture decisions with AI agents. The heat penetrates from the inside out - warming my body directly rather than heating the air - which means the iPad balanced on the wooden bench beside me stays cool enough to function. This detail matters because it's part of what makes the whole scenario possible, and somehow that makes it more absurd, not less.

This shouldn't be possible. Software architecture happens at desks, in offices, with proper keyboards and multiple monitors spread across whiteboards and design documents. You need focus, tools, the right environment - that's been the foundational assumption for decades. Yet here I am, sweating through API design decisions, evaluating service boundaries, reviewing technical specifications, researching alternative approaches, understanding supplier capabilities. The agents are working through system design proposals, testing integration patterns, documenting technical decisions, comparing vendor options. I'm reviewing their work and providing direction. Not pretend work, not "checking email" - actual architectural judgment and strategic research that used to anchor me to a desk for hours.

Something fundamental has shifted, and the absurdity of this scene is the clearest proof. For most of the history of software development, work required presence. You sat at your desk, opened your IDE, and typed. When you left, progress stopped. The tools assumed synchronous interaction - tight feedback loops, constant iteration, hands on keyboard. Development was something you did, actively, in real time, with your full attention focused through the specific tooling that made software creation possible.

Now I can supervise architectural work from a sauna. The question isn't whether this is happening - I did it this morning - but why it's suddenly possible. What actually changed? What assumptions broke? And what does it mean that something this absurd has become not just possible, but genuinely productive?


What This Proves: Five Shifts That Compound

The sauna scenario works because work no longer requires five things that used to be non-negotiable. Each of these assumptions held for a long time, each has quietly broken, and when you stack them together they compound into something that looks ridiculous from the outside but feels completely natural when you're living it.

The desktop stopped being the center, but it didn't disappear. I'm not at my desk right now. I'm on the tube, yet architectural work continues. The iPad, even sometimes an iPhone, is enough for review, for evaluation, for providing direction on system design decisions. The desktop still exists - sometimes I need it for complex diagramming, for sessions that benefit from multiple screens and a full keyboard - but it's no longer the mandatory center of all architectural activity. Deep design work happens wherever the thinking happens, whether that's at a desk, on a train, or in a sauna. Work happens in more places, through more surfaces, and the environment adapts to what the work actually requires rather than forcing all work through a single interface.

Work continues without my physical presence. While I'm in the sauna, agents are researching vendor capabilities, comparing integration approaches, documenting architectural decisions. Progress no longer requires me sitting at a keyboard actively directing every step. I can delegate entire problem spaces - 'evaluate these three API gateway options' or 'document the data flow for this integration pattern' - and return later to review what was produced. The work persists in my absence. Presence and progress have decoupled, and once you notice this shift, you realize how much of traditional work structure was built around the assumption that they couldn't.

Architectural work is no longer synchronous. I'm not watching agents work in real time, seeing each document update, each comparison table, each decision point as it happens. I set direction, they work asynchronously, I evaluate results when I return. The tight feedback loop - the assumption that underpinned decades of development and design tooling - is gone. Work happens on its own timeline, and the value comes not from constant real-time oversight but from clear direction and thorough evaluation.

The workstation became an intervention surface, not just a creation surface. When I return to my desk after the sauna, I open my design tools to review what agents produced, correct misunderstandings, approve directions, refine approaches. The workstation shifted from "where I do architecture" to "where I evaluate and finalize architecture." Creation happens elsewhere - in agent sessions, in research threads, in documentation generation. My desk is where I intervene, where I apply judgment, where I make the decisions that require human architectural experience.

Speed matters less than continuity. The agents work quickly - researching suppliers might take twenty minutes, documenting an integration pattern might take thirty - but here's what's different: I'm not waiting for those twenty minutes. I'm not sitting at my desk watching progress bars. I'm in a sauna, or on a call, or thinking through a different problem entirely. The work completes on its own timeline, and I return to review it when I'm ready, not when it demands my attention. We spent decades optimizing for fast feedback loops because interactive work required constant presence - you changed code, watched tests run, adjusted immediately. But delegated work is different. The value isn't that agents finish quickly (though they often do), it's that they finish without requiring you to wait. You're not blocked. You're not context-switching back to check if it's done. You delegate, move on, and return later to evaluate. Continuity beats velocity when the work can proceed without constant supervision. Your productivity stops being limited by iteration speed and starts being limited by how many autonomous processes you can meaningfully supervise.

These five shifts compound. Individually, each is noticeable but manageable. Together, they enable something absurd: productive architectural work from a sauna. The location doesn't matter. The specific tools don't matter. Even my constant presence doesn't matter. What matters instead is judgment, direction, and the ability to evaluate what agents produce against architectural principles and business requirements - the work that genuinely requires human experience, not just human presence.


What This Doesn't Mean

Before this sounds like a manifesto for hot-tub-driven development, it's worth being explicit about what this shift doesn't mean, because the implications are easy to misread.

This isn't about location flexibility. Yes, I can work from a sauna, but that's a symptom, not the point. The shift is about what work fundamentally is, not where it happens. The sauna is proof that presence and progress have decoupled - that architectural judgment can happen anywhere you can review and direct - but the location itself is incidental. The meaningful change isn't "work from anywhere" flexibility. It's that the work requiring human judgment has separated from the work requiring human execution, and once those separate, the physical requirements change. The sauna matters because it's absurd, and the absurdity makes the shift visible. But the shift would be just as real if I were supervising from a coffee shop, a train, or a different room in my house.

Not all work decouples this way. Deep architectural thinking - the kind where you're wrestling with fundamental design questions, exploring tradeoffs between approaches, building mental models of complex systems - still needs uninterrupted focus and extended concentration. Learning a new domain still requires immersion. Some debugging still demands hands-on iteration, the kind where you need to see the system respond in real time to understand what's breaking. The sauna works for supervision, review, and direction. It works for evaluating what agents have produced and deciding what needs refinement. It doesn't work for everything, and pretending it does misses the point. Knowing which work can be delegated and which requires your direct, focused presence becomes the new skill.

Supervision is real work. Reviewing agent output, making architectural decisions, evaluating tradeoffs between competing approaches, deciding whether a proposed solution actually solves the right problem - this isn't "management overhead" or a step removed from real technical work. It's technical judgment, arguably the most valuable kind. The fact that it doesn't require a keyboard doesn't make it less valuable or less demanding. If anything, it's more valuable. Agents can generate solutions, research options, document systems, produce implementation proposals - but they can't yet evaluate whether those solutions are the right ones, whether the tradeoffs make sense in context, whether the documentation captures what actually matters. That evaluation requires experience, architectural intuition, and understanding of business constraints that agents don't have. The work changes form, but it doesn't become less technical.

This actually creates more time for the work that requires human presence. When agents handle research, documentation, and analysis, you gain time for the work that genuinely can't be delegated. Time to sit with development teams and understand what's actually blocking them, not what the ticket system says is blocking them. Time to get out and speak directly to stakeholders, to understand the business problems behind the technical requirements. Time to build cross-functional relationships that make architectural decisions land better because people trust the judgment behind them. The irony is that delegating execution work to agents doesn't make architectural work more isolated - it makes it more human. The time you're not spending on documentation or research is time you can spend on the conversations, relationships, and contextual understanding that agents can't replicate. The shift isn't toward solitary work. It's toward focusing human time on the parts of architectural work that genuinely require human interaction.

This raises more questions than it answers. If work can happen anywhere, how do teams coordinate? If the most valuable work - judgment, evaluation, direction - is often invisible to traditional productivity metrics, how do we measure contribution? If presence doesn't equal progress, what does "being at work" even mean? If supervision becomes the primary human role, how do junior developers learn? These aren't solved problems. They're emerging tensions we're only beginning to notice, and noticing them is the first step toward understanding what actually changed.


The Center Doesn't Disappear - It Moves

The absurdity of directing architectural work from a sauna is that it shouldn't feel normal - yet it does. There's no moment of surprise anymore when I realize I've spent twenty minutes evaluating API design proposals while waiting for a train, or reviewing integration patterns between meetings, or providing strategic direction from somewhere that has nothing to do with traditional work environments. The work happens wherever I am, and the context shifts naturally to match what that specific work requires.

What's actually changing is that different kinds of work are revealing themselves as requiring different contexts, and we're noticing which is which. Some work genuinely benefits from the full desk setup - not out of tradition, but because the work itself demands it. Other work turns out not to, and that's happening whether we think it should or not. The shift isn't that one environment replaced another. It's that the question changed from "where should work happen?" to "what does this specific work actually need?" And the answers we're discovering aren't what decades of development culture assumed they would be. Whether that's good, whether we should lean into it or resist it, whether there are costs we haven't noticed yet - those are open questions.

The clearest signal that something fundamental has shifted is that the contradiction - the absurdity and the reality existing simultaneously - no longer feels like a contradiction. Sauna-driven development sounds ridiculous. It also happened this morning, worked fine, and will probably happen again next week. The question isn't whether this shift is happening. It demonstrably is. The question is what we do with a reality where architecture and other knowledge work happens in more places, through more surfaces, with less direct human presence required than we ever thought possible.


This article synthesizes insights from a five-part series exploring how AI agents are changing development work. Each article examines one of these shifts in depth, with concrete examples and implications:

  1. When the desktop stops being the center - How work surfaces are multiplying
  2. What happens when work continues without you - The decoupling of presence and progress
  3. Why development is no longer synchronous - Breaking the tight feedback loop assumption
  4. The IDE as intervention surface - From creation to evaluation
  5. Why faster feedback stopped being the whole story - Continuity over velocity

If these shifts feel familiar, the series explores them in greater depth. If they feel surprising, the individual articles show how each emerged and what it means in practice.

Start here: When the desktop stops being the center

Top comments (0)