Making AI Useful with David Rasch
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
- Transcript