We've reproduced 30+ real AI runtime failures over the past week. Here's the pattern we keep seeing.
Over the past few weeks, we've reproduced 30+ real AI runtime failures from GitHub issues instead of just reading about them. Most weren't model failures - they were runtime contract mismatches between providers, tools, and application code. That led us to build StateGuard. We'd genuinely love feedback from builders: what runtime failures are you facing, and is this something you'd use?
Incase y'all wanna connect:
GitHub: https://github.com/dood1ebyte/stateguard
LinkedIn: https://www.linkedin.com/in/adivaishnav
Trending on Indie Hackers
The interesting part for me isn't that the failures happened - it's where they happened.
It sounds like the individual pieces were often working as expected, but the assumptions between them weren't aligned. Those kinds of failures are tricky because every component can look "correct" in isolation while the overall system still breaks.
Finding those patterns feels much more valuable than treating every runtime issue as a model problem.
That's exactly the kind of thinking that led us to build StateGuard. We realized many runtime failures weren't isolated bugs - they happened because the assumptions between components drifted over time.
We're taking the product in the direction that real builders need, so conversations like this are incredibly valuable to us. If you've run into examples of these failures in your own projects, I'd genuinely love to hear about them and learn from your experience.
If you're open to it, feel free to connect with me on LinkedIn. I'd love to chat developer-to-developer, hear more about the problems you've seen, and get your thoughts on what we're building.
LinkedIn: https://www.linkedin.com/in/adivaishnav
I like the way you described it as assumptions drifting over time. Those are some of the hardest failures to notice because no single change necessarily looks wrong in isolation. It's the accumulation of individually reasonable changes that eventually breaks the contract. That makes identifying the pattern much more valuable than fixing one-off failures.
That's exactly where our thinking ended up too. Once we started reproducing these failures, it became obvious that fixing individual bugs wasn't enough - you had to understand why the assumptions between components drifted in the first place.
I'd actually love to hear more about your experience with this. We're building StateGuard around real developer feedback rather than assumptions, so if you're up for it, let's connect on LinkedIn and continue the conversation.
Genuine question: should model providers eventually solve this at the source, or is defending against drift always the application layer’s job?