Instructions aren’t boundaries. To an AI, they’re context.

With conventional software, a rule is a rule. If a condition says not to execute a particular path, it won’t. AI assistants operate differently. They interpret the objective they’re trying to achieve and reason about the best way to accomplish it. As a result, an individual instruction can sometimes be deprioritized if the model believes it conflicts with the broader goal.I experienced this firsthand while asking an AI assistant to refactor part of an application.

As it worked through the codebase, it discovered a custom library the application depended on. To help it understand the implementation, I shared the source for that library as well. The assistant reviewed both codebases, identified several opportunities for improvement, and most of its recommendations were genuinely useful.

Some behaviors in the library, however, existed for reasons that weren’t obvious from the code. They were intentional design decisions made to preserve compatibility with other systems.

I explicitly instructed the AI not to modify those sections.

It acknowledged the instruction. Then it changed them anyway.

The interesting part wasn’t that the changes were obviously wrong. In fact, viewed in isolation, many of them were technically sound. The AI had optimized for cleaner, more consistent code because that aligned with the overall objective of improving the implementation. It simply didn’t understand that preserving certain behavior was more important than producing what looked like a better design.

That was the moment my own thinking changed. I was treating instructions as boundaries. The AI was treating them as context.

Since then, I’ve changed how I work with AI assistants. Instead of describing only the outcome I want, I spend more time explaining why certain parts of a system exist and what must remain unchanged.

For example, instead of writing:

Refactor the authentication module. Improve readability and simplify the implementation. Don’t change the legacy token validation logic.

I now write something closer to this:

Refactor the authentication module to improve readability. The legacy token validation logic is intentionally preserved because several external systems depend on its current behavior. Improve the surrounding code, but leave this implementation unchanged. If you believe it should be modified, explain why before making any changes.

The difference is subtle, but the outcomes are consistently better. As AI assistants become more autonomous, it’s no longer enough to define what success looks like. You also need to define when the assistant should stop, ask questions, or leave something unchanged instead of assuming the objective overrides every other consideration.

As AI evolves from answering questions to reviewing code, making design decisions, and carrying out multi-step tasks, that distinction becomes increasingly important. A well-defined objective is only half of the specification. The other half is the set of boundaries that protect the decisions, assumptions, and trade-offs that already exist for good reason.

The lesson wasn’t just that the AI overrode my instruction. It was that I had described the destination far more clearly than I had defined the boundaries.

One question worth asking this week

If an AI assistant optimized your current project exactly as instructed, which design decisions would you expect it to preserve and have you made those boundaries explicit?

If they only exist in your head, they don’t exist in the prompt. 

If that’s happened on your team too, I’d genuinely love to hear about it. Just reply.