In many cases, no
The first automation case is easy to write - no page objects, no need to use DRY, etc.
By the 100th test you need a lot of programming - or codeless automation suites.
The problems really start when you then continue to use the
add or change functionality or bug discovered / fixed
write new UI test
The test suite starts to grow and before long takes first hours and then days to run. The number of tests cases keeps growing (I've seen tens of thousands), as do the intermittent errors that destroy confidence of the tests adding value. Multiply test cases by browsers and devices and versions and orientation and the Universe might end. Ultimately the original intent of rapid feedback disappears and qa becomes a separate function that does checking and verification but doesn't directly influence quality in the context of application code creation by developers. Testing gets done for the sake of testing and quality does not improve long term.
It also becomes apparent that you should be following the principles behind the Agile Testing Pyramid with the Unit, Integration and UI layers and just using a tool to write ever more UI cases does not promote this conversation and action within the organization.
Currently approaches such as 'keep the test suite under 15 mins by deciding which end to end UI tests are needed and which existing ones could be moved to integration or unit tests' are not approaches that AI test automation can handle as far as I'm aware. Maybe google have it internally.