So what’s supposed to happen in a campfire?
That was how the session opened. With a shrug, a half-shared screen, and a team of engineers who’d never run a campfire before about to run one anyway.
There’s a lot of talk right now about software engineering being at a tipping point, about engineering organizations needing to reinvent themselves to survive, about the job of a software engineer changing so radically that there might be only a sliver left of what programming used to be.
There’s a lot less talk about how anyone is supposed to get from point A — doing things the old way, to point B — doing things the new way. Engineering leaders, the managers under them, and the individual contributors who have to change how they work day to day: where’s their map?
What you get instead is the LinkedIn version: generous with the before-and-after, a little sketchy on the part in the middle — the method itself. Maybe because the method is still being worked out. We’re still working it out too, but we have a senior team that’s about as far out on the edge of this stuff as you’ll find. So when our CEO, Otto, sent around Steve Yegge’s post on how Anthropic runs its engineering org, people put their hands up to try the thing Yegge calls a campfire.
It’s roughly what it sounds like. A few people gather around a living prototype (that’s the campfire) and prompt it together, adding tinder and logs, until a working feature comes out the other side. Yegge claims Anthropic shipped Claude Cowork ten days after someone first had the idea, apparently this way.
He also calls it “the death of the ego.” Your rawest, least-finished ideas and half-built implementations are right there in the open for a room of your peers to pick apart. And then they don’t pick them apart at all. Someone says “Yes, and ...” and you just keep going.
But aren’t good engineers supposed to have egos? I’m not so sure I agree.
So, like any well-meaning writer with a research question and a healthy amount of curiosity, I got myself invited to a campfire.
The feature on the table was a greenfield one: get Swarmia to deeply understand a team’s pull requests and issues and automatically group them into the work streams each team is doing. You don’t set anything up or define categories by hand. You connect your tools, and Swarmia tells you what your teams are working on, ideally as good as they could explain it themselves.
The clearest version of why that’s useful is right after getting started with our product. As you can imagine, engineering work produces a lot of data points, and while Swarmia already does a great job of showing you where to focus right away, there’s always room to add a touch of delight.
So in this post-campfire reality, an engineering leader connects their tools, grabs a coffee, comes back, and Swarmia has already mapped their teams and which work stream each one is focused on. From there you can see how that focus has moved over time, which areas are generating the most maintenance work, and who to talk to about a given part of the product.
In the code, this was called “themes.” By the end of the session it had become “work streams,” which also killed a running confusion between “themes” and “teams.”
So why hadn’t we built this yet? Well, it’s properly greenfield, it leans on AI in places that are hard to get right consistently, and it’s the kind of hairy, open-ended problem that never quite makes it onto a roadmap of committed work.
All of which makes it close to a perfect campfire candidate.
The first real decision was how to work at all. Someone pointed out the problem with splitting up: “That’s something we could do sitting at our own desks.” So they built together, which is what makes it a campfire, after all.
If you’ve been around software engineering a while, it might sound a lot like mob programming. Otto tried mob programming years ago and never warmed to it — typing code together in a room, he found, drags everyone into the trivial stuff instead of the decisions worth making as a group.
A campfire also turns the usual planning meeting on its head. Normally you talk your way to a plan and then scatter off to build it; here, the team builds first, and the conversation happens around the thing taking shape on the screen. Talking is expensive, and this way, you start with something concrete to react to.
Not everything pointed straight at the feature. Every so often the conversation jumped up a level to a bigger “what if?” — an adjacent product, say, or a different use for the same data. With the stakes this low, a tangent costs almost nothing to chase and nothing to drop, so the format invites them.
At one point I read the description of a campfire out loud to the room, mostly to watch their reaction:
A campfire is basically three to five people, with someone driving and sharing their screen, and the rest commenting and helping with review.
If they wanted reassurance they were doing it right, there it was.
If you want to know what a room full of engineers will happily tear to shreds, it’s AI-generated copy (which brings me joy, of course). This was the clear weak spot of the prototype, and nobody was shy about it — which is the other thing a live prototype gets you: criticism that’s specific, immediate, and quick.
Which raises a fair question: is anyone comfortable calling the output, quote, atrocious, out loud in a room full of the people who prompted it? Turns out yes, and easily. Partly because engineers are used to having their work reviewed line by line, and partly because nobody in the room wrote the thing — the machine did. Someone prompted it, sure, but you can say “oh man, this sucks” and nobody flinches, because there’s no author in the room to offend. “It’s easier to be blunt with a machine,” one of them said. “When a person’s written the code you think twice, so you don’t make anyone feel bad.”
I asked. The answer was an easy yes — though I suspect this might be because a campfire feels like a fun break to anyone who’s spent the morning working out why one engineer’s FTE number won’t show up. It’s like a more casual, more frequent alternative to a hackathon.
Nobody expected to ship a feature out of it, and that turned out to be kind of important. There was no merge to master waiting at the end, so nobody had to defend the thing they’d just built. A half-formed idea could go up, get poked at, and get dropped without anyone losing face.
The other half is that exploring is cheap. One of the biggest productivity gains from AI coding tools is that you can try three implementation paths and keep whichever turns out best, instead of committing to one before you start.
I heard it in how the team describes the work now: “In the old way, the hardest part was prioritization and figuring out what to build. In the new way we just build everything, then pick which one to actually deploy.” A caveat did come right after, though: “It’s debatable whether everything you build this way is worth building.”
Has this way of working made them more productive? The team thinks so, though they’re honest that the evidence is mostly gut feeling, for now.
This session didn’t, and nobody minded. But a campfire doesn’t have to stop at a prototype — plenty end with something in production, usually soon after rather than in the session itself. A few things that have come out of ours:
One campfire session at Swarmia went from a Figma mockup to a complete working prototype in five to ten minutes. I’ve spent longer scrolling reels just this morning. That only happened because the groundwork was already in place: the design system, the mockups, CI/CD that ships changes safely, guardrails, Claude skills, and repo instructions that keep the agents on the rails.
We don’t run these sessions on a schedule. There’s been some back-and-forth internally about making them recurring, and the answer so far is no. They work when there’s a problem to gather around, and you can’t schedule that. We run them in person, too. When everyone’s in the same room, it’s harder to peel off and build your own thing, and building one thing together is the whole point. No reason it couldn’t work remotely, though — it’d just take more effort to keep everyone around the same fire (and not scrolling reels).
I’m the last person who should be handing out engineering advice, so take these as field notes rather than instructions. But a few things about how this campfire ran seemed important:
I came in with a research question: how does an engineering org actually change the way it works? One campfire is only a single experiment, but it points at something.
And whatever that something is, it won’t look the same everywhere. For us right now, campfires are one piece of it. For a team buried in support tickets or scaling pains, it might look like something else entirely.
The tools are the easy part. You can buy Claude Code and Cursor on any random Tuesday. The trickier change is getting used to a way of working where a half-formed idea can survive in the open long enough to become something, or die fast and cheap, and nobody takes either outcome personally.
So yeah, maybe it’s death of the ego or something equally as dramatic. But maybe it’s just a room full of senior engineers agreeing, for a couple of hours, to say “yes, and” instead of “no, because.”
Subscribe to our newsletter
Get the latest product updates and #goodreads delivered to your inbox once a month.
