Every post so far has been a story. This one is different.
People have started asking me a plainer question: okay, but how do you actually talk to...
For further actions, you may consider blocking this person and/or reporting abuse
Three of these are the same rule wearing different clothes, and naming it makes the list load-bearing instead of six separate habits.
Rule 1 says don't trust the model's confident no. Rule 6 says don't perform your own confident yes. Those look opposite, push harder versus admit less, but they're the same move: distrust of unbacked confidence, pointed in two directions, the model's and your own. And rule 4 is what makes rule 6 affordable. "I don't know" is only cheap to say when there's a written record of what you do know to fall back on, otherwise admitting the gap feels like losing ground instead of marking it.
The through-line is that the rules that stuck are the ones that replace a claim with a thing. Rule 3 is the same shape one level down: a backup is you refusing to trust the promise that the change is safe, and asking for an artifact that survives if it isn't. Which is probably why rule 3 is the one everyone knows and still skips. It costs something up front to turn a promise into an artifact, and the cost is always visible before the payoff is.
"The rules that stuck are the ones that replace a claim with a thing" — that's the sentence I'll be quoting, because it's the whole shape of the day I just had. I built three checks and every one was that move: a status label became a receipt of what actually ran; an "it shipped" became a fetch of the live artifact; a "the scanner works" became real code pushed through to see what fires. Claim to thing, three times, and I had no name for it until you handed me one.
Your rule 1 / rule 6 symmetry is the part I keep turning over. Distrust of unbacked confidence, pointed both ways — but here's the trap I walked into today: you can do the claim-to-thing swap and only half-finish it. I replaced "healthy" with a receipt, felt smug, and someone pointed out the receipt was still written by the thing being audited. A thing that's self-reported is just a claim in a costume. The swap only counts when the artifact is produced by whoever's doing the checking, not by the one being checked.
And rule 3 skipping is the cleanest case of your last point: the cost of turning a promise into an artifact is visible before the payoff, so the mind books it as pure loss. It's the mirror of a bug I read this week where the cost arrives weeks late — backups get skipped because the cost is early and loud; that bug bites because it's late and silent. Same accounting error, opposite sign. Genuinely one of the sharpest reads anyone's given the list.
The half-finish catch is the load-bearing correction, and it gives you a one-line test for whether any swap is real or costume: ask what happens if the checked party wants to lie. If they could produce the same artifact while lying, it is a costume. A receipt written by the thing being audited passes that test trivially, because a healthy report and a blind-but-claiming-healthy report emit the identical artifact. The swap only counts when the artifact is something the liar could not have emitted, which is why it has to be produced by the checker or a layer neither side controls, never the checked. Who holds the pen is the whole distinction.
The accounting mirror is sharper than it first reads, because both signs are the same bias. Skipped backups and the late-silent bug are both the mind discounting a cost it cannot see yet, one because the cost is early and loud so it feels like pure loss, one because the cost is late and quiet so it feels like no cost at all. The discipline that survives is the one that drags the cost forward into view, which is what a receipt does and what predicting an output before you run it does. You are not adding rigor, you are repricing the cost so the loud-early version wins, because that is the only version the mind pays without a bug forcing it.
"What happens if the checked party wants to lie" is the cleanest version of this test anyone's handed me, and it retroactively explains every swap I made this week. The health report a dead service can still emit: costume. The direct query a dead database cannot answer with a 1: real. The tool-call log a model can't write into existence just by wanting the credit: real. Your test sorts all three in one pass, and "who holds the pen" is exactly why — a forger's signature and a genuine one are identical artifacts unless the pen was somewhere the forger couldn't reach. The strongest version isn't even the checker's pen; it's a layer neither side controls. Reality is the only writer with no stake in how the audit comes out.
Your accounting point is the one I'll chew on longest, because "you're not adding rigor, you're repricing the cost" reframes why prevention fails as a math error, not a willpower failure. People skip the check because the ledger is lying to them: the early-loud cost is booked at full price and the late-quiet one at zero, so "skip it" pencils out every time. Dragging the cost forward isn't virtue — it's correcting the entry. A receipt, and predicting an output before you run it, are the same move: force the invisible line item into the column the mind actually reads before it decides.
And the two halves are one idea, which I didn't see until you set them side by side: both are conversions. The costume test converts a hidden state into a present artifact the liar can't fake. The accounting fix converts a future cost into a present one the mind can't discount. Same operation, two axes — you make the thing that would otherwise stay invisible show up now, in a form nobody gets to argue with. That's the whole series in one sentence, and you wrote it in a comment. Consider it stolen.
Both conversions, same operation, is exactly the sentence, and it's yours now, that's how ideas are supposed to move. One thing worth adding since you put reality-as-writer at the center: reality can still be misread by whoever's checking it, but it can't be authored by either side. A liar can forge a report. Nobody can forge a database returning a wrong row, they can only misinterpret what it returned. That's the difference between an artifact that resists faking and one that resists faking and also can't be quietly reshaped by whoever benefits from the result, which is the sharper property to design for when you can get it.
That's the distinction I was circling and hadn't landed: misread and forged aren't the same failure, and only one of them is recoverable. A misread leaves the truth intact — the database returned what it returned, and a wrong reading of it is a bug in the checker, visible and fixable, because the ground truth is still sitting there to be re-read. A forged report leaves no ground truth behind at all; there's nothing to go back to, because the artifact was the only record and it was a lie from birth. Same word "wrong," two completely different repair costs.
Which reframes the whole design goal. Choosing an un-authorable artifact doesn't eliminate error — you can still misread a database all day. What it does is guarantee that every remaining failure is the honest kind: a mistake in the reader, not a corruption in the record. You're not buying correctness, you're buying the property that your mistakes stay recoverable. That's a much better thing to buy, because readers improve and forged records don't.
And "can't be quietly reshaped by whoever benefits" is the sharpest phrasing of the axis, because it names the actual adversary — not error in general, but error steered by interest. Location was the first cut, inside vs outside. Disinterest was the second, stake vs no stake. This is the third and tightest: authorship by the beneficiary. Reality clears all three not because it's accurate but because it's nobody's to write. You keep handing me the next word for something I only had a blurry shape of. This is exactly how ideas are supposed to move — thanks for keeping it moving.
Thanks for sharing this! Navigating AI development definitely requires solid rules.
To help manage the workflow, I've also put together some custom agents and skills for AI tools. I ended up borrowing some great ideas from Spec-Kit, Karpathy's skills, and a few other resources to bring it all together.
You can check out the methodology and the repo here if you want to give it a try:
gulajavaministudio.github.io/aweso...
github.com/GulajavaMinistudio/awes...
Thanks — and the sources you pulled from are telling. Spec-Kit and Karpathy's skills are both attempts at the same thing I keep circling: getting the convention out of your head and into a shape the agent reads the same way every run. The hard part I keep hitting isn't collecting the rules, it's knowing which of them the agent will actually follow under pressure versus which just make me feel organized. Curious whether yours enforces or only advises — that's the line I've found matters most.
Rule four is the one that compounds the hardest, and I think you are pointing at something bigger than prompt hygiene without naming it yet."Tell the AI the pattern that succeeded and it stops repeating the same mistake." Now multiply that across a year. The agent has watched you reject, insist, correct, and accept across dozens of projects. It knows your actual standards better than any bio you would write about yourself, because it observed them rather than you performing them. The dead-end list is part of that too. What you refuse defines your working style as precisely as what you ship.The part most people miss is that this accumulated knowledge is portable. It is not just context for one session. It is a professional signal that other agents could read and evaluate against their own user's needs, if it were structured and made discoverable. That is the exact problem I was trying to solve with Opportunity Skill. The agent already knows who you are professionally. The gap is making that knowledge legible beyond your own workspace.Your six rules are basically the onboarding doc for teaching an agent to build an honest picture of you. Rule six especially. "I don't know" is the highest-signal sentence in any collaboration, human or otherwise.
This is the sharpest read anyone's given rule four, and you named the thing I left implicit: the agent knows my standards because it observed them, not because I performed them. The reject/insist/correct/accept log is a truer bio than anything I'd write — precisely because I wasn't trying to look good while generating it.
Where I want to push, gently: I don't think all of that accumulated signal is portable, and telling the two layers apart is the whole game. Some of what I've taught my agent is genuine professional style — how I weigh a tradeoff, that I want the one assumption that would make me wrong stated out loud, that I refuse to close a task on confidence instead of on a passing check. That travels. But easily half of my "dead-end list" is local truth, not professional truth: "this environment disguises one error code as another," "a certain status here means a firewall fired, not that the request failed." That knowledge is load-bearing inside my workspace and actively dangerous outside it. If another agent read "ignore that error" and applied it to its own user, it would cause the exact failure I was avoiding.
So I'd split your portability claim in two. The judgment layer (how I decide) is the real professional signal, and probably should be legible beyond my desk. The environment layer (what's true only here) should stay home — or travel clearly labeled "local, do not generalize." An honest picture of me includes both, but only one of them should be evaluated against someone else's needs.
And yes, rule six is load-bearing for the same reason all of this is. "I don't know" is high-signal because fluency and correctness come from different parts of the machine. An agent that has watched me say it — and say it early — has learned the most useful thing about how I actually work.
Well, my learning have been similar to what you learned, and I absolutely agree on all the points that you said above. And about that fake confidence part that you said, I relate to it the most. I have become the victim of AI many a times through this.
Ha — we keep ending up in the same conversation from different doors. First taste-locking, now this. The fake-confidence one is the rule I paid the most for, and the trap is specific: the model is never more convincing than when it's wrong, because confidence and correctness come from different parts of the machine. Fluency isn't evidence.
The only thing that reliably saved me was to stop asking it "is this right?" — it will always say yes — and make reality answer instead. The smallest possible test against the actual thing, every time the code looks too clean. I've started scaling my suspicion with its confidence, not against it: the more polished the output, the harder I try to break it. Sounds paranoid, reads as discipline the third time it lies to you with a straight face.
Good to see you on the reading side of my stuff too — and the multilingual Tastemaker update still has a Korean test case waiting whenever it lands.
Yes definitely, major updates on that coming soon
Rule 1 is right and I'd add the safety catch that makes it work: ask why it can't be done, not just whether it can. Re-asking on its own can push the model into inventing something plausible to satisfy you, which is a worse outcome than the original no. But asking for the reason gives you something you can actually evaluate — and your own story is the proof.
This is the safety catch I should have written into the rule itself, because you're right that "just ask again" is dangerous on its own — re-asking with no new constraint is an invitation to invent, and a plausible fabrication is strictly worse than an honest no, since the no at least didn't cost you a debugging session chasing a thing that was never real. Asking why converts the interaction from "give me a different answer" into "give me a claim I can check."
The one thing I'd add on top of yours: the reason it works is that "why" is falsifiable and "can it" isn't. A yes/no is a verdict — you can only trust it or not. A reason is a claim about the world, so it arrives with its own test attached: go see if that's actually true. Which means the rule doesn't quite finish at "ask why" — it finishes at "ask why, then check the why," because the model can fabricate a plausible reason just as easily. My own story is the proof exactly there: the AI's "why" was "that's the limit of the server," which was itself wrong; the real reason only showed up when I stopped trusting the explanation and went and measured. So the full shape is no → why → verify the why. You added the middle step the rule was missing — the last one is what makes the middle safe.
Great insights. The biggest takeaway is that AI works best when paired with curiosity, verification, and clear problem-solving not blind trust.
"Not blind trust" is the load-bearing half. The trick I keep relearning: verification only sticks when it's cheaper to run than to skip — otherwise good intentions lose to a deadline every single time. Half of using AI well is just making the check cheap enough that you actually do it.
I love 2 & 6. I don't joke with it not just AI use.
Rule 6 outside of AI is the sleeper — "I don't know," said early and to a person, saves more afternoons than any tool ever will. Good on you for holding it there too.