jonny (good kind) on Nostr: i underexplained why that switcher is so bad: so there is this fallback condition ...

i underexplained why that switcher is so bad:

so there is this fallback condition where "if we don't know what the effort level should be, the default is high." Now that's not computed in a single place where one might expect it to, it's actually encoded in a dozen or two different places in different ways. The most common way that's encoded is by returning undefined with a comment that says "the API's default is high" (rather than actually returning a default value, which would ensure that what is displayed is always correct, but whatever).

however the LLM overgeneralizes here in an extremely funny way. Note that the possible menu values are hardcoded in the body of the function - so there is some possibility that the values that are displayed in the TUI are not the same as the ones hardcoded there. That's where the preposterous design of "passing the current string as well as left/right" (rather than, well, the normal way that forms always work) truly shines. Because "high is the default", if there current value is not in the hardcoded array... the default for the *current displayed value should be "high"*.

So it overgeneralized the default value being high as a fallback into "if we don't know what position in a list is currently highlighted, the current position is "high", so therefore if the user pressed left the current value should be "medium"." That's like saying "the zero point on my map is at 0 degrees latitude and 0 degrees longitude. I don't know where I am on the globe, but I was just told to go 10 degrees north, so therefore I am currently in Ghana."