You seem confused about a few things.
AES on the other hand tells me I gave it the wrong key
No it doesn't. There are ways to do this in combination with AES, ranging from the simple but weak (padding schemes that function as a basic checksum, including an actual checksum somewhere) to strong (encrypt-and-mac, authenticated encryption modes, etc.). However, all of them attach other operations to the AES primitive. AES itself has absolutely no support for detecting key mismatch; any AES key can be used to encrypt, or decrypt, any message of the correct length (exactly 128 bits, because pure AES doesn't even include ECB so it can't handle multiple blocks, much less partial ones).
I can just switch using another key without having to worry about if the decrypted message using a key that's not the original key was the original message
In general, even schemes like the ones I mentioned above (padding or MACs or authenticated encryption) require fully decrypting the message before you can tell whether or not the key was correct. There's also no way to distinguish between "the key was incorrect" and "the ciphertext was tampered with", without some additional out-of-band data. Used correctly, cryptography can tell you if a message is authentic, but it generally can't tell you why or even really how a message is corrupted (where "decrypted with the wrong key" will definitely corrupt a message). A cryptographically secure hash of the key can be included with the message, such that the correctness of the key can be validated quickly, but this does in fact weaken security in numerous ways. (Making it faster to brute-force search the key space, and because any pre-image attacks on the hash function could be used to aid in recovering the key, but also, it becomes trivial to determine if two messages were encrypted with the same key. That last vulnerability can be mitigated in various ways, such as by including the IV and/or part of the ciphertext with the key when hashing.) NONE of this has anything to do with AES per se, though; you could (shouldn't, but could) do exactly the same with a one-time pad.
If your worry is that the message is decrypted incorrectly in a subtle way, well, that is once again what cryptographic integrity / authenticity checks are for. With that said, except in modes of operation that make AES behave as a stream cipher, it's not generally possible to make very subtle changes. There are exceptions (such as the first block of CBC), but in most cases tampering with a ciphertext (or using the wrong key) will result in one completely scrambled (random-seeming) block in the plaintext, or the entire message being scrambled in that way, respectively. Unless your recipient has no idea what the expected structure of the data is, it's often possible to detect such corruption if you look for it. I assume that's what you mean by "rubbish that's distinguishable by ChatGPT", but bear in mind that encrypted data is not necessarily text, and even if it is text it's not necessarily encoded as you expect.
So now I am just guessing 256bit instead of however long OTP is
On a technical level, this is one way in which OTPs are generally more secure than more advanced ciphers: unless the message is less than the key length, correctly deciphering the entire message requires brute forcing a larger keyspace. Of course, brute-forcing any encryption key even close to 256 bits is utterly impossible in practice with current computing hardware - if you put every processor on the planet to work doing nothing else, the heat death of the universe would still happen long before you finished - but there is a theoretical difference in strength nonetheless.
On the other hand, there is a weakness of OTPs here too. Suppose you know 1/4 of my AES key - 64 of 256 bits - and want to brute force the rest (192 bits). That's still practically impossible with modern compute hardware, and as such, your quarter of the key is worthless unless somebody else has another fragment. With a one-time pad, though, if you have a quarter of the pad, you can perfectly decrypt one quarter of the corresponding message. There are ways to safely split a one-time pad between parties such that no individual can use it at all, but doing it by length doesn't work (of course, splitting a key by length is a terrible idea with AES too; the same methods available for a one-time pad work at least as well with AES keys).
Anyhow, to actually answer your question, it's generally straightforward to mathematically prove that one-time pads are stronger than AES if both are used correctly; it's impossible even in theory to tell whether a candidate one-time pad is correct, whereas with AES you can in theory perform cryptanalysis or just brute-force the (almost certainly shorter than the message/one-time-pad) key. Even without any way to directly detect if the key was correct or not, there are fewer possibilities to narrow down. In practice the difference is immaterial though, due to how ludicrously impractical to brute-force even 128-bit AES keys are (and the lack of known cryptographic "breaks" for AES, even though we can't prove they don't exist the way we can for one-time pads). Since the non-security advantages of AES (and other bulk data ciphers) vs. one-time pads are tremendous, almost everything uses AES (or other modern symmetric ciphers) and effectively nothing uses one-time pads.
