I recently completed the Vibe Coding Workshop — Civic Tech Edition, working through four practical use cases designed around real municipal workflows.
The goal wasn't simply to “make an AI app.” The workshop focused on turning vague prompts into structured, testable, reliable workflows using RICE, CRAFT, explicit enforcement rules, and Git-based iteration.
The first challenge was a municipal complaint classifier.
The input contained citizen complaints that needed to be classified into an exact municipal taxonomy such as:
Each complaint also needed a priority:
Urgent / Standard / Low
The initial naive prompt was simply:
“Classify this citizen complaint by category and priority.”
The problem became obvious quickly: a simple prompt can classify the topic, but it doesn't necessarily enforce severity detection, evidence, or consistent taxonomy.
For example, a complaint mentioning an injury, child, school, hospital, ambulance, hazard, fall, or collapse needed to be treated as urgent. I converted the requirements into explicit agent instructions and skills:
NEEDS_REVIEW
for ambiguous casesThe final classifier was tested against the supplied Pune dataset and produced the expected results_pune.csv
.
Key lesson:
A good prompt doesn't just tell an AI what to do. It defines what counts as correct.
The second use case was an HR leave-policy summarizer.
At first glance, this sounds straightforward:
“Summarize the policy document.”
But policy documents contain details that cannot safely be summarized away.
The document included requirements such as:
The major failure modes were:
Clause omission · Scope bleed · Obligation softening
The workflow was redesigned to explicitly preserve:
I also added validation so the generated summary could be checked for required policy details rather than simply trusting the output.
The final workflow generated summary_hr_leave.txt
and passed the policy-summary validation.
Key lesson:
For policy workflows, “approximately correct” is often incorrect. Important conditions and exceptions have to survive the transformation. The third challenge involved municipal budget analysis.
The dataset contained:
The task was to calculate growth for a specific ward and category, for example:
Ward 1 – Kasba → Roads & Pothole Repair
The main failure modes were:
Wrong aggregation level · Silent null handling · Formula assumption
This was important because an apparently reasonable calculation can become completely misleading if data from different wards or categories is accidentally combined.
The implementation enforced:
The output correctly produced values such as:
Scope is part of correctness.
A mathematically correct formula applied to the wrong aggregation level is still a wrong answer.
The final use case brought everything together.
The task was to build an interactive policy Q&A system using three separate documents:
The challenge wasn't just answering questions. It was preventing the model from combining information from different documents to create a permission that no document actually grants.
For example: “Can I use my personal phone to access work files when working from home?”
The HR document may discuss remote work, while the IT policy specifically limits personal-device access.
The agent therefore needed to maintain source boundaries.
The final workflow required:
For unsupported questions, the required response was: “This question is not covered in the available policy documents…”
The test cases successfully demonstrated:
The most important part of a document Q&A system isn't just retrieval.
It's knowing when not to answer.
Across all four use cases, the biggest shift was moving from:
“Give the AI a prompt and see what happens.”
to:
“Define the task, failure modes, enforcement rules, skills, validation, and test cases before trusting the output.”
The workflow I followed was essentially:
Naive Prompt → Identify Failure → RICE Prompt → agents.md → skills.md → Code → Test → Analyze → Fix → Commit
Git also became part of the development process rather than just version control. Each UC was developed and committed separately, creating a traceable history of what failed, why it failed, and what changed.
The four use cases reinforced a simple principle:
Reliable AI isn't just about generating better answers. It's about designing systems that make incorrect answers harder to produce.