How much of the feedback on a release actually needs to block it?

David Rasch looks for the checks his team can automate so nobody has to keep thinking about them. If an agent repeatedly makes the same mistake, a deterministic check can catch it before a person spends another review pointing it out. That leaves the person reviewing the work to decide what matters.

We talk about where to spend that judgment: the data model, changes to the interface, and the parts of a system that need careful design. Code may be easier to replace now, but someone still has to understand what the software is supposed to do.

David gives an example of an AI review getting caught up in a race condition for a task that runs about once a month. In that case, he decided the extra complexity wasn't worth it. I share an experiment where repeatedly responding to review feedback left my project unable to do anything at all.

The useful question is what needs fixing before this release, and what can become a separate ticket whose priority you decide later. A patient reviewer can always find more work. You still need a person who can decide when the work is worth doing.

Useful questions from the conversation

Which repeated review comments could become automatic checks?

Which parts of this change need someone to understand the design?

Does this issue need to stop the release, or can you decide its priority separately?

Chapters

00:00 When AI agrees with everything

00:12 Meet David Rasch

02:12 What you still need to understand

05:02 Data foundations before more code

10:00 Building and selling as an engineering education

14:42 Which parts need careful design?

19:12 Automating repeatable review checks

21:20 Code is easier to rework

22:31 When review becomes a loop

25:02 Human judgment and work worth doing

28:55 Where to find David

Find David: https://www.linkedin.com/in/rasch

Listen to Episode 36 of Build & Break Through: https://buildandbreakthrough.riverside.com/e/making-ai-useful-with-david-rasch