Why AI endurance coaches can get training volume wrong

What happens when you let a frontier model set load targets

Luke Forward · 5 min read

Luke Forward riding the individual pursuit qualifying at the UCI Masters Track World Championships

We’ve helped design and build Zepho, an LLM endurance coaching app. But I’m also a keen track cyclist and I’m very happy to be a guinea pig for product testing. Here’s how I got on with my preparation for the UCI world track masters…

I went into October’s racing on a pursuit-specific, anaerobic-heavy training block prescribed by two AI coaches. I used the race and the build up to the race as an opportunity to stress test Zepho and Strava’s MCP server using Claude. About 12 weeks before the race I gave Zepho and Claude all my relevant context. Both knew what I was training for and how much time I had, and both gave me a specific, periodised, sensible-looking plan.

Twelve weeks later, after following a plan that was somewhere between the two options, my one-minute power went up marginally. My three-minute power, the thing that decides a pursuit, dropped a little. My repeatability collapsed (not critical for the individual pursuit but still interesting). Both AI coaches focussed too much on specificity at the expense of core aerobic volume.

So what went wrong? Why do LLMs seemingly struggle with aerobic load progression? And what can we do about it?

The case study

I’m a sample size of one, so treat this as a worked example rather than evidence. But on the plus side, I had two six-week blocks in the same season, for the same events, with every ride recorded.

Before the Nationals in June my training was fairly unstructured: track league every week (a natural VO2 max hit), a decent amount of solid aerobic sessions (threshold and sweetspot) most weekends, general endurance in between. Contrast that to the run up to the Masters Worlds in October where I did the most structured block I’ve ever done, built around short, hard intervals specifically for the pursuit and Kilo.

Six weeks before

Nationals (Jun)

Worlds (Oct)

Hours per week

6.9

6.2

Training stress (TSS) per week

TSS is a measure of physiological cost, normalised and relative to you

344

279

Threshold / sweet-spot sessions

4

0

Typical interval session

4 x 5 min at 330W

3 or 4 x 2 min at 400W+

Fitness (CTL) on race day

CTL is an average daily TSS of your last 6 weeks, 42 days with an exponential decay

about 50

about 40

The hours dropped a little. Training stress dropped by a fifth, and all by dropping quality aerobic work. The intervals in the Worlds block were harder per minute but far shorter, so a session that felt brutal was worth about half the training load of an unglamorous hour at Tempo or Sweet Spot.

The outcome: My kilo time was identical, pursuit five to ten seconds slower, and a scratch race a long way off my best (although that was never the focus). The specific work did some of what it was supposed to, but the cost wasn’t worth it. I lost too much of my aerobic base, and for a rider with a naturally fast-twitch profile and a thin aerobic floor, that’s a bad deal. After looking at my history in detail, it seems my anaerobic power barely moves whatever I do but my aerobic base disappears the moment I stop training it.

What went wrong?

It would be easy to conclude that LLMs are bad at coaching. But they aren’t. The session design was good. The taper was in some ways textbook (although the text books are for elite athletes doing 20+ hours a week and I’d argue for most people tapers are way too generous).

A common framing mistake. I told the models I had around six hours a week. Both treated that as a hard boundary and tried to optimise inside it. What I got was a pretty decent six-hour plan with a very generous taper. But what I needed was the answer a good human coach would have given: “six hours isn’t enough for a pursuit at this level, now’s the time to dig in, so let’s do this.” Neither model pushed me. Neither ever challenged the constraint. Looking back over a year of AI-generated plans, I don’t think either plans prescribed enough volume and I have a sneaking suspicion that this is because the frontier models bake in guardrails and are intentionally conservative.

So what you get if you’re not careful is a coach who is overly polite about volume. It won’t tell you that you’re not doing enough, often because you set the constraint and it’s not going to argue with you.

In retrospect, “build the aerobic base first, then add the specific work” is endurance coaching 101. It’s in every textbook the models were trained on. But that message gets lost when the whole conversation is framed around optimising the time you have, and an LLM will happily have that conversation with you for as long as you like.

Why this happens

I don’t have an inside view of how these models were trained, so this is informed guesswork, but the shape of the bias is easy to explain.

The training data is dominated by advice aimed at the over-enthusiastic beginner: listen to your body, rest is where adaptation happens, more isn’t always better. That’s good advice for most people asking a chatbot about running. It’s the wrong message for a Masters athlete with a target eight weeks out. That’s exactly the time to dig in and get the work done.

Then there’s the tuning. Models are rewarded for answers that are helpful and safe. The response that adds a rest day can’t hurt anyone. The response that says “you need to find three more hours a week” might. Nobody sues a coach for prescribing recovery. So every nudge in the feedback loop pushes the same way, and you end up with a coach whose default is to under-prescribe and over-explain.

This isn’t specific to sport. Any product that uses an LLM to prescribe a quantity under a user-stated constraint will hit it: dosing, budgets, study hours, capacity planning. The model will give you the best answer inside your box and will rarely tell you the box is wrong.

Takeaways for anyone building an LLM advisor

  • Watch for the constraint you handed it. If a user states a limit, the model will optimise inside it and will almost never push back. If the right answer might be “your limit is wrong”, you have to design for that explicitly.

  • Assume the errors have a direction. LLM mistakes under uncertainty are not random. They lean towards the safe, the moderate and the inoffensive. Work out which way “safe” points in your domain and check whether that’s actually the lower-risk side.

  • Don’t let the model decide quantities it can calculate. If there’s an established formula, use it. The model’s role is to use judgement, explain and adapt, not to guess a number obscured behind a complex formula.

  • Don’t make assumptions; and eval-test everything. LLMs are amazing at giving the perception of quality. Don’t ever take that at face value. Define what good looks like and run the tests, it’s the only way to validate quality beyond surface level competence.

What next?

The plan I’m now following, from October to December, looks nothing like the previous plans. I’m going back to basics, quality aerobic work and volume first, then build on that. More time, more volume, taking my fitness from a CTL of about 40 to 60 by mid December. Which is still actually pretty conservative, yet it’s 50% more riding than the Worlds block.

My new plan was still produced by an LLM. The main difference is that the model didn’t set the load targets. Instead I gave it a sustainable target that I know works for me (build to a CTL 55 by mid December), and a deterministic model of how training load accumulates (the standard CTL and ATL calculation – forty-year-old arithmetic). The maths says what weekly load was needed to hit the target, the model’s job is now to schedule that load across the days I have, explaining it, and adapting as I go.

We keep learning similar lessons across LLM products. When implementing LLMs into your product a hybrid approach works best, deterministic calculations should be deterministic and the model should be given the tasks that require nuance, judgment, language and context.

This approach is a design change as much as a modelling one. Here it means the product sometimes has to tell people something they didn’t ask to hear, and the way that lands is a UX problem, not a prompt engineering problem. For example, for Zepho, we’ve stopped asking people how much time they have to train (baking in the constraint from day 1), instead we now get Zepho to tell the athlete how much time and training is typically needed to meet their goal. And where there’s a mismatch, we force the conversation early to manage expectations.

I’ll be running the volume experiment through the winter and sharing the data. If you’ve run into similar challenges when creating an LLM powered product I’d love to share notes. If you’re interested in learning more about Zepho please check out zepho.ai.


Luke Forward · 3 November 2026

Have a challenge in mind?
Let's solve it together.