--- 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 · 146 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 is running Claude code review skills in GitHub Actions so expensive and noisy compared to running them locally? Running Claude-based code review skills in CI produces overwhelming noise because the model treats every PR generically, backing minor style nitpicks with lengthy essays as if reviewing a stranger's code. One team hit roughly $1000 in a single day running these skills in GitHub Actions, versus getting clean, actionable output when the same skills were run locally on a developer's machine before pushing. _Teams weighing AI code review costs against custom tooling can track real-world cost tradeoffs on daily.dev._ ### What are some examples of custom linter rules a team can create for enforcing coding conventions instead of using AI code review? Examples include no-raw-color and no-hardcoded-mono for design system consistency, no-swallowed-errors for proper error handling, no-render-helpers for enforcing React component patterns, check-no-mock for discouraging mock-heavy tests, and a de-blab rule built on Vale that strips passive voice and AI-sounding phrasing from comments and docs. These were generated by pointing an AI tool at existing markdown style guides and asking it to convert deterministic rules into linters. _Developers building custom lint rules to enforce team conventions can compare approaches on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@mihai** · 37 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 --- 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-08-15T18:06:50.976Z","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":145},{"@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":37}},{"@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 is running Claude code review skills in GitHub Actions so expensive and noisy compared to running them locally?","acceptedAnswer":{"@type":"Answer","text":"Running Claude-based code review skills in CI produces overwhelming noise because the model treats every PR generically, backing minor style nitpicks with lengthy essays as if reviewing a stranger's code. One team hit roughly $1000 in a single day running these skills in GitHub Actions, versus getting clean, actionable output when the same skills were run locally on a developer's machine before pushing. Teams weighing AI code review costs against custom tooling can track real-world cost tradeoffs on daily.dev."}},{"@type":"Question","name":"What are some examples of custom linter rules a team can create for enforcing coding conventions instead of using AI code review?","acceptedAnswer":{"@type":"Answer","text":"Examples include no-raw-color and no-hardcoded-mono for design system consistency, no-swallowed-errors for proper error handling, no-render-helpers for enforcing React component patterns, check-no-mock for discouraging mock-heavy tests, and a de-blab rule built on Vale that strips passive voice and AI-sounding phrasing from comments and docs. These were generated by pointing an AI tool at existing markdown style guides and asking it to convert deterministic rules into linters. Developers building custom lint rules to enforce team conventions can compare approaches on daily.dev."}}]} ```