DOP 355: Why AI Coding Slows Down Code Review
Show Notes
#355: Picture your engineering team a year from now. A coding agent doing the coding. A testing agent on tests. A security agent on security. An infrastructure agent on infrastructure. All of them wired into GitHub and Jira, all of them working right alongside the humans. Not science fiction either - Atlassian and GitHub are already shipping these features.
So out come the stats everyone loves to quote. AI code introduces 1.7 times more issues. Half of it ships with security holes. Code duplication is through the roof. AI-assisted PRs take four to five times longer to review. The response to most of it: so what? If you have a way to detect the issue and feed it back, that is just the SDLC doing its job. Couldn’t care less if it is 1.7x or 50x more issues - what matters is what is left at the end, per feature shipped. Security holes? You have scanners. Detect, fix, ship. The only real problem is when you skip the detection or sit on the fix for months, and that has nothing to do with AI.
Here is the one stat that actually sticks: PR reviews backing up. Speed up coding and leave everything downstream at human speed, and you have not sped up delivery - you have just moved the pile from Jira tickets to pull requests. The review pipeline was built for human speed, and now it is the bottleneck. The blunt fix: stop letting AI write 10,000-line PRs, work in smaller chunks, and accept that the job is about to get mentally harder. Delegate the tedious work and what is left is the demanding work - architecture, taste, is this even the feature we should ship. The silly stuff, does every function have a comment, is it camel case, goes to the machine. Spend your time there and you are wasting your talent.
Offshoring never worked when the only goal was cheaper - chase the cheapest engineers, then chase even cheaper ones, and you end up dragging the work back in house. Same trap with AI. Offshore to Opus, then Sonnet, then Haiku, then Llama on a laptop. If cheaper is your primary motivation, you are doing it wrong. The win is qualitative, not the price tag. Where does it land? Three people per product, end to end - frontend, backend, database, deployments. Augmented at every stage, not autonomous. A human still pushes the final button to prod, the way you never let a Jenkins pipeline deploy straight to production without a check. Full autonomy is coming the way self-driving cars came: not in a year, not everywhere at once, and not by flipping it on at 4pm on a Friday. Even when the technology is ready, you are not. And if you think none of this touches your job, there is a story here about a textile factory built in the eighties that ran on five people. Knowledge work is next. The only exception is a monopoly, and you probably do not have one.
Episode Transcript
Share and Download
Hosts
Viktor Farcic
Viktor Farcic is a member of the Google Developer Experts and Docker Captains groups, and published author.
His big passions are DevOps, Containers, Kubernetes, Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-Driven Development (TDD).
He often speaks at community gatherings and conferences.
He has published DevOps Paradox and Test-Driven Java Development.
His random thoughts and tutorials can be found in his blog The DevOps Toolkit.