This is especially true when it comes to reinforcement learning: what people should take away from the bloodstained guides written by past RL programmers, it is

This is especially true when it comes to reinforcement learning: what people should take away from the bloodstained guides written by past RL programmers, it is one thing at a time: https://andyljones.com/posts/rl-debugging.html https://andyljones.com/posts/rl-debugging.html https://clemenswinter.com/2021/03/24/my-reinforcement-learning-learnings/ https://clemenswinter.com/2021/03/24/my-reinforcement-learni... https://blog.nelhage.com/post/systems-that-defy-understanding/ https://blog.nelhage.com/post/systems-that-defy-understandin... Never make multiple changes. Test every case where you have a known answer or oracle, and start with the simplest possible case - because it'll be broken anyway. Log the heck out of everything. Make sure you can visualize the agent's state and inputs. Start with the simplest possible agents like a hardwired sequence of actions and only gradually ramp up the complexity etc. Know your domain very well, so you don't have surprises like the Nethack DRL dev recently discovering a bizarre performance regression was caused by the phase of the moon during testing runs vs training data. etc Jumping in to a complex proprietary video game stack where this purpose is totally unsupported and wanting to apply fancy DRL is a recipe for suffering, and for Heisenbugs, and for interactions, and papercuts.