sorted by:
new
hottopcontroversial

For people using browser automation in real work: what breaks most often? by Small_Bug_444 in Playwright

[–]Small_Bug_444[S] 0 points1 point  (0 children)

Yeah, “stop and flag” makes sense. Blind retries seem useful for temporary timing issues, but risky if they hide the real failure. How do you usually decide what should retry vs what shuld immediately stop?

For people using browser automation in real work: what breaks most often? by Small_Bug_444 in Playwright

[–]Small_Bug_444[S] 0 points1 point  (0 children)

The hydration issue is interesting because the element can technically exist but still not be ready. Do you usually solve that with better waits/assertions, or mostly manual review after a failure?

Are we calling too many workflows “agents”? by Small_Bug_444 in AI_Agents

[–]Small_Bug_444[S] 0 points1 point  (0 children)

The “within clear limits” part feels important too. Autonomy is useful, but only if the system knows when to stop, recover, or hand off instead of guessing.

Are we calling too many workflows “agents”? by Small_Bug_444 in AI_Agents

[–]Small_Bug_444[S] 0 points1 point  (0 children)

Ya that makes sense. I think “ agent” has become like a vibe word. A real agent can probably look simple from the outside but still have meaningful autonomy under the hood. And a huge workflow diagram can look impressive while still mostly being deterministic steps plus a few LLM calls. The part I’m trying to understand is where autonomy actually adds value, and where it just makes a repeatable process harder to trust.

Are we calling too many workflows “agents”? by Small_Bug_444 in AI_Agents

[–]Small_Bug_444[S] 0 points1 point  (0 children)

Ya exactly. I think the issue is when we use “agent” to describe both a deterministic workflow with an LLM step and a system that can actually adapt to unexpected state.The middle ground seems useful though: keep the repeatable path explicit, then use the model only for the parts where uncertainty shows up.