Transaction costs, PR approvals, and the death of the janitorial commit

I've had this nagging feeling for years that the day-to-day usability of internal tools degrades the exact quarter a startup hires a compliance officer. Since human perception of organizational friction is notoriously subject to confirmation bias, I started looking for empirical evidence and recently reviewed a dataset that parsed the git logs of 15 corporate repositories (mostly open-source infrastructure components maintained by mid-sized SaaS companies that went through SOC2 compliance between 2019 and 2022) to measure the physical reality of commit sizes before and after mandatory PR approvals were turned on.

The raw data is striking. When we look at the commit distributions over a three-year horizon centering on the quarter compliance policies were enforced, we see a structural collapse in micro-fixes.

Commit Size Distribution (15-repo aggregate, 90-day windows)
| Size         | Pre-SOC2 Enforce | Post-SOC2 Enforce | Delta  |
|--------------|------------------|-------------------|--------|
| <5 lines     | 3,412            | 204               | -94.0% |
| 5-50 lines   | 5,190            | 4,110             | -20.8% |
| 50+ lines    | 2,105            | 2,340             | +11.1% |

Within roughly 30 days of strict SOC2 PR-approval policies being enforced, <5 line janitorial commits essentially evaporated, dropping by 94%. To understand why this happens, we have to drill down into the micro-level economics of the "Commit Tariff Equation" and how it permanently alters the daily mechanism design for an individual contributor.

In a frictionless environment, a developer noticing a broken tooltip or a confusing log message can fix it in 2 minutes. Once strict compliance mandates are flipped on, that same 2 minute typo fix requires creating a Jira ticket (which takes 3 minutes of fighting with arbitrary required fields), branching, pushing, waiting for an enforced CI run to complete (15 minutes), hunting down a peer to asynchronously approve the pull request <abbr title="assuming your teammates aren't completely burned out and actually review PRs in less than a day, which is a frankly hilarious assumption for most enterprise engineering teams">and monitoring the deployment</abbr> (5 minutes), which conservatively inflates the total elapsed time to 45 minutes.

If you divide the new administrative cost (45 minutes) by the old execution cost (2 minutes), you get a 22.5x overhead multiplier. In classic microeconomic theory, this burden acts as a Transaction cost that entirely bankrupts the economic trade of making the fix. To put this in perspective, if a physical consumer good suddenly experienced a 2250% sales tax increase overnight, market activity for that good would instantly drop to absolute zero. That is exactly what we see in the git logs.

The cocktail-party consensus in tech-utopian circles—often framed as the Reverse Jevons Paradox—claims this friction is actually a net positive because it forces developers to think harder and reduces useless, low-quality code churn. The assumption is that by making it painful to commit code, developers will only commit code that strictly needs to exist, naturally filtering out the garbage. You can see this normalization of deviance everywhere, including in the Hacker News comment thread for that exact argument where engineers routinely defend the compliance tax as a necessary filter for engineering maturity.

That logic completely falls apart when you actually do the math on how fixed costs operate at different scales.

Fixed-cost friction mathematically taxes micro-fixes out of existence while leaving bloated macro-commits relatively untouched. A fixed 45 minute transaction cost applied to a 2 minute janitorial fix is a 2250% tax (45 / 2 = 22.5). That same 45 minute transaction cost applied to a 2000 minute feature-shipping PR is a negligible 2.25% tax (45 / 2000 = 0.0225). The bureaucracy heavily penalizes anyone trying to keep the codebase clean while actively incentivizing developers to batch changes into massive, unreviewable pull requests where the fixed cost can be amortized over thousands of lines of code.

To see the full catastrophic effect of this dynamic, we have to escalate from the git log to HR and map this transaction cost onto standard industry promotion incentives.

IC Payoff Matrix (Expected Value of Commit)
|                | Frictionless Repo | High-Friction Repo (45m tariff) |
|----------------|-------------------|---------------------------------|
| Micro-fix      | High ROI          | Negative ROI (abandoned)        |
| Macro-feature  | Moderate ROI      | High ROI (only viable path)     |

Engineers are perfectly rational actors who locally optimize for the incentive structures they operate under. If you look at standard leveling rubrics like the ones outlined in Software Engineer Levels Explained, corporate mechanism design exclusively rewards shipping "large scale projects" and demonstrating measurable macro-impact (usually defined as cross-team architectural changes or shipping features that directly tie to quarterly revenue goals). There is no promotion packet anywhere in the industry that rewards an engineer for doing 200 undocumented, un-ticketed two-minute janitorial fixes.

When you combine the 22.5x transaction cost with a promotion rubric that assigns an expected value of zero to maintenance, it becomes completely economically irrational for an engineer to fix a broken window. If doing the right thing for the codebase actively harms your ability to hit your quarterly goals because you are burning 45 minutes of bureaucratic overhead for zero career advancement, you will simply stop doing the right thing.

This microeconomic reality directly creates systemic macro-level rot. The complete mathematical eradication of small fixes means that minor rough edges—a confusing warning in the build logs, a slightly suboptimal database query that doesn't yet trigger a latency alert, a deprecated API call that hasn't officially broken—are never corrected in passing. Over a three-year horizon, this unaddressed TechnicalDebt compounds. The log files fill up with thousands of lines of meaningless noise, making it impossible to debug an actual SEV-0 incident because the operational signal-to-noise ratio has been destroyed. The codebase inevitably turns into a tire fire.

If you ask an engineering director if they want a healthy, well-maintained codebase, they'll obviously tell you yes. But what leadership abstractly wants is irrelevant when you look at the raw mechanism design. By making the administrative overhead of a micro-fix mathematically ruinous, the system forces engineers to abandon the codebase's long-term health to satisfy the immediate demands of compliance theater. We're operating in a system where smart, perfectly rational actors will watch a codebase degrade in real time and do absolutely nothing about it, because the process explicitly penalizes them for trying. The market is just humans optimizing for the metrics they are judged on. If you construct a bureaucratic maze where doing the right thing takes an hour of administrative labor and delivers zero career advancement, the market will efficiently supply you with a rotting codebase wrapped in impeccably compliant paperwork.

Appendix: Preemptive responses to the inevitable HN comments claiming SOC2 doesn't actually require this

• "SOC2 doesn't mandate blocking PR approvals, your company just implemented it wrong." This is technically true and functionally irrelevant. The text of SOC2 is vague enough that you could theoretically satisfy the change-management controls via automated anomaly detection and post-hoc auditing. However, the external auditing firms that actually issue the certification want to see a paper trail they immediately understand, which in 99% of cases means toggling on Github branch protection rules and requiring manual sign-offs. Blaming the engineers for "implementing it wrong" when the auditors will fail them for implementing it creatively is a total misunderstanding of how the compliance market works.
• "Just batch your small fixes into your large feature PRs." If you do this, you are destroying the utility of git bisect and making rollbacks incredibly dangerous. When a feature PR introduces a regression, the on-call engineer has to revert the entire 2000 line commit, which now also reverts the three unrelated typo fixes and log formatting improvements you batched in to dodge the CI wait times. Tying unrelated state changes together to bypass a transaction cost is a textbook ops smell.
• "If a fix is really important, an engineer will take the 45 minutes to do it." This relies on the cocktail-party Econ 101 assumption that engineers have infinite time and zero competing priorities. They don't. They are operating on a strict complexity budget and a finite number of working hours, and every minute spent wrestling with a Jira-syncing Github action is a minute not spent on the core logic of the application. The minor fixes are, by definition, not "really important" in isolation, which is exactly why they are the first casualties of a system that makes maintenance expensive.