Nobody is shipping your agent’s code (yet) | Predictions from LinearB’s Ori Keren

0:27Ben Lloyd Pearson And, you know, of course, we sat down with you last year and I actually have to give you like credit for your prediction. You know, it was a little bit contrary, maybe a little controversial, but I think it turned out to be spot on. And before we get into your predictions for 2026, you know, I don't look back on last year and when everyone was hyping up how like AI was going to 10x engineering and your engineering output. And you went on record and said that productivity would actually go down in 2025. And like I said, I think that was a great prediction. And I want to ask you about that.

1:00But first, I wanted to see if you had any bold predictions for this next year. Yeah, I hope it is as bold as the old one, as the previous one. But I think my prediction is that it's still going to be very interesting in code generation. New stars will pop up and new hype will be there. but we're still not going to see the 2x 3x like uh productivity improvement that everybody's expecting to so that's my prediction maybe not as bold but i still believe that this is a year of like uh norming if you will like uh before we get that uh promise yeah well i mean if you consider we may be in peak hype that may be actually a pretty bold statement to make right now So I got a lot of questions that I want to ask about that.

1:51But first, I just want to give you a chance to reflect and look back on what we shared a year ago and just see how things have played out in that time. So, you know, one of the big arguments that you made back then is that the friction of adopting new tools and the natural resistance to change would slow teams down before it sped them up. And like I said at the top, you described a dip where teams would have to figure out how to work with this new technology before they actually receive many of the benefits. And looking at the state of the industry now, do you feel vindicated? Do you think we actually went through this productivity dip?

2:25Yeah, I actually think we did. Or at least we stood still in the same place. You can look at data that is out there. we see that there's like 30 % more pull requests, for example, that are being created. That's great. But as you go downstream at the development pipeline, you see that it's actually maybe 2 % more that are being released because there's a lot of gates that it's being stopped. We saw, I think, as an industry, a decrease in the stability and the quality. There's research that's talking about it. I think DORA, the DORA metrics are speaking about like 7.2 or something like that, decreasing the stability.

3:09And qualitatively, people are talking about it. So I think if you balance all of this, we actually had this deep or at least like we stood still and we're still learning how to utilize these tools, right? Yeah. And I really like that you brought up DORA because, you know, I think the research report that came out earlier this year really did is a big part of the vindication. because one of the statements they made was that upstream velocity increases are lost to downstream chaos. So even if you're moving faster, there's still so many other aspects of our SDLC that haven't been impacted in the same way by AI.

3:44Yeah, I absolutely agree with that. There's so many factors, and we can elaborate on that later, but it's almost like going back to SDLC fundamentals. like what are the phases, where does AI really play, where does it give us the productivity gauge, and where does it hurt us or take us even back? You know, last year you also made a bold prediction around our adoption of AI agents, and you were spot on that 2025 would be a year of experimentation versus full adoption. But now that we have spent that full year experimenting, is 2026 the year that we hand over the keys? Yeah. Yeah, unfortunately, I think probably you're going to be a downer here as well, because I think one of my favorite quotes is like a box CEO, Aaron Lira.

4:35I think he told once that it's not about how fast the technology progresses. It's about how fast enterprise can adopt workflows and processes. So the technology is there. But you know, like the merge rate of Agente code is like around 20%. maybe you get it like to 35 40 percent if you're elite so and enterprise are not ready to go uh let agents write the code and other agents check the code for quality and let it go all the way through so i think agent like definitely like uh there are like early adopters who are doing amazing things with agents definitely when you go zero to one right you build uh you're up for the first time It differs between that to enterprise software that has tons of microservices out there and you need to maintain the quality.

5:26So it's different. I think, again, that technology is amazing and it's there to create code. But handing over the keys, it's not a technology question. It's, again, enterprise workflow and processes question. So unfortunately, they're still not ready. There's steps to make still. That's so spot on because it's not a technology problem. It's a communication problem. a human problem at its core. And I think that's what everyone has spent 20, 25 grappling with as technology comes in and it exposes these core communication friction points and problems within your org. And that's actually what people are going to have to spend time fixing.

6:03Absolutely. You phrased it? Perfect. Well, you might be referring to yourself as a downer. I call that being pragmatic, actually. I agree. And I've been, regular listeners of Dev Interrupted to know that I am frequently arguing about how the application of this technology is the most important thing right now, that the capabilities of it is already quite good. We just need to apply it to all the aspects of our SDLC. And, you know, one place that is being applied a lot is, you know, within the IDE. So one of the things that you discussed last year was how there was this risk of losing the spark, so to speak, of creativity, if developers rely too heavily on AI to generate code and you know we've we've gone through about a you know a year of heavy usage now like are you seeing that loss of creativity or have developers still found a way to continue being creativity despite all of these tools yeah uh here i think i missed by the way because um i've seen like senior developers and even product uh you know managers and people are doing this thing where you can switch modes okay like uh when i'm in this mode of like enterprise work and i need to get things done yeah i need to work in a more organized way but actually when i'm switching into creativity mode and i could do some vibe coding it actually uh i missed there because even myself like i experimented with that and you can see like that you didn't lose like that's part of creativity you just need like to understand in which mode you're operating so i think uh thanks for all the compliments that i hit spot on in the beginning I think here I missed.

7:41I actually missed. Yeah, that's a great admission, actually. And, you know, I certainly have felt that just personally. Like, you know, when I'm in those more creative modes with AI, it does really allow me to think bigger than I've been able to think before. You know, and it's a pretty great feeling. I think AI has actually, like, enabled my output and my ability to be creative more than it hindered it. Like, instead of it being a spark, it was like a whole fire. and I could turn ideas into prototypes so fast that the math on building everything changed overnight. So I think it actually increased my productivity.

8:19It makes me think of, like, you know how like you have like inventors and like people invent things that are pragmatic and useful, but you also have people who invent like useless things or things for fun and things for show and things to teach. I think suddenly code had that revolution overnight where people build code for pragmatic and useful reasons, But now you can build code for fun, to experiment, to teach, to learn, to explore. And that's like a whole new modality. I think you phrased it perfect. And my concern was that I actually think that coding and building is actually very creative work.

8:50And I remember when, you know, coding very earlier in my career, like you start to write things. And as you get into the zone, like, yeah, well, maybe I can have, you get ideas that are like bottom up. It didn't come up with them. you're actually maybe tasked to do something else. I was afraid that you would lose that. And you're right that like, I think like, again, when you switch modes or okay, I'm not like now in enterprise mode, I need to deliver this feature. You actually give yourself artistic freedom for ideation. AI enabled you to do that like much faster and actually amplify that. All right.

9:28So that covers the recap from last year, both the good and the bad. and you've already previewed your thoughts on 2026, but I'm wondering what ROI looks like for AI in 2026. So we've got a lot of engineering leaders out there now who are looking for a return on their investments into AI. Is this a year that we finally figure that out? Even if we're not going to see a 2x or 3x improvement by what you believe, is this still a year that ROI starts to become a thing that engineering leaders understand? I think engineering leaders would work harder at the beginning to say, hey, how does success and how does ROI look for my organization?

10:14If they're doing themselves a favor, that's what they need to do early on. And I think, unfortunately, there's a lot of like, well, there's tons of data points, right? So you can have some politics get into it. And what am I measuring to prove my ROI? so I think this is a year where every engineering organization will go through this question how do I measure like the success and the ROI and I think this is like I told you at the beginning if you if leaders do a good job in defining success and how they measure ROI which can differ by the way from there are the basic things but they it can differ from one org to another depending on stages the company is in etc people will start uh talking in these terms and start showing hey you know you know what i'm actually getting like uh an ROI but again i think it will still stay in the unfortunately on the single digit like uh productivity gains like five percent eight percent something like that so definitely here where you can start showing it uh especially if you do a good job at the beginning defining it thinking about it internally exposing it externally to stakeholders people i think i think this is the year that people will start seeing it but again just the beginning i want to talk a little bit about how the developer experience has also evolved and changed this year especially the tooling the dev workspaces how people get their work done on a day-to-day basis as software engineers now has fundamentally changed and In 2025, we saw a shift from more like chat-like interfaces to more composer-like ones where we've gone beyond the world of autocorrect or autofill and autocomplete for tab completing code.

11:59We moved into the chat era of having the chat window generate your code alongside you. Now we're moving into a composer mode where you have multiple agents maybe working in parallel or sequentially, and you're maybe even looking less at the code than you did before. Evolutions of coding tools like cursor are making that chat and that composer experience first class and hiding away the code in some cases so you know how do you think that this change in developer tooling will impact 2026 and what do you think we can expect to see you have to admit that i think that we're going to see more um innovation around that there's like maybe another move like into web interfaces where I activate a bunch of agents, et cetera.

12:44So there's going to be more innovation there. But again, if organizations really want to see the productivity improvement, they need to start thinking about how to apply AI. It's not just AI, but like smart decisions further downstream. So for example, I'm getting really excited. And if like organizations will start to think about, you know, reviews and quality instead of just, hey, this is how we do code review. We review every piece of code. Maybe do it. Change risk analysis and decide where you deploy AI, where you use humans, stuff like that. I think if people will move from manual deployments or CD to sometimes to AI-driven canary deployments and automatic wallbacks, et cetera, that will actually move the needle in developer productivity much more dramatically than any other change that you will get in like, where it's like how you generate the code.

13:43Unfortunately, I think the universe and the industry will stay focused on, because LLens, that's the problem that they know how to solve and everybody gets excited. Exactly. And the industry is so vested into it. So I think there's still got to be improvement there. They won't move the needle. And what we moved the needle in SDLC is, I think, the stuff that I spoke about. That's fascinating. And we're going to talk more about how AI is going to impact the rest of the SDLC in closing the delivery gap. And, you know, I think what I'm hearing from you here is that it doesn't matter how shiny and new and reinventive we recreate the ways that developers make code.

14:22The center of gravity in our industry right now is around code generation. But there's a lot of problems in delivering software that can and needs to be solved by teams with working with AI. So that's a really great kind of insight into how next year might look. And Ori, looking at the economic climate as well, you know, engineering leaders, when they're in an environment where they're making these decisions, they're pretty, they're under a lot of pressure, like immense pressure from above and below. You have developer teams that have varying degrees of wanting to adopt the tools. You have your executive leadership with varying degrees of appetite and taking on new AI experimentation.

14:57And you're stuck in the middle navigating that as an engineering leader. So do you think that in 2026, the budgets will start shrinking back, that the growth budgets are going to change from last year, where it's buy every tool, experiment with everything, see what happens? Now that we've had a whole year of that, what does that mean for a budget cycle in 2026 for these engineering leaders? I think that in terms of economic and the way engineering didn't need to prepare for this year, it's more of how things were like last year. I don't think like where you're going to see a lot of like oh let's put more budget into growth like hire more engineers more AI tools etc I think because we spoke about like the deep or at least like at the beginning or we maybe stayed in the same spot and we spoke about like even if we improve like single digit I think the main issue is like this big expectation gap that exists between like these maybe executive that are not tech first or at least how the industry really expect like, oh, when this is like 3x, 4x coming to the single digit and this will put more economical pressure on like engineering leaders to do more with less and it will stay the same.

16:18Unfortunately, that's what I think will happen. So we won't get like much more budgets. The expectation to do more with less will still be there. will still under deliver because, again, I think, as, again, an ex-VP of engineering, getting, like, 5 % to 8 % to 10 % improvement is amazing. It's amazing. But it will still, like, won't impress, like, because everybody wants this 3X. Right. So that's why budget will still be, and macro, et cetera, and other reasons, that's why budget will still be constrained. Ori, I feel like I am surprised almost on a weekly basis by all the new things that happen in the world of AI and new technologies.

16:59With that said, what technologies or trends do you think have a chance of surprising engineering leaders in the next year? If we think about surprises, there's two interesting areas. One is that supply chain. I think there's going to be like these cases where big outages are going to surprise engineering leaders. Not necessarily because of security, you know, is in the supply chain but uh we've seen more and more dependencies in like software that's not like created in-house that all of a sudden a change a small change there explodes in a very glorious way and it causes outages i think we'll see more uh more than these things and i think everybody's mindset to this uh supply chain is like thinking about it like again from the security perspective and not from okay like this library changed something and then half of the world is not working like uh we've seen one or two like incidents like that's that's one thing and i think the other uh surprise that could be positive or negative is like the technology around ci because uh and and what i see with ci is like and i think uh a lot of like engineering leaders would agree with me it came back to this like plateau of like uh more coverage and more tests are not producing more quality um and it's actually the flakiness and the instability of this system that were designed like years ago uh are slowing like uh the you know engineering teams down so i think there could be like negative surprises there like okay i'm blocked like i can't released now for a week or two because like my infrastructure is not stable or a positive surprise is like new technology and new innovation that will make smart moves there that could accelerate.

18:51These are the areas and of course there's like you know quantum computing and everybody talk about I think like it's still it's going to be a conversation in 2026 in you know for CISOs and security that prepare, but still not like the thing that caught people by surprise in 2026. Hopefully I'm not like sitting here in 2027 and say. We'd be in a very different world, I think. Yes. But who knows? And, you know, we've been covering quite a lot here on Zav interrupted, like some of these new security concerns that are arising from AI usage, you know, things like poisoning models to recommend malicious packages and prompt injecting within products.

19:34There's a lot of just new things that we've never really viewed as like a security risk that are just like a new category of problem that we have to face. But I want to shift gears to another specific problem that we're seeing in the market right now. And that's this gap that's forming between how fast AI allows us to generate code and how quickly we can ship it to our customers. Coding obviously has sped up dramatically, but things like reviewing and testing code haven't kept pace quite as well. So for 2026, Ori, I'm curious, do you think that, like, is the biggest bottleneck going to be the code review process?

20:12Or are there other things that will also start to appear within the SDLC that are bottlenecks for AI-driven teams? Yeah, I think it's going to be in phases, and it depends on how early adopters teams are. But definitely, okay, let's say if you look at the phases of, the classic phases of SDLC, you write the code, then you need to get it merged. definitely a big big bottleneck that exists now in sdlc uh people uh i think this is the year where again we're talking about technology and we're talking about processes and workflows i think this is the year where technology is like getting better by the way not just as a code review tool because uh we talked before about the challenges over security incident come in but we're also talking about quality problems so i look at like i think that sometimes in industry we call code review as a quality gate sometimes it's like uh silent it could be silent by the way sometimes it could be uh not silent like active that that prompts the developer hey we spot a bug here so i think it's the year of like uh code reviews like definitely or quality or bug hunters, definitely taking like a front seat in SDLC and being adopted and leaders will think about, one, how do I do it in a smart way?

21:32Am I letting like an AI agent review the code of what another agent wrote and going back and forth? I think there will be brave organizations that will start making this decision with risk analysis, etc. But even if you're not going all the way there, I think people will need to assess the quality of the code where it's active in the face of developer or not necessarily active in a silent mode on every pull request basis and produce measurements and keep on improving. So yeah, it's the year of code quality, if you will. And then one instance is code review. Another instance is measuring it and creating a feedback loop to improve how you use the AI tools.

22:20Definitely see this as where it's being fully adopted. If AI is writing more of your code, who's actually reviewing it? You wouldn't let a developer approve their own pull request, so why let the same AI tool that generated the code be the one that reviews it? Linear B gives you an independent AI code review separate from Copilot, Cursor, or whatever tool wrote the code in the first place. It flags logic errors, subtle bugs, and security issues the original AI might miss before your human reviewers even step in. And it auto-generates PR descriptions, so nothing ships without context. No blind spots, just a real second opinion on every PR.

22:59I want to zoom in on that anecdote for a moment, of the idea of like AI agents generating code that other agents are then reviewing and maybe making that decision based upon some risk analysis. And that involves acknowledging that code comes at different levels of risk and quality and need out of the gate, right? And so code can't be treated in this one-size-fit-all way anymore. And in fact, with AI, in generating the code, we also have the ability to then improve our systems around understanding and shipping that code. So do you think that 2026 is a year where teams move away from having these rigid, legacy, one-size-fit-fits-all pipelines, and they started maybe building or adopting more dynamic workflows that change based on the level of risk for the code?

23:46And who wrote it? Absolutely. I think the teams will need to have smart pipelines and take smart decisions, especially around review and merge. Do a risk analysis, decide what are you doing with this code. Do you let an agent review it and go back and forth? Where do you let that code get merged automatically? you need to put it in the framework of enterprise policy because remember that's what's slowing us down not the technology and i think this is there where people will automate like okay define their policies and then will want and implement tools that help them like automate and implement those policies both in review and merge but also in how you run tests and like we said like more coverage now I think reached like a plateau.

24:35More coverage doesn't mean more quality. So what do you do different there in CI? Where do you choose like smart decisions? What smart decisions are you taking there and what to run, et cetera, conditionally? And how do you handle all this flakiness? That's right. Definitely the year where automation, like if organizations that choose, think about it in advance, decide on their policy, choose tools like to implement it like automation workflows. will be the, these ones will like hit jackpot. These are the ones that will get like a high productivity increase. So I want to address a problem that we hear quite often with engineering leaders today.

25:16And that is, you know, they're looking up their pipeline right now and they're seeing that their developers are using AI to generate, let's say 50 % more code. However, they're not always seeing more features being shipped as a result of that. if you're an engineering leader that's out there listening to this, Ori, what is the advice that you would give as the first lever they should pull to start closing that gap between the increased velocity of code but a lack of velocity increase for impact and features? Yeah, I think it's going back to what we said before. Define your policy on where are you willing to take risks, calculated risks.

25:58Like where do you break some of the old paradigms? Like we said, one size fits all. I have three reviewers looking at every piece of code, every pull request that's coming in. No, okay. In some cases, it's okay for an agent to review the code. So definitely pull that lever. Decide like on new policies and new ways on how you review and merge the code. That's the second phase, by the way, after writing the code, right? And by the way, you need to take smart decisions. I think you need to choose a vendor that sees everything until downstream. If you stay in code generation and you don't see, hey, how does that impact my microservice that sits there and how does it interact with others and how does that affect my change failure rate and other metrics and my rework and my quality, you just need a code review for the sake of code review.

26:50So also choose the right tools that see the downstream impact. That's the first lever I would pull. and I'm going back, maybe it's boring to the same answer from before. The second level I will pull is like smart decisions in, you know, CICD systems. I think like it will move like, you know, chronological order by the phases. I think if last year was the year of code generation, again, we'll continue to hyper on code generation. This is the year where like smart policies will get into how we do review and merge code. And then we get, okay, some extra throughput. gains. Yeah. And I think one of the best gains that a team can get from, from approaching it this way is that, uh, you know, you don't have to boil the ocean.

27:35You don't have to solve all problems at once with AI. You can pick the, the painful parts of your process that, that are not creating big bottlenecks and focus in and solve those. And, you know, it's not going to 2X your output, but it will, it will solve a problem that might be consuming five or 10 % of your team's time. And if you can just solve multiple problems like that, then that does add up over time. So the last topic that I want to talk about today is AI enablement, ROI, executive reporting, you know, all of those really big, important stuff that a lot of engineering teams are grappling with right now.

28:10So, you know, in 2025, basically everyone bought AI tools, rolled them out into their teams. And, you know, now we're all facing this critical question, like, how do we actually know if these tools are working? Like, are they improving productivity? Are they improving quality and efficiency? And one of the biggest challenges that we're hearing is that it's really hard to distinguish between AI adoption and AI impact. Like we know developers are using Copilot and Cursor, but we don't, it's hard to actually prove those tools are improving delivery. So do you think in 2026, like is AI impact like going to be the focal point of a lot of engineering teams?

28:48Oh, absolutely. I love this question. And I want to answer a couple of phases. First of all, I think even if you think adoption, it's not a yes, no question. Are we adopting? Yes, no. it's like what are we adopting um in which things and what's the level of adoption first of all that's also not like a full solvable problem uh because it's i think like again the metrics that like the vendors uh that that produce that generate the code give you is like uh unfortunately are a vanity metrics oh like a lot of interactions with this a lot of inter uh who cares like uh Did it really create like a pull request or a value that get all the way to production?

29:27So first of all, adoption is an interesting question. But you're spot on that I think like the people will move from just measuring adoption to measuring impact. And here it's really interesting. I think the way to think about it, one way like to think about it at least is that there's a funnel here of like, hey, code is being written. and a pull request is a, it's reviewed and merged. It's past CI and CD. It's ready to deploy. It's out in production. I don't know, feature flag enabled, et cetera. Now, if I think about like, even take like a very famous metric, like cycle time that we used to like break into segments and we look at the velocity, you know, between, okay, coding to how fast it reached production.

30:12There's a new interesting statistic that within AI Impact that is like, what's the drop-off also? That's why I'm saying it's a funnel. So it's not just how fast do I move, it's how much like pull requests I lose in the way because, okay, a lot of work created, how much of them got merged, how much of them really got to production, et cetera, et cetera. So I think like in order to measure impact, people need to realize that there's a funnel here. At least that's at least how I think about it. What's the drop-off like in those phases, not just the speed. And then there's a quality question. After we look at all of this and we improve all of this and there's like the, let's look at the final quality score, right?

31:00Like how many incidents did we have? How many bugs did we have? We need to keep track that it doesn't get hurt. So definitely a year where measuring AI will be like a major thing. I agree to move from adoption to impact. And it's really important for leaders to establish an agreement with their peers and their businesses on what does impact look like? How do I measure, establish it early on and be consistent on measuring it? Something Ori just called out is how hard it is to separate AI adoption from AI impact. Knowing that AI reviewed a poll request doesn't tell you whether it actually helped.

31:41Linear B's AI code review metrics dashboard shows what really matters. You see every bug, security issue, and performance problem AI flags. And with suggestions, developers actually accept. Over time, you can spot patterns across teams and repositories and see where risk keeps repeating. These aren't vanity metrics. They're trust signals. If you're being asked to prove whether AI code review is worth the investment, Linear B gives you the evidence to answer that question with confidence. I love that example you gave of the developer generating a lot of code. And, you know, along the way, does this word request go away?

32:17Does this pull request go away? When it gets delivered, does it get rewritten and refactored later? Did it cause an incident? How many bugs were in it? Like, these are still not only like unknowns, but people aren't even looking at them yet, which is fascinating. And I think it's like a big opportunity. It's like if a tree falls in the wood and no one's around to hear it, did it ever make a sound? if ai generates a pull request and no one ever reviews or merges it did it ever exist you know it's a yeah very familiar challenge yep yep and and you know i want to take that into my next question about how this is something we've been kind of talking about this entire conversation like this velocity paradox of like oh you have more code so you can ship faster well no there's a lot of other steps and bringing code to production to actually shipping it and creating value but But the center of gravity in our industry right now, it being in code generation, everyone's staying fixated there.