Enter SQL in my life-as-a-non-developer, a true story.
When I need to check anything in Rivale database, I ask Claude Code, the agent I “wired” to the app (context, rules, and everything) so it knows everything about my product. Yeah, right…
I ask for a simple SQL query to use. It spits out 100% made-up columns that are not in the SQL tables.
How do I know? I had errors since the early days, and when pasted back into Claude, it commented with variations of:
“Yeah, that’s on me. I should have checked schema for the real columns […]”
A diabolically masked-as-confident answer, plainly wrong to my request.
Classic Claude.
Actually, classic LLMs.
After the first weeks, I had enough: F**k you, you f****ing lazy a**! (this is the sanitized version)
Building Rivale as a solopreneur means every friction like this is mine to solve. I either find a way, or I drop the ball on that thing and rethink it as a whole.
So I went hunting. Three defenses, in order.
Defense 1: correct it by hand
Every single time, I prompted the required action: “Give me this and that SQL. Check schema before sharing it back with me!”
Failed. There were sessions in which Claude followed my prompts, but that felt more like a few lucky moments than a structural improvement. The overall % of sessions with wrong SQL as the first output barely moved.
Defense 2: put the rule in CLAUDE.md
I researched, learned about CLAUDE.md and its importance, and added a specific rule at the very top of the file. I thought: this loads at every session AU-TO-MA-TI-CAL-LY, hence it has to work since it will be read at the beginning of all sessions!
Failed. Even though I kept reading “tips” from “experts” that if you want your Claude to do/know/remember something, you have to add it to your CLAUDE.md file. That’s partially correct, mostly misleading.
Defense 3: stop asking. Make it mechanical.
Fast forward to the moment I learned about hooks. Oh my.
I always had the solution right before me, at least theoretically, in my Claude setup. But I couldn’t see it because hooks get much less attention and I hadn’t thought about them ever.
Everyone talks about prompts, skills, agents, no? But a more important question is: why? Why these and not hooks?
I see hooks as the gears that make an agentic system deterministic. The power of hooks? They’re mechanical rules, they can’t be skipped, they always fire.
Eur-hook-a!
So today, this sits in my setup. It fires on any prompt that mentions SQL, before the model can answer:
name: sql-schema-check
enabled: true
event: prompt
pattern: (?i)\b(sql|schema|column|table|select |insert |update |delete |alter |create table|rpc|migration|42703|42601|42P01|does not exist|syntax error)\b
action: blockRead that last line again: block. Claude cannot answer me until it has checked the real schema.
No more back and forth with made-up column names because my LLM is lazy doing its work but so strong in faking it’s done it following my prompts and rules.
I’m breathing again (instead of capslocking my frustration back to Claude).
So what, Matteo?
- A request within a prompt, even a well-structured one, is easy to ignore by the LLM.
- A rule in your files could potentially be ignored as well because it competes with everything else in the context.
- A mechanical rule/hook always fires. It can’t be silently skipped. Read it like a human would do: the check happens every single time, whether the LLM feels like it or not.
- What a hook can’t do is think for you. Mine catches invented column names. It does not catch SQL syntax or query logic.
Claude Code pays nothing for being wrong. I’m the one who pays, every time, both in tokens and productivity (= money + efficiency + sanity).I stopped asking my AI to be less lazy and started removing the choice. That’s the whole shift: from persuading the model to constraining it.
Which repetitive things did you turn into a rule/skill/hook? Let me know on LinkedIn.