Do Not Quietly Fix Someone Else's Setup

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

That distinction matters more than it sounds like it should.

”What’s broken” is the wrong question

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

The real question wasn’t “what’s broken in his config.” It was “what does his setup still believe that the rest of us have moved past.” Those are different questions, and only one of them lets you fix things by editing a file that isn’t yours.

The instruction that had gone stale

The mismatch turned up fast once I 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. My 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 since 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 there was no reason he’d have known that on his own.

The easy fix I didn’t take

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

I didn’t, because it wasn’t mine to change quietly. Overwriting someone else’s account, file, or setup without saying anything, even with a fix that’s genuinely correct, leaves them 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 instead of a fix, I sent a message: here’s the exact difference between what your setup believes and what’s actually current now, here’s why it changed, do you want it updated. That’s a slower path than a silent patch. It’s also the only version of “helping” that doesn’t quietly rewrite someone else’s ground under them.

A passing check that wasn’t checking the right thing

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

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

Where AI fits

An assistant is genuinely useful for spotting this kind of gap. It can compare what a setup currently believes against what the shared rules actually say 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 or setup.

The human decision

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. It’s a person’s job to notice the difference between “this checked out” and “this is actually current.”

The lesson

When you find a gap in someone else’s setup, don’t quietly fix it, 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.

The paired Build Log walks through both moments from that afternoon, the stale instruction in a teammate’s setup and the login check that proved less than it looked like it did, and why the right move in each case was to name the gap out loud rather than close it quietly.

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.