# The Habit That Stops Your AI From Quietly Wrecking Your Plan

> Source: <https://dev.to/stkremen/the-one-line-that-stops-your-ai-from-wrecking-your-plan-4jc0>
> Published: 2026-06-18 11:00:00+00:00

This is the third and final part of a little series. In part 1 I worked out the workflow: let the AI build the plan *with* you instead of writing it alone. In part 2 I shared the actual prompts that make an agent plan with you. This one is about the single habit that made the biggest difference of all — and the one I resisted the longest.

It's writing down what the app should **not** do.

For a long time my instinct was simple: tell the AI what to build and how to work, and that's it. Describing what *not* to build felt pointless. Why spend words on features I'm not even making?

Then I noticed a pattern. I'd agree on a clean, small plan with the agent. Then a few prompts later, while building something unrelated, it would casually add an admin panel I never asked for. Or wire up a payment flow "to be helpful." Or refactor a simple feature into a multi-tenant architecture. Every time, I'd lose an afternoon pulling out work I never wanted.

The agent wasn't broken. I'd just left the door open. An AI fills empty space with assumptions — and an unspoken boundary is empty space.

Here's the reframe that fixed it for me: a non-goal isn't a note for humans. It's a guardrail for *future prompts*.

"No payments in v1" isn't there to remind you of anything — you already know. It's there so that three days from now, when you ask the agent to "improve the checkout screen," it doesn't quietly decide that checkout needs Stripe integration. The line holds the boundary even when you forget to.

That's why the moment you delete a non-goal, the idea comes back. The agent rediscovers it, thinks it's helping, and spends your time on it. The boundary only works while it's written down.

The good news: you don't have to think these up yourself. Ask the agent to produce them while you're still planning. Two prompts do the job.

**Surface them:**

```
Based on this plan, list everything you might be tempted to add that I have NOT
asked for — extra features, extra structure, extra integrations. For each one,
tell me whether we should build it now or explicitly leave it out of this version.
```

This is revealing. The agent will list exactly the things it would have silently added — auth systems, dashboards, caching layers — and now you get to say "not yet" *before* it happens instead of after.

**Lock them in:**

```
Take everything we agreed to leave out and write it as a short list of non-goals.
Phrase each as a clear rule, like "Do not add X in this version." I'm going to
keep these in front of you for the rest of the project.
```

Then you do exactly that — keep the list somewhere the agent reads every time (your project instructions, your rules file, whatever your tool uses), so the boundary travels with every future prompt.

People ask whether non-goals are forever. They're not. Keep each one until the thing actually ships, or until you genuinely decide to build it. A non-goal isn't a permanent ban — it's a "not now" that protects your current scope. When "not now" becomes "now," you delete the line on purpose, not by accident.

Looking back, this was never really about planning. It's the same thing I keep running into everywhere I work with an agent: the hard part isn't the code, it's deciding what the agent gets to know — and what it doesn't. A plan is that decision at the start. Non-goals are that decision about the edges. I've got a few more of these fights to write up. They're all the same fight.
