We’re excited to share that Honeycomb has completed our first-ever acquisition: we’re joining forces with Grit, bringing aboard not only a strong team but also compelling technology that supercharges our ability to deliver on our mission: to bring observability to every software engineer.

Observability is way more about software engineering than it is about operations. Operators are users of observability data for monitoring and alerting on systems. They’ll use that telemetry data to scale systems, or potentially debug the outside of applications. In contrast, software engineers are creators, designers, and users of observability data, and where they use that data is much wider than that of pure operators of production systems.

You can’t throw a rock without hitting an online discussion about ‘vibe coding,’ so I figured I’d add some signal to the noise and discuss how I’ve been using AI-driven coding tools with observability platforms like Honeycomb over the past six months. This isn’t an exhaustive guide, and not everything I say is going to be useful to everyone—but hopefully it will clear up some common misconceptions and help folks out.

At Honeycomb, we believe that observability should be accessible, effective, and transformative. That’s why our customer education team is thrilled to introduce Honeycomb Academy, a learning hub designed to help our customers of all experience levels master observability, OpenTelemetry, and the Honeycomb platform.

At Honeycomb, we’re actively growing our design system, Lattice, to ensure accessibility, optimize performance, and establish consistent design patterns across our product. One metric we use to measure Lattice is the adoption of components across the product. Adoption is about understanding how, where, and why they’re being used.

CloudWatch metrics can be a very useful source of information for a number of AWS services that don’t produce telemetry as well as instrumented code. There are also a number of useful metrics for non-web-request based functions, like metrics on concurrent database requests. We use them at Honeycomb to get statistics on load balancers and RDS instances. The Amazon Data Firehose is able to export directly to Honeycomb as well, which makes getting the data into Honeycomb straightforward.

How many of you started with technologies you still use exactly the same way today? Even if you’re a master Lisp/Clojure developer, you’ve still evolved, right? I should really get my head around those parentheses some day.

Last week marked the inaugural HumanX conference, a convening of leaders, technologists, policy makers, and media, all brought together to discuss the state of AI and its potential impact on the future of software, business, and society.

Observability and monitoring are not about gathering different data—they differ in their purpose, but share the same data.

The common definition of a computer is a programmable machine that stores, retrieves, and processes data. I would argue that ChatGPT already fits this definition, as you can control how it responds with prompts (programs), it can store data you pass it (memory), it can search that data to generate a response (RAG), and it can process inputs to produce a response (inference).

f you've been using Honeycomb for a bit, you know that Calculated Fields (otherwise known as derived columns) are a powerful way to transform your events to a format that's easier to query and understand. However, they use a lisp-esque language that can be difficult to read and a pain to write.

As software teams race to integrate AI into their development workflows, we need to ask ourselves: are AI-powered tools actually making software better?