Ronie
Stochastic thoughts

AI-first interfaces — the power of user prompts

Shortly after I started playing with the idea of an AI-first interface and built a simple AI-Powered TODO list, I found the AI… dumb. And the solution I found was to give context to the AI.

Here’s the link if you want to test it by yourself:
https://claude.ai/public/artifacts/09bc9cb5-cf6f-4cd1-9329-4d40b81dfb70

Custom prompts are the key
Custom prompts are the key

And by “context”, I mean give the user control over the prompt. This next version of the TODO list has a text box where users can add all the intelligence they need to the system.

That completely changes a dumb TODO list that sometimes does things in a slightly annoying way, for example, prefixing every item in my grocery list with “buy …”, into something smarter than every other TODO list app I ever tried (not that many, to be honest).

Here’s me trying the same “Lemon Chiffon Cake and Brownies” from the last post, but now customizing the prompt.

https://www.youtube.com/watch?v=4RhwyG3qOYE

Custom prompt = smart TODO list

I added a Markdown editor that solved my problem of not being able to save and load lists. I can keep them as pure text somewhere and copy and paste them to the app when I need them.

It’s not as convenient as having local storage, but it’s good enough™. With the bonus that I can edit the list myself for small adjustments.

The problem of jailbreak

Every system that allows the user to enter free text has a problem: malicious users.

With AI, that escalates from SQL and JavaScript injection to jailbreak. This means making the AI ignore the prompt from the software and replace the instructions with something the user wants, usually malicious.

When I was playing with this app, I noticed it would be very easy to jailbreak my weak prompts, then I realized something even more interesting: it wouldn’t matter if that happened.

Why? For 2 reasons:

  1. The way Claude apps work is that they use the user’s Anthropic account. If users try anything malicious, it would be no different than using their regular account. They can’t get any extra mileage by going through this app.
  2. The app runs in a sandbox, that’s obvious. But more than that, they can’t cause damage if they are in an isolated space. Think that this system could save data to the local browser storage instead of a server, and that still counts as “isolated,” even if the app is not in a sandbox.

And finally, if the AI can only interact with the system through a limited API, we can design that API to be extremely narrow — bringing us back to the familiar territory of SQL and JavaScript injections.

Of course, not every app can restrict itself to the strategies of using the user’s account and being in an isolated environment. However, narrow APIs are more feasible. That doesn’t mean they are simple to design or implement, but they are the “narrow waist” that most apps would have.

Is that really true? Can we start building practices for narrow APIs targeting AI use? Is plain MCP already good enough, or do we need extra design guidelines?

I don’t know, what’s your take?