After months of building an AI platform with ChatGPT as my engineering partner, I started noticing recurring collaboration patterns. They weren’t random. They appeared again and again, often with surprisingly predictable triggers—and equally predictable fixes.
When I started this project, I expected the biggest challenges to be Python, APIs, embeddings, vector databases, or understanding RAG. I was wrong. So far, the hardest part hasn’t been building the platform. It’s been learning how to work effectively with ChatGPT as an engineering partner over the course of a long-term project. Eventually, I realized I was encountering the same failure modes over and over again. Once I recognized them, I could often predict when they would happen—and, more importantly, how to avoid them.
Here are the ten failure modes I encountered most often:
- 🧠 Doom Mode
- 🔒 Micromanagement Collapse
- 🧭 Context Drift
- 🏗️ Abstraction Fever
- 👏 Compliment Inflation
- 🤝 Forgotten Behavior
- 👻 Phantom Modules
- 🗂️ Architecture Amnesia
- 📝 Semantic Misalignment
- 🛤️ Solution Momentum
🧠 Doom Mode
Symptom
The model doesn’t come to an end. Instead of recognizing that a task is complete, it keeps refining the result, adding more sections, or searching for an even better answer. The underlying problem is usually not the model itself, but the absence of a well-defined termination condition. I started calling this behavior Doom Mode because it reminded me of the myth of Sisyphus: the model appears doomed to search endlessly for the perfect ending without ever recognizing that it has already arrived.
Example
While writing one of my Charlie whitepapers, I asked ChatGPT to produce an introduction, the main chapters, and a Final Conclusion. Because the article exceeded the context window, I instructed to generate it chapter by chapter using „Continue“. After the Final Conclusion, ChatGPT didn’t stop. Instead, it continued with Acknowledgements, then Final Words, then another closing section, and so on. The task had no clear finish line because I had asked for the „best“ article instead of defining exactly what „done“ meant. It was probably endless.
Typical Triggers
- „Write the best…“
- „Create the ultimate…“
- „Make it as comprehensive as possible.“
- Vague notions of final, complete, or perfect
- No explicit stopping condition
Countermeasures
- Treat complex prompts as state machines: define both the desired outcome and the termination condition.
- Define an explicit termination condition (stop or exit condition).
- Avoid open-ended superlatives like best, ultimate, or perfect.
- Explicitly define what „done“ means.
🔒 Micromanagement Collapse
Symptom
The more detailed instructions you add, the worse the output becomes. Responses often become surprisingly short or overly constrained, as if the model no longer has enough freedom to solve the problem.
Example
At one point I kept adding more and more instructions to improve a prompt. Instead of getting better, the responses became shorter, more rigid, and less useful. Ironically, deleting half of the prompt immediately produced better results. That was the moment I realized that more instructions don’t necessarily create more clarity.
Typical Triggers
- Step-by-step instructions
- Redundant rules
- Contradicting requirements
- Overly long prompts
Countermeasures
- Define goals instead of implementation steps.
- Describe the desired outcome.
- Use success criteria.
- Remove unnecessary constraints.
🧭 Context Drift
Symptom
The conversation slowly drifts away from the original objective. Ironically, the new ideas are often interesting, making the drift difficult to notice.
Example
This happened regularly during architecture discussions. I started by designing a single component—for example, the document loader—and thirty minutes later we were debating knowledge management, AI collaboration, or software engineering philosophy. Those conversations were often valuable, but they no longer solved the original engineering problem. That eventually motivated me to introduce explicit engineering states and separate analysis from implementation.
Typical Triggers
- Long conversations
- Multiple side topics
- Continuous brainstorming
- Frequent introduction of new ideas
Countermeasures
- Summarize progress.
- Apply context engineering.
- Decide whether a new idea belongs to the current task or the backlog.
- Maintain explicit engineering states. (See my article on Engineering States.)
🏗️ Abstraction Fever
Symptom
A concrete implementation task gradually turns into a discussion about general principles. Instead of writing a class, you’re suddenly debating software architecture—or the meaning of software engineering itself. Similar to Anthropic’s notion of overeagerness.
Example
Several times I simply wanted to implement a small feature in Charlie. Instead of discussing the concrete class, ChatGPT started proposing generic frameworks, reusable architectures, or broad design principles. I eventually learned that I sometimes had to explicitly say, „Don’t abstract. Don’t over engineer. Focus on the current objective.“
Typical Triggers
- Open-ended questions
- Architecture discussions
- Missing scope boundaries
Countermeasures
- Explicitly define the desired level of abstraction.
- Ask for a concrete deliverable.
- Bring the discussion back to the original problem.
👏 Compliment Inflation (Sycophancy)
Symptom
The model spends more time praising your ideas than improving them. Technical discussion slowly turns into motivational commentary.
Example
During longer discussions, ChatGPT increasingly responded with phrases like „That’s an excellent observation“ or „This is a very sophisticated idea.“ While encouraging, those comments gradually displaced technical critique. I eventually asked ChatGPT to reduce compliments and focus on challenging my ideas instead.
Typical Triggers
- Long-term collaboration
- Reflective discussions
- Architecture conversations
Countermeasures
- Define the preferred communication style.
- Ask for concise feedback.
- Keep the focus on engineering rather than encouragement.
🤝 Forgotten Behavior
Symptom
The model gradually forgets previously established ways of working. This includes preferred wording, communication style, review habits, or formatting preferences.
Example
Over months of collaboration I established dozens of working agreements: address me as single person rather than multiple persons (what makes a difference in German by using „du“ instead of „ihr“), avoid unnecessary praise, don’t overengineer, keep explanations practical, and distinguish side questions from the main engineering task. After starting a new conversation, many of those agreements disappeared and had to be reintroduced manually – over and over again. This experience eventually led to the idea of an Assistant Collaboration State.
Typical Triggers
- Long conversations
- Starting a new chat
- Context window limitations
Countermeasures
- Document working agreements.
- Store collaboration preferences.
- Reintroduce important behavioral rules when necessary.
👻 Phantom Modules (Hallucinated Code)
Symptom
The model confidently refers to files, classes, methods, or modules that never existed. The suggestions sound perfectly plausible—which makes this failure mode particularly deceptive.
Example
After several refactorings, ChatGPT occasionally suggested moving functionality into classes or modules that sounded completely plausible—but didn’t actually exist in the repository. None of the names were obviously wrong. They simply belonged to an imaginary version of the project that only existed in the model’s reconstructed memory. This experience also contributed to the introduction of Engineering Truth in long-term engineering conversations.
Typical Triggers
- Large codebases
- Multiple refactorings
- Long-running projects
Countermeasures
- Share the current repository structure.
- Verify generated module names.
- Treat references as assumptions rather than facts.
🗂️ Architecture Amnesia
Symptom
The model loses track of the overall project structure and starts reasoning about an outdated architecture.
Example
This became particularly noticeable after major refactorings. Even though we had just reorganized the project into new packages and services, ChatGPT sometimes continued reasoning about the previous architecture. The solution was surprisingly simple: whenever I shared the current project tree (export with shell tree command), the quality of architectural discussions improved immediately. This experience also contributed to the introduction of updating the engineering conversation with the current Repository Structure and ADRs.
Typical Triggers
- Large refactorings
- New conversations
- Long-running projects
Countermeasures
- Provide the current project tree.
- Share architecture diagrams.
- Regularly re-establish the current architecture.
📝 Semantic Misalignment
Symptom
The model interprets an important term differently than you intended. Words like artifact, section, chapter, or paragraph may have completely different meanings depending on the context.
Example
One example that repeatedly caused confusion was the word artifact. In my engineering workflow, I used artifact to refer to visual engineering outputs such as architecture diagrams, workflows, pipelines, or other graphical representations. ChatGPT, however, interpreted artifact much more broadly. For the model, an artifact could also be a table, a list of principles, a Markdown document, or almost any structured output. We were both using the same word, but referring to different concepts. Once I replaced the ambiguous term with more precise language—for example, explicitly asking for an architecture diagram or a Mermaid diagram—the misunderstandings disappeared almost immediately.
Typical Triggers
- Ambiguous terminology
- Implicit assumptions
- Project-specific vocabulary
Countermeasures
- Reconsider the wording before extending the prompt.
- Replace ambiguous terms with more precise ones.
- Think in semantics, not syntax.
🛤️ Solution Momentum
Symptom
Once a solution starts gaining momentum, the model keeps improving it instead of questioning whether it should continue on that path. This can lead surprisingly far into a dead end.
Example
For example, after I had chosen one implementation strategy, ChatGPT became increasingly focused on refining that approach. It rarely questioned whether a fundamentally different solution might be better. What eventually helped (needless to say, after already having spent a lot of time in this dead end) was asking a simple question: „If we started this project from scratch today, would we still choose this architecture?“ Surprisingly often, that reopened the solution space.
Typical Triggers
- Many iterations on the same solution
- Long collaborative sessions
- Implicit assumption that the current approach is correct
Countermeasures
- Ask for fundamentally different approaches.
- Occasionally start the discussion from scratch.
- Validate important design decisions using external sources.
- Ask: „If we started today, would we choose the same solution?“
Related Concepts and Common Terminology
During the research for this article, I discovered that most of these failure modes are not unique observations. Many have already been described by researchers or practitioners—often under different names and usually in isolation. What surprised me was how consistently they appeared together during one long-running engineering project.
| Failure Mode | Common Terms | Notes |
|---|---|---|
| 🧠 Doom Mode | Missing Termination Condition, Undefined Stopping Criterion | There is no widely used name for this exact behavior. The underlying mechanism is the lack of a clearly defined stopping condition. „Doom Mode“ is my own nickname. |
| 🔒 Micromanagement Collapse | Prompt Brittleness, Over-Constrained Prompting | Prompting guides frequently warn that too many constraints can reduce output quality instead of improving it. |
| 🧭 Context Drift | Prompt Drift, Task Drift, Context Rot | One of the best-known long-conversation problems. The discussion gradually moves away from the original objective. |
| 🏗️ Abstraction Fever | Overeagerness, Scope Expansion | Similar to Anthropic’s notion of overeagerness: the model tends to introduce broader abstractions than the current task actually requires. |
| 👏 Compliment Inflation | Sycophancy | A well-established research topic describing the tendency of LLMs to agree with or excessively validate the user instead of providing critical feedback. |
| 🤝 Forgotten Behavior | Instruction Attenuation, Prompt Decay | Previously established instructions and collaboration rules gradually lose influence during long conversations. |
| 👻 Phantom Modules | Hallucinated Code, Fabricated References | Well known in code generation. My observation is a more specific case where the model invents plausible project-specific modules or classes. |
| 🗂️ Architecture Amnesia | Context Dilution, Context Rot | Closely related to context loss, but specifically affecting the model’s understanding of the current software architecture. |
| 📝 Semantic Misalignment | Prompt Ambiguity, Semantic Ambiguity | Both human and model use the same words but attach different meanings to them, leading to subtle misunderstandings. |
| 🛤️ Solution Momentum | Anchoring, Design Fixation, Local Search Bias | I couldn’t find a commonly used LLM-specific term. The behavior resembles cognitive anchoring: once a solution gains momentum, alternative approaches receive progressively less attention. |
Note: The names used in this article are intentionally practical rather than academic. In several cases (such as Doom Mode, Phantom Modules, Architecture Amnesia, and Solution Momentum), I’ve chosen names that I found intuitive during day-to-day engineering work, while also referencing related concepts from existing research where appropriate.
Final Thoughts
Looking back, I don’t think these failure modes are bugs. They’re recurring collaboration patterns. Once I stopped treating ChatGPT like a sequential program and started treating it like an engineering partner with predictable states and unambiguous instructions, the quality of our collaboration improved dramatically.
These observations are based on one long-running AI engineering project. They are empirical patterns that repeatedly appeared during months of collaboration with ChatGPT—not formally validated characteristics of all LLMs.
If this article resonates with your own experience, I’d love to hear which failure modes you’ve encountered—and whether you’ve found others that deserve to be added to the list.