Back to projects

Project Case Study

Entropy AI.

A satirical AI assistant with multiple personalities, persistent chat state, and Anthropic-powered responses wrapped in a deliberately unhelpful product.

Next.jsReactZustandAnthropic API
Entropy AI chat interface

The Problem.

Entropy started as a joke: what if a polished AI assistant was competent enough to answer you, but visibly annoyed that you asked? The project only works if the joke sits on top of an application that still feels like a real chat product.

That meant the personality could not just be a different coat of paint. The model selector, response timing, system prompts, persistent conversation state, loading behavior, and interface all had to reinforce the same idea.

How It Works.

The application is built with Next.js and React. Chat state is managed with Zustand and persisted locally so the user can keep a conversation without creating an account. A Next.js API route handles requests to Anthropic and selects a system prompt based on the Entropy personality the user picked.

The three modes deliberately behave differently. Standard is useful with attitude, Haiku constrains responses to the bit, and Turbo adds an intentionally ridiculous delay before returning a response. They all use the same underlying API path, which keeps the product behavior separate from the model provider integration.

Decisions That Mattered.

  • Use one AI integration with personality-specific system prompts instead of pretending each UI option is a completely different model stack.
  • Keep conversation history local because accounts would add friction without improving the joke or the core experience.
  • Make response timing part of the product behavior. Turbo being slower is intentionally wrong, which only works if the loading state makes the delay feel deliberate instead of broken.

Challenges & Tradeoffs.

Comedy is surprisingly easy to overdo in an AI product. The responses still need to be useful often enough that the app feels intentional rather than like a prompt that only insults the user.

The personality rules also have to survive real user input. Keeping the different modes distinct without duplicating the entire API implementation was the main structural concern.

What I'd Change Today.

  • Add automated coverage around the API route and model-selection behavior so personality changes do not accidentally break the basic chat flow.
  • If I revisited the project, I would tighten the boundaries around model configuration and make the prompt behavior easier to test without calling the provider.