After weeks of collaborating with ChatGPT as my engineering partner while building an AI platform, 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.
This article is based on my experience with ChatGPT. Other LLMs—such as Claude, Gemini, or open-weight models—may exhibit some of these behaviors differently, or not at all. Still, I suspect many of the underlying collaboration challenges are shared across today's generation of LLMs.
Here are the ten failure modes I encountered most often:
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
Countermeasures
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
Countermeasures
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 —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
Countermeasures
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
Countermeasures
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
Countermeasures
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. This experience eventually led to the idea of an * Assistant Collaboration State*.
Typical Triggers
Countermeasures
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
Countermeasures
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
Countermeasures
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
Countermeasures
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
Countermeasures
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.