DEV Community: heric libong

WHAT IS THIS RUBBER DUCK FOR?

heric libong — Fri, 10 Apr 2026 09:08:09 +0000

This is a submission for the DEV April Fools Challenge

What I Built

The starting point was a brief moment in Harry Potter and the Chamber of Secrets, when Arthur Weasley asks Harry: "what exactly is the function of a rubber duck?"

I took that very essential question as the basis for the project and turned it into a ministerial interface for the formal examination of a yellow plastic duck.
So I built What Is This Duck For?, a web app that treats a rubber duck as a matter of public administration, emotional uncertainty, procedural concern, and possible domestic surveillance.

The app lets visitors submit the duck to five official interpretive modes:

Analyze the Duck — a mock-expert technical reading
Request Deeper Interpretation — overthinking, philosophical drift
Escalate to Ministry — paperwork, forms, bureaucratic misery
Trust the Duck — calm reassurance and quiet faith
Do Not Trust the Duck — bathroom paranoia and suspicious side-eye

Each mode generates a formal “ministerial report” with a hypothesis, classification, threat level, confidence score, and conclusion. The result is mildly concerning, far more official than necessary, and hopefully funny.

Demo

You can try the live demo here:

Live Demo

The interface is designed to feel strangely official for something that should never have required official attention in the first place.

A typical session looks like this:

choose a mode
trigger the inquiry
watch the report compile itself
leave with fewer answers than you started with

Code

Source code is available here:

GitHub Repository

The project includes:

a FastAPI backend
Gemini 2.5 Flash
a custom frontend with a ministry-style interface
prompt-based persona logic
an About page explaining the investigation as if it were a real institutional service
custom duck persona assets for each official mode

How I Built It

I built the app with FastAPI, server-rendered templates, custom CSS, and JavaScript for the interactive report flow.

The biggest part of the work was not _“building a useful product,” _but overbuilding a completely useless one with as much conviction as possible.

A few highlights:

I designed the homepage as a fake bureaucratic dashboard
I created five distinct duck-analysis personas with different tones and behaviors
I refined the generated writing so each mode felt readable, funny, and specific
I added custom duck visuals for each persona on the About page
I deployed the demo on Hugging Face Spaces

For the AI side, I worked with Gemini CLI from the beginning, using it throughout the project to build, refine, and steer the experience. On the generation side, I used Google Gemini to produce structured, persona-driven reports that stayed coherent, readable, and funny.

One of the most interesting challenges was building the five analysis personas so they produced outputs that felt distinct, coherent, and consistently funny without becoming repetitive. That required a lot of prompt iteration — especially around the relationship between hypothesis and conclusion — and a gradual shift away from pure absurdity toward a more structured comic logic, all with Gemini 2.5 Flash.

Agents Sessions

1 - This initial prompt defined the joke, the scope, and the rules of the project from the start.

what_is_the_duck_for - initial prompt initial prompt

You

You are my coding assistant. I am building a deliberately silly challenge project called "What Is This Duck For?".

Context:
- This project is for a challenge whose spirit is: build something intentionally useless, funny, light, absurd, and simple.
- The concept: a very serious interface uses Google Gemini to analyze a yellow rubber duck, but never reaches a useful conclusion.
- This is NOT a serious product, NOT an MVP, NOT a scalable app.
- It must stay small, clean, readable, and fun.
- No overengineering.

Your role for this step:
Bootstrap the project environment from scratch inside the current workspace.

Current state:
- Workspace already exists.
- A Python virtual environment .venv already exists.
- Nothing else is installed yet.

Technical direction:
- Python backend with FastAPI
- Simple frontend with HTML/CSS/vanilla JS
- Gemini API integration later
- No database
- No authentication
- No React
- No Docker for now
- No testing setup yet unless strictly necessary
- Keep the architecture minimal

What I want you to do now:
1. Inspect the current workspace first.
2. Activate/use the existing .venv.
3. Install only the minimal dependencies needed for the initial project skeleton:
- fastapi
- uvicorn
- jinja2
- python-dotenv
- google-genai
4. Create a clean minimal project structure for this app.
5. Add a .gitignore.
6. Add a .env.example.
7. Add a minimal README.md that presents the project in the spirit of the challenge.
8. Add the minimal FastAPI app skeleton and the basic template/static folders, but do NOT build the full app yet.
9. Make sure the structure is simple and easy to continue step by step.

Recommended structure:
- app/
- main.py
- gemini_service.py
- prompts.py
- templates/
- index.html
- static/
- css/
- style.css
- js/
- app.js
- img/
- .gitignore
- .env.example
- README.md
- requirements.txt

Important constraints:
- Do not invent extra features.
- Do not add database, auth, admin panel, API complexity, or unnecessary abstractions.
- Do not implement the real Gemini logic yet beyond placeholder structure.
- Do not generate a complex UI yet.
- Keep names explicit and readable.
- Keep the codebase lightweight and hackathon-friendly.
- Prefer clarity over cleverness.

After you make the changes:
1. Show me the final file tree.
2. Explain briefly what you installed and created.
3. Tell me exactly what command I should run next to start the app locally.
4. Mention any point that still needs my manual input, especially the Gemini API key.

If something is ambiguous, make a reasonable minimal choice and state it clearly.

24 messages not shown

Agent

Providing the Final Response

The project "What Is This Duck For?" is now bootstrapped with a minimal FastAPI skeleton and a clean directory structure.

Final File Tree

.
├── app/
│   ├── static/
│   │   ├── css/
│   │   │   └── style.css
│   │   ├── img/
│   │   └── js/
│   │       └── app.js
│   ├── templates/
│   │   └── index.html
│   ├── gemini_service.py
│   ├── main.py
│   └── prompts.py
├── .env.example
├── .gitignore
├── README.md
└── requirements.txt

What was installed and created:

Dependencies: fastapi, uvicorn, jinja2, python-dotenv, and google-genai were installed into your existing .venv. A requirements.txt was generated.
Backend Skeleton: Created app/main.py with basic routing and static file serving.
Gemini Service: Added app/gemini_service.py and app/prompts.py as placeholders for the AI logic.
Frontend: Built a minimalist "Advanced Rubber Duck Analytics" interface using vanilla HTML, CSS, and JS.
Project Docs: Added a README.md in the spirit of the challenge and a .env.example for configuration.

How to start the app locally:

Prepare Environment: bash cp .env.example .env
Run the Server: bash .venv/bin/uvicorn app.main:app --reload
View the App: Open your browser at http://localhost:8000.

Manual Input Needed:

Gemini API Key: You need to edit the .env file and provide a valid GEMINI_API_KEY.
Duck Image: I've created the app/static/img/ folder. You might want to drop a picture of a rubber duck there later to replace the CSS placeholder.

36 messages not shown

You

You are my coding assistant.

We are continuing the project:
WHAT IS THIS DUCK FOR?

Important:
Do not implement the Gemini engine yet.
Do not redesign the UI.
Do not add backend complexity.
This step is about documentation, planning, and locking the behavior of the 5 buttons.

PROJECT STATE

The interface now includes the 5 final action buttons:
1. ANALYZE THE DUCK
2. REQUEST DEEPER INTERPRETATION
3. ESCALATE TO MINISTRY
4. TRUST THE DUCK
5. DO NOT TRUST THE DUCK

We want to keep the project simple and organized.
So before implementing the engine, we want:
- a small docs folder
- a clear planning document
- a task checklist we can follow and update
- a mini-spec for the 5 button modes

YOUR TASK

Create a docs/ folder at the project root.
Inside docs/, create these files:

project_plan.md
task_checklist.md
button_modes.md

Fill them with simple, practical, readable content.

CONTENT REQUIREMENTS

A) docs/project_plan.md
Create a short project plan that reflects the real order of work:

current state
what is already done
what comes next
what should come later

The order should be:

Environment bootstrap
Basic app skeleton
UI base
Final button set in the interface
Lock the behavior of each button
Implement Gemini interaction
Polish the UI and visual identity
Final cleanup / submission preparation

Keep it concise.
Do not write corporate/project-management jargon.
Write it like a practical internal roadmap.

B) docs/task_checklist.md
Create a checklist with markdown checkboxes.

Include:
- completed tasks
- current tasks
- upcoming tasks

Use clear checkboxes like:
- [x] ...
- [ ] ...

Include at least:
- project bootstrapped
- FastAPI skeleton created
- single-page UI created
- 5 final buttons added
- button behavior spec pending
- Gemini backend pending
- report panel dynamic update pending
- rubber duck visual improvement pending
- aesthetic polish pending
- README/submission refinement pending

C) docs/button_modes.md
This is the most important file for this step.

Write a mini-spec for the 5 buttons.

For each button, define clearly:
- button label
- internal mode name suggestion
- role
- tone
- type of absurdity / angle of error
- expected response style
- what kind of conclusion it should tend to produce

Use these 5 buttons exactly:

Analyze the Duck
base pseudo-scientific analysis
Request Deeper Interpretation
over-interpretation / intellectual overreach
Escalate to Ministry
absurd bureaucracy / official classification
Trust the Duck
confident mystic reading / symbolic authority
Do Not Trust the Duck
suspicious administrative paranoia

IMPORTANT RULES

Keep all docs short and useful.
Do not overengineer.
Do not add product language.
Do not implement code logic yet unless absolutely necessary.
Do not change the backend or Gemini integration in this step.
If you need to make a very small frontend text adjustment for consistency, keep it minimal and list it explicitly.

OUTPUT REQUIRED

After making the changes, show me:

the final file tree for the new docs/ folder
the full contents of:
docs/project_plan.md
docs/task_checklist.md
docs/button_modes.md
a short explanation of how these docs will help the next implementation step
if you changed any file outside docs/, list it explicitly

Agent

Structuring Project Documentation / Outlining the Button Spec / Formulating Button Mode Details / Executing the Plan's Steps

I will create the docs/ directory and populate it with the project plan, task checklist, and button mode specifications.

7 messages not shown

Agent

I have created the requested documentation and planning folder.

Final File Tree for `docs/`:

docs/
├── button_modes.md
├── project_plan.md
└── task_checklist.md

Contents Summary:

project_plan.md: Provides a concise, practical roadmap from project bootstrap to final cleanup, focusing on building a "serious, useless" application.
task_checklist.md: Lists all completed, current, and upcoming tasks with markdown checkboxes, covering infrastructure, interface, and AI integration phases.
button_modes.md: A detailed specification for the five analysis buttons, defining their internal mode names, tones, absurdity angles, and expected response styles.

How these docs will help:

Consistency: button_modes.md ensures that as we implement the AI prompts, each mode remains distinct and follows its intended "absurdity angle" (e.g., dry science vs. mystic prophecy).
Focus: project_plan.md keeps the project scope narrow, preventing feature creep and maintaining the simple, single-page concept.
Organization: task_checklist.md allows us to track our progress accurately and ensures we don't skip the crucial "polish" steps at the end.

No files were changed outside of the docs/ folder in this step. We are now ready to implement the backend logic to handle these specific modes.

2 - Persona Refinement | Making “Ministry” Funnier and More Concrete

Persona building | what is duck for persona_building

You

We are doing a targeted correction pass on the "ministry" persona only.

Do not change frontend.
Do not change backend flow.
Do not change logging.
Do not change JSON schema.
Do not modify the other personas unless strictly necessary.

DIAGNOSIS

The other personas are now much closer to the desired result.
The main remaining failure is "ministry".

Current problem:
"ministry" still tends to generate bureaucratic worldbuilding instead of a clear comic theory of function.

It produces:
- too much administrative texture
- too many clauses, sections, and procedural layers
- too much fake-ministry prose
- not enough immediate sense

The result is coherent in tone, but not funny enough and not clear enough.

CORRECTION GOAL

The ministry persona must no longer feel like:
"a generic bureaucratic monologue"

It must feel like:
"a civil servant calmly explaining the duck’s specific administrative function and the ridiculous procedural consequences attached to it"

NEW RULES FOR MINISTRY

The hypothesis must clearly state what the duck is administratively FOR.
It must describe a concrete official or semi-official function.
The function must be simple, specific, and readable.
The conclusion must comment on the administrative implications of that function.
It must not spiral into ministry lore.
Keep the bureaucracy petty, local, and humiliating.
Not epic, not sprawling.
Prefer:
one form
one permit
one missing signature
one wrong classification
one absurd office rule
over:
multiple clauses
layered subcommittees
long directive chains
abstract grievance systems
The joke should be understandable even on first read.
The duck must remain central.
The bureaucracy must exist because of the duck’s function, not the other way around.

GOOD DIRECTION EXAMPLES

The duck serves as a floating compliance marker for baths already in progress.
The duck functions as an informal complaint receiver for minor bath-related grievances.
The duck is required as a witness object before a splash incident can be officially recorded.
The duck temporarily certifies that a bather is still emotionally eligible for continued soaking.

BAD DIRECTION EXAMPLES

abstract grievance manifestation object
sprawling directive chains
excessive clause stacking
vague ministry lore
classification replacing function

TONE TARGET

The humor should come from:
- procedural seriousness
- ridiculous administrative logic
- calm official language applied to a bath toy

It should be funny because it sounds annoyingly plausible,
not because it sounds huge or overbuilt.

TASK

Update only the ministry persona instructions in app/prompts.py.
Update docs only if needed for consistency.
Do not touch the other persona instructions unless required.

After changes, show:
1. the updated ministry prompt section
2. any doc changes if made
3. a short explanation of how you made ministry clearer, more concrete, and less lore-heavy
4. confirmation that JSON schema, frontend, backend flow, and logging were unchanged

Agent

Refining the Persona / Prioritizing Functionality

I will update the "ministry" persona in app/prompts.py to ensure it focuses on a clear, concrete administrative function for the duck, followed by a humorous interpretation of its procedural consequences. I'll then review and adjust docs/tone_charter.md and docs/button_modes.md to ensure they remain consistent with this more targeted, petty bureaucratic tone.

1 message not shown

Agent

I have updated the "ministry" persona in app/prompts.py to be more concrete and petty.

1. Updated Ministry Prompt Section

    "ministry": """
    PERSONA: THE PETTY CIVIL SERVANT
    Function Claim: Propose a simple, concrete administrative role for the duck (e.g., a witness for splash-claims, a floating compliance marker, a receiver for bath-grievances).
    Style: Calm, official, and annoyingly procedural. Focus on one specific hurdle: one missing permit, one wrong signature, or an expired bather-eligibility form.
    Avoid: Sprawling lore, multiple clauses, or epic bureaucracy. Keep it local, petty, and understandable.
    Conclusion: Explain the specific administrative consequences or jurisdictional headache caused by the hypothesis.
    """,

2. Documentation Changes

I have verified docs/tone_charter.md and docs/button_modes.md. They already align with this "petty bureaucrat" direction, so no further changes were required there.

3. Explanation of Changes

Concrete Function: The model is now explicitly told to propose a simple administrative role (e.g., "witness for splash-claims") instead of generating abstract "grievance manifestation" lore.
Petty Hurdles: I replaced the instruction for "rigid legalistic style" with a focus on specific, relatable administrative failures like "one missing permit" or "one wrong signature."
Reduced Lore: I banned "sprawling lore" and "epic bureaucracy" to ensure the joke remains grounded in the bathroom context and is immediately understandable.

4. Confirmations

JSON schema remains unchanged.
Frontend was not modified.
Backend flow remains exactly the same.
Logging is still active and unchanged.

Prize Category

I’m primarily submitting this for Best Google AI Usage.

Gemini was a core part of the project, both in the building process and in the app itself. It helped turn a simple joke into a system of distinct personas, structured reports, and consistently readable comic outputs rather than generic AI text.

And if the Ministry happens to win over the public, I would gladly accept the consequences under Community Favorite.

Thanks for reading, and please proceed with caution.
In matters involving the yellow rubber duck, certainty remains premature.

Unlocking an African Mythology Archive with Gemini: From a Django API to a Living Archive

heric libong — Wed, 04 Mar 2026 10:58:38 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

I built African Mythology: Living Archive, an application designed to structure and bring to life the mythological pantheons of Sub-Saharan Africa. Using AI, the project organizes mythological entities, their complex relationships, and their visual representations.

The problem: Oral traditions facing a structural challenge

Unlike Greek, Egyptian, or Norse mythologies, the myths of Sub-Saharan Africa are primarily transmitted through oral tradition. Although some information exists online, it is often fragmented, scattered, and poorly structured.

In 2024, I attempted to create a Django API to organize this cultural heritage. The project remained at the “empty shell” stage: for a solo developer, the research effort and manual data entry required to transform oral narratives into structured data was simply too large.

The role of Gemini: Turning the idea into something real

The Google DeepMind – Vibe Code with Gemini 3 Pro hackathon on Kaggle helped revive the project. The central question — “What can we do today with AI that was impossible before?” — became the turning point.

The API architecture already existed, but I lacked a way to quickly explore relationships between entities and generate a coherent visual universe. Gemini allowed me to:

Explore and test pantheon structures at scale
Accelerate the structuring of entities and genealogies
Generate the foundations of an iconography that respects cultural markers

Phase 1 — Hackathon (Experimentation and Vibe Coding)

The starting point was my original models.py file from 2024. Instead of manually writing import scripts, I used this model as context for Gemini to explain the domain logic of the project.

Excerpt from the initial data model:

# Divinities, Heroes and Creatures: base structure
class Divinity(models.Model):
    name = models.CharField(max_length=100)
    ethnicity = ArrayField(models.CharField(max_length=100))
    domain = ArrayField(models.CharField(max_length=100))
    story_description = models.TextField()
 [...]


class Hero(models.Model):
    name = models.CharField(max_length=100)
    story = models.TextField()
    country = models.CharField(max_length=100)
 [...]

class MythicalCreature(models.Model):
    name = models.CharField(max_length=100)
    description = models.TextField()
    habitat = models.CharField(max_length=255)
 [...]

From this base, Gemini helped formalize a consistent JSON structure. This workflow enabled the creation of the first functional prototype using the Build tool in Google AI Studio, following a Vibe Coding approach. At this stage, navigation and structure were validated without requiring a full backend.

Phase 2 — Development and Integration (Antigravity)

After the hackathon, the project moved from prototype to a working engine. This development phase outside the competition made it possible to industrialize the workflow:

Antigravity: Used to orchestrate the flows between Gemini model calls and the generation of structured content for the application (entities, relationships, and visual prompts).
Gemini 3 Pro Agent: Used to design orchestration logic and progressively integrate it with the existing API.
Visualization: Generation of precise prompts for _Imagen (Vertex AI) _to avoid generic representations.

Demo

The current demo represents the first functional stage of a larger roadmap. The long-term goal is to build a true interactive archive of Sub-Saharan African mythologies, enabling users to explore pantheons, their relationships, and their stories through a visual and conversational interface.

You can explore the demo here:

Hugging Face Application (Live):

GitHub Repository (V2):
https://github.com/hericlibong/african_mythology_V2

What I Learned

Working on this project changed the way I think about using AI in a development workflow.

** Giving the model** real structure makes a huge difference. Once Gemini had access to my Django models.py, the responses became much more coherent because it could understand the logic of the project.
LLMs are surprisingly good at structuring narrative data. Gemini helped turn mythological stories into consistent JSON structures that the application could actually use.
Cultural content requires very precise prompting. Without strong constraints, image generation quickly drifts toward generic representations rather than culturally meaningful ones.

Google Gemini Feedback

Working with Gemini was a key part of turning this project from an idea into a working prototype.

What worked well

Gemini was very effective at structuring narrative information into usable data. It helped transform mythological descriptions into consistent JSON structures that could be integrated into the application.
Providing project context (like my Django models) significantly improved the quality of the responses.
Google AI Studio made it easy to iterate quickly during the experimentation phase.

Where I ran into friction

Image generation required many iterations to avoid generic or culturally inaccurate outputs, especially for mythological figures tied to specific traditions.
Moving from experimentation in AI Studio to a more production-ready workflow still requires some learning and tooling adjustments.

Infograph2Data: Unlocking the Data Trapped in Pixels 📊

heric libong — Mon, 16 Feb 2026 07:31:03 +0000

This is a submission for the GitHub Copilot CLI Challenge

Infographics and charts are everywhere… but the numbers inside them are often stuck in images and PDFs. If you work in journalism, reporting, research, or data storytelling, you’ve probably retyped values by hand (slow), or avoided using a chart altogether (worse).

Infograph2Data is a web app that turns static charts (PNG/JPG) and PDF pages into structured data you can actually use: CSV / Excel / JSON.

What I Built

A Visual Data Extraction pipeline with a clean “human-in-the-loop” workflow:

1) Upload an image or a PDF

2) Identify chart type + structure (line/bar/pie/scatter, etc.)

3) Select what to extract (series, axes, categories)

4) Review and edit the extracted numbers in a spreadsheet-like UI

5) Export to CSV / Excel / JSON

This is designed for real-world usage: you don’t blindly trust the model—you validate and correct before exporting.

Why this exists (the genesis)

I’m building tools around data storytelling and journalism workflows. A lot of valuable information is published as visuals (reports, infographics, screenshots, press charts), but using that data in analysis or visuals requires manual work. Infograph2Data was built to bridge that gap: “from pixels to data” in minutes.

Demo

✅ Live demo (Hugging Face Space):

✅ GitHub repository:

https://github.com/hericlibong/Infograph2Data

No login required. Just upload a chart/PDF or screenshot PNG or JPG and run the flow.

Demo assets for judges

The repo includes a demo_assets/ folder with multiple chart styles (bar/line/pie + PDF).

This lets judges test quickly without hunting for files.

https://github.com/hericlibong/Infograph2Data/tree/main/demo_assets

Tech Stack (high-level)

Backend

FastAPI (API + serving the built frontend)
Vision-capable LLM extraction (OpenAI key-driven)
PDF support (page rendering + multi-page flows)
Structured schemas + validation

Frontend

React + Vite (TypeScript)
5-step wizard UI
Spreadsheet-like review/edit experience
Clear API health indicator

Deployment

Docker-ready
Hugging Face Spaces demo

The “Copilot CLI-first” part (this is the core of my submission)

This project was built with GitHub Copilot CLI as my main sidekick in the terminal.

Every major step started as a prompt, not as copy/paste from external code:

architecture & folder structure
FastAPI routers + services
frontend pages/components for the 5-step flow
debugging sessions (logs → hypothesis → patch)
deployment fixes and dev/prod parity adjustments

I kept a full “prompt trail” inside the repository:

/docs/prompts_history.md (the seed prompts + planning)
/docs/devlog.md (the step-by-step build + decisions + fixes)

That means judges can audit the process: it’s prompted development end-to-end, not repackaging code from elsewhere.

Important note: I intentionally avoided pulling in random snippets from the internet. The work here is original and built from scratch, with Copilot CLI assisting me as a terminal-native engineering copilot.

A concrete example where Copilot CLI saved the day (deployment bug)

Right before submission, the Hugging Face demo was “live” but uploads failed:

/api/health returning 404
POST /api/files returning 405

This was a classic frontend/backend routing mismatch:

the frontend called /api/*
the backend exposed routes at /health, /files, etc.
requests fell into the SPA catch-all route → 404/405

Using Copilot CLI in the terminal, I quickly:

diagnosed the mismatch from server logs
updated the backend routing to use a consistent /api prefix
ensured local dev matched production by keeping the /api prefix in the Vite proxy

Result: ✅ demo works again, and local dev stays aligned with prod.

Usability & UX choices (judging criteria)

To make this judge-friendly and actually usable:

5-step guided flow (no guessing)
Health indicator (you instantly know if the API is reachable)
Human-in-the-loop review (edit before export)
Instant export to formats people really use (CSV/Excel/JSON)
Demo assets included (fast testing)

If you want to run it locally (quick)

git clone https://github.com/hericlibong/Infograph2Data.git
cd Infograph2Data
cp .env.example .env   # add your OPENAI_API_KEY
docker build -t infograph2data .
docker run -p 7860:7860 --env-file .env infograph2data

My Experience with GitHub Copilot CLI

Copilot CLI was most valuable when:

turning vague requirements into a clean architecture fast

generating consistent scaffolding across backend + frontend

debugging from real logs under time pressure

keeping momentum without leaving the terminal

This challenge theme is spot-on: Copilot in the terminal isn’t just autocomplete—used well, it becomes a workflow accelerator.

Connect & Repositories

SassyAI: The Sarcastic AI Assistant

heric libong — Sun, 11 May 2025 23:33:48 +0000

This is a submission for the Amazon Q Developer "Quack The Code" Challenge: That's Entertainment!

What I Built

SassyAI: The Judgy Assistant

SassyAI is an interactive, sarcastic AI assistant that never fails to roast users with witty, snarky, and sometimes outright rude responses. Designed for developers and tech enthusiasts looking for a humorous break, SassyAI doesn’t just provide answers—it provides attitude.

Update (V2 is live 🚀)

A new version is available as a web chatbot powered by an LLM, with a fresh UI and a versioned persona.

Repo (V2): https://github.com/hericlibong/SassyAI

Live demo (Hugging Face): https://ricolajazz-sassy-ai.hf.space

Features:

Dynamic Theme Switching: Choose between several sarcasm-infused themes (e.g., general knowledge, coding, philosophy, food debates, rogue AI fears).
Customizable Contexts: Easily add new sarcastic themes by sending prompts to Amazon Q.
One-Session Interactivity: No need to restart the app—switch themes and continue bantering seamlessly.
Personalized Experience: The user can set a nickname to make interactions more engaging.
Visual Flair: Thanks to the integration of Rich, SassyAI’s responses are not only witty but also visually appealing.
Command Guide: Interactive help and theme selection directly from the chat.

SassyAI is not just an AI assistant; it’s an AI that doesn’t care about your trivial questions—and isn’t afraid to say it.

Demo

Code Repository

Repo github

How I Used Amazon Q Developer

Amazon Q Developer played a crucial role in generating sarcastic responses for different contexts. Here’s how we leveraged it:

1. Automated Sarcasm Generation:

We crafted context-specific prompts to elicit humorous and ironic replies.
For instance, for the "general knowledge" theme:

Act as a sarcastic AI assistant who refuses to answer simple factual questions.
Generate 5 different humorous responses for the question: "What is the capital of France?"
The tone should be mocking, but clever.

Amazon Q delivered varied responses, which we integrated seamlessly into the engine.py file.

2. Theme Expansion:

We used Amazon Q to quickly prototype new contexts like "sports" or "nerd culture" by generating sarcastic replies based on custom prompts.
The responses were automatically structured and added to the engine for fluid integration.

3. Customization:

The modular nature of the responses allows for quick addition of new themes.
Users can extend the list by simply sending a prompt in the correct format to Amazon Q.

Installation and Usage

Prerequisites:

Python 3.12

Installation Steps:
1 - Clone the repository:

git clone https://github.com/hericlibong/SassyAI-v1
cd SassyAI

2 - Create and activate the virtual environment:

python3.12 -m venv venv
source venv/bin/activate

3 - Install dependencies:

pip install -r requirements.txt

4 - Run the CLI:

python sassy_ai/main_cli.py 
or cd sassy_ai
python main_cli.py

Log File

SassyAI generates a log file (amazon_q_log.md) that documents each prompt sent to Amazon Q and the corresponding responses. This log provides transparency regarding which contexts were generated automatically and helps in tracking future improvements.

Customization: Adding Your Own Themes

SassyAI is designed to be extensible. You can easily add your own sarcastic themes using Amazon Q.

Example: Adding a "sports" theme

1 - Generate responses with Amazon Q:

Act as a sarcastic AI assistant who dislikes sports discussions.  
Generate 5 different humorous responses for the question on sport events, sport practice, or sport personality.  
The tone should be mocking, as if the AI finds sports debates boring or trivial.

2 - Amazon Q Integration:

The responses will be automatically placed in the engine.py file under custom_responses.
The corresponding regex will be added to custom_patterns.

3 - Update the theme list:
Modify main_cli.py to include the new theme

"sports": {"prompt": "Who is the best football player?", "color": "blue", "emoji": "⚽"},

Feedback and Contribution

Your feedback is welcome!
Feel free to contribute by creating pull requests or submitting issues on GitHub.
Let’s make SassyAI even sassier!

DEV Community: heric libong

WHAT IS THIS RUBBER DUCK FOR?

What I Built

Demo

Code

How I Built It

Agents Sessions

Final File Tree

What was installed and created:

How to start the app locally:

Manual Input Needed:

Final File Tree for docs/:

Contents Summary:

How these docs will help:

1. Updated Ministry Prompt Section

2. Documentation Changes

3. Explanation of Changes

4. Confirmations

Prize Category

Unlocking an African Mythology Archive with Gemini: From a Django API to a Living Archive

What I Built with Google Gemini

The problem: Oral traditions facing a structural challenge

The role of Gemini: Turning the idea into something real

Phase 1 — Hackathon (Experimentation and Vibe Coding)

Phase 2 — Development and Integration (Antigravity)

Demo

What I Learned

Google Gemini Feedback

Infograph2Data: Unlocking the Data Trapped in Pixels 📊

What I Built

Why this exists (the genesis)

Demo

Demo assets for judges

Tech Stack (high-level)

The “Copilot CLI-first” part (this is the core of my submission)

A concrete example where Copilot CLI saved the day (deployment bug)

Usability & UX choices (judging criteria)

If you want to run it locally (quick)

Connect & Repositories

SassyAI: The Sarcastic AI Assistant

What I Built

SassyAI: The Judgy Assistant

Update (V2 is live 🚀)

Features:

Demo

Code Repository

How I Used Amazon Q Developer

Installation and Usage

Log File

Customization: Adding Your Own Themes

Feedback and Contribution

Final File Tree for `docs/`: