FH

Fred Hebert

Things Fred Says on Podcasts

Where to Find Them

Fred Hebert has been a guest on O11ycast and Fallthrough .

Recently: “The Tortoise and the Agent” on Fallthrough (October 2026); “Ep. #49, Incident Commanders with Fred Hebert of Honeycomb” on O11ycast (March 2022).

What They Said

“I haven't seen a lot of discourse in the industry about what's the most amount of change a user can take before they just don't try your features anymore. Because if you're shipping features faster than your users can try them, you're not doing important work. They're not going to use them.” — Fred Hebert, Fallthrough

In his closing thoughts, Hebert says software keeps reinventing from first principles when decades of history are available. Teams smash one bottleneck after another, he argues, without asking where the real ceiling is.

Fallthrough · 2026-10-24 Permalink → Listen →
Fallthrough Around 57:55 into the episode
Reid Savage

…get a lot of people that are like, oh, wow, that actually solves my workflow problem. Thanks. I'm going to try that. And you'd be surprised at the response you get when you just share and what you're learning out loud. Cool. Anything that we left unsaid? I know we're running up against time here.

Matthew Sanabria

…drained properly so that we have proper slide strains and the proper size rest of the wastewater system. That can carry everything out at the rate that we're pouring things in. So I think that there's a bit of the things from the old, I think are relevant to the now again in a lot of ways.

Fred Hebert

Yeah. I think in software, we have a tendency to reinvent from first principles in places where there's decades of history that shows what works well, what doesn't work well. And we would save so much time by studying more of what other people do. or did in the past. Like the question about we're chasing and we're just like smashing bottlenecks one after each other. And I haven't seen a lot of like discourse in the industry about like, what's the most amount of change a user can take before they just don't try your features anymore. Because if you're shipping features faster than your users can try them, you're not doing important work. They're not going to use them. Like that's your bottleneck at the end as a user. So if that's the thing, like, and you're able to establish that, you don't need to go any faster than this.

Kris Brandow

Yeah. And if you're able to

Fred Hebert

think about the holistic point of view of the system, probably as good, yeah, Richie can take it over.

Kris Brandow

I was just going to say that a lesson that some companies have forgotten is that from product thinking is like users don't care if your app uses AI or not. What they actually care about is, does this solve my problem? Like I am not enticed as someone who is responsible for some budgets of some…

Speaker names from our own diarization · position estimated from where the line sits in the episode
“I want to be in a position to not be the human in the loop where the role of the human in the loop is to say yes, no, and then get blamed when something goes wrong.” — Fred Hebert, Fallthrough

Hebert, a senior SRE at Honeycomb who calls himself one of the company's biggest AI skeptics, explains what led to his blog post about embracing the code review bottleneck. He wants AI workflows that support engineers rather than substitute for them.

Fallthrough · 2026-10-24 Permalink → Listen →
Fallthrough Around 08:11 into the episode
Fred Hebert

…product be a poison pill for SAS. Like SAS moves fast, ships 100 commits a day or something like that. And a single tenant product ships ideally once a week. And you don't want one to slow down the other. And so there's a lot of coordination work to make both development workflows work at the same

Matthew Sanabria

…understanding of how we got here today, right? So that's how we got here today. We were introduced on email, and we're, I guess, we should start there. So you wrote this blog, it looks like back in July of 2026. So like five years ago in terms of AI time, right? What prompted this blog post?

Fred Hebert

I'm one of the, I guess, biggest, not naysayers of AI, but one of the people who dislikes it the most. I'm a big, big nerd about cognitive systems engineering, and I want to be in a position to, you know, not be the human in the loop where the role of the human in the loop is to say yes, no, and then get blamed when something goes wrong. I want to be involved in the development of things and whatnot. And I've been very, very vocal about what I think a good workflow would be like in terms of supporting people rather than substituting them. And the blog post came because when we started the tenant team, we knew we had to rewrite essentially the whole deployment mechanism for SAS Honeycomb into Greenfield. And AI was already good enough at that point to be doing a fairly decent job. There was an agreement on the team that it would make sense to use it for a lot of work. So for maybe close to six to nine months, we experimented a lot with deployment…

Matthew Sanabria

And, Reid, were you on the other side of this? Or were you in agreement with Fred? Or where did you stand on this side?

Reid Savage

Oh, I was, I mean, in total agreement with Fred. So since I was managing two teams, I was kind of like, you know, whatever approach we want to take, I'm good with. Whatever works for the team, whatever works for this new service area. I really didn't want to get in the way. I think basically the…

Matthew Sanabria

What do you see broadly at Honeycomb? Like, is this vibe coding opinion learnings? Like, is it well accepted in the company? Like, are there people that are pro and against? Or where does it kind of fall at Honeycomb for you all?

Speaker names from our own diarization · position estimated from where the line sits in the episode

Collections They Appear In

Hands-On Engineering Podcasts