Why does my clock drift a few minutes every day?

That slow drift is normal, and yes, you need to fetch the time yourself. The Pico W has no real-time clock with internet sync built in. It has an internal clock that runs off a cheap oscillator, and those are never accurate. A couple minutes over a day or two is completely typical. The wifi connection doesn't sync time automatically either, that only happens if your code asks a server for it. The thing you saw while googling is probably NTP, which just means asking a time server on the internet what time it is. If your code is in MicroPython, the easy way is ntptime. One import and one call to ntptime.settime() and the Pico sets its clock from the internet. Do that once when it boots and then every so often after that, like once an hour or once a day. If your code is in CircuitPython there's a similar thing built into the wifi library, something like pool.get_ntp_time.

One gotcha: NTP gives you UTC, so if your clock shows the wrong hour but stays accurate after syncing, you need to add your timezone offset in code. That trips up almost everyone the first time. Also worth checking wheather your code even sets the time at boot right now. Some AI-written examples just set a fixed date or let the clock start from zero and never sync, which would explain why it drifts and why resetting fixes it until it drifts again. And no, nobody resets their clock every few days once it's set up properly. Once the sync is in there it just quietly corrects itself and you never think about it again. It's a five line change at most depending on the library, so it's a nice gentle way to start poking at the code yourself instead of letting the AI do all of it.

Adding to the ntptime advice, put the sync call in a try/except or wrap it in a check for wifi being up first. Mine woud crash on boot half the time beacuse it tried to sync before the wifi actually connected, and I spent ages wondering why the display was blank every second reboot. Also once you've got this working, watch what happens around daylight saving. My clock was perfect for months then jumped an hour in spring and I had no idea why til I remembered I was just adding a fixed offset to UTC.

I'd push back a bit on the 'five line change' estimate. Sure, the raw sync call is tiny, but then you need the timezone math, a check that wifi is actually up, and some way to retry when the server doesn't answer. By the time it survives a router reboot it's more like twenty lines for a beginner, which is still very doable but nobody should feel dumb if it takes an evening.

Also, syncing once a day always struck me as stingy. The call costs basicly nothing, so I just sync every fifteen minutes on mine and the drift never gets a chance to build up at all.

This thread is making me feel better about my own setup. I've got a little display showing the temperture from a sensor outside, and I let the AI write all that code too. I did the same thing you did at first, just rebooting the thing whenever it acted up, and never actually opened the file to see what was going on. What finally helped me was pasting the code back into the chat and asking it to explain it line by line like I was five. Sounds silly but I learned more doing that than from any tutorial.

One question for you though, since mine runs off a power bank: does syncing from the internet every hour eat much battery? Wondering if I should sync less often.