Gathering around the fire: Durable human experience patterns in the AI era

There’s a study by Polly Wiessner called Embers of Society: Firelight Talk Among the Ju/’hoansi Bushmen that I’ve been thinking about a lot lately. I was reminded of it from my own experience with AI, and from watching how everyone around me interacts with it.

Wiessner compared different types of conversational interactions among the Ju/’hoansi – a population of hunter-gatherers living in southern Africa. Her research noted that the purpose and style of these conversations varied depending on whether they took place during the day or at night.

Daytime talk centered on economic matters and getting things done. Nighttime talk, which typically took place around the fire, was completely different. It steered away from the tensions of the day toward singing, dancing, ceremonies, and stories. By the light of the fire, the learnings of the day were shared and understood.

Wiessner argues that among communities, night talk plays a big role in evoking higher-order theory of mind through the imagination, conveying the attributes of people across broad networks, and transmitting the “big picture” of cultural institutions, which is what generates regularity of behavior, cooperation, and trust.

Embodying the Ju/’hoansi

I see a similar pattern in how we work with AI. It’s one I’ve been leaning on as I figure out how to turn AI into an effective productivity partner and collaborator in my own day-to-day.

In this day-and-night analogy, daytime is the operational work we do with AI, the standard back and forth between human and agent that produces huge amounts of output.

Then comes night. Gathered around the fire, we start to review and dig deeper into all of that output: reflecting on what has happened and solidifying our thinking. We seek to understand more deeply. These “nighttime” interactions – focused on driving understanding – are the vital balance to the high-output, more transactional “daytime” ones.

As someone who works at the intersection of engineering and design, I spend a lot of time thinking about how we might design a UX that accounts for both types of interaction – day and night. What kind of affordances allow users to review output at scale and to truly understand them? What cognitive tools will the UX give users to make sure decisions that they make with AI are grounded and bullet proof? The future I expect looks familiar in terms of who produces good work. It just looks different in how much of it they produce, and how fast it is.

Rethinking the current paradigm

It’s vital that we strike a balance between elevating efficiency and driving understanding. How do you build trust in something that is new to you? Let’s consider human interactions. When we bring on a new team member, there’s a runway – weeks or months – where rapport builds gradually and both sides learn how the other works. AI doesn’t get that runway. It’s handed real tasks from the first message, with no context to draw on. The challenge is to build that trust fast, and I do it using practices I already naturally lean on when I converse with colleagues or work through a tricky problem.

Many current UX patterns in our AI tools focus on tangible actions – “pin frequently used agents,” “start a new task”. But I’m imagining a near-future reality where standard UX patterns focus more on reviewing and understanding output and helping to drive trust – “explore this concept from another POV,” “brainstorm a better solution to this problem than the one you’ve just put forward”.

These are the kinds of patterns I’m already trying myself, in my own interactions with AI. I’m sharing them below to help you do the same – and to hopefully inspire you to think a little differently about what a truly satisfying, trust-led user experience looks like.

A few guidelines to keep in mind as you try the below patterns for yourself: rely on human judgement, evolve through iteration, embrace constructive skepticism, and stay exploratory without scaling naively. Give them a go and let the fireside sparks fly.

Brainstorming with AI to ideate and imagine

Before I write a line of code for a new feature, I open a brainstorm with AI. I start with the big picture: my ambitions for the feature, for the business, and for the experience. Then I describe it in three layers. What it should do. What it could do. What I would dream for it to do one day. Sometimes, I’ll go down geek-out rabbit holes on one single feature where I imagine endless redesigns. From there the problem and possibility spaces expands in ways it wouldn’t have if I’d sat down alone.

02

Role- playing to get someone else’s POV

If I’m writing something that matters, like an email, a paper, or a presentation, I’ll ask AI to analyze it from different viewpoints. A business leader two levels up. The engineering lead. A PM from another team. Each one gives me feedback through their own lens. It’s a way of getting out of my own head and being mindful of the audience I’m actually writing for, even when I can’t tell where my blind spots are.

Asking AI to play devil’s advocate – on itself

Sometimes, I’ll ask AI a high-stakes question about a topic I’m not well versed in. The AI gives me an answer, confidently, but I don’t have the judgment to know if it’s right, and I can’t push back because I don’t know enough. So I ask AI to be its own devil’s advocate. Throw edge cases at its own recommendation. Argue against the choice it just made. Often its stance shifts, or it surfaces trade-offs it glossed past. The back and forth means we land at a place where I can confidently move forward.

04

Coaching AI to help solve complex problems

If something breaks in production, the vibe-coding move is to ask AI to fix it. But this quick move sometimes results in incomplete fixes. So instead of asking for a fix right away, I stay in the problem space. Gather evidence about what broke. Analyze the code. Add observability. Only once AI shows that it clearly understands the problem, do I let it propose a solution – and usually it ends up being a pretty solid one.

Learning through experimental play

Recently, I needed a graph visualization for a threat surface tool used by security analysts, showing nodes and relationships. I knew my data and API. What I didn’t know was which UI library handled them best. So instead of picking one on paper, I built the same thing three times in parallel, each wired to my real data. By the time I had three working versions, the winner was obvious. It wasn’t A/B testing. It was learning through building, so the real build could be one-shotted with confidence.