Loading…
Topic
Code Review
40 posts about Code Review. Every summary links to the original.
- 40 posts
- 18 companies
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
AI is approving our pull requests: Here’s how we made it safe
Intercom describes how it uses an AI PR review Agent to approve some pull requests amid a workflow where more than 93% are Agent-driven and engineers deploy hundreds of times daily. The system decomposes review into specialist sub-Agents that assess problem descriptions, intent alignment, safety, logic, best practices, and execution paths, while applying Intercom-specific guidance and enforcing smaller changes. In a pilot of more than 100 PRs, AI-approved changes had zero reverts and approval time improved 6–16 times at the 75th percentile; in four rollout weeks, 497 PRs went fully autonomous. Reported revert rates were lower for AI-authored than human-authored code in both backend and frontend comparisons, though the source says zero reverts will not necessarily persist. The process remains auditable, allows human review requests, and keeps the shipping engineer accountable for production behavior and rollback.
Bugbot now self-improves with learned rules
At its July 2025 beta exit, Bugbot resolved 52% of identified bugs by the relevant PR merge; that rate is now nearing 80%. In the public-repository comparison, Cursor Bugbot reached 78.13% across 50,310 analyzed PRs, versus Greptile’s 63.49%; an LLM judge checked whether comments were addressed by merge. It now turns reactions and replies to Bugbot comments, along with human-reviewer comments, into live feedback rather than relying exclusively on offline experiments. Bugbot converts those signals into candidate rules, evaluates them on incoming PRs, promotes candidates to active status as signal accumulates, and can disable rules receiving consistent negative feedback. More than 110,000 repositories have enabled learning, generating over 44,000 rules, which users can edit or delete in the Cursor Dashboard.
Agentic coding at ClickHouse
Industry perspectives on AI coding agents remain divided between dismissal and excessive automation claims. ClickHouse integrated agentic coding across internal workflows, progressing from simple boilerplate scripts to active backend C++ development. Engineers primarily use command-line agents such as Claude Code with Claude Opus 4.5 and Codex CLI alongside observability platforms like Langfuse and Librechat. While agents effectively investigate continuous integration logs, generate internal dashboards, and assist with small C++ tasks, they lack architectural competence and require rigorous code review. ClickHouse treats agents as pair programmers for contained tasks, retaining human ownership over product strategy, attention to detail, and core code quality.
PlanetScale protects production reliability with Bugbot
PlanetScale describes code review as the bottleneck created by rapidly increasing agent-generated code, while human review capacity remained fixed. To preserve production reliability, the company adopted Bugbot as a dedicated agentic review layer alongside its existing process. Bugbot surfaces semantic and logical issues that static analyzers, linters, and straightforward frontier-model reviews may miss, including premature completion states, non-converging asynchronous controllers, and database restart edge cases. Across more than 2,000 pull requests reviewed monthly, roughly 80% of Bugbot's comments are addressed before merge. PlanetScale says this prevents potential production downtime, saves the equivalent of two full-time engineers of review effort, and lets engineers focus on complex infrastructure work without sacrificing quality.
Closing the code review loop with Bugbot Autofix
Bugbot Autofix extends the code review agent so it can find issues in pull requests and automatically propose fixes. It spawns cloud agents in independent virtual machines that test software, and more than 35% of its changes are merged into the base PR. Now out of beta and available to all Bugbot users, the feature adds proposed fixes to the pull requests Bugbot reviews once enabled. Bugbot’s average issues identified per run has nearly doubled over six months, while the user resolution rate rose from 52% to 76%, indicating more bugs are caught and fewer false positives are flagged. Future work includes configurable automations, self-verification, deeper research, and continuous codebase scanning.
How Stripe rolled out a consistent Cursor experience for 3,000 engineers
Stripe rolled out Cursor to more than 3,000 engineers while preserving its standards for developer experience and API uptime. The company preloaded Cursor on every machine, taught it in onboarding labs alongside VS Code and IntelliJ, and used Cursor Rules to supply codebase and coding-standard context, with teams able to add local rules. Adoption was reinforced by power users, while code review evolved to use LLMs to flag complex methods and risky files so reviewers could focus attention without sacrificing quality. An internal survey found developer sentiment at a five-year high, and MacVicar observed the largest productivity gains among longest-tenured engineers rather than junior developers. That finding has prompted exploration of letting new hires learn the codebase before receiving Cursor access, reinforcing MacVicar’s advice to start before every AI-workflow question is settled.
Building a better Bugbot
Bugbot is a code review agent built to identify logic bugs, performance issues, and security vulnerabilities in pull requests before production, as increasingly capable coding agents increased review workload. Its development moved from qualitative assessments to systematic experimentation, using an AI-driven resolution-rate metric, the BugBench benchmark, and online evaluations of real pull requests. An early production flow ran eight parallel passes with randomized diff ordering, majority voting, category filters, validation, and deduplication, while later versions adopted a fully agentic design with tools and dynamic context. Across 40 major experiments, resolution rate rose from 52% to over 70%, bugs flagged per run from 0.4 to 0.7, and resolved bugs per pull request from roughly 0.2 to about 0.5. Newer versions caught more bugs without a comparable rise in false positives, and planned capabilities include Autofix, self-verification, deep research, and continuous scanning.
Best practices for coding with agents
Cursor's guide presents practices for using coding agents that can run for hours, complete multi-file refactors, and iterate until tests pass. Planning first is emphasized: Plan Mode researches the codebase, asks clarifying questions, creates a reviewable implementation plan, and waits for approval. The guidance recommends letting the agent discover context, starting new conversations when focus declines, and using Rules for persistent project instructions while Skills provide dynamic workflows. It also describes hooks for long-running loops, worktrees for isolated changes, parallel model runs, cloud agents, and Debug Mode's hypothesis-and-instrumentation process. Careful diff review, specific prompts, and verifiable goals remain necessary because generated code can be subtly wrong.
Bugbot is out of beta
Cursor has released Bugbot, a code review agent that automatically analyzes pull-request changes for logic bugs, edge cases, and security issues before production. It runs automatically on pull requests, gathers context from changes to understand code intent, and comments detected issues directly where they occur. Teams can steer reviews with custom BUGBOT.md rules, then send flagged issues to Cursor or launch a background agent on the web with one click. During its beta, Bugbot reviewed over 1 million PRs and found over 1.5 million issues; more than 50% of identified bugs were resolved before merge. Cursor also reports adoption by several companies, with testimonials citing review-time savings, strong bug detection, and confidence reviewing AI-generated code.
How OVO determined the right technology stack for their web-based projects
OVO faced maintainability issues caused by fragmented web technology stacks, including PHP, Vue, React, Nuxt, and Go, alongside outdated documentation. This fragmentation resulted in severe context-switching costs during code reviews and prolonged onboarding times for new engineers. To establish a single primary front-end stack, the team compared React and Vue against maintainability principles encompassing operability, simplicity, and evolvability. Vue was selected because its standardized framework structure and documentation minimized architectural variations across projects. Implementation entailed creating a standardized Vue boilerplate, updating the internal UI library, and scheduling periodic upgrades for legacy React services rather than migrating them entirely.
What is PostgreSQL commitfest and how to contribute
PostgreSQL Commitfest is the community's month-long review process for patches intended for merging into core. Contributors submit patches to pgsql-hackers, create a Git branch from master, consolidate changes, generate a versioned patch, and associate its mailing-list thread with an open Commitfest entry. The process expects authors to explain rationale, respond to review, rebase or revise patches, and review a comparable number of other patches. Submitted changes are checked by CFBot across architectures and operating systems, while statuses such as "Needs review," "Ready for committer," and "Waiting on author" track progress. Commitfests occur five times yearly, with the March event tied to feature-freeze for the October major release.
A Software Engineer's Guide to Working Across Time Zones
Working across time zones can make live collaboration difficult when teammates are nine to 12 hours apart, as described by a developer based in Singapore. The proposed alternative is to treat much of the work as asynchronous and deliberately document progress, blockers, decisions, and context. Examples include taking turns across working hours, annotating non-obvious pull request changes, posting end-of-day summaries with links or investigation notes, and recording meetings with agendas, key decisions, and action items. During Shopify's Hack Days prototype work on Linkpop, a Singapore-based frontend developer handed off updates before sleeping while North American teammates extended backend functionality and responded to blockers. The post concludes that these practices become habits that support handoffs, reduce back-and-forth, preserve information for absent teammates and future reference, and can provide longer uninterrupted focus periods.
On the Importance of Pull Request Discipline
The article argues that pull request (PR) discipline matters beyond code correctness because implementation and maintenance both benefit from changes that are clearly structured and documented. It describes a PR as a proposal whose title, summary, commits, comments, reviewers, labels, projects, and linked issues should intentionally communicate scope, design reasoning, low-level details, ownership, and historical connections. Its practical guidance focuses on precise titles, useful summaries, logically ordered commits, deliberate remote-branch changes, defined PR boundaries, and moving asides into follow-up PRs. It also recommends smaller, well-ordered PRs, permalink-based code references, distinctive branch-name prefixes, and learning Git commands including reflog, cherry-pick, and rebase. The article treats discipline as judgment rather than rigid law, allowing emergency exceptions while encouraging post-resolution documentation.
A Software Engineer’s Guide to Giving Feedback that Actually Matters
The post presents feedback as a professional tool that can either support growth and collaboration or fuel ego-driven competition. It focuses first on pull request reviews, where engineers should prioritize critical code and logic over stylistic nitpicks, use linters or pre-commit hooks for uniform formatting, and frame comments to preserve a two-way educational dynamic. Recommended practices include discussing team review processes, explaining feedback goals, drafting messages before sending, reinforcing strengths, asking questions, separating behavior from identity, and making comments specific and timely. For broader workplace issues, the post advises asking whether feedback must be said, by the speaker, and immediately, then using considerate timing and SMART framing to improve the chance that it will be heard and produce change.
When Culture and Code Reviews Collide, Communication is Key
The post examines how cultural differences in politeness, directness, and face-saving can distort written code reviews, causing useful feedback to be softened, misread, or ignored. It contrasts a passive-aggressive Shopify pull-request exchange about missing permalink tests with a more curious and explicit version that states why a separate test would be worthwhile. The discussion distinguishes assuming positive intent from asserting it: context can reduce bias, but it must not erase the impact of embarrassing or harmful communication. It recommends treating reviews as collaborative invitations, asking questions, explaining reasoning, acknowledging reviewers as contributors, and looking past stylistic language to shared goals. The conclusion is that clearer communication and shared ownership can make disagreement productive and improve both learning and the codebase.
Six Tips for Staying Technical as a CTO
The article examines how a CTO can remain technically credible after moving from the individual contributor track into leadership. It argues that leadership inevitably reduces technical depth because performance reviews, one-on-ones, organizational communication, and other people responsibilities limit time in code, making the transition an intentional choice for those who value managing people. Its recommended practices include voracious reading, coding as a hobby, participating in hackathons, learning directly from more technical colleagues, maintaining a private network of technical advisors, and aggressively clearing bugs, incident-remediation work, and backlog. The author illustrates hands-on learning with Shopify’s Spin environment, which provisions a cloud development instance and opens a repository in about 30 seconds, and concludes that controlling operational issues preserves time for innovation and technical leadership.
Introducing Pull Requests and Discussions 🥳
Hugging Face Hub released pull requests and discussions under a new community tab for all repository types, including models, datasets, and Spaces. This feature enables community members and repository owners to interact directly, propose model card updates, report biased generations, and contribute files. The pull request implementation departs from traditional Git hosting platforms by avoiding forks and standard branches. Instead, contributors push to custom ref branches stored directly on the source repository to bypass creating heavy forks for large machine learning artifacts. Furthermore, the Hub treats discussions and pull requests without hard distinctions, listing them together to streamline collaboration across machine learning assets.
Embracing a Docs-as-Code approach
Engineers at Grab faced difficulties finding and writing technical documentation because materials were fragmented across various platforms and disconnected from daily workflows. To establish a single source of truth, the organisation adopted a Docs-as-Code approach starting in 2021. Under this system, documentation is written in plaintext Markdown within dedicated folders inside each service's Git repository. An internal developer portal automatically builds and publishes documentation whenever updates are committed, integrating documentation maintenance into the standard code development and review workflow. By April 2022, approximately 80% of Grab services were projected to host their documentation on the internal portal, with the model also expanding to technical training content.
Great Code Reviews—The Superpower Your Team Needs
The article presents code review as a way to improve software quality, learning, and shared team responsibility, contrasting it with large, shallow pull requests that provide little actionable feedback. Its practices include keeping PRs small, using Draft or WIP PRs for early direction checks, limiting each PR to one concern, focusing comments on code rather than people, choosing reviewers with relevant context, and giving reviewers a clear map through the PR description. For data engineering, it gives an internal guideline of roughly 200–300 affected lines, while warning that excessively tiny PRs can obscure the overall picture. The stated benefits are faster, deeper reviews, easier rollback and iteration, better knowledge sharing, and a codebase that does not depend on one person, although the article frames these techniques as experiments teams should adapt.
A Guide to Mindful Communication in Code Reviews
Code reviews are presented as both technical work and communication, teaching, and learning. The guide defines mindful communication as listening and speaking with compassion, kindness, and self-awareness, then applies that perspective to reviewers and authors. It recommends self-checking before commenting, asking open questions instead of assuming, omitting linter-detectable nits, signaling what can wait, giving example code and documentation, and ending substantial feedback with “What do you think?” Reviewers are encouraged to approve unless major problems exist, while large changes and architectural decisions should receive broader discussion. Authors should link relevant documentation, assume good intent unless feedback is hostile, keep diffs focused, and seek feedback early; these practices take time but can become a learnable habit that varies by team.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.