When your game holds Guinness World Records for the longest and the largest online battles in history—including a single fight with more than 8,600 players simultaneously—having observability tools you can rely on is essential.

That’s the case for Fenris Creations (formerly CCP Games), the Iceland-based game development company behind EVE Online, a massively multiplayer online role-playing game (MMORPG). Christine Yen recently talked with Technical Director Nick Herring to hear about how Honeycomb has become central to how his team builds, debugs, and collaborates across one of the most complex live-service games ever made, and how using AI can sometimes feel like managing a really bad intern.

AI as a Sherpa through 23 years of code

As Fenris has weaved AI into its engineering workflow, an important lesson has been revealed: AI amplifies what's already there, good or bad.

The company’s first use case was a matter of survival. EVE Online's codebase spans millions of lines of Python and tens of millions of lines of data defining the universe. So much institutional knowledge has accumulated over 23 years that even modern IDEs struggle to keep up with its scale and dynamic typing.

"The first thing that we started doing with AI is using it as a Sherpa over these millions of lines of Python," Nick said. "You can throw some things at Claude, and it will figure out most of it, or at least find the right spots to look."

But Fenris quickly learned that AI performs very differently depending on the quality of the underlying system. “Different parts of our ecosystem have gone through different cultural evolutions as far as the people who have worked on them,” Nick said. “So some have had way more engineering discipline, some have had way less engineering discipline.”

In codebases with strong engineering discipline (good test coverage, linting, design docs, consistent patterns), AI accelerated everything. “It confirmed all of the things that we've been doing in the last three to four years and allows us to run faster in that direction.”

But when the team started applying AI to systems with old codebases, it became problematic. “When you try to apply it to systems that don't have those principles in place, it allows you to run faster into a wall.”

Nick described asking Claude to help stream a real-time OpenGL map to screens around the office. Without context, it suggested calling FFmpeg over the command line for every single frame. When the team supplied the actual architecture (frame buffer objects, pixel buffer objects, x264 encoding, RTMP streaming), it nearly one-shotted the solution. "If you have those principles in place, where you've done the legwork of the research and the architecture, it's very powerful," Nick said.

The same lesson applied when the Fenris team tried to generate AI skills from their existing service documentation. The docs were written for humans: polite, readable, and written in a way that wouldn’t make new employees feel dumb. But Claude treated optional-sounding language as actually optional and skipped critical steps. The fix required going back through documentation and being, as Nick put it, "very much belligerent" about what was required. It was painstaking work, like course-correcting an eager but unpredictable intern. But the process ultimately sharpened Fenris’ documentation for both human and AI readers.

From exceptions to Honeycomb links

One of the most telling signs that Honeycomb had become truly embedded at Fenris was a communication shift between humans. "We've seen teams start to communicate not in exceptions but in Honeycomb links," Nick explained. "Instead of going, 'Hey, this doesn't work,' they go, 'Hey, this is what I'm seeing from Honeycomb.'"

That change happened organically, as a result of Honeycomb's Slack integration. Posting a link to a query inside Slack automatically renders a graph and the underlying query inline, no click required. For a team spread across disciplines, that frictionless preview became a surprisingly powerful on-ramp.

"It lures other disciplines in to go, 'What's that? That looks interesting,' and then they get hit by a truck with all the information of what's going on," said Nick.

OpenTelemetry semantic conventions as a force multiplier

Fenris didn't get there by luck. Nick’s team invested heavily in OpenTelemetry semantic conventions before leaning into Honeycomb's more advanced capabilities. That foundation made everything downstream easier.

Their approach is layered by scope: service.name for standard OTel conventions, eve.* for ecosystem-wide attributes that require cross-team alignment, and app.* for domain-level attributes that individual engineers can own. The discipline pays off when you're trying to make sense of a universe where every laser fired, every missile exploded, and every ship docked generates telemetry.

"When we struggle to get people building services to use a domain span attribute prefixed with app.*, that's where your freedom happens," Nick said. Consistency with those conventions, he noted, is what makes data discoverable, especially as AI tools start joining the conversation.

Canvas opens the door to new audiences

Honeycomb's AI-powered Canvas feature has pushed observability beyond the engineering team entirely. Nick described quality analysts—people with deep product knowledge but no systems engineering background—who are now able to trace exactly where a complex feature is breaking down.

"I think Canvas has offset that up another echelon," Nick said. "I'm seeing managers who've always been curious about those Honeycomb things flying around. Now, you can give them Canvas, and they go, 'What does this mean? What's going on? Can you tell me more about what's happening in this trace?'"

Illustrating the way Canvas has made observability insights accessible to more people at Fenris, Nick recalled when one of the company’s technical managers came to him excitedly: "He came running to me with, 'Have you seen Canvas? This thing's nuts.'"

Conclusion

Looking ahead, Nick wants to start piecing together the moving parts of AI and observability tools and integrating them with the conversations that people are already having to support the collaborative effort of teams.

“With game development, it's a lot more about collaboration,” Nick said. “You're not going to get requirements with a bow on the top. It's more about people saying, “Hey, I have this crazy idea. How do we work this into the existing systems that we have, or do we need to build something novel?’”