# 2026 Engineering Strategy: Closing the AI Delivery Gap

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

## Transcript

Hey everyone, it's your host Ben Lloyd Pearson.
I'm here today with Andrew Ziggler, and we're joined by Ori Karen, co-founder and CEO at Linear B.
Ori, it's always wonderful to have you on our show.
It's great to be here and it's fun for me too.
Yeah, we we love getting your predictions every year.
So it's a an annual tradition, I feel like at this point to have you come on our show and just share what you think the next year looks like for engineering leaders.
And you know, of course, we sat down with you last year, and I actually have to give you like credit for your prediction.
Uh, you know, it was a little bit contrary and maybe a little controversial, but I think it turned out to be spot on.
Uh 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 gonna 10x engineering and uh 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 uh I want to ask you about that.
But first, I wanted to see if you had any bold predictions for this next year.
Yeah, I I hope it is it is as bold as the old one, as the previous one.
But I think uh my prediction is that uh it's still gonna be very interesting in code generation, new stars will pop up and new hype will uh will be there.
But we still not gonna 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.
Uh so I got a lot of questions that I want to ask about that.
Um, but first I just want to give you a chance to to reflect and look back on what we shared a year ago uh 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 uh where teams would have to figure out how to work with this new technology before they actually like receive many of the benefits.
And looking at the state of the industry now, like do you feel vindicated?
Like, do you think we actually went through this productivity dip?
Yeah, I I actually think uh we did, or at least like we uh stood still in the same in the same place.
Uh you can look at data that is out there.
Uh, we see that there's like uh 30% more pool requests, for example, that are being created.
That's great.
But as you go downstream at a development pipeline, you see that it's actually maybe two percent 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 uh Dora uh the Dora uh uh metrics are speaking about like uh 7.2 or something like that, like decreasing the stability and qualitatively people are talking about it.
So I think like if you balance all all of this, we're actually head this deep, or at least like we stood still and we're still learning how to uh uh utilize these tools, right?
Yeah, and 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 you know, 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.
Yeah, I absolutely agree with that.
There's so man there's so many factors, like uh it's almost like uh and we can elaborate on that later, but there's it's almost like going back to S DLC fundamentals, like what are the phases, where does AI really play, where does it give us the productivity gaze and where they uh 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, it's 2026 the year that we hand over the keys.
Yeah.
Uh unfortunately I think uh probably you're gonna be a downer here as well because um uh I think uh one of the my favorite quotes is like uh box CEO, Aaron Leva, he told, I think he told once that like the it's not about how fast the technology progresses, it's about how fast like enterprise can adopt like uh workflows and processes.
So the technology is there.
But you know, like the merge rate of a Genty code is like around twenty percent.
Maybe you get it like to thirty five, 40 percent if you're elite.
So an enterprise are not ready to go uh uh let agents uh write the code and then 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 your app for the first time.
So I guess it differs between that to like enterprise software that has like tons of microservices out there, and you need to maintain the quality.
Uh so 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 uh and again enterprise workflow and processes question.
So unfortunately, they're still not ready.
Uh the steps will make still.
Yeah.
That's so spot on because it's not a technology problem.
It's a communication problem, it's a human problem at its core.
And I think that's what everyone has spent 2025 grappling with is technology comes in and it exposes these core communication friction points and problems within your org.
And that's actually what people are gonna have to spend time fixing.
Absolutely.
You phrased it perfect.
Well, well, you might be referring to yourself as a downer.
I call that being pragmatic, actually.
And I and I, you know, I've been uh regular listeners of Dev Interrupted know that I am frequently arguing about how the application of this technology is the most important thing right now.
The the 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 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 uh to generate code.
And you know, we 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 creative despite all of these tools?
Yeah.
Uh here I think I missed, by the way, because uh uh I've seen like senior developers and even product uh, you know, uh 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 can do some vibe coding, it actually uh I miss there because even myself, like I experimented with that and you can see like that you didn't lose like that spar of creativity.
You just need like to understand in which mode you're operating.
So I think uh thanks for all the compliments uh that that I hit spot on in the beginning.
I think here I missed.
I actually missed.
Yeah, no, that's uh that's a great admission, actually.
And you know, I've I certainly have felt that just personally, like, you know, when I'm in those cre more creative modes with AI, it does really allow me to to to think bigger than I've been able to think before, you know, and it's a pretty pretty great feeling.
I think AI has actually like enabled my output and my ability to be creative more than it hindered it.
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.
It 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 for 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 uh perfect.
And uh my concern was that I actually think that coding and building is actually very creative work.
And I remember when you know coding uh very earlier in my career, like you start to write things as is and as you get into the zone, like you get, oh maybe I can have you get ideas that are like uh bottom up that you you didn't come up with them, you actually maybe tasked to do something else.
I was afraid that you would lose that, and you're right.
That like uh 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 uh amplified that.
All right, so that that covers the recap from from last year, both the good and the bad.
Uh and you've already previewed your thoughts on uh 2026, but I'm I'm wondering what ROI looks like for AI in 2026.
So if you know we've got a lot of engineering leaders out there now who are looking for a return on their investments into AI.
Is is this a year that we finally figure that out?
Even if even if we're not gonna see a two or three X improvement by by your uh by what you believe, is this still a year that ROI starts to become a thing that engineering leaders understand?
I think um engineering leaders would work uh harder at the beginning to say, hey, how does success and how does ROI look uh for my organization?
Uh if they're doing themselves a favor, that's what they need to do early on.
And I think there's uh unfortunately there's a lot of like um, well, there's tons of data points, right?
So uh you can have uh 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 uh measure like uh the success uh and the ROI?
And I think this is like I told you at the beginning, uh, 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 dependent on stages uh the company is in, etc.
People will start uh talking in these terms and start showing, hey, uh, you know what?
I'm actually getting like um an ROI, but again, I think it will still stay in the unfortunately on the single digit like uh productivity gains, like 5%, 8%, uh something like that.
So definitely a year 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 uh 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 is fundamentally changed.
And in 2025, we saw a shift from more like chat-like interfaces to more composer-like ones, where you we've gone beyond the world of auto-correct or auto-fill and auto-complete for tab completing code.
We 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?
I have to admit that I think that we're gonna see more um uh innovation around that.
There's like maybe another move like it into web interfaces where I activate a bunch of agents, etc.
So there's gonna be more innovation there.
But again, if organizations really wanna see the productivity improvement, they need to start thinking at how to apply AI.
It's not just AI, about like smart decisions further downstream.
So for example, I'm I'm getting really excited in if like uh organizations will start to think about you know, reviews and quality instead of just hey, this is how we do code review, like we review every piece of code, maybe do a change risk analysis and decide where you deploy AI, where you use humans and stuff like that.
Uh, I think if people will move from manual deployments or you know, CD to sometimes to uh AI-driven canary uh deployments and automatic goalbacks, etc.
That will actually move the needle in developer productivity much more dramatically than any other change that you will get in, like uh uh where it's like um uh how you generate the code.
Unfortunately, I think the universe and the and the industry will stay focused on on because LLNs, that's the problem that they know how to solve, and everybody gets excited and the industry is uh so vested into uh into it.
Uh so I think uh there's gonna it's still gotta be improvement there.
They won't move the needle.
What we move the needle in in SDLC is uh I think the stuff that I spoke about.
That's fascinating.
And and we're gonna talk more about how AI is going to impact the rest of the SDLC and 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, the 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, and 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.
We're just 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 need to prepare for this year, it's more of how uh things beat uh were like last year.
I don't think like where you're gonna see a lot of like uh, oh, let's put more budget into growth, like uh hire more engineers, more AI tools, et cetera.
I think because we spoke about like uh the deep, or at least like at the beginning, uh, or we maybe stayed in the same spot.
And we 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 uh maybe executives that are not, you know, uh tech first, or at least how the industry really expect, like uh oh, when this is like 3x, 4x coming to the single digit, and this will put more economic pressure on like engineering leaders like uh to do more with less.
Uh and it will stay the same, the same, unfortunately.
That's I what I think will happen.
So we won't get like much more budgets.
Um the expectation to do uh more with less will still be there.
We'll still uh under the liver, because again, I I think as a again, an ex-VP of engineering, getting like five to eight percent to 10% improvement is amazing.
It's amazing.
But it will still like one impress, like the because everybody wants this 3x.
Um that's why budget will still be and macro, etc.
Other reasons, that's why budget will still be uh 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.
With that said, what 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 the supply chain.
I think uh there's gonna be like these uh cases where big outages uh are going to surprise engine engineering leaders, not necessarily because of security, uh, you know, is it that's in the supply chain, but uh we've seen more and more dependencies in like uh software that's not like uh created in and out.
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 uh 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 so that's one thing.
And I think uh the other um surprise that could be positive or negative, it 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 like 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 the you know engineering teams down so I think uh there could be like a negative surprises there like okay I'm blocked like I can't release now for uh for a week or two because like my uh infrastructure is not stable or a positive surprise is like new technology and new innovation that will uh make smart uh moves there that could accelerate these are these are the areas that and as of course there's like uh you know quantum computing and everybody talk about I think like uh it's still it's gonna be a conversation in 2026 in you know uh for CISOs and security that prepare but still not like that the thing that uh 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 uh but who knows and you know we've we've been covering quite a lot here on Zev 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.
Like there's a lot of just new things that we've never really viewed as like a security risk that or just like a new category of problem that we have to to face.
But I want to shift gears uh to another specific problem that we're seeing in the market right now.
Uh 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.
Um, you know, coding obviously has sped up dramatically, uh, but things like reviewing and testing code haven't kept pace quite as well.
So for 2026, Ori, uh, you know, I'm curious.
Do you think that like is is the biggest bottleneck going to be the code review process, or are there other things that will also start to appear within the SDLC that are that are bottlenecks for AI-driven teams?
Yeah, I think it's gonna be in phases, and it depends on how early adopters teams are.
But definitely after 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 uh 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 uh better.
By the way, not just as a code review tool, because uh we talked before about the challenges over security incident uh coming, but we're also talking about quality problems.
So I look at like a thing that sometimes in the industry we call it code review as a quality gate.
Sometimes it's like uh silect, 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 bugging definitely taking like uh uh front seat in ASDLC and being adopted, and leaders will think about one, how do I do it smart in a smart way?
Am I letting like uh an AI agent uh review the code of what another agent wrote and going back and forth?
I think there will be brave uh organizations that will start making these decisions with risk analysis, etc.
But even if you're not going all the way there, like uh I think 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 silent in a silent mode on on uh every pull request basis and produce measurements and keep on improving.
So yeah, it's the year of of code quality, if you will.
And then like uh one instance is code review, another instance is measuring it and creating a feedback loop to improve how you use the AI tools.
Uh definitely see this as uh a year 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 co-pilot, 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.
I 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 pit fits all pipelines and they start maybe building or adopting more dynamic workflows that change based on the level of risk for the code and who wrote it?
Absolutely.
I think the teams will need to have smart uh pipelines and take smart decisions, like uh especially uh like you said around review and merge, do a basic analysis, decide uh what are you doing uh with this code?
Do you let like an agent review it and go back and forth?
Where do you let that code getting merged automatically?
Uh, you need to put it in the framework of uh uh enterprise policy, because remember, that's what's slowing us down, not the technology.
And I think this is the year where people will uh automate, like okay, define their policies and then will want and implement tools that help them like uh automate and implement those policies, both in review and merge, but also in how you run tests and uh like we said, like more coverage.
Now I think reach like a plateau, more 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, etc.
Conditionally, and how do you handle all this flakiness?
Uh that's yet definitely the year where automation, like if organizations that choose, think about it in advance, decide on their policy, uh, choose tools like to implement it, like uh with uh automate 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 I'm gonna address a a problem that we we hear quite often with engineering leaders today, and 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.
Uh 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, you know, or what what is the advice that you give as like the first lever they should pull to to start closing that gap between you know the increased velocity of code, but with a lack of velocity increase for impact and features?
Yeah, I think uh it's going back to what we said before.
Define uh your policy on where are you willing to take risks, calculated risks.
Like where do you uh break some of the old paradigms?
Like uh we said one size fits all.
Uh I have three reviewers looking at every piece of code or every pull request that's coming in.
No, okay.
Uh in the in some cases, it's okay for an agent to review the code.
So definitely pull that lever, decide like uh on new policies and new ways on how do you review and merge the code.
That's the second phase, by the way, after code after writing the code, right?
And by the way, you need to make smart decisions.
I think you need to choose a vendor that uh sees everything until like downs downstream, like if you stay in code generation then and you don't see, hey, like how does that impact my microservice that sits there and how does it interact with other and how does that affect my change failure rate and other metrics and my rework and my quality?
Uh you just did a code review for the sake of code review.
So uh also choose the right tools that sit that see like uh the downstream impact.
Uh that's the first lever I would pull.
Uh and I'm going back, maybe it's boring to the same uh answer from before.
The second lever I will pull is like smart decisions in in the you know CI CD systems.
I think like it will move like in a chronological order by the phases.
I think if uh last year was the year of code generation, again, we'll continue to hyper on code generation.
This is the year where like our smart policies uh we'll get into how do we do a review and merge code, and then we get okay, so some extra uh throughput uh 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.
You 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 gonna 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 uh AI enablement, ROI, executive reporting, you know, all of those really big important stuff that that a lot of engineering teams are grappling with right now.
So, you know, in 2025, basically everyone bought AI tools, rolled them out to 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 make 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 co-pilot 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 gonna be the focal point of a lot of engineering teams?
Uh oh, absolutely.
I love this question.
And I want to answer it in 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 which teams 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 the uh that produce that generate the code give you is like uh unfortunately are a vanity metrics.
Oh, like uh 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.
So, first of all, adoption uh is an interesting question, but you're spot on that.
I think like the uh 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 uh hey, code is being written, a pull request is uh it's reviewed and merge, it's uh past CI and CD, it's ready to deploy, it's out in production, I don't know, feature flag enabled, etc.
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.
There's a new interesting uh statistic that within AI impact that is like uh what's the drop-off also?
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 uh pull requests I lose in the way.
Uh, because okay, uh a lot work created, how much of them got merged, how much of them really got to production, etc.
etc.
So I think like uh in order to measure uh 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 that is the quality, and then there's a quality question.
Like uh, after we look at all of this and we improve all of this, and there's like the um let's look at the final like uh quality score, right?
Like how many incidents did we have, how many bugs did we have?
Uh, we need to keep track that that uh uh it doesn't get hurt.
So definitely a year where uh measuring AI will be like a major thing.
I agree to move from adoption to impact.
Uh and it's really important like to for leaders to uh establish like an agreement with their peers and their businesses on what does impact look like?
How do I measure, like 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 pull request doesn't tell you whether it actually helped.
Linear 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.
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 it I think it's like a big opportunity.
Yep.
Yep.
And and you know, I I want to take that uh 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 you know, the center of gravity in our industry right now, it being in code generation, everyone's saying fixated there, and you're right that people are going to start focusing on the adjacent problems, try to smooth out this bump we have in our production pipeline.
But in the meantime, do you think that this like almost like grotesque proliferation of code is going to warp how we think and work with the rest of the pipeline.
Like I think it's going to have a fundamental change that if you can create code this rapidly and this easy, it calls into question many things that were part of the pipeline before.
Yeah, I think here's spot on like uh it's almost like gonna be uh organization will be split into two cohorts like one that get it that okay are generating code and and by the way I'm not saying you you can't you can always improve how you generate code like put more quality in and we can talk about it it's really fascinating how you create this feedback loop.
But there's gonna be organization that are still focused uh solely there and there's gonna be organizations that are that will understand uh they already get it we I talk to engineering leaders all the time they get it that just don't know how to uh maybe measure it or what to apply uh but I uh the organization that will understand okay if I really want to get start getting closer to this like uh I don't know 25% improvement etc I'm gonna put my focus on uh the rest of the SDLC and what do I improve there?
And how can I apply AI there?
Uh by the way, that's what gets me really excited.
Again, uh, I'm looking for this like uh uh company that will build something that uh uh the LLMs are actually uh looking at all the logs that are coming from the services and learning them and then knowing your services in a very intimate way.
That are telling you, well, wait, these things that the thing that you're about to write, here's what I think it's is going to happen.
And oh, you know, and you know what?
I'm gonna release it like to five percent of the population with a canal release.
And uh, oh, I'm rolling it back.
I saw things I'm fixing it.
Now I'm uh rolling it, uh deploying it again.
Oh, now it looks better because I keep looking.
When that happens, uh this is when we get like the 2x and the 3x.
So uh that's what gets me excited.
Like when people uh and I don't again, I don't know if like uh somebody is already working on it or companies are thinking about it that uh and then if our LLMs are actually uh will be great at like solving those problems, and maybe there's different technologies that we need to adopt there.
Well, if there's nobody working on it already after this episode, I imagine they will someone crack it.
I think I said it like five times in like different companies.
So and somebody you're just hoping, you're just praying somebody steal my ideas, somebody please.
No, like at the at the end of the day, like uh uh trust me, like uh you can see it.
Like people already know it, they're already thinking like that.
Uh these ideas exist in brains across the universe right now, even if I didn't say somebody's working.
There's a there's a lot of companies sitting on top of a lot of earned uh knowledge and domain expertise and can and partnerships that are building these kinds of agents, right?
That are kind of second uh getting ahead of you and guessing what your next intentions are.
Like what you just described makes me think of like there are some AI SREs out there that exist that respond to incidents and read logs, and I think those are fascinating because we always think of chat as with an or like interacting with an AI as something we initiate.
But imagine you get that 3 a.m.
text from the AI about your outage, it's a different kind of world.
Yeah, or imagine they fix it.
Yeah, or imagine you don't need to talk about three.
You don't even get the 3 a.m.
text.
You get an instant report the next morning about what it fixed while you were sleeping.
Uh so I want to talk about something that's been really central to Linear B in the last year, uh, and that is in being an AI productivity platform.
So the idea is to combine measurement with all of these automations and policy enforcements that you've been sharing with us so far in this episode.
So I'm I just wanted to touch on this concept of visibility, like metrics, dashboards.
Like what role do those play within this, you know, the next year of AI adoption and impact uh for organizations that want to leverage AI to be more productive.
Uh I think a major role and there's a major opportunity uh for uh these platforms like uh Linear B, because uh like we said before, you need vendors to up that see all the way downstream, the downstream impact, right?
Let's take code quality as an example.
Uh uh, even even if you think about still code generation, right?
Think about SCI of two years ago, where you looked at like a problem and you spot a problem in your metrics, you say, Hey, like, you know, well, my problem is in quality in this service.
Think about what you had to do.
You had to build a a program to educate uh everybody that's uh working in this service and this thing.
Hey, this is our uh what we should need to do.
This is where we need to focus on.
And I'm not saying you shouldn't do that, but now if you find a problem, and if you see, hey, a code that was written by this AI tool or by this team in this specific service with this policy produces a lot of security problem.
So here's what I'm going to do.
I'm gonna tell you take this prompt and give it back to whatever tool you're using, and all of a sudden the improvement cycle of the quality is automatic.
The loop closes the loop closes.
That's the huge opportunity that exists inside this AI productivity platform.
Uh look at the pipeline, uh, don't just suggest fixes, like uh suggest prompts that go back like to whether it's like to the code generation tool or the thing that reviews the code and the improvement is there.
You don't need like now a uh a roll-out program that educates everybody, et cetera.
And people appreciate it and love it.
So uh there's a real uh uh chance here of like close the loop and get improvements fast for productivity platforms.
That's why I think again, and I know I'm biased because uh I'm the CEO of like uh such a company that has a productivity platform, that uh if people choose uh the quality or the code review tool from companies like us that see everything, like the chances that everything outside the chances of in of constant improvement like uh increase dramatically.
Well, Ori, this has been a really good episode.
I just have one more question for you.
Uh, and that is you know, I think it's like the ultimate question for 2026.
If you're an engineering engineering leader out there who's listening to this, you're probably hearing the question from someone on your executive team.
What's our ROI for all of our AI investments?
So, Ori, in your opinion, what's the answer that uh shows this impact that they can provide today?
Yeah, maybe I'll disappoint you, but I think like I would say you go and define with your business engineering how to ask them how do we measure success?
Or say, hey, together, we're gonna decide how do we measure success.
I think that's what my my advice like for every engineering leader.
Put this question, start uh running this question with your teams internally, then expose it with like uh uh your peers, your like uh business peers.
That's my advice because that's uh what I think every engineering leader needs to ask now.
Answers will come up, such as do we measure the throughput?
Uh if all the things that we spoke about today.
And if we measure throughput, let's measure the throughput across the entire SDLC.
So I I guess that's my answer.
If I have to ask a question, an engineering there say, how how do you measure success?
Ask yourself, ask your the people that report to you, then get these answers back to the uh business and set expectations because you're gonna have a rough ride next year.
Remember, the expectations is for 3x.
Um and you're gonna be proud in your 8% improvement.
Uh but if you uh set the expectation right, uh, I think you're gonna get like a little bit easier life with an engineering leader.
Okay, Ori, I have one quick question at the end before we go.
What is the most interesting thing that you have vibe coded this year?
Oh, I love this question.
So I did uh uh some things uh that are related to the business to help.
Okay, let's move them all aside and talk about like a cool project.
Uh so I vibe coded, uh I'm I'm still working on it, uh, but uh I'm uh I love music.
So I vibe coded like a a tape.
You know, I used to used to have tape as a teenager.
Like uh well, you can't really like okay, next song, and then you can hear the next song.
Uh you can you need to press forward, and then you don't know, like okay, it's like moving, where will it end?
Oh, it's like in the middle of the old song.
So you play build a playlist.
You have to really think what songs you you wanna put in your playlist because and then like you can move uh forward or backwards or record, etc.
And uh we're now working on visualization of the tape, and uh I it's so much fun like doing it uh over the weekend.
Yeah, and six.
I love that.
If you come back to listen to it, you gotta rewind it if you wanna.
You gotta rewind, yeah.
Yeah, you gotta rewind and wait.
You can't just like start, yeah.
We gotta rewind.
That's great.
I love that.
It's it's it's fun to like use code to explore other hobbies and interests too.
One thing I built this year was uh a recipe app.
You know, I love the cook, but I wanted something a little more bespoke for how I collected my recipes and my ingredients and stuff.
So I just kind of whip my up myself.
So that's a fun uh anecdote.
I love that.
Yeah, cool.
And I I think I love most I think it just represents my belief that we're entering this like code as art phase of of the world where like if you have an artistic idea, just write code that generates that idea for you.
It's really cool.
Well, thanks for joining us today, Ori.
It's always a wonderful pleasure to have you share your insights and check out you know how your predictions perform year to year with our audience.
And that's it for today's show.
If you enjoyed the episode, the best way to support us is to rate our podcast on your preferred platform, whether that's Spotify, Apple, or wherever else you might be listening to us.
And also if you want to learn more about Linear B and all the things we're discussing today, head over to the l to linear b.io to check out all of our latest research and content.
And lastly, we'd love to hear from our audience.
You can connect with Andrew, Ori, and myself on LinkedIn, or join the conversation about this episode on the Dev Interrupted Substack or LinkedIn newsletter.
So thanks everyone.
We'll see you next week.
And thanks again, Ori.
Thank you for having me.