# Scaling AI Code Review and Ownership

**Podcast:** The AI Native Dev - from Copilot today to AI Native Software Development tomorrow
**Published:** 2026-09-29

## Transcript

30 to 70 pull requests in just three months.
That's a big jump and a lot for developers to be in control of, let's say.
Initially, it looked like we were seeing a sublinear increase in outages correlated with that, right?
Like our change failure rate appeared initially to be going down.
And then it turned out over the long term it averaged out so that, you know, we were shipping twice as many pull requests and we were seeing, you know, 1.5 times as many incidents.
There is a limit to how many incidents you can ask a human to work, right?
Your human code review attention is limited.
How do we enable our developers to scale up not just their ability to produce code, but also their ability to review code?
The AI Native Dev is a podcast for developers and engineering leads at the cutting edge of AI and agentic coding.
Join your hosts Guy Pajani and me, Simon Maple, every week as we chat with the most exciting voices in AI and tackle the biggest questions facing developers today.
This is the AI Native Dev.
Yesterday you were writing code.
Today you're prompting agents.
Tomorrow you'll be running a software factory.
Agentic Coding is moving fast enough to give anyone whiplash.
This June, AI DevCon London sold out.
Hundreds of developers, engineering leads and VPs packed in to hear speakers from Anthropic, OpenAI, Netlify and GitHub cut through the hype and get to what actually works.
This November, we're bringing it back to New York.
Bigger, bolder and full of people actually building the agentic future.
Three days of real talks, real tools, real answers, whether you're directing the agents, building the loops themselves, leading the teams or setting the strategy.
As a podcast listener, you can get 15% off your ticket using promo code POD15.
We have so much planned and we can't wait to have you join us in New York.
Hello and welcome to another episode of the AI Native Dev.
My name is Simon Maple.
I'm the host for this episode.
And joining me is Liz Fong-Jones, Technical Fellow at Honeycomb.
A massive welcome to Liz.
Hey, how are you going?
Hey, doing very well.
Thank you.
And I think this is your first time on the AI Native Dev.
Now, Liz, you're a technical fellow at Honeycomb, but you actually started more on the SRE side and then moved into DevRel, a little bit into field CTO, and now a technical fellow.
Tell us a little bit about the journey that you've been on.
Yeah, I think over the course of my career, I focused on being a generalist.
in the field of reliability and I focused on up-leveling the teams I work with.
So I started as an individual contributor as all junior devs do and then I moved to kind of advising Google S3 teams and SWE teams on what the best way was to implement reliability practices and then I took a swing at the engineer manager pendulum and managed the big table S3 team at Google about 12 people under me for a couple of years and I realized that you know I could have all the impact the world working on one specific team, working with one specific set of people.
But I really wanted to have a broader impact on the industry because I could see so many people that were struggling to implement SRE practices across their organizations.
And I thought, you know, there's a real role to uplevel the industry and to help people get more satisfaction and not just have ops be this drudge thing, you know?
So that's really what led me down this path of DevRel and field CTO work is kind of thinking about how do we move the industry forward and what's the best lever to do that?
And sometimes the best lever to do that is not managing one engineering team.
It's funny, actually, because when I also moved from developer relations into the field CTO, really enjoyed it, actually.
It was at Sneak.
I probably...
talked more with CISOs and CTOs, and I kind of felt like it's a little bit like a DevRel kind of role, but it's just more leveled up into the leadership space.
Exactly.
You're doing leadership coaching, right?
You're working peer-to-peer with other executives who are struggling to implement changes across their org.
And that's actually where our similarity ends, because I moved back into DevRel because I kind of missed the developers a little bit more.
But tell us a little bit about the technical fellow.
Yeah, so as a technical fellow, I get to do kind of distinguished engineering work across all of our various engineering teams, as well as still continuing to hold on to some of that work to evangelize and teach and to write about what we're doing.
Really, honestly, the kind of writing and appearing on podcasts and kind of...
being able to be that public face of Honeycomb engineering so that our engineers can primarily focus on being heads down, except for, right, like, of course, nurture the ones who want to speak publicly.
But, right, like kind of being that ambassador for what are we doing?
What are we seeing is really, really helpful, especially given Honeycomb's brand is that we are for forward thinking engineering teams, right?
So kind of helping.
pilot, what does that look like?
And being in a position to give people advice where we've already seen what the path looks like.
And Hanukkah very openly kind of talked about how this kind of a role, it really helps technical engineers and technical folks.
progress their careers without needing to drop into that slippery slope, that horrible slope of this management thing.
I remember my dad, who was an engineer, actually an electrical engineer, kind of was promoted into a managerial role many, many, many years ago.
And that felt like his promotion.
He succeeded because he went into a managerial role.
But of course, that's not actually what most engineers are particularly good at or actually want to do.
So I think this is a really strong way of...
of leveling folks up without...
I agree.
And also, I think it does make engineers, better engineers to take a turn at management at least once in their careers, even if they don't decide to do it full time, longer term.
I think it gives you a level of visibility into how engineering organizations work, how to have impact as a senior engineer.
So I wouldn't say necessarily that, you know, I agree with your premise that being a manager is not the promotion.
But also, I would say that it shouldn't be something where engineers should, you know, steer away from it and say, oh, God, no, I'm never going to do that.
Because I think you have a lot to learn from doing it at least once.
Yes.
Oh, that's so true.
That was my experience.
I totally agree with that, actually.
I think today more than ever, you know, the personal skills of, you know, interaction, the communication.
with AI as well as other people is so important to be able to vocalize those things.
Now, one of the things I love doing, Liz, on this podcast is finding quotes from people and throwing it back at them and saying, let's chat about this.
Let's see if this still holds up.
Now, one of the things that I actually completely agree with here, actually, so your line was, AI amplifies your existing practices.
It makes a dysfunctional org more dysfunctional and a high ownership org faster.
Now, I totally agree with that, but let's define what is a dysfunctional org?
What are the traits or the things that you would see and say, yes, if you add AI there, it'll actually make you get to that bad state faster.
What would you see as those flags?
Oh, man.
I actually prefer to talk about the inverse of that and talk about the traits of the functional orgs rather than talk about the traits of the dysfunctional orgs because I think there's just so many different varieties of dysfunction out there that it's hard to enumerate them all.
But I think, you know, let's anchor on what you said about ownership, though.
I think ownership is really that primary force that dictates whether an org is high or low functioning.
And it's the extent to which developers view their contributions as something that they take a sense of pride in, that they want to own the lifecycle of end-to-end, that they are responsible for, and that they are happy to sign their name to.
And I think everything else kind of flows out of that because when we talk about reliability practices, an organization that has poor reliability practices likely does not have a strong sense of ownership because otherwise, why would you let broken code ship to production and leave it broken in prod, right?
So we can talk about all the ways that you can leave broken code in prod, but I think it fundamentally boils down to, are the developers allowed to follow it into production?
Can they do so, right?
Like without having to go and ask for five sets of permissions.
And are they actually following through?
Right.
So, you know, we hear, I think this was in the news recently, Toby Lutke, the CEO of Shopify said, you know, 12 months ago, we are now an AI first org.
Everyone should be using AI.
And then literally a week ago, he lamented slop bombs being outlawed by engineers at production and out of their teams.
And I'm like, man.
That was kind of a foreseeable consequence if you were telling people to move without ownership and just use AI and move faster and who cares about the consequences and now suddenly they're reaping the consequences.
So I think ownership of not lobbing slop bombs because you are responsible and accountable for what you ship.
I think that's the important thing.
So you're saying that the bearing here...
is more important than the speed in terms of if you're, you will actually accelerate to the destination faster and if you're doing something bad.
And I think the important thing is...
Yes, and if you are not steering in any particular direction, right?
Like, you know, you add rocket fuel to a rocket that has no steering or guidance and it'll just go in circles until it blows up, right?
Yeah.
I think that's the classic example of, you know, of acceleration without direction.
Yes.
It's just going in circles.
Yes, and I guess, you know, A takeaway there is AI is not going to fix any existing problems that you have.
It's going to magnify them.
So if you have a problem, AI won't fix it.
You need to fix the problem and then introduce AI to accelerate the path that you're on.
Right.
If you're not in alignment about what you should be shipping, then you're just going to ship more random acts of engineering.
Right.
Like that's not good for anyone.
It's certainly.
I know that customers have a very limited patience for the amount that they allow their UI to change, right?
If the Riverside podcast reporting software looked different every time I logged in every single week, I'd become very frustrated very quickly, right?
Like there are limits to how much churn you can introduce and you have to think consciously about how you're spending that churn.
So I really like the example that you gave about ownership there because I think...
And I think there's almost like that willingness for employees, for developers to say, actually, yeah, I want to see this through to production.
Beyond ownership, are there other traits of a repo where you would look at something and say, oh, actually, yeah, these people are using, these folks, developers are using autonomy well or, you know, strong patterns.
And it's actually very...
easy to add AI in?
Maybe it's DevOps practices.
Are there other things that you can look at a repo and say, this is AI ready?
Yeah.
So I think one primary thing is AI copies existing patterns that exist in your code base.
If you have five different ways of doing something, AI will become very confused and it will create six ways or seven ways of doing it.
So I think making sure that you have alignment in your engineering organization about how do you do things, what are the common patterns, as you say, and then making sure to encode for AI and also for your new hires.
Where do you find these patterns?
How do you use them?
And I think, you know, taking your nudge there, right?
Like it is important as well to have strong CI, CD patterns so that you can actually validate things with.
five minutes of effort and not 60 minutes or three hours of effort making sure that you have good observability making sure you have good testability and not just you know empty calorie tests but actual like real meaningful tests right again machines copy and if they are copying bad practices then you're going to wind up creating thought bombs if you are copying good practices then you are going to have an easier time testing and validating what you're producing and that you know starts with testing starts with high quality comments and even in our code base where we have relatively high quality comments we found that ai unfortunately is regressing us to the mean there we're having like lots of very low low value comments that ai is creating right like so how are you guarding against ai making your code base worse how are you actually propagating good patterns around testing good patterns around observability kind of making sure that we are engineering things in a way that it's going to be easier to roll them out to production And I think we talked about this briefly off air, but the advice that we are kind of like giving here is actually the same advice that we would give pre-AI in terms of what functional looks like, what good looks like, you know, good testing, good reliability, all those things.
This is just good development.
It's like telling people to eat their vegetables.
It is.
And the trouble is no one wants to eat their vegetables until they wind up with a vitamin deficiency, right?
Yeah.
Except for the thing is.
AI has made it a lot easier to do the eat your vegetables part as long as you tell AI to do it and not just have AI slop coding a bunch of new features into your codebase.
You have a bunch of new engineering bandwidth.
How you choose to spend it is up to you.
And because the machines never get bored, it's a great thing to do to have them add to your codebase, to add rich Y events, to add attributes.
These are things that we used to have to tell developers, like telling them to eat their vegetables or brush their teeth right like now it's something that the robots are actually pretty competent at doing and they're happy to do it as long as you instruct them to right like so i think it's both that the necessity of doing it is higher than ever because we're having this increased volume of uh code that we're trying to land and also the ease of doing it is much better as well yeah no absolutely um so let's talk about a functional organization.
Let's talk about Honeycomb.
Let's talk about the Honeycomb bot, Autobot, sorry, that merges pull requests and creates pull requests.
I believe that went from 30 pull requests merged per day to 70 pull requests merged per day in three months.
Did I get those numbers right?
You got the numbers right, but I think the attribution is wrong.
So yes, we do have an internal coding bot called Autobot.
However, the Autobot is producing maybe five of those pull requests per day.
So it's not the majority creator of the pull requests.
It is the 100% reviewer of those pull requests.
And it has gotten so good that our developers are no longer needing to look for trivial bugs and changes, right?
So I think, you know, when we're talking about increasing your number of pull requests by a factor of two or more, right, like your human code review attention is limited.
How do we enable our developers to scale up not just their ability to produce code, but also their ability to review code?
And I think it really helps there to have a helpful assistant like Autobot pointing out problems so that the developer doesn't have to be a human linter or a human bug checker.
Right.
And this is really interesting because the speed at which people can write code and...
trying to deliver code is not the problem here.
The problem is the speed at which us as humans can validate that the code that is being generated, the pull requests that are coming in are valid, are correct, are well tested.
Exactly so.
I would argue any real production system...
should probably not be a dark factory, at least at this time.
I think there is a need for human oversight, human review, human accountability, as I was talking about, right?
Like, you know, how are we making sure that we're feeding back the lessons that we learn?
How are we making sure that we are maintaining our standards?
And I think those standards have to come from humans, right?
Like, I don't think the robots are capable of coming up with enforcing the standards on their own, right?
Like, we have to, right?
Like, just because you have adaptive cruise control in your car doesn't mean that you can fully let go of the wheel, right?
Like, you still have to pay attention.
So can you tell us a little bit about how the Autobot, and I love the name Autobot.
It does sound very Transformer-like, so it feels like we've got a lot of power on our side.
Tell us a little bit about how that works under the covers.
Why is it so reliable?
Yeah, so originally we conceived of Autobots as this mechanism to automate the creation of small kind of bite-sized pull requests.
And, you know, we developed, we invested a fair amount of time in essentially doing cloud code in a box to work on a single linear ticket.
And it still does that, although we're in the process of sunsetting that because it turns out that now it's, you know, commoditized and now you can have bespoke services that do that in a box for you.
But I think at the time when we started this effort in April or May, this was, you know, phenomenally effective in terms of, for the first time, having even developers who are not super it's Lewin in Cloud Code, be able to say, you know what?
This ticket looks relatively simple.
You know, nothing ventured, nothing gained, right?
Like, you know, let's assign that ticket to Autobot and see what pull request it produces, right?
So that's kind of how Autobot started.
Was this effort to kind of clear off the lower hanging fruit that doesn't require a developer to supervise and tell the robot consistently and steer it, right?
Like, you know, this is the kind of design direction I want this to take.
The theory was if you decomposed everything into a linear ticket well enough so that it would be able to complete the linear ticket on its own, that then your Autobot could take that and turn it into a portal quest.
And then you could, as a human who requested the Autobot to run, you could go ahead and review that self-review first.
And then after that, hand that to your peer reviewer to review as well.
So that's how it started.
And then we realized that there were a relatively small percentage of these smaller tickets.
And also that same functionality could also be used to reproduce kind of in a box the functionality that I think in April or March this year, Claude Anthropic released this Claude Code Reviews functionality.
And it was phenomenally expensive.
It was like $20 or $30 per run.
And it took like 10 or 20 minutes to run.
And we looked at it and we said, actually, we want something like this.
but we would prefer that it run within less than two or three minutes, that it costs dollars per pull request and not tens of dollars.
So we pivoted the Autobots project towards handling reviews because we realized that our human developers were more than capable of creating this mass volume of pull requests anyways, Autobots or not, and that we needed to focus that instead on how do we make the review load of our human reviewers lighter.
And how does...
So obviously, you know, Claude as an LLM or a general LLM, these types of things will always be kind of like very expensive and long to run.
In the news this week, so this will tell folks when we recorded it, obviously, Jev is making a lot of waves right now.
It's hitting the headlines in most places.
With an LLM which is very specific to being able to provide yes-no answers or multiple choice, how will that now impact places or specific tasks like code review?
Yeah.
So I think the primary place where we're thinking about deploying Gev right now...
is classifying pull requests into safe to merge with just the automatic review versus not safe to merge requires a human review.
Previously, we had been relying on humans to self-identify, and we were doing this experiment, actually, to try to have about 20% of our pull requests automatically reviewed and landed without having a human review.
Again, focusing that human attention, because if you double the number of pull requests, either you more than double the amount of time that you're spending as a human reviewing, or you have to loadshed you have to figure out what's less important to review and what's more important to review so previously we had been doing this experiment of having humans and the reviewers labeling you know do i think this is a pull request that requires high effort to review or not and Now I think we can have Jev do that.
We can have Jev be that gut check of, can I trust the reviewer's opinion on whether or not this is safe to land?
And if so, go ahead and land it without human intervention.
So there still is the language model layer doing the code review.
But I think the classifier is then doing that work of How complex is the code change?
Did the reviewer raise any significant concerns?
Should I merge or not?
Yeah, and I think there are three kind of like key things that are hitting the news here with Jeff.
One is the cost.
One is the speed.
But the other is the confidence score.
And I presume it's the speed and the cost are probably the nice to haves here, but it's the confidence score, I guess.
Right, exactly.
If I'm already spending five minutes and $10 in tokens to review this pull request, the thing that's actually important here is getting an automated confidence score on can I land this safely, right?
So yeah, 100% agree.
But for us, again, this is not that we're intending to spend less time doing code reviews than we did before.
It's to focus the time that we're spending doing code reviews on the design patterns and not on trivial bugs and on the more complex PRs and not on the more simple PRs.
If I'm twiddling a single config knob, most of the time, that's not a big deal.
except for some of the time it actually has the potential to bring down production.
So I think that's kind of that trade off there.
And I as a human can, of course, opt out of automatic code review entirely and say, hey, this requires special caution.
But honestly, most developers are are very conscientious right like at least in a high autonomy org so we don't want to cause outages in production so by definition you know outages happen when something happens that was unexpected that we didn't foresee that we thought it was going to be a simple change and was not right like so having these additional guard rails whether it be a language model doing a review or it being job doing a you know sanity check of does this make sense or not to to immediately land right like i think those are the levers that we need to do to really go beyond beyond 2x because we've hit the ceiling of how much code we can conceive of and review.
And this is interesting because whenever we hit the ceiling, we always tend to go beyond it in a way we kind of like least expect.
But, you know, 30 to 70 pull requests in just three months, that's a big jump and a lot for developers to...
be in control of, let's say.
Yes, and we definitely, initially it looked like we were seeing a sublinear increase in outages correlated with that, right?
Like our change failure rate appeared initially to be going down and then it turned out over the long term it averaged out so that, you know, we were shipping twice as many pull requests and we were seeing, you know, 1.5 times as many incidents.
And there is a limit to how many incidents you can ask a human to work, right?
Yes.
Yes.
We have to start looking at how do we de-risk these other things.
So where's the line, would you say, between something that's been reviewed and something that's been understood?
Because it's almost like, you know, when I deliver a 500-line pull request versus a 10-line pull request, one will definitely be scrutinized more than the other.
In the same way, if I was to provide you with 500 pull requests versus one, there are going to be many more that just go through with maybe a, you know, reduced visibility from the human.
How do we make sure that as humans, we don't just become very blasé and just, you know, push pull requests along and actually understand what happens?
Is this, again, another, maybe it is the Jev, the Jev angle of...
Is the code review the right place to be having that discussion?
Often we find that that is a better place...
to be talking about it at the project and at the ticket level than at the pull request level.
By the times, especially if generating the code is cheap and you could do it five times over, why are we that attached to the way the specific code works and not to the broader design pattern?
That's the thing that we should be aligning on is, is the direction correct and not, is this implementation exactly correct?
Language model can help you understand what the individual lines of code do, right?
But the broader pattern, that's something that you have to hold in your head in that we as humans that are supervising these systems need to have a consistent picture of how is this supposed to behave at the macro level.
Yeah.
Let's then take it one step further.
Let's say, you know, there's an outage or some system fault.
We obviously need to have a look at...
Well, we need telemetry data and we need observability.
Now, you draw quite a hard distinction here between what telemetry is and what observability is.
Really data versus the ability to truly understand the system.
Data versus understanding 100% every day.
Well, how does AI change what understanding a system means if a human actually doesn't write that code?
I don't think the human has to write the code.
And also, I don't think the human has to do the querying by themselves.
However, examining the outputs of the queries, that's something that a human has to do to really kind of internalize and understand how did this outage happen?
What are the other things that we should be looking at that are similar?
How do we prevent this outage from happening again?
So I think having telemetry data, having it queryable and legible both to the humans and AI.
is helpful for them kind of establishing that feedback loop.
And I don't think it's just at the moment of outage.
I think also in your development cycle, right, you should be having your language models test the telemetry that they're producing by querying a dev environment, right?
Like to make sure if I added an attribute, is that attribute present?
Do I have the ability to detect if something backlogs, right?
If something starts queuing, right?
So I think I think the answer is yes and.
I think, yes, we have to have telemetry.
Yes, we have to have the ability to analyze that telemetry.
And also, it's not just the human's job and it's not just the robot's job.
It's a joint responsibility to turn the telemetry data into understanding.
Yes, yeah.
And I guess as someone who has a lot of history in the world of SRE, you talked a little bit about how, you know, your opinion on...
how people should be using dark factories in production.
How much should we be trusting AI to do with data in an incident?
It would be lovely to think that we can wake up in the morning and kind of click a button to say, yes, I can see the AI agents have...
identified the problem.
They've done all the background root cause analysis.
They've suggested the issue, sorry, they've suggested a solution.
They've reviewed it.
I just need to review it myself.
and push that through.
How close are we to that today?
And do you see a world soon?
Again, it depends on how well you are implementing the practices of the last 10 years.
Yes.
We have had feature flagging for 10 or 15 years, depends on how you count Netflix's early stuff.
We've had feature flags for 15 years.
If you were implementing feature flags well, then yes, a robot with access to MCP can identify which feature flag will solve your problem and can flip the feature flag and the telemetry will be recorded both for the robot who's diagnosing in real time and for you with a cup of coffee or a Diet Coke in your hand the next morning.
If you have that telemetry data recorded and if you have the controllability, remember observability and controllability and control theory are duals.
If you have both observability and controllability, You do have the ability to not have to wake up at 2 a.m.
because you can actually go ahead and fix the problem without necessarily even fully understanding it, right?
And then to be able to examine what happened after the fact with the kind of, you know, flight recorder or whatever it is, right?
So I think we're pretty close if and only if you have working automatic rollbacks, working feature flags, working observability.
If you don't have those things, your agents are just guessing and throwing darts at the dartboard and they might cause more chaos than they actually solve.
So it depends very heavily on your production maturity practices.
And it's not so much your trust in the AI, it's your trust in the system with which the AI environment is running in.
Exactly.
Our job is to make it so that the tools that the robots have are safe.
If we're having AI exercise its judgment about whether it's okay to kill these pods, I think that that is a very dangerous thing to give your AI agents the ability to kill random pods in production, right?
We should be giving them tools to abort rollouts, to revert rollouts, right?
So I think you kind of have to make sure that the tools are always safe to use and that the robots, right, like rather than trusting the robots to decide whether or not to call them.
Yeah, structured functionality that they can use.
And let's talk about, And that's really, to be fair, this is also true about your most junior developer on your team.
Yes.
Right?
Like, you know, if you're making it safe for your junior developers that they cannot accidentally cause production outages, right?
Like, I think that that's great for your robots too.
Hey, everyone.
Hope you're enjoying the episode so far.
Our team is working really hard behind the scenes to bring you the best guests so we can have the most informative conversations about agentic development.
whether that's talking about the latest tools, the most efficient workflows, or defining best practices.
But for whatever reason, many of you have yet to subscribe to the channel.
If you're enjoying the podcast and want us to continue to bring you the very best content, please do us a favor and hit that subscribe button.
It really does make a difference and lets us continue to improve the quality of our guests and build an even better product for you.
All right, back to the episode.
Let's talk about, let's continue this path down trust and safeguarding.
You described needing things like Claude MD rules, MCP-mediated access, least privileged systems, all these things which help this safeguarding.
What, in your opinion, have you seen that kind of would be a really...
Good piece of advice that most teams actually don't think about or, you know, it's great practice, like least privilege.
This is something that we've known for many, many years, decades.
What are the things that teams can do today that is just completely non-negotiable to avoid?
I think the starting point is really hermetic CINCD, like to have fast and reproducible CINCD.
I think that's the foundation of everything.
I think your mention of least privilege is great.
Actually, I discovered that on its own, actually, Claude has started when working with Amazon profiles to default to using read-only profiles if it's provided the option to have both a read-only and read-write profile, even if the read-write profile is technically available.
it will still use read-only just to be safe, right?
Which I think is a great safety practice, right?
And you can also enforce that, right?
To enforce, you know, hey, commands that use the read-only profile are automatically approved.
Commands that use the read-write profile must use human approval, right?
So I think for layers, defense, and depth, I think that those are all really, really great things.
And is there, you know, anything you think we are over-trusting these days in terms of are there default settings that we should absolutely try and avoid?
I think the main thing that we are realizing does not scale is having humans click yes.
I think that classifiers do a much better job than humans when attention is scarce.
And I think that, you know, you do have to develop a certain number of repetitions of hitting yes before you start trusting auto mode.
And you have to have a certain number of repetitions of, you know, seeing automatic code review catch issues that you wouldn't personally have caught before you start caught trusting automatic code review.
Right.
But I think eventually you do realize, yes.
I can trust the automated steering, but I'm still going to keep my eyes on the road.
But that's very different than gripping the steering wheel tightly.
So I think we have a tendency as human beings to micromanage.
We have a tendency to assume that we will always do a better job than the robots.
And I think that that is the mistake.
I think the mistake is over-trusting your ability to make decisions under time pressure and stress.
And I think that's a situation where a robot that never gets tired will do a better job than you.
Yeah.
And of course, if something does go wrong, is it the robot's fault or is it the operator's fault?
Now, Honeycomb's AI values state if your name's on it, you own it.
So tell us a little bit about how far that extends.
I don't think it's about fault.
I think it's about whose responsibility is to clean up and to think about how do we harden the system so this doesn't happen again.
Right.
You know, if we're talking about, you know, some kind of failure that leads out to production.
Well, number one, ideally, something going wrong should not bring down all of production.
We should focus on making the failures smaller in blast radius rather than rather than trying to prevent them from happening entirely.
And then I think in terms of the accountability, right?
Like the main thing is to say, right?
Like, you know, not, you know, the robot did it, you know, it's not my fault.
The robot did it, right?
Like, you know, Claude did it is not a really great excuse, right?
Like instead you have to examine and say, okay, what are my structural biases that caused me to over-trust in this output, right?
So actually there's a example this past week where I I was doing some analysis of A-chains that we were rolling out, and I was trying to do the analysis A-B tested by which shard or which partition ID.
And for some reason, my AI assistant did not find the telemetry field for partition ID.
And then it's confabulated this thing about how we need to construct a new telemetry field for partition ID.
I should have rerun the query and actually typed partition ID to see whether it automatically dropped out.
I shouldn't have trusted the AI assistant when it blithely asserted there was no partition ID field.
But then also, my accountability, I told it, okay, if you're missing the partition ID field, then we need to go and create a pull request to add the partition ID field.
The field was there all along.
So I wasted some tokens and I wasted five minutes of a principal engineer's time to review the pull request that would have added a duplicate partition ID field.
You could say, blame Claude, or you could say, I should have been more skeptical about this output.
Surely we should have had partition ID.
I should have known that of course we had partition ID in there.
I should have run the query by myself before I trusted this robot that said, there's no partition ID field.
We need one.
But I signed off on it.
That's my responsibility.
That's what we mean when we talk about taking ownership.
I think there are more mundane things beyond code, right?
Like, for instance, don't send someone a slop bomb of, you know, this is, you know, a 10-page clawed artifact, right?
Like, I think that that's, you know, a little bit more self-explanatory of if your name is signed to it, you should stand behind it, and you should ideally have spent as much time reading over and producing it as the reader is going to take to read it.
But I think the more interesting thing is, as we're talking about here, what happens when code that you ship is wrong for whatever reason?
How are we encapsulating the learning so that Claude doesn't make the mistake over and over and over again?
It's us humans that have to figure out how do we more effectively use these tools.
And as AI practices, let's say, rather than models, get more developed so that we will get to a stage where AI can fully build, test, review and deploy changes, potentially small, potentially non-complex and maybe non-critical systems.
At what stage would a human who hasn't been involved in any of that, at what stage would a human own that?
Would it not be fair to say if at that point Claude's name's on it, let's say, or Codex's name's on that, it should own it?
And we essentially say we are happy that a very small percentage of these will be wrong, but it's the bot that effectively owns that delivery through to production.
Yeah, I think at that point, it's the human team that creates the workflow files that guide that loop that are responsible for the quality control and checking of that loop and the tuning of it to make sure that it is more as effective as it's supposed to be.
Despite what you might be seeing in the news, there is not actually fully automated recursive self-improvement, right?
Like there is always some degree of human guidance involved.
So even if robots are coming up with tickets and solving the tickets and pushing them to production, debugging them in production, there is still a person that owns the system prompt for that.
There is still the person who is paying for the quota for that.
There is still the person that expects results from that.
Right.
And I think that that is where the ownership lies is to go and spot check some of those pull requests every now and then to do evals, to tune the system prompt.
Right.
Like, I don't think that we are at a point yet where we can say we're just going to go fully hands off.
Sure.
If you're down to go fully hands off, hand me your checkbook, please.
I will take your checkbook.
Right.
But as long as humans are paying for it, humans have the right to inspect the results.
I think that's what it boils down to.
Right.
Like is there still a process owner.
And that process owner is accountable for the results.
Yeah, no, nicely said.
It's what are we recording on the 22nd of September today, Liz?
So we're kind of giving away a little bit about the behind the scenes here.
But on the 22nd of October, Hacktoberfest is right around the corner.
Of course, in years gone by, there have always been some problems where you get bad human pull requests which have been raised and mass created, which have annoyed maintainers.
Now, today's problem, of course, that was largely fixed by having an opt-in style of Hacktoberfest.
But today, even if you opt in, probably a bigger worry is someone's just going to come up and provide some AI slop pull request.
One of the things that was kind of partly mentioned previously is that you were considering eliminating external contributions to open source projects because of the kind of floods of pull requests that were very slop oriented.
Have you made a decision in and around that or any experiences recently in and around that space?
Yeah.
So I do think that for security reasons and a variety of reasons related to code style, maintainability.
I think that maintainers definitely should continue accepting bug reports.
Whether maintainers accept pull requests is up to their discretion because it turns out with a well-equipped bug report, you can have your agent write a fix for it in your preferred style, right?
So why should you trust someone else's agent where it might be just as much work to check the work over as if you had done it yourself?
So I think that's kind of my first thought is bug reports always, always valuable as long as they're well formatted that say exactly this is what I expected to happen.
This is what actually happened.
This is where I think the problem might be, but not necessarily proposing a fix and leaving up to the maintainers discretion.
I think the other thing is not relaxing our standards, right?
Like we should not have lower standards for AI created pull requests than human created pull requests.
And also I've seen efforts both in the academic space as well as in the open source and commercial space to actually require someone to complete a quiz about the work that they've submitted before they actually get a chance to submit it.
So if you cannot answer basic questions about the pull request that you've submitted, you probably shouldn't be submitting it because you have no idea what's going on.
The I am not a robot button, I suppose, for a pull request.
The I am not a robot button where actually, this is the funny thing, you're using slop to fight slop.
You can have an agent take the pull request and create a quiz about it that you must pass before you can have it submitted.
And I think, yes, as you say, you can triage them with AI.
Also, a very interesting thing.
So my wife works on Google Chrome security.
And one of the things that they're starting to do is they're starting to require that in order to get fast-tracked for your security exploit bug, you must provide a working reproducer.
You must provide something that provides evidence that you crash a Chrome process.
No crasher, no triage, right?
because otherwise you would have to deal with all of these slop reports.
But if you have something that genuinely crashes the browser, that is clearly a sign that you are onto something real and we should go and invest resources in debugging it.
So I think there are heuristics that you can apply to open source contributions.
And Linus Torvalds came out in favor of using AI.
Linus Torvalds said, I think that AI agents have a valuable role to play.
And literally this past week, I have a dev box that's a ARM64 box that has an unconventional hardware configuration, let us say.
And that dev box has a bug that prevents it from booting on Linux 6.19 and newer.
And I was able to, with Claude Fable's help, actually figure out what the bug was, figure out what a working patch for it was.
and the patch was only six lines.
It's really not that complex of a patch, but I was the first one to run into this situation and it solved a general problem for a variety of classes of hardware.
So I submitted it upstream and it went through the normal Linux vetting processes.
It took over two months to land, but it did eventually land.
I think that's a sign that things are working as intended, that a genuine patch that is small enough to review, that has good enough justifications.
regardless of whether it's by humans or not.
If we're restricting open source contributions to bugs only, though, versus the larger, more directional changes that we might with full features, what does that mean for open source?
Non-maintainers should not be suggesting large directional changes without discussion with the maintainers first.
That is the source of the slop bombs.
Just because you can do something and send someone a 10,000-line pull request does not mean you should.
Talk to humans first and get approval.
And then, you know, at that point, you're proceeding as if you were a trusted maintainer on the inside if you've gotten to sign off on your plan.
So the path is issue first, long discussions or if it's obvious, short discussions with the maintainers.
And from that point, you probably have enough credibility just through that discussion to be able to share a pull request.
Right, because the maintainer is context of what you're trying to do.
Yeah, excellent.
Excellent.
So open source has a bright future.
I think that it has some structural problems.
I think there is that question of who is paying for all of those tokens for automatic review and triage.
Right.
So I think that there is the challenge of when you've got a million developers out there who are all paying for a heavily subsidized $20 a month open AI or Cloud or Gemini subscription.
Right.
you have to prevent those from denial of servicing your open source maintainers.
And for critical projects like Linux kernel or Kubernetes, right, like the Linux kernel has a automatic review bot called Sashiko and Sashiko is fully paid for by Google, right?
Like, which is great.
So I think corporate sponsorship helps, but I think that there are smaller projects that receive less commercial love.
that are really, really struggling.
And certainly there have been efforts to do outreach to them.
For instance, Anthropica's Project Glasswing, which gave access to Mythos to a bunch of very security critical projects like Curl and OpenSSL.
But I think there's kind of this broader problem of who pays for these tokens and how do we make sure that open source maintainers are resourced and they don't burn out.
Yeah, I think that's...
Which is the same problem that's always been before, and I just felt more magnified.
It is.
We're tripping over all the same problems, right, but at a faster rate.
It's very interesting.
And actually, you know, executives have money to spend on it now.
That is the difference, right?
Like, as previously, you know, telling people, yes, you should implement observability, and they're like, budget what budget?
Now it's like, you need to implement observability or else your AI effort will fail.
Great.
Here's some money.
Let's, you know, we're...
A few minutes left.
It's been a wonderful chat.
Really, really enjoyed it.
But I want to end always with the easiest question, Liz, which is let's talk about what's going to happen in the next 50 years.
Well, maybe not 50.
50 years, try 50 days.
Exactly, right?
So maybe we talk about just two or three years.
And let's talk about a role change or maybe even a change that needs to happen in the org around an observability engineer.
Do you feel that will still be a role, a standalone role or a job title in future?
Or do you think that discipline needs to merge into another role that exists today?
We've already seen that site reliability engineering, security engineering, observability engineering, these all broadly fall under the platform of platform engineering, as it were.
um right because they are all cross-functional disciplines that require buy-in of individual development teams and they do have their own specialized skill set but broadly speaking our job is to produce the kind of common standards and tooling that developers need to do their jobs So I think the great merger into platform engineering is already well underway, right?
Like, you know, I mentioned security engineering, accessibility engineering, right?
Like test engineering, right?
Like all of these disciplines where, you know, you don't want each developer to have to think about each of these things and be an expert in each of these things, but it is to some extent those developers' job to ensure that their code conforms to our org standards, right?
So I think that's basically the crux of it is Observability engineering is not necessarily going to be about building out your own observability platform.
There are vendors out there, or if you're a sufficiently large scale, sure, there might be an observability tooling team or something.
But I think the outreach to developers piece, I think that that is something that broadly gets owned by all of platform engineering, and that platform engineering employs people from a variety of different specialties who all collaborate to bring the expertise to the teams that need them.
Yeah, super interesting.
And I think, yeah, even back in my days at Sneak, this was a...
Even pre-AI, it made sense for more and more things to be centralized, particularly around security best practices providing those services.
And I think it makes sense.
Yeah, exactly.
It's a perfect mapping, right?
Like security, observability, testing, right?
Like all reliability.
You don't want each dev to have to be an expert in service level objectives.
You want every dev to have service level objectives, though.
Yeah.
Amazing.
Liz, we talked about it a lot, but where can people follow up on some of the things that you and Honeycomb have been doing and talking about?
We definitely maintain a very active engineering blog.
So if you go to honeycomb.io slash blog, you'll find writing by not just me, but also by my colleagues, charity majors, Christine Yen, and all of Honeycomb Engineering.
And you can find me on the internet basically everywhere as Liz the Gray.
Wonderful.
Liz, it's been an absolute pleasure to chat and really, really enjoyed going deep in various topics.
So thank you so, so much for your time.
And it's been a pleasure having you on the AI Native Dev.
Thank you.
Wonderful.
And I hope all of our listeners out there enjoyed it just as much as I did.
Thanks for tuning in and see you on the next session.
Bye for now.
The AI Native Dev is brought to you by TESL, the package manager for skills and context.
Your hosts are Guy Pajani and me, Simon Maple.
Our producer is Tom Dowler.
The AI Native Dev is not just a podcast, it's a community, and we host monthly meetups at the TESL offices in central London.
Visit tesl.io forward slash community to learn more, and I hope to see you there.