How to make AI write in your methodology, not ChatGPT's

There is a specific complaint that comes up whenever coaches talk about AI programming. It sounds like a quality problem, and it usually is not. The plan is technically sound. It is just not how I would write it.

That complaint is worth taking seriously, because it points at the real limitation. A general-purpose model has read every training philosophy ever published and averaged them. Your philosophy is a set of decisions that sit deliberately outside the average. So the output lands somewhere in the middle, and the middle is nobody's method. You can fix most of this. Not by asking more politely, but by turning your method into constraints the generator has to obey.

The difference between a preference and a constraint

Here is the part that changes the results, and it is simpler than most prompt guides make it sound. "There is one big prompt" describes a preference. A preference is weighed against everything else in the request, and the model decides how much it matters. "The session always starts with the primary lift" is a constraint. Constraints get applied or they fail.

So start by going through your programming and separating the things you care about into two lists. The first list is what you happily delegate. Which muscle groups pair well, how many exercises fit in forty-five minutes, what a sensible warm-up looks like. You do not have an unusual opinion here, and neither does anyone else. Let the system handle it.

The second list is your method, and it should be short. If it runs to twenty items you do not have a method, you have a taste, and taste is very hard to encode. Three to seven real rules is normal. Here is what they tend to look like:

• A movement pattern gets hit twice a week, never three times
• The hard lift goes first, while the client is fresh
• Nothing heavy within seventy-two hours of a session that matters to them
• Deloads arrive at weeks five and nine, planned in advance, not when they crash
• Volume climbs, intensity stays flat, for the first four weeks

Write those down in plain sentences. You now have something you can actually check against a plan, which matters more than you might think, because a rule you cannot check is a rule you will not enforce.

Where to put the rules so they stick

Most coaches put them in the chat box and hope. That works for a single session and fails the moment you are on your fourth client of the evening, because a preference typed into a message is not a system.

There are three places worth using, in increasing order of how much they will save you.

First, a written philosophy document. One page, your rules, kept in whatever you already use for notes. This is for you, not the machine. Its job is to stop you rediscovering your own method every time you sit down.

Second, a reusable intake. Most generators take structured input: training days, session length, equipment, experience, goal priority. Fill it in the same way every time and you remove the biggest source of variation, which is how you described the client on a Tuesday when you were in a hurry.

Third, your own editing pass, and this is the one that gets skipped. Whatever comes out, you change two or three things to make it yours. Those edits are the most valuable data you have, because they are the exact points where the system's average disagrees with your method. When the same edit keeps appearing, that is a rule that belongs in your philosophy document, not a thing you fix by hand every week.

What this looks like in practice

Forge AI takes a structured intake rather than a chat: goals, experience, the client's actual week on a seven-day grid, equipment, session length, injuries, conditions, allergies, and how many weeks the block should run. You can also name the plan and describe who it is for, which is what stops the intake from defaulting to a generic client.

The rules you care about end up as the constraints the pipeline validates against. If you tell it the client trains Monday, Wednesday and Saturday, a plan that schedules four sessions is wrong rather than stylistic, and it gets caught. Same with a rest day that quietly becomes a training day, or a load that jumps outside a sensible range.

That is the difference between a preference and a constraint showing up in the finished document. The model did not read your mind. It was given something checkable. And when the system gets it wrong in a way you could not have anticipated, it says so. Plans that need a professional eye arrive flagged with specific notes rather than a general warning, which is the standard we hold ourselves to: the machine raises the question, you answer it.

The test that tells you whether it worked

Give yourself a fortnight and then read back a generated plan next to one you wrote by hand, covering two clients at roughly the same level. Do not compare quality, because you will not be objective about your own work. Compare the specific things a client would notice.

Do the sessions open the way yours open? Do the rest days land where yours land? Does the block build the way yours builds, or does it front-load and fade? Does it use the exercises you would have picked, or the plausible-but-not-yours ones you keep deleting?

If the answers are mostly yes, you have encoded your method and the drafting is now genuinely yours. If they are mostly no, look at your rules again and ask whether each one was a constraint the system could check, or a preference you hoped would survive a long context window. Nine times out of ten it is the second.

One last thing worth saying plainly, because it is the reason this matters more than it used to. A plan that reads like generic AI output is not just less satisfying to send. It is more likely to be wrong in ways specific to your client, because the average has no opinion about your client's knee. The closer the output is to your method, the more of your professional judgement is standing between the client and the averages.

You can try Forge AI on a real intake and read the whole thing before you decide anything, or start from the free programme generator if you just want to see the shape of the output first. Either way, bring your own rules to it. That is where the difference lives.