When I coach teams on bringing AI into their engineering, I like to run a thought experiment. Imagine I join your team tomorrow as a senior engineer. I am good, I am fast, and at the end of my first day I open a pull request with 3,000 lines of code.
The first answer I usually get is, “We have a rule that blocks any PR over 300 lines.” Fine, I say. Then I opened ten of them. Now what?
It was never about the lines
We all know that counting lines of code is a poor measure of engineering. That is not the point of the exercise. The point is velocity, and what your team does when it meets velocity it was never built to handle. Ten clean, well-scoped pull requests in a day is not a problem of style. It is a problem of validation. There is real business value sitting in that work, and you do not want to throw it away. But you cannot merge what you cannot trust. So how do you react?
For most teams, the honest answer is that their process quietly assumes a human can keep up by reading everything. Strip that assumption away and the cracks show. Review becomes a rubber stamp, or a bottleneck, and often both.
This is no longer hypothetical
I used to run this purely as a hypothetical. It is not hypothetical anymore. Agentic programming, where AI agents write, refactor, and review code under direction, makes a day like that not just possible but ordinary. The volume the thought experiment describes is now a normal Tuesday for teams working this way. The question is no longer whether your team will face it, but whether you will be ready when it does. It also breaks most of the ways we used to measure velocity, which is a related problem worth its own attention.
Shift the work left: the plan is the product
The answer has two halves, and the first is to move your most valuable thinking earlier. When code was the expensive part, it made sense to spend your judgment there. Now that producing code is cheap, your judgment is better spent on the spec and the plan. A clear, well-reasoned plan is something a human can actually review with care, and it is where you catch the expensive mistakes while they are still cheap to fix.
I have come to treat the specification as the most important product the team makes. Get that right, and a great deal of the downstream review takes care of itself, because you already agreed on what good looks like before a line was written.
Guard the work on the right: let the machines check the machines
The second half is to build strong automated guards on the other end. If a human cannot personally read every line, then your continuous integration has to be the thing that does. Comprehensive automated tests, type checks, linting, dependency and secret scanning, and real quality gates stop being nice to have. They are what makes high volume safe. The machine checks the machine’s output, and a change does not merge until it clears the bar. That is what lets you accept the velocity instead of fearing it.
What is left for the human
None of this removes the human. It relocates them. Review stops being a line-by-line slog and becomes a question of intent and outcome. Did this do what the plan said it would. Does it clear the gates. The way I run my own teams, the work is directed, reviewed, and gated: senior judgment concentrated at the front, where the plan is set, and at the end, where the guards live. The middle, the typing, is where the leverage of agents actually shows up.
That is the real lesson of the 3,000-line day. The bottleneck was never the keyboard. It was always your ability to decide what to build and to trust what came back. Agentic programming just made that impossible to ignore.
Helping teams reshape their process around this, more investment in the spec, stronger automated guards, and a clearer role for human judgment, is a growing part of what I do as a fractional CTO with Artificer Innovations. If your team is feeling the gap between how fast it can now produce code and how fast it can safely ship it, let’s talk.