I make every AI response start with one word, and it's saved me from more bad decisions than I'd like to admit. Small habit, big signal. Here's why I never skip it.
I run long AI sessions, not the quick "fix this regex" kind, but the ones where I'm pairing with a model for an hour or two, iterating on a Liquibase migration script, or debugging a flaky integration test in a Spring Boot service. Somewhere around message fifteen or twenty, I noticed a pattern that bugged me for weeks before I did anything about it. The model starts drifting. Not dramatically. It doesn't suddenly forget how to write Java but a constraint I gave at the top of the conversation, something like "don't touch the existing exception handling, just add the new validation" quietly stops being respected. Or the tone shifts from terse code-only answers to chatty explanations I never asked for. Or it starts reformatting things I told it to leave alone three messages ago. Nothing that breaks the build immediately. Just enough sloppiness that I have to reread every response line by line to make sure it's still doing what I asked. That got old fast. The trick, and why it's not really about the trick I picked up a version of this idea a while back — it's been floating around AI power-user circles for a bit: tell the model to start every single response with a specific word, something short and unlikely to show up naturally. I use "ACK" for most of my sessions, mostly out of habit from years of writing message queue consumers, where an ACK means: Yes, I got it, processing now. You just add it to your system prompt or custom instructions: At the start of every response, before anything else, write: ACK That's it. Two seconds of setup. Here's why it actually works, and it's not magic, it's just a cheap signal. If the model still has your full instruction set loaded in its working context and is actually attending to it, it'll dutifully print ACK. The moment that word disappears, or gets buried three paragraphs in, or turns into something slightly off like "Ack." with odd capitalization, that's your canary. Something shifted. Maybe the context window truncated your earlier instructions. Maybe the model just decided this response didn't need the formality. Either way, you now have a visual tripwire instead of having to reread every line of every response to catch drift. I want to be blunt about one thing though: this is not a substitute for actually reading what the AI gives you. I still review every diff before I commit it. The ACK trick doesn't replace vigilance, it just tells me when to be more vigilant. Big difference. Why this reminded me of canary tokens (and why it's not the same thing) If you've worked in security-adjacent systems, and I have — I built a document ingestion pipeline on S3, SNS, and SQS at Encore Capital where audit trails mattered — you've probably run into the concept of a canary token. It's a unique string planted somewhere in a system (a fake API key in a config file, a hidden field in a database record) that should never trigger under normal operation. If it fires, you know someone touched something they shouldn't have. Same underlying principle here: a constant signal whose absence tells you something anomalous happened. But the threat model is completely different. A canary token protects against an external actor, someone probing your system, exfiltrating data, or attempting a prompt injection attack against your AI application. My ACK word isn't defending against an attacker. It's defending against internal drift, the natural tendency of a long-running conversation to lose fidelity to instructions given many turns ago. One is a security control. The other is more like a smoke detector for your own workflow discipline. That distinction matters more than it sounds. It changes what you do when the signal fires. With a real canary token, you're calling incident response. With my ACK trick, you're just thinking "okay, let me remind the model what I actually asked for," and moving on. Where I actually use this at ITJobOpportunities This isn't just a personal quirk for side projects. It's become part of how I work with AI tooling while building ITJobOpportunities, and I want to be specific about where. We run a resume improvement pipeline (the /improve-your-resume flow on the public portal) that takes a candidate's raw resume, sends it through an LLM via OpenRouter with a DeepSeek fallback, and produces an ATS-friendly version, sometimes compiled through LaTeX into a PDF. That's a multi-step conversation under the hood: extract structure, rewrite bullet points, reformat, validate against known ATS parsing quirks. Each step has strict formatting rules I don't want the model wandering from, because a malformed LaTeX escape character breaks the whole PDF compilation step, and the candidate just sees a spinner that never resolves. Early on, while iterating on the prompt chain for that pipeline, I'd get responses that started drifting after a few retries, especially when the resume text was messy — OCR'd PDFs, odd bullet symbols, tables that don't map cleanly to plain text. The model would occasionally start "helping" by adding commentary or restructuring sections I'd explicitly told it to preserve verbatim. Adding a required lead token to the system prompt for that internal pipeline step gave me a dead-simple way to spot when a response had gone off-script during testing, before it ever reached a candidate. Same logic applies to our Job Fit Check feature. When a candidate uploads a resume against a specific job posting, we run an async LLM job that scores relevance and returns matched and missing skills plus a short summary, streamed to the frontend over SSE with polling as a fallback. That's a tightly scoped output: a JSON-like structure feeding a UI that renders progressively. If the model decides to get chatty and wrap the JSON in markdown fences with a friendly intro sentence, that breaks the parser downstream. During development, I used a similar tripwire, not literally "ACK" but a required leading marker, to catch when a prompt revision caused format drift before it ever hit staging. Here's a simplified version of what that looks like in practice, stripped of anything proprietary: SYSTEM_PROMPT = """ You are scoring resume-to-job relevance. Rules: 1. Output must be raw JSON, no markdown fences, no commentary. 2. Start your response with the token: SCORE_OK 3. Never include personally identifiable information in the summary field. """ response = call_llm(SYSTEM_PROMPT, user_prompt) if not response.startswith("SCORE_OK"): log.warning("Drift detected in job-fit scoring response, flagging for review") # fall back to a stricter re-prompt or manual queue That if not response.startswith(...) check is the automated version of eyeballing whether the token showed up. Once you're running this in production, you don't want a human staring at every response anyway. You want the canary wired into your validation layer so it fails loudly and gets logged, not silently corrupts a candidate's job fit score. Where the human version and the automated version diverge For personal AI use, a visual tripwire is enough. You're the human in the loop, you're reading every response anyway (or you should be), and the word just gives you a faster signal than rereading three paragraphs to check tone and constraint adherence. For production AI pipelines, that same idea needs to become an actual assertion in code, not a vibe check. A few ways I think about the difference: Personal chat sessions : a leading token in your custom instructions, checked visually, is genuinely enough. Cheap, fast, no engineering required. Internal tooling / dev workflows : still mostly manual, but worth logging when the token's missing so you can spot patterns over a week of usage, not just catch it in the moment. Customer-facing async jobs , like our resume improvement or job fit scoring: the token needs to be a hard validation gate. If it's missing, don't show the result to the user, and definitely don't silently degrade. Queue it for retry or manual review. Anythi...