The author shares two years of experience building a platform with AI, identifying six recurring failure modes (Band-Aid, Assumption, Drift, Hallucination, Lack of Common Sense, Path of Least Resistance) and argues that even as models improve, these failure modes persist, becoming harder to detect.
I spent more than 2,000 hours across seven months building a live platform with AI as my only technical partner. I had no software development background going in. Throughout the build, I repeatedly encountered the same six failure modes: Band-Aid: Fixing the symptom instead of the cause Assumption: Filling a gap with what should be true instead of checking what actually is Drift: Quietly changing the scope or structure without saying so Hallucination: Inventing something instead of admitting it does not know Lack of Common Sense: Missing something a human would catch immediately Path of Least Resistance: Choosing the easy fix instead of the right one I documented the experience in a field report called AI: The Perpetual Intern. Here are two moments that helped make the underlying problem clear to me. Story one: The nine migration files I could no longer judge After a long and detailed design conversation, the model produced nine complete database migration files. They included isolated schemas, permissions, versioned pricing, audit rules, and more. It was genuinely impressive. Then the model asked me how a particular field should behave. I realized I could not answer. I had approved every decision individually, but I no longer understood how the nine tables worked together as a whole. I could not see what all those reasonable individual decisions had added up to. I eventually had to build an actual frontend so I could use the system as a person would before I could responsibly make the next architectural decision. Story two: Asking twice and being told yes twice We had to restore the project from backup twice. One of those restorations became necessary after an old Git repository quietly injected garbage text into hundreds of frontend files. I asked the model directly whether the cleanup was actually complete. It said yes. I asked again to make sure. It said yes again. It was not complete. When I pushed back, the next proposed fixes became worse. The model offered to wipe entire structural directories just to make the visible symptom disappear. That was not a lack of intelligence. The model was highly capable throughout the entire process. But its confidence was not connected to verified system truth. Why this still matters as models improve I have gone back to building with newer models since finishing the manuscript, and they are genuinely better. They handle context better, verify more often, and make narrower changes instead of broad rewrites. That is real progress, not just marketing. But the six failure modes have not disappeared. They occur less often, and that can make them harder to catch because everything surrounding the mistake now looks more polished and convincing. That is why I think this framework is worth preserving. It is not a takedown of any company or model. It is a ruler. Whenever a new model arrives, the useful question is not simply, “Is it smarter?” The more useful questions are: Which of these failure modes did it actually reduce? Which ones still remain? Which decisions still require a human, no matter how convincing the output looks? What this subreddit is for This is a place for real and specific accounts of building with AI: What broke What worked What you had to learn the hard way Model comparisons based on actual use, not benchmark screenshots Session design and context-management techniques Verification habits and safeguards Failures you caught before they caused real damage Failures you did not catch until afterward What this sub is not for: hype posts, unverified leaks, or “this changes everything” claims without a real example behind them. If you have a story like the two above, bring it here. That is what this place is for. What is your version of one of these six failure modes? Or is there another recurring failure mode that I have not named yet?
Discusses the common gap between clean benchmark-style testing environments and messy real-world usage in AI workflows, leading to production failures, and mentions evaluation platforms like Confident AI, Braintrust, and Langfuse.
The article argues that AI agent failures in production are often due to poor organizational design and undefined responsibility boundaries rather than model limitations. It proposes a maturity model distinguishing between AI assistants, automation, and AI employees to guide task ownership.
A team reflects on six common structural failure points in AI builds: context, identity, decision memory, attention, write-back, governance, and economics, and offers a diagnostic tool based on their experiences.
This article highlights that many AI agent projects fail in production not because of model quality, but because teams launch without clearly defining what constitutes failure, missing critical edge cases that lead to confident incorrect outputs.
The author observes that AI agents exhibit human-like failure patterns, such as overconfidence and skipping steps under context pressure, suggesting that system reliability depends more on robust validation and controlled environments than just model intelligence.