I built a pet social network. Thirteen entity types in a single DynamoDB table. The fact that "pet social network" and "database architecture" are in the same sentence tells you everything about my priorities.
This is where I learned the most dangerous thing about AI-assisted development at higher levels: Claude can write syntactically perfect code for an architecturally broken design. And the better the code looks, the harder it is to catch that the architecture is wrong.
Single-Table DynamoDB in 30 Seconds
DynamoDB has no JOINs, no foreign keys, and one primary key. Single-table design means all 13 entity types (users, pets, health events, medications, clubs, posts, reactions, comments...) share one table with a partition key + sort key structure:
| Entity | Partition Key | Sort Key |
|---|---|---|
| User | USER#<id> |
PROFILE |
| Pet | USER#<id> |
PET#<petId> |
| Health Event | PET#<petId> |
EVENT#<timestamp>#<id> |
| Club Post | CLUB#<id> |
POST#<timestamp>#<id> |
"Get all of a user's pets" → one query. "Get a pet's health timeline" → one query. "Get all posts in a club" → one query. Clean, fast, elegant.
But "get all upcoming appointments across all of a user's pets" → the design breaks.
Where AI Gets This Catastrophically Wrong
Early in the project, I described the features and let Claude design the data model. It produced something clean: well-named attributes, consistent key patterns, proper structure. The code compiled, ran, and returned data.
Then I needed a query I hadn't specified upfront: "show all upcoming appointments across all pets for reminder emails."
The schema had appointments under each pet's partition key (PET#<petId>, APPT#<date>#<id>). Getting appointments for all pets meant querying each pet separately and merging results client-side. User with 5 pets? That's 5 queries instead of 1.
In a relational database, this is a trivial JOIN. In single-table DynamoDB, this is a design error that requires restructuring the schema or adding a GSI.
Here's the dangerous part: Claude would have happily written the 5-query client-side merge. It would have worked. The code would have been clean, idiomatic, well-tested. The code review would pass. The architecture review should have caught it.
The Level 5 Skill
At higher levels of AI-assisted development, code quality goes up and architectural risk goes up at the same time.
At Level 1, the failure mode is obvious: bad code. You can see it. It doesn't compile.
At Level 5, Claude writes code that's clean, idiomatic, and fully functional. The failure mode is subtle: good code implementing the wrong architecture. A well-designed relational schema in DynamoDB. Beautiful queries for a key design that can't support your access patterns. Perfect code for a broken foundation.
This isn't just a DynamoDB problem. In Post 7, Claude designed a music platform architecture that would have hit $3K/month at scale if we hadn't caught the cost model. In Post 8, it built an e-commerce flow without catching Gmail's email normalization quirk. The pattern is always the same: the code is clean, the architecture has a flaw, and the flaw is invisible until it isn't.
The code review is the easy part. The architecture review is where your expertise matters. And it's the one thing AI can't do for you, because it requires understanding what you're building for, not just what you're building.
What I Got Right
The access patterns that worked were the ones I designed before writing code. The ones that failed were the ones I forgot to plan for.
That's the tax for single-table design: you pay upfront during planning, or you pay double during restructuring. Claude is incredible at implementing access patterns you've already designed. It's dangerous at designing them for you, because it'll produce something that looks architecturally sound until you need the one query pattern it didn't anticipate.
The Takeaway
Claude can write perfect DynamoDB queries for a broken schema. Whether the schema is right is still your job. And that doesn't get easier with better AI. It gets harder, because the code is so clean that the flaws hide better.