What I Never Put Into an AI Tool

I use AI heavily. I also have a rule I don't bend: proprietary work doesn't go into it. Not the code, not the architecture, not credentials or business logic. If it belongs to the engagement, it stays inside the engagement.

Most people assume that rule costs me the benefit. It doesn't — and the reason why is the interesting part.

Why absolute beats sensible

The boring reason: in enterprise work, "where did this data go" is a question with legal weight, and the answer has to be simple and provable.

The real reason: a rule containing judgment calls fails under deadline pressure. "Don't share anything sensitive" asks a tired engineer, at 7pm before a release, to classify what counts as sensitive. Eventually that call goes wrong. "Nothing from the engagement" requires no classification at all.

Good guardrails aren't the theoretically optimal ones. They're the ones that still hold when nobody has time to think — which is exactly when they're load-bearing.

Why it costs less than expected

The constraint made me better at using these tools.

If I can't paste the module, I have to reduce the problem to its shape: strip the domain, keep the structure. What's really being asked is a question about state synchronization, or cache invalidation, or a rendering boundary. That reduction is engineering work — the same work that makes a problem tractable for a colleague.

Two things follow consistently. The reduction often solves the problem — by the time something is abstract enough to describe safely, I usually understand it well enough to fix it. And the answers come back better: a cleanly stated question gets a well-grounded answer, while a question buried in three hundred lines of domain code gets one entangled with details that don't matter.

Where it genuinely costs

Whole-codebase reasoning is off the table. Large refactors get decomposed by hand. Tracing an unfamiliar bug through a real system is slower.

Real losses — and I take them, because the alternative isn't "the same work with slightly more risk." It's an unbounded, unauditable exposure of intellectual property I've been trusted with. That trade isn't close.

The pattern that generalizes

Every team draws this line somewhere. The ones that draw it well share four traits:

• The line fits in one sentence, decided in advance. A policy that needs a paragraph gets approximated, and everyone's approximation differs.
• Categories, not sensitivity levels. "Nothing from client repositories" is enforceable. "Nothing sensitive" is a vibe.
• The sanctioned path is genuinely good. A restriction with no supported alternative gets routed around.
• It's framed as craft, not compliance. "We don't put client material into external tools" lands as professionalism. "Legal says we can't" lands as an obstacle.

The point

The teams that get the most from AI won't be the ones with the fewest restrictions. They'll be the ones whose restrictions are simple enough that everyone actually follows them — because the compounding value comes from consistent daily use, and consistency requires a rule nobody has to deliberate over.

Mine fits in a sentence. I've never had to reconsider it mid-sprint. That's the entire design goal.