schema-guard: AI SQL names checked vs real snapshot

The problem schema-guard targets is not that coding agents write bad SQL syntax, but that they write against a schema they assume is real. As the author puts it, an agent bases its query on a README, an old query, or a naming convention, and the failure shows up later in CI, in a dashboard, or at 2am. Snowflake's own developer blog ran a post on this in September 2026, which suggests the vendor sees the same pattern among its users.

The tool's approach is to keep a snapshot of the actual tables and columns, names and types only, inside the repo, and to check the agent's SQL against that snapshot before it runs. The snapshot is taken once by someone with warehouse access, so the agent itself never needs that access. The author reports a Databricks reader run live on a Free Edition workspace on 2026-10-04, returning 9 tables and 277 columns in under 30 seconds on a cold warehouse.

The author is openly cautious about the evidence. The test world is small and synthetic, the stale README was designed in, and there are only 3 runs per cell; two grader references were even added after reading runs. A one-line rule in a project file gets a similar result if the agent follows it, while the hook does not depend on that. Whether this holds in a real warehouse with years of schema drift is the open question, and the readers for Snowflake and BigQuery have not yet been run against live accounts.