AI is an engine. You drive the car.

A year ago my prompts were sloppy. I'd type a half-formed sentence, hit enter, and act surprised when the model handed back something confidently wrong. The reflex is to blame the model — wrong answer, must be a dumb model. After enough of those, I stopped blaming the model and started reading my own prompts. They were the problem.

AI has no common sense — it has what you give it

This is the thing it took me too long to internalize: a language model has no common sense to fall back on. It has exactly the context you hand it, and nothing else. Give it too little and it has to assume — and an assumption you didn't ask for is just a hallucination with good posture.

It's an engine. You drive the car. The model supplies the horsepower; the steering is entirely on you.

So "lying" is the wrong frame. Most of the time the model did exactly what I told it to — I just hadn't told it the right thing. The fix isn't a better model. It's narrating the job the way the model actually needs it.

Framing is the whole skill

What changed my hit rate wasn't clever wording. It was structure — saying the boring parts out loud:

Bounds — what it must not do. This is a conversation, not a code change — don't touch my files.
Success criteria — what "done" looks like. Give me a clean markdown report; don't reformat the findings — I need to review the security details as-is.
Clarifying questions first — let it ask before it assumes. One round of questions kills most of the wrong-direction answers.

Two more things I keep relearning: the first prompt matters most, and it's usually not the biggest — it has to be concise to be accurate. And there's no one-size-fits-all. Each model wants to be driven a little differently. That last point is most of why I ended up building a tool instead of keeping a folder of copy-paste snippets.

So I built a composer

The Prompt Composer is the roughly-90% of what I worked out over that year, turned into something I'd actually use every day: a structured frame, a live preview of what you're really sending, and a way to treat a prompt as a reproducible artifact instead of a throwaway chat message. The free composer is MIT-licensed and the repo is public — pull it apart if you want to see how it works.

Where your prompts live — and where they don't

If I'm asking people to paste their actual prompts — and, in the Pro app, their own API keys — the data posture has to be boring in the right way. The honest, specific version:

The free composer never stores your prompts. The only thing it keeps is a one-way SHA-256 hash, used purely for rate limiting. There's no readable copy of your prompt sitting in a table somewhere.
The Pro app does store prompts — because you asked it to. Saved drafts sync so your work is still there when you come back to it. That's a feature, not surveillance: they're your prompts, kept for you, not mined.
Bring-your-own-key stays encrypted at rest — AES-256-GCM envelope encryption under a server master key, decrypted only at call time. The one concession to usability is the last four characters kept in plaintext, so you can tell which key is which.

The line I actually care about: nothing is kept that you didn't choose to keep, and your keys are encrypted either way.

One honest caveat

None of this makes the model trustworthy. Better prompts get you wrong answers far less often; they don't get you to zero. The whole point of framing — Bounds, Success criteria, a concise first prompt — is to make the output something you can actually check. So check it. Every time. That's not a knock on the tool; it's the job.

If that's how you already think about this stuff, the composer will feel like home. If it isn't yet — that's exactly the year I just described.