Infrastructure cost in code review: making dollars a review dimension

Quick answer

Code review reliably checks correctness, security, and style, but cost is invisible in a Terraform diff: a one-line instance-type change can multiply the bill without looking any different. You make cost a review dimension by surfacing the priced cost delta in the pull request automatically, so reviewers see the dollar impact beside the code and can question it like any other concern. Over time this trains authors to check their own cost before pushing. The principle is put the cost delta in front of the reviewer so cost gets the same scrutiny as correctness.

A diff shows what changed in the code, but not what it costs. Changing an instance type from a small to a large is one character in the diff and a doubling of the bill. Reviewers cannot weigh cost they cannot see, so cost gets skipped in review not from neglect but from invisibility. Making cost a review dimension means putting the dollar impact where the reviewer already looks.

Why cost is invisible in review

Review dimension	Visible in diff?
Correctness	Yes, in the logic
Security	Often, in the config
Cost	No, hidden in resource sizing

Correctness and security leave traces in the diff a trained reviewer can spot. Cost does not: the sizing, count, and type fields that drive cost look like ordinary configuration, and their dollar consequence is nowhere in the text. So even a diligent reviewer misses cost, because there is nothing to see. The fix is to add the missing signal.

Surfacing the cost delta

The signal is the priced cost delta, posted automatically on the pull request. When a reviewer opens a PR and sees this change adds 300 dollars a month, cost becomes as visible as a failing test. They can then apply judgment, is that expected, is it justified, the same judgment they apply to logic and security. c3x posts this delta as aPR comment, so the dollar figure sits in the review thread with no extra tool to open.

Reviewing cost like any concern

Once the delta is visible, reviewers treat it as a normal review item: an unexplained jump gets a question, a large addition gets a justification, a surprising number gets investigated. This is not about blocking every costly change, since some are necessary, but about ensuring cost is considered rather than shipped blind. A reviewer asking why does this add 300 a month often uncovers an accidental oversizing the author did not intend.

The author-side effect

Knowing that the cost delta will appear in review changes author behavior before the review even happens. Authors start checking their own cost impact before pushing, right-sizing preemptively because they do not want to explain a surprise in review. This self-correction is the biggest long-term benefit, the same cultural shift thatcost awareness aims for, achieved through routine visibility rather than mandates.

Making it routine

Add cost commenting to every infrastructure repository so the delta is always present, and set a team norm that unexplained cost jumps get questioned in review, just like unexplained logic changes. When cost is a standing part of every review, it stops being an afterthought and becomes a habit. Price your changes against theresource catalog so the delta reviewers weigh is grounded in real rates and worth taking seriously.

FAQ

Why is cost invisible in code review?

Because cost is hidden in resource sizing, count, and type fields that look like ordinary configuration in a diff, with no dollar consequence visible in the text. Correctness and security leave traces a reviewer can spot, but a one-line instance-type change that doubles the bill looks unremarkable, so even a diligent reviewer misses cost from invisibility, not neglect.

How do I make cost a code review dimension?

Surface the priced cost delta in the pull request automatically, so a reviewer opening a PR sees that a change adds a given amount per month as clearly as a failing test. That gives them the missing signal to apply judgment about whether the cost is expected and justified, the same scrutiny they apply to logic and security.

How should reviewers handle cost in review?

Treat the cost delta as a normal review item: an unexplained jump gets a question, a large addition gets a justification, a surprising number gets investigated. It is not about blocking every costly change, since some are necessary, but ensuring cost is considered rather than shipped blind. A reviewer asking why a change adds cost often uncovers accidental oversizing.

Does cost-aware review change author behavior?

Yes, and this is the biggest long-term benefit. Knowing the cost delta will appear in review, authors start checking their own cost impact before pushing and right-size preemptively to avoid explaining a surprise. That self-correction, driven by routine visibility rather than mandates, is the cultural shift toward engineering cost awareness that cost-aware review aims for.

How does C3X make cost a review dimension?

C3X prices the Terraform plan statically against a live catalog with no cloud credentials and posts the cost delta as a comment on the pull request, so the dollar impact sits in the review thread beside the code with no extra tool to open. That gives reviewers the missing signal to weigh cost alongside correctness, and trains authors to check cost before pushing.

What to do next

Give cost the scrutiny correctness gets. C3X posts the cost delta in every infrastructure PR for reviewers. Start with the quickstart.