A few months ago I had a weird idea: what if I could take every single workout I’ve logged over the past two years and turn it into a series of blog posts — without writing them all by hand? I’d been tracking everything in the HEVY app religiously, and somewhere in that data was a real story about how my training had evolved. I just needed a way to pull it out. So I started experimenting, and what followed was one of those projects where you end up learning way more than you bargained for.
Here’s exactly how I went from a raw CSV export to eight published blog posts — using Gemini, Claude, and a bit of Python.
Step 1: Getting the Data Out of HEVY
If you’ve never used HEVY, it’s a workout logging app that’s genuinely great for tracking sets, reps, and weights over time. What I didn’t fully appreciate until this project was how good its data export is. Buried in the settings is a simple option to export your entire workout history as a CSV — every exercise, every set, every rep, timestamped and ready to go.
The export gave me a flat file with columns like:
- Date — when the workout happened
- Workout Name — whatever I’d named the session
- Exercise Name — e.g. “Leg Press (Machine)”
- Set Order — set 1, set 2, etc.
- Weight (lbs) and Reps — the actual numbers
- Notes — any cues or comments I’d added
Two years of training compressed into a few thousand rows. At first glance it was overwhelming — just a wall of numbers. But that’s where AI came in.
Step 2: Using Gemini to Identify Training Phases
I took that CSV and dropped it into Google Gemini with a pretty straightforward prompt: “Here’s my complete workout history. Can you identify distinct training phases — periods where my program, exercise selection, or structure meaningfully changed?”
What came back was genuinely impressive. Gemini analyzed the patterns in workout naming, exercise rotation, and frequency, and carved out eight distinct training phases across the two years:
- Phase 1 — Early bro split (push/pull/legs)
- Phase 2 — Muscle group split (chest/triceps, back/biceps, legs/shoulders)
- Phase 3 — First upper/lower split
- Phase 4 — Day-specific programming with more exercise variety
- Phase 5 — Full body training, 4x per week
- Phase 6 — Experimental mixed split (chest/legs, back/arms)
- Phase 7 — Return to upper/lower with more refinement
- Phase 8 — Current protocol, the most refined version yet
Each phase had a clear start and end date, a description of the programming logic, and the exercises that defined it. This became the skeleton for eight separate blog posts.
Step 3: Python for the Numbers
Before handing anything off to Claude to write, I wanted the actual stats — real numbers for each phase that I could include in the posts. I wrote a short Python script to process the CSV and calculate per-phase aggregate data:
- Total workouts — how many sessions in each phase
- Total sets — across all exercises and workouts
- Total reps — across all sets
- Total volume lifted — calculated as weight × reps for every set, summed up in lbs
The volume numbers turned out to be one of the most satisfying parts of the whole project. Seeing that Phase 7 alone accounted for over 1.1 million lbs of total volume lifted across 40 workouts made the data feel real in a way that just reading workout names never did. Python made that kind of aggregation genuinely easy — a few pandas groupbys and some date filtering, and the numbers were ready to go.
Step 4: Claude Writes the Posts
With the phase structure from Gemini and the stats from Python, I handed everything over to Claude to actually write the blog posts. This is where the workflow got genuinely interesting — instead of writing prompts in the chat UI, I was using Claude Code (the CLI tool) to run multi-step agentic tasks directly against my WordPress site via the WordPress.com MCP integration.
Here’s roughly what Claude handled for each of the eight posts:
- Writing the post content — each phase got a full write-up covering the training split, the exercise selection rationale, and the progression logic, in my voice
- Inserting the stats table — a formatted WordPress block table with total workouts, sets, reps, and volume, injected after the weight update heading in each post
- Assigning categories and tags — Claude created a “Workout” category and then built out a full tag taxonomy from scratch: workout type tags like upper lower split, full body, bro split, and exercise-level tags for every movement (deadlift, hack squat, preacher curl, and about 50 others)
- Updating the WordPress templates — the sidebar, the single post template (to add tag display), and the blog page layout were all updated as part of the same project
The fact that Claude could read the CSV files, run Python scripts, call the WordPress API, and update templates all in a single session — without me switching between tools — is what made this feel like a genuinely new way to work.
What the Finished Product Looks Like
The end result is eight posts, one per training phase, each with:
- A Pexels hero image relevant to the training style
- A breakdown of the 4-day split structure and the reasoning behind it
- A day-by-day muscle focus section explaining the exercise choices
- A stats table — total workouts, sets, reps, and volume lifted for that phase
- The actual working weights as of the end of that phase, listed by exercise
- Tagged with every relevant exercise and training style so they’re discoverable by anyone browsing the site
The whole thing took a few hours of actual work — most of it spent iterating on prompts and debugging the WordPress API calls rather than writing anything manually. That ratio felt right. The AI handled the repetitive work; I focused on the structure and decisions.
A Few Things I’d Do Differently
Honestly? Not a lot. But a few things stood out:
- Start with a schema. Defining the tag taxonomy before creating posts would’ve saved a pass. We created all 56 tags after the fact and then updated posts — doable, but cleaner to plan it upfront.
- Pagination on the API matters. The WordPress.com API has rate limits on parallel calls. Batching tag creation in groups of 10 kept things smooth; trying to do more at once hit limits.
- Context window is real. The Claude session that did most of this work hit context limits and had to be resumed with a summary. For very long, multi-step sessions, checkpointing your state (saving intermediate files, keeping track of IDs) is worth doing intentionally.
If you’re sitting on a dataset — workout logs, journal entries, financial records, reading history — and you’ve ever thought “there’s probably something interesting in here,” the tooling to pull it out and publish it properly has gotten genuinely good. This project is proof of that.
The eight workout posts are live in the workout category if you want to see what came out the other end.
Leave a Reply