I hesitate to call it an anti-pattern but it kind of is. It leads you down some bad paths.

- In the best possible scenario: 1) you're spending time to duplicate configuration between dev, test, and prod, any time the environments change, 2) you hope your testing in one environment is actually borne out in prod, 3) you are shutting down dev & test when they're not in use (to save money), 4) you rebuild it all regularly to ensure it's still actually repeatable to repair or rebuild it, 5) you do maintenance on all 3 regularly to stay up to date on security patches and dependencies, 6) you still do trunk-based development that just deploys to each environment successively with automated functional tests, which makes one of the environments (either dev or test) unnecessary, and the other inaccurate

- In the more likely scenario: 1) your "duplication" of configuration is inaccurate or literally not the same, leading to differences which cause bugs, 2) your results in prod don't mimic those in test, 3) you aren't shutting down dev/test when not in use, leading to not only unnecessary charges, but potential security issues if they get compromised (because who secures dev/test?), 4) you never rebuild it, so when there's an issue and you need to repair or replace it, you have no idea how to do it again, or the automation doesn't work, so you spend more time fixing it while your stuff is down, 5) you never do maintenance, leading to failed disks, out of date software, and general maintenance headaches, 6) you are probably not doing trunk based development, but cherry-picking changes from a "dev", "test", and "prod" branch, ending up with diverging codebases which don't match each other, and is a nightmare to debug and maintain

That's the very short version of it, anyway. Thankfully there is a modern method which solves all those problems.

Only use ephemeral environments, and production. The ephemeral environment is built from scratch whenever you want to test, and is shut down automatically after idleness. This ensures trunk-based development, allows multiple independent test deployments with specific feature-branch changes to exist simultaneously, re-tests all your automation constantly, uses the latest updates to avoid dependency stagnation, is versioned, saves money and resources, and eliminates security concerns.

Faster development, fewer bugs, less money, less maintenance toil, less downtime, more security. But it's not popular on HN so nobody does it.