Where should feedback loops be built into the development life cycle? What’s the right cadence for developers to get direct feedback on their code?

Feedback loops should maintain the right balance between asking for feedback and doing the actual work. Asking for feedback too frequently could slow down the actual work. On the flip side, asking for feedback too infrequently could result in an undesired business output potentially causing rework. 

Some guidelines on maintaining right balance are - 
1) Ask for feedback just before starting the work to make sure developers and business are on the same page. In other words, paraphrase what the business asked for
2) Ask for feedback after successfully completing the unit testing but just before releasing the feature to the integration testing environment
3) Ask for feedback just after completing the unit testing for any change orders requested by the business
4) Ask for feedback as soon as practical after becoming aware of any cross functional or cross project conflicts to make sure business is bought into what path to take, to resolve such conflicts

Read Gene Kim's "The Phoenix Project" to really understand the big picture here.  It's a quick fun read. You'll learn that before you focus on feedback loops, the first step is to get the work flowing by breaking it into small pieces.

It is very difficult to give a definitive answer to this, as I feel the answer is a function of a number of factors: Requirements volatility, project scale, Developer domain knowledge/ experience, delivery style (agile/ waterfall), requirement and validation lifecycle control etc. It also depends on whether we are talking directional feedback or validation feedback? If we assume a modular/ agile approach on a medium scale programme with relatively stable requirements where the developer has some previous exposure to the domain and the use of DevOps or similar: the directional feedback should be relatively short cycle but light touch, as it is more about ensuring consistent understanding of the requirement than assessing the code/ solution. So short cycle feedback on semantic and functional consistency is key, which then give the developer the free reign to code as they see fit (giving room for creativity) to that end. The validation feedback will then be less frequent due to the lower risk of divergence and more aligned to capability delivery milestone assurance. Where this tends to go wrong is people trying to to short cycle validation or doing the longer cycle validation without the short cycle lightweight directional feedback.  

The feedback loop can be implemented at the IDE level to share the feedback on the developing code during compile/runtime. However, an additional gateway could be at the code repository level when the particular feature or the pull request is raised. 

My suggestion is narrowly focused on vulnerability and software quality management and left shifting problem discovery and remediation through just-in-time feedback. Having developers use code and software composition/component analysis plug-ins in their IDEs is a great way of delivering immediate, interactive feedback. The plug-ins identify problems right when they are introduced and suggest ways to eliminate those. This is the least expensive place to catch and remediate those types of problems.