The issue is that you lack experience. And the only solution is years of practice. Same as any other skill.

Do you think you could study music theory for five months and then compose at the level of Beethoven? Study art theory for a few months and paint at the level of Michelangelo? Study business theory and run a large corporation competitively?

Of course not!

The AIs are drawing on a huge body of reference material created by people with decades of experience. Even if their results are distinctly lacking compared to a really good programmer, and potentially fundamentally flawed in ways that can really bite you in the ass, they're still going to blow the socks off of any beginner.

And you'll be a beginner for many years - there are no shortcuts to getting good. Even incredibly gifted beginners take years before they start composing code that a professional would be willing to take credit for.

So don't try to measure yourself against experts when you're just starting out.

Oh and:

Strangely, the method names I came up with actually helped a bit.

There's absolutely nothing strange about that. Choosing good, descriptive method (and variable!) names has long been accepted as one of the single biggest things you can do to make your code easier to understand. Name your methods to describe what exactly they're doing (usually a phrase of several words), and your variables to express the context and expectations of the data they hold (usually 2-3 words) and it will be much easier to keep track of what exactly things are doing.

With a good naming convention and short lines of code, the code will usually read almost like a sentence describing exactly what it's doing. Which leaves your comments free to explain WHY you're doing it. And as a rule of thumb, make sure to write at least one line of concise, high-level descriptive comment for every few lines of code.

Think of comments as street signs for your code - when you want to change something in code you haven't looked at in a while, you don't want to have to slog through all the code to find the spot that needs changing - it's much easier if you can just skim through the comments to quickly get to the right general area.

As a beginner it can even be helpful to write the comments BEFORE you write the code: e.g. when composing a function start with the comments giving a high-level breakdown of the steps you'll need to go through to accomplish the task, and only once you're sure you've got all the basic steps in place do you go back and fill in all the code that does the work between them. E.g. as a simple dumb example with terrible variable names:

// the previous process finishes with the values of num1 and num2 reversed.  Swap them.
temp = num1
num1 = num2
num2 = temp

Sure, it's pretty obvious with only a moments thought WHAT the code is doing - but you'd have to read the entire previous section to figure out WHY it needs to be done. And it might not be obvious.

The corollary is that it's VERY important to keep your comments up to date whenever you change the code, which is greatly helped by keeping them high level enough that it takes major changes to make them wrong. The "WHY" is also generally a lot less likely to change than the "WHAT", so that helps too.

Detailed "WHAT" comments are really only necessary when doing something cryptic. Which can occasionally yield dramatic performance improvements, but as a rule is just a sign that you're trying to do too much at once.