PunGPT, Designing AI Personality Under Constraints

The Idea

Most AI assistants are optimised to be helpful. Very few are designed around tone as the primary goal.

I wanted to find out what that takes. Helpful is easy to measure and easy to optimise for. A consistent personality is much harder to define, and harder still to sustain across a full conversation. To test it, I picked a deliberately small brief: a chatbot with one job, delivering puns and dad jokes in context.

The goal was not the jokes. It was to see how tone is established, how it drifts under pressure and what it costs to keep it consistent.

PunGPT responds to what the user actually said, finds the angle from there and stays in character, so it feels intentional rather than like a randomness machine that occasionally lands a good one.

The Build

The first challenge was personality design. A chatbot that drops random jokes regardless of context is easy to build and immediately annoying to use. Responding in context required careful, iterative prompt engineering to establish a tone that stayed consistent without feeling rigid.

The second challenge was technical. Running on a free, lightweight LLaMA model meant working within real limits on content length and processing. Managing conversation history without letting the prompt balloon, controlling token usage and keeping responses fast enough for the timing to work all required deliberate architectural decisions. Those decisions had little to do with humour and everything to do with making it possible.

The application uses a familiar chat layout, consistent with similar tools. Users can clear the history and start a new conversation at any time.

Behind the Build

I designed, built and prompted PunGPT end-to-end on my own, from defining the personality to the technical foundations that keep conversations contextual and performant.

The application is also available on mobile, with a consistent experience across platforms.

Results

PunGPT delivers a steady stream of contextual puns, which was the point. It is an experiment, not a productivity tool.

What I took from it is useful well beyond jokes:

• Tone is a design decision, not a side effect. It has to be specified, tested and defended against drift, like any other product requirement.
• Constraints shape the product. Limits on context and compute forced choices about what the system remembers, and those choices determined the quality of the experience.
• Small experiments teach quickly. A low-stakes project is a cheap way to learn how a medium behaves before applying the lessons to higher-stakes work.

It is also a reminder that sometimes the most interesting problems are hiding inside the most ridiculous ideas.