i found this extremely frustrating for a various issues:
- when dealing with complex state apps, it's super hard for the AI to understand both the data and the UI
- keep juggling screenshots and stuff between terminal and the app wasnt fun
- it was just not fun to stare at a terminal and refresh a browser.
Agent looping is a brutal problem to debug. Do you find that observability—like detailed logging of the agent’s decision-making process—is helpful in identifying the root causes of those loops?
Honestly yeah – static catches structural stuff (missing exit conditions). But the trickier loops are when the model keeps deciding to retry. Like "let me try one more search" forever. That's prompt behavior, need runtime traces for those.
the signal-to-noise ratio has definitely gotten worse. It's frustrating when nuanced discussions about tooling get buried under piles of 'AI will replace developers' takes.
that's always true. i think the author is interested in code examples of such.
and unlike many other frameworks/tools, erlang provides a great pit-of-success for implementing fault tolerance - e.g if you follow common/best practices - you'll achieve a fairly good fault tolerance.
Thanks a lot! That like a great solution, a couple of followup questions:
- So basically an AE spins an env prior to a demo call? or is there a demo env all AEs use?
- How do you guys solve for "demo data"? e.g we want our potential customer to see how the system looks like "live".
- Are you guys happy with it? anything we can learn from past mistakes?
that's why i started working on https://github.com/frontman-ai/frontman . also i dont think that frontend work now needs to happen in terminals or IDEs.
reply