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.
1. From a Naive Prompt to a Reliable Classifier — UC-0A
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:
- Pothole
- Flooding
- Streetlight
- Waste
- Noise
- Road Damage
- Heritage Damage
- Heat Hazard
- Drain Blockage
- Other
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.
What I changed
I converted the requirements into explicit agent instructions and skills:
- Exact category validation
- Severity keyword detection
- Evidence-based reasoning
-
NEEDS_REVIEWfor ambiguous cases - Batch CSV processing
- Handling malformed or missing rows
The 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.
2. Making AI Preserve Policy Details — UC-0B
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:
- 14-day advance notice
- Written approval before leave begins
- Unapproved absence resulting in LOP
- Maximum 5-day carry-forward
- January–March usage window
- Medical certificate requirements
- Multiple approval authorities for Leave Without Pay
- Restrictions on leave encashment
The major failure modes were:
Clause omission · Scope bleed · Obligation softening
What I changed
The workflow was redesigned to explicitly preserve:
- Numerical limits
- Deadlines
- Conditions
- Approval authorities
- Prohibitions
- Consequences
- Exceptions
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.
3. Making Data Analysis Respect Scope — UC-0C
The third challenge involved municipal budget analysis.
The dataset contained:
- 5 wards
- 5 budget categories
- Monthly data for 2024
- Actual spending values
- Several deliberate null values
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.
What I changed
The implementation enforced:
- Exact ward/category scope
- Explicit MoM or YoY selection
- Previous-period values
- Formula displayed alongside each result
- Explicit null detection
- No calculation when required values are missing
- Zero-division validation
The output correctly produced values such as:
- July 2024 → +33.1% MoM
- October 2024 → -34.8% MoM
Key lesson
Scope is part of correctness.
A mathematically correct formula applied to the wrong aggregation level is still a wrong answer.
4. Building a Safe “Ask My Documents” Agent — UC-X
The final use case brought everything together.
The task was to build an interactive policy Q&A system using three separate documents:
- HR Leave Policy
- IT Acceptable Use Policy
- Finance Reimbursement Policy
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.
Enforcement rules
The final workflow required:
- One supporting source document
- Filename + section citation
- No cross-document blending
- No invented permissions
- No hedged statements
- Preservation of conditions and restrictions
- Exact refusal for unsupported questions
For unsupported questions, the required response was:
“This question is not covered in the available policy documents…”
The test cases successfully demonstrated:
- Annual leave carry-forward → HR 2.6–2.7
- Slack installation → IT 2.3
- Home-office allowance → Finance 3.1
- Flexible-working culture → exact refusal
- Leave Without Pay → HR 5.2
Key lesson
The most important part of a document Q&A system isn't just retrieval.
It's knowing when not to answer.
What I Learned
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.
Top comments (0)