LoreSpec: an open standard for structured AI conversation outputs. Makes agent chats portable, auditable, and machine‑readable. Model‑agnostic — works with any LLM that reads a system prompt. Plug it into your audit/pipeline: https://lorespec.org/

The AI landscape is experiencing unprecedented growth and transformation. This post delves into the key developments shaping the future of artificial intelligence, from massive industry investments to critical safety considerations and integration into core development processes.

Key Areas Explored:

• Record-Breaking Investments: Major tech firms are committing billions to AI infrastructure, signaling a significant acceleration in the field.
• AI in Software Development: We examine how companies are leveraging AI for code generation and the implications for engineering workflows.
• Safety and Responsibility: The increasing focus on ethical AI development and protecting vulnerable users, particularly minors.
• Market Dynamics: How AI is influencing stock performance, cloud computing strategies, and global market trends.
• Global AI Strategies: Companies are adapting AI development for specific regional markets.

This deep dive aims to provide developers, tech leaders, and enthusiasts with a comprehensive overview of the current state and future trajectory of AI.

AI #ArtificialIntelligence #TechTrends #SoftwareEngineering #MachineLearning #CloudComputing #FutureOfTech #AISafety

Why Automate PR Reviews on GitHub with Qodo Merge

Pull request review is the biggest recurring time cost in most engineering teams. Every PR that sits waiting for a human reviewer represents blocked work, lost context, and accumulated merge conflicts. The problem scales with team size – a 20-developer team generating 15 PRs per day can easily accumulate hours of review backlog each week, especially when senior engineers are the bottleneck.

Qodo Merge addresses this by providing AI-powered PR review that triggers automatically when a pull request is opened on GitHub. Built on the open-source PR-Agent engine, Qodo Merge analyzes your diff, generates structured PR descriptions, posts code review comments with severity ratings, suggests improvements, and identifies test coverage gaps – all within minutes of the PR being created. The February 2026 release of Qodo 2.0 introduced a multi-agent architecture where specialized agents handle bug detection, security analysis, code quality, and test coverage simultaneously, achieving the highest F1 score (60.1%) among eight AI code review tools in benchmark testing.

This guide covers everything you need to set up Qodo Merge on GitHub – from installing the managed GitHub App to self-hosting PR-Agent via GitHub Actions, configuring review behavior with .pr_agent.toml, and using slash commands to interact with the AI reviewer directly in your pull requests. Whether you want the managed experience or full self-hosted control, you will have automated PR review running on your GitHub repositories by the end of this guide.

For a broader look at the Qodo platform including test generation and IDE features, see our Qodo review. For pricing details across all tiers, check our Qodo Merge pricing breakdown.

Option 1: Install the Qodo Merge GitHub App

The fastest way to get Qodo Merge running on GitHub is through the managed GitHub App. This requires no CI/CD configuration, no Docker containers, and no API key management. Qodo handles the infrastructure, and you get reviews on your PRs within minutes of installation.

Step 1: Sign up and authorize

1. Navigate to qodo.ai and click Sign Up or Get Started
2. Choose GitHub as your sign-in method
3. GitHub displays an OAuth authorization page asking you to grant Qodo permission to read your profile information
4. Click Authorize to proceed

After authorization, you land on the Qodo dashboard where you can manage repositories, view review activity, and configure organization-level settings.

Step 2: Install the GitHub App

The GitHub App installation is separate from the OAuth sign-in. The OAuth grants Qodo access to your identity, while the App installation grants it access to your repositories and pull request events.

1. From the Qodo dashboard, click Add Repositories or Install GitHub App
2. GitHub displays the App installation page with the required permissions:
   • Read access to repository contents, metadata, and pull requests
   • Write access to pull request comments, issues, and checks
   • Webhook subscriptions for pull request creation and update events
3. Choose your installation scope:
   • All repositories – Qodo Merge reviews PRs on every repository in the organization, including repositories created in the future
   • Only select repositories – choose specific repositories from a list and add more later as needed
4. Click Install to complete the process

For GitHub organizations, the installation may require organization owner approval. If you see a Request button instead of Install, the request is forwarded to your organization owner. Ask them to approve the Qodo app under Settings, then Third-party access.

Step 3: Verify the installation

Once the GitHub App is installed, verify it works by opening a pull request on one of the enabled repositories.

1. Create a branch and make a code change
2. Push the branch and open a pull request targeting your default branch
3. Wait 2 to 4 minutes for Qodo Merge to analyze the diff

Qodo Merge posts several items on the PR:

• A PR description summarizing the changes, categorized by type (bug fix, feature, refactor, etc.)
• A code review with structured findings organized by severity – bugs, security issues, code quality, and best practices
• Code improvement suggestions with specific, actionable recommendations for each finding

If nothing appears after 5 minutes, check the troubleshooting section at the end of this guide.

Option 2: Self-Host PR-Agent via GitHub Actions

For teams that want full control over the review pipeline – or need to keep source code within their own infrastructure – self-hosting PR-Agent via GitHub Actions is the best approach. PR-Agent is the open-source engine behind Qodo Merge, available under the Apache 2.0 license on GitHub. You bring your own LLM API keys, and the review runs entirely within your GitHub Actions environment.

This is the most popular deployment method among teams using the open-source version of Qodo Merge, and it is the approach our Qodo Merge review recommends for budget-conscious teams.

Prerequisites

Before setting up the GitHub Action, you need:

• A GitHub repository with Actions enabled
• An OpenAI API key (or an API key for another supported LLM provider like Anthropic, Azure OpenAI, or Hugging Face)
• Repository admin access to add secrets and workflow files

Create the workflow file

Create a new file at .github/workflows/pr-agent.yml in your repository:

name: PR-Agent

on:
  pull_request:
    types: [opened, reopened, ready_for_review, review_requested]
  issue_comment:
    types: [created]

jobs:
  pr_agent:
    if: ${{ github.event_name == 'pull_request' || (github.event_name == 'issue_comment' && startsWith(github.event.comment.body, '/')) }}
    runs-on: ubuntu-latest
    permissions:
      issues: write
      pull-requests: write
      contents: read
    name: Run PR-Agent
    steps:
      - name: PR-Agent
        id: pr_agent
        uses: Codium-ai/pr-agent@main
        env:
          OPENAI_KEY: ${{ secrets.OPENAI_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          github_action_config.auto_review: "true"
          github_action_config.auto_describe: "true"
          github_action_config.auto_improve: "true"

Add your API key as a repository secret

1. Go to your repository on GitHub
2. Navigate to Settings, then Secrets and variables, then Actions
3. Click New repository secret
4. Set the name to OPENAI_KEY and paste your OpenAI API key as the value
5. Click Add secret

The GITHUB_TOKEN secret is automatically provided by GitHub Actions and does not need to be configured manually. It grants the workflow permission to post comments on pull requests.

Understanding the workflow configuration

The workflow triggers on two event types:

• pull_request events (opened, reopened, ready_for_review, review_requested) – these trigger the automatic review, description, and improvement commands
• issue_comment events – these enable slash commands like /review, /describe, and /improve that you type as PR comments

The three github_action_config environment variables control which commands run automatically:

Set any of these to "false" if you want to trigger them manually via slash commands instead.

Test the setup

Commit the workflow file to your default branch, then open a new pull request. Within 2 to 4 minutes (depending on the diff size and LLM response time), PR-Agent should post its review comments on the PR. Check the Actions tab in your repository to see the workflow run and troubleshoot any errors.

Using Slash Commands for Interactive Review

One of the most powerful features of the Qodo Merge GitHub integration is the ability to interact with the AI reviewer using slash commands. These work with both the managed GitHub App and the self-hosted PR-Agent setup (as long as the issue_comment trigger is configured in your workflow).

Type any slash command as a comment on an open pull request, and Qodo Merge processes the request and responds with structured output.

/review – Full code review

The /review command triggers a comprehensive code review of the PR diff. The reviewer analyzes the changes for bugs, security vulnerabilities, code quality issues, and best practice violations.

/review

The output is a structured review with findings categorized by severity and type. Each finding includes a description, the relevant code snippet, and a suggested fix where applicable. You can also use /review --extended for a more thorough analysis that examines additional dimensions like error handling completeness and edge case coverage.

/describe – Generate PR description

The /describe command generates or updates the PR description based on the diff content.

/describe

Qodo Merge produces a structured description including a summary of what the changes do, the type of change (bug fix, feature, refactor, documentation), a file-by-file walkthrough, and optional labels. This is particularly useful for PRs opened by developers who leave the description blank or write minimal notes.

/improve – Code improvement suggestions

The /improve command identifies specific code improvements and presents them as actionable suggestions.

/improve

Each suggestion includes the file path, line number, the current code, a recommended change, and an explanation of why the change improves the code. Suggestions typically cover performance optimizations, readability improvements, and pattern adherence.

/ask – Ask questions about the PR

The /ask command lets you ask natural language questions about the pull request.

/ask What is the impact of this change on the existing authentication flow?

Qodo Merge analyzes the diff in context and provides a detailed answer. This is useful for understanding complex changes, especially when reviewing someone else’s PR.

/update_changelog – Generate changelog entries

/update_changelog

This command generates changelog entries based on the PR changes. It categorizes changes into sections like Added, Changed, Fixed, and Removed, following the Keep a Changelog format.

/add_docs – Generate documentation

/add_docs

Generates docstrings and inline documentation for functions and classes modified in the PR. The documentation follows the conventions of the target language – JSDoc for JavaScript, docstrings for Python, Javadoc for Java, and so on.

/test – Generate test suggestions

/test

Identifies untested code paths in the PR and suggests test cases with descriptions and expected behavior. This command does not generate complete test files (that is handled by Qodo Gen in the IDE), but it outlines what tests should be written to cover the new or modified code.

Configuring Review Behavior with .pr_agent.toml

The .pr_agent.toml file is the configuration center for Qodo Merge and PR-Agent. Place it in the root of your repository to customize how the AI reviewer behaves for that specific repository. This configuration works with both the managed GitHub App and self-hosted PR-Agent.

Basic configuration

Here is a starter configuration that covers the most commonly customized settings:

[pr_reviewer]
num_code_suggestions = 4
inline_code_comments = true
require_estimate_effort_to_review = true
extra_instructions = """
Focus on security vulnerabilities, logic errors, and missing error handling.
Do not comment on code style or formatting - our linter handles that.
"""

[pr_description]
publish_labels = true
use_bullet_points = true
add_original_user_description = true
include_generated_by_header = true

[pr_code_suggestions]
num_code_suggestions = 4
extra_instructions = """
Prioritize suggestions that fix potential bugs or improve error handling.
"""

[github_action_config]
auto_review = true
auto_describe = true
auto_improve = true

Excluding files from review

Use the ignore configuration to prevent Qodo Merge from reviewing files that do not benefit from AI analysis:

[ignore]
glob = [
  "*.lock",
  "*.generated.*",
  "dist/**",
  "node_modules/**",
  "*.min.js",
  "coverage/**",
  "__snapshots__/**",
  "*.svg",
  "*.png",
  "*.jpg"
]

This prevents the reviewer from wasting tokens and time on lock files, build output, generated code, minified files, and binary assets.

Custom labels

Define custom labels that Qodo Merge applies automatically based on the content of the PR:

[pr_description]
publish_labels = true

[pr_description.custom_labels.security]
description = "PR includes changes to authentication, authorization, or security-sensitive code"

[pr_description.custom_labels.database]
description = "PR includes database migrations, schema changes, or query modifications"

[pr_description.custom_labels.api]
description = "PR modifies public API endpoints or request/response schemas"

[pr_description.custom_labels.breaking-change]
description = "PR introduces a breaking change to an existing API or interface"

Adjusting review depth

Control how thorough the review is by adjusting the reviewer configuration:

[pr_reviewer]
# Number of code suggestions to generate (1-10)
num_code_suggestions = 6

# Include effort estimation for the review
require_estimate_effort_to_review = true

# Include security analysis in every review
require_security_review = true

# Ask the reviewer to identify testing gaps
require_tests = true

# Maximum number of files to review per PR (0 = unlimited)
max_files = 0

Higher values for num_code_suggestions produce more improvement recommendations but increase LLM token consumption and response time. For self-hosted PR-Agent, this directly affects your API costs. Start with 4 suggestions and increase if your team finds the output too brief.

Advanced GitHub Actions Configuration

Beyond the basic workflow, you can customize the PR-Agent GitHub Action for more complex scenarios.

Using a different LLM provider

PR-Agent supports multiple LLM providers. To use Anthropic’s Claude instead of OpenAI:

env:
  ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  config.model: "anthropic/claude-sonnet-4-20250514"
  github_action_config.auto_review: "true"
  github_action_config.auto_describe: "true"
  github_action_config.auto_improve: "true"

Add your Anthropic API key as a repository secret, and set the config.model to the desired Claude model. PR-Agent also supports Azure OpenAI, Hugging Face, and other providers through LiteLLM.

Running only on non-draft PRs

If you want to skip draft pull requests to save API costs:

on:
  pull_request:
    types: [opened, reopened, ready_for_review]

jobs:
  pr_agent:
    if: ${{ !github.event.pull_request.draft }}
    runs-on: ubuntu-latest

The ready_for_review trigger ensures that PR-Agent runs when a draft PR is marked as ready, so reviews are still triggered at the right time.

Restricting slash commands to specific users

By default, anyone who can comment on a PR can trigger slash commands. To restrict this to specific users or teams:

jobs:
  pr_agent:
    if: >
      github.event_name == 'pull_request' ||
      (github.event_name == 'issue_comment' &&
       startsWith(github.event.comment.body, '/') &&
       contains(fromJson('["username1","username2"]'), github.event.comment.user.login))
    runs-on: ubuntu-latest

Replace username1 and username2 with the GitHub usernames of users who should have permission to trigger AI review commands.

Running PR-Agent with Docker directly

For teams that want more control over the PR-Agent version and configuration, you can run the Docker image directly instead of using the GitHub Action:

steps:
  - name: Run PR-Agent
    run: |
      docker run --rm 
        -e OPENAI_KEY=${{ secrets.OPENAI_KEY }} 
        -e GITHUB_TOKEN=${{ secrets.GITHUB_TOKEN }} 
        -e github_action_config.auto_review=true 
        -e github_action_config.auto_describe=true 
        -e github_action_config.auto_improve=true 
        codiumai/pr-agent:latest

This approach lets you pin to a specific PR-Agent version by replacing latest with a version tag.

Customizing Review Behavior for Your Team

Getting Qodo Merge installed is the first step. Making it useful for your specific codebase requires tuning the review behavior based on your team’s conventions, tech stack, and pain points.

Writing effective extra_instructions

The extra_instructions field in .pr_agent.toml accepts natural language that guides the AI reviewer. Here are examples for common scenarios:

For a Node.js backend service:

[pr_reviewer]
extra_instructions = """
This is a Node.js Express backend using PostgreSQL.
Focus on:
- SQL injection prevention (all queries must use parameterized statements)
- Authentication middleware on all protected routes
- Proper error handling with try/catch and error logging
- Input validation using Joi or Zod schemas
Do not comment on import ordering or semicolon usage - our ESLint config handles those.
"""

For a React frontend:

[pr_reviewer]
extra_instructions = """
This is a React 19 application using TypeScript and Tailwind CSS.
Focus on:
- Proper hook usage (dependency arrays, cleanup functions)
- Component re-render prevention (memoization where appropriate)
- Accessibility (ARIA attributes, keyboard navigation, alt text)
- Type safety (no 'any' types without justification)
Do not comment on CSS class ordering or component file structure.
"""

Combining Qodo Merge with existing tools

Most teams already have linters, formatters, and CI checks running on their PRs. Qodo Merge complements these tools by providing semantic analysis that rule-based tools cannot perform. A practical setup looks like this:

• Linter (ESLint, Ruff, etc.) – handles formatting, style, and simple patterns
• Static analysis (SonarQube, Semgrep) – handles deterministic bug detection and security scanning
• Qodo Merge – handles AI-powered semantic review for logic errors, design issues, and contextual problems

Configure Qodo Merge to skip the categories that your other tools already cover:

[pr_reviewer]
extra_instructions = """
Do not comment on code formatting, import ordering, or naming conventions.
Our ESLint and Prettier configurations handle those concerns.
Focus exclusively on logic errors, security vulnerabilities, missing error
handling, and performance issues.
"""

This reduces comment noise and ensures that each tool in your pipeline contributes unique value rather than duplicating feedback.

Considering Alternatives

While Qodo Merge is a strong option for GitHub PR review, it is worth evaluating alternatives before committing to a tool. For a full list, see our guide to the best AI PR review tools.

CodeAnt AI is a Y Combinator-backed platform that bundles AI PR review with SAST security scanning, secret detection, infrastructure-as-code security, and DORA metrics in one tool. Pricing starts at $24/user/month for the Basic plan (PR review with line-by-line feedback and one-click auto-fixes) and goes to $40/user/month for the Premium plan that adds security scanning and engineering dashboards. For teams that want PR review plus security analysis without stitching together multiple tools, CodeAnt AI offers strong value at a competitive price point.

CodeRabbit at $24/user/month provides faster review times (approximately 90 seconds versus Qodo’s 2 to 4 minutes), a lower false positive rate, and 40+ built-in linters. Its free tier is more generous than Qodo’s, with unlimited repositories and hourly rate limits instead of a monthly cap.

The open-source PR-Agent route is the most cost-effective if your team has the DevOps capacity to manage the deployment. A 20-developer team self-hosting PR-Agent typically spends $20 to $80 per month on LLM API costs versus $600 per month for the Qodo Teams subscription. See our Qodo Merge pricing guide for a detailed cost comparison.

For teams evaluating broader alternatives to the Qodo platform, our Qodo alternatives guide covers the full landscape of competing tools.

Troubleshooting Qodo Merge on GitHub

Qodo Merge is not posting reviews

Check the GitHub App installation. Navigate to your GitHub organization settings (or personal account settings), then Applications. Verify that Qodo Merge (or PR-Agent) is listed and has access to the target repository.

Check the webhook deliveries. In your repository settings, go to Webhooks and examine the recent deliveries. Failed deliveries with 4xx or 5xx response codes indicate a connectivity issue between GitHub and Qodo’s servers. For self-hosted PR-Agent, check the GitHub Actions workflow logs instead.

Check if the PR is a draft. Qodo Merge skips draft pull requests by default. Mark the PR as ready for review or configure draft PR handling in your .pr_agent.toml:

[github_action_config]
handle_draft_pr = true

Check the free tier limits. The Qodo free Developer plan caps at 30 PR reviews per month for the entire organization. If your team has exceeded this limit, reviews stop until the next billing cycle. Check the Qodo dashboard for your current usage.

Check the Actions workflow (self-hosted only). Go to the Actions tab in your repository and look for failed PR-Agent runs. Common failures include expired or invalid API keys, rate limiting from the LLM provider, and permission errors on the GITHUB_TOKEN.

Slash commands are not working

Verify the issue_comment trigger. Your GitHub Actions workflow must include issue_comment as a trigger event for slash commands to work. If you only have pull_request triggers, slash commands will not be processed.

Check the conditional logic. The workflow job needs an if condition that allows issue_comment events where the comment body starts with /. Review the workflow example in this guide and confirm your condition matches.

Verify permissions. The workflow needs issues: write and pull-requests: write permissions to post response comments. Check the permissions block in your workflow file.

Reviews are too noisy

Add file exclusions. Configure the [ignore] section in .pr_agent.toml to skip files that generate low-value comments – lock files, generated code, minified assets, and test snapshots.

Reduce the number of suggestions. Lower the num_code_suggestions value in the [pr_reviewer] and [pr_code_suggestions] sections. Start with 3 to 4 and increase only if the team wants more.

Add targeted extra_instructions. Tell the reviewer what not to comment on. If your linter handles formatting and your team has agreed on naming conventions, exclude those categories explicitly.

Disable automatic commands. If auto_review, auto_describe, and auto_improve are all enabled, each PR gets three separate comment threads. Disable the ones your team does not find useful:

[github_action_config]
auto_review = true
auto_describe = true
auto_improve = false

Configuration file is not being read

Verify the file name. The file must be named exactly .pr_agent.toml in the repository root. Variations like pr_agent.toml (without the leading dot) or .pr_agent.yaml (wrong format) are not recognized.

Verify the file is on the default branch. PR-Agent reads the configuration from the default branch, not from the PR branch. Merge your .pr_agent.toml to main (or your default branch) before testing.

Validate the TOML syntax. Use a TOML validator to check for syntax errors. Common mistakes include missing quotes around string values, incorrect table headers, and improperly escaped special characters.

Summary

Setting up Qodo Merge on GitHub gives your team automated PR reviews that catch bugs, security vulnerabilities, and code quality issues before human reviewers spend time on the pull request. The managed GitHub App is the fastest path – install it, select your repositories, and reviews start appearing within minutes. The self-hosted PR-Agent approach via GitHub Actions offers the same core review capabilities at a fraction of the cost, with full control over your data and infrastructure.

The slash commands – /review, /describe, /improve, /ask, and others – turn the AI reviewer into an interactive tool rather than a passive commenter. Combined with the .pr_agent.toml configuration file, you can tailor the review behavior to match your team’s coding standards, tech stack, and quality priorities.

Whether you choose the managed app or the self-hosted route, the goal is the same: every pull request gets immediate, structured feedback so that human reviewers can focus on architecture, design decisions, and the contextual questions that genuinely require human judgment.

Further Reading

• How to Set Up Qodo AI in JetBrains (IntelliJ, PyCharm, WebStorm)
• How to Set Up Qodo AI in VS Code: Installation Guide
• Best AI Code Review Tools in 2026 – Expert Picks
• Best AI Test Generation Tools in 2026: Complete Guide
• CodiumAI Alternatives: Best AI Tools for Automated Testing in 2026

Frequently Asked Questions

How do I install Qodo Merge on GitHub?

There are two ways to install Qodo Merge on GitHub. The first is the managed Qodo Merge GitHub App, which you install from the Qodo website by signing in with your GitHub account, authorizing the app, and selecting your repositories. The second is self-hosting PR-Agent via GitHub Actions by creating a workflow file in your repository, adding your LLM API key as a GitHub secret, and configuring the action to trigger on pull request events. The GitHub App is the faster option and requires no CI configuration, while the GitHub Actions approach gives you full control over the review pipeline and avoids sending code to Qodo’s servers.

What slash commands does Qodo Merge support on GitHub?

Qodo Merge supports several slash commands that you type as PR comments. The main commands are /review to trigger a full code review, /describe to generate or update the PR description, /improve to get code improvement suggestions, /ask followed by a question to ask about the PR, /update_changelog to generate changelog entries, /add_docs to generate documentation for changed code, and /test to generate test suggestions for modified functions. Each command triggers a specific AI agent that analyzes the PR diff and posts structured feedback directly on the pull request.

Is Qodo Merge free for GitHub repositories?

Yes, in two ways. The Qodo free Developer plan includes 30 PR reviews per month at no cost, and it works with GitHub repositories through the managed GitHub App. Alternatively, you can self-host PR-Agent – the open-source engine behind Qodo Merge – for free using GitHub Actions with your own LLM API keys. The self-hosted option has no review limits and no subscription cost. The only expense is LLM API usage, which typically costs a few cents per review depending on the diff size.

How do I set up PR-Agent as a GitHub Action?

Create a workflow file at .github/workflows/pr-agent.yml in your repository. Set the trigger to pull_request events including opened, reopened, ready_for_review, and review_requested types. Use the Codium-ai/pr-agent Docker image as the action, pass your OpenAI API key as a secret named OPENAI_KEY, and specify the PR-Agent commands you want to run – typically github_action with auto_review, auto_describe, and auto_improve enabled in the configuration. Commit the workflow file to your default branch and open a pull request to test it.

What is the difference between the Qodo Merge GitHub App and self-hosted PR-Agent?

The Qodo Merge GitHub App is a managed service that handles all infrastructure, provides the multi-agent review architecture from Qodo 2.0, includes the context engine for multi-repo intelligence, and offers SOC 2 compliance. Self-hosted PR-Agent is the open-source version that runs in your own GitHub Actions pipeline with your own LLM API keys. It includes core review features like describe, review, and improve commands but does not include the multi-agent architecture, context engine, analytics dashboard, or managed hosting. The GitHub App is easier to set up but costs $30/user/month on the Teams plan, while self-hosted PR-Agent is free aside from LLM API costs.

How do I configure Qodo Merge review behavior on GitHub?

Create a .pr_agent.toml file in your repository root. This TOML configuration file controls review behavior including which commands run automatically on PR events, the number of code suggestions, whether to include effort estimation, which files to exclude from review, and custom prompts for the AI reviewer. Configuration options include pr_reviewer settings for review depth and focus, pr_description settings for auto-generated descriptions, and pr_code_suggestions settings for improvement recommendations. Changes to the configuration file take effect on the next pull request without any restart.

Can I run Qodo Merge only on specific GitHub repositories?

Yes. When installing the Qodo Merge GitHub App, you can choose between granting access to all repositories in your organization or selecting specific repositories from a list. You can change this selection at any time in your GitHub organization settings under Applications. For the self-hosted PR-Agent approach via GitHub Actions, you control exactly which repositories run the review by adding or removing the workflow file from each repository. This gives you granular control over which repos get automated PR review.

Why is Qodo Merge not reviewing my GitHub pull requests?

Check these common causes in order. First, verify the GitHub App is installed on the repository by checking your GitHub organization settings under Applications. Second, check if the PR is a draft – Qodo Merge may skip draft PRs by default. Third, verify you have not exceeded the free tier limit of 30 PR reviews per month. Fourth, check your .pr_agent.toml configuration for path exclusions that might be filtering out the changed files. Fifth, check the GitHub webhook deliveries in your repository settings to ensure webhooks are being delivered successfully. For self-hosted PR-Agent, also verify that your LLM API key is valid and your GitHub Actions workflow is running without errors.

Does Qodo Merge work with GitHub Enterprise?

Yes. Qodo Merge supports GitHub Enterprise through both the managed GitHub App and self-hosted PR-Agent. For GitHub Enterprise Cloud, the standard GitHub App installation process works. For GitHub Enterprise Server (self-hosted GitHub), self-hosting PR-Agent via GitHub Actions is the recommended approach since the Qodo managed app may not be able to reach your internal GitHub instance. The Enterprise plan also supports on-premises and air-gapped deployments for organizations with strict network isolation requirements.

How do I customize the PR description generated by Qodo Merge?

Configure the pr_description section in your .pr_agent.toml file. You can set publish_labels to control whether labels are added, use_bullet_points to switch between paragraph and bullet-point format, add_original_user_description to preserve the original PR description alongside the AI-generated one, and include_generated_by_header to show or hide the attribution line. You can also add custom_labels with name, description pairs to define your own labeling taxonomy that Qodo Merge applies automatically based on the PR content.

What alternatives to Qodo Merge are available for GitHub PR review?

The main alternatives for GitHub PR review are CodeRabbit at $24/user/month with 40+ built-in linters and a generous free tier, CodeAnt AI starting at $24/user/month with bundled SAST and DORA metrics, GitHub Copilot code review at $19/user/month built natively into GitHub, and Sourcery with Python-focused review. CodeRabbit is the most popular alternative with faster review times (90 seconds vs 2-4 minutes) and lower false positive rates. CodeAnt AI bundles the most security features at its price point. For a comprehensive comparison, see our guide to the best AI PR review tools.

How do I use the /review command in Qodo Merge?

Type /review as a comment on any open pull request in a repository where Qodo Merge is installed. The AI agent analyzes the full diff, checks for bugs, security vulnerabilities, code quality issues, and best practice violations, then posts a structured review with categorized findings and severity ratings. You can add flags to customize the review – for example, /review –extended to get a more thorough analysis. The review typically completes within 2 to 4 minutes. You can trigger /review multiple times on the same PR, and each run analyzes the latest state of the diff.

Can I use Qodo Merge alongside other GitHub review tools?

Yes. Qodo Merge runs independently and does not conflict with other review tools like CodeRabbit, SonarQube, Semgrep, or GitHub’s built-in code review. Each tool posts its own comments on the pull request. Many teams layer Qodo Merge for AI-powered semantic review alongside a static analysis tool like SonarQube for deterministic rule enforcement. The only consideration is that multiple AI review tools posting on the same PR can create comment noise, so most teams choose one AI reviewer and complement it with rule-based analysis tools.

Originally published at aicodereview.cc

DISCLAIMER!!: DO NOT INSTALL OPENCLAW ON YOUR PERSONAL MACHINE. IT IS STRONGLY RECOMMENDED THAT YOU USE A VIRTUAL MACHINE OR A VIRTUAL PRIVATE SERVER INSTEAD.

Prerequisites
Before you begin, ensure you have the following:

1. A Virtual Private Server (VPS) or Virtual Machine with:
   • Node.js version 22.16 or later installed
   • Git installed
2. A Telegram account (or another supported messaging platform)
3. An API key for the AI model of your choice

Introduction

What is OpenClaw?
OpenClaw is a self-hosted gateway that connects your favorite messaging applications such as WhatsApp, Telegram and Discord, to your AI coding agents like Chat GPT.
OpenClaw allows you to chat directly with your AI model using your messaging app and have it do tasks for you.
How does it do tasks for you?
With OpenClaw, you can create Agents(action models) that use your AI model to perform task for you.

Step 1: Set up a VPS(Virtual Private Server)
Using a cloud platform of you choice, set up a server/ virtual machine.

In my case, I have setup my server on the Microsoft Azure platform.

Step 2: Access your VPS via SSH(Secure Shell) using terminal

From your machine, launch a terminal such as Git-bash, Powershell or in my case Mobaxterm.
Use the command username@ip-address to connect to your server. You will be prompted for a password, provide it and then you will successfully have accessed your cloud server.

Step 3: Security
The reason it is advised that you run OpenClaw on a VPS or a machine that does not have any of your personal information is because: 1) The software is opensource meaning that it has anyone contributing to it’s development including anyone with malicious intent. 2) OpenClaw requires elevated privileges on your machine as it interacts deeply with system memory or processes.

Click on the link to connect tailscale to the virtual machine
Install Tailscale

Run the command above to start tailscale. You will be given a link to signup to tailscale

Login or create an account if you do not have one
Choose the identity provider of your choice.

Select a device

click on the download button

Install the application

Look for the tailscale icon on your apps tray and click on it. It will redirect you to a login screen. Login using your credentials and then click the connect button.

You will get success and now you are now connected to a virtual private network.

Navigate to the following file sudo nano /etc/ssh/sshd_config
Copy the tailscale IP given to your server by tailscale

Make the above changes to the file

Create a new user
Add user to root

restart ssh service using the above command then logout the server using the logout command.

Access the server using the new username and the new tailscale IP address

With this, we have secured the server such that no other traffic can reach it other than devices on the this tailscale VPN network. Our server is secure.

Step 4: Install OpenClaw

Run the above command to install OpenClaw

Choose what you want to setup as local gateway.

Then select the workspace directory as the default provided one.

Select a model provider that you want OpenClaw to use. Remember that to use the model, you will need an API key from which in many instances you are required to have a paid subscription.
In my case, I am using OpenRouter, a website that allows you to connect to free available AI models out there.

After choosing the model, you will be prompted to provide an API key. Paste the API key that you generated from OpenRouter.

Then you will need to choose a default model under OpenRouter. There is a long list, scroll until you find your chosen model.

From OpenRouter, I am using a model known as StepFun 3.5 Flash. I chose it because I found it to have the best starts compared to the other available opensource models.

For gateway port and gateway bind, leave them as default. For the gateway auth, choose token.

For tailscale exposure leave as off, then on how to provide gateway token choose the generate/store plaintext token option then leave the gateway token blank.

Channel status; this is the social media application that you want to use to communicate with your model. Select yes to configure a channel.

Select a channel. For me, I will be using Telegram. OpenClaw then gives a small guide on how to obtain a Telegram bot token that you can use.

Open your Telegram application and search for BotFather. Select the account “BotFather” with a tick mark (It’s the Legitimate one).

In the chat with BotFather, type /newbot to create a new bot. The username has to end with the word ‘bot’. After choose a unique username, you will get the link to start a chart with the new bot you have created and also an API key (which you can enter in OpenClaw).

Enter the API key and when prompted to select a channel, scroll down and choose finished (the last option in the list).

When prompted for DM access policies select yes and pair with telegram.

For web search, choose a browser that you would like the agent to access and use for browsing (I recommend using a new browser that you don’t use for any of your personal activities/browsing). Then on your browser of choice get an API key and add it to OpenClaw.

For configuring skills, select ‘No’. You can configure skill later after the setup is complete.
What are skills in OpenClaw?
OpenClaw skills are plug-ins/additions for an OpenClaw AI agent: each skill teaches the agent how to do a specific task, such as searching the web, sending emails, controlling software, or running a workflow. Instead of the AI only chatting, skills give it extra abilities and step-by-step instructions so it can actually perform useful actions.

For hooks, choose, skip for now and for systemd lingering, choose enable.

For install gateway service, select yes and service runtime select the recommended ‘Node’ option. OpenClaw will install the gateway now.

After the gateway is installed, the agent will now be alive.

It will start asking questions such as the name to call it and what you want it to be. Provide the answers. This information is stored in a file BOTSTRAP.md this file defines what the agent is. Every time it starts, it reads this file to know/remember who it is.

It will then ask questions about you. This information is stored in USER.md, this tells the agent who you, the user is. Eg. It tells the agent to address you as (the name you want it to call you) and any other information you want it to know about you.

It then proceeds to ask about what behaviour you want it to have. This information is stored in a file SOUL.md, it gives the agent a character. I chose to stop there as this information can be added directly to the files directly i.e USER.md, SOUL.md, skills.md … Type /exit to leave the interactive cli.

To access bot via telegram, press the link provided by BotFather as shown here and it will take to the inbox chart of your bot.

After getting to the inbox chart of your bot, type /start to start the bot. It will give you a pairing code to use to connect the bot to OpenClaw.

Run the command openclaw pairing approve telegram <your pairing code> to connect your telegram bot to OpenClaw. If you get an error “command not found” as I did.

Locate the file openclaw on your host and navigate to that location. As shown, this is the location my file was at.

From the location of you file, execute the command and the connection to telegram will be approved.

And now we can chat with the bot from your telegram

If you want to access openclaw via web, run the command ssh -N -L 18789:127.0.0.1:18789 user@serverIP. This command maps the exposed port on our VPS to our local machine.
Note: The server and your local machine have to be in the same network. And how is this possible, using the tailscale configuration that we deed. By activating tailscale on both the VPS server and your local machine, tailscale creates secure network and adds both your machines into that network. This implements security as well as enables your machine to access the VPS server seamlessly.

Now you are able to access openclaw on your machine, but this gives you an error.

To solve it, navigate to the file openclaw on your host, run the following command ./openclaw dashboard --no-open. OpenClaw will give you a URL with a valid token. Paste the URL on your web browser. You will redirected to a tailscale website and prompted to login. Login, this authenticates you connection to OpenClaw using tailscale ( a security measure).

Now you are able to access the openclaw UI from your web browser. Here you can have a UI interface to configure your agent instead of using the cli/terminal interface.

Conclusion

This guide demonstrated how to install OpenClaw on a Virtual Private Server, secure the instance with Tailscale, obtain an API key for an open-source AI model through the OpenRouter platform, and connect everything to a Telegram bot as the communication channel for the AI agent. With this foundation in place, the next step is to equip your OpenClaw agent with the skills it needs, enabling it to perform specific tasks and automate real workflows.

This article served as an introduction to help you get started with OpenClaw and prepare you to build a more capable, customized AI agent. Happy building with OpenClaw, and enjoy creating an AI agent tailored to your own needs and ideas.