How to Build Your Own AI Personal Trainer (No Code)
Published September 29, 2026
Building your own AI trainer and nutrition coach takes three parts and no programming: a profile file the assistant reads every session, standing rules that constrain its behaviour, and a food database attached as a tool so the numbers are retrieved rather than invented. Here is the whole build.
Everything here works with a general assistant. You are not writing software, you are assembling a workflow, and the components are a text file and one configuration line.
What are the three parts?
Memory. A file holding your profile, targets, constraints, regular foods and a running log. This is what a paid app charges for, and a markdown file does the same job.
Behaviour. Standing rules that apply to every reply rather than one request. This is what stops an assistant answering food questions from memory when you asked it to look them up.
Data. A tool the assistant calls to retrieve food composition, so figures come from a catalog rather than recall. This is the only part that needs anything installed.
Most people build the first, skip the second, and never do the third, which is why most of these setups produce plausible output that cannot be checked.
Part one: the file
In Claude Code, a markdown file in the working directory is read automatically. Cursor has project rules. For other clients, paste it at the start.
# Profile
- 34, male, 82 kg, 180 cm. Desk job, lifts 4x/week.
- Goal: lose fat, keep strength.
- Targets: 2,150 kcal, 175 g protein.
- Allergy: shellfish. Will not eat cottage cheese.
- Left shoulder dislikes overhead pressing.
- Current bests: squat 120x5, bench 85x5, deadlift 150x3.
## Core foods (per 100 g)
| Food | kcal | P | F | C | food_id |
## Recipes (per serving)
## Session log
## Food log
The core foods table is the highest-value part and the one people skip. Resolve the fifteen or twenty things you eat most weeks once, record their values, and from then on most log entries need no lookup at all. It is an hour that pays out for months.
Part two: the rules
These matter more than any prompt, because they apply to everything.
## Rules
- Always search the food catalog before quoting a macro. Never estimate
a food from memory.
- If a lookup misses, say so and ask me for the label. Do not substitute
a similar generic row.
- State the gram weight you assumed for anything I describe in words.
- Cross-check rows with the 4/4/9 rule and flag gaps over 20%.
- Append to the logs. Never rewrite earlier entries.
- Never prescribe a specific training weight. Rep ranges with RPE only.
- If I report pain, tell me to see a professional. Do not program around it.
- One change per review. Do not rewrite the programme unprompted.
Each exists because of a specific failure. The first stops the assistant answering quickly from memory. The fifth stops it helpfully tidying your history, which is data loss. The last stops you collecting plans instead of following one.
An honest caveat: these are instructions, not enforcement. Compliance is high and not total, which is fine for preferences and not good enough for an allergy. Read ingredient lists yourself, every time.
Part three: the database
The part that separates this from every prompt-only guide.
claude mcp add --transport http calorie-api \
https://calorieapiadmin.com/mcp \
--header "X-API-Key: YOUR_KEY"
The key comes from the dashboard after starting a plan on MCP pricing. Claude Code and Cursor work; Claude.ai, Desktop and mobile cannot connect to this server because browser sign-in is not enabled. The walkthrough is in connect a remote MCP server, the reference is in the docs, and the MCP page is the overview.
Once attached, ask for a meal and watch two calls happen per food: a search returning a row, then a portion scale. That is the mechanism working. If you see no calls, the rules are not holding.
For software rather than personal use, a REST plan is the right route.
Building it in the right order
The sequence matters, because doing it backwards means redoing work.
1. Attach the database first and confirm it returns real rows. Ask for 180 g of cooked chicken breast and check you see a search followed by a portion scale. If that does not work, everything built on top inherits invented numbers.
2. Write the rules. Behaviour before content. Without them the assistant answers from memory regardless of what else you set up.
3. Write the profile. Stats, targets, constraints.
4. Resolve the core foods. The hour that pays for itself.
5. Only then start logging. Sessions and meals, appended.
The common mistake is starting at step five, discovering in week three that none of the figures came from anywhere, and rebuilding the log. The order above avoids that.
A worked first week
Day one. Attach the tool, write the rules and the profile. Log nothing. Thirty minutes.
Day two. Resolve fifteen to twenty core foods into the table. Roughly an hour, and the most valuable thing you will do.
Days three to five. Log properly, weighing what you prepare. Expect it to feel slow, because it is, and because it is calibrating your eye for portions.
Day six. Total one recipe you cook often and save the per-serving row. One calculation, four future meals covered.
Day seven. Run the weekly review even though a week of data means little. The point is seeing the loop once.
If by day seven the file feels like something you own, this will work. If you have not opened it since day three, it will not, and that is useful information for the price of a week.
The daily and weekly rhythm
After each meal: one sentence of what you ate. Most entries cost nothing, because the core foods table already has the values.
After each session: lifts, sets, reps, effort. Appended to the log.
Weekly: the review, in this order. Days logged out of seven, average calories, average protein, weekly average weight. Days logged first, because if it is four the averages only describe the days you chose to record.
Monthly: re-resolve the core foods, since a catalog gets corrected, and prune recipes you stopped making.
How do you know it is working?
Two checks, run every week or two, because a setup like this degrades quietly.
Ask which tool produced a figure. "Which catalog row gave you that protein number?" A specific answer means the mechanism is working. A vague one means the assistant answered from memory and your rules have stopped holding, which happens on long sessions.
Add the totals yourself. Take a logged day and sum the entries. If the stated total disagrees, arithmetic is being generated rather than computed.
Both take under a minute and they catch the two ways this setup fails silently. Neither is obvious from the output, which is exactly why they need to be deliberate habits rather than things you notice.
If the rules have stopped holding, the fix is usually a fresh session rather than a longer reminder. Instructions given thirty messages ago compete with everything since.
Adapting it for other goals
The same three-part structure works beyond fat loss with small changes.
Gaining. Same file, different targets, and a longer review window. A few hundred grams of gain a month is smaller than normal weight fluctuation, so four weeks is the minimum before a decision means anything. See tracking a lean bulk.
Maintenance. The most underrated use. Targets become a range, the review becomes monthly, and the log becomes a light touch rather than a daily task.
Managing a specific nutrient. Sodium, fibre or protein alone. Check the database actually carries the nutrient before relying on it, because a tool reporting zero for something it never held is worse than one that says it does not know.
Cooking for a household. Total recipes rather than meals, and scale per person from the per-serving row.
What this does not give you
A phone app. Desk workflow. Barcode lookup exists but you type the digits.
Reminders or accountability. Nothing notices you stopped.
Technique coaching. Nothing can see you move.
Backups. The file is yours, which means losing it loses everything. Put it in version control if that is natural; a training log with a full history of corrections is a genuinely nice thing to own.
What it costs to run
Worth knowing before you start, since the components are priced separately.
The assistant. Free tiers are usable for this. Paid tiers give you longer context, which matters once your file grows.
The food database. A subscription, and the only part with a clear price. Details on MCP pricing, with a trial so you can find out whether the workflow suits you before paying.
A kitchen scale. The cheapest component and the one that removes the most error. If you buy one thing on this list, buy this.
Your time. The largest cost and the one nobody prices. Roughly two hours of setup spread over a week, then a few minutes a day.
That last line is the real decision. The software costs are modest and comparable to a tracking app. What this asks for is attention during the setup, which is exactly when motivation is highest and patience is lowest.
Is it worth the setup?
Honestly: for some people. The first fortnight is real effort, and it lands exactly when patience is lowest.
Worth it if you already track, are annoyed by app interfaces, and want figures you can audit. Not worth it if you have never logged food, because this makes the habit harder rather than easier. Start with a free app and a scanner, build three months of consistency, then come back if the interface is what is in your way.
What we have not measured
We have not run this setup for a quarter and published what it got wrong, nor measured how often the standing rules are ignored. The failure modes described are observations about assistant behaviour in general, not counted rates from a trial.
What is documented here is mechanism: which component produces which number, and which parts are lookup rather than judgement. Those you can verify yourself in an afternoon, which is the point of describing the build rather than reporting a result.
Common mistakes
Skipping the database. The most common, because it is the only part requiring setup. Without it you have a nicely organised system producing invented figures, which is worse than no system because it looks reliable.
Letting the file sprawl. After a few months the log dominates the file and the client is reading three years of history to answer a question about today. Split the log into its own file by year and keep the profile short.
Rewriting instead of appending. Ask an assistant to tidy a log and it will helpfully reformat history. That is data loss and it is why the append rule exists.
Treating the rules as suggestions. They are instructions in a prompt, not enforcement, and they need spot-checking. That is what the two verification habits above are for.
Related
Frequently Asked Questions
How do I build my own AI personal trainer?
Three parts and no programming. A profile file the assistant reads every session holding your stats, targets, constraints and logs. Standing rules that constrain behaviour on every reply. And a food database attached as a tool so nutrition figures are retrieved rather than recalled.
Do I need to be able to code?
No. The file is markdown and the database connection is a single configuration line in Claude Code or Cursor. You are assembling a workflow rather than writing software.
What standing rules matter most?
Always search the catalog before quoting a macro; say so when a lookup misses instead of substituting a generic row; state the gram weight assumed for anything described in words; append to logs rather than rewriting; never prescribe a specific training weight; and refer pain to a professional.
Why does the core foods table matter so much?
Because resolving the fifteen or twenty foods you eat most weeks once, and recording their per 100 g values, means most future log entries need no lookup at all. It is roughly an hour of work that removes most of the ongoing friction.
Is building your own worth it over an app?
It suits people who already track, dislike app interfaces and want auditable figures. It is a poor choice if you have never logged food, because it makes the habit harder rather than easier. Build consistency with a free app first, then reconsider.