Sunday coffee & Code: RFP Automation - Database Schemas with Claude Code + a Design Shift

This week I re-asserted an architectural decision - and it drove some database work (I went with Postgres). 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝘄𝗼𝗿𝗸 (𝘀𝗰𝗵𝗲𝗺𝗮 𝘄𝗶𝘁𝗵 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲) I’d sketched an initial schema with ~21 columns and asked Claude Code to review it based on what it could infer from the codebase 𝘢𝘯𝘥 the design direction I was heading in (more on that below). It didn’t disappoint. It suggested a cleaner structure, pointed out where normalization helped, where a little denormalization was pragmatic, and - most importantly - flagged a couple of changes that made the job-queue pattern safer (a problem I knew I had - avoiding blocking when multiple workers reach for the next job). 𝗗𝗲𝘀𝗶𝗴𝗻 𝗿𝗲𝗮𝘀𝘀𝗲𝗿𝘁𝗶𝗼𝗻: 𝗮𝗴𝗲𝗻𝘁𝘀 𝗳𝘂𝗹𝗹𝘆 𝘀𝗲𝗽𝗮𝗿𝗮𝘁𝗲𝗱 𝗳𝗿𝗼𝗺 𝘁𝗵𝗲 𝘄𝗲𝗯 𝘀𝘁𝗮𝗰𝗸 The goal: 𝗰𝗼𝗺𝗽𝗹𝗲𝘁𝗲 𝘀𝗲𝗽𝗮𝗿𝗮𝘁𝗶𝗼𝗻 𝗼𝗳 𝘁𝗵𝗲 𝗼𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗼𝗿 𝗮𝗻𝗱 𝗮𝗴𝗲𝗻𝘁 𝗿𝘂𝗻𝘁𝗶𝗺𝗲 𝗳𝗿𝗼𝗺 𝘁𝗵𝗲 𝘄𝗲𝗯 𝗨𝗜 + 𝗯𝗮𝗰𝗸𝗲𝗻𝗱 𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀. Now the job runner can: • Pull the next job from the DB queue • Call an Orchestrator • Track timings + status • Write results back • Support multiple orchestrators (so capacity can scale out) This was especially important because I 𝘬𝘯𝘦𝘸 multi-orchestrator support was going to collide with assumptions in my RAG implementation. What this buys me: • 𝗦𝗺𝗮𝗹𝗹𝗲𝗿 𝗮𝘁𝘁𝗮𝗰𝗸 𝘀𝘂𝗿𝗳𝗮𝗰𝗲 (prompt injection is still a concern, but containment improves) • 𝗠𝘂𝗹𝘁𝗶-𝗮𝗴𝗲𝗻𝘁 𝘀𝗰𝗮𝗹𝗮𝗯𝗶𝗹𝗶𝘁𝘆 (spin up multiple backend agent runners) • 𝗦𝘆𝘀𝘁𝗲𝗺 𝘀𝗰𝗮𝗹𝗮𝗯𝗶𝗹𝗶𝘁𝘆 (components can be distributed and scaled horizontally & vertically) • 𝗙𝗮𝘂𝗹𝘁 𝗶𝘀𝗼𝗹𝗮𝘁𝗶𝗼𝗻 (backend failures won’t take down the UI or uploads) 𝗪𝗵𝗮𝘁 𝗜 𝗹𝗲𝗮𝗿𝗻𝗲𝗱 (𝗮𝗳𝘁𝗲𝗿 ~𝟭𝗵𝟰𝟱) After ~1h45 with Claude (and about $10 in extra capacity), it was done - including code changes and most of the documentation. A few takeaways: • CC can be a great tool for database schema design reviews based on the code base. • CC can miss some documentation updates (easy to overlook in a big change set) • Purchased capacity can take ~10 minutes to show up (I hit the “credit purchase delays” note on the Anthropic help agent) • Extra capacity burns fast when you’re finishing multi-orchestrator behavior + docs • You still need 𝘀𝘁𝗿𝗼𝗻𝗴 𝘀𝘆𝘀𝘁𝗲𝗺 𝗱𝗲𝘀𝗶𝗴𝗻 𝗶𝗻𝘀𝘁𝗶𝗻𝗰𝘁𝘀 Claude accelerates decisions, it doesn’t replace them (if you don’t it will become a mess) • I merged my first PR without reading 𝘦𝘷𝘦𝘳𝘺 change end-to-end (too many diffs)… which probably means I need to tighten my testing discipline from here.