I've had the opposite experience so far, though I've admittedly not used it that much yet. I've got this Python fiscal date library at work, and I wanted to add

I've had the opposite experience so far, though I've admittedly not used it that much yet. I've got this Python fiscal date library at work, and I wanted to add a something like a `strtftime()` method which would replace $P with the period, $Q with the quarter, etc, but treat $$ as a literal $ (so that e.g. $$P would result in $P). Simple enough, but I thought it would be cute to see if I could get copilot to do it for me. I spent at least a half hour trying to figure out what kind of prompt would result in a correct implementation. No matter how explicit I was it kept giving answers that failed to handle the $$P -> $P conversion correctly. Finally I was able to get it to spit out an answer that at least had the right idea, but it had an unrelated bug in it. The package also has some functions to determine holidays, and I was impressed that Copilot could generate code for new holidays that mimicked my style, docstrings and all. But disappointingly it failed for any slightly obscure holiday (say, Eid al-Fitr), generating code that was just wrong, even when I hinted that it would have to use an alternative calendar library. It kept trying to use the Hebrew calendar for Islamic and Hindu holidays, I guess because I'd already imported it for Hanukkah. It also seems useless for Spark ETL, having to be handheld to a degree that it would be easier just to write the code myself. My first attempt to play around with Copilot was to see if it could do a salted join (no luck, unless by "salted join" I meant something like "a join on a column called salt"). I'll keep playing around with it, maybe it's just a "me" problem.