--- title: Stop burning tokens on code review | daily.dev description: An engineering leader shares why AI-based code review tools like Cursor's BugBot and custom Claude code review skills became too slow, noisy, and expensive... canonical: https://daily.dev/posts/stop-burning-tokens-on-code-review-kxrtlop02 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Stop burning tokens on code review | daily.dev og:description: An engineering leader shares why AI-based code review tools like Cursor's BugBot and custom Claude code review skills became too slow, noisy, and expensive... og:url: https://daily.dev/posts/stop-burning-tokens-on-code-review-kxrtlop02 og:image: https://api.daily.dev/og/posts/kXRtlop02.png og:image:alt: Stop burning tokens on code review og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Stop burning tokens on code review **[swizec.com](https://daily.dev/sources/swizec)** · 6 min read · 147 upvotes · 16 comments ## Summary An engineering leader shares why AI-based code review tools like Cursor's BugBot and custom Claude code review skills became too slow, noisy, and expensive (hitting $1000/day in one case) for a team producing thousands of PRs a quarter. The fix that worked: converting team-specific coding rules from markdown guidelines into custom linters, which run in seconds, are deterministic, can run in-editor and on pre-commit hooks, and stop agents from ever pushing bad code. Several example custom lint rules are shared, covering design system consistency, logging, testing conventions, and prose quality. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why did running Claude code review skills in GitHub Actions become expensive and noisy? Running Claude-based code review skills as automated GitHub Actions checks produced overwhelming, pedantic feedback that took longer to review than the original code, and costs spiked to roughly $1000 in a single day. The same skills worked fine when engineers ran them manually on their own machines before pushing, since they could quickly triage which comments mattered. _Anyone weighing AI code review costs against custom tooling can track real-world cost tradeoffs like this on daily.dev._ ### What is a de-blab linter and what does it catch in code comments or docs? A de-blab linter, built on the Vale linting tool, automatically flags and helps fix passive voice, convoluted wording, AI-sounding phrasing, navel-gazing, and unnecessary history lessons in comments, docstrings, and markdown files. It was created by turning a team's style guidelines into deterministic linter rules rather than relying on an LLM to review prose. _Developers cleaning up AI-generated prose in codebases can find tooling ideas like this on daily.dev._ ### How much did enabling Cursor's BugBot for pull request review cost per week? Enabling Cursor's BugBot for automated pull request review cost about $1000 per week for a team producing roughly 2900 pull requests per quarter. It occasionally caught valuable issues like missing business requirements or cross-team dependencies, but also added noise through invented security concerns and excessive risk-assessment fluff in PR descriptions. _Teams budgeting for AI code review tools can compare real costs like this on daily.dev before committing._ ## Community discussion Top comments from developers on daily.dev. **@mihai** · 39 upvotes > I see where the author is going with this, and I agree that a lot of the mechanical feedback left in comments, like conventions, formatting, style, etc., can and probably should be captured by linters and formatters. > > > I do think it leaves out a fairly important aspect of the code reviewing process. Getting a peer review is not just about finding code issues, getting your approval quickly and merging your work, it also serves as a learning and knowledge-sharing env for the team. Every time a teammate puts up a PR, having a peer review it means there is at least one more person on the team who... **@elmarchavez** · 9 upvotes > This is actually fascinating to read. Not only that it saves the company money, but also the implementation is much more human and much more intentional. I like this approach much more. **@trevorsuna** · 5 upvotes > This is a good boundary: use linters for deterministic team policy, and save model review for context and tradeoffs. Moving repeatable rules into fast local checks also prevents the bad pattern before a PR exists, which is more useful than producing another noisy review comment. **@ogluka** · 3 upvotes > I get what author is saying, and yes of course team should have documented guidelines and everything set up to push similar, clean and good code, but having reviewer at the end of the pipeline helps, you cannot guarantee how a model will write a code in which IDE or environment and how developer or agent will push at the end, so having the last "wall" for code review is good, for me it can be gitlab pr agent reviewer with custom guidelines and it will point out if something isn't good, the tokens are also not so expensive for this, for example i can push 200+ file changes and it will cost 0.1... **@bob\_marley\_556** · 2 upvotes > which tool is best for code review ## Similar posts on daily.dev - [Why I’m Sold on AI for Code Reviews](https://daily.dev/posts/why-i-m-sold-on-ai-for-code-reviews-fmllklpxk) · Atomic Spin · 0 upvotes · 0 comments - [Code review is burning out your best engineers](https://daily.dev/posts/code-review-is-burning-out-your-best-engineers-5anqvkfac) · The New Stack · 0 upvotes · 0 comments --- Tags: [#architecture](https://daily.dev/tags/architecture), [#ai-coding](https://daily.dev/tags/ai-coding), [#claude](https://daily.dev/tags/claude), [#code-review](https://daily.dev/tags/code-review) [View this post on daily.dev](https://daily.dev/posts/stop-burning-tokens-on-code-review-kxrtlop02) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Stop burning tokens on code review","url":"https://daily.dev/posts/stop-burning-tokens-on-code-review-kxrtlop02","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/stop-burning-tokens-on-code-review-kxrtlop02"},"datePublished":"2026-08-15T16:35:07.735Z","dateModified":"2026-09-14T07:42:18.690Z","description":"An engineering leader shares why AI-based code review tools like Cursor's BugBot and custom Claude code review skills became too slow, noisy, and expensive...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/12e84add440a689b67854911cbe986ad?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/12e84add440a689b67854911cbe986ad?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"swizec.com","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"swizec.com","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/a0733daf6e014e23a638ded7f2d4cd70","url":"https://daily.dev/sources/swizec"},"commentCount":16,"discussionUrl":"https://daily.dev/posts/stop-burning-tokens-on-code-review-kxrtlop02","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":147},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":16}],"keywords":"architecture,ai-coding,claude,code-review","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"swizec.com","item":"https://daily.dev/sources/swizec"},{"@type":"ListItem","position":3,"name":"Stop burning tokens on code review"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/stop-burning-tokens-on-code-review-kxrtlop02","comment":[{"@type":"Comment","text":"I see where the author is going with this, and I agree that a lot of the mechanical feedback left in comments, like conventions, formatting, style, etc., can and probably should be captured by linters and formatters.\nI do think it leaves out a fairly important aspect of the code reviewing process. Getting a peer review is not just about finding code issues, getting your approval quickly and merging your work, it also serves as a learning and knowledge-sharing env for the team. Every time a teammate puts up a PR, having a peer review it means there is at least one more person on the team who has seen and understood the change before it hits a stable branch. It gives the team shared awareness and ownership of the shipped work.\nAnother aspect of code reviewing that can’t really be captured by tools are things that aren’t necessarily wrong within the code itself, but that might make someone ask questions like “is this the right abstraction?” or “is this PR solving the right problem? what are the consequences of this landing in our codebase?”","datePublished":"2026-08-16T06:09:25.261Z","url":"https://daily.dev/posts/kXRtlop02#c-TkwyuasJW","author":{"@type":"Person","name":"mihai","url":"https://daily.dev/mihai","image":"https://avatars2.githubusercontent.com/u/15910058?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":39}},{"@type":"Comment","text":"This is actually fascinating to read. Not only that it saves the company money, but also the implementation is much more human and much more intentional. I like this approach much more.","datePublished":"2026-08-16T16:56:41.442Z","url":"https://daily.dev/posts/kXRtlop02#c-jULNYHRfw","author":{"@type":"Person","name":"Elmar Chavez","url":"https://daily.dev/elmarchavez","image":"https://media.daily.dev/image/upload/s--7PjH979T--/f_auto/v1780994221/avatars/avatar_bK85rJb2OXXID2LX2wi5y?_a=BAMAMiWQ0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":9}},{"@type":"Comment","text":"This is a good boundary: use linters for deterministic team policy, and save model review for context and tradeoffs. Moving repeatable rules into fast local checks also prevents the bad pattern before a PR exists, which is more useful than producing another noisy review comment.","datePublished":"2026-08-17T02:39:15.810Z","url":"https://daily.dev/posts/kXRtlop02#c-auppi9zlP","author":{"@type":"Person","name":"Trevor Suna","url":"https://daily.dev/trevorsuna","image":"https://media.daily.dev/image/upload/s--dZ7gXxpp--/f_auto/v1784081551/avatars/avatar_EMoP47rpuw8DNjhp6R1b6?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":5}},{"@type":"Comment","text":"I get what author is saying, and yes of course team should have documented guidelines and everything set up to push similar, clean and good code, but having reviewer at the end of the pipeline helps, you cannot guarantee how a model will write a code in which IDE or environment and how developer or agent will push at the end, so having the last “wall” for code review is good, for me it can be gitlab pr agent reviewer with custom guidelines and it will point out if something isn’t good, the tokens are also not so expensive for this, for example i can push 200+ file changes and it will cost 0.1 - 0.3 $ per review with optimised model.","datePublished":"2026-08-17T12:30:46.369Z","url":"https://daily.dev/posts/kXRtlop02#c-SHe7v1kWa","author":{"@type":"Person","name":"Luka Orkoshneli","url":"https://daily.dev/ogluka","image":"https://avatars.githubusercontent.com/u/73040859?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3}},{"@type":"Comment","text":"which tool is best for code review","datePublished":"2026-08-18T04:49:05.433Z","url":"https://daily.dev/posts/kXRtlop02#c-cyrrI3iET","author":{"@type":"Person","name":"Aashish pokhrel","url":"https://daily.dev/bob_marley_556","image":"https://avatars.githubusercontent.com/u/126847212?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/stop-burning-tokens-on-code-review-kxrtlop02#faq","mainEntity":[{"@type":"Question","name":"Why did running Claude code review skills in GitHub Actions become expensive and noisy?","acceptedAnswer":{"@type":"Answer","text":"Running Claude-based code review skills as automated GitHub Actions checks produced overwhelming, pedantic feedback that took longer to review than the original code, and costs spiked to roughly $1000 in a single day. The same skills worked fine when engineers ran them manually on their own machines before pushing, since they could quickly triage which comments mattered. Anyone weighing AI code review costs against custom tooling can track real-world cost tradeoffs like this on daily.dev."}},{"@type":"Question","name":"What is a de-blab linter and what does it catch in code comments or docs?","acceptedAnswer":{"@type":"Answer","text":"A de-blab linter, built on the Vale linting tool, automatically flags and helps fix passive voice, convoluted wording, AI-sounding phrasing, navel-gazing, and unnecessary history lessons in comments, docstrings, and markdown files. It was created by turning a team's style guidelines into deterministic linter rules rather than relying on an LLM to review prose. Developers cleaning up AI-generated prose in codebases can find tooling ideas like this on daily.dev."}},{"@type":"Question","name":"How much did enabling Cursor's BugBot for pull request review cost per week?","acceptedAnswer":{"@type":"Answer","text":"Enabling Cursor's BugBot for automated pull request review cost about $1000 per week for a team producing roughly 2900 pull requests per quarter. It occasionally caught valuable issues like missing business requirements or cross-team dependencies, but also added noise through invented security concerns and excessive risk-assessment fluff in PR descriptions. Teams budgeting for AI code review tools can compare real costs like this on daily.dev before committing."}}]} ```