DEV Community: Jay Elsheikh

Comet and Atlas: why the AI browser bet is failing

Jay Elsheikh — Mon, 05 Oct 2026 08:00:00 +0000

For about a year, the serious product bet in consumer AI was a new browser. Chat was a window you pasted into. A browser was the place the work already lived: the tab, the login, the form, the receipt. If the model could see that page and act on it, the address bar would replace the chat box.

Perplexity shipped Comet in July 2025, first on the Max plan, then free worldwide on 2 October 2025. OpenAI shipped ChatGPT Atlas on 21 October 2025, macOS only. The Browser Company's Dia sat in the same conversation. Three products, one sentence: stop copying the page into a chatbot.

That sentence was right about the problem. It was early about the container.

Why a browser felt like the product

Search and chat had split the job badly. You asked a question, got an answer, then opened six tabs to check it. An AI browser promised to collapse that loop. Type the task. The browser searches, opens the pages, summarizes them in place, and, when you allow it, clicks through.

Comet's pitch was research with an agent beside the page. Summaries sat on the article. Agent mode could run a multi-step task. Atlas's pitch was action. OpenAI described a browser that could complete work across sites you were already signed into, with ChatGPT as the sidebar that could take the wheel.

The category had a clean story for investors and for users tired of tab hoarding:

The page is the context. You should not have to paste it.
The click is the action. You should not have to do the last ten steps yourself.
The session is the memory. Logins, carts, and dashboards are already there.

By early 2026 the usage stories matched the pitch, at least in third-party trackers. Presenc AI put Comet near 18 million monthly active users in Q1 2026, up from about 2.4 million a year earlier, with agent-task completion climbing as the tool-use stack got less fragile. Perplexity has not published that figure itself. The direction was hard to miss: a lot of people tried a browser whose main feature was a model.

HUMAN Security's May 2026 read of agentic web traffic put Comet at 47% of observed agent traffic and Atlas at 20.3%. Together they were most of the category. Media, commerce, and travel were almost the whole destination list. Product and search routes were about three quarters of the activity. Checkout was a sliver. People were browsing with an agent. They were rarely letting it buy.

Atlas was a browser you had to switch to

Atlas launched on the Mac and stayed there. No Windows build, no iOS, no Android. Bookmarks, extensions, and a decade of Chrome muscle memory do not move because a sidebar is clever. OpenAI later said the plain part out loud: getting people to switch browsers was harder than meeting them inside ChatGPT, which they already open.

The product still taught the company something. A browser session is a better workplace than a chat transcript. Multiple tabs, downloads, logins, and a page that stays put are what an agent needs when the task is "finish this," and a single message box is a poor place to keep that state. Atlas was the prototype of that workplace. It was also a second app to install, patch, and explain.

Comet had a wider door. It went free, it reached phones, and head-to-head tests through the spring often rated its agent mode quicker than Atlas. The iOS app hit the US App Store top tier within two days of the 18 March 2026 launch. Distribution was the advantage. A Chromium fork is still a browser you have to choose every morning.

The bet had a cost the demo hid

An agent that clicks inside your accounts is a different product from an agent that answers a question. In March 2026 a federal court injunction blocked Comet's agents from Amazon's signed-in account pages. The fight was about authenticated sessions, and it spread. Site owners started treating "a browser with a model in it" as a bot with a screen, and blocking rates on agent traffic climbed through the spring even while the two AI browsers still led the category.

There is a second cost, and it sits on the vendor's bill. Driving a real page, with screenshots, tool calls, and retries, is expensive at millions of users. A sidebar summary is cheap enough to bundle. "Control the browser and finish the task" is a metered computer. Comet could grow on the first. The second had to be priced like compute.

That is the rise, stated cleanly. The AI browser won the argument about context. The page should be in the prompt. It lost the argument about distribution. Chrome was already open. ChatGPT, Claude, and Grok were already installed. A third app that was also a browser had to be better than both, every day, for a person who did not want a new default.

What the year actually proved

The useful idea survived the apps. You can see it in what shipped next: OpenClaw, Hermes, Grok Bot, Claude Desktop, and the ChatGPT desktop app, each with a browser the agent drives and, in several of them, computer use that clicks the desktop itself. Google's version of the smaller idea, Ask Gemini on the current Chrome tab, is the third piece in this series.

Curious to hear your thoughts ,Will AI browsers survive or Open Agents like GrokBot is actually the future?

Why full repo context matters for code review

Jay Elsheikh — Thu, 24 Sep 2026 07:21:57 +0000

Why full repo context matters for code review

Most "AI review" tools only see the diff you send them. That's a problem because a patch rarely stands alone — a renamed helper, a config file, a sibling module — the rest of the codebase usually decides whether the change is correct. A reviewer that only sees the patch ends up flagging things that are already handled elsewhere, and missing things that depend on context outside the diff.

The latest Cloud release, ThinkReview Cloud 2.4.0, is built around that gap. The headline change is how you grant Cloud access to your repositories, and what it can do once it has access.

GitHub App and GitLab.com OAuth for repo-wide reads

Previously, connecting a repo for full repository context required generating a personal access token and pasting it into ThinkReview. That works, but it's friction, and it's a token that has to be scoped, stored, and rotated.

Cloud 2.4.0 adds two first-party auth paths:

GitHub App install — Click Connect on Integrations, pick the account or repos you want to grant access to, and the App handles the rest. No PAT to manage.
GitLab.com OAuth — Same flow for GitLab.com repositories. Authorize once, Cloud can read the project, not just the diff.

PATs are still supported for self-hosted GitHub Enterprise, self-hosted GitLab, Bitbucket, Azure DevOps, or any case where installing the App isn't an option.

Reviews that look past the diff

With repo-wide read access, the first review on a PR can now look through the real project:

Surrounding files in the same module
How the changed function or class is used by callers
Whether a flagged issue is already mitigated elsewhere in the codebase

The practical effect: fewer "the patch looks wrong" comments that ignore the rest of the repo, and fewer false positives that you'd otherwise have to defend in a reply.

Conflicting and overlapping PRs

A second consequence of repo-wide context is cross-PR awareness. Cloud reviews can now check other open pull requests / merge requests that touch the same files. If two in-flight changes are likely to collide — same function, same config, same generated file — the review can flag that instead of treating your PR as if it were the only one in flight.

This is most useful on long-lived branches and busy repos where merge order matters.

What you need

A ThinkReview account with an active plan or available review credits
A connection via Connect with GitHub or Connect with GitLab (recommended), or a PAT for self-hosted hosts, under Integrations
The ThinkReview extension, MCP, or an API client calling the hosted review endpoints

Where to go

Integrations: portal.thinkreview.dev/integrations
Full release notes: thinkreview.dev/release-notes/cloud-v2.4.0
Feedback: thinkreview.dev/feedback
Bug reports: the "Report a Bug" button in the extension review panel

If your team has been holding off on giving an AI reviewer broader repo access because of the PAT step, this release is the path of least resistance.

AI code reviews for pull requests the right way - Gitlab GitHub Azure & Bitbucket

Jay Elsheikh — Sun, 20 Sep 2026 09:15:06 +0000

Most AI code review tools either dump every finding as a bot comment or leave you with a long blob to paste yourself. Neither feels right on a real pull request. The first floods the conversation thread with noise the team has to skim past. The second turns every finding into a small copy-paste chore.

ThinkReview has always lived on the PR page as a copilot: severity-ranked findings, file ranges, follow-ups, and copy you can paste. The last mile was still copy-paste. That is the part this release removes.

One click from finding to conversation

Each finding in the review panel now has a Post control. Click it, and that specific finding is published as a conversation comment on the same pull request or merge request you are looking at. No second tab. No hand-formatting markdown.

The comment is the finding you already read in the panel: title, file path, line range, and the explanation. It shows up in the conversation thread — the same place teammates already watch for review notes — not as an auto-spam from a bot that reviewed every commit overnight.

That is the useful split:

Inline review comments still belong to the human review you write on the diff.
Conversation comments are the place to share a finding the whole thread should see.
ThinkReview Post writes the second kind, on demand, from the finding you selected.

While it posts, the panel shows a short toast with a spinner. The PR page stays usable. If the host rejects the comment — missing write access, expired token, wrong scope — you get that error instead of a silent failure.

Where it works

Post uses your Full Context integration — the same credentials ThinkReview already uses to read the repo — and is available on:

GitHub (GitHub App or personal access token)
GitLab (OAuth or personal access token, including self-managed with a custom domain)
Azure DevOps (personal access token)

On GitHub App, the comment is attributed to ThinkReview. On GitLab OAuth / PAT and Azure PAT, it is attributed to you, because those hosts post as the authenticated user.

Bitbucket reviews still run in the panel. Posting from the finding is GitHub, GitLab, and Azure for this release.

Setup you actually need

You already have a working review if Full Context can fetch the diff. Posting is a write. That is the extra check:

GitHub App: the installation needs permission to write issues/comments on the repo. If reviews work but Post returns a permissions error, update the App install and try again.
GitHub PAT: the token needs comment write on that repository.
GitLab OAuth: posting notes requires the api scope (GitLab does not offer a narrower "notes only" write scope). If you connected GitLab before this change, reconnect OAuth so the new scope is granted.
GitLab / Azure PAT: the token needs permission to comment on the MR or PR.

If Post opens the setup hint instead of sending, finish Full Context for that host first — GitHub App, GitLab OAuth, or a PAT — then click Post again.

How to use it in a real review

Open the PR or MR in the browser and run AI Review as usual.
Read the finding in the panel. Edit nothing you would not want on the thread — the body is the finding text.
Click Post on that item.
Confirm the comment on the conversation tab. Refresh if the host is slow to render.

Post one finding, or several. Skip the noisy ones. That is the point: the model ranked the issues; you still choose what the team sees.

Same panel, one new control

Install or update ThinkReview from the Chrome Web Store, Microsoft Edge Add-ons, or Firefox Add-ons. Same credits, same models, same panel. The new control is only the last step from finding to thread.

ThinkReview remains a copilot. The next post is about why one click is not the same as a comment bot — and why we still wait for you to press Post.

GitLab Self-Hosted MR ThinkReview: Finally, A Simple Solution

Jay Elsheikh — Sat, 29 Aug 2026 20:00:07 +0000

If you work on self-hosted GitLab, you've probably spent years watching AI code review happen on gitlab.com while your merge requests on gitlab.mycompany.com stay strictly on Overview, Changes, and a static comment box.

Most tools that promise to close that gap come with a heavy tax: GitLab Premium or Ultimate seats, inbound webhooks, dedicated service accounts, and external dashboards that live entirely outside the merge request you are actually reviewing.

We kept asking: Why isn't there a simple GitLab self-hosted AI code review that just works on the MR — on both Community Edition and Enterprise Edition?

So we built ThinkReview.

The Problem with Self-Hosted GitLab AI

If you live on GitLab Community Edition (CE), there is no GitLab Duo. If you live on GitLab Enterprise Edition (EE) without Premium/Ultimate — or on an air-gapped instance — Duo still requires an AI gateway, version pins, and administrative sign-off.

A self-hosted merge request AI review shouldn't mean:

Upgrading CE to EE Ultimate just to turn AI on
Standing up GitLab Duo Self-Hosted and complex AI gateways
Exposing your private instance so an external vendor can POST bot comments
Copying giant diffs into ChatGPT and losing the context of your Changes tab

A Simple Solution for CE and EE

ThinkReview takes the opposite path: install the extension, add your custom GitLab domain, open the MR, and click AI Review.

No GitLab admin project. No bot accounts. No second browser tab. The review lives right in your browser on your custom domain, supporting:

GitLab.com
GitLab Community Edition (CE)
GitLab Enterprise Edition (EE) — whether you have Duo or not

A custom domain is the only setup requirement so the extension can safely run on gitlab.company.com.

What You Get in the Review Panel

ThinkReview acts as an intelligent copilot right inside your merge request sidebar:

Summary of what the code change actually does
Severity-ranked findings (critical / high / medium) with direct file and line ranges
Quality, security, and best-practice scores on demand
Review agents (like security or pentest checklists) running on the same MR
Suggested follow-up questions to dive deeper into chat, plus copy-ready comment generation
Code suggestions that you copy and post yourself — keeping you in full control
Cursor / Claude Code / Copilot deeplinks to jump straight into your IDE to fix findings

Review Self-Hosted MRs Directly from MCP

If you prefer working inside your editor, ThinkReview MCP brings the exact same capability to your favorite AI assistant.

Full instructions : https://thinkreview.dev/blog/2026-08-11-thinkreview-mcp-oauth-claude-code-setup

Simply paste a GitLab merge request URL—whether gitlab.com or your self-hosted CE/EE instance—into Cursor, Claude Code, Claude Desktop, or GitHub Copilot and call review_url_code. ThinkReview fetches the diff securely through your portal git credentials and returns a structured review containing summaries, findings, security notes, and follow-up questions.

Hosted endpoint: https://mcp.thinkreview.dev/v1

Listed on the Official MCP Registry as io.github.Thinkode/thinkreview.

Getting Started in Minutes

On the GitLab Self-Hosted MR page:

Install ThinkReview on Chrome, Edge, or Firefox.
Open the extension popup and choose GitLab Self-Managed.

Add your instance domain (e.g., gitlab.mycompany.com) and grant permissions.
Open any merge request on Community Edition or Enterprise Edition and click ThinkReview.

From Cursor or Claude Code:

Connect your git credentials in the ThinkReview portal.
Add ThinkReview MCP and authenticate.
Ask your assistant: "Review this GitLab MR with ThinkReview: https://gitlab.mycompany.com/..."

There is a free tier with daily review credits so you can test out a real GitLab community edition code review right now. Discover more at thinkreview.dev.

Why Google shipped three Gemini Flash models in 12 weeks

Jay Elsheikh — Wed, 19 Aug 2026 13:36:08 +0000

Google introduced Gemini 3.7 Flash just 23 days after 3.6 Flash, and 86 days after 3.5 Flash debuted at I/O. That is three workhorse Flash models in less than three months. While 3.5 Pro never arrived, Flash had to step up.

Three Flashes, three distinct jobs

3.5 Flash (May 19): The I/O statement. Frontier intelligence with action, outperforming older Pro models at high speeds across platforms.
3.6 Flash (July 21): The unit-economics patch. Optimized for tokens, latency, and tool-call waste, reducing output prices.
3.7 Flash (August 13): The completion-rate patch. Focused on algorithmic improvements to reasoning foundations, helping agents better adapt to roadblocks and multi-step planning.

The gains are where coding agents actually die

Google's 3.7 updates concentrate heavily on software engineering and multi-step workflows. We saw massive jumps in benchmarks like DeepSWE v1.1 (+16.3 pts) and FrontierCode 1.1 Main (+9.2 pts).

The expensive part of coding isn't the first-pass code that almost compiles—it's the fifth tool call that undoes the third, or the ambiguous instruction the model guessed instead of clarifying. Pull request review lives in this exact failure mode.

What this means for code review

Three Flash models in 12 weeks changes how we should approach AI-generated code review:

Expect the workhorse to move: Your review stack should switch models as fast as Google ships them.
Prefer models that finish the job: Look for long-horizon engineering capabilities over chat fluency.
Watch retries, not list price: The cheaper review is the one that doesn't need a second pass to fix a hallucinated finding.
Keep a human on the loop: Pair models with repository-level context when the real bug lives outside the diff hunk.

That is the job ThinkReview is built for: an AI code review copilot on GitHub, GitLab, Azure DevOps, and Bitbucket that goes beyond rubber-stamping PRs. Google just showed it can revise a production coding model three times in a summer. Your review workflow should keep up.

Pick your model in Model selection, run it on a real diff, and keep your engineering judgment.

How I listed my MCP on the official MCP Registery and how you can do yours too ?

Jay Elsheikh — Mon, 10 Aug 2026 11:25:49 +0000

When people ask “where do I find MCP servers?”, a growing chunk of the answer starts in one place: the Official MCP Registry at registry.modelcontextprotocol.io.

I recently listed ThinkReview MCP there — our hosted server that runs AI code reviews on GitHub, GitLab, Azure DevOps, and Bitbucket PR/MR URLs from Cursor, Claude, and Copilot.

Here’s exactly what I did, and how you can do the same.

First, what the registry actually is

The Official MCP Registry stores metadata, not your binaries.

That means:

You don’t upload a zip of your server
You publish a server.json that describes your MCP
Clients and other directories can discover you from that record

There are two common shapes:

Package-based — your server lives on npm / PyPI / NuGet / Docker, and the registry points at that package
Remote / hosted — your server is a public URL (Streamable HTTP), and the registry points at that endpoint

ThinkReview is remote. Our endpoint is:

https://mcp.thinkreview.dev/v1

So I didn’t need to publish an npm package just to get listed. I only needed a solid public docs repo + a valid server.json.

Docs that mattered:

The registry is still in preview. Expect possible breaking changes before GA.

Step 1 — Put something public on GitHub

Directories and developers want a repo they can open.

I created a public visibility/docs repo:

github.com/Thinkode/thinkreview-mcp

It includes:

What the MCP does
Endpoint + transport
OAuth and Bearer setup for Cursor / Claude / Copilot
Example configs

It does not include our private review engine, auth, or billing backend. For a SaaS MCP, that’s the right split:

Public: docs + configs + registry metadata
Private: the actual product

If you’re building an open-source local MCP, your full source can live in that same repo.

Step 2 — Install the publisher CLI

brew install mcp-publisher
mcp-publisher --help

Or grab a binary from the registry releases.

You’ll use three commands most of the time:

mcp-publisher init
mcp-publisher login ...
mcp-publisher publish

Step 3 — Choose your namespace (this is the gotcha)

Your server name is tied to how you authenticate.

Auth method	Name format	Example
GitHub login	`io.github.<user-or-org>/...`	`io.github.Thinkode/thinkreview`
Domain proof (DNS/HTTP)	reverse-DNS of your domain	branded names under your company domain

I used the GitHub org namespace because it’s the fastest path:

io.github.Thinkode/thinkreview

Note: the registry name (thinkreview) and the GitHub repo name (thinkreview-mcp) do not have to match. Pick a clean registry name; point repository.url at whatever public repo you use for docs or source.

Later, you can move to a branded domain namespace if you want cleaner naming — that needs DNS TXT or a /.well-known/mcp-registry-auth proof on your domain.

Step 4 — Create `server.json` for a remote MCP

In the repo:

cd thinkreview-mcp
mcp-publisher init

Then edit the file for a hosted server. Skip packages unless you also ship a local install. Use remotes instead:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.Thinkode/thinkreview",
  "title": "ThinkReview",
  "description": "Live PR/MR code reviews via review_url_code. OAuth or portal Bearer auth.",
  "version": "1.3.0",
  "websiteUrl": "https://thinkreview.dev/features/mcp",
  "repository": {
    "url": "https://github.com/Thinkode/thinkreview-mcp",
    "source": "github"
  },
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://mcp.thinkreview.dev/v1"
    }
  ]
}

A few rules that saved me time:

Prefer "type": "streamable-http" (SSE is deprecated)
The URL must be publicly reachable
version is required, unique per publish, and immutable once published — use semver
name must match your auth namespace (io.github.Thinkode/... if you logged in as that org)

Commit server.json so the listing is reproducible.

Step 5 — Authenticate

For the GitHub namespace path:

mcp-publisher login github

You’ll get a device code, authorize it in the browser, and the CLI confirms you’re logged in.

That login only lets you publish under io.github.<that-account-or-org>/....

Step 6 — Publish

mcp-publisher publish

When it works, you’ll see something like:

Publishing to https://registry.modelcontextprotocol.io...
✓ Successfully published
✓ Server io.github.Thinkode/thinkreview version 1.3.0

That’s it. Your MCP is now in the official upstream registry.

Step 7 — Verify

Search by a short token that matches your listing:

curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=thinkreview"

Or use the exact registry name:

curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.Thinkode/thinkreview"

You should see metadata like:

name: io.github.Thinkode/thinkreview
version: 1.3.0
status: active
remote: https://mcp.thinkreview.dev/v1
repository: https://github.com/Thinkode/thinkreview-mcp

From there, community directories (PulseMCP, Glama, mcp.so, mcpservers.org, etc.) often pick listings up over time — but the official registry is the upstream source you want first.

How to keep it updated

Every meaningful MCP release:

Bump version in server.json
Commit
Run mcp-publisher publish again

Or automate it in GitHub Actions with mcp-publisher login github-oidc on version tags so every release republishes metadata.

If something fails

Error	What it usually means
No permission to publish this server	Your `name` doesn’t match your GitHub/domain auth
Invalid or expired JWT	Re-run `mcp-publisher login github`
Registry validation failed	Package listings need ownership proof (`mcpName`, etc.). Remote listings need a live public URL
Version already exists	Bump semver — published versions can’t be overwritten
Search returns empty	You’re searching the wrong string (e.g. repo name vs registry `name`)

The short version

Make a public repo (docs + examples is enough for remote MCP)
Install mcp-publisher
Add a server.json with remotes pointing at your hosted URL
mcp-publisher login github
mcp-publisher publish
Verify with the registry API

That’s how ThinkReview MCP got onto the official MCP Registry — and the same path works whether you’re shipping a local open-source server or a hosted product like ours.

If you’re listing a remote MCP too, start with the GitHub namespace, get discoverable fast, then brand the namespace later once DNS/domain proof is worth the extra step.

ThinkReview MCP: run live PR code reviews from Cursor, Claude Code, and Copilot

Jay Elsheikh — Fri, 07 Aug 2026 10:52:48 +0000

You already use Cursor, Claude Code, or GitHub Copilot to write and refactor code. What if the same assistant could run a real ThinkReview analysis on a pull request—without you copying diffs into chat?

Today we are introducing ThinkReview MCP: a hosted Model Context Protocol server at mcp.thinkreview.dev/v1. Connect it once, then ask your assistant to review any PR or merge request URL on GitHub, GitLab, Azure DevOps, or Bitbucket. ThinkReview fetches the changed files, runs the review, and returns structured feedback: summary, suggestions, security notes, best practices, and suggested follow-up questions.

Why MCP for code review?

Browser extensions are great when you are already on a PR page. MCP is for the moments when you are in the editor or terminal and want review context without context-switching.

Typical flow:

You are pairing with an AI agent on a fix or feature branch.
A teammate shares a PR link in Slack or a ticket.
You ask: “Call review_url_code for https://github.com/org/repo/pull/42.”
ThinkReview returns the same quality of review you would get from the extension—grounded in the actual diff, not a guess from partial snippets.

One tool, one URL, no patch upload. That is the whole idea.

What you need before connecting

ThinkReview MCP is designed to be quick to set up, but two things must be in place:

1. Your ThinkReview Bearer token

Generate or copy your personal token from the MCP integration page in the ThinkReview portal. It is the same authorization token used by the ThinkReview browser extension. Add it to your MCP client as:

Authorization: Bearer <your-token>

If you regenerate the token, update every MCP client (and expect the extension to need the new token too).

2. Git credentials in the portal (required)

MCP cannot fetch a PR diff without git access. Before your first review, add a Personal Access Token under Settings → Integrations in the portal.

ThinkReview uses that PAT to call your git host’s API—same as URL-based reviews in the cloud. If integrations are missing, or the token cannot reach a private org repo (for example SSO not authorized on GitHub), reviews will fail with a clear access error instead of a vague API failure.

This step is easy to skip when you are excited to wire up Cursor—but it is the most common reason MCP reviews do not work on the first try.

The `review_url_code` tool

ThinkReview MCP exposes a single tool today:

Tool	What it does
`review_url_code`	Runs a live code review on a PR or MR URL

Required: prUrl — the full pull or merge request link.

Optional: language (response language), mrId (your tracking ID), forceRegenerate (bypass cache when the PR has new commits but you want a fresh review immediately).

Reviews use the same credits as the browser extension. Results are cached per user when the changed-file fingerprint has not changed, so re-asking about the same PR is fast and does not burn credits unnecessarily.

Custom review agents you configure in the portal are not run by default through MCP—the tool returns the main structured review. Agent workflows remain centered in the extension and portal today.

Connect in minutes

The portal MCP setup page includes copy-paste configs for:

Cursor — add thinkreview under mcpServers with the hosted URL and Bearer header
Claude Code — JSON config or a one-line CLI claude mcp add command
GitHub Copilot (VS Code) — .vscode/mcp.json or user MCP config with the servers key

Example for Cursor:

{
  "mcpServers": {
    "thinkreview": {
      "url": "https://mcp.thinkreview.dev/v1",
      "headers": {
        "Authorization": "Bearer <your-token>"
      }
    }
  }
}

Restart your client after saving. Then try a prompt like: “Review this PR with ThinkReview: https://github.com/org/repo/pull/123.”

Full setup details, security notes, and troubleshooting live in our docs: MCP Integration.

Smarter caching and clearer errors

This release ships alongside improvements to the URL review pipeline MCP uses under the hood:

Commit-aware caching — reviews refresh when the PR’s changed-file list changes, not only when you force regeneration
Actionable git errors — private repo or token issues surface as access-denied guidance (check integrations, org access, GitHub SSO) instead of opaque 404s

Try it today

If you already use ThinkReview in the browser, MCP is the natural next step for AI-native workflows:

Configure git integrations in the portal
Copy your MCP token and client config
Ask your assistant to call review_url_code on your next PR

ThinkReview remains open source for the browser extension. Explore the project and install links on thinkreview.dev.

Extension repository: github.com/Thinkode/thinkreview-browser-extension
Chrome Web Store: ThinkReview — AI copilot for pull requests
Firefox Add-ons: ThinkReview on Firefox

Lookin forward to your feedback , any questions would love to hear

original post :

Code Review bots clutter PRs , anybody feel the same?

Jay Elsheikh — Fri, 24 Jul 2026 01:42:46 +0000

I'd like to get your thoughts if anybody feel the same about code review bots like bugbot , gitlab duo , code rabbit and others that auto post comments on your behalf vs a tool like ThinkReview that shows the review to the reviewer only while the reviewer is still responsible for their final comments

anybody feel the same about how much cluttered the PR gets with these bots ?

Zero setup code reviews for gitlab and azure devops

Jay Elsheikh — Tue, 09 Jun 2026 12:31:31 +0000

Jay Elsheikh

Jun 9

Agentic code reviews without setup on Azure devops PRs

2 min read

Agentic code reviews without setup on Azure devops PRs

Jay Elsheikh — Tue, 09 Jun 2026 12:30:55 +0000

Hello peer developers,

I’m sharing a workflow I built over the past few weeks that has made our pull request security reviews more consistent and more actionable.

ThinkReview is a browser extension that works across Git platforms (Gitlab, Github , azure devops and Bitbucket )and runs a custom review checklist based on what your team cares about, such as OWASP guidance and your internal secure coding standards.

Below is a quick look at the end result, then I’ll walk through how I set it up

Example: a pentesting-focused review agent

In this example, I created a review agent focused on pentesting.

Define the agent’s goal and scope (what kinds of issues it should look for).
Provide a reference the agent should follow, such as STRIKE Graph best practices. https://www.strikegraph.com/blog/pen-testing-best-practices

You can create up to 10 review agent

Run the review on a PR and get findings mapped back to the reference.

In the PR shown here, ThinkReview flagged a couple of OWASP-related issues using the reference we provided.

The project is open source on Github : https://github.com/Thinkode/thinkreview-browser-extension

and you can install it from

chrome webstore : https://chromewebstore.google.com/detail/thinkreview-ai-code-revie/bpgkhgbchmlmpjjpmlaiejhnnbkdjdjn

firefox :

https://addons.mozilla.org/en-US/firefox/addon/thinkreview-code-review

Lookin forward to your feedback , any questions would love to hear

How I set up automated AI code reviews on Azure devops (under 60 seconds) with no CI or coding

Jay Elsheikh — Tue, 02 Jun 2026 22:59:52 +0000

I built an open source Browser extension called ThinkReview to work seamlessly with Azure DevOps — a tool that automatically reviews Pull Requests using any LLM, whether cloud-based or on premise (TFS) without leaving your browser

And the best part?

1- Opensource:

https://github.com/Thinkode/thinkreview-browser-extension

2- Works on your browser (Chrome , Edge or Firefox )

3- It works out of the box on dev.azure.com and company.visualstudio.com

4- If you have on premise ADO with custom domain, All you need is to add the custom domain and your PAT in the extension

5- Chat with your Pull Requests

7- All while on the same page of your PR

I focused on the Ease of Setup and to still maintain the human factor rather than a bot that auto post cluttered comments that developers can miss
Setup takes less than 60 seconds without the need for any coding or integration with CI
It doesn’t spam your PR with Bot comments which will clutter your PR
You won’t need to leave your azure PR page or change to a different tool
Supports legacy Azure on premise formely known TFS down to 2016

Try It Out
Install from Chrome Web Store:

👉 ThinkReview: AI Code Reviews for Azure DevOps

Firefox users:

👉 ThinkReview on Firefox

I Built a One-Click Bridge from Azure Devops PRs Code Review Directly to Cursor/Claude Code

Jay Elsheikh — Sat, 18 Apr 2026 00:36:54 +0000

Hi Everyone ,

I’d like to share here a new feature that I implemented in ThinkReview extension workflow which utilises cursor deeplinks with one click to implement critical bugs , best practices or security issues from the code review

ThinkReview is an opensource browser extension that supports Gitlab , Github , Azure Devops and Bitbucket.

In this demo it generates a code review for a Github PR.
I decided to implement one of the best practices it outlined.
I already use cursot , I will click on the cursor button and with one click it will open cursor and implement it

First Go to any PR and select which IDE agent you want to use currently (Cursor , CLaude code and Github copilot are supported but much more to come )

check the code review generated and select one of the points you'd like to implement , here I'm selecting one of the best prctices about moving magic numbers to constants

Once you click the implement via button in my case here I selected cursor , it will open cursor with your prompt ready to be sent

First thing it will check if we are on the correct branch of the PR
otherwise it will stop and ask you to switch to the correct branch manually

here it identified correctly we are not on the correct branch so I'm going to switch to the correct branch manually

Here it implemented the best prctice in the right branch and I was happy to commit and push the code

here I regenerated the review again and I see the best practices scoring has gone up from 90 to 95
Yay

ThinkReview is open source and you can install the extension from Chrome Store and Firefox addons
https://github.com/Thinkode/thinkreview-browser-extension
https://thinkreview.dev

DEV Community: Jay Elsheikh

Comet and Atlas: why the AI browser bet is failing

Why a browser felt like the product

Atlas was a browser you had to switch to

The bet had a cost the demo hid

What the year actually proved

Why full repo context matters for code review

Why full repo context matters for code review

GitHub App and GitLab.com OAuth for repo-wide reads

Reviews that look past the diff

Conflicting and overlapping PRs

What you need

Where to go

AI code reviews for pull requests the right way - Gitlab GitHub Azure & Bitbucket

One click from finding to conversation

Where it works

Setup you actually need

How to use it in a real review

Same panel, one new control

GitLab Self-Hosted MR ThinkReview: Finally, A Simple Solution

The Problem with Self-Hosted GitLab AI

A Simple Solution for CE and EE

What You Get in the Review Panel

Review Self-Hosted MRs Directly from MCP

Getting Started in Minutes

Why Google shipped three Gemini Flash models in 12 weeks

Three Flashes, three distinct jobs

The gains are where coding agents actually die

What this means for code review

How I listed my MCP on the official MCP Registery and how you can do yours too ?

First, what the registry actually is

Step 1 — Put something public on GitHub

Step 2 — Install the publisher CLI

Step 3 — Choose your namespace (this is the gotcha)

Step 4 — Create server.json for a remote MCP

Step 5 — Authenticate

Step 6 — Publish

Step 7 — Verify

How to keep it updated

If something fails

The short version

Links

ThinkReview MCP: run live PR code reviews from Cursor, Claude Code, and Copilot

Why MCP for code review?

What you need before connecting

1. Your ThinkReview Bearer token

2. Git credentials in the portal (required)

The review_url_code tool

Connect in minutes

Smarter caching and clearer errors

Try it today

Code Review bots clutter PRs , anybody feel the same?

Zero setup code reviews for gitlab and azure devops

Agentic code reviews without setup on Azure devops PRs

Agentic code reviews without setup on Azure devops PRs

Example: a pentesting-focused review agent

How I set up automated AI code reviews on Azure devops (under 60 seconds) with no CI or coding

I Built a One-Click Bridge from Azure Devops PRs Code Review Directly to Cursor/Claude Code

Step 4 — Create `server.json` for a remote MCP

The `review_url_code` tool