Shipping Code I Never Fully Read

For most of my 14 years as an engineer, writing code meant typing it. Then AI arrived, and at my previous company we started to use it. But the habit stayed the same. We read every line. Sometimes I stopped the agent in the middle and told it to go another way. When something got merged, at least one human had seen all of it, changed it, argued about it. The code was ours.

A few months ago I joined a new team. Here nobody writes code by hand. Never. The AI writes everything, and the team ships a lot. A normal pull request has between 1,000 and 3,000 changed lines. Nobody reads that with their eyes. It is simply not possible.

This post is about what that felt like, what I learned, and what I think we can do better.

The first weeks: the slowest person on the team

I did not change my habits at the start. I let the AI write, but I watched it write. I read the diff while it was being generated. I stopped it when it went in a wrong direction. I kept my pull requests small, 500 lines at most, because that was the most I could really understand.

The result was simple. I shipped one pull request per day. Sometimes two. My teammates shipped several a day, each one much bigger than mine.

I was the slowest person on the team. With 14 years of experience. That is not a nice feeling.

What actually hurts

Speed was not the real problem. The real problems came later.

Review becomes a ritual. When a PR has 2,500 changed lines, the review is not a review. You scroll, you look at the parts that look scary, you check that CI is green, you approve. Everybody knows this. Nobody says it.

Ownership disappears. If I did not write the code and I did not read the code, is it mine? When someone asks me why a function works the way it does, my honest answer is often "I don't know, let me ask the AI". That is a strange thing to say about code that has my name on the merge.

Bugs without a story. This one surprised me the most. We have bugs and we know they happen. We often do not know why. Nobody has the mental model of that part of the system anymore. So we give the stack trace to the AI, the AI finds something, fixes it, and we move on. Only AI can debug code that only AI understands. That is a dependency I never had before.

Slowly becoming one of them

After a couple of months, something changed in me. I started to do what the team does. My PRs became bigger. I started to approve my own generated code after reading only the parts that felt important. I still want to read everything. But I can't. And I cannot stay the slowest person on the team forever.

I want to be honest about this, because I think many engineers are in the same place right now. We are not choosing this way of working because we thought about it deeply. We are drifting into it because of pressure, because everyone around us does it, and because it works. Mostly.

What the research says

I went looking to see if this feeling is only mine. It is not.

The old code review research is very clear. In the big Cisco study by SmartBear, with around 2,500 reviews and 3.2 million lines of code, reviewers were most effective at 200 to 400 lines at a time. Above that, the number of defects found per line drops fast. That study is from 2006, and humans did not get better at reading since then. A 3,000 line PR is far past that limit.

Addy Osmani gave this problem a good name: comprehension debt. It is the gap between the code that exists and how much the team actually understands it. He also points to an Anthropic study where engineers who passively handed the work to AI scored 17% lower on comprehension than engineers without AI. But the engineers who used AI to ask questions and explore tradeoffs kept their understanding. So the tool is not the problem. The way we use it is.

Then there is the METR study from 2025. Sixteen experienced developers worked on real tasks in codebases they knew well. With AI they were 19% slower. But they believed they were about 20% faster. That one stayed with me. Our feeling of speed is not a measurement.

One more thing I see in our own code. When the AI changes behavior, it also happily updates the tests to match the new behavior. Green tests then do not mean the system is correct. They only mean the code agrees with itself.

Velocity is easy to see. Understanding is invisible until the day you need it.

What I learned

1. Lines of code are not the unit of review anymore. Intent is. I cannot review 3,000 lines. I can review a plan, a design decision, a data model, an API contract.
2. Being slow was not the mistake. Trying to keep the old process in a new world was. The goal should stay the same, a human understands what ships, but the way to reach it has to change.
3. Ownership is not about who typed it. It is about who can explain it, change it, and be on call for it. If nobody can, nobody owns it.
4. Debugging is a skill we are losing quietly. If we only debug through AI, one day we will not be able to do it at all.
5. The pressure to be fast is mostly social. Nobody asked me to ship more PRs. I compared myself to others and pushed myself.

How I move forward

These are my personal rules for now.

1. I review the plan before the code. Before the agent writes anything, I ask it for the approach, the files it will touch, and the tradeoffs. That is where I put most of my attention.
2. I read the core, not the whole. Domain logic, data model changes, migrations, security, and anything touching money or customer data, I read line by line. Generated boilerplate, glue code, and simple tests, I skim.
3. I ask the AI to explain, not to summarize. "Walk me through the data flow of this request" teaches me much more than "summarize this PR".
4. Once a week I debug one bug myself, without AI. Even if it is slower. Just to keep the muscle alive.
5. I accept that I will not be the fastest. I want to be the person who still understands the system. As code gets cheaper, that person becomes more valuable, not less.

What we can improve as a team

This is not only a personal problem. Here are the ideas I want to bring to my team.

1. Mark the important parts. A 3,000 line PR that is 2,600 lines of generated tests and types and 400 lines of real logic is fine, if the 400 lines are clearly marked. The agent should write a PR description that tells the reviewer where to look.
2. Stacked PRs. Let the AI produce many small, ordered changes instead of one big one. AI does not get tired of splitting work. Humans get tired of reading.
3. Plan review as a real step. Agree on the design in a short written plan before generation, and review that plan as seriously as we used to review code.
4. Protect the tests. Any change to an existing test expectation goes in a separate commit and gets a human look. Otherwise the tests stop being a safety net.
5. Guardrails in CI. Module boundaries, dependency rules, type checks, architecture tests. Let the machine check what humans cannot check at this volume.
6. Decision records. A short note in the repo for every non-obvious decision, written by the agent and confirmed by a human. Future us will need the why.
7. Measure the right things. Not only the number of PRs. Also how often we revert, how long a bug takes to understand, and how many incidents we could explain without AI.
8. Owners for every area. Every part of the system should have a human who can explain it. If nobody can, that is debt, and it goes on the board like any other debt.

Where I am today

I don't think the answer is to go back. The team ships things that would take much longer by hand, and that is real. But I also don't think the answer is to stop reading and hope for the best. Somewhere between "I read every line" and "I read nothing" there is a way of working where humans still own the system. I am trying to find it. Slower than my teammates, and a bit faster every week.

If you work like this too, I would love to hear how you handle review and ownership. I am sure I am not the only one who still feels a little guilty when I click approve.