Larry's Garage in English

This post starts from a practical problem: I use an AI assistant to write this blog's posts, and without a structure the results were disappointing. The solution I found isn't a magic prompt — it's a working contract. It's called a project prompt, it's public on Codeberg, and in this post I explain why it's built the way it is.

The problem: a blog is a journey, not a stream of posts

I use AI to support my writing, not to replace it. I run the experiments; the AI helps me turn my raw notes into publishable content. Clean division of labor in theory. In practice, in my earlier sessions, without a structure the results swung wildly: scattered output, where the AI took creative liberties, filled gaps with guesswork presented as fact, and quality varied from session to session.

The thing is, Larry's Garage isn't just another content stream. We're telling a journey: a series of experiments with open source and privacy-oriented technology. There's a mission — sharing a critical, mindful approach to new technologies — and an audience we want to reach with something: a different sensibility. Earning that attention takes authority and style. We can't afford invented facts, inaccuracies, or narratives that lose the thread.

Then there's a less obvious requirement: consistency between posts, not just within a single one. Every AI session starts from scratch, and without something anchoring the style, the body of the blog tends to drift over time.

Why just asking doesn't work

The intuitive answer is to write “don't hallucinate” or “don't be sycophantic” in the prompt. I considered it, and discarded it, for one simple reason: those are empty instructions.

A language model producing a hallucination, by definition, doesn't know it's doing it. Asking it not to is like asking someone not to make careless mistakes: if they knew they were wrong, they wouldn't be. Same for “don't flatter me”: an instruction requesting critical treatment, phrased as a blanket prohibition, leaves the behavior essentially unchanged.

So here's the shift in focus: if I can't act directly on the content of the output, I can act a great deal on its form — on the process that produces it. Don't tell the AI what to write; spell out how to work.

Processing behavior, not content

The idea behind the project prompt is this: constrain the AI's behavior to a shape where the context in which hallucinations arise is limited, and the way of working is homogeneous from post to post.

In practice, the prompt doesn't describe the content of the posts: it describes a three-phase workflow, each phase with a human gate. This is the heart of the prompt:

PHASE 1 — DISCOVERY

Purpose: gather information, define the message and structure, populate the session context. [...] Exit criterion (Gate): when all narrative points are covered by real information (no inventions needed), notify me. Decision: it's up to me to decide whether to continue discovery or move to execution.

PHASE 2 — EXECUTION (Drafts)

[...] produce the draft in Italian. I read, revise, request changes. We iterate. Exit criterion (Gate): when I explicitly declare “final draft” or “validated”, we move to Phase 3.

PHASE 3 — DELIVERY (Final Package)

[...] produce a single canvas [...] containing: Italian post, English post, hero image, Mastodon launch posts, Bluesky launch posts.

The gate principle is what convinces me most: the signal comes from the AI, the judgment belongs to the human. The assistant notifies when it thinks it's ready, but the decision to proceed is always mine. These are two different competencies: the AI knows when it has all the information; only I know when my satisfaction is reached. Mixing them would mean either trusting too much (an AI certifying itself) or not using the AI at all.

And there's a deliberate symmetry in the design: the AI never produces content from a later phase without my explicit confirmation, and I can't quietly change content after validation. If I request changes after declaring the final draft, Phase 2 formally reopens and requires a new validation. These aren't bureaucratic rules: they're attempts to close the time windows where error goes unnoticed.

The rules that do the dirty work

The phases would be an empty shell without the substantive rules. Three examples, from the prompt:

Zero inventions. Commands, versions, software names, prices, error messages, URLs: only those present in my input or in the reference documents. If a detail is missing, the assistant stops and asks me. It's the rule that fights hallucinations most directly: it doesn't say “don't invent”, it says “these are the only permissible materials”. An inclusion, not a prohibition.

Binding reference documents. Bilingual signature, image style, social constraints: everything that doesn't live in the prompt lives in documents loaded into the session, and there's an explicit rule: if a needed document is missing, the assistant must stop and ask, not approximate from memory.

Separating observed from inferred. Every statement in the post must declare whether it's something I observed or something I'm inferring. It's the same honesty I demand from my tools, applied to my own storytelling.

(For those who notice these details: the opening line of this post, “This post starts from a practical problem”, is itself an example of the rule — what follows is direct experience, declared as such.)

External validation: having the prompt reviewed by another model

After writing it, I did something that first looked like an affectation: I submitted the prompt to a model other than the one that uses it daily — GLM 5.3, via privatemode.ai, a platform chosen because it offers verifiable privacy, which for this blog's mood is no small detail.

The result: seven suggestions, each flagging a real gap. Some examples:

• what to do when a reference document isn't in the session → the “stop and ask” rule;
• ambiguity about post-validation changes → the Phase 2 reopening clause;
• default behavior at session startup → “every session starts at Phase 1”.

I incorporated them all. The lesson wasn't so much about the individual points as about the method: whoever had written the prompt (me and my assistant) was too familiar with the text to see the holes. Using multiple models isn't an affectation — it's peer review.

The first run

All that said, the rest should be said too: this post is the prompt's first real-world use, and it was born from its own process. It went through discovery, passed through its phases, and is about to be packaged according to its delivery. The test is real, and the first adjustments already emerged during writing — they'll have to go into the next version.

The plan is explicit: after publication, I'll collect the feedback from this round of use, and the prompt will be revised and released as a new version on the repository. The system gets reviewed with the same method it works by.

The prompt

The complete project prompt — current version, in Italian, with all the rules cited above and the others I didn't get to tell — is public here: larrys-garage-md.

It's on Codeberg, not the usual suspects: that's a choice, like everything else on this blog. Codeberg is a service ethically aligned with the project's approach — nonprofit, open source, community-oriented — and that matters more than the convenience of a well-known brand.

And one detail that isn't a detail: the prompt is released under Creative Commons BY 4.0. That's an explicit invitation. If you read this blog and use an AI assistant as an editor, take the prompt, adapt it to your work, modify it. The license only asks for attribution. If you do, I'd love to hear what comes of it.

---

“Free technology isn't just code — it's the freedom to look under the hood.”

👤 Lorenzo | ItsMeLarry 🧪 AI & Open Source Experiments | 🕹️ Retro Gaming & Graphic Novels 🎸 Rock, Folk, Jazz, Punk | 🔒 Privacy First 📍 Tuscany / Digital

🔗 noblogo.org/itsmelarry-en | 🐙 Codeberg