What is an example of how an application can anticipate user behavior?

Depending on what we mean...

A lot of applications have a happy path which is ideal if you are more familiar with it, and over-optimizing for brand new users might be problematic if it's repeat users who use it most.

So one way to anticipate the unique needs of new users without over-optimizing the whole application for new confused users is to design a state which is special for new users, but gets replaced once they are through the starter period.

I think this has to be done thoughtfully from a product/engineering perspective, to not create a hairy mess of different application paths, but there is a good happy place which can anticipate some varied needs and account for them.

Anyway, that's what comes to mind for me.

First off, I'm a non-developer, so please tell me if you think I got any of this wrong...

I'd argue that lazy loading is a performance strategy that tries to anticipate user behavior. From Mozilla:

Lazy loading is a strategy to identify resources as non-blocking (non-critical) and load these only when needed. It's a way to shorten the length of the critical rendering path, which translates into reduced page load times

Lazy loading can occur on different moments in the application, but it typically happens on some user interactions such as scrolling and navigation.

If you think about lazy loading in the context of "scrolling", the site anticipates that a user is going to land on the page and see the assets that are at the top of the page and so it loads these first, only after scrolling down does the site load these other assets.

What is an example of how an application can anticipate user behavior?

There are multiple ways to understand your question. Others have answered about things like pre-loading a likely user request. I will answer how you must be smart at understanding where the real pain points of your users are, and how you design your app around that projected user behavior.

I would say all applications try to anticipate user behavior. And definitely all applications should try to do it.

Exceptions are the ones that try to do everything for every possible use case, famous examples including Microsft Word, My Space, Sea Monkey, Emacs, $ git.
They inevitably end up having super confusing user workflows, but boy, they do check all the checkboxes.

Paul Buchheit, the original developer of Gmail, had a nice article a while ago

Copying the mistakes of a failed product isn't a great formula for success.

What's the right approach to new products?
Pick three key attributes or features, get those things very, very right, and then forget about everything else. Those three attributes define the fundamental essence and value of the product -- the rest is noise.
For example, the original iPod was: 1) small enough to fit in your pocket, 2) had enough storage to hold many hours of music and 3) easy to sync with your Mac. That's it -- no wireless, no ability to edit playlists on the device, no support for Ogg -- nothing but the essentials, well executed.

We took a similar approach when launching Gmail: 1) it was fast, 2) stored all of your email (back when 4MB quotas were the norm), and 3) had an innovative interface based on conversations and search. The secondary and tertiary features were minimal or absent.

Paul Buchheit - If your product is Great, it doesn't need to be Good.

Having to define those there attributes forces you to have a great understanding of your user needs, and to have discussions with them to discover them.

Exercise left to the readers: what are the three attributes define the fundamental essence and value of DEV?

There are techniques for preloading network requests when a user hovers over a link.

Infinite scroll loading gets more items to display as soon as the user reaches the bottom of the scroll area.

If you plug in your headphones, suggest the default music or book application.

I once helped a colleague of mine writing the code for a rather complex 2-level menu (I didn't like the idea at all, because I'm generally adverse to complex UI, but designers and management wanted it regardless) that had the ability to predict if a user would jump over to the second level or out of the current first level item based on mouse movement acceleration, which while not perfect, made the whole thing at least somewhat usable by preventing accidential switching.

Please, if you are a designer, don't try to replicate that. Even though it was mostly usable, it sucked to have such a lot of content hidden from view. Screen estate is cheap; use it wisely.

I'm not sure what you mean exactly but you can use Cypress for end-to-end testing. So that you can test and see how users would interact with your website.