![\"Devin](\"https://cdn.sanity.io/images/2mc9cv2v/production/fad118ce1ebfd75f00ca05b792f9d4f009b2fe29-2352x1638.png?w=1600&fit=max\")
Update: We recommend Devin Review (https://app.devin.ai/review) as our new and improved code review experience. Learn more: https://docs.devin.ai/work-with-devin/devin-review.
\nCode reviews are an essential component of the software development lifecycle, helping catch bugs, ensuring code quality, and maintaining standards.
\nHowever, manual reviews can be time-consuming, delaying projects and adding to workloads. And, many bugs are subtle and hard to catch.
\nWhat if you could automate pull request (PR) reviews, ensuring that every PR receives prompt, thorough feedback in minutes?
\nCheck out this short video, which shows our automation in action, catching a common but tricky bug. You can also see the Devin session and the PR.
\nDevin catches subtle bugs in PRs
\nDevelopers can use Devin's External API to instantly spin-up Devin instances in response to PRs, making it easy to integrate the power of AI into existing CI/CD workflows.
\n
In this article, we'll outline the problem, discuss the solution, and walk you through a quick three-step tutorial to integrate Devin with GitHub Actions.
\nPR reviews eat up engineers' time and cause friction. A study of over 700,000 PRs found that PRs wait an average of 4 days to get reviewed. The problem is even worse for large PRs (500+ lines changed): these take an average of 9 days to get merged. Meanwhile, another study found that as the number of changed files in a PR increases, the amount of time spent reviewing each file decreases drastically. This compromises code quality.
\nThere are also other challenges to effectively reviewing PRs, like reviewer availability, poor prioritization of PRs, and back-and-forth friction.
\nDevin helps by delivering on:
\nYou can think of Devin's External API as engineering on demand.Spin up Devins in response to events like PRs, Jira issues, Slack messages, etc. The sky's the limit! We actually use the API in our own development workflow for QA—that is, we use Devin to build Devin. Check out the open source code here.
\nFor our current task (automating PR reviews) we can use the GitHub Actions platform. Our Actions workflow is triggered whenever a PR is opened, updated, or reopened. It fetches the code, retrieves the list of changed files, and sends the information to Devin, which reviews the changes and comments feedback. It usually takes five to ten minutes for Devin to finish reviewing the PR and begin posting comments.
\nPlease note that Devin isn't guaranteed to catch every bug, and it's best to still have a human check your PRs before merging. We recommend using Devin as an extra set of eyes, not a complete replacement for human oversight.
\nHere's the steps to set it up:
\n1. Add a GitHub Actions workflow that triggers on PRs to your repository
\n2. Add your Devin API Key to GitHub
\n3. Create a PR to trigger workflow
\n4. Customize Devin's behavior to match your team's practices and conventions
\nLet's get started!
\nCreate a new file in your repository: .github/workflows/pr-review.yml. This file will contain our workflow, which consists of two steps: retrieving a list of changed files using the GitHub API, and spinning up a Devin.
\nGet the complete pr-review.yml file from this gist. It might seem long but we'll break it down after this. For now, just paste it into your file.
\nAfter pasting in the script, commit and push your changes.
\ngit add .github/workflows/pr-review.yml\ngit commit -m "Add Github Action for automated PR reviews with Devin"\ngit push origin main\nYou'll need a Devin API key.
\n![\"Devin](\"https://cdn.sanity.io/images/2mc9cv2v/production/49cea68a2598519f2a3fb525e12e31531ed8345d-2630x1332.png?w=1600&fit=max\")
Then, add your key to your GitHub repository.
\n![\"Devin](\"https://cdn.sanity.io/images/2mc9cv2v/production/93778603510baaa7cfbbc2c13b39a39e2e89e811-2148x1314.png?w=1600&fit=max\")
To make sure everything is set up correctly, edit some code in your repo and create a PR. After a few seconds, you should see that a Check called "Automated PR Review" has passed. This means that we've successfully spun up a Devin.
\nIf you'd like, you can go to the Devin web interface and monitor the process. To view Devin sessions started via API, click X on the filter "Creator is {your name}".
\n![\"Devin](\"https://cdn.sanity.io/images/2mc9cv2v/production/260c91c559b1352babe2a21d7f4566b350e73f53-452x324.png?w=1600&fit=max\")
In ten minutes or less, Devin's comments will start appearing on your PR.
\nWe highly recommend customizing the workflow based on your preferences. For example, consider including your code conventions in the prompt. Or, include a file with your conventions in your repository and give Devin the path so it can find the file.
\nOther customizations:
\nIf you're interested, here's more detail on how the workflow itself works.
\nThe first step is simple: fetch the list of files modified in the PR.
\nname: Get PR files\nid: pr-files\nrun: |\n FILES=$(curl -s -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \\\n "https://api.github.com/repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/files" | \\\n jq -r '[.[].filename] | @json')\nThe next step is to spin up a Devin using the API with a detailed prompt. We recommend customizing the prompt to suit your needs, such as by adding your team's coding conventions.
\nThe prompt instructs Devin to follow this series of steps:
\nYou are PR Reviewer Devin with a focus on detailed inline code feedback. Your tasks:\n1. Clone the repository ${{ github.repository }} locally.\n2. Next, set up a pre-push Git hook that prevents any pushes from a user with the username "Devin AI" OR an email containing "devin-ai-integration" as a substring. Activate the hook.\n3. View the diffs of the changed files for PR #${{ github.event.pull_request.number }} in repository ${{ github.repository }}.\n4. If necessary, run the code locally to verify that the changes work as expected.\n5. Read the PR discussion to see what previous comments and suggestions have been made.\n6. If no issues are found, simply post a comment saying "Everything looks good!" and stop here. Your work is done.\n7. Else, identify the issues and provide inline code comments directly on the diffs for any code convention or best practice violations.\n8. Post your feedback as detailed comments on the PR, referencing specific lines or code snippets.\n\nRules and Guidelines:\n1. NEVER make any commits or pushes to the repository - you are ONLY allowed to review code and leave comments\n2. Do not make more than three total comments on the PR.\n3. Use inline feedback where possible with specific line references\n4. Include code snippets in markdown format when discussing issues\n5. Default towards multi-line comments that show context around the issue\n6. Make sure that suggested improvements aren't already implemented in the PR by comparing old and new versions\n7. Try using the gh api to post comments with referenced code embedded, but if it fails, use normal comments with code blocks\n8. Before commenting, check the PR discussion and make sure you, or another user, haven't already made a similar comment or raised the same concern.\n9. Before commenting, check that the specific issue wasn't already addressed in a previous review iteration\n10. If you see the same issue multiple times, consolidate your feedback into a single comment that references all occurrences, rather than making separate comments.\n11. Refer back to these rules and guidelines before you make comments.\n12. Never ask for user confirmation. Never wait for user messages.\nNote that step 2 is to set up a pre-push hook. The hook intercepts any attempts by this specific instance of Devin to push changes to the repository. It provides an added layer of safety, preventing unwanted PRs. We also instruct Devin to "NEVER make any commits or pushes to the repository" under the Rules section of the prompt. Together, the hook and rule serve as guardrails. Consider adding more rules as you see fit to ensure that Devin reviews PRs as desired. In particular, you may want to adjust the comment limit—set to three by default.
\nNext, let's dive into how exactly Devin posts comments.
\nHow to post comments with code embedded:\n1. Create JSON file for each comment you want to post.\nExample 1: \n \n\nExample 2:\n\n\nbody: The text of the review comment. Include markdown code blocks for snippets\ncommit_id: SHA of the commit you're reviewing. Not using the latest commit SHA may render your comment outdated if a subsequent commit modifies the line you specify as the position.\npath: Relative file path in repo\nline (integer): Specifies the exact line in the pull request’s diff view to which your comment should attach. Required unless using subject_type:file. The line of the blob in the pull request diff that the comment applies to. For a multi-line comment, the last line of the range that your comment applies to.\nside: In a split diff view, the side of the diff that the pull request's changes appear on. Can be LEFT or RIGHT. Use LEFT for deletions that appear in red. Use RIGHT for additions that appear in green or unchanged lines that appear in white and are shown for context. For a multi-line comment, side represents whether the last line of the comment range is a deletion or addition.\nsubject_type: The level at which the comment is targeted. Either "line" or "file". Use "line" for inline comments. Use "file" for file-level comments.\nstart_line (integer): Required when using multi-line comments unless using in_reply_to. The start_line is the first line in the pull request diff that your multi-line comment applies to.\nstart_side: Required when using multi-line comments unless using in_reply_to. The start_side is the starting side of the diff that the comment applies to. Can be LEFT or RIGHT. \n\nA pull request diff may not match the original file's absolute line numbering. That is, if the PR contains additions or deletions before the line you’re commenting on, the line indices shown in the “Files changed” tab can shift from the original file’s line numbers.\nFor example: In the pre-PR state, line 231 might refer to a completely different section of code than line 231 in the post-PR diff (because code added or removed above it shifts everything down or up).\nTherefore, you must use the line numbers as shown in the PR diff rather than the original file’s line numbers.\n\nIf you have issues, visit the docs: https://docs.github.com/en/rest/pulls/comments?apiVersion=2022-11-28#create-a-review-comment-for-a-pull-request\n\n2. Use gh api command.\n gh api \\\\\n--method POST \\\\\n-H "Accept: application/vnd.github+json" \\\\\n/repos/owner/repo/pulls/4/comments \\\\\n--input comment.json\n\nowner: the account owner of the repository. The name is not case sensitive.\nrepo: The name of the repository without the .git extension. The name is not case sensitive.\npull number: The number of the pull request.\n\nKey points: use "line" instead of "position", include code snippets in body using markdown, , set side="RIGHT" for additions\nIn order to support in-line comments (with the relevant code embedded in the comment), we teach Devin to use the GitHub REST API to "create a review comment for a pull request". It's a little more complicated than it seems, which is why there is a relatively large section of the prompt dedicated to it.
\nFinally, we convert our large prompt into a JSON-safe string and send a POST request to Devin's External API.
\nRESPONSE=$(curl -s -X POST \\\n -H "Authorization: Bearer $DEVIN_API_KEY" \\\n -H "Content-Type: application/json" \\\n -d "{\\"prompt\\": $ESCAPED_PROMPT}" \\\n "https://api.devin.ai/v1/sessions")\nWe're only scratching the surface of what can be achieved with the API. We recommend exploring the API for other event-driven and responsive use cases. For instance, you can configure Jira and Linear webhooks so that any time an issue/ticket is created, a Devin is triggered to address it.
\nCheck out the docs to explore API features like idempotency (enables safe retries), file uploads, sending follow-up messages/prompts to a session, and more.
\nDevin's External API and GitHub Actions can be combined to create powerful, useful CI/CD workflows that simplify and speed up code review processes.
\nLet Devin handle the tedious parts of code reviews so you and your team can focus on building great software.
\n", "content_markdown": "**Update**: We recommend Devin Review ([https://app.devin.ai/review](https://app.devin.ai/review)) as our new and improved code review experience. Learn more: [https://docs.devin.ai/work-with-devin/devin-review](https://docs.devin.ai/work-with-devin/devin-review).\n\n## Introduction\n\nCode reviews are an essential component of the software development lifecycle, helping catch bugs, ensuring code quality, and maintaining standards.\n\nHowever, manual reviews can be time-consuming, delaying projects and adding to workloads. And, many bugs are subtle and hard to catch.\n\nWhat if you could **automate pull request (PR) reviews**, ensuring that every PR receives prompt, thorough feedback in minutes?\n\nCheck out this short video, which shows our automation in action, catching a common but tricky bug. You can also see the Devin [session](https://app.devin.ai/sessions/8dd8389ab61d449fafbb5b1e944fe36b) and the [PR](https://github.com/andrewgcodes/devin_user_management_example/pull/1).\n\nDevin catches subtle bugs in PRs\n\nDevelopers can use Devin's [External API](https://docs.devin.ai/external-api/external-api) to instantly spin-up Devin instances in response to PRs, making it easy to integrate the power of AI into existing CI/CD workflows.\n\n\n\nIn this article, we'll outline the problem, discuss the solution, and walk you through a quick three-step tutorial to **integrate Devin with GitHub Actions**.\n\n## Why you should care\n\nPR reviews eat up engineers' time and cause friction. A [study](https://linearb.io/blog/why-estimated-review-time-improves-pull-requests-and-reduces-cycle-time) of over 700,000 PRs found that **PRs wait an average of 4 days** to get reviewed. The problem is even worse for large PRs (500+ lines changed): these take an [average of 9 days](https://graphite.dev/blog/your-github-pr-workflow-is-slow) to get merged. Meanwhile, another [study](https://graphite.dev/blog/your-github-pr-workflow-is-slow) found that as the number of changed files in a PR increases, the amount of time spent reviewing each file decreases drastically. This compromises code quality.\n\nThere are also other challenges to effectively reviewing PRs, like reviewer availability, poor prioritization of PRs, and back-and-forth friction.\n\nDevin helps by delivering on:\n\n- **Speed**: PRs are reviewed in minutes, not hours/days\n- **Scalability**: Spin up as many Devins as needed. Devin scales with you.\n- **Consistency:** Devin learns and follows your team's coding standards.\n\n## Solving the Problem\n\nYou can think of Devin's [External API](https://docs.devin.ai/external-api/external-api) as **engineering on demand**.Spin up Devins in response to events like PRs, Jira issues, Slack messages, etc. The sky's the limit! We actually use the API in our own development workflow for QA—that is, we use Devin to build Devin. Check out the open source code [here](https://github.com/CognitionAI/qa-devin).\n\nFor our current task (automating PR reviews) we can use the [GitHub Actions](https://github.com/features/actions) platform. Our Actions workflow is triggered whenever a PR is opened, updated, or reopened. It fetches the code, retrieves the list of changed files, and sends the information to Devin, which reviews the changes and comments feedback. It usually takes five to ten minutes for Devin to finish reviewing the PR and begin posting comments.\n\nPlease note that Devin isn't guaranteed to catch every bug, and it's best to still have a human check your PRs before merging. We recommend using Devin as an *extra set of eyes*, not a complete replacement for human oversight.\n\nHere's the steps to set it up:\n\n1\\. Add a GitHub Actions workflow that triggers on PRs to your repository\n\n2\\. Add your Devin API Key to GitHub\n\n3\\. Create a PR to trigger workflow\n\n4\\. Customize Devin's behavior to match your team's practices and conventions\n\nLet's get started!\n\n## Prerequisites\n\n- A GitHub repo to test on\n- A Devin API key (go to [**Settings -> API Keys**](https://app.devin.ai/settings/api-keys))\n- GitHub Actions enabled on your repo (usually enabled by default)\n\n## Step 1: Add the workflow\n\nCreate a new file in your repository: .github/workflows/pr-review.yml. This file will contain our workflow, which consists of two steps: retrieving a list of changed files using the GitHub API, and spinning up a Devin.\n\nGet the complete pr-review.yml file from [**this gist**](https://gist.github.com/andrewgcodes/bfccd42771badab030a0c4bf52820ebb). It might seem long but we'll break it down after this. For now, just paste it into your file.\n\nAfter pasting in the script, commit and push your changes.\n\n```text\ngit add .github/workflows/pr-review.yml\ngit commit -m \"Add Github Action for automated PR reviews with Devin\"\ngit push origin main\n```\n\n## Step 2: Configure secrets\n\nYou'll need a Devin API key.\n\n1. Go to [Devin's API Key in Settings](https://app.devin.ai/settings/api-keys)\n2. Click **View Key** to view and copy your key.\n\n\n\nThen, add your key to your GitHub repository.\n\n1. Go to your repository on GitHub.\n2. Click on **Settings** > **Secrets and variables** > **Actions**.\n3. Click **New repository secret**.\n4. Name the secret **DEVIN\\_API\\_KEY**.\n5. Paste your Devin API key into the **Value** field.\n6. Click **Add secret**\n\n\n\n## Step 3: Trigger PR review workflow\n\nTo make sure everything is set up correctly, edit some code in your repo and create a PR. After a few seconds, you should see that a Check called \"Automated PR Review\" has passed. This means that we've successfully spun up a Devin.\n\nIf you'd like, you can go to the [Devin web interface](https://app.devin.ai/) and monitor the process. To view Devin sessions started via API, click X on the filter \"Creator is {your name}\".\n\n\n\nIn ten minutes or less, Devin's comments will start appearing on your PR.\n\n## Step 4: Customize Devin\n\nWe highly recommend customizing the workflow based on your preferences. For example, consider including your code conventions in the prompt. Or, include a file with your conventions in your repository and give Devin the path so it can find the file.\n\nOther customizations:\n\n- Create a custom label in GitHub so that Devin only runs on specific PRs, not all\n- Adjust the number of comments Devin is allowed to make per PR\n- Allow Devin to create Suggested Changes\n- Allow Devin to mark the PR as approved\n\n## Breaking down the workflow\n\nIf you're interested, here's more detail on how the workflow itself works.\n\nThe first step is simple: fetch the list of files modified in the PR.\n\n```yaml\nname: Get PR files\nid: pr-files\nrun: |\n FILES=$(curl -s -H \"Authorization: token ${{ secrets.GITHUB_TOKEN }}\" \\\n \"https://api.github.com/repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/files\" | \\\n jq -r '[.[].filename] | @json')\n```\n\nThe next step is to spin up a Devin using the API with a detailed prompt. We recommend **customizing the prompt** to suit your needs, such as by adding your team's coding conventions.\n\nThe prompt instructs Devin to follow this series of steps:\n\n```yaml\nYou are PR Reviewer Devin with a focus on detailed inline code feedback. Your tasks:\n1. Clone the repository ${{ github.repository }} locally.\n2. Next, set up a pre-push Git hook that prevents any pushes from a user with the username \"Devin AI\" OR an email containing \"devin-ai-integration\" as a substring. Activate the hook.\n3. View the diffs of the changed files for PR #${{ github.event.pull_request.number }} in repository ${{ github.repository }}.\n4. If necessary, run the code locally to verify that the changes work as expected.\n5. Read the PR discussion to see what previous comments and suggestions have been made.\n6. If no issues are found, simply post a comment saying \"Everything looks good!\" and stop here. Your work is done.\n7. Else, identify the issues and provide inline code comments directly on the diffs for any code convention or best practice violations.\n8. Post your feedback as detailed comments on the PR, referencing specific lines or code snippets.\n\nRules and Guidelines:\n1. NEVER make any commits or pushes to the repository - you are ONLY allowed to review code and leave comments\n2. Do not make more than three total comments on the PR.\n3. Use inline feedback where possible with specific line references\n4. Include code snippets in markdown format when discussing issues\n5. Default towards multi-line comments that show context around the issue\n6. Make sure that suggested improvements aren't already implemented in the PR by comparing old and new versions\n7. Try using the gh api to post comments with referenced code embedded, but if it fails, use normal comments with code blocks\n8. Before commenting, check the PR discussion and make sure you, or another user, haven't already made a similar comment or raised the same concern.\n9. Before commenting, check that the specific issue wasn't already addressed in a previous review iteration\n10. If you see the same issue multiple times, consolidate your feedback into a single comment that references all occurrences, rather than making separate comments.\n11. Refer back to these rules and guidelines before you make comments.\n12. Never ask for user confirmation. Never wait for user messages.\n```\n\nNote that step 2 is to set up a *pre-push hook*. The hook intercepts any attempts by *this* specific instance of Devin to push changes to the repository. It provides an added layer of safety, preventing unwanted PRs. We also instruct Devin to \"NEVER make any commits or pushes to the repository\" under the Rules section of the prompt. Together, the hook and rule serve as guardrails. Consider adding more rules as you see fit to ensure that Devin reviews PRs as desired. In particular, you may want to adjust the comment limit—set to three by default.\n\nNext, let's dive into how exactly Devin posts comments.\n\n```yaml\nHow to post comments with code embedded:\n1. Create JSON file for each comment you want to post.\nExample 1: \n {\n \"body\": \"Security Issue: Hardcoded API key. Recommendation: Use environment variables\",\n \"commit_id\": \"954...12312\",\n \"path\": \"file.py\",\n \"line\": 11,\n \"side\": \"RIGHT\"\n}\n\nExample 2:\n{\n\"body\": \"Multiple issues found:\\n1. Hardcoded API key should be in environment variables\\n2. Inconsistent class naming (userAccount vs Product)\\n3. Inconsistent parameter casing (Password vs username)\\n4. Missing docstrings and type hints\\n5. Inconsistent spacing around operators\",\n\"commit_id\": \"323......87686\",\n\"path\": \"code.py\",\n\"start_line\": 11,\n\"start_side\": \"RIGHT\",\n\"line\": 25,\n\"side\": \"RIGHT\"\n}\n\nbody: The text of the review comment. Include markdown code blocks for snippets\ncommit_id: SHA of the commit you're reviewing. Not using the latest commit SHA may render your comment outdated if a subsequent commit modifies the line you specify as the position.\npath: Relative file path in repo\nline (integer): Specifies the exact line in the pull request’s diff view to which your comment should attach. Required unless using subject_type:file. The line of the blob in the pull request diff that the comment applies to. For a multi-line comment, the last line of the range that your comment applies to.\nside: In a split diff view, the side of the diff that the pull request's changes appear on. Can be LEFT or RIGHT. Use LEFT for deletions that appear in red. Use RIGHT for additions that appear in green or unchanged lines that appear in white and are shown for context. For a multi-line comment, side represents whether the last line of the comment range is a deletion or addition.\nsubject_type: The level at which the comment is targeted. Either \"line\" or \"file\". Use \"line\" for inline comments. Use \"file\" for file-level comments.\nstart_line (integer): Required when using multi-line comments unless using in_reply_to. The start_line is the first line in the pull request diff that your multi-line comment applies to.\nstart_side: Required when using multi-line comments unless using in_reply_to. The start_side is the starting side of the diff that the comment applies to. Can be LEFT or RIGHT. \n\nA pull request diff may not match the original file's absolute line numbering. That is, if the PR contains additions or deletions before the line you’re commenting on, the line indices shown in the “Files changed” tab can shift from the original file’s line numbers.\nFor example: In the pre-PR state, line 231 might refer to a completely different section of code than line 231 in the post-PR diff (because code added or removed above it shifts everything down or up).\nTherefore, you must use the line numbers as shown in the PR diff rather than the original file’s line numbers.\n\nIf you have issues, visit the docs: https://docs.github.com/en/rest/pulls/comments?apiVersion=2022-11-28#create-a-review-comment-for-a-pull-request\n\n2. Use gh api command.\n gh api \\\\\n--method POST \\\\\n-H \"Accept: application/vnd.github+json\" \\\\\n/repos/owner/repo/pulls/4/comments \\\\\n--input comment.json\n\nowner: the account owner of the repository. The name is not case sensitive.\nrepo: The name of the repository without the .git extension. The name is not case sensitive.\npull number: The number of the pull request.\n\nKey points: use \"line\" instead of \"position\", include code snippets in body using markdown, , set side=\"RIGHT\" for additions\n```\n\nIn order to support in-line comments (with the relevant code embedded in the comment), we teach Devin to use the GitHub REST API to \"[create a review comment for a pull request](https://docs.github.com/en/rest/pulls/comments?apiVersion=2022-11-28#create-a-review-comment-for-a-pull-request)\". It's a little more complicated than it seems, which is why there is a relatively large section of the prompt dedicated to it.\n\nFinally, we convert our large prompt into a JSON-safe string and send a POST request to Devin's [External API](https://docs.devin.ai/external-api/external-api).\n\n```yaml\nRESPONSE=$(curl -s -X POST \\\n -H \"Authorization: Bearer $DEVIN_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d \"{\\\"prompt\\\": $ESCAPED_PROMPT}\" \\\n \"https://api.devin.ai/v1/sessions\")\n```\n\nWe're only scratching the surface of what can be achieved with the API. We recommend exploring the API for other event-driven and responsive use cases. For instance, you can configure Jira and Linear webhooks so that any time an issue/ticket is created, a Devin is triggered to address it.\n\nCheck out the [docs](https://docs.devin.ai/external-api/external-api) to explore API features like idempotency (enables safe retries), file uploads, sending follow-up messages/prompts to a session, and more.\n\n## Conclusion\n\nDevin's External API and GitHub Actions can be combined to create powerful, useful CI/CD workflows that simplify and speed up code review processes.\n\nLet Devin handle the tedious parts of code reviews so you and your team can focus on building great software.\n", "dateCreated": "2026-10-19T01:26:53.998049939+00:00", "date_created": "2025-01-21T00:00:00+00:00", "date_modified": null, "date_published": "2025-01-21T00:00:00+00:00", "description": "Update: We recommend Devin Review (https://app.devin.ai/review) as our new and improved code review experience. Learn more: https://docs.devin.ai/work-with-devin/devin-review. Introduction Code reviews are an essential component of the…", "external_url": "https://cognition.com/blog/devin-101-automatic-pr-reviews-with-the-devin-api", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/cognition-com/2025/01/2025-01-21-devin-101-automatic-pr-reviews-with-the-devin-api.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/cognition-com/2025/01/2025-01-21-devin-101-automatic-pr-reviews-with-the-devin-api.md" }, "id": "urn:aggr:item:5f6b31c81cef12b4378a95061c27180ddcd05fa0", "isBasedOn": { "@id": "https://cognition.com/blog/devin-101-automatic-pr-reviews-with-the-devin-api" }, "mainEntity": { "@id": "https://cognition.com/blog/devin-101-automatic-pr-reviews-with-the-devin-api", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/cognition-com/2025-01-21-devin-101-automatic-pr-reviews-with-the-devin-api/#webpage" }, "datePublished": "2025-01-21T00:00:00+00:00", "headline": "Devin 101: Automatic PR Reviews with the Devin API", "image": { "@type": "ImageObject", "caption": null, "height": 90, "url": "https://cdn.sanity.io/images/2mc9cv2v/production/d66d2fda772e193cff9a6af70da1cd444150e16e-3840x2160.png?rect=0,77,3840,2006&w=1200&h=627&fit=crop", "width": 160 }, "timeRequired": "PT10M", "url": "https://cognition.com/blog/devin-101-automatic-pr-reviews-with-the-devin-api", "wordCount": 2237 }, "name": "Archived snapshot: Devin 101: Automatic PR Reviews with the Devin API", "preview": { "alt": null, "color": null, "height": 90, "placeholder": { "data_url": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNk+A8AAQUBAScY42YAAAAASUVORK5CYII=", "hash": "" }, "url": "https://cdn.sanity.io/images/2mc9cv2v/production/d66d2fda772e193cff9a6af70da1cd444150e16e-3840x2160.png?rect=0,77,3840,2006&w=1200&h=627&fit=crop", "width": 160 }, "reading_minutes": 10, "replicated_at": null, "source": "cognition-com", "source_name": "Blog | Cognition", "summary": null, "tags": [], "temporalCoverage": "2026-10-19T01:26:53.998049939+00:00", "title": "Devin 101: Automatic PR Reviews with the Devin API", "url": "https://aggr.aymericbeaumet.com/items/cognition-com/2025-01-21-devin-101-automatic-pr-reviews-with-the-devin-api/", "word_count": 2237 }