Transcript #
Nathen Harvey: For those of you that are unfamiliar with DORA, I just want to level set on which Dora we're talking about here. There are quite a few. There's the small child, Dora. She is one of my favorites. How many of you have watched that show ever, Dora the Explorer? The beautiful thing about Dora is every transformational journey she goes on, she has a map in her backpack and she completes it in three steps. Now, Swiper's always there trying to set her off course. I'm here to tell you that your AI adoption journey is going to be just like that. It's three easy steps with just a little bit of Swiper in the way. Of course, we're here in Europe, so we also have DORA, the Digital Operational Resilience Act. I do assure you that if you and your team get better at delivering and operating software and doing this in an automated fashion, that's going to make those regulators from the Digital Operational Resilience Act happy because you'll be more resilient.
Where I come from in the United States, there are a few states within the United States that have a specific set of legislation. They call it Designated Outdoor Refreshment Areas. This means that you can walk around with a beer as long as you stay within the Designated Outdoor Refreshment Area. That, I have to admit, is probably my second favorite DORA in the world. There are others, but I can't take you through all of them. What I am here to talk about is this research program, DORA, that's been running for well over a decade now. This is really research into how do teams get better at doing the technology? How do we get better at IT? How do we get better at software delivery? How do we get better not just with the technology, but as teams, as people? How do we drive our businesses forward and really serve our customers?
DORA used to be an acronym, but we've deacronymed it. DORA now stands for nothing, which doesn't quite sound right either. We have a tagline, that's what DORA stands for. It stands for get better at getting better. The interesting thing is, and we'll get to this at the end of the talk, I'm actually starting to question our tagline. I'm worried that it's not going to serve us right, right now. More on that ahead.
The 2025 DORA Research #
If you know anything about DORA, you might know that we run a survey. We run a giant survey every year, and maybe you've participated in that survey. If you have, thank you for sharing your data and your insights with us. It's really helpful. Last year, we had nearly 5,000 people take our survey. We augment that with additional qualitative research. Qualitative research is basically a qualitative researcher sitting down and having interviews with practitioners, with leaders, really trying to get a little bit more context around what's actually happening. I'm going to share some data from our most recent survey. There is a little footnote on this slide here that you'll see. This global survey was conducted between June 13th and July 21st, 2025. I'm going to tell you some things about how AI adoption is going. Do you think it's accurate? I might be lying to you. We'll leave that for you to sort out. Last year we published this report, the State of AI-Assisted Software Development. You can download the 2025 report here, dora.dev/dora-report-2025. You can grab that report there and read it. It's 140 pages long, so I'm going to summarize it for you. I am going to test you now because I'm putting up another QR code. This one, I really want you to participate in this one. I want you to answer this question for me. What is stopping you? You just generated something with an AI, or maybe one of your colleagues just generated something with an AI.
What's stopping you from shipping it to production right now? Why not go directly to production? Let's just see what we're thinking here. What's stopping you? Trust. You don't trust the solution. Governance, security, quality, uncertainty. Being fired, someone put in there. It's good. It's interesting because might you be fired if you're not using the AI also? It's interesting. You can keep throwing some answers in there. I think they're fascinating. Fear. I don't know how. We are a bank. Stop using that as an excuse, you could still do better.
AI Adoption and Use #
I want to talk about AI adoption and use and what our data found. Remember, how do we collect our data? Surveys. Ninety percent of people tell the truth on surveys, 10% lie. This slide was, how many of you are using AI professionally at work? Ninety percent of our survey respondents said yes, and 10% said I'm not allowed to, so I better say no. Remember, this was June and July of last year. We're not going to ask this question again. Because, like I said, we've been doing this research for 10 years. Never once have we asked, do you use a computer at work? From this point forward, we can stop asking, do you use AI at work? Because, yes, you do. We're using it. How much do you rely on it? I think these numbers have probably changed. Reliance on something is different than just using a thing.
Like, if I rely on something and it goes away, that's problematic. What we see here is that about 35% of our respondents say I rely on it a little or not at all. A majority of our respondents are saying, yes, I rely on using that AI for that particular task or set of tasks that I'm doing. I think that's really interesting. Is it helping? We'll get to that. This one is also really fascinating to me. We asked, think back to a recent work day, about how many hours did you interact with AI? Now, stop. I get it, though. I'm falling back into these bad marital patterns. I'm sitting at home and I'm working out something with the AI and it's getting close to dinner time, and my wife is ready for me to stop working. I know like, just one more prompt. Just one more, I'll be there in a minute.
One more prompt. Please, not the 12 hours. If you're the long tail in this chart, please get up, walk away. If you're sitting here in this talk, close the laptop, stop with the AI. Just listen to me for a minute. That'll make me feel better. It will be better for your long-term health, I promise you. The interesting thing here is the median hours, median of two hours working with AI. There are other studies, not our studies and not studies that I will quote, but there are good studies, nonetheless, that ask this question about, how much time a week does a software engineer typically spend actually writing code? The ranges vary pretty wildly, but 10%, 15%, 30% at the high end. How much is two hours in an eight-hour day? It's about 30. You're probably using AI to help you write code. Also, this is, I think, a bit of a challenge for us, are like how people perceive us as software engineers. AI is coming to take your job because it's going to write all of the code for you. It's going to take away that thing that you do 10% of your time, so therefore we don't need you anymore. That math doesn't math to me either. It doesn't work.
Is it helping you? How do you feel about using this? Your perceived impact on individual productivity, it's going up. You feel more productive. I feel like I'm getting more done. I feel more engaged with the work that I'm doing. I feel like I'm spending more time on good work, valuable work, maybe less time on toil. About 5%, slightly decreased, moderately decreased, or extremely decreased my productivity. I've certainly had those days working with AI as well. I've definitely had those days. This is really interesting. We've got high levels of reliance. We're using it a lot. We feel like it's really helping us improve. What about code quality? How's the quality of the codebase that you're working with? Also, improving. With about 10% saying it's actually a little bit worse now that we're using AI. Our codebase is a little bit worse off. This is a really hard question, like, how is it impacting code quality?
What do you mean by code quality? This is one of our challenges as researchers. We don't know. We want you to tell us what do we mean by code quality. You just answer this question, we'll do the data. Here's the thing, how much do you trust the quality that AI is generating? How much trust do you have in whatever it is that it's generating? Whether it's code or that email that you're about to send off to your boss, or a prospect, or the financial plan that you've built for your family. How much do you trust that? Thirty percent trust it a little or not at all. I got to tell you, I'm on team somewhat, right there in the middle. I want to sit down and have coffee. If you were part of the 11%, that say you trust it a great deal or you trust it not at all, if you fall into either of those buckets, you're both wrong.
You should not trust it a great deal. Those are probably the ones I want to talk to most. I want to understand that. How? What are you doing? The not at all, don't you feel the FOMO? You've got to start working with these skills. That great keynote, we've got to start learning in public and leaning in to these new ideas.
If I summarize that entire 2025 report for you in three slides, I'm going to do it right now. AI's primary role in software development is that of an amplifier. The greatest returns on your investments in AI are going to come from a strategic focus on the underlying organizational system. Without that foundation, AI has a tendency to create localized pockets of productivity that are often lost to downstream chaos. I saw a post on LinkedIn, someone lamenting the fact that they can now build something in hours, and it takes six weeks still for that thing to make it into the hands of a customer, to get into production. We've accelerated part of the system, but we're not yet as an industry thinking about the entire system in a holistic manner. That's exactly what we're seeing in our data as well.
Exploring AI's Relationship to Key Outcomes #
We do like to report what you're telling us with DORA, we also try to understand and make some sense of the complexity that is your organization, that is these technology tools that we're working with. What is AI's relationship with key outcomes? I promise I'm only going to do this once with one chart. I'm going to teach you how to read this chart really quickly. What we do is we collect a bunch of data, we build a little model, and this tells us the shape of the world. Then, as researchers, we have this amazing capability. We can say, here's the shape of this complex world. Let's change just one thing and see what happens. I encourage you to go back to your organizations and try to change just one thing and see what happens. Because you can't. It's impossible. You can't do that. Our data, what we do, we build up this model.
We say, let's change one thing. What thing are we going to change? We're going to change the score that you achieved for AI adoption. We're going to ramp up AI adoption, change nothing else, and then run a bunch of simulations across our model. What happens? If the score that you receive for this outcome on the vertical bar stays the same, your dot will show up on that dash line, which represents zero. To the right of the dash line, that thing increased. To the left of the dash line, it decreased. Individual effectiveness increased the most. Software delivery instability increased. Just want to be super clear. It's probably not what you wanted. Organizational performance, time spent doing valuable work, code quality, product performance, software delivery throughput, it's probably do what you want, and team performance all improved. Burnout and friction, they basically stayed at zero. Those little bars that come out from the middle of that dot, that's our certainty rate.
We call those error bars. It's not just we that call them that, that's what they're called. The wider the bar, the less certain we are about this. The tighter it is, the more certain we are about it. If you look at burnout and friction, they're both pretty close to zero, and their error bars definitely overlap zero. For burnout, this probably makes sense in June or July. I'm going to maybe counter that. Imagine, you're at work, and it sucks. You feel burnt out. You question everything that you're doing. Your manager comes over and says, here's some AI. Guess what? Work still sucks. You still hate what you're doing. Like, that's not helping your burnout at all. Just handing you a new tool isn't going to help. We see that. The positive spin on this was, it didn't hurt, it didn't make it worse. I do worry right now, today.
How many of you are managing a fleet of agents right now? Maybe a fleet sounds too many, like three or four. If you're trying to do work with three or four agents, and they're all doing very different things, you might find yourself now bouncing from task to task to task. It's ok. It's cool. Because we are all, as humans, super good at multitasking, there's research that shows this. No, wait, it's the other way around. We're all shit at multitasking. It's cool. We'll just give it all to the agents. I've certainly found myself like, I told this agent the thing that I meant to tell that agent. The cognitive overload that we're taking on, I think we don't yet understand it. I worry that in this year's research, we're going to find very different results.
When we think about some of these things. Some are getting better. Some, like software delivery instability is getting worse. In DORA, the way that we measure software delivery instability is we look at how frequently are your pushes into production resulting in what I call the, oh, expletive moment. You've all been there. Push a change to production and you or someone around you shouts out an expletive. What are we going to do? We have to act right now. Like we're going to roll that back. We're going to push forward a hot fix. That's bad. That's software delivery instability. With AI, we see that going up. In 2024, so in the previous year's research, we saw software delivery instability going up and we saw software delivery throughput going down. This year, we see that it's improving. We're seeing changes over time. A lot of these changes have to do with the J-Curve of transformation of taking on anything new.
Anytime you take on something new, your organization will likely go through this pattern. You're going to bring in a new tool. There's going to be some low-hanging fruit. You're going to go pick that fruit. You're going to eat it. Things are going to look really good. Then all the low-hanging fruit will be consumed. Now you've got to get to the hard stuff. That's when it sucks. It gets hard. Software delivery instability starts to go up. You dip into this trough. Today, I would talk about that trough as there's a couple of things. There's software delivery instability. There's the trust that you don't have. With that trust comes a lot of verification of the tools. With that verification comes maybe the changing of your job. I'm a software engineer. I write code. No, I just review it. I just read other people's code, and it's not even people that are creating it anymore.
That's going to drop you down into this dip, the instability tax, the verification tax. There is another side. We've seen this all before. DORA's been researching, as I said, for over a decade. We were there as the cloud just started taking hold. Guess what happened in every organization when they brought on the cloud? Things got a little bit better. Then they got a lot worse. Then we figured out how to use this technology. The same thing with SRE practices. We've seen this in our data modeled over time. We know that this is what's happening. What we don't yet know, because all of this is so new and because the technology is changing so fast, how do you get there? How do you get to the other side? Collectively, we're learning that right now. We're all learning that together.
Team Performance - A Look at Seven Team Profiles #
With DORA, we also want to look at how are teams performing? How are you doing? We've oftentimes looked at just software delivery performance, and published benchmarks on software delivery performance, and given names to things like low performers and elite performers. How many of you show up to work to be a low performer? I didn't think so. Some of you silently raised your hands, but you're sitting next to your manager, so I get it. I see you. We're engineers. We're supposed to be low performers. Like, let the computers do the things. We looked at more than just software delivery performance. In fact, we wanted to understand how are teams doing across these eight different factors: team performance, product performance, effectiveness, friction, burnout. Remember, we found that at least 90% of the people in our survey are using AI. What we also found were that there were seven unique team profiles when looked across those eight different characteristics.
The first thing that that tells us is it's not because of AI. If everyone's using AI and we're seeing vastly different, highly variable performance levels, it's not either the AI's fault or the AI that's making that happen. What do these seven team profiles look like? First, because we had seven, we couldn't just use low, medium, high, and elite. We had to come up with way more creative names. Some of these names, just by looking at the name, you might find yourself. You might find your team. Let's look at a chart, shall we? No, let's look at seven charts. No. You can't see anything here. These things are really hard to read. We did, you could call them crimes with this spider chart or this radar chart. They don't act the way that they should. We're not going to look at these charts because you can't see them anyhow.
Let's look at two of the different groups here. Constrained by process. Teams are running on a treadmill. Despite working on stable systems, their effort is consumed by inefficient processes, leading to high burnout and low impact. How many of you feel seen right now? You can see here, burnout is high. Friction is high, or I'll tell you because it says so there. Individual effectiveness is low. The time I'm spending doing valuable work is low. My software delivery instability, actually pretty good. It's lower than everyone else's. My throughput is a little bit lower than everyone else's as well. It's not the perfect team to be on. It's not terrible. We've seen worse. We're not really delivering a whole lot of value. Let's contrast that with harmonious high achievers. Now when you go back to work, you can tell boss, we're a harmonious high achiever. Like this is what excellence looks like, we think.
We've got a virtuous cycle, stable, low-friction environment, empowered teams delivering high-quality work sustainably and without burnout. We have to think about these things. Can we deliver quality sustainably? Can we do that with low levels of friction across the organization without burning our people out? These are really important considerations. Here's the thing. If we have everyone using AI and wild variance in the levels of team performance, how do we overcome that? What are some of the signals here? I have a question for you about just that. What one thing would you need to change in your environment to confidently trust the solutions that AI generates? We just had that question about what's stopping you. Let's explore that a little bit differently. What's stopping you? What's one thing you could change right now that would unlock some of that gate? Same QR code, new answers: guardrails, tests, testing, a harness, management, competency, end-to-end test, automated testing. There's one I'm looking for in particular, validation. My manager. That's real. Observability. Education. Access to better models. Governance. This is great.
DORA AI Capabilities Model #
If it's not that you're using AI, maybe it has something to do with how you're using AI. We've seen this before. When we investigated the cloud years ago, we saw some teams that were getting a lot of great value out of cloud. Some teams that were like, it's slower and more expensive. Why did we move to the cloud? It wasn't because you had the cloud or not. It was how you used it. Dr. Nicole Forsgren talks about this a lot as having a membership to the gym. How many of you have a membership to the gym? How many of you go regularly? Just having the membership isn't enough. It's not going to make you fit. You have to do the work. We investigated this. We wanted to understand, are there specific things that help some teams get more value out of AI than others? What we identified were seven capabilities that when combined together with adoption, drive better outcomes. You've probably heard a couple of themes. There was one talk talking about AI adoption, and AI deployment, and AI value. You don't get adoption just by buying the tools. You don't get value just by having adoption. You can't have impact without adoption. Frankly, this leads us to a lot of challenges. I was talking with Blanca around measurement. How do we know that it's working? Let's go measure it. I want you to be very careful with measurement. One of the most important things with measurement is to understand what is the question that we're trying to answer. I was talking to someone else, and we were talking about what's happening in their organization. They happen to sit on the board. They go to board meetings. The people on the board are like, what are we doing with AI? Are we using AI? Are we using it? Is everybody using it?
The only question they have is adoption. Tell them that you're adopting, show them the numbers, and stop. That's not enough. It is enough to answer their question today. That's all the measurement that you need to answer that question. Next year they might ask, you all adopted all this stuff, what is our return? Now we have a different question. I can guarantee you can't get to the returns if there is no adoption. You got to start there. Measuring adoption, we all know, is not enough. It's not enough. For the love of whatever you view as good and holy, stop measuring how many lines did the AI generate. How many of you as software engineers loved being measured on how many lines of code you wrote? Why is it different for an AI? It's a stupid metric. Stop. What does matter? These seven capabilities. Having these capabilities and conditions in your team, within your organization, will help take the adoption that you're so focused on and let it drive through to real outcomes that we care about.
We've got a clear and communicated stance. If you don't make it clear how, when, where, what AI you can and can't use within your organization, this will cause all kinds of friction for your employees. If I don't know if I'm supposed to use it, one of two things will happen. I simply won't use it, and I'll be fine with that. I'll blissfully work without AI. Or I'll know the power because I've used it at home and I'm going to bring it into work and I'm going to use it anyhow. Then I'm going to worry about getting caught and getting fired for that. Make sure that your stance is clear and communicated. Next up, we have a healthy data ecosystem and access to that internal data. You want the AI to do better for you? Make sure it understands what are the policies that your organization has?
Who are your customers that you're trying to feed? Let's make sure that all of that is accessible to the AI. The next two are two that really have nothing to do with AI. Strong version control practices. The AI can go down a really crazy path if you don't have the confidence that you can roll back those changes very easily. I've talked to so many people who've said, I find myself committing to version control much more frequently. To which I say, what are you talking about? Why weren't you committing to version control every two minutes? Why is this new? It is. It's time. Learn those version control practices. All you need to know how to do really is commit and to roll back. If you can safely and confidently do those, you'll be in a better place. The next one is also super important, working in small batches.
If DORA has found nothing else, it's that if you want to improve software delivery throughput, and software delivery instability, the best way to get there is through shipping smaller changes. When you work in small batches, you can reason about what you're changing. When something goes wrong, you can reason about how to undo that, how to fix that thing. When you roll out changes, try not to roll them out to everyone all at once. Do we have progressive delivery? Can we slowly roll things out? Working in small batches is a powerful thing. Unfortunately, the bots came along, and they're like, "I see your small batches. I'm going to raise you this 50,000-line PR. Here's a small batch for you. Ship it." Even the bots do better if we give them smaller, well-defined tasks. It just makes sense. Then two that I want to dig into a little bit further, user-centric focus and quality internal platforms. Having a user-centric focus, every piece of software that we create is made for humans. Even if the consumers of that software are bots, we're creating it for humans. The end goal is that this software makes someone's life better. That's why we're here. AI, maybe it's a forcing function for us. As software engineers, our job is not to write code. Our job is to solve problems. Our job is to understand who our users are and build the things that they need, the things that are going to improve their lives. This is fundamentally changing the work that we do. I, personally, I'm optimistic that this is helping us get closer to our users, better understand and have empathy for them, and build better solutions for them. One of the things that we found in our research, in the data, was that when you have a user-centric focus, your team performance improves.
The other thing that we found that was really interesting was when you don't have a user-centric focus, your team performance actually decreases. This is really powerful. I think when it comes to AI, there's a really fascinating thing that we can do now. Yes, AI can generate that 50,000-line PR in the time that it would have taken you to create a 10-line PR. It can do things a lot faster. What else does this do for us? This really unlocks optionality. Now I can prototype five things in less time than it took me to prototype one thing. You know what we're really bad at? Is understanding exactly what our user wants. Let's go build six things. Let's go build 10 things and try them out. Let's debate them as a team. Let's bring in some users to talk about them before we invest in actually productionalizing one of them and shipping it off to production.
Wait, but why just one? We've been building A/B test frameworks forever. Why not A-B-C-D-E-F-G? How many different things can we be actually running in production, getting real user feedback on to help us make better decisions? If you have the capability to enable your product development team to help you build higher fidelity prototypes that we can then explore lots of different options, we can converge on the best choice. We can put some of those best choices in front of users, take feedback from them, feed that back into the cycle. We're building this really tight connection with our users. This is really awesome. Let's get there.
The other thing that probably isn't a surprise that really helps is quality internal platforms help turn your AI adoption into real value for your organization. When I think about quality platforms, there's the obvious things. A platform helps us scale a capability, a technology across an organization because we centralize some of those capabilities, make them available to everyone. Another thing that if you've spent any time near platform engineering, I'm sure you've heard the phrase, treat your platform as a product. Have you heard that phrase before? One of the things about products is they have customers. Who's the customer of the platform? Before AI, who was the customer of the platform? It was other software engineers. It's other developers. I have a lot of empathy. I understand the pain that they have. I know what they're going through. Now it's changing. It's not just other developers I'm building for, I'm also building for the bots.
I need to improve my developer experience. I also need to improve the agent experience. It turns out that some of the things we do for one are good for the other. When we have better documentation, that can help our developers. It can sure help our agents. I know this because now you're all writing documentation. Everyone is writing documentation. DORA has researched it for years and said, "We see documentation is like sunshine, it unlocks all of these capabilities within an organization." Everyone's been like, yes, but writing docs sucks. How many agent files have you written or skills have you written? You are writing documentation now. What's changed? As a senior engineer, I'm not writing documentation to help a junior. I will write documentation to help a bot. Let's be honest, that's messed up. Why? Because when I write the documentation to help the junior, it takes a year or more for them to progress.
The feedback cycle on did I write good documentation or not is really long. When I write documentation for an agent, I get that feedback right away. I changed the agent and I re-ran the prompt and I saw the results from that. It's really fascinating. There was a research paper that they did a little bit of research into like, do these agents files actually help produce better output? Their finding was, no, not so much. I think the interesting thing was, as the user, do I have more confidence in the output because of the agent file? I feel like I have more control, maybe that gives me better trust. We do know, and this is true everywhere, that trust begets adoption, begets trust. The more you use something, the more you trust it. The more you trust it, the more you use it. While maybe it's not helping the bots right now, maybe it is helping me. Maybe that's good enough.
Here's the other thing about AI. We talked about internal platform. We start with developer experience. Now we have to think about agent experience. I want to go back to that very first question. What's stopping you from YOLOing that thing that the AI just generated into production? Because now everyone in your organization is a builder. We go from developer experience to agent experience to builder experience. How do I help Jane from accounting ship that application that she dreamed up last night and built with an AI? That sounds scary, doesn't it? Maybe that's the new job. Maybe that's the new platform engineering. How do we make it safe for there to be more builders across our organization? That's scary. Maybe that's what we have to do. Because otherwise what's the flip side to that? Shadow IT, shadow AI. That's always been a label, in my perception. You might not agree with this.
I feel like shadow IT is a label that we, technologists, have used to denigrate the other side of the house. Those business people, and their shadow IT. Why do you think they're doing that? So that you could stay employed. They're getting their business problems solved. Shadow IT, we should feel bad when there's shadow IT. That's a signal to us that there's a real business problem, it's so bad that they're willing to work around working with us. We need to go enable that. I think a platform team, and this idea of platform, maybe more of your engineering capacity should shift toward enabling builders, and less should go toward shipping that next feature. Just something to think about.
DORA AI Capabilities Model in Action #
I want to show you the DORA AI capabilities model in action. If you go to dora.dev, you can do that or you can just watch here. I'm going to click on this little AI guy. I want to show you this capabilities model. We're going to explore it a little bit here. Let's say that you're part of the legacy bottleneck. One of the challenges that the legacy bottleneck has is product performance is low. You decide as a team, we want to improve our product performance. You can come out here to the model and you can click on product performance, and it will show you which capabilities together with AI adoption drive product performance. From this model, you can figure out like, wait, product performance? What does that even mean? How did we assess it? You can click on this how to assess button. Working in small batches, AI accessible internal data, clear and communicated stance.
What do those things mean? You can figure out how to assess them and you can learn more about them. The way that this model works though, you're doing AI adoption. You want to drive an outcome or multiple outcomes. You want to improve these things. How do you do so and make sure that the AI adoption is happening? Follow those arrows backwards with these capabilities and conditions in place. Your AI adoption is more likely to have an impact on those things on the other side, on those outcomes.
Continuous Improvement vs. Radical Change #
A bad system will beat a good person every single time. That's from W. Edwards Deming. The one quote I remember to cite. Think about that. When it comes to adopting AI and changing how you work, there's two different approaches that you might take. If you're a fan of the Toyota Production System, you might know the terms Kaizen and Kaikaku. Augmenting, where we look at a current system and we try to make it a little bit better. This is continuous improvement. That's Kaizen. Then evolving. Evolving is like, maybe we throw everything out. Maybe we start from fresh and design the systems that are going to be completely different. That's Kaikaku. That's radical change. When I go back to that slide, the question that I asked you all, what's one thing you would change in order to make it safer, to trust that code that the AI generated, you could ship to production?
Not one of you said code reviews. How many of you feel like code reviews are the new bottleneck? I think it's time. I am a big proponent of Kaizen and continuous improvement, not Kaikaku, radical change. Maybe it's time code reviews go away. Maybe it's time they go away. How uncomfortable does that make you? Pretty uncomfortable. Why do we have code reviews? To validate that there are missing tests. Why else do we have code reviews? To learn. Give me one more reason why we have code reviews. Two brains think better than one. Share the knowledge. How many of you have walked up to a brand-new codebase with an LLM at your side and learned about that codebase very quickly? We can share the knowledge a lot faster. How many of you have written tests to validate that you have tests for this thing or have other ways of validating that without asking a human to look at this thing to validate that there are tests there?
How many of you sit down and do pair programming? You know what's better than asynchronous code review? Synchronous code review. Write that together. We've got four eyes looking at the code as we go. It's better. Maybe it's time to throw out code reviews. Every bit of engineering capacity that we're investing in code reviews would be better invested in better guardrails and better understanding of the intent of what we're trying to build. I know, it's radical. They don't call it radical change for no reason. I think it's time. We need to think about this as an industry. I mentioned that that 2025 report was not the latest report. This is the latest report, the DORA AI Capabilities Model Report, dora.dev/dora-aicmr. This came out in December. It goes into those seven capabilities, talks a little bit more about each one of them. How do you measure them? How do you put them in practice within your organization? All of this. I highly encourage you to download that report and check it out as well.
From Insight to Action #
I want to close out with some final thoughts. The first final thought is probably the most important thing that I will say all day today. Don't believe me. Don't believe our research. The way that DORA does research is we go out and we research the world. We get as many inputs as we possibly can. None of you work for the world. Some of you, there is the world, the program, like maybe you're on that program. You don't work in the world. You work at the organization that you work at, and in its context and with its customers. Even within your organization, you don't probably work for the whole organization. You work for a business unit or an application. You've got to contextualize what we've found. Take our findings and use them as your hypothesis. DORA found that when we have a clear and communicated stance, AI adoption leads to better outcomes.
Let's go try that out. Also, you cannot do this alone. No one can improve alone. Look around you. These are your peers. We're all learning together. Also, if you join the DORA community, you can join thousands of other practitioners and leaders and researchers around the world who are taking some of these ideas and trying to figure out what does it mean when we put them into practice.
See more presentations with transcripts