Case study · lp-design.eu
Lucas-Bot
Every portfolio is a monologue. This one has a second voice: a version of me that visitors can question directly. I decided what it may say, what it must refuse, and where it has to admit it doesn’t know. Developed alongside Claude Code, learning how to turn ideas into reality at a faster pace than ever.
- Role
- Concept, persona and limits. Direction and review
- Built with
- An AI coding assistant, to my specification
- Context
- Built for this site, lp-design.eu. Running in production
- Timeline
- 2026
01Question
A case study is mostly a decision about what to leave out. I choose the projects, the order, the level of detail, and a reader who wanted something else has exactly one option: an email, and a wait. Most people don’t send it. The question that goes unasked is often the one that would have decided it.
A language model is the obvious answer and a bad one if you are careless with it. A bot that invents a project I never did, or a client I never had, is worse than no bot at all: it makes every honest sentence around it suspect. So the brief wrote itself. Let people ask anything, hold every answer to something I have actually written, and treat the refusal as part of the design rather than a failure of it.
A bot that flatters me is worth less than one that admits what it doesn’t know.
02Rules
It speaks as me, in the first person, because a third-person assistant introduces a formality that I don’t want for this portfolio. But it names itself in its opening sentence: a version of me, trained on my work. The disclosure is the greeting, not fine print underneath it. A visitor who works out on their own that they have been talking to a machine has been tricked, and that costs more trust than the feature could ever earn back.
Everything it is allowed to know lives in one file I wrote by hand, in my own words: the projects, the reasoning behind them, the parts of the process I would tell someone about over a coffee. Nothing is fetched from the open web while it answers. When a question lands outside that file, it says so and gives out my email instead of reaching for something plausible. Alongside that sits a list of what it will not discuss at all: confidential work, client roadmaps, unreleased features, anything from inside a studio I have worked in.
The other limits are the unglamorous ones, and they were the part of the brief I was most specific about. A public endpoint with a model behind it is someone else’s free compute and my invoice, so it needed a ceiling on how often it can be called, how much it will say, and how much it can cost me in a month even if everything else fails.
Limits I asked for
- Rate limit
- Per IP, 20 requests per minute
- Reply cap
- 500 tokens
- Context cap
- 20 messages, 1500 characters each
- Timeout
- 30s, cancelled when the visitor leaves
- Origins
- Restricted to this site
- Spend
- Hard monthly cap at the provider
03Method
I should be straightforward about how this was made, because the interesting part is the method rather than the artifact. I am not a front-end or a back-end developer. The code I write myself is embedded: Arduino, Python, an ESP32 with things wired to it. Every line running this bot was written by an AI coding assistant working to my brief.
What that buys me is reach. What it costs is that I have to know exactly what I am asking for, and I have to be able to tell when the answer coming back is wrong. Both of those come from the embedded work. Once you have debugged a sensor that lies to you, you recognise the feeling of a system that looks correct and isn’t, and you stop taking a confident-sounding answer at face value.
So my work here was the part I would have done anyway: deciding what the thing should be, where its edges are, what it must never do, and then reading, testing and rejecting until it behaved. I can’t claim the engineering. I can claim the brief, the judgement about what was worth building, and the willingness to keep sending it back.
Next
All projects