What if you threw away your app’s backend - the APIs, the business rules, the database, everything - and replaced it with… an AI model?

AI

A friend on my ultimate frisbee team has been working on a vibe-coded game tracker for the past two years. It keeps track of the score, and more importantly, calculates who should substitute in between points (we’re shockingly bad at remembering this ourselves).

The app works, but there are a surprisingly large number of edge cases that we discovered through real-life usage. A player shows up late and needs to be added to the rotation. Or someone gets injured and leaves early. Or we messed up the rotation and want to stick with our new pattern. Or we don’t have enough players and need to play short-handed.

After two years of weekly iteration, we still have trouble getting through a game without running into a wrinkle that forces us to revert to the old-fashioned approach. Turns out real life is hard to model!

The idea

This sparked a thought: instead of building code to handle each and every edge case, why don’t we just explain our rotation rules to an AI model and ask it to figure out what comes next? When exceptional circumstances pop up, we can simply explain what should happen in plain English and the model will adapt.

I spent some time vibe-coding a proof-of-concept to see if this could work. Here’s the general idea:

• A React frontend binds to a global Redux-esque state object that contains the entire app’s state
• On any action from the user, the frontend makes an API request to Claude that includes:
  1. The current state object as JSON
  2. The requested update (“increment Disco Fever’s score by 1”)
  3. A system prompt describing how the app should behave and the JSON schema it should return
• The AI model returns an updated state object, which the frontend renders as UI

Here’s the result: ultimate.nathanfriend.com (and here’s the source: gitlab.com/nfriend/ultimate).

Does it work?

Yes! Well, kind of.

It mostly works great. Clicking around the app, it feels like a traditional, if sluggish, SPA web app:

The real killer feature, though, is the ability to talk to the app and ask for any arbitrary update!

I can click the microphone button and just speak something like this:

Set Disco Fever’s score to 13, swap out the next line for characters from Marvel movies, and add a relevant emoji next to each player’s name.

And the app will happily comply:

This is pretty wild! We’ve entirely eliminated the risk of an edge case derailing the app mid-game.

Does it actually work though?

Well… no. There are a few glaring problems that keep this squarely in the “proof-of-concept” category:

1. It messes up the lines

This one surprised me a bit. Despite the simplicity of the rotation rules, the model very often gets it wrong. Actually, you can see an example in the first GIF above: it fielded one too many players (8) in the current line! It also adds “Nova” to the same line twice at some point.

The model should be able to follow this pattern easily, so I think this one is probably surmountable with some prompt tweaking. (And maybe including more context - like past lines - in the request.)

2. It’s sllloooowww

Since every action in the UI requires a round-trip to the model, it’s agonizingly sluggish: each action takes 5-10 seconds.

If you can believe it, this is much improved over my initial attempt, which was closer to 50 seconds.

The main bottleneck is the model itself; we send quite a bit of content to it (system prompt + entire game state JSON object), and it outputs another full game state object.

To cut this down from 50 seconds to 5 seconds, I did the following:

• Switched from Sonnet to Haiku
• Optimized the game state object to be as small as possible
• Minimized the amount of content in my system prompt
• Asked the model to send minimal JSON diffs that I then merge into the previous state object, as opposed to it sending a full copy every time

In the future, I think something like Taalas’s 17k tokens/second model (demo) might render these optimizations unnecessary. (No affiliation, I just find this demo wild.)

A note on pricing

Behind the scenes, I’m proxying all calls to the model through Stripe’s AI Gateway. This is part of Billing for LLM tokens, which allows me to charge end-users for their token usage (with markup!).

This is neat, since it makes this approach economically viable. Without this, I’d be on the hook for token spend, which would quickly become a problem with even moderate levels of scale.

Should you do this?

Maybe! I think this approach is a great candidate for a (very) narrow class of applications:

• Extreme fault tolerance: it’s not a huge deal if the app falls flat on its face
• Local state only: the app doesn’t need backend persistence
• Performance insensitive: a sluggish UI is tolerable

Putting it another way: could you model your use case by explaining it to ChatGPT and asking it for periodic updates? The approach described here is essentially building a custom frontend for an AI model that presents itself as a visual UI instead of the chat interface we’re used to.

Have you done something similar? Let me know about it at hello@nathanfriend.com.