Review
The Tabnine Code Review Agent (in development)
Last updated
Was this helpful?
The Tabnine Code Review Agent (in development)
Last updated
Was this helpful?
The Code Review Agent is currently in Private Preview and available to to existing enterprise customers. Please to request early access.
Tabnineâs Code Review Agent enables organizations to produce higher quality, more secure code by leveraging and enforcing any given teamâs unique best practices and standards for software development.
The agent checks the code against rules that align with your unique standards.
If the code doesnât conform with your rules, the agent flags the deviations and provides guidance and suggested edits to fix the issues.
To use the Code Review Agent, you first need to feed your coding standards and best practices into Tabnine. You can provide us one of the following:
Best practices document in plain language that Tabnine will convert into rules for validating code.
Access to your code repositories that serve as the gold standard for creating high-quality code. Tabnine will then extract the PR comments and other code patterns and convert them into rules for validating code.
In addition to each engineering team being able to define its own unique rules, Tabnine also offers a vast array of predefined rules any team can activate, including commonly used industry standards and language or framework-specific best practices.
Tabnine has crafted a set of predefined rules by leveraging various best practices documents, as well as thorough vetting by language-specific experts.
We have more than 140 rules for each supported language (half are related to security, while the rest verify the codeâs correctness, readability, and performance).
Although some rules are generic (e.g., relevant to all Python code), most are library-specific (e.g., Cryptography, SSL, lxml), which ensures that the Code Review Agent validates not only the high-level structure of the code, but also specific functions.
Rules are in plain language, making it easy to review and maintain them.
Rules are at an organizational level (i.e., the same set of rules is available to every Tabnine user within the company).
Rules can be enabled or disabled and their severity can be set (during Private Preview, this will be done by the Tabnine team).
A rule should be descriptive, clear, and concise, and should focus on a single pattern of code that should be followed or avoided. Here are examples of effective and ineffective rules:
Effective rule: âUse Parameterized SQL queries: ensure that SQL queries are parameterized to prevent SQL injection attacksâ provides a clear description of the rule and its purpose, which will be useful both for the AI and the developer that sees it as a comment in the PR.
Ineffective rule: âAvoid risky concurrency code patterns that should not be usedâ is too general, making it more difficult for the AI agent to understand the patterns that should be enforced or avoided.
Each rule has the following fields. The customer needs to provide the information in the âdescriptionâ field, and the rest of the fields are optional (i.e. if you donât provide the information, Tabnine will generate the information for you. You can edit the information provided by Tabnine if needed.)
Description: Write a short description of the desired behavior. For example, âalways check the response status code for an HTTP request to ensure it was successful (e.g., response.status_code == 200 for a successful GET request)â. Alternatively, describe the behavior that needs to be avoided (e.g., âDo not ignore checking the response status code after making an HTTP request.â)
Language (optional): The code language(s) on which the rule should be applied
Severity (optional): How severe you find a violation of this rule. Options are INFO/WARNING/ERROR/CRITICAL.
Category (optional): What category the rule is related to: performance, security, or architecture. This will be shown in the review comment.
Good example (optional*): An example of a piece of code that follows the rule (e.g., a function that sends an http request and checks the status code).
Bad example (optional*): An example of a piece of code that violates the rule (e.g., a function that sends an http request and doesnât check the status code).
Library (optional): If the rule is relevant for a specific library, or a list of libraries.
* The good and bad examples are optional, but for rules that are related to internal enterprise code (e.g., âUse a db api wrapper created in the enterprise codebase instead of the db generic libraryâ), we highly recommend providing such examples to improve the effectiveness of the AI agent.
Predefined Rules
âNever send sensitive information (such as usernames or passwords) in the URLs and query parameters as they are not secure. The recommendation is to use headers.â
âOnly use SHA256 to securely hash data.â
âUse timeouts when sending HTTP requests to avoid blocks in the application.â
Customer-Specific Rules
âOnly use library acme_secure_api_access for accessing external APIs, do not use standard http libraries,â or âNever encrypt data yourself, always use acme_encryption_service.â (These rules use a company-specific service instead of allowing new code to be added that repeats an existing function.)
âNever access the users database table directly, use acme_user_service APIs.â (This rule applies another company-specific policy for service reuse.)
âUse acme_dropdown components instead of the react standard dropdown component.â
The Code Review Agent reviews the code in the pull request.
When developers create a pull request, the Code Review Agent checks the code in the PR against the set of rules.
If the code doesnât conform to your expectations in any way, the agent flags it to the code reviewer and provides guidance and suggested edits to fix the issue.
During Private Preview, we support the following:
Languages: Python, Java, JavaScript, TypeScript, C#, Kotlin, PHP, C++.
Platforms: GitHub and CLI
LLM: The underlying LLM for the Code Review Agent is GPT-4o mini