Reading the title, my mind conjured what I consider to be the utopia of debugging: a probabilistic assessment of likely failure points across the entire stack,

Reading the title, my mind conjured what I consider to be the utopia of debugging: a probabilistic assessment of likely failure points across the entire stack, backed by reasoning over the relationships between the components. From there, generate a prioritized actionable debugging task list. An example might be "test input X on function Y so we can rule out Z". (Aside: The "so we can" part is the key to focusing the effort, otherwise debugging can turn into a technical-debt paydown-party. There is a time and place for that, but maybe not while your service grinds to a halt for unknown reasons.) Therefore, you can imagine why reading the article was extremely disappointing. No offense, JetBrains; this is still probably pretty good. Certainly a step in the right direction. And it is predictive debugging on a local scale. Context: I guess you could say I'm a harsh critic of the comically inane ways that debugging often happens. Often debugging happens at the worst time: when a person's cognitive capabilities are drained and stress is maximum. This is not the set of conditions we want. Debugging is quite different than designing. Mental flexibility and triage is key.