Too many tables look right. Most of them aren't.

A query that looks correct can fail at five distinct points, none of which produce an error. The table selected is stale. The join creates fanout. The filter includes data from an 18-hour-old snapshot. The column returns NULL because it was renamed without migration. The result includes test data because the is_test flag was never documented.
Each of these failures is invisible at query time. The query compiles, runs, returns data, and the wrong data gets used.
Warehouses accumulate traps over time: duplicate models with similar names where the most obvious one is stale, many-to-many joins that silently double row counts, columns renamed without updating downstream references, test accounts seeded in production data and never excluded. These are the standard condition of a warehouse used by multiple teams over multiple years.
Experienced analysts navigate these traps through familiarity. They know which tables are safe, which joins are dangerous, which columns can be trusted. That navigation exists in their heads.
Automation inherits the trap-filled warehouse without inheriting the knowledge required to navigate it. Cleaning up the warehouse is a permanent battle; the trap count never reaches zero. Making the navigation knowledge explicit and available is what actually changes the outcome.