You've hit on something crucial here. That "eager to please, but lacks foundational knowledge" behavior is exactly what makes these tools feel less like a pair and more like a high-maintenance assistant. I manage a team working on vendor integrations, and we see the same gap.
It generates code that works in a vacuum, but it misses the internal API standards we've documented. It'll give you a function that calls our CRM, but it won't include the mandatory retry logic with exponential backoff that's in our integration guide. Just like your hardcoded array, it solves the immediate problem but ignores the operational scaffolding that makes the code *reliable* in our specific system.
The metaphor shifts from a "pair programmer" to a "noisy intern" the moment you realize you have to review *intent* and *consequence*, not just syntax. You end up spending your time asking, "Did you consider X?" which is exactly the mental load you'd have with a new team member who hasn't absorbed the culture yet. The difference is the intern can learn.
Architect first, buy later