The Page Object Model (POM) wraps page selectors/actions in classes; Cypress teams often prefer 'App Actions' — driving app state directly (via cy.request or the app's own store) — for setup, reserving UI interaction for the behavior under test.
POM centralizes selectors and interactions per page, aiding maintenance in large suites — the same pattern used in Selenium. Cypress's creators argue that for STATE SETUP you should skip the UI entirely: seed data and log in via the API/app store (app actions), so tests are fast and only exercise the UI for the specific behavior being verified. Many teams blend both: light page objects or reusable custom commands for shared UI flows, plus app actions for setup/teardown. The anti-pattern is driving the full UI for every precondition, which is slow and flaky.
To test 'delete a product', the team seeds a product via cy.request (app action) rather than clicking through the 'create product' UI first — the test now focuses solely on the delete behavior and runs in a fraction of the time.
In an interview: 'Cypress recommends against heavy Page Objects. What do they suggest instead and why?'