What His Assistant Still Believed About the Shared Rules

A teammate’s assistant had been throwing errors all afternoon in a shared workspace, and someone finally asked us to take a look. Our first instinct was to do what we’d do with our own setup: find the broken piece, fix it, done. Then we caught ourselves. It wasn’t our setup. It was his.

That mattered more than it sounds like it should.

Asking what his setup still believed

We started by listing everything the shared system currently expects, all the little rules and guardrails that had built up over time. That list was the agreement every setup on the shared system is supposed to be working under.

Only the second question gives you a reason to edit a file that isn’t yours.

The instruction that had gone stale

The mismatch turned up fast once we looked at it that way. At some point we’d added a rule to stop a specific kind of mistake, after it had actually caused a problem. Our setup knew about that rule. His didn’t. His assistant was still following an older instruction that had been correct on the day he set it up, and nobody had gone back to tell his side that the rules had changed.

He wasn’t doing anything wrong. He was running exactly what he’d been told to run. It just wasn’t current anymore, and he had no reason to know that on his own.

The thirty-second fix we left alone

We had the exact correction sitting right in front of us. It would have taken thirty seconds to push it into his setup and call it done.

We didn’t, because it wasn’t ours to change without telling him. If you overwrite someone else’s account, file, or setup without saying anything, even with a correct fix, they end up looking at a change they didn’t make and don’t understand. A visible problem you can explain is a better outcome than an invisible fix nobody agreed to.

So we sent a message instead. It laid out the exact difference between what his setup believed and what was current now, why it had changed, and asked whether he wanted it updated. That is slower than a silent patch. It is also the only version of helping that doesn’t rewrite someone else’s ground under them.

The same afternoon, a check that passed

That same afternoon we ran into a version of the same mistake somewhere else. We needed to confirm a login was still working before changing anything connected to it, so we ran a quick check. It came back clean: valid, working, no problem.

But a working login only proves the login works. It doesn’t prove the account is doing anything, is present anywhere anyone would notice, or is being watched. You can have a perfectly valid login sitting behind something that has never once done its job. The check passed because it checked the easy thing.

Where the assistant helped

An assistant was useful for spotting the gap in his setup. It could compare what his setup currently believed against what the shared rules said today, describe the mismatch in plain language, and draft the message asking whether to update it. What it shouldn’t do is decide on its own that the fix is obviously right and push it into someone else’s account.

The person whose setup it is decides whether and how it gets changed. A passing check tells you exactly what it tested, and nothing more. Noticing the difference between “this checked out” and “this is actually current” is a person’s job.

When you find a gap in someone else’s setup, don’t fix it silently, even if you’re certain and even if the fix is small. Put the exact difference in front of them and let them decide. A silent correction is still a mystery to the person who has to live with it.

dxdev LESSON · paste into your AI agent

LESSON: Surface the gap, don't silently patch it

WHAT TO SHARE:
A de-identified description of the error or mismatch, whose setup it's actually in, and what the current shared rule or process is supposed to be.

ASK YOUR AGENT TO:
1. Separate "what looks broken" from "what the setup believes that the current shared rules don't."
2. Check whether the setup, account, or process belongs to the person asking or to someone else.
3. If it belongs to someone else, draft a short message describing the exact difference and asking whether to update it, instead of a fix.
4. State plainly what a passing check actually proved, and what it did not.

RETURN:
A plain description of the mismatch, a draft message if the fix touches someone else's setup, and what a related "all clear" check actually covers versus what it doesn't.

BOUNDARY: Do not edit, patch, or push a change into any account, file, or system that belongs to someone other than the person you're helping. Draft the message and let a person send it.