Gemini 3.8 is absolutely

I’m a Pro user and the model just doesn’t listen anymore.

I give it some rules/instructions, it says “okay got it”, and then literally the next prompt it forgets everything and starts doing some random I never asked for.

Sometimes it creates random files, adds code/functions I didn’t ask for, starts doing extra tasks, or just completely ignores what I told it to do.

And the funny thing is, I can literally say:

“Don’t do this. Only do this.”

Gemini: “Sure :+1:”

Next response: does exactly the thing I told it NOT to do

I don’t know if something changed with 3.8, but the instruction following has been really bad for me lately

Anyone else having the same issue?

I’ve learned a lot about prompting over the past few months. When you say “Don’t do this”, it’s a pink elephant problem. What do you have to do to “not think of a pink elephant”? Same thing happens with LLMs.

I’ve made numerous other observations about prompting. I’m capturing the results in a formal project I call “synthetic scars”. The pink elephant problem becomes an obvious trap. Synthetic Scars is a work in progress… for our public press so far

The issue you are seeing with Gemini 3.8 is a known symptom of conversational prompt drift, not an inherent degradation of the underlying reasoning engine. When an agentic LLM begins creating phantom files, introducing unrequested helper functions, and ignoring explicit prohibitions, it is almost invariably the result of three specific architectural anti-patterns:

1. The Token Attention Trap of Bare Negative Constraints

Randal rightly points out the “pink elephant” phenomenon, but the mechanics go deeper into transformer self-attention. When you prompt:

“Don’t create new files. Only do this.”

The attention heads attend heavily to the high-entropy semantic tokens: create, new, files. In a high-temperature or complex reasoning turn, the model computes probability vectors based on semantic proximity. A bare negative constraint frequently acts as an attention magnet, priming the model to generate the exact behaviour you sought to forbid.

The Fix - Paired Invariant Framing: Never supply an isolated negative constraint. Every constraint must be formulated as a strictly paired invariant: an explicit positive mandate coupled to a bounded negative exclusion:

  • Sub-optimal: “Don’t create any files.”
  • Architecturally Sound: “Positive Mandate: Restrict all edits exclusively to existing lines within src/controller.js. Negative Constraint: Absolute prohibition on instantiating new files on disk.”

2. Context Decay and the Fallacy of In-Chat Governance

You noted that you give rules, the model replies “okay got it”, and then forgets them on the subsequent prompt.

An in-chat acknowledgement (“okay got it”) is ephemeral conversational fluff. In a multi-turn chat, your rules compete against the system prompt, tool schemas, and recent conversational history. As context length expands, conversational instructions undergo severe recency degradation.

The Fix - Root Ingestion:
Operational guardrails must never be negotiated in chat turns. They must be anchored at the root instruction layer:

  • If you are operating in Google Antigravity or an agentic IDE, anchor them in your workspace AGENTS.md or system instructions.
  • System-level instructions are injected into the model’s pre-turn context on every single invocation, entirely immune to conversational decay.

3. Execution Gating (Decoupling Planning from Tool Invocation)

When you ask an agentic model to evaluate a problem, its default bias is action-oriented: it attempts to immediately satisfy the user by calling file-creation tools or writing exploratory boilerplate.

If you do not want unrequested code or files:

  1. Enforce Phase Gating: Explicitly mandate that the model operates in a two-phase lifecycle:
    • Phase 1 (Exploration & Advisory): The model is restricted to analytical text output only. Zero tool calls or file writes permitted.
    • Phase 2 (Targeted Execution): Triggered only after you explicitly approve a numbered, single-step blueprint.
  2. Deterministic Tool Gating: If your environment exposes tool permissions, require user confirmation for write/creation operations while leaving read tools automated.

Gemini 3.8 has exceptional reasoning depth, but like any advanced engine, attempting to govern it through unstructured conversational chat will inevitably result in scope creep and boundary violations. Structure the guardrails at the system layer with paired invariants, and the model’s consistency transforms overnight.

Hi @heryad,

I am just chiming in to completely second everything @dllhell and @RandalSchwartz have shared.

As @dllhell explained, relying on conversational chat for operational guardrails often leads to context decay, whereas anchoring your rules in your workspace AGENTS.md completely bypasses that issue. Pairing that with explicit phase gating for tool executions will definitely keep the agent from creating unrequested files.

Please let us know how the agent performs after you implement these structural guardrails. If you try these approaches and still feel the model is aggressively hallucinating or drifting more than expected, please feel free to share a specific example here. We definitely want to investigate if there is an underlying instruction-following regression in 3.8.

Thanks to @dllhell and @RandalSchwartz for the detailed and helpful explanations!

I’m also getting success by having an orchestrator with no task but to manage the state of the workflow, and call subagents for each of the steps. And amazingly enough, I give the overall plan to the orchestrator as a Makefile! Yes, a 50-year old but well tested model of DAGs, and baked heavily into every LLM model.

@RandalSchwartz The Makefile metaphor is brilliant, and it highlights a fundamental truth that many modern agent frameworks ignore: directed acyclic graphs (DAGs) and dependency resolution were solved decades ago.

Using a declarative DAG where each target maps to an isolated subagent task brings two immediate breakthroughs:

  1. Deterministic Topography: The orchestrator model cannot hallucinate intermediate steps or skip prerequisites. Target C cannot execute until Target A and Target B exit with code 0.
  2. Token Hygiene: Because the orchestrator only manages state transitions and passes distilled artefact outputs between subagents, the primary context window stays completely clean.

The one critical frontier where classical make needs an architectural extension in agentic software engineering is Phase Gating (The Human Verification Gate):

Classical make assumes that once the graph is computed, execution should proceed autonomously to the terminal target. With LLMs, if an exploratory target encounters an ambiguous architectural fork, letting the subagents steamroll through the remaining targets often leads to clean compilation of the wrong design.

In our production setups, we wrap that DAG in a strict two-stage lifecycle:

  • Stage 1 (Topological Blueprint): The orchestrator maps the dependencies and prints the execution graph (numbered subagent tasks and trade-offs), but is physically prohibited from triggering tool recipes or subagent writes.
  • Stage 2 (Conversational Authorisation): Execution only begins after an explicit human command (‘go’ or ‘proceed’), running either single-step with review or batch execution.

the 50-year-old Unix DAG discipline of make with deterministic human turns chaotic, drifting agents into banking-grade engineering pipelines. Brilliant observation.