It's been one year since we issued an AI mandate inside Honeycomb, and we've been doing a lot of reflecting internally on how far we've come and how far we have yet to go.

Last week I shared a post from our SVP of sales, Manny Alves, on the way our GTM teams use AI and how we expect our teams to interact with customers and prospects. This week I'd like to share a (lightly edited) note from Emily Nakashima, SVP of Engineering. It lays out our reasons for going all in on AI and connects it back to our values and business prop. It sets forth a new north star for our engineering org to shoot for (which yes, creates as many new questions as it answers!). And it balances out this abstract, aspirational language with some practical advice for the concerns of the day (e.g. "we have too many long slack threads").

While the specific FAQ may not be directly relevant to your engineering orgs, I included it here because I love how the combination reflects the kind of engineering leadership we have grown to expect at Honeycomb: ambitious, humane, and eternally grounded in the details.

~charity

AI Usage in Engineering, by Emily Nakashima

In August of 2025, Honeycomb's founders wrote a message to the company about our stance on AI adoption, asking each employee to attempt to 2x their productivity (really, impact) with AI.

While this goal applied to all teams at Honeycomb, it's particularly interesting for engineering, given the industry-wide focus on AI-assisted coding and new entrants in the "AI Ops" and "AI SRE" product categories. What does it mean for us in engineering?

Why adopt AI?

💡 "To give all software engineers the observability they need to understand their software & delight their users." - Honeycomb mission

Reason 1: to help shape the future of our industry

AI is here to stay in the industry, and it's changing how software engineers everywhere work. However, the precise new ways we'll uphold and live out our values in this technology era are yet to be determined. If we want to be the ones inventing them and shaping how teams run and maintain software at scale, we need to be continuously building our skills and capabilities with AI to better understand how and where we can and can't (or shouldn't) push the boundaries.

Reason 2: to retain our credibility with our customers as expert guides

Our success as a business has heavily relied on our reputation as tastemakers and experts in software. It's not good enough for us to simply adopt AI tools and workflows after they are known to work and broadly adopted. We are not followers. We wrestle with software on the boundaries of what's possible, we explore hard problems, we reason from first principles, and when we find something that works we bring the industry along with us. It's who we are. It's why people listen.

Reason 3: we need every tool we can get to help our customers overcome the inertia of the status quo

The state of the art in the industry is just bad. But it's everywhere. Which means it takes a lot of energy to dislodge the status quo.

Every vendor claims to "do observability." But doing it right means helping teams change the way they build and validate software, which goes much deeper than slapping a few more dashboards on top of archaic logs and metrics. Our job isn't to out-shout the hype cycles or go nose to nose with the status quo on features and checklists. It's to stay relentlessly focused on honing an opinionated approach, making it easier and easier for engineering teams to understand their software, their product, and their users.

What's our north star?

⭐ We aspire to be in the top 10% most AI-enabled, most productive engineering teams at companies of our size and stage.

Concretely, in addition to the company-wide 2x mandate, we have the following near-term goals for EO 2026. These goals are an initial guess and are VERY subject to change as we learn more. We want them to point us in the right direction, not prescriptively tell us where to focus.

• By the end of the year, our systems are safe enough that at least 25% of all PRs are AI-reviewed and auto-merged (with no human review required) while maintaining a change failure rate under 3% (we're close today)
• We maintain our SLOs and don't increase incident response workload outside of sustainable bounds (📉 course correction already needed here)
• We are actively re-shaping how software teams work, such that our jobs continue to be impactful, meaningful, and sustainable
• We are sharing what we learn outside of Honeycomb (e.g., via blog posts, conference talks, social media, etc.)

Note: while the above list of measurable goals focus on code authorship, our goal is to use AI across the software development lifecycle. As we find additional points in the lifecycle to measure, we'll add them to the list above.

FAQ

What kind of support can I expect for my AI usage?

Expect the company to provide you with resources like product subscriptions, tokens, and shared best practices, but know that your own continuous experimentation and learning will also be required. If we waited until all aspects of AI-assisted coding and related educational resources were fully baked to invest in, we would miss the boat. This means we all have to participate actively in learning and experimentation together.

Additionally, we've asked the engineering enablement team to add some AI platform work to its roadmap. This team has a broader charter beyond AI, but we recognize that we need both distributed and centralized efforts to achieve our vision. If there is a particular way our AI-backed tooling could be more robust or AI usage could be easier, this team is probably the right one to share it with; engineering leadership will work with them to continue to add support for the AI platform portion of their work.

How do I know if my AI usage meets Honeycomb's expectations? How is this measured?

As with all conversations about, "Am I meeting expectations for my role?" or "How am I performing?" your first stop is your manager. While we may look at some metrics to understand adoption and usage, there's no specific set of quantitative metrics we expect each person to hit. Your manager can help you understand how you are performing relative to the expectations of your role. That said, sometimes a rough heuristic can help keep us all calibrated. Here is one: aim to have a shareable insight that impacts how you approach future work at least ~1x/mo. We are trying to push boundaries vs trying to play it safe.

Are we headed toward a "software factory" approach?

It's an intriguing approach that's generating a lot of conversation in the industry, and while we want to explore it, we understand that a lot of the patterns and best practices aren't settled yet.

We expect that across engineering, we've exited the era of "AI as glorified autocomplete" and are all making use of agentic workflows, often using multiple agents concurrently. However, the exact patterns that we'll land on as the most impactful and effective over the long term are still up for debate. Our ask is that you help us figure out how we can all be effective at these new higher levels of abstraction, but we don't necessarily yet have prescriptive guidance about the exact patterns we see in the future. Engineering enablement is currently the owner of the next steps here, as part of their developer productivity charter.

Should I be running a certain number of agents at once?

There are many contributing factors to how many agents anyone should be running, including technical limitations, and the fact that different people's brains work in different ways and dovetail with tools differently. Everyone should put in the time and experimentation to find out where their "sweet spot" is. Ultimately, the answer to this question is you should run the number of agents that allows you to deliver impact most effectively, and you should do the work of generating the data to answer that question for yourself.

I see a 200-reply thread about AI usage patterns. Should I participate?

There is real, meaningful work to be done around creating and defining AI norms and usage patterns. These tools are driving novel human interactions, and getting them right involves conversation, iteration, and deep listening.

That said, none of us have the job of Professional Slack Responder™, and many of these threads quickly can become circular, sucking up a lot of time and emotional energy without creating forward progress. Nobody is required to participate in these discussions, but if you choose to join in, you are expected to:

• Be quick to assign action items and next steps, even if experimental, rather than rehashing a question you've already seen discussed.
  • Move conversations from Slack to a meeting if you believe the conversation is valuable but it isn't coming to a conclusion.
• Ask yourself if you're genuinely moving the conversation forward, vs. venting or engaging just to avoid missing out.
  • The workflow challenges that spawn these threads are often very real, but a long Slack thread may not be part of the solution.
• Be a responsible steward of your coworkers' and your own time and energy.
• Make sure you're doing your first job first.

There are things about these tools that make my job less satisfying, more stressful, etc. How do I cope with that?

Every major wave of technological change impacts how we do our work and the satisfaction we may feel from our craft, often in a mix of positive and negative ways. This is very, very true for AI tools and particularly apparent for more autonomous agentic workflows.

It's not strange to feel a sense of loss or grief as we set down or reduce parts of our job that felt satisfying and prioritize other ways of working. Our ask isn't to pretend those feelings don't exist, but to engage with them head on. We encourage you to take time to experiment to find new ways of working that fit both you and the available tools, and share what's working (and what's not) with your teammates and Honeycomb at large.

Is this just about writing code faster?

No. We believe there's leverage across the whole lifecycle.

We encourage you and your teams to spend time experimenting with these tools for use cases beyond code generation, and to make time to talk with each other about how best to collaborate as these tools change your workflows.