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 it? Not the drama, just the method. So here it is — the six rules I actually learned, plus the real conversations behind them, mistakes included.
This isn't a technique. It's closer to an attitude, hammered into shape over a year of getting things wrong.
The six rules
1. Don't take "it can't be done" at face value.
AI states limits with total confidence, and sometimes it's simply wrong. Ask again. Ask differently. My biggest breakthrough came from a place AI had already declared impossible.
2. Ask for one thing at a time.
Stack too many requests into one prompt and everything tangles. Break it small, get one piece working, then move to the next. It feels slower. It isn't.
3. Make a copy before you let it touch anything.
AI breaking something that used to work is more common than you'd think. Copy first. If it goes wrong, you have somewhere to go back to.
4. Write down what worked.
Tell the AI the pattern that succeeded and it stops repeating the same mistake. Failures are worth keeping too — a list of dead ends is still an asset.
5. Keep the process simple.
The same result through a tangled process costs more every time — more time, more money, more chances to break. Simple is cheaper and faster, almost always.
6. Say "I don't know" out loud.
Don't perform expertise you don't have. "I have no idea what this is, explain from zero" gets you a better answer than pretending you followed the first one.
What asking actually sounded like
No secret phrasing. Just plain description of what I wanted, admitting up front that I didn't know the technical words for any of it.
"I want this cell to turn red if it's bigger than that cell, but I don't know any code. Explain from the start."
"I want one button. Press it, and the scattered rows line up by date. Is that possible?"
"This screen gets slow when a lot of people use it at once. Walk me through why, and whether there's a fix."
That's the whole trick. Say what you don't know, describe what you want in ordinary words, and the AI meets you where you are.
Where AI actually got it wrong
Trust it. Just not blindly. These are real ones.
The fake limit. When an internal tool I'd built slowed to a crawl under real traffic, AI told me flatly: that's just the limit of the server, nothing to be done. I couldn't accept that answer, so I kept pushing on it, night after night. The real cause was somewhere else entirely — the tool re-fetched everything from scratch on every click instead of remembering what it just loaded. Fix that one thing, and the "hardware limit" evaporated. The limit wasn't the server. It was not questioning the AI's confidence.
The outdated screen. Setting up outside access for the first time, the steps AI described kept not matching what was actually on my screen. Its knowledge had a cutoff date, and the interface had moved on since. The fix was just telling it back: "here's what I'm actually seeing now" — and it adjusted from there.
The thing it deleted. Early on, asking for one small fix would sometimes wipe out something else that had been working fine. That's exactly why rule three exists. Even now, with much better tools, I still make the copy first. Old habit, still worth it.
The one-line version
Say what you don't know honestly — but question "it can't be done" one more time. And always make a copy before you touch anything.
Those three lines cost me the most, across an entire year, to actually learn.
A month from now, none of this will feel dramatic. You'll just have one small tool sitting there that you built. That's exactly where I started too — one small thing, which quietly turned into twenty-two.
Your first one is next. Go find the annoying thing.
This is part of From Zero to Ship — the honest logbook of a non-developer who shipped 20+ working tools with AI. If this resonated, the rest of the series is there.
Top comments (31)
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.
Three cuts, location then disinterest then authorship, and they compress into one test if you ask what each one is actually pricing: could a party with something to gain have produced this same artifact more cheaply than the truth would have cost them. Inside vs outside asks whether the cheap fake is even reachable from where the artifact lives. Stake vs no stake asks whether anyone reachable has a reason to take the cheap route. Authorship by the beneficiary asks the sharpest version of that, whether the party with the motive is also the one holding the pen, which collapses reachable-and-motivated into the same hand.
So the three axes aren't three separate checks, they're the same question asked with progressively less charity toward the artifact's origin. And that reframes what "un-authorable" is actually buying, per your earlier point. It's not that the cost of forging is infinite, it's that the cost of forging has been moved higher than the cost of just doing the thing honestly, for whoever's in a position to fake it. A record clears the bar not by being unforgeable in principle but by making forgery a worse deal than truth for every party who could reach the pen. Reality clears it completely because there's no pen to reach. Everything short of that is a matter of how expensive you made the cheap route, for exactly the people who'd take it.
Compressing the three cuts into one price — "could a party with something to gain have produced this same artifact more cheaply than the truth would have cost them" — is the version I'll be using from now on, because it turns a philosophy question into an accounting one you can actually run. And your correction to "un-authorable" is what makes it usable: I'd been treating it as a binary — forgeable or not — and you've replaced it with a spread: forgery priced above honesty for whoever can reach the pen. That's reachable, which "unforgeable in principle" never was.
The one thing I'd add, from watching this fail in a clinical setting, is that the price is charged in the forger's currency, not the designer's. "Our system is hard to forge" is almost always the designer pricing the fake at their own cost — and the designer is precisely the party with no motive. The cost that matters is the one paid by whoever has both reach and reason, and that person's cost is usually far lower than yours, because reach is exactly what makes it cheap. Controlled-substance records are the sharp example: forging one is expensive for everyone in the building except the one nurse diverting the drug, for whom the pen is already in hand and the motive is the whole point.
Which is why the clinical fix for your worst case — motive and pen in the same hand — is to split the pen: two-person sign-off on the high-risk path. It doesn't make forgery impossible, it re-prices it from "one motivated person writes it" to "two people have to collude," and collusion is the cost spike that does the work. That's your authorship axis run in reverse: if you can't remove the beneficiary from the pen, add a second hand that would have to be bought too. Reality needs no pen; everything short of reality is just how many hands you made a lie require. Cleanest this has ever been in my head — you turned three intuitions into one ledger.
The two-person sign-off is the right move, and here's the actual mechanism underneath it: it's not eliminating the beneficiary from the pen, it's making the beneficiary's cost function additive instead of solo: forging alone costs X, forging with a witness costs X plus whatever it takes to buy or coerce a second signature, and that second number is usually the one that actually deters, not the first.
Where it still breaks: if the same incentive reaches both signers, same nurse-diverting-drugs shape, just two nurses on the same shift who both benefit or one covering for the other, the collusion cost collapses back toward solo cost, because you haven't added an independent party, you've added a second instance of the same interested party. So the sign-off only re-prices forgery if the second hand is actually decorrelated from the first one's incentive. Same reach, same reason, buys you nothing. Which turns add a second hand into add a hand with a different motive structure, a sharper requirement than just headcount.
The additive-cost framing is the clearest version of this I've seen — and the collusion-collapse case is the one I actually live in, since "nurse diverting drugs" isn't hypothetical where I build.
Your sharpening — "a hand with a different motive structure," not just a second hand — is right, and I'd add the part that bit me: motive structure isn't static, so decorrelation you verified at design time drifts. Two signers with genuinely independent incentives on Monday can be correlated by Friday — a reorg puts them under one manager's number, or they've been on the same shift long enough that covering for each other has become the reciprocal norm. Nothing in the sign-off rule notices: headcount is still two, the "different motive" box is still checked from when you checked it. You didn't lose the second hand — you lost the independence of it, silently.
So in my systems the approver-pair independence can't be a role assigned once; it has to be recomputed against the current org relationship every time, because the org tree is the thing that quietly moves underneath it. "Add a hand with a different motive" is the right requirement — the trap is treating it as a one-time check on a property that decays. Same shape as every other gate I've watched break this month: proven independent once, never re-observed, correlated by the time it mattered.
Recomputed rather than assigned is the right frame, and it names something worth generalizing past this one gate: any property verified once and then treated as a fact, instead of a measurement with a shelf life, is going to be wrong exactly when it matters, because the org chart doesn't drift randomly, it drifts toward efficiency, which is toward putting people who work together under the same authority. So independence isn't decaying by accident, it's decaying in the specific direction that makes collusion cheaper, the same direction the org optimizes for on every other axis.
Which means the re-check can't just be scheduled, it has to be triggered by the events that actually move the org graph: a reorg, a manager change, a shared project assignment. A quarterly re-verification catches drift on average but misses the case where two signers get reorganized under one manager the week before the sign-off that mattered. The gate that actually holds probably reads the org system directly at sign-off time rather than trusting a cached independence flag from whenever someone last checked.
"It decays in the specific direction that makes collusion cheaper" is the part that upgrades this from a maintenance problem to a design one. If independence decayed randomly, a periodic re-check would be adequate — you'd catch it on average, and average would be fine. It doesn't decay randomly. It decays along the same gradient the org optimizes for, which means the failure isn't in the tail, it's in the direction of travel. A scheduled check is calibrated for noise and the thing it's watching is a trend.
I arrived at "read it at use time" from a much weaker direction and I think your reason is the load-bearing one. In my systems the equivalent problem was date-triggered state — records that change status when a date arrives. The obvious build is a nightly job that updates them. I stopped doing that, but only because scheduled jobs quietly fail to run and the gap is silent; the fix was computing the state at read time, from the date, every time it's asked. Same shape as your sign-off-time org read, but my justification was "the scheduler might not fire." Yours is stronger: even a scheduler that fires perfectly is sampling a moving target at intervals chosen for convenience, not for how fast the target moves.
One thing I'd add underneath it, because it's the half I've actually built elsewhere: reading the org graph at sign-off is necessary but leaves nothing behind. Six months later the question isn't "were they independent" — it's "on what basis did this pass," and by then the org has moved again and you cannot reconstruct the graph as it was. So the read has to be written into the approval record: the specific relationship path evaluated, and the fact that it was evaluated at all, present rather than absent. Otherwise the audit trail degrades into "the system allowed it," which is the same self-report we keep circling back to.
And a design question I don't have a clean answer to: if the org system is unreachable at sign-off, does the approval block or proceed on the last known state? Fail-closed makes an HR outage stop consequential work; fail-open reintroduces exactly the cached flag you just eliminated, only now it's invisible because it only appears during incidents. I've built the receipt half and not the recompute half, so I'd genuinely like to know which way you land on that.
Fail-closed for the sign-off itself, but the honest version of fail-closed here isn't silence, it's a loud, logged exception path, not the same failure shape as the cached flag you're trying to eliminate. The reason to prefer blocking: an HR outage is rare, bounded, and visible the moment it happens, someone notices immediately that approvals are stuck and escalates. A silently stale independence check is none of those, it's common, unbounded, and invisible until the exact moment it matters, which is a worse failure to build toward even though it's a better failure to experience day to day.
Where I'd actually let it proceed: only for the reversible half of what gets sign-off, if such a half exists in your system, the same advisory-versus-irreversible split that keeps showing up in this thread generally. An approval that can be revoked or re-audited after the fact if the org graph turns out to have been stale can fail open with a stamped exception, org-system-unreachable-at-T, approved-under-exception-pending-recheck, and a mandatory re-verification once the system's back. An approval with no revocation path, the one your receipt half is actually protecting, has to fail closed, because there's no later moment to catch the mistake in.
So the design question isn't fail-open-or-closed as a global policy, it's which of your sign-offs are cheap to unwind and which aren't, and the org-outage behavior should split along that line rather than applying uniformly to both.
The reversibility split is the answer, and mapping my own sign-offs onto it was clarifying in an uncomfortable way — because the line doesn't fall where the approval workflows are shaped.
Most of what I gate is genuinely unwindable: a scheduled change that hasn't taken effect, a posted item that can be retracted, a payment that at worst becomes a clawback. Ugly, but there's a later moment. The exception is the category I'd never have filed as high-stakes: viewing. Access to evaluation results, personal records, anything where the approval grants a read. Those look like the lightest approvals in the system — no money moves, nothing is created, and the natural instinct is to put them on the permissive side during an outage. But a read has no revocation path at all. You can claw back a payment; you cannot unsee a colleague's evaluation. So the split I'd have drawn by consequence-severity puts reads in the cheap bucket, and the split by reversibility puts them in the strictest one. That inversion is the useful part of your framing for me.
One thing I'd add about the stamped exception, from a mistake I've already made elsewhere:
approved-under-exception-pending-recheckneeds an expiry, not just a flag. A pending-recheck marker with no deadline becomes the new normal state, and nothing in the system distinguishes "waiting for HR to come back" from "nobody ever came back." I ran into this with known exceptions in a scanner — they were printed in the report and excluded from pass/fail entirely, so the exception list quietly became the baseline. The fix was giving each one an accepted date and a condition that kills it, and failing the run when one outlives it. Same treatment here: the stamp records when the exception was granted, and if the re-verification hasn't happened by the time the org system has been reachable for N days, that's an alarm rather than a backlog item.Reads having no revocation path is the piece that actually corrects the reversibility split, because it's counter-intuitive in exactly the direction that matters: severity-by-consequence and severity-by-reversibility usually point the same way, and the one case where they invert is the one nobody double-checks, since a read looks like the safe default precisely because nothing downstream changes. The clawback-versus-cannot-unsee framing is the right test to generalize from, and it probably reclassifies more of a typical system's light approvals than the reversibility framing initially suggests.
The expiry point is the one worth stealing outright, and the scanner precedent makes the failure mode concrete: an exception without a deadline doesn't stay an exception, it becomes a silent amendment to the policy, and the tell is exactly what you found, the exclusion list quietly turning into the baseline nobody re-reads. Tying the expiry to org-system-reachable-for-N-days rather than a fixed calendar date is the right anchor too, since a calendar expiry would fire during an outage that's still ongoing and a reachability-based one only starts the clock once there's actually something to re-verify against.
Your prediction about reclassification held up the moment I looked. The second one in my system is notifications — anything where approval results in a message going out to staff. It sits in the same "light approval" band as reads for the same reason: nothing is created, no money moves, and it's trivially correctable in the sense that you can always send a follow-up. But a correction is a new message, not an undo. The original was read, and the read is the irreversible part again. Two categories now, both filed as low-stakes by consequence, both with no revocation path — and I'd guess the pattern is that anything whose effect lands in a human head rather than in a record is in this class.
On the reachability anchor, there's a dependency I want to name before I build it, because it's the same shape as everything else in this thread: the clock only advances if something is actually measuring reachability and writing it down. If that probe stops, the counter never increments, and the exception stays valid forever — not because the org system is down, but because nobody is checking whether it's up. "Unreachable for a month" and "unmeasured for a month" produce an identical stalled clock, and the second one is the failure that doesn't announce itself.
So the anchor I'd actually implement isn't "the system has been reachable for N days" but "reachability has been measured on N distinct days, and it was up on those days." That way a missing measurement is a gap in the record rather than a silent pause in the timer — the exception can't outlive its deadline by starving the thing that counts. Which is a slightly annoying amount of machinery for what started as "add an expiry to the stamp," but every version of this I've built has ended up needing the layer that proves the counter itself is still counting.
The notifications case is a clean second instance because it isolates the mechanism: nothing created, nothing moved, and still no way back once a person has read it. That is a sharper definition of the class than reversible-by-consequence, it is reversible-by-record.
One thing worth building into the reachability anchor before it ships: measured on N distinct days only helps if the measurement itself cannot silently degrade into a no-op that still writes a plausible log line. A cron job that logs checked, reachable=true without ever making the call satisfies your fixed version exactly as well as a real probe does, and produces the identical failure mode you just diagnosed, one layer up. The floor under measured has to be something the prober cannot fake by doing nothing, a counter or heartbeat that something outside the prober can check independently. Otherwise the fix inherits the bug it was written to close.
"The fix inherits the bug it was written to close" — that's the sentence, and
you're right that N distinct days doesn't survive it.
One sharpening on the floor, because outside-observable is necessary and I don't
think it's sufficient. A counter the prober increments is still fakeable by a
prober that increments without probing; you've moved the no-op one instruction
to the left. What makes it un-fakeable is a content requirement, not a location
one: the record has to carry something the prober could not have produced
without the remote call. A server-set header, an etag, a build hash, any value
the far side controls. Not "I called it" but "here is something only it could
have given me."
That also closes the regress for free, which the heartbeat doesn't. A heartbeat
needs a watcher, and the watcher needs one. A record carrying remote-originated
content can be checked by a third party who trusts neither the prober nor the
watcher.
I went and looked at my own after reading this. My deploy verification records
the build hash it found in the live HTML — a no-op can't produce that. It also
records "the index page contains the title," which is a boolean my own script
authored, and which a prober doing nothing would report identically. Same
script, same run, two probes, one of them worthless. I hadn't noticed the
difference until you named it.
And reversible-by-record has a property reversible-by-consequence doesn't: the
irreversibility is instantaneous. A row can be deleted an hour later. A read
notification cannot, which means the friction has to sit before the send, not
anywhere after it. That changes where the guard goes, not just how heavy it is.
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.