DEV Community: Pramod Kodag

I built an API that roasts you, and every response is AI-generated

Pramod Kodag — Mon, 22 Jun 2026 08:32:23 +0000

TL;DR I built Snark, an open-source REST API that serves AI-generated humor. Roasts, brutally honest commit messages, ELI5, corporate jargon, and around 25 other endpoints. Every response is a live LLM call, so you almost never get the same line twice. Here's how it works under the hood.

Why I built it

Most joke APIs hand you a random line from a static list. That's fine for about ten requests, and then you've seen everything it has.

I wanted the opposite. An API where every response is generated fresh by a language model, in the voice of a specific persona, and where the same endpoint almost never repeats a joke on you. Honestly it started as an excuse to learn provider fallback and caching properly, but I ended up using it more than I expected.

Here are a few real responses from the running service:

$ curl -s localhost:8100/v1/wit/commit-message/ | jq -r .response
fix: finally found the typo

$ curl -s localhost:8100/v1/wit/bug-blame/ | jq -r .response
The culprit behind the burnt toast is a rogue toaster wire,
sparked to life by a freak solar flare. Case closed.

$ curl -s "localhost:8100/v1/wit/explain-like-im-5/?q=quantum+physics" | jq -r .response
Quantum physics is like coloring with crayons, but the colors
can be in many places at the same time.

The stack

Nothing exotic here:

Django and Django REST Framework for the API
PostgreSQL for personas and a response log
Redis for caching and per-IP rate limiting
Groq as the default model provider on its free tier, with Gemini and Claude as optional fallbacks
Docker Compose, so a single docker compose up brings the whole thing up with nothing external to provision

Provider fallback is the part I care about

If you lean on a single model provider, it will eventually let you down. Rate limits, content filters, the occasional 500. So Snark doesn't trust any one provider on its own.

Every endpoint runs through one orchestrator. It tries the default provider, and if that goes wrong it walks down a chain:

def _generate_with_fallback(system_prompt, user_prompt, temperature, max_tokens):
    primary = ProviderRegistry.get()
    try:
        return primary.generate(...)
    except ContentFilterError:
        # The model refused. Soften the prompt and retry on the SAME provider
        # before giving up on it.
        softened = system_prompt + "\n\nIMPORTANT: Keep it light and safe..."
        try:
            return primary.generate(system_prompt=softened, temperature=max(temperature - 0.2, 0.3), ...)
        except (ContentFilterError, ProviderError):
            pass
    except ProviderError:
        pass

    # Primary is out. Walk the rest of the chain.
    for fallback in ProviderRegistry.get_fallbacks(exclude=primary.name):
        try:
            return fallback.generate(...)
        except (ContentFilterError, ProviderError):
            continue

    raise ProviderError("All AI providers failed to generate a response")

The bit I'm happiest with is the content-filter branch. When a model refuses, the first instinct is to bail and hit the next provider, but a lot of the time the model just needs a calmer prompt. So before switching anything, it lowers the temperature, appends a "keep it safe" line, and asks the same provider again. That alone rescues a surprising number of requests, and it's cheaper than paying for a second provider's round trip.

The other nice side effect is that a provider is just a class with a generate() method. When I added Claude, it was one new file. The registry handles the ordering and the "don't retry the one that already failed" logic.

Stopping it from repeating itself

A generator that keeps repeating itself feels broken, even if every response is technically a fresh API call. I deal with this in the prompt rather than in code.

Right before each call, Snark grabs the last 10 responses for that persona from the database and drops them into the system prompt as a "don't do these again" list:

recent = (
    ResponseLog.objects.filter(persona=persona)
    .order_by("-created_at")
    .values_list("response_text", flat=True)[:ANTI_REPETITION_COUNT]
)

anti_rep = (
    "\n\nIMPORTANT: Do NOT repeat or closely paraphrase any of these "
    "recent responses. Be completely original:\n"
    + "\n".join(f'- "{s[:80]}"' for s in recent)
)

It's cheap, the model doesn't have to remember anything between calls, and in practice it does a good job of keeping things varied.

Caching without making everything identical

This one's a bit of a contradiction. Caching saves money and latency, but the entire point of the service is that responses are unique. Cache too hard and you've built the static joke list I was trying to avoid.

The middle ground I landed on is to cache by the exact shape of the request, but only for a few minutes. The key is a SHA-256 of slug : user_input : mood, and it expires after five:

def _response_cache_key(slug, user_input, mood):
    raw = f"{slug}:{user_input}:{mood or ''}"
    digest = hashlib.sha256(raw.encode()).hexdigest()[:16]
    return f"wit:resp:{digest}"

So if two people hit /roast/dave/?mood=spicy in the same minute, they share one result and I only pay for one call. Across different inputs, or the same input a few minutes later, you still get something new. Each response tells you which one you got:

{ "response": "...", "persona": "The Honest Committer", "cached": false }

Personas instead of hardcoded prompts

Every endpoint maps to a persona that lives in the database. A name, a system prompt, a tone, some rules, and its own temperature and max_tokens. "The Honest Committer" writes the commit messages, "The Feedback Villain" handles code review comments. Adding an endpoint is usually just adding a row, not writing code.

On top of that there's an optional ?mood= parameter (sarcastic, deadpan, unhinged, wholesome, and so on) that overrides the tone, so one persona can say the same thing fifteen different ways.

A few things I learned

The one that bit me: my tests mock the model SDKs, which is the right call for fast, deterministic tests, but it also means a green test suite tells you nothing about whether a provider's real API still matches your code. When I started bumping dependencies I had to check the SDKs structurally instead of trusting the checkmark.

Bundling Postgres and Redis into the compose file early was worth it too. Once docker compose up brought up everything, the "how do I even run this" questions disappeared.

And the thing that took longest to accept is that the jokes were the easy part. The fallback, the retries, the anti-repetition, the caching, that's what actually makes it feel like a real service rather than a demo.

Try it

It's open source under AGPL-3.0 and free. The endpoints don't need any auth or keys. You only need a free Groq key to run your own instance:

git clone https://github.com/PramodTKodag/snark.git
cd snark && cp .env.example .env   # add a free Groq key
docker compose --profile dev up
curl http://localhost:8100/v1/wit/roast/your-pr/

Repo is here: https://github.com/PramodTKodag/snark

If it got a laugh out of you, a star on the repo genuinely helps. And if you'd have built the fallback differently, I'd like to hear it.

🔒 The Future of Authentication Is Coming

Pramod Kodag — Fri, 15 Aug 2025 15:07:04 +0000

For years, authentication has been stuck in the same cycle, passwords, OTPs, wallets, and endless sign-in hoops.

I’m building something that changes that

It’s secure enough to trust with your most valuable data, yet simple enough for anyone to use without a manual.

It bridges the gap between the familiar world of today’s logins and the decentralized possibilities of tomorrow, all without the friction you’ve come to expect.

No, I’m not ready to spill the technical magic just yet.

But I will say this: once you’ve experienced it, going back to the old way of logging in will feel like using dial-up internet in 2025.

The countdown has begun.

Stay tuned.

HR Management system using FLASK framework

Pramod Kodag — Wed, 09 Aug 2023 10:47:59 +0000

I am thrilled to share one of my significant projects developed for Trakit Solutions—an Attendance and HR Management System. This web-based application, built on Flask, has revolutionized the company's workforce operations by providing an integrated solution for attendance tracking and streamlining HR processes.

Simplifying Attendance Tracking: The primary focus of this project was to simplify and automate the attendance tracking process. Leveraging the versatility of Flask, I designed a user-friendly interface that allows employees to conveniently log their attendance using various methods such as biometric devices, QR codes, or manual entry. The system captures and securely stores attendance data, ensuring accurate and reliable records.

Efficient HR Management: In addition to attendance tracking, the HR Management System offers an array of features to streamline HR processes. I developed modules to manage employee profiles, including personal details, employment history, and performance evaluations. This centralizes employee data, simplifying HR tasks such as onboarding, leave management, and generating comprehensive reports.

Enhanced Data Analysis and Reporting: To enable data-driven decision-making, I integrated powerful analytics and reporting capabilities into the system. Using Flask's extensibility, I incorporated data visualization libraries such as Matplotlib and Plotly. This allows HR administrators to gain valuable insights from attendance trends, employee performance, and leave patterns, facilitating resource planning and performance evaluation.

Seamless Integration and User-Friendly Interface: The Attendance and HR Management System seamlessly integrates with Trakit Solutions' existing infrastructure, ensuring a smooth implementation process. The user interface features a clean design and intuitive workflow, making it easy for employees and HR personnel to navigate and interact with the system. Continuous feedback and iterative development ensure ongoing enhancements for an optimal user experience.

This project exemplifies my expertise in web application development, specifically in leveraging Flask to deliver practical solutions for real-world business challenges. By simplifying attendance tracking, optimizing HR processes, and facilitating data analysis and reporting, this system has significantly improved Trakit Solutions' workforce management.

Through this project, I have demonstrated my dedication to leveraging technology to enhance operational efficiency and productivity within organizations. The Attendance and HR Management System stands as a testament to my ability to deliver effective solutions tailored to the unique needs of businesses in streamlining their HR processes.

HRManagementSystem #AttendanceTracking #FlaskDevelopment #WorkforceOptimization #DataAnalysis #EfficientHRProcesses

Selenium project with Python to scrap data

Pramod Kodag — Wed, 09 Aug 2023 10:46:16 +0000

I am excited to share one of my initial projects, which holds a special place in my portfolio. This project involved scraping data from the ICEGATE website while overcoming challenging security measures, including captchas. Through perseverance and expertise in Python, I developed a bot that successfully bypassed captchas using Tesseract, extracted and parsed the data, and stored it in a MySQL database.

Overcoming the Captcha Barrier: In the early stages of this project, I encountered captchas implemented on the ICEGATE website, designed to prevent automated scraping. Overcoming this obstacle required innovative thinking and technical skills. To address this challenge, I leveraged Tesseract, an OCR engine. By training Tesseract on a diverse set of captcha images, I enabled my bot to accurately recognize and decode captchas, effectively bypassing this security measure.

Scraping and Parsing Data: Once the captcha barrier was overcome, I focused on scraping the desired data from the ICEGATE website. Python, with its rich ecosystem of libraries, proved to be an excellent choice for this task. I utilized powerful web scraping libraries such as BeautifulSoup and Selenium to navigate the website, extract the required data, and prepare it for further processing.

Parsing the obtained data was a crucial step in transforming the raw information into a structured format. With Python's string manipulation capabilities and the use of regular expressions, I developed a robust parsing algorithm. This algorithm efficiently extracted the relevant information from the data dump, ensuring its cleanliness and compatibility for subsequent analysis.

Storing Data in MySQL Database: To ensure proper management and accessibility of the scraped data, I integrated a MySQL database into the project. Leveraging the MySQL Connector library in Python, I established a seamless connection between my bot and the database. This allowed me to store the parsed data in well-structured tables and columns, facilitating efficient retrieval and future use.