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?
[link] [comments]