I Don't Read the Code

On April 5th of this year, I merged 78 pull requests and 90 commits into CloudZero repositories. One Sunday. I have been writing software for most of my life, and on my best day as a young engineer (caffeinated, headphones on, deadline burning), I never came within an order of magnitude of that.

The part that still amazes me: I don’t read the code anymore.

I know how that sounds. Twenty-five years of my identity says it’s negligence. So instead of arguing about how it sounds, I pulled my own telemetry and looked at what happened: every commit and PR under my GitHub handle across the org, as captured by the internal stats system I built to study this very transition.

The data

Start with the embarrassing part. For all of 2025, the chart is flat. In November and December, two full months, I merged three pull requests. A dozen commits. That’s an honest picture of a CTO’s coding life: the day job is strategy, customers, board decks, and the occasional emergency, and hands-on building fits in the cracks. There’s one bump: twenty-six PRs in June 2025, a burst of early agent experiments, nearly all of them AI-flagged. Then it goes flat again. The tooling wasn’t ready, or I wasn’t. Whatever I believed about myself as a builder, the telemetry said occasional contributor.

Then the line goes vertical.

January: 18 PRs. February: 49. March: 199. April: 355. My rank among every human who opened a pull request at CloudZero that month tells the same story: 12th in January, 3rd in February, 2nd in March, then #1 in April and every month since. Same job, same meetings, same number of hours in the cracks. Thirty-three repositories touched instead of two, ops tooling and internal platforms and standards repos I’d never have had time to enter before.

The shape of the work says more than the volume:

As output exploded, the median change shrank: 438 lines in February, 138 in March, 67 in April. The median time from open to merge fell from 83 hours in November to two minutes in March, then under a minute at the April peak. That shape is the tell of a different process entirely: many small, complete, verified units of work flowing through a pipeline, each one scoped tightly enough to be checked by machinery rather than pondered by a human. High tempo, small batches, fast integration. The DORA playbook, taken to an extreme never intended for humans.

What I actually do now

The hours that used to go to reading and writing code now go to four things, in an order I chose deliberately: design, loops, goals, outcomes. Each one feeds the next: design decides what should exist, loops build it, goals aim them, outcomes prove it.

Design got the biggest share back. The scarce skill all along was deciding what should exist, where the boundaries go, what the system must never do. I spend more time on architecture now than at any point since my twenties, because it’s the part the machines still need me for, and because in an OODA world, orientation is the part of the loop that wins.

Loops are the engineering. Instead of writing the function, I build the loop that writes it: the harness of context, evals, tests, review passes, and cost visibility that lets an agent observe, orient, and act toward a goal without me in the middle. When the output is wrong, I fix the loop that produced it and let the re-run fix the output, the way a factory engineer fixes the line rather than the widget.

And the loops don’t stop at new code. Self-improving skills absorb the bug queue, the operational and SRE toil, and the refactoring no one ever has time for. Always running loops keep my codebases evolving and improving while my attention is on the next idea. Maintenance, the tax that has always eaten most of an engineer’s hours, moved into the loop; creation stayed with me. Every improvement compounds into every future run. That’s the whole thesis about retention, lived at the level of my Tuesday.

Goals replaced instructions. The unit of work I hand over stopped being “implement this function this way” and became “make this true, prove it, and stay under this budget.” Writing a goal that can’t be gamed is harder than writing the code, but I’ve found it to be 100x more rewarding.

Outcomes are what I read now. I read the test results, the eval scores, the behavior under load, the review-agent findings, the deploy health, the cost telemetry: the number in the loop. I verify the way an architect verifies a building: instrumented inspection and a walk of the finished floors, rather than a personal look at every weld. The welds get more scrutiny than I ever gave them personally (tests, review agents, gates on every PR I’ve merged this year), which is precisely why two-minute merges don’t frighten me. Reading source line-by-line stopped being how I know something works. Evidence took its place.

But what about security and compliance?

These are the two things that should have broken first, and they’re the first two questions I get. Both rest on the same assumption: that a person reads the diff and can make sense of it. At 78 merges in a day that assumption is arithmetically dead. No reviewer holds that queue in their head.

So I expected both to get harder. Then I looked at our data.

Our internal security testing and our third-party pen tests agree on something uncomfortable: undirected human review misses defects. Not because reviewers are careless, but in the same measurable way we’re bad at estimating how long something will take. We read the diff, we feel diligent, and the finding turns up later anyway.

The problem isn’t really review skill. It’s that we’re bad at review when nothing tells us where to look. Give a reviewer twenty changed files and no signal about which one is dangerous, and attention spreads itself evenly across things that are not equally risky.

So we stopped asking humans to read everything and wrote down a standard instead that we are now preparing to roll out company wide. Every repository will carry a risk tier, and the tier, not habit, decides how much human involvement a change needs. Three tiers, and the gate is never softer than this:

Tier 2’s automated path is a compound condition: the author owns every file they touched, every check is green, the review agent’s confidence is at our top rating, every comment is resolved, the diff is small enough that AI review is still reliable, and no security alerts are open. Miss one and a human owner reviews the code. Nothing merges in any tier until the checks pass and every comment is resolved, human in the loop or not.

Ratings come from machine-readable signals (deploy target, data classification, blast radius, infrastructure sensitivity, external exposure) and the highest one wins, with no averaging, because a repo that provisions IAM is high risk no matter how clean everything else looks. AI generates the rating, a human ratifies it, and it expires. Unrated repos and expired ratings get Tier 1 treatment until somebody ratifies them, because a stale rating is worse than no rating.

Two things make this a control rather than a vibe.

Segregation of duties survives. The approver is never the author. In the automated case the approver is an independent third-party review service, deliberately a different vendor from the tools writing the code, because a model grading its own homework isn’t a control. And the automation cannot cast an approval: bots are barred from approving pull requests across the org, so automated approval is expressed as a required status check that nobody bypasses, admins included.

We will measure whether it works. We are going to maintain a private suite of pull requests with deliberately seeded defects the reviewer has to catch that we will re-run quarterly and again whenever our service provider ships a new model or a new review tool. We will track escaped defects per tier, revert rates on AI-approved versus human-approved changes, and whether engineers are genuinely resolving review comments or just clearing them. If an AI reviewer is unavailable or detection rate slips, those affected repositories will revert to human review. Nothing merges unreviewed.

The result should be that most of our code ships without a human reading it, and the release train stays lean. The audit story gets stronger rather than weaker: consistent application of a control beats heroic effort every time, and this is consistent by construction: same rules, same gates, same evidence on every commit, all of it auditable.

But Erik, CC8.1 says all code must be human reviewed.

No, it doesn’t. CC8.1 names the steps a change must go through (authorized, tested, approved, implemented through a defined process); it never names the actor, and CC5.1 says in as many words to consider “both manual and automated controls.” What SOC 2 actually demands is authorization, testing, traceability, segregation of duties, monitoring, and human accountability. We kept all six. Every merge carries the same evidence package whether a person or the gate approved it; the who changes, the what doesn’t.

AI cannot be held accountable for anything, at least not yet, us humans still have a monopoly on accountability (sadly?). So accountability sits with named humans, but we will hold them accountable for their systems. Not their code, not their work. Their systems, including the automation they built and now rely on.

That reframing changes what human review is for. The review I still want humans doing is a review of the automation itself. Is it doing what we think it’s doing? If it failed, how would we know? Are the controls and audit logs in place such that you’d be comfortable being held accountable for whatever this thing does at three in the morning on a Sunday? A diff can’t answer any of that, and those are the questions that matter now.

Engineers need to understand that their job is on the line even when AI did all the work. That’s the trade: ownership is what you take on in exchange for no longer having to type.

Do that, and your auditors will be satisfied even though you no longer read the code.

Governance done right doesn’t stand in the way of creation. It removes what does.

How far, how fast

The same shift shows up across the whole company:

For all of 2025, under 5% of CloudZero’s pull requests carried detectable AI involvement. By April 2026: 44%. By July: 56%, a majority, and that’s a conservative detector, counting only explicit co-author trailers and known tool signatures. The true number is higher. The story runs bigger than one unusual CTO: in March, my 120 AI-flagged PRs were about 15% of the org’s 816. The whole engineering population is moving through the same door, some faster, some slower. This is the sorting Jensen Huang was warning about when everyone thought he was talking about compensation. The floor moved. NVIDIA said “100% of our engineers”; our telemetry says the middle of the adoption curve arrived in about ninety days.

Falling in love with creating, all over again

The charts can’t show this part.

I grieved a little, at first. Reading code was how I knew things. It was the craft I came up in, the way I earned my seat, and there’s a version of engineering pride that treats line-by-line comprehension as the last honest virtue. Letting go of it felt like the bricklayer letting go of the trowel.

But somewhere around February (you can see the exact month in the charts) the grief flipped into joy. Because the code, it turns out, was the cost all along. What I loved was the thing standing there afterward, working, that didn’t exist before. For twenty-five years the only path to the outcome ran through the material, so I loved the material the way you love a road that leads home. The road moved. Home didn’t.

Once the road moved, something came back that I didn’t know I’d lost. The maintenance tax (the bug queue, the pages, the refactors) now runs inside the loops, so the reclaimed hours go to the only work that ever felt like the point: new ideas, new features, experiments that would never have justified the typing they once cost. I’m creating more now than at any point in my career, and it feels the way it did at the beginning, before I knew what a backlog was. Creating is what I fell back in love with.

I used to fall asleep debugging. Now systems build while I sleep, and I wake up to outcomes: some wrong, most right, every one of them teaching the loop something I get to keep. My job is to want the right things, to design loops that can’t lie to me about whether we got them, and to own the result either way. That’s the part of engineering the typing was always in service of.

If this still sounds like negligence, I understand; it sounded that way to me in January. So don’t argue with how it sounds. Do what I did: pull your telemetry, find the flat line, and build one loop for one workflow, with a goal that can’t be gamed. Give it ninety days, the time the middle of the adoption curve took to reach our whole company. Your chart will tell you the truth mine told me, and then you’ll face the only question that matters: now that the typing is no longer the price, what will you create?

I don’t read the code. I read what the code did, and I ask if it’s true.

I’ve never felt more like an engineer.