
I've been (vibe) coding a lot lately. I experimented with a few infrastructure projects (logging system, LLM gateway, tool calling permission management, etc.) but one that I found real passion around is an AI workout manager and coach. I built this one in parallel with the other, more "professional", projects out of frustration with other products that I've tried.

In the end I resorted to using Apple Notes and ChatGPT in order to plan out my training sessions. It was ok for a bit but quickly became too much to effectively manage and ChatGPT started losing context. Ok, I'm an engineer, we're in the vibe coding era, I can "fix" this.

![Calendar view](/images/2026-02-03/calendar.png)

# Background

I've been active my whole life, be it sports or even just workouts to stay healthy. As a high-schooler I trained rowing a lot, to the point where it got me to the brink of "do I go professional or not?". I had good success locally as well as at the European U23 level. (Un)fortunately I got a knee injury that required rehab and taking it easy for a while. During that time I got even more into computer science and tech as I had all this extra time all of a sudden (high school + 1-2 training sessions a day keeps you **busy**). Good thing this happened, really, because it was what built the foundation of my career. And I have a really good life because of it.

I stopped rowing at that point pretty much completely, but I remained active through gym and other workouts. I kept doing indoor rowing workouts and have always had a Concept2 rowing machine in my posession no matter where I lived. Later, in the past 5 years, I started two new sports: cycling and skiing. I transitioned to gravel cycling specifically over the past 3 years and added backcountry skiing. To keep my motivation up I signed up for the occasional gravel race and last year I did my first "ultra" (520km, 10k m vertical). And I loved it! For this year I plan that same ultra gravel race, [Seven Serpents: Quick Bite!](https://www.seven-serpents.com/quick-bite/) in May and the [World Rowing Master Regatta](https://wrmr2026.com) in September.

# Why

As you might be able to tell from the above background, I'm not your typical gym rat or weight-loss warrior, my focus is two-fold: develop strength and stamina for better life quality and do well in the above mentioned sports. I would put myself into the "amateur athlete" category. There's apps targeting this type of customer too but they often lack at least one major feature. And since we now live in the AI era, I looked at that as well and have not seen a good implementation of an AI coach targeting athletes just yet. I don't need fancy videos showing me how to perform an exercise. I need a very solid, knowledgeable and to-the-point kind of coach. I need a good and simple UX around seeing the training plan, performing workouts and syncing those to my Wahoo bike computer. The coach should remember a lot about the workouts and me. Oh and I made sure it has more of a to-the-point kind of vibe. No fluff.

# How

It's pretty simple actually. The frontend is a Next.js web app and an iOS native companion app. There's a Postgres database. That's it. The Next.js app handles everything from the frontend to the mobile API. Would I do it like this if I was not vibecoding it? Unlikely. I'd probably split things up a bit more, use multiple services, etc. But honestly, that would be over-engineering. Oh and also, I should say that while I do use the term "vibe coding" it's not really vibe coded. I go to great lengths to review the code but most importantly make sure the architecture and structure is sound.

I started by doing the work with Cursor. I like the integrated review capability, the editor and the fact that you can switch between multiple models. I used mainly Opus 4.5, some GPT-5.2 and the Cursor model, Composer 1, as well. Their model works surprisingly well for refactors and other simple(r) tasks, especially due to its speed. The iteration is super fast. However, what ended up happening as the project grew larger is that I did not really review all the agent changes in real-time. I would end up creating PRs, reviewing those and even then I'd help myself with agent PR reviews. The Cursor interface quickly became a hindrance (especially since it kept changing so fast). Then I briefly tried the Cursor CLI with the idea to keep the model-switching capability but I did not have a good time with that. It's so far behind the other good coding agent CLIs like OpenCode, Codex and Claude Code. I switched to using Claude Code as the main CLI with the occasional use of Codex and OpenCode as well. I like Claude Code's interactivity but for some specific tasks I prefer how Codex and OpenCode need a lot less hand-holding.

# What

This is how Claude describes the project:

> Fitter is an AI-powered workout coaching platform that combines a native iOS app with a Next.js web dashboard to deliver personalized fitness guidance. At its core is an
  intelligent AI coach that conducts onboarding interviews to understand your training background, goals, and physical profile—then provides
  contextual advice and can directly create or modify workouts on your behalf. The platform supports both cardio workouts (cycling, running, rowing, swimming) with structured
  intervals and training zones (Z1-Z5), and strength workouts with sets, reps, and exercise circuits. Users can plan their training via a visual calendar, sync workouts with Wahoo
  devices through OAuth integration, and receive weekly check-in notifications on iOS prompting reflection on recovery, fatigue, and motivation. The AI coach automatically takes
  notes during conversations—tracking feedback about workout difficulty, pain, or performance—building a memory that makes future advice more personalized. Built with Swift 6 and
  SwiftUI on mobile and TypeScript/React on web, Fitter bridges the gap between generic workout apps and having an actual coach who knows your history and adapts your training
  accordingly.

(Fitter is the working name I use for the project.)

![Coach chat](/images/2026-02-03/coach-chat.png)

# I like it because it's mine

I have a huge bias, obviously, but I think it has a unique angle on the AI fitness coach theme. It's not just another gym coach or workout manager, it's not an app to make you a better runner and it's also not an app to log and publish your workouts (keep using Strava for that, I do). But if your goal is to become stronger, fitter and do well in your sport(s) of choice, then it might be interesting to you as well.

Note: This is very much work in progress. I have been using it for months though and if you'd like to try it out let me know! Hit me up on [LinkedIn](https://www.linkedin.com/in/jernejstrasner/) or [X](https://x.com/JernejStrasner).


Building My AI Fitness Coach


Most of my career was iOS. I shipped apps, lived in Xcode, and got very used to the nice, tight feedback loop of building for one platform. At Facebook (now Meta), I expanded that into working with custom frameworks and tools outside the typical iOS development workflow. Later I moved into management and leadership work, which meant less hands-on coding day to day. Everything else (backend, frontend, databases, etc.) mostly happened on evenings and weekends as side projects. After I left Sentry, that weekend-and-evening hacking turned into full-time exploration.

As part of my exploration of LLMs and related infrastructure, I inevitably came across tool calling.

I’ve been building a workout manager and AI workout coach for myself ([fitness.antlab.ai](https://fitness.antlab.ai)). This gateway work grew out of my own need: I want models to take actions safely and predictably, not just generate text confidently. More on the AI coach another time. I think it’s a cool product in itself, and it’s gotten really good feedback from a few professional and amateur athlete friends who’ve been using it.

## Why build a gateway?

Tool calling is the part that makes LLMs useful beyond chat. Instead of guessing, the model can fetch data or run an action. The problem is that every provider implements “tool calling” with slightly different semantics, and wiring tools plus OAuth into every backend service becomes a mess quickly.

A gateway gave me three practical wins:

- Centralised configuration: define tools once, expose them to different models.
- Authentication and permissions: handle OAuth and per-tool scopes in one place.
- Consistency: normalise provider responses so callers do not need a pile of special cases.

My longer-term goal was more ambitious: manage context in the gateway and eventually stop depending on MCP servers. Even before that, the edge cases taught me where the spec ends and reality begins.

## Edge cases and implementation lessons

### 1. Resource metadata discovery is not consistent

Different MCP servers expose OAuth resource metadata in different places. What ended up working in practice was checking three locations, in this order:

1. The resource URL itself
2. `/.well-known/oauth-protected-resource` appended to the resource URL
3. `/.well-known/oauth-protected-resource` at the host level

This is one of those “I wish it was simpler” parts. You cannot assume everyone follows the same discovery endpoint.

### 2. `WWW-Authenticate` parsing is easy to botch

Some providers return a 401 with a `WWW-Authenticate` header that includes a `resource_metadata` URL. Parsing that header is fiddly, and it is very easy to accept something malformed (or reject something valid).

In my implementation there is still a TODO to add proper unit tests for this case, because it is exactly the kind of bug that only shows up in production.

### 3. Specs leave room, and providers take it

There are a few validation checks I still consider “must do”, but they take time:

- Supported endpoint auth methods
- Supported response types
- Supported grant types
- Refresh token support

The spec leaves room for interpretation, and providers use that freedom.

### 4. Discovery can fail even when you have credentials

One pragmatic change that improved UX: if discovery fails but the gateway has preconfigured OAuth credentials (some providers need this), it still populates client ID/secret so users can try authenticating. Some providers have flaky metadata endpoints, and letting the user proceed is better than a hard stop.

### 5. Token refresh needs a bit of slack

Tokens expiring “right now” is a common failure mode. I added a 30-second skew so the gateway refreshes slightly before expiry and avoids race conditions.

## Termination reasons: normalised vs native

Models report “why I stopped generating” in different ways. The gateway tracks two fields:

- `finishReason`: a normalised reason (for example `stop`, `tool_calls`, `length`)
- `nativeFinishReason`: the provider’s raw reason (for example `STOP` or `MAX_TOKENS`)

Here’s a simplified version of the check that decides whether to warn the caller about an upstream failure:

```go
func shouldNotifyUpstreamFailure(term upstreamTermination) bool {
    // Notify if nativeFinishReason indicates an error (non-empty and not "stop" or "max_tokens" - case insensitive)
    if term.nativeFinishReason != "" {
        native := strings.ToLower(term.nativeFinishReason)
        if native != "stop" && native != "max_tokens" && native != "function_call" && native != "tool_calls" {
            return true
        }
    }

    // Notify if finishReason indicates an error (not "stop", "tool_calls", or "length")
    if term.finishReason != "" {
        reason := strings.ToLower(term.finishReason)
        if reason != "stop" && reason != "tool_calls" && reason != "length" {
            return true
        }
    }
    return false
}
```

Two patterns that mattered:

- Gemini tends to use uppercase stop codes like `STOP` and `MAX_TOKENS`, while others use lowercase. Lowercasing avoids false alarms.
- Some APIs use `tool_calls`, others use `function_call`. In both cases it usually means “the model successfully decided to call a tool”, so I treat them the same.

Anything else (for example `content_filter`) triggers a warning, because it often means the response did not complete normally.

## How models differ in tool calling

The uncomfortable truth is that tool calling is learned behaviour. The API surface looks similar, but models make different choices about when to call tools, how strict they are about schemas, and how often they “give up” and answer in plain text.

### OpenAI (ChatGPT, GPT-4 class models)

OpenAI gives you explicit control over tool choice (auto, required, none). In practice, I’ve found behaviour varies a lot by model and prompt style. Some models will happily call a tool early, others need a very clear nudge, and the same toolset can behave differently across versions.

What helped me most was keeping tool names and parameter descriptions short, and not exposing too many tools at once.

### Anthropic (Claude)

Claude is generally comfortable mixing tool use with text, and it can chain tool calls naturally. It can also be more proactive than you expect, which is great when it is right and annoying when it is not. I ended up tuning tool descriptions more carefully to reduce “helpfulness” that turned into unnecessary tool calls.

### Google (Gemini)

Gemini has a lot of surface area and a lot of knobs, and when it works it can be excellent. The reliability was the harder part for me. I’ve seen runs where it calls tools correctly, then later in the day it answers in plain text instead of invoking the same tool, or it flips between behaviours across requests. That unpredictability is what pushed me to invest in stricter monitoring around termination reasons and tool-calling outcomes.

## Takeaways

Tool calling is not a pure spec implementation. It is model behaviour. If you want it to feel consistent to users, you have to do the boring work:

- Design tools for clarity. Short names, tight schemas, good descriptions.
- Do not expose everything at once. Too many tools lowers accuracy.
- Normalise and monitor. Treat unexpected termination reasons as real signals, not noise.
- Test across models. The same prompt and toolset will behave differently.

## Future work (and a note on the AI coach)

This gateway is still very much iterative. The next things I want to tackle:

- Better tool definitions, with examples that steer models toward correct calls.
- Lightweight JS tools so users can define simple functions without running a full MCP server.
- Automated regression tests that run prompts across models to catch behaviour drift.

And yes, the other project is still going: Fitter is a structured workout manager and AI coach. It lets athletes plan sessions, generate intervals, and sync workouts to devices. The coach side is where tool calling really earns its keep, but that’s a separate post.

## Conclusion

Tool calling is what turns LLMs into something you can build a product around, but it gets messy fast across providers. Finish reasons are inconsistent, tool-calling semantics vary, and reliability can swing from model to model. A gateway helps, but only if you treat standards as guidelines, normalise responses aggressively, and keep tightening your tool definitions based on real behaviour.


Building an LLM Gateway: Lessons from Tool Calling Across Models


I’ve been building products and tools for years — mostly iOS, lots of scripting, some backend, a lot of “make it work and ship it.” Recently I started poking into the AI space. Not just “call an LLM and magic happens,” but the *internals*. I want to understand enough to eventually build something serious on top of this tech.

One of the first things I kept hearing about in RAG (retrieval-augmented generation) setups was **chunking** and **embeddings** — and how they all tie into a **vector database**. I figured I’d document my beginner mental model.

## Step 1: Chunking
This part made sense quickly. You have long documents, but your embedding model (and later the LLM) has token limits. So you split the text into smaller **chunks**.

- Typical chunk size: ~500–800 tokens (2,000–3,200 characters in English)  
- Overlap: 10–20% so context flows between chunks  
- Too big = you get noisy, unfocused vectors. Too small = you lose context.

I now think of chunking as just a preprocessing step to keep everything bite-sized for the next phase.

## Step 2: Embeddings
Once you have chunks, you pass each one through an **embedding model**. This is where my “OK, but how?” curiosity kicked in.

The model outputs a **vector** — literally just an array of floats, like: [0.0213, -0.1342, 0.0876, …]

The magic is that similar meanings end up with vectors that are close together in this high-dimensional space. “Car” and “Automobile” will be neighbors. “Car” and “Banana” will be far apart.

It’s nothing like Levenshtein distance (string edits). Instead, embeddings are trained so semantic closeness translates to geometric closeness.

## Step 3: Storing in a Vector DB
Each chunk’s vector goes into a **row** in the vector database, alongside the original text and metadata. The DB builds an index so later we can search fast.

The vector DB doesn’t care about tokens or text anymore — it’s just arrays of numbers and math.

## Step 4: Retrieval
Here’s the clever bit:

1. User asks a question.  
2. You embed the question into its own vector (same model).  
3. The vector DB finds the **nearest neighbors** to that query vector.  
4. You fetch the corresponding chunks and feed them into your LLM for the final answer.

The naive way is to just scan all rows and pick the highest cosine similarity score (cosine similarity = dot product normalized for vector length). That works for small data, but with millions of vectors it’s too slow.

## Step 5: How Lookup is Actually Fast
Most vector DBs use an **approximate nearest neighbor** index — HNSW is the popular one. My mental model:

- Imagine all your points as cities on a map.  
- The DB builds a set of “highway” layers to jump across the space quickly, then “street” layers to refine locally.  
- When searching, it hops across highways, drops down to streets, and zeroes in on the closest points without visiting every “city.”

This gets you *almost* the same result as scanning everything, but way faster.

## Dot Product & Cosine Similarity (The Core Math)
The dot product is just multiplying each vector component, summing it up.  
Cosine similarity is the dot product divided by the product of vector lengths — which basically strips out magnitude and keeps only the **angle** between the vectors.

For embeddings, angle matters more than length, because we care about **direction in semantic space**, not absolute size.

## Final Mental Picture
- Chunk → embed → store in vector DB → embed query → find nearest vectors → send chunks to LLM.  
- Embeddings are just numbers.  
- Vector search is just “find points closest to this one” with clever shortcuts.  
- The rest is plumbing and product thinking.

I’m only scratching the surface, but already this feels a lot less like magic and more like a set of tools I can reason about.

Jernej Štrasner

Investing

Writing

Building My AI Fitness Coach

Building an LLM Gateway: Lessons from Tool Calling Across Models

Learning How Chunking, Embeddings, and Vector Databases Actually Work