AI is quickly being integrated into every stage of the software development lifecycle—from defining requirements and generating code to testing, documentation, and deployment. Code review is no exception. As teams incorporate these tools into their workflows, the relationship between AI and code review is developing in two related ways.
Developers can use AI to examine their work before it reaches another person, helping them find missing exception handling, inconsistent naming, or code that doesn’t follow the project’s standards. At the same time, AI coding tools are producing more of the code that teams need to review. Both changes can make development faster, but neither removes the need for an experienced developer to understand what the code should do, how it fits into the application, and whether it’s the right solution.
At Traust, we’ve built AI into our code review process where it adds real value. We use it to speed up the research behind a review, provide a valuable first pass, and help developers examine their own work before handing it to someone else. At the same time, we know AI can generate code that works but should never have been written. The tools will continue to evolve, but that basic approach gives us a strong foundation for using them responsibly.
AI Can Add a First Layer of Review
Traditionally, a developer might finish a change, test it, and then submit it to another developer for review. Now we can add another step in between: asking an AI coding tool to review the change first.
That initial pass can catch fairly common issues, such as:
- Missing exception handling or logger calls
- Naming and formatting that don’t follow project conventions
- Repeated or unnecessarily complicated code
- Unclosed conditions or other syntax problems
- Missing documentation
- Possible security or performance concerns
This doesn’t mean the code is ready to merge when the AI approves it. Rather, it lets the developer clean up straightforward issues before asking a teammate to review the work.
Instead of using the first pass to point out a missing logger call or an obvious formatting problem, the human reviewer can spend more time on questions that require context: Does the functionality match the ticket? Is the approach consistent with the rest of the application? Will another developer be able to support it later?
In that sense, AI doesn’t eliminate review work. It helps move some of the routine work earlier in the process.
A review-sql.md file defines how the AI should evaluate SQL and PL/SQL against project standards, giving it the context needed to provide a useful first pass before human review.
An AI Review Is Only as Useful as Its Context
A generic request to “review this code” may produce useful suggestions, but it doesn’t tell the AI much about how a particular team builds software.
For example, the AI may know common PL/SQL practices, but it won’t automatically know that a project requires a specific logging framework or prefers native Oracle APEX processes over custom code. It may suggest something technically acceptable but inconsistent with the application.
That’s why we keep development rules and review instructions alongside the project code. Those rules give the AI a more useful checklist: look for logger calls, follow the agreed naming conventions, check project-specific PL/SQL patterns, and compare the implementation against the team’s documentation.
The same principle applies to human review. Standards make feedback less subjective because the reviewer can point to an agreed practice instead of a personal preference. Giving those standards to an AI reviewer makes its feedback more relevant for the same reason.
However, more context doesn’t make the AI infallible. It simply gives the tool a better starting point.
AI Can Make a Large Codebase Easier to Understand
One of the most useful applications of AI and code review may be the research that happens before a reviewer can make a judgment.
Consider a PL/SQL package with 20,000 lines of code. A reviewer may need to examine a small change but have little experience with the package or its business rules. First, that person needs to understand which procedures are involved, how they connect, and what else might be affected.
AI can help the reviewer get oriented. It can summarize a package, explain a procedure in plain language, trace connections between functions, or identify sections related to a requirement. It can also compare versions and pinpoint which application components changed.
This is especially useful in Oracle APEX, where logic may be spread across page processes, dynamic actions, SQL queries, PL/SQL packages, shared components, and component attributes. The reviewer still needs to verify the AI’s explanation, but the tool can reduce the time spent finding where to begin.
Sometimes the simplest use is one of the best: ask AI to translate unfamiliar code into human language. That explanation isn’t the review itself, but it provides enough context to start asking better questions.
AI-Generated Code Creates New Review Work
The other side of this relationship is that AI tools are writing more code. That can increase development speed, but it can also create a false sense that a task is finished because the generated code works.
But working code isn’t always good code.
For example, we’ve seen AI generate a custom implementation for behavior that Oracle APEX already handles through a native process. The code may compile and produce the expected result, but it adds logic that the team now needs to test, secure, document, and maintain. It may also work differently from hundreds of other pages in the same application. (Oracle’s APEXlang skills help reduce this risk by showing AI coding agents in VS Code how to create native APEX components through APEXlang, giving them better platform context without removing the need for human review.)
This is a common risk with generated code. The AI responds to the immediate request, but it may not recognize the simplest option available in the framework or the pattern already established across the project. It can produce an answer that is technically plausible while still being the wrong choice for that application.
AI-generated code may also include unnecessary abstractions, duplicated logic, generic names, or error handling that doesn’t match project standards. Human developers create these problems too. The difference is that AI can produce a large amount of code very quickly, so the review burden can grow just as quickly.
As code generation gets faster, teams need to be careful not to let review become a superficial step between generation and deployment.
Treat AI Feedback as a Suggestion — Not a Verdict
AI reviewers can be useful, but they can also be very confident when they’re wrong.
A tool may flag code because it looks inefficient or unconventional. In context, however, a performance requirement or business rule may explain the decision. The AI sees an unexpected pattern and labels it as a problem, even though changing it would make the application worse.
That’s why an AI finding should begin a question rather than end the discussion:
- Is the concern technically correct?
- Does the tool understand the surrounding application?
- Is there a project-specific reason the code works this way?
- Would the suggested change improve the application or merely make the code look more conventional?
To paraphrase a 1979 IBM training manual, “the AI can never be held accountable” for the result. The developer has to decide whether the suggestion makes sense and remains accountable for the code that moves forward.
Blindly accepting AI review comments isn’t much safer than blindly accepting AI-generated code.
Human Review Moves Toward the Bigger Questions
As AI handles more initial analysis, the human reviewer’s role becomes less about scanning every line for simple issues and more about understanding the change as a whole.
That includes questions AI may struggle to answer reliably:
- Does this solve the user’s actual problem?
- Does it fit the architecture and patterns of the application?
- What other functionality could be affected?
- Is the solution understandable and maintainable?
- Are the performance and security tradeoffs acceptable?
- Is custom code necessary at all?
These questions require knowledge of the application, the client, and the decisions made throughout the project. They also require conversation. A reviewer may question an approach, the developer may explain it, and both may arrive at a better solution.
AI can support that conversation by gathering information and offering another perspective. It can’t replace the shared judgment behind it.
Code Review Still Belongs to the Team
The future of AI and code review isn’t a choice between automated review and human review. The strongest process uses each where it adds the most value.
AI can give developers a useful pre-review, enforce documented standards, summarize unfamiliar code, and help reviewers find the parts of a large application that deserve attention. Human reviewers can then evaluate whether the change is correct, maintainable, consistent, and appropriate for the application.
At the same time, teams need to apply that same discipline to code generated by AI. Faster output is only valuable if the resulting application remains understandable, supportable, and dependable.
The tools will continue to change, and our processes will change with them. But the goal of code review remains the same: catch problems before they reach production, share knowledge across the team, and make sure the code we deliver isn’t just functional, but right for the application.
