# 2026 Engineering Benchmark: AI Adoption vs. Impact Gap

**Podcast:** Dev Interrupted
**Published:** 2026-03-24

## Transcript

Hey, what's up everyone?
Welcome back to Dev Interrupted.
I'm your host, Dan Lines Linear B, COO and co-founder.
Today's episode will focus on the 2026 Engineering Benchmark Report from Linear B.
So this year's report, it's our biggest, our most comprehensive yet.
It's an amazing, amazing report.
We're going to take a look at what the data says about engineering teams and really specifically how AI is fundamentally reshaping the way we build software.
And to help me walk through all this data, I have my fellow co-host and linear B's director of AI innovation, Ben Lloyd Pearson, BLP, to answer all of my questions about this year's report.
Ben, always great to share an episode with you.
Welcome to the show.
Yeah, thank thanks for having me.
Uh it's always a lot of fun to just share all the cool research we're doing at Linear B.
So a lot of cool data for us to unpack today.
Yeah, amazing.
And you and I were talking before the show.
You did you came on Dev Interrupted to do this, I think like two years ago, maybe even three years ago.
Three years ago.
Three years ago.
And so I think it will be pretty interesting to see how this has progressed.
Obviously, a lot of it has to do with AI, but how do you feel about now coming on three years later and doing the same thing, but with an updated report?
Oh man, I mean, it's wild to think about just how different the world is today versus when I when I first started here at Linear B.
I mean, the AI was barely even something we were talking about at that point, and now it's like all we can talk about, and I feel like everything I'm doing is now being impacted by it.
So, you know, of course, so is this report, and there's going to be a lot of new AI stuff that we're going to talk about today, which is pretty awesome.
Yeah, it's really cool.
I mean, I I read through everything in there, and definitely like it's gonna be exciting to get into that AI stuff that's really popping out.
A lot of good insights there.
But I guess probably the best way.
Let's start with an overview.
Let's start out with an overview summary.
Maybe you can give us an overview of what makes either this report uh unique or maybe some of the things that are kind of like uh jumping out at you uh for this year.
Yeah.
Well, like you said, it's it's the most comprehensive analysis we've ever done.
Um 8.1 million poll requests, about 4800 engineering teams spread across 42 different countries.
So pretty large scale of data that we're dealing with here.
And what really sets this year apart from is that we've introduced a completely new dimension to this report around AI productivity and specifically how to measure it.
So for the first time, we're not just looking at all the traditional software delivery metrics.
You know, those are still there, we're still reporting on them, but we're also examining how AI is impacting engineering workflows across the board.
So, and on top of that, we've combined uh for the first time ever, qualitative data along with our, or excuse me, qualitative analysis along with our quantitative data, uh, where we surveyed a bunch of engineering leadership or engineering leaders about how they're using AI within their organization.
Both to understand the data behind what's changing, but then also the perception of of the leaders that are running these things.
And if I had to pick one thing that is sort of the the top line that everyone should take away from this is that AI adoption is effectively maximized at this point.
It's it's almost universal.
So it in our findings, 88.3% of developers now use AI regularly, so that's you know, at least multiple times a week, which is up from 70 just under 72% when we last surveyed this back in early 2024.
But I want to make I want to stress one really critical point, and that is that adoption does not equal impact.
So AI generated PRs are behaving completely different than ones that are unassisted by AI.
They're larger, they wait longer for reviews, and they merge at less than half the rate of human-authored code.
So what I really want people to take away is that AI is accelerating code generation.
I I think we all know that at this point, but it's also exposing bottlenecks everywhere else in the SDLC, primarily with things like reviews, testing, governance, organizational readiness.
There's still a lot that uh needs to be solved outside of code generation.
Yeah, man.
Uh, you mentioned a few things there.
One thing that I really uh like about the report when, and hopefully, like all of our listeners will will read through this.
We do have the qualitative responses now.
So as you read through the report, you can see what engineering leaders are saying and commenting on and that type of thing.
So I thought that was really cool.
The other thing that I really liked about the report on the AI side is it doesn't just talk about AI, I guess, generically as being like one single unit.
Yeah.
It's there's the agentic pull requests.
There's the AI assisted, and then there's the non-AI assisted and the comparison there.
Exactly.
Um, maybe you can explain, you know, what what's the difference between like the AI assisted and the fully agentic, just uh for our listeners.
Yeah, yeah.
So we have a lot of data that compares these three classifications of PRs.
So um, you know, on the simplest side, you have unassisted PRs.
So this is something where a human authors it, they don't use AI to generate code at all, probably don't even use it to ideate.
They just write the code sort of as we've always done for many years and then submit it.
Um, one level up from that is AI assisted PRs.
So this is where the code is is authored by a human, but is significantly shaped with AI tools, whether that be the actual generation of the code or you know, maybe planning for generating the code or or you know, research, that type of stuff.
And then at the highest level, you have a gentic PRs.
So those are pull requests that are created entirely by an AI agent.
Um, definitely the most um or the the less the least mature of these three categories, but that's agents like Devin, Copilot, stuff like that, when they they generate the pull requests themselves rather than having a human lead the effort.
Yeah, and we're gonna get into uh some of those different differences because I thought that was really cool how the report broke that out.
Um and obviously that that is new to the report.
What else is new compared to previous uh years for the report?
Yeah, so the biggest thing is probably the new section that we introduced that focuses exclusively on AI productivity insights.
And we've we've broken this down into a few parts.
So AI code in the SDLC, so this is how AI generated and AI assisted PRs behave compared to manual or unassisted pull requests.
Uh the DevX of AI, so this is how developers are experiencing AI adoption and their level of trust with it.
Um, and then the last big addition related to AI is uh a new survey that that uh gauges the state of AI readiness among respondents.
So this is a look at whether organizations have the foundations to make AI successful.
And if you've read this year's door report, this will this will be very familiar with you because we tried to build upon the re the great research that they're doing over there.
Um related to all this new AI AI stuff, we've also added a new benchmark this year for acceptance rate.
And that's not the typical one of of how much how many lines of code did you accept, or how what percentage of of submit of recommendations from an uh coding assistant did you accept?
It's not that.
Instead, we're measuring the percentage of pull requests that get merged within 30 days.
So this is really relevant for AI generated code where things like ownership and acceptance patterns can be completely different than your typical pull request.
And you know just just a preview before we get into it too much, the data on this is really striking.
You know manual PRs merge at about 80 84 and a half percent so about 84% of all the unassisted PRs that are open get merged across all of our users.
But AI PRs merge at just 32.7% which is less than half of that rate.
So a pretty stark difference between those two numbers.
Yeah and it's like super cool that we have that data.
That's some of some of the ones that popped out to me.
And yeah when we say accept acceptance rate like usually uh that's something that's pushed by the vendors like Copilot and all of them saying how much you know, code that we suggested to developers that they actually accept.
I think this is even actually more useful.
It's more so saying of all this code that's being generated, how much of it is actually making it into customers' hands or like into production.
And there's such a big difference between the agentic, the assisted, you know, fully developer created.
Uh I know we're going to dive into it, but I really wanted to highlight that one as well.
Yeah and and I mean, when you're thinking about lines of code that is generated by an AI, if you measure that as your acceptance rate, it doesn't actually mean that any of that code ultimately gets accepted.
The developer might just be generating it and then deleting half of it because they don't like it, you know.
Um this is a great that our version of this metric is a great way to understand of all the things that AI is generating for your organization, which of them are actually useful enough to be deployed to production?
Like that's a far more meaningful metric to track.
Yeah, high value metric.
Okay, I know there's a few other things that are different or maybe different in how we're analyzing uh the data.
We already talked about, okay, now there's three types of PRs, right?
There's the agentic AI PRs, there's the AI-assisted PRs, there's the unassisted, so like fully developer PRs.
Um, I think there's something about an AI readiness matrix matrix.
Uh yeah, maybe you talk to us about that and if there's anything else that you want to dive into on the differences.
I'll cover the readiness matrix, but I do want to point out one just just one really interesting factor about those three classifications of PRs that we described.
So again, that's unassisted, that is AI assisted, and agentic AI PRs.
Um, you know, like I said, we wanted to track the differences in behaviors between all of these, and and some examples of what we were able to discover is that for, for example, with AI assisted PRs, they tend to be about two and a half times larger than unassisted PRs when you're looking at the the P75, so the 75th percentile.
Um, but what's more striking is that AI PRs have a pickup time that is more than five times longer than unassisted PRs.
So they're basically waiting idle for review much, much longer than manually generated code.
So again, very stark differences in what we're seeing here.
Um and then on top of that, uh, we've also introduced this AI readiness matrix.
Again, based on Dora research, um, within Dora, within the latest DORA report, um, they have you know these seven categories of success criteria with AI.
You know, a big, a big story they're pushing with DORA is how AI amplifies both the good and the bad.
So if you have, for example, bad version control practices, when you start using AI, it's gonna amplify all those bad sides of it.
So we surveyed a bunch of engineering leaders to understand whether the typical organization has the foundational capabilities.
So there's things like data quality, version control, maturity, clear AI policies, the things that actually takes to make AI successful.
Um, and there's some pretty eye-opening findings around that too.
Like uh, for example, 65% of companies lack dependable data quality.
And on top of that, AI policy alignment is sharply polarized.
So, you know, there is a very big difference between organizations that are strong at this stuff and and not so strong.
Okay.
Amazing stuff.
New report, a lot of new things going on in the world with AI.
The report captures all of the differences.
The first one that I'd like to dive into is what you were giving us, I think a little appetizer on with the unassisted versus the assisted versus fully agentic.
Maybe you can recap again the data behind that.
But I what I want to get into is let's figure out why these uh because the behaviors are like so different there.
So maybe give us a recap of the data and then let's talk about like why that's happening.
Yeah, so it's a recap.
You know, AI assisted PRs are being accepted and merged at about half the rate of manually generated PRs.
And we had a couple of other data points that that sort of indicate why this might be happening.
So again, looking at the P75 level, the 75th percentile, the typical AI assisted PR has about four, has a little over 400 lines of code, which is pretty large.
It's not gigantic, but it is large.
And that's compared to 157 lines of code for unassisted PRs.
Um, and then agentic AI PRs are kind of in the middle at about 290-ish lines of code.
So um, when you think about it, you know, we our one of our recommendations we've always had at Linear B is that um you want to try to keep your PRs below 300 lines of code because that's sort of a chunk of of information that is relatively it's it's manageable for a human to keep all that information in our head and make clear decisions about it and review it promptly and efficiently.
Um so when you have P pull requests that are getting you know 400 plus lines of code, it increases a lot of the mental tax on people who have to review the code.
Um, you know, so people are reviewing more, there's more files they have to look at, there's more parts of the system that get affected when PRs get bigger, and just an overall higher complexity.
Um and one of the and I I really love the qualitative survey we introduced with this report because it does add a lot of flavor to all of the data points that we've been gathering to help us understand why these sorts of things are happening.
So we can't it and the survey questions around this kept coming back to very similar issues.
Like AI tends to make changes that are larger than the scope of what was requested from them.
They're very verbose at times.
Um they often just do more than a human would, uh, which is, I mean, when you think about it, creating more code is effectively free for an AI.
It takes a lot of mental power for a human to do it.
So it's just naturally much easier for an AI to just generate larger volumes.
Yeah, I mean, I I I think the takeaway is like, okay, if I'm a developer, I'm not using AI, my PR sizes are generally smaller.
Probably because, you know, it's pretty intensive to actually code.
You gotta write, think about it, write out all the code.
As a developer, you're usually trying to get like the most done possible with the least amount of code.
I mean, that's really hard hands-on work.
For AI, these PRs in one sense could be getting bloated.
And the downstream impact of that, I'm thinking about quality.
I'm thinking about quality, both from like, I don't know, maybe like bugs and security and that kind of stuff.
But I'm also interested in uh the reviewer portion.
Meaning if a human's gonna go and have to review that.
Now maybe AI is also doing the review, but if a developer is gonna review it, well, my review is definitely not gonna be as good as if it's smaller.
And then you also mentioned something about maybe some scope creep too in there.
Like, is it doing more than it's really asked to do?
Um, it feels like it's putting so much pressure like on the review process.
Is that how you feel about it?
Or like what are your what are you what are your thoughts?
Yeah, I mean that that is the bottleneck right now that I think most organizations that are adopting AI are struggling with the most right now.
So, you know, I already mentioned the the these that AI generated PRs wait over five times longer.
It's it's actually about 5.25 times longer to be picked up for a review.
Um so that's a representation of a little over a thousand minutes, which a smarter person than me would have to figure out how many hours that is uh for AI generated PRs versus about 200 minutes for an unassistant PR to get picked up for review.
But here's where things get really kind of weird.
Um it it will make sense, I think, if we break this down.
Okay.
Once someone starts reviewing an AI-generated code, they it tends to get reviewed much faster.
Um in fact, it's it's uh the typical AI assisted PR gets reviewed in about 194 minutes compared to 252 minutes for manual PRs.
So while they take longer to get picked up, they get reviewed faster.
Okay, well, yeah, we gotta break that that's really interesting.
So the pickup time is longer, meaning, okay, let's say I see that there's a PR out there and it needs to be reviewed.
If it's assisted by AI, it takes longer for that review to actually begin.
But once the review begins, it's actually faster.
Yep.
You have a guess why.
Well, I mean, I I would say that I'll start with the part that makes uh most sense to me.
Because right now we're talking about assisted versus unassisted, but there's that third category of full of fully agentic, right?
That third category of fully agentic, I could see why those wouldn't be picked up as fast because it's like who owns that?
Or like uh code.
This is a good idea.
I don't feel like BLP.
If you opened up a PR that you worked hard on and then it was like assigned to me, and we're buddies, and I know you're trying to get this done.
I have a lot of incentive to go help out my boy, like to okay, I gotta get BLP's uh code out there.
That makes sense to me because there's like a human component in ownership.
Now if AI, which I have no like uh relation to, opens up to me what's a random PR, like I'm not really incentivized to pick it up.
Like that makes sense to me.
Yep.
I'm the only thing that I could say, now let's say BLP, you're using uh assistance in your so let's say that you're using Copilot, but it would still be under your name, right?
When the PR goes up, I would still be incentivized to go get it, but we also said that the PR is larger.
And if the PR is larger in general, me as a reviewer, I'm gonna be less incentivized to want to start that.
That's the only thing I can think of.
Is it that or is there other stuff behind the scene?
You're definitely on to something, uh, and I think there's a little more to this too.
So and again, this is really where it was really great for us to lean on qualitative data this time as well, because one thing that came up in multiple survey respondents was that um, you know, a lot of people are just hesitant to open AI PRs, you know, they're uncertain about them, they're they don't know what the mental load is gonna be on that.
They they they have concerns about trust with the AI.
Like, like is it gonna contain errors or missing context?
And then and then it becomes my problem.
Like if I look at it and I start reviewing it, then then it becomes my problem, you know.
So I think that explains part of why they take so long to get picked up for review.
Um, but then once it once the reviewer does pick up, uh, you know, they tend to just scan for high-level issues rather than like deeply understanding the change.
You know, one of the respondents to our survey said that, you know, a larger amount of our code is slipping into production without proper review.
So rubber stamping.
Like that's what is starting to happen more and more.
Um, and then we also heard concerns about how you know AI often gives up mistaken suggestions and non-working code.
And you know, I've been hearing a lot, particularly in in the last year, about the struggles with trust when it comes to AI performance.
You know, do you actually trust that what it's doing is the right thing and that it has good security and good quality and and all of those factors.
So I really think it is it's a combination of bigger pull requests coming in from AR, AI, the lack of ownership over who that PR belongs to, um, coupled with uh, you know, just this sense that you know it's very challenging to to modify to work with AI after it's already done a thing.
So, you know, it can sometimes be frustrating if you have to repeatedly tell AI that it got something wrong and and push back and have it, you know, continually correct itself.
So I think it's a it's a it's a sort of confluence of many factors that are contributing to uh to this interesting dichotomy between pickup and review time.
Yeah, I think that's one of the most interesting things in the report.
The reason uh that I think it is interesting is if we take a step back, adopting AI only matters for an engineering organization because the promise is getting productivity, right?
On the other side.
Like if you're a CTO, VPE, director, you're adopting these AI tools with the intent that you're releasing more features, releasing more features on time, providing real value, right?
And a lot of this stuff with okay, a gentic PRs are being open, but I think I I don't have the exact data.
Less than 50% actually even make it out to production, right?
And and uh, or maybe you know, there's some quality issues on the other side.
I think like one of the reasons to look at the report is to understand for yourself, okay.
If I have an AI strategy, what are the hiccups that are being seen in the industry right now about actually getting uh that AI code out into production, then therefore, what can I do about it?
I think that's like one of the coolest things about this whole report.
Yep.
I also had an idea to run Bayou BLP.
Oh.
And I don't think, I don't think it's in the report.
It might be.
We said something that was like for the assisted.
Okay, the assisted PRs, right?
The AI assisted PRs.
They're being they're bigger, but they're being reviewed faster.
Is that true?
Yes.
Is there data overlaid on that that also says are those ones being AI reviewed as well?
And the reason that I'm I'm bringing that up is if you're in a situation that, okay, um, let's say that we're using Copilot as an organization and we're using cursor as an organization, and I have the same tool creating code and reviewing the code.
I have a theory that it's not the review is not going to find as many issues.
And therefore, let's say I'm a human developer and I'm going to do the review and I'm really reliant on that AI review.
I might say, hey, it didn't find too many issues.
And therefore I think it's good.
I'm just going to do a cursory overview.
Versus if it's all human created code, and then I have an AI run on top of it in the review, and then the reviewers there, they might see some stuff like, whoa, it found a lot of things, and the review's going to take longer.
So I don't know that it's actually in the report, but I have like a theory a little bit here about okay, if co-pilot's doing both the code generation and the review, it's not going to find too much more in the review, and the review is going to actually go faster.
Yeah, that's that's interesting.
We we don't we don't have data specifically for this, and maybe it would be a good addition for next year, particularly when you consider just how common AI code reviews are becoming.
Um, you know, I've been saying for a little while now that that things like AI code reviews, AI pull request descriptions, those are like the very first like ubiquitous use cases for AI within the SDLC.
Um, even you know, even beyond like code generation, I think if you're thinking about the benefits you can gain from AI, those code reviews are really where a lot of the benefits stack up.
I I think what it really comes down to is the level of trust.
Like, do you have trust that the AI code review that you have on your repos is actually catching things that your team should be taking action on?
Um and if the answer is is no, then you're probably gonna have just as much scrutiny as you did before, and you're probably just gonna ignore whatever the AI code review uh is telling you.
And if the answer is yes, you do trust it, then when it tells you everything's green, you're just gonna say, well, everything's probably green then.
And if it warns you that stuff is orange or red, then you're gonna you're gonna accept that and try to fix it.
So and I think this really just points out, you know, how um your organizational practices are really the thing that defines success with AI.
So if you aren't able to tell your your AI code review or your AI assistants um what your organization's standards, like the the things that you expect all PRs to do, um even down to like the specific components within your tech stack, like how to build with those and how to use them and and your security requirements for all of those things.
Yeah, effectively that.
Yeah, these are the configuration granularity to achieve a level of trust that uh make your strategy actually work.
Like first, you have to have a strategy.
You have to have an AI strategy that allows your workflow from code creation out to production actually be smooth.
If you don't have a strategy, it you'll probably be the same or worse.
And then yeah, all those rules or automations that you're putting in place like that matter so much.
I want to keep on the AI topic because it's probably most interesting, but change uh up a little bit.
What does the report say about type of code created?
Meaning, um, is AI creating a bunch of new code or is it more like doing like bug fixes and that kind of stuff?
Like, do we have any data on that?
Yeah, this this uh this data couldn't be any more clear than the state of that, actually.
Um AI is almost exclusively generating new code.
So when you look at the the P75 of unassisted PRs, they have a refactor rate of about 0.37.
So that means about 37% of the code in the PR is is a refactor of existing code.
Um but with AI assisted PRs, it's almost zero.
It's barely, it's it's practically negligible.
Um, which means that AI is creating a ton of new code paths rather than focusing on improving legacy code.
Um, and it's potentially not helping solve any problems associated with technical debt.
It may actually be creating more tech debt than it is solving for.
Um I think that this is something that may get solved over time as the technology behind this improves, like you just start training the model to be to be more critical about generating new code and to focus on leveraging existing code more.
It's probably also something to say about the context that you feed into these models.
You know, if if you just kind of give it free reins and code generation is a piece of cake for AI, then it's just going to keep creating new code because to it to an LLM, it doesn't matter how much code you have.
So yeah, it's this is one of the areas where it's you know, you every organization should understand at this point that AI is probably generating more new code than your organization has ever seen before.
Yeah, that's really really interesting.
Let's see if we can dive in there more.
So do you think it's because okay, so AI is definitely generating new code as compared to like cleaning up tech debt?
That's a that's a takeaway.
Okay.
Do you think it's because that's what it's being instructed to do?
Like the rules and the prompts and that type of thing.
Is it because that's what it's better at?
Like it's better at creating new code versus looking at existing code and modifying it.
Or do you think it's like, or is it something else?
Like I'm trying to just like uh, or is that how I don't know, us humans as developers are saying, like, hey, what I need the most help with is actually creating a bunch of new code, like I can go and refactor stuff on my own.
I'm trying trying to understand it.
I think it's the the the opposite of your first idea.
So it's not being instructed to create new code.
It's it's instead not being instructed to focus on using let existing code, right?
Yeah, this is where if you just take AI and throw it at your code base, it doesn't care what exists today unless you tell it that it needs to care about that.
Um I think that's really one of the challenges that most engineering organizations will need to solve to really see the big productivity gains, like this type of challenge, like that granular configurability of if you're gonna use this library, you have to access it this way, or if you're gonna do this type of function, yeah, you must use this library we've already created for it over here.
Um so that way if it encounters issues trying to implement that stuff, it's doing it within the the framework of your organization, and instead of just saying, well, I'm just gonna do it all new because that's the easiest and the quickest way to solve the problem.
Yeah, so it's like getting all the context.
Like first giving AI, okay, here's all the context.
Here's uh all these different uh here's here's our policy of how we work at this company.
Here's how we use these libraries.
So make sure you you're saying it's more like feeding all of that in, is what would be needed.
Uh most companies are probably not doing that or were maybe not as good at it yet.
Therefore it's it likes doing okay you're telling me to do like green field stuff like build from scratch type of thing.
Yep.
Yeah if if prompt engineering were the phrase of the last year, I think context engineering is the phrase of the next year.
So instead of focusing on better prompting and and all of that, you should be focused on the context that you're building and supplying to these models because context can be can be applied universally it can be applied granularly it's it's really the thing that is going to determine success when you're adopting AI.
And this actually gets in if I can just go straight into my next point on AI readiness because this merges perfectly into what I wanted to talk to you.
Go for it.
On that so you know we we we serve it as a part of our survey we um you know we borrowed from the door research where they have their seven categories of AI readiness.
We condensed it slightly down to six just because we already had a a pretty large survey um and we we asked, you know, these engineering leaders that responded on it on a series of uh uh challenges that every organization faces.
So things like version control practices, delivery habits, internal and plat internal tooling and platform reliability.
Um, these are all things that you need to be good at to be successful with AI.
Um and we just asked, you know, how robust are these systems for you.
So, for example, we asked, um, do you have clear and communicated AI policies?
And for that particular one, uh, we had very polarizing responses.
Um, so about 60% of respondents believe that they have a clear AI, at least somewhat clear AI policy, while about 26% believe the opposite, and then about 14% were somewhere in the middle.
So this is sort of like one of the first steps that you really should have on your AI readiness journey, so to speak.
You know, just telling your developers like what tools are approved, how should you use them, how do you request new tools, where are we applying AI within our SDLC, those types of things.
And then the other one, getting back to our narrative of context that we keep talking about, um, a majority of organizations indicate that their data is not ready for AI models.
About 65% of organizations say they have data data problems.
And I think this is honestly probably the biggest challenge of 2026 for even just putting engineering aside.
I think anyone who is trying to adopt AI, whether it's for software engineering or marketing or sales or customer success, whatever it may be, if you don't have high quality data that provides the context that the AI needs for whatever sort of problem you're trying to solve, you're gonna you're going to encounter significant issues.
This is where hallucination becomes a problem.
This is where bad results become a problem.
And this is the type of thing that erodes trust in AI.
So clear and communicated AI policy and data hygiene and availability.
Those are the two big challenges that I think uh the industry as a whole is facing right now.
This report is so freaking cool.
I guess it's like, you know, all based on this AI revolution that everyone's in.
But like I love how it has the data and then also the qualitative responses from the leaders and stuff.
Like that was like really hooking me while I was reading through.
So now, you know, we talked a lot on numbers and that type of stuff on the pod so far.
As we're moving into, and maybe we're in like planning, maybe we're in the planning mode, I'm an engineering leader.
I know I gotta get this AI stuff working for me.
Um, not just doing stuff, but actually getting to an output.
What are your thoughts on uh the things I should be focusing on or any like uh things that I might trip me up as an engineering leader?
What should I be thinking about?
Yeah.
So, first of all, don't confuse adoption with impact.
Just because everyone is using AI today, it doesn't mean that you're getting real value from it yet.
Uh, you know, except as I mentioned, 88% and other studies have said somewhere like around 90 to 95% of developers are using AI every week at this point.
Um, adoption is basically universal, as I I mentioned, but impact, productivity gains, they aren't yet.
So you need to measure things like like acceptance rates, you know, our version of it, where you're measuring the amount of AI code that's actually making it into production.
Um you need to measure your review patterns, like where are the bottlenecks showing up, what what are causing what things are causing the biggest bottlenecks uh within your teams?
And then what are your actual delivery outcomes?
Like, are you delivering more features to your to the company to the to your customers or whatever whatever sort of business outcomes your your executives are concerned about, is AI actually supporting uh those needs rather than just focusing on you know raw usage statistics.
And then the other point I'll make is that you know, you need to fix your foundations before scaling AI.
Uh looking at this AI readiness, and we're gonna have a lot more content around this concept of AI readiness, AI enablement over the coming months because we think it's a really important topic right now.
But you need to fix all of those foundational problems, like high quality data, clear policies, reliable internal tooling.
If you have all of those things, AI will amplify the benefits of them.
And if you have problems with them, AI will amplify the problems that they create.
So it will make the worse worse and it will make the best better.
All right.
So those those are the two things that I I think every engineering leader out there should be focused on uh for the next year.
Yeah.
I uh that all makes sense.
And I I guess what I I would add on, like my takeaway is I also think 2026 is gonna be a year or uh around quality.
And what I mean by that is, like you said, if AI is amplifying everything, it's also creating bigger PRs.
It's also maybe doing some scope creep and creating things that we don't even need from the story and that type of stuff.
What we're focusing on at Linear B, and what I would encourage all the listeners is to think about quality.
So for example, how many security issues are now being created by AI?
How many bugs?
How many maintainability issues?
Is our tech debt uh getting bigger or smaller?
And then the last thing that I would re-emphasize that you said BLP is yes, the impact is super, super important, but also can I start giving AI more uh context so that it's doing the right thing more often, which then would reduce the quality problem.
So that would be my concern or the thing to to watch out for.
Just because it's doing more doesn't mean it's doing better.
Exactly.
All right, cool.
Is there anything else that we need to hit on before we go to the outro here?
Uh no, I just just want to remind our listeners, go read the report.
It's it's 48 pages, packed with tons of data that we a lot of which we weren't aren't even able to scratch the surface on in this short podcast episode.
Um we love producing this.
It's we always learn a ton ourselves as we do it, and I know our audience does as well.
So yeah, go download the report, check it out.
You'll learn a lot.
All right.
Alright, well, thanks so much, Ben.
Yeah, this this year's report, it's a total uh game changer.
Yeah, it's not just about benchmarking performance anymore.
It's also about all the stuff we talked about, understanding how AI is fundamentally reshaping software delivery.
If you or your team want to see where your metrics stand and understand how AI is impacting your organization, be sure to check out the 2026 Engineering Benchmarks report at linear b.io.
We'll definitely put a link in the show notes.
Uh thanks again, Ben, and thanks everyone for listening.
We'll see you next week.
AI is everywhere in software engineering, but most teams still can't prove its impact.
That's where the Apex framework comes in.
Apex is a new operating model for engineering productivity designed to measure AI where it actually matters at the pull request level.
It connects AI activity to delivery outcomes, not just tool usage.
Apex is built on four pillars with AI leverage, predictability, efficiency, and developer experience.
Apex helps you increase throughput without sacrificing delivery confidence or burning out your team.
Because speed without predictability creates chaos and faster coding often shifts bottlenecks downstream.
If you want to operationalize AI the right way, Linear B and Apex gives you the system and the cadence to do it.
Download the guide and start measuring what matters.