The Problem, In One Sentence
Data catalogs are excellent at telling you your data is broken. They are considerably worse at actually fixing it. Someone still has to write the SQL, get it reviewed, and ship it. Albugent tries to close that specific gap.
What It Does
It scans SQLite datasets, finds the classics—negative billing amounts, NULL patient names, exposed PII—and generates a targeted fix for each. No giant, all-or-nothing SQL script. Just one isolated fix per problem, where you click Approve or Reject and move on. There's also a full CLI mode where an agent investigates everything on its own and opens a GitHub PR with a written report.
And Here's the Part I Actually Care About
The agent never touches the database. Not because it was told not to in a system prompt, but because it cannot. No write-access function is exposed to its runtime. Only a plain Python function, triggered strictly by a human clicking Approve, can execute any writes.
I went back and forth on whether this was overkill for a hackathon demo. It was not. The one time I let a patch auto-apply, it overwrote a legitimately empty column—a delivery date for an order still in transit—with a default value, because the logic hadn't yet learned the difference between "this is broken" and "this is just what normal looks like sometimes." Small bug on a demo dataset, but absolutely unacceptable in production.
The point is: don't ask the model to be careful. Just don't give it the capabilities to be careless.
Things That Actually Broke (Said With Love)
A risk-scoring function had a parameter mismatch that silently zeroed out risk scores for a while, and I didn't notice because the flat numbers looked fine. A date-matching check happily paired two unrelated date columns together because it only asked "does this look like a date," never "should these two go together." Neither of these is a dramatic bug, but both would've been mortifying to demo if I hadn't caught them.
What I'd Tell Someone Doing This Next
Don't let the LLM do arithmetic or decide what "risky" means through vibes and a hopeful prompt when you can just compute it. Save the model for what's genuinely hard to hardcode—prioritizing the investigation or writing summaries humans actually want to read. Everything else with exactly one correct answer belongs in code, not in a model that is confidently wrong exactly as often as it is confidently right.
Thanks
Special thanks to AWS for hosting this hackathon, providing access to Bedrock, and building the infrastructure around Strands and MCP that made integrating agentic workflows into this architecture so seamless.
Project Links
GitHub Repository
3-Minute Demo Video
Engineering Retrospective on DEV.to
Top comments (0)