I’ve been running into this problem constantly. We built out a few Puppeteer scripts using AI generation, and they work great for a week or two. Then the client’s site gets a redesign, one selector changes, and the whole thing falls apart. We’re constantly going back and patching things.
I get why it happens—AI generates workflows based on the current DOM structure, so any layout shift breaks the selector chains. But there has to be a better approach than manually fixing scripts every time.
Some of my team thinks we should just accept it and budget for maintenance. Others say we need to build in more fallbacks and error handling from the start. But honestly, I’m wondering if there’s a way to make Puppeteer workflows more resilient to UI changes without having to rewrite everything.
Have any of you dealt with this? How do you handle it when generated workflows start failing?
This is exactly the kind of problem Latenode solves really well. The key difference is that Latenode doesn’t just generate a static script once and hope it works. You can build your workflow with flexibility built in from the start.
Instead of relying on brittle selectors, you describe what you actually need to do in plain text, and the AI Copilot generates a workflow that’s designed to be updated and maintained. The big win is that you can regenerate or adjust the workflow without rewriting everything from scratch.
More importantly, when something does break, you can quickly update the workflow description and regenerate the automation. It’s way faster than debugging and patching traditional scripts.
I had the exact same issue. We tried adding more defensive selectors and fallback logic, but it just made the scripts harder to maintain. What actually helped was treating UI changes as a reason to revisit the workflow design rather than just patch it.
We started documenting exactly what each step was supposed to accomplish in business terms, not technical terms. Login as user X, then extract data from section Y. That way, when a site redesigned, we had a clear description of what the workflow needed to do, and we could rebuild it faster with fresh selectors.
It shifted our thinking from “how do we make this selector more robust” to “how do we rebuild this quickly when it breaks.” Made a real difference in maintenance overhead.
The brittleness of selector-based automation is inherent to the approach. I’ve found that adding multiple fallback selectors helps temporarily, but you’re right that it’s not sustainable. What works better is building abstraction layers within your Puppeteer code. Instead of hardcoding selectors throughout, create functions that encapsulate the intent of each action—find the login button, find the data table, etc. When selectors break, you only need to update the abstraction layer, not every reference. This reduces maintenance work significantly and makes regeneration easier when you eventually need to rebuild sections of the workflow.
The core issue is that DOM-based selectors are inherently fragile. To mitigate this, consider incorporating visual recognition or more semantic approaches alongside traditional selectors. Some teams use a combination of CSS selectors, XPath patterns, and text content matching to increase resilience. Additionally, implementing a robust logging and alerting system helps catch failures early. This way, you’re not blindsided by changes after days of silent failures. Regular regression testing against test environments that mirror production also helps catch issues before they reach live workflows.
Use data-test attributes or aria labels instead of class names. Ask the dev team to add these. Way more stable then regular selectors. Also add try-catch blocks everywhere.
One more thing—if you’re using AI to generate these workflows, make sure you’re setting up monitoring from day one. We didn’t, and we didn’t realize a workflow was failing until the client complained. Now we have alerts for any Puppeteer errors or unexpected state changes. It doesn’t prevent failures, but it means you catch them within minutes instead of days.
Another important consideration is testing. Set up automated regression tests that run your Puppeteer workflows against staging environments. Use container snapshots to maintain stable testing conditions. This won’t prevent production failures, but it catches regressions before deployment. Combined with a solid rollback strategy, you can recover quickly when a site redesign does break things.