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 (7)
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.
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.
Great insights. The biggest takeaway is that AI works best when paired with curiosity, verification, and clear problem-solving not blind trust.
I love 2 & 6. I don't joke with it not just AI use.