DOP 334: If Code Is the Easy Part, What Should Developers Actually Be Doing?

Episode 334

Show Notes

#334: The debate over whether AI saves developers time misses a fundamental truth: coding was never the hardest part of software development. Writing code is mechanical work - the real challenges have always been understanding problems, designing solutions, communicating with stakeholders, and navigating organizational complexity. AI is now forcing a reckoning with this reality, pushing developers at every level to reconsider what skills actually matter.

The traditional separation between architects who design and developers who implement is breaking down. AI enables a return to something like pair programming, where the person thinking through problems can now work alongside a fast executor without the old bottleneck of slow human typing. This shift means developers need stronger communication skills - the ability to explain technical decisions to non-technical stakeholders and translate business requirements into technical direction. For juniors, the opportunity is unprecedented: you can upskill faster than ever in the history of software, but only if you balance building things with actually understanding how they work.

Darin and Viktor explore what this means for developers at every career stage, from juniors who should focus on fundamentals and end-to-end understanding, to seniors who are becoming more like editors and supervisors of AI-generated work. The developers who will thrive are those who combine real experience with a willingness to embrace change - and that combination has always been the winning formula.

Frequently Asked Questions

Is writing code the hardest part of software development?

Viktor Farcic argues on DevOps Paradox episode 334 that typing code is the easiest part and he does not understand the fuss about it. His comparison is the technical books he has written: once the subject is understood, the chapters planned and the scripts validated across operating systems, the actual writing was almost mechanical. Everything around the code, deciding what to build and why, is where the difficulty sits.

Why does AI make pair programming between an architect and a developer practical?

Viktor Farcic explains on DevOps Paradox episode 334 that the pairing was always desirable and never possible, because one architect serves ten, twenty or more people writing code. You cannot pair one to many. If the person producing code becomes much faster, the ratio changes and the architect can think about the next step while the current one is being built, then validate it in short iterations.

Should you still refactor code that AI wrote?

Viktor Farcic questions the assumption on DevOps Paradox episode 334. Cleaning up code exists mostly so humans can navigate it, and that trade-off has two sides: avoiding repetition often means one central function carrying conditionals for a hundred callers, where most of the code serves nobody in particular. He suggests two hundred self-contained lines can be easier to understand than twenty lines spread across five libraries.

What skills do developers need to work effectively with AI?

Viktor Farcic names two on DevOps Paradox episode 334. The first is accepting that the work changes rather than assuming you will do the same thing slightly differently, the same reset that moving from Java to Rust demands. The second is communication, which he says many engineers avoided the profession to escape. His test is whether you could explain what you are about to do to a technical CEO.

How do code reviews change when AI writes the code?

Viktor Farcic tells Darin Pope on DevOps Paradox episode 334 that it depends on who opened the pull request. Reviewing his own work, he wants the tool to find correlations he missed. Reviewing someone else’s, the tool can approve code that is technically fine and heading the wrong way entirely: it confirms you have arrived in Paris without knowing the destination was London.

What should junior developers focus on now?

Viktor Farcic advises on DevOps Paradox episode 334 that juniors balance building things with stopping to understand them, since neither theory nor practice alone gets you there. His concern is that the pressure to look productive every hour crowds out learning, at a moment when upskilling is faster than at any point in the history of software. His half-serious suggestion is joining a company that rejects AI and learning quietly.

What is the DevOps Paradox podcast?

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 334 is a conversation between the two hosts about what developers do when writing code stops being the bottleneck, covering architecture, code review, communication, and advice by career stage. Every episode page carries the audio, the video, and a full transcript.

Episode Transcript

Read the Full Transcript

Topics

Share and Download

Hosts

Darin Pope

Darin Pope

Viktor Farcic

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.