Do you still have this problem if you add a comment before declaring the variable like "Note: thingsById is not a dictionary, it is an array. Each index of the array represents a blabla id that maps to a thing"

In my experience they under overvalue var names, but they value comments even more. So I tend to calibrate these things with more detailed comments.

Can't you just write the code instead of the more detailed comments? What is the benefit of this approach?

Have you ever been vacuuming, and ran across a little thing on the floor that refuses to get picked up (a small piece of metal or whatever), and spent 5x more time trying to get the vacuum to work than it would have taken to just pick it up and throw it away?

And then eventually reach down and pick it up - to feed it to the vacuum?

That is what this reminds me of.

You can fix the code of course. I just experiment with what sort of comments produce better code. In my experience, heavily commented code is handled by LLMs significantly better. So the total quality of comments eventually add up, if you're planning to use an LLM in a project in the long term, it pays off to comment it for LLM's context.

Curious if you get better results with something like “thingsByIdx” or “thingsByIndex,” etc.?

Did you add the type annotation of it in code?

This is in Go, so both "yes" (it's defined with an explicit type in the file, sometimes the same func) and "yes but" (afaict next to no code-agent looks at type information that e.g. gopls has readily available, or even godoc).

I get what you're saying, but what's interesting to me is that this case is a mild signal that a subsequent developer could take the same erroneous implication. "Id" does in fact imply to me that entries are indexed by "Id", i.e., an attribute of the item being indexed, and that they are not array-like, in that they wouldn't all get different IDs by a deletion, for example.