We often figure things out just in time, like just-in-time compilation. If doing Z would require doing X and then doing Y, we don't necessarily figure out how to do both X and Y, and then check whether we'll be able to do both X and Y, and then prepare to do both X and Y, and only then actually do X and then Y. We'll often just start doing X, and in the process figure out whether and how we can do X, and prepare elements of doing X, and also start getting info about Y. This makes sense and eez gewd.

But here's one way this pattern can cause a problem: Say that, over and over, you think "maybe doing Z (X + Y) would be good here", so you keep trying X over and over, in order to build up to Z, because starting to do X is how you JIT-do Z. And you bang your head against X a bit, try a few more things, and then give up. Later, you sorta succeed at an MVP of X. ...But then you start doing Y and realize that Y is much harder than you thought it would be. Now your work on X might be wasted; you still can't get to Z.

So, maybe sometimes flip the JIT; skip to another part of Z and try that for a bit.

The JIT flip problem is an example of non-aggregation of desire--your different selves at different times who hold the Z supergoal don't communicate to each other that Y is a necessary subgoal with a lot of uncertainty around its feasibility, which should therefore be explored with fairly high priority to resolve some of the uncertainty. The JIT flip is related to overhauling key elements ASAP.