AI coding turned a 40-year developer into a reviewer

AI coding can save implementation time while making a developer’s day harder. Chad Cox, a 40+ year programmer and CTO of VoiceGrid.ai, reports that AI now writes most of the code in his work. He can build and maintain multiple products, but his daily job increasingly involves reading, questioning, and correcting generated changes.
Cox’s background makes the shift more striking. He began programming by plotting turkeys on an Apple IIe, back when software moved on floppy disks. His book, How Years of Programming Led Me to Stop Coding (Probably Forever), describes his transition from hands-on coder to a conductor of AI teams.

What did AI make faster?

The immediate gain is straightforward: less time manually producing every implementation detail and more capacity to work across several products. For an organization rolling out AI coding, that can change the apparent size of its development team without requiring a larger number of staff.
But generated code is only the first stage of finished work. Every proposal still has to be understood, tested, corrected, and integrated. A team measuring only how quickly AI produces a patch will miss the work created when that patch is incomplete, unsafe, or inconsistent with the existing system.
The useful measure is the full cycle from request to accepted change. That includes prompt time, generation, review, corrections, repeated attempts, and testing—not merely the amount of code produced.

Why is reviewing different work?

Reviewing AI output requires constant active judgment. The reviewer has to question assumptions, trace unfamiliar behavior, and decide whether an apparently neat solution actually belongs in the codebase. That produces a different kind of mental fatigue from writing every line yourself.
This is where an AI rollout can fail: implementation appears faster while the review and correction queue grows. More drafts do not create more value if senior developers spend the day reconstructing the reasoning behind them.
There is also a trust problem. Experienced programmers may recognize insecure patterns or unnecessary complexity quickly, but speed can encourage them to approve plausible work before they fully understand it. AI fluency does not remove the need for engineering judgment; it moves that judgment into a more consequential place.

What should a team do when reviewing becomes the bottleneck?

When review time starts dominating, a company should change the workflow rather than simply generate more code.
A sensible rollout begins with a clear merge requirement. The developer submitting the change must be able to explain its behavior and why it fits the system, whether they wrote it or generated it. If that explanation cannot be produced, the change is not ready to merge, regardless of how polished it looks.
Teams must keep one named human owner for each change. AI can draft the implementation, but it cannot own the production consequence, answer operational questions, or take responsibility for a regression. The submitting developer still has to inspect the full diff, run the relevant tests, and check edge cases and security implications.
Measuring the entire cycle provides another safeguard. Teams should record where time actually goes instead of rewarding large volumes of generated code. If creating the first draft takes minutes while understanding and repairing it takes hours, the rollout has changed the bottleneck rather than removed it.

Can the satisfaction of coding survive?

The answer depends on whether the developer’s role expands beyond reviewing output. “Conductor” is a useful description because it implies more than pressing generate and accepting the result. The developer still sets the architecture, defines constraints, breaks down difficult problems, evaluates competing approaches, and owns the final design.
That preserves the part of programming that creates satisfaction: solving a hard problem and understanding why the solution works. It gives up the satisfaction of typing every line, but it does not require giving up ownership of the system.
The goal should not be preserving manual code production at all costs. It should be ensuring that faster generation produces work the team can still understand, maintain, and trust.