Connect a Repo, Get Your First PR Review in Minutes

On Friday afternoon a pull request bumps an EKS node group's minimum size from 3 to 6. Two reviewers approve it: the HCL is valid, the plan is clean, the reasoning in the description makes sense. Three weeks later a cost anomaly lands in someone's inbox, and it takes an afternoon of scrolling CI dashboards and Slack history to trace it back to that merge. Nobody did anything wrong. The review checked whether the change was correct. Nothing checked what it would cost, or remembered that it shipped.

This is part three of our Connection Value series. The opener laid out the ladder: what a single connection gives you in the first five minutes, the first week and every month after. Part two covered cloud accounts: connect one, get dollar findings before your coffee cools. This part covers the connection most teams don't expect from an operations platform: your code repository.

The first result is easy to verify. Connect GitHub or GitLab, and with zero configuration, CloudThinker Review checks your most recent open pull request. A few minutes later there's a review comment on the PR (bugs, vulnerabilities, best-practice issues) waiting where your team already works. No rules to write, no config file to commit, no onboarding call between you and the first result.

The review is the appetizer, though. The reason a repo connection belongs on an operations platform is what happens after: your infrastructure gets a memory of what changed, when, and who owns it. A coding assistant can't give you that, and it's most of this article.

---

Why operations is blind to code

Code and operations already share a lot of data. They rarely share it at the moment it would help, for structural reasons:

Review checks correctness, not consequences. A reviewer reading a Terraform diff sees min_size = 6. They don't see the monthly bill that number implies for your region and instance family, and nobody is going to price it by hand on every PR.

Deploys live in CI, not on the operations timeline. The fact that payments-api shipped at 13:20 is recorded somewhere in a pipeline run. It isn't on the cost graph or the latency dashboard, so correlating the two means opening both and lining up timestamps by eye.

Ownership drifts. Tagging conventions get enforced for a quarter, then services get split, teams get reorganized, and "who owns this container?" becomes an archaeology session.

Code security and cloud security sit in separate queues. A leaked key found in a repo and the over-permissive role it unlocks in AWS are often the same problem. They usually end up in two tools, triaged by two people who never compare notes.

01Code

Repositories

• GitHubOAuth app, repos you pick
• GitLabOAuth app, projects you pick
• What it readsCode, pull requests, deploys, metadata

Read and comment only

02Operations memory

CloudThinker

• ReviewBugs, vulnerabilities, practices
• PriceMonthly delta of IaC changes
• MarkEvery deploy on the timeline
• MapRunning service to repo and owner

Can never merge or push

03Where it shows up

Existing workflow

• PR comments and checksNext to your human reviewers
• Cost and incident findingsWith a probable-cause deploy
• ChatQuestions about any finding

No new place to look

---

The first five minutes: a review you didn't configure

Connecting a repo takes an OAuth grant. You pick the organization and the repositories, and the connection starts read-only: the agent can read code, PRs and metadata, and post review comments. It can't merge, push or change settings. (More on that boundary below, because it's a hard one.)

The moment the connection lands, Review picks up your most recent open PR and reviews it. It's an actual review, not a lint pass:

• Bugs: null-path logic, off-by-one boundaries, error cases that swallow exceptions, race-prone patterns.
• Vulnerabilities: injection risks, unsafe deserialization, secrets committed in the diff, permissive CORS or IAM statements.
• Best-practice issues: missing timeouts on network calls, unbounded queries, retries without backoff. The things that page someone at 2 a.m. six weeks later.

The result posts as a normal PR comment with file and line references, so the author sees it in the same review flow as their human reviewers. Findings are graded, and it's explicit when something is a judgment call rather than a defect.

One honest note on quality: the first review is generic by design. It knows your code but not yet your conventions. It gets sharper as it sees more of your PRs and as you accept or dismiss findings. Treat the first one as a demo of the loop, not the ceiling.

---

Why this isn't a coding assistant

Fair question: doesn't Claude Code or Cursor already review code? Yes, and if you use one, keep using it. Coding agents help you write the change. This connection helps you operate what the change becomes once it's running in production. The review comment is where the overlap ends. Everything below lives outside your editor, which is why a coding assistant isn't positioned to do it.

01Before merge

Cost of a PR

Terraform and CloudFormation changes get a predicted monthly delta in review.

02Timeline

Deploy markers

Every deploy becomes a timestamp that cost and incident findings can point to.

03Ownership

Repo to service

A running service links to its repo and the people who commit there.

04Security

Weekly AppSec

Code findings land in the same queue as cloud posture findings.

---

What operations gains from knowing your code

1. The cost of a PR, before you merge it

If a PR touches Terraform or CloudFormation, the review includes an infrastructure cost prediction: a check comment estimating the monthly billing delta of the change, using pricing for your actual regions and instance families. It's the same cost analysis that runs against your accounts in part two.

Take the Friday PR from the top of this post:

 resource "aws_eks_node_group" "workers" {
   scaling_config {
-    min_size     = 3
-    desired_size = 3
+    min_size     = 6
+    desired_size = 6
     max_size     = 12
   }
 }

The check comment reads the plan, prices three more always-on nodes at your on-demand rates, and posts the delta next to the diff. A realistic set of predictions from a week of PRs:

Numbers are illustrative; yours come from your pricing. The point is the timing. A +$570/month decision is a thirty-second conversation in review and a forensic exercise three weeks later when it surfaces as a cost anomaly. Most infrastructure cost regressions aren't waste. They're merges nobody priced.

2. Deploy markers: the timestamp that answers "what changed?"

Once the repo is connected, every deploy becomes a marker on your operational timeline. That sounds mundane. It's the single highest-leverage thing on this page.

Nearly every production question reduces to what shipped nearest to this timestamp? Cost spiked Tuesday at 14:00: what deployed Tuesday morning? Latency doubled after the weekend: what merged Friday? Without markers, the answer is a manual lookup per repo:

# GitHub: recent deployments for one repo
gh api "repos/acme/payments-api/deployments?environment=production&per_page=20" \
  --jq '.[] | [.created_at, .sha[0:7], .ref] | @tsv'

# GitLab: the same, per project
glab api "projects/acme%2Fpayments-api/deployments?environment=production&order_by=created_at&sort=desc" \
  | jq -r '.[] | [.created_at, .sha[0:7], .ref] | @tsv'

That works for one repo you already suspect. During an incident you don't know which repo to suspect, and the pipeline that shipped the change may not even use the deployments API. With markers on the timeline, the correlation is a lookup, not an investigation.

Here's how that plays out on a cost anomaly:

01Signal

Cost anomaly

Spend on payments-api steps up on Tuesday afternoon.

02Readings

Three suspects

Traffic growth, new resources, or a change that shipped.

03Lookup

Deploy markers

The nearest deploy is a3f9c12, about 40 minutes earlier.

04Evidence

The diff

The change touched scaling config; traffic stayed flat.

05Finding

Probable cause

The anomaly names the deploy and links the evidence.

Spend on payments-api steps up on Tuesday afternoon. There are three readings. Traffic grew, so the spend is real demand. New resources were created outside any deploy. Or a change that shipped altered how the service scales. Each predicts something different: growth shows up in request metrics, new resources show up in inventory, and a change shows up as a deploy marker just before the step. Request rates are flat and inventory shows no new resource types. The nearest marker is deploy a3f9c12 to payments-api, about 40 minutes before the step, and its diff touches the autoscaling configuration. The anomaly alert from part two gains a probable-cause line, "anomaly began ~40 minutes after deploy a3f9c12 to payments-api", instead of just a red arrow.

The incident investigation in part five uses the same markers as its first suspect list: when an alert fires, the recent-deploys check is step one, the same way it is for a good on-call engineer. If you've read our root cause analysis guide, you know "recent change" is the leading hypothesis in most incidents. Deploy markers make that hypothesis testable in seconds.

3. Repo to service mapping: "who owns this?" in one click

CloudThinker maps your running services (the containers, functions and instances it sees through your cloud connection) back to the repositories they're built from, and to the people who commit there. The topology view links a running service to its repo and its most active recent contributors, so "who owns this?" is one click instead of an archaeology session through tagging conventions that were enforced for exactly one quarter.

The mapping is heuristic (image names, build metadata, tags, deploy history), and heuristics are sometimes wrong, so every link supports a manual override that sticks. Expect it to get the common cases right on its own and to need a handful of corrections for monorepo edge cases. Once it's right, it stays right, and every incident and cost finding after that arrives with an owner attached.

4. A weekly AppSec scan, in the same findings view as your cloud posture

Finally, the connection schedules a weekly AppSec scan of the repository: dependency vulnerabilities, committed secrets and configuration mistakes (overly permissive IAM in your IaC, debug flags, unsafe defaults). Findings land in the same security view as the cloud posture scan that runs against your accounts. One queue, not a code-security silo and a cloud-security silo that never meet. A leaked key found in code and the over-permissive role found in AWS are, for once, on the same page, and often they're literally the same problem.

---

Why this beats the traditional workflow

The deeper difference is memory. A review tool forgets the PR the moment it merges. An operations platform that has read the PR remembers it when the cost graph moves or the pager goes off, and that memory is what turns "something changed" into a named deploy with a diff.

---

Read and comment only, in every mode

The trust question deserves a plain answer, because "AI with access to my repos" should raise one.

CloudThinker's cloud-side actions run within Auto Mode, so you decide what runs on its own and what waits for approval. The repo connection sits outside that entirely:

• Read and comment only. Ever. Review posts review comments and check comments. It doesn't merge PRs, push commits, close branches, deploy, or modify branch protection or repository settings. Unlike CloudThinker's cloud-side actions, no Auto Mode setting changes this. There is no setting that lets it merge.
• Cost predictions are advisory. A "+$412/month" comment is information for the humans doing the review. It doesn't block the merge, and it doesn't gate CI unless you wire that up yourself.
• You choose the repositories. The OAuth grant is per repo or per org, your call, and revocable from your Git provider at any time through the standard app-permissions screen.
• Everything is in the audit trail. Every review posted, every scan run, every service-mapping override is logged with what, when and on whose authority, the same trail that covers every CloudThinker connection.

This connection gives your operations a memory of your code. It never gives anything the ability to change your code.

---

Getting started

1. Connect a repo. Follow the connection guide for GitHub or GitLab and pick the repositories to grant. The first review starts on its own.

2. Ask about the change history.

"For the payments-api repo, list everything that deployed to production in the last seven days, and for each deploy that touched Terraform, estimate the monthly cost delta."

3. Join it to an open question.

"Our AWS spend jumped on Tuesday afternoon. Check which deploys landed in the two hours before the jump, show the diffs, and tell me which one most likely explains it. Propose only, change nothing."

---

Related reading

• The connection value ladder
• Connect a cloud account, see dollar findings in five minutes
• Connect PagerDuty, get an alert noise audit
• Root cause analysis guide
• The compounding effect of connected operations

One connection, four compounding returns

Five minutes after the OAuth grant, you have a PR review. Within the week, you have per-PR cost predictions, deploy markers on your timeline, an ownership map and a weekly security scan. Each one makes the other connections smarter: the cloud connection's anomalies get probable causes, and the incident connection's investigations get suspect lists. That compounding is the subject of part seven, but you don't have to wait for the theory to see the first review comment.

Try CloudThinker free (100 premium credits, no card required), connect a repo via the connection guide, and check your most recent open PR a few minutes later.