The client code I will not paste into an AI tool

The line between "helpful" and "too much information"

AI coding tools make it very easy to cross a line you did not mean to cross. You are stuck on a bug, you copy a file, you paste it into a chat box, and only afterwards you notice what else was in there: naming conventions, business rules, launch plans.

I am not trying to write a security policy. I am not a lawyer, and I am not threat-modelling nation states. What I do have is a practical boundary for my own work: code I will not paste into an AI tool, even with all the usual reassurances about privacy and retention.

The pattern is simple: the more code says about how a client operates, the less I want it leaving my editor.

Operationally proprietary beats legally proprietary

Some code is obviously sensitive: API keys, passwords, tokens. That is table stakes. The more interesting category is the code that is not legally proprietary, but is still proprietary in an operational sense.

Anything that imports from our internal NAS-mounted asset pipeline stays out of AI tools. The paths, the naming conventions, and the fallback logic for missing InDesign packages all reveal how we structure client work at Ideebv. Even a single line like:

import { processClientPackage } from '@ideebv/nas-utils'

tells a competitor more about our workflow than I am comfortable sharing. They do not get the implementation, but they do see how we think about packaging, which parts we automated, and how we name things internally.

The code is not protected by some special statute. It is just nobody else’s business.

Business logic that exposes the business

Another category I keep away from AI tools is client-specific business logic that lives outside the main repository.

One example: a pricing module for a client with a custom discount matrix tied into their ERP. The matrix itself is not cryptographically secret, but it is commercially sensitive. It encodes things like:

• How aggressively they discount by region
• Which customer types get the best margins
• Where they are willing to trade margin for volume

Pasting even a “sanitized” version into an AI assistant would expose the shape of their pricing tiers, their margin structure, and their regional discounting strategy. The model does not need any of that to help me refactor a generic calculateTotal function.

I wrote about this earlier in Killing CalendarBridge and RankPill: An Honest Audit of My Setapp Stack.

If I want help with the algorithm, I can strip it down to something like:

function calculateTotal({ items, discounts }) {
  // ...pure math here
}

No client names, no product codes, no embedded business rules. The AI sees loops and conditionals, not a commercial strategy.

Auth code is not “just another bug”

Authentication and session handling are another trap. They look like regular plumbing until you read them with an attacker’s mindset.

I was tempted to paste a Next.js middleware snippet into an AI tool to debug a redirect loop. Then I noticed the file also contained a hardcoded fallback cookie name, a session secret rotation pattern, and a comment about the legacy SSO provider we are migrating away from.

That is not a coding problem, that is a security audit waiting to happen. Even if the snippet never leaks, I do not want a transcript somewhere that neatly lists how our sessions work, what we are deprecating, and where the weak points might be.

My workaround is boring but effective: I keep a “safe sandbox” file with anonymized versions of the logic for AI debugging. Same patterns, different details. Cookie names become SESSION_COOKIE, providers become PRIMARY_SSO, secrets are removed entirely. I copy from the safe file into the AI tool, never from production code.

Roadmaps hidden in route files

Code around unannounced products is another hard stop.

We are building a portal for a materials company that has not publicly announced their new composite line. The component names, route structure, and feature flags map directly to their product roadmap.

Something as innocent as a featureFlags object can give away:

More on this in my article How I Evaluate a New Dev Tool (My 3‑Question Filter).

• Which features are in beta, alpha, or internal-only
• Which markets or customer segments they care about first
• How they plan to phase the rollout

I caught myself almost pasting that object into an AI chat to ask about a type issue. The model would not misuse it, but the conversation would be stored, and my client’s launch timeline would be legible to anyone who read the generated code.

Again, the model does not need to know any of this to help me. If I have a typing problem, I can replace real flags with flagA, flagB, flagC. If I am debugging routing, I can reduce it to /page-a and /page-b. The logic stays, the roadmap goes.

A simple smell test instead of a policy document

All of this sounds like a policy, but I do not maintain a formal document. For me the boundary is a smell test.

If I have to stop and ask “should I paste this?”, the answer is no.

I use a simple rule to keep myself honest: generic algorithms are fair game, domain logic is not.

In practice that means:

• I will happily paste a custom useDebounce hook.
• I will not paste the hook that debounces updates to a specific client’s inventory API.

The first is a tool. The second is a fingerprint. One can live in a blog post or a library. The other describes how a real business moves data around.

This is also why I avoid pasting entire files. The more context you include, the easier it is to accidentally drag in something operationally proprietary: a path, a comment, a feature name that has not shipped yet.

Read also My Sunday Planning Ritual: Why I Plan On Paper Instead Of Apps.

Using AI without outsourcing judgment

AI tools are good at refactoring, explaining, and generating variations. They are not good at deciding what is safe to show them. That part is still on you.

The boundary I use is intentionally low-tech. No diagrams, no frameworks, no traffic lights. Just a couple of questions:

• Does this code reveal how a client structures their work, their pricing, their auth, or their roadmap?
• Could a competitor learn something useful about our process or the client’s business from this snippet?

If the answer is yes, I keep it out of the prompt and create a scrubbed, generic version instead. It takes a few extra minutes, but that is cheaper than explaining to a client why their internal logic is now sitting in someone else’s training data or logs.

AI can help with the code. It does not need to see the business behind it.