The Joint That Won't Hold: Catching Anti-Patterns Automatically

Opening Scene

Before any piece leaves the workshop, a shop foreman inspects it — checking every joint for the specific, well-known signs of trouble: a tenon cut fractionally too loose, a mortise with hairline splitting at its edge, a wedge driven at the wrong angle. These aren’t exotic failures; they’re the same handful of recognizable mistakes that show up again and again across a career of building furniture, and an experienced eye catches them in seconds precisely because it’s seen each one before. The piece doesn’t ship until every joint passes that inspection.

Database schemas have their own recognizable, recurring anti-patterns — and AI-assisted review can now catch them with the same speed and consistency.

In Plain English

Automated anti-pattern detection applies AI-assisted analysis to a schema to flag known ER design mistakes before they reach production: a many-to-many relationship collapsed into a comma-separated column (Article 2), a self-referencing hierarchy with no cycle protection (Article 3), a mandatory relationship modeled as nullable (Article 4), a hidden supertype/subtype structure flattened into one sparse table (Article 5), a weak entity given an independent primary key that should be composite (Article 8). Each of these anti-patterns is a well-known, recurring mistake — exactly the kind of thing a trained review process, human or automated, is good at catching consistently.

The Old Way

Before automated detection, catching these mistakes depended entirely on manual schema review:

• Schema review was a manual, often inconsistent process, dependent on whichever senior reviewer happened to be assigned, and easy to skip entirely under deadline pressure, exactly the way an unshipped piece with a bad joint could slip past a rushed inspection.
• Anti-patterns often weren’t discovered until they caused a real, visible problem — a data integrity issue, a query that returned wrong results, an application bug traced back weeks later to a mismatched relationship — long after the schema had already shipped and accumulated dependent code.
• Even experienced reviewers caught anti-patterns at variable rates depending on fatigue, familiarity with the specific part of the schema, and how much time review was actually given, an inherently inconsistent safeguard compared to a systematic, repeatable check.

Catching an anti-pattern before it ships has always been far cheaper than fixing it after other code and data come to depend on it, exactly the refactoring cost covered in Article 13.

What’s Changing (and Why AI Is the Reason)

1. AI-assisted schema linting tools can now systematically check for the full catalog of known ER anti-patterns on every proposed schema change, applying the same consistent checklist every time regardless of reviewer fatigue, deadline pressure, or unfamiliarity with a specific part of the schema — a meaningfully more reliable safeguard than variable manual review alone.
2. These tools increasingly integrate directly into the schema change workflow itself — flagging a likely anti-pattern at the moment a migration is proposed, not weeks later once a downstream bug surfaces — shifting anti-pattern detection from a reactive discovery to a proactive gate, the same shift from “found a bad joint after the piece shipped” to “caught it during final inspection.”
3. Because AI coding assistants are themselves increasingly the ones generating new schema, automated anti-pattern detection has become a genuinely necessary complementary safeguard, checking AI-generated structure with the same rigor as human-authored structure, since neither source is immune to producing a well-known, recognizable mistake.

The Metaphor, Fully Extended

Joinery Element	ER Modelling Concept
The shop foreman’s final inspection before a piece ships	Automated anti-pattern detection applied to a proposed schema change
A specific, well-known flaw like a loose tenon or a split mortise	A specific, well-known ER anti-pattern like a nullable mandatory relationship
Catching the flaw during inspection, before the piece reaches a customer’s home	Flagging the anti-pattern during schema review, before it reaches production
The foreman’s checklist, applied consistently to every piece regardless of who built it	An automated linting checklist, applied consistently to every schema change regardless of its source
A joiner’s own work inspected with the same rigor as an apprentice’s	AI-generated schema checked with the same rigor as human-authored schema

Quick Recap

• Automated anti-pattern detection systematically flags known ER design mistakes before they reach production, the same consistent safeguard a shop foreman’s final inspection provides for every joint before a piece ships.
• Manual review alone is inconsistent, dependent on reviewer fatigue and deadline pressure, while automated checks apply the same checklist every time.
• Integrating detection directly into the schema change workflow shifts anti-pattern discovery from reactive to proactive, catching issues at proposal time instead of after a downstream bug surfaces.
• AI-generated schema needs this same rigor applied to it as human-authored schema, since neither source is immune to well-known, recurring mistakes.

Where This Fits in the Series

Article 16 covered feeding documented patterns forward into AI tools; this article covered catching mistakes automatically before they ship. Article 18 turns to a newer question — how these patterns hold up for data that AI agents themselves generate.