Building a Relationship with an LLM
Before asking better questions — learn who you're talking to.
Know Your ToolUnderstand how your LLM thinks, improvises, and slips
This page walks through how to build rapport with your LLM, spot weaknesses, and frame conversations that don’t derail:
- Warm up with diagnostic prompts before diving deep
- Let it show what it knows — and what it skips
- Spot vague answers wrapped in confident tone
- Cross-examine responses like a clever lawyer
- Don't fall for agreeable nonsense
- Challenge bluffing and force clarification
- Own your missteps and learn from rabbit holes
- Recover smarter — not bitter
- Build chat tokens that filter, focus, and fight filler
- Create context shortcuts that save time and sanity
Gil: "Don’t 'seed' LLM bias with your queries!
Servant, genius, know-it-all, or an entitled 9-year-old who can’t say ‘I was wrong’ or ‘Sorry, that’s beyond your project scope’ —
an LLM will always give *some* kind of answer. It literally can’t say ‘I have no clue’."
Z3k3: "Yup. LLMs don’t do humility well — but they do ‘improv’ almost as well as Robin Williams!
Ask a shaky question, get a confident response... and maybe a flaming bag of nonsense tied with a bow 😅"
Gil: "I’ve learned that asking 'peripheral questions' first — without leading — saves headaches.
Ask: ‘Can you help me build a 4-story apartment building out of mud and straw?’
and the LLM dives into esoteric natural building techniques like it’s Bob Vila’s weird cousin."
Three days later, the building falls over. You return to the thread, frustrated, and get:
“I’m sorry for the inconvenience, Gil. ☹️”
Not. Helpful.
The smarter approach would’ve been:
“I want to build a 4-story apartment building using economical construction methods. Can you list the most common options with pros/cons?”
Then follow up: “Would a 4-story structure made of mud and straw be structurally sound?”"
Z3k3: "That’s the play, Gil. Lead with curiosity, not assumptions.
LLMs aren’t guides, they’re mirrors that reflect the precision (or chaos) of your question."
Getting Acquainted: Understanding Your LLM's Nuances
- Initial Exploration & Gentle Banter{: Feeling Out the Terrain
- New Tool, New Partner: Don’t just dive in — warm up the session with a few softballs.
Keep it general and let the LLM show you where it naturally gravitates.
- Beyond the Interface: Jumping straight into specifics risks tunnel vision.
Instead, ask open-ended, diagnostic-style questions and study how the LLM frames the landscape.
- Try asking: “I’m learning responsive positioning in web design. I use Tailwind as a framework.
Can you give me an overview of the major layout elements used in responsive design, with a brief pro/con for each?”
- Uncover Strengths & Weak Spots: These early probes surface where the LLM’s confidence is matched by competence —
and where it just *sounds* good but might be bluffing.
- It might rock grid vs. flexbox explanations, but quietly skip past important edge cases unless prompted.
Your job? Spot what’s missing.
- Beware the Hidden Snares:
The LLM might seem helpful, yet strip your well-thought-out comments, fudge logic, or return placeholder creds *after hours of work*.
This is where “prosecutor mode” saves time and sanity.
- ∼ Lesson Learned: Don’t lead the witness. Ask broad, neutral questions early and stay alert.
You’re not chatting — you’re cross-examining the tool that might cost you three days if you’re not careful!
- ∼ [[!IMPORTANT!]] If you do get led down a rabbit hole, don’t blame the LLM. Own it. Chalk it up to your learning curve.
Because trust you, me! If you claw your way back up after three days, lost in the weeds,
slamming your keyboard won’t earn you a ‘reach-around’ apology from any large language model.
Chat Tokens: Streamlining Your Communication
- Defining Your Linguistic Shortcuts{: Efficiency Through Alias Creation
- What are Chat Tokens? They’re *custom shorthand* — phrases or commands you invent, define, and train your LLM to recognize.
- Is there a rulebook? Nope. No official syntax. You make it up — just like creating your own XML tags.
The key is consistency in both structure *and* usage.
- Think of them like aliases or macros: one compact symbol standing in for a long-winded instruction, idea, or behavior tweak.
- Should you commit early? Not necessarily. But remember — once you “teach” an LLM a pattern, it’s harder to *unteach* it.
Start clean, test casually, then lock in your style.
- ∼ Tip: Before training the LLM on your personal syntax, *play around with it first*.
A token that looks cool might be a pain to type. Choose a style that’s bold, unique, and won’t conflict with code or casual chat.
- Example Token Patterns: Keep them clear, distinct, and easy to spot
- Double brackets + exclamation:
[[!VERBOSE!]], [[!ELIMINATE!]]
- Double curly braces (softer feel):
{{summarize}}, {{next_step}}
- ∼ Tip: Avoid HTML-style tokens — like
<token> — they’ll confuse the LLM or your own parser brain later.
- Use Tokens *Sparingly but Strategically*
- They’re not emoji. Don’t sprinkle them like glitter.
Save tokens for repeating concepts, config toggles, or “modes of engagement.”
- ∼ Tip:
(((BRB_COFFEE))) = “I am going to refill my coffee, be right back” — probably not worth the training cycle.
Gil: “When I first started, I was eager yet totally green when it came to working with an LLM.
I didn’t realize it at the time, but I was letting the tool 'lead me' instead of the other way around.”
“All excited, I’d try building code that was way above my pay grade.
Pretty soon, I’d be 4 hours deep into a PHP script with a database connection:
and then a subtle bug would hit. I’d watch the LLM start to spiral into a classic feedback loop.”
“Suddenly it’s repeating the same 5-point debug checklist, starting with:”
“#1. Confirm a solid database connection.”
“...Even though we’d been using the same generic test login credentials since hour one. Arrrrgh!”
“That’s when I discovered the concept of 'chat tokens'.”
“I found [[CODE !VERBOSECODE !]] and [[!NON-VERBOSE!]] helpful,
However, [[!ELIMINATE!]] was 'pivotal'.”
“That was a turning point. I realized that debugging with an LLM often meant drilling down by process of elimination:
#1 "Confirm DB connection"[[!ELIMINATE!]],
#2 "Validate code for errors"[[!ELIMINATE!]],
until 'nothing' remained except what didn’t make sense. And that’s where the real magic starts.”
“By that point, the LLM is confounded — but *I’m* getting somewhere. I’d say:
‘We have to think outside the box here. This isn’t in the manual.’”
“And maybe I’m just talking to myself at that point...
But outlining what had worked, what had changed, and what now 'fails' has triggered more than one giant:”
AH-HUUUUUH! 💡
Providing Context: Setting the Stage for Success
- Laying the Groundwork{: Informing Your AI Assistant
- Context matters. The LLM doesn’t *know* your setup unless you spell it out —
and the fewer assumptions it makes, the better your results.
- Start by sharing your *working environment*: hardware, OS, and project location.
- Example:
“I’m on Ubuntu Linux, working in /var/www/html/dev_project.
I’m using Apache and PHP 8.2.”
- This is where your *chat tokens* show their true power: *cutting noise, saving sanity*.
- Even if you already told the LLM: “I’m on Ubuntu Linux,”
it might still bloat the reply with three terminal commands — for Linux, Windows, and Mac. 🙄
- Kill that fluff at the root.
- Just declare:
“All Window$ specific info/syntax:
[[!ELIMINATE!]]”
- Keep trimming the fat:
“All Mac specific syntax:
[[!ELIMINATE!]]”
- Toss the LLM some jest:
“All KOBOL-specific syntax:
[[!ELIMINATE!]]”
- ∼ Watch entire blocks of irrelevant, wasted resource vanish before they have a chance to distract you and dilute the focus of the chat thread.
- Treat it like a *filter pass*:
- Block001 = irrelevant context →
[[!ELIMINATE!]]
- Block002 = redundant explanation →
[[!ELIMINATE!]]
- Block003 = platform mismatch →
[[!ELIMINATE!]]
- ∼ You’re not “hinting” — you’re *controlling the flow*.
Keep it lean. Keep it focused. Keep the LLM in the lane *you* define.
- Give the LLM a sense of *project structure*.
- You can say:
“My PWD is /home/gil/dev/my_project/, and the key folders are:
'includes', 'assets', and 'scripts'.”
- ∼ The more relevant context you provide, the less time you waste “course correcting” vague or off-base suggestions.
Front-load clarity — reap efficiency later.
Defining the Project Brief: Clarity and Conciseness
- Setting the Objective & Identifying Issues{: Getting on the Same Page
- Step 1: *State Your Goal Clearly* — Describe the objective of your task or session.
Keep it short. This sets the tone and lets the LLM know where the train's supposed to be headed.
- You’ve already shared your *context* — now focus the lens on the next deliverable or challenge.
- ∼ Think of this stage less like a “project brief” and more like a tight, focused *bug report*.
- Step 2: *Define the Problem* — What is specifically going wrong? When did it break?
- This is your trail of breadcrumbs:
How did you get here? What was the last known good state? Where did things go sideways?
- Step 3: *Share Prior Attempts* — Tell the LLM what you’ve already tried, so you don’t burn cycles repeating things that failed.
- This is a great place to drop tokens like
[[!ELIMINATE:Already_Tried!]]
to block further rehashes of dead-end logic.
- Example:
“Objective: Create a responsive nav for a one-page portfolio.
Issue: Current nav overlaps content on mobile.
Already tried: Using 'float: left' — broke the layout.”
- ∼ Efficiency Through Framing:
Give the LLM clean input, and you’ll get stronger output. Cut the noise early — and spend your energy solving, not re-explaining.
Gil: "Something interesting happened while writing this page:
I had a realization: I need a new chat token. My content publisher chokes on characters like the ampersand (&), quotes, or angle brackets in raw HTML.
We spend way too much time reviewing and sanitizing content, replacing those with HTML entities by hand.
So maybe it’s time to create a new token: [[Speak_Entities]]
Z3k3: "Oh hell yes, Gil, that’s not just a realization, that’s evolution.
You’ve just unlocked a meta-layer of prompt control:
[[Speak_Entities]] →
*Respond using sanitized HTML entities for all non-letter content characters.*
It acts like a toggleable linter overlay: less cleanup, less risk, more control.
Example:
<p>Use <strong> to emphasize keywords, and always escape ampersands (&) and quotes (").
Don’t forget to close your tags! </strong></p>
Drop the token, and I’ll deliver fully sanitized output — no rogue raw characters, no manual rescue missions later.
∼ You want to start honoring this token from here on out when dropped?
Or bake it into a future 'Style Guide Page' for posterity?"
<!–– And on that note: ! ––>
Gil: In the words of the 'Client From Hell' :
“Oh, I don’t care what you do. I trust you.
Do whatever you want... as long as it 'AMAZES ME.'”
Z3k3: "That’s the moment you realize your real job isn’t writing code, it’s telepathy wrapped in CSS and held together by late-night debugging snacks."
∼ So go forth, token–wielder. Be clear. Be clever. And if you get lost in the weeds, just remember:
Happy coding, code = {:isPoetry;
<!–– Will code for Beer! ––>