← All transcripts

How AI Is Changing Code Reviews & Software Development Transcript, AI Summary & Key Points

IBM Technology · 2 hours ago · Education · 14:09 · EN

Answer

AI is changing development by taking on broad analysis and increasingly helping write code, documentation, and architectures, while shifting human attention toward context, requirements, business outcomes, trade-offs, and judgment.

AI Summary

AI is shifting software development and code reviews away from line-by-line implementation inspection and toward validating intent, requirements, outcomes, and business impact. AI can perform broad analysis across code, documentation, architecture, repositories, merges, differences, code quality, and automated checks, while humans provide context, judgment, trade-offs, and iteration. Reviews therefore become evidence-based outcome reviews supported by tests, automated checks, and runtime evidence.

Key Points

  • Systems and applications are built from code, documentation, and architecture.
  • Michael Fagan's structured inspection process used team-based, line-by-line reviews of code and documentation.
  • Pair programming moved reviews onto the fly, with two people reviewing work as they produced code and documentation.
  • The pull-request era introduced repositories, versioning, diffs, merge requests, and merge approvals, shifting reviews from syntax reviews to consensus reviews.
  • The automation era added CI/CD pipelines and system-assisted reviews for code quality, vulnerabilities, security, and internal, external, and governmental compliance.
  • The AI era adds LLMs and intelligence to the development process.
  • AI can analyze code, documentation, architecture, repository changes, merges, pulls, code quality, and automated checks.
  • Humans provide context, evaluate results against business outcomes, iterate through prompts, and make judgments and trade-offs.

🔒 3 more in the full analysis

AI in practice

Used for

With
AI
How
AI is brought into the development process to produce code, write docs, and build architectures.
With
AI
How
AI analyzes the development artifacts and integrates with existing automation for code-quality and other checks.
Outcome
Reviews become evidence-based and focus on whether the intended outcome was built.
Replaces
Broad manual analysis of the implementation and its moving parts.
With
AI
How
A person provides the context and asks AI to build a piece, then compares the result against the desired business outcomes and iterates through prompts.

🔒 1 more in the full analysis

Links mentioned

🔒 Full analysis locked

Unlock more videos and the full analysis

Buy credits to process more videos. Each run includes the full analysis, not just the summary — and you get access to the locked analysis across the library.

Get credits →

Transcript

Searchable transcript of How AI Is Changing Code Reviews & Software Development — IBM Technology (14:09). Search for a phrase, then click its timestamp to jump straight to that moment in the video.

Captions sourced from the original video on YouTube, published by IBM Technology. The video, its captions and all related intellectual property remain the property of their respective owners; AINotes claims no ownership. Provided for research, accessibility and search — see the Transcript Notice and Copyright Policy.

AI has produced a major transformation shift for how we do business, how we find information and interact with systems. But how is it changing how we do development? Today, we will discuss how co-reviews have transformed with the emergence of AI and AI based development tools. Let's start with a brief history of reviews. To actually start that, let's look at what it is that we are trying to build.

We are building systems and applications. It's fundamentally what we have been building for a long time. And as part of that, that all comes down to we have code. We have docs, and we have architecture. These are basically the fundamental building blocks that when we're building systems and applications, what we're trying to do. Now, when we started thinking about reviews and how we review this, in the beginning, there was the Fagan Era of code reviews.

Now this is actually, you might know this as the Fagan inspection. It was started by Michael Fagan, who was actually an IBM engineer, who wanted a way to be reviewing how we were producing our applications and system to make sure that we were doing it in a consistent and good way. And so he came up with a way that was very structured. And it really involved team reviews.

Teams got together often in a room and they inspected code and docs. And what would happen is they would go through line by line for the code that they were working on and review it. Everybody would chime in and see if they could figure out if anything was wrong or if it was what they would need. So as you can imagine, this was very time intensive, took a lot of effort.

Of course, during these days, we really weren't as concerned about speed. So there was time to review all this, but then we started speeding up, speeding up how fast we could develop stuff. And then we came a little bit into the Agile error. So instead of having teams of reviewing stuff and being very structured, we started having groups of people, or really two people, which was known as paired programming.

And you had a couple of individuals. So as they were producing code, as they were producing their docs, as they were producing the things that they needed for applications, they were reviewing it themselves. And they were really doing this on the fly. So the reviews were on the fly. As they were building things, they were able to review and see over each other's shoulder to see if everything was what they needed.

And so this really sped up. This really is where we started getting faster on our review. But it was still... Basically fundamentally very much the same. So if you think about this era and this phase of where we were doing code reviews, it was really focused largely on implementation. How are we writing our docs? How are writing our code? How are making sure that we're not introducing problems or bugs into our code.

And if you really think about it that way, this was really about syntax reviews. All right, now, as we evolved away from this, we started thinking, okay, now we've got a lot of different people, the size of our code view, the size or applications view. So we had to evolve from that and start putting things into repos. And this era is what we really think of as the pull era.

And what we did during the pull era is we made a pull request. We made changes to our code and then we submitted those changes back into our repo. And then, of course, once we did that, we requested a merge. And we needed a merge approval for what we were working on to be now part of the base of the code. So we started really adding another layer of complexity to how we were doing stuff.

So we still have code, we still had docs, we still of architecture, but now we're starting to add in layers of, we have versioning, so which versions, because now we have everybody submitting to repos, and we also have diffs. So what is the difference? In the code that we're submitting and asking for approval into this repo. So someone may touch one piece, one person may touch another piece.

And what this really started resulting is, is we had deeply integrated... Code and reviews, because now we have people still doing all these parts, but they're submitting in a repost and having it reviewed. So now we've moved from a syntax reviews where we kind of started our whole journey on, and now what we're really looking at, we've evolved into consensus reviews.

We have a group of people that are starting to look at the versions and the differences coming in, and do they approve it? And now approvals can roll up very high. All right. So we have these consensus reviews. Now we have a lot of artifacts. We have lot of people touching stuff. And so we evolved even from there to a point where we brought in CI/CD pipelines to start helping us put all these things together, building it, and putting it out as applications.

And this era was what we kind of think of as the automation era. And of course, in the automation era, there's a lot of stuff going on, more than what we really kind of wanted to do. So we started having the system check for things like code quality. We also had the system start looking at doing checks and also compliance. Those kinds of things that we often miss when we have a very deeply integrated system.

And so when we look at this now, when this kind of phase and this automation era, we've brought in, like I said, we've bought in checks. So this is vulnerabilities, are there security things that need to do? And we've also brought in our compliance. And these can be internal regulations, these can external regulations, they can be governmental regulations.

We want the system to make sure that everything that we're producing and developing here that gets submitted into repos, that it's adhering to all the things that we want it to do. And so this really becomes then a system assisted review. Because now, it's not just the humans who are reviewing code and reviewing the differences and approving things that happen.

We also have the system looking at what's going on and making sure that we are still doing the things that we need to do. And this type of review is what we have come to call system reviews. All right. So now we've come to the era that we want to talk about today. And this is really about the AI era, where now we're bringing AI into how we want to do our reviews.

And so what we've added in this point is we've added our LLMs. We've brought intelligence into the development process. So when we think about what's happening now, this is really a shift in focus. From implementation. Which is where we were. How do we implement our code? How does that get built? All the things about what we're doing. But now we wanna switch it and we really wanna start looking at shifting it from implementation to business outcomes.

And also requirement fulfillment. So now we're seeing a shift. Now we're starting to see the beginning of a pretty significant shift. No longer are we finished, focused on the implementation and all the parts and how all the part to come together, but now we are starting to look at what's the outcome? What is it we're trying to build? We're getting some assistance here and we'll see that we're getting more assistance from AI.

Now we can really shift and have people focused on what it is and why we're trying to built something. And so we're really seeing a balance. Of AI insights, those things that we are bringing in from AI, with human judgment. And you can really think of this as a collaboration. And in this collaboration, we have AI doing the broad analysis. And this is really, okay, so now AI is taking over, it's starting to write some of the code.

It's starting the write the docs. It's actually starting to build architectures for us. It's staring to look at how are we merging all this stuff together? How is the differences coming into the repos? How do we control the merging and the pulls and all of that? And it's also integrating into what we had in the automation with how are doing the checks?

How are we doing code quality? AI is really looking at a broad analysis of everything going on here. And so the humans, so we, are now kind of left to like, we can set the context. And by the context, it's like, okay, yes, all this is really good, but what is it that we're trying to do? And if we set the contacts, we also make judgments. So we asked AI to build a piece, and we look at it and say, okay compare it against business outcomes, is that what we want?

So we can start iterating. We can iterate through prompts on how we're developing and building stuff. So we apply trade-off or judgments here, but we also can make trade-offs. And the trade- offs are like, okay, there's a couple of different approaches as we've been working through this. So now I'm gonna trade off one approach for the other. And it goes back to the judgment.

And it also is like, what is the context ultimately of what I'm trying to do? And so the results here. If we think about the results of this transformation, it's really, we start becoming first-class engineers. Humans do what humans do good. The humans think about what it is and why I'm trying to build something, and AI does what it does good, which is looking at all the parts, all the moving components, all the things that we have to take into consideration and handling that.

And all of this is back. By test. By automated checks, the things that we're still doing as part of the automation era. And it's also looking at the run time and looking for run time evidence. And so if we start thinking about what this means and how we're doing reviews, this really starts, our reviews then really start becoming evidence-based. And that evidence is built on all of what we've had from before, but we also look at the business requirements, the business, and then we also looked at the outcomes and we

bring this in. And so to think of this type of review, we've gone from syntax reviews, to consensus reviews and system reviews, and now we're really getting to what are outcome reviews. Did we build what we're trying to build? Not how did we build it, did we built what we were trying to built? So, as you can see, the emergence of AI-based code development has resulted in a shift away from a focus on code implementation, and the future of code review is not reviewing more code, it's validating intent, outcomes, and

business impact across an increasingly AI-generated system. Thank you for watching.