The JSON was always valid and it prescribed 31 chest sets a week: numeric constraints get calculated in code, before the prompt

🏋️ A workout generator built with AI always returned perfectly valid JSON. Too bad it prescribed 31 chest sets a week to someone who only wanted to stay in shape.

Valid schema, dangerous advice

And to a beginner who had flagged a knee problem, 3 sets of 5 on the leg press.

Technically it was all correct: valid schema, right fields, structure respected.

The advice, though, was wrong, and in some cases it could even be dangerous.

The numbers leave the prompt and move into the code

So whoever built that coach changed the way they use the model: the AI doesn’t decide the numbers anymore.

Before the prompt is built, an ordinary function calculates the training prescription using goal, experience, available days and health information.

Only then does the model come in.

It receives limits that are already set, and it can choose the exercises without stepping outside those boundaries.

Which limits the function calculates

For example:

• 10-12 weekly sets per muscle for a beginner
• 12-16 for an intermediate
• 14-20 for an advanced lifter
• longer rest periods if the goal is strength, shorter ones for metabolic work
• a deload week every six weeks, or every four when there’s a medical flag

The weekly volume ranges have backing in the literature: the dose-response meta-analysis by Schoenfeld, Ogborn and Krieger (Journal of Sports Sciences, 2017) associates each additional weekly set with an average 0.37% increase in muscle gain, and analyses the bands under 5, 5-9 and 10 or more weekly sets per muscle separately. On rest periods, the American College of Sports Medicine position stand (2009) recommends 2-3 minutes with heavy loads and 1-2 minutes for hypertrophy work.

The number of available days affects volume too, but always within defined rules.

From five days up, the weekly limit rises by two sets, up to a maximum. Below two days it drops, but never under six sets.

Why the same reasoning applies to other AI products

The interesting part, to me, is that this reasoning applies to a huge number of AI products.

There are decisions you can leave to the model.

And there are others that, when they go wrong, can cost you money, create security problems or do real damage.

Those are better taken out of the prompt and moved into the code.

It’s the same separation I apply in projects that deliver custom-built software for companies: the rules that always have to hold live in the code, and the model is left with the flexible part.

Four rules for splitting code and prompt

In practice:

1) Decide up front what the AI gets to choose and what has to be fixed.

2) Anything that has to follow precise rules, you calculate with ordinary code.

3) You leave the model the more flexible part.

Here it can choose the exercises, but it can’t make up sets, rest periods and loads.

4) And above all: valid JSON only tells you the response has the right shape.

It doesn’t tell you that what’s inside makes sense.

Which decisions are you still leaving to the model that, if they go wrong, could really cost you?