DEV Community: Harshit Raut

QuietPatch: Building an AI-Powered Repository Caretaker with Google Gemma and Reviewable Code Fixes

Harshit Raut — Fri, 23 Oct 2026 19:23:00 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

I built QuietPatch — an AI-powered repository caretaker that helps developers find, understand, and fix common maintenance issues in their codebases without manually inspecting every file.

QuietPatch combines deterministic code scanners with Google Gemma to analyze findings, prioritize issues, and generate reviewable code patches. It then runs verification checks and creates a maintenance report so developers can understand what was found, what was evaluated, and which fixes were proposed.

The key idea is to make repository maintenance less repetitive. Instead of manually searching for TODOs, checking configuration files, investigating broken documentation links, prioritizing issues, and drafting fixes from scratch, developers can use QuietPatch to automate much of that initial work.

Safety is built into the workflow: proposed patches remain reviewable, and developers must explicitly approve changes before they are applied. QuietPatch does not automatically commit or push code.

I built it to explore how AI agents can make software maintenance easier while keeping developers in control. The goal is simple: less time spent on repetitive codebase housekeeping, more time spent building and shipping software.

Demo

quietpatch.onrender.com

Code

Harshit10-LM / QuietPatch

A local-first AI repository caretaker powered by Gemma and Ollama. Detects technical debt, explains code maintenance issues, generates reviewable fixes, and traces agent workflows with Sentry.

QuietPatch 🌿

Your project works. QuietPatch makes it ready to ship. A local-first AI repository caretaker powered by Gemma for Hacktoberfest 2026 DEV Open-Source AI Challenge, Week 3: "Slow and Steady."

1. What QuietPatch Does

Every engineering team accumulates maintenance tasks that get continually postponed: broken internal markdown links, undocumented environment variables causing staging outages, unpinned dependencies, missing packaging scripts, and lingering # TODO and # FIXME comments.

QuietPatch is not another general-purpose AI chat bot or hallucinating code generator.

Instead, it acts as a deliberate, slow-and-steady repository caretaker:

Deterministic Discovery & Scanning: Discovers files while strictly respecting .gitignore and security limits; executes real AST and pattern scanners across documentation, configuration, TODOs, Python, and TypeScript.
Gemma-Powered Analysis & Prioritization: Feeds grounded evidence to an open-weight Gemma model to explain why each defect matters and assign a realistic severity (critical, high, medium, low, informational).
…

View on GitHub

How I Built It

I built QuietPatch around Google Gemma, an open-weight AI model family, with a workflow that combines deterministic code analysis and AI-assisted maintenance.

The AI behind QuietPatch

I use two execution modes:

Local inference: Gemma 4 E4B through Ollama, allowing developers to run AI analysis on their own machines without sending repository snippets to a hosted AI provider.
Hosted inference: Gemma 4 26B A4B Instruct through Google's Gen AI API, powering the publicly deployed demonstration on Render.

This dual-mode approach lets QuietPatch explore both local-first development and a hosted experience that people can access without installing the entire application.

How the agent works

I built a Python and Flask backend that coordinates the maintenance workflow:

Discover: Inspect the repository structure and identify supported files.
Scan: Use deterministic Python scanners to find maintenance issues, such as TODO/FIXME markers, broken documentation links, and configuration inconsistencies.
Analyze: Send relevant findings and bounded source context to Gemma for explanations and prioritization.
Propose: Ask the model to generate targeted, reviewable edits for eligible findings.
Validate: Check the proposed changes against the original files and enforce path and patch-safety rules.
Report: Present findings, proposed fixes, verification outcomes, and maintenance-run status in the dashboard.

An important design decision was to keep deterministic scanning separate from AI reasoning. The scanner establishes the evidence, while Gemma helps interpret it and suggest possible fixes. This makes it easier to distinguish confirmed findings from AI-generated recommendations.

The rest of the stack

Frontend: React, TypeScript, and Vite.
Backend: Python and Flask.
Local AI: Gemma 4 E4B with Ollama.
Hosted AI: Gemma through the Google Gen AI API.
Deployment: Render.
Observability: Sentry for tracking maintenance runs, model calls, latency, and failures.

I implemented background maintenance execution so long-running AI work does not need to keep the initial HTTP request open. Sentry tracing helps investigate failures across the different stages of the workflow.

Keeping developers in control

QuietPatch does not automatically commit or push AI-generated changes. Proposed patches are presented for review, and changes must be explicitly approved before application.

Hosted inference also has a clear privacy boundary: selected repository snippets are sent to Google's API. Local inference is available for developers who prefer to keep that analysis on their own machines.

The project is still evolving. Hosted models can return transient errors, time out, or produce unusable output, so I have been working on bounded retries, response validation, and preserving successful results when individual proposals fail. Those challenges have been an important part of learning how to build AI-assisted developer tools responsibly.

My main takeaway is that building an AI agent is not just about connecting a model to an API. It also requires deterministic checks, safe edit handling, clear state management, observability, and honest reporting when the model cannot complete a task.

Why Does Open Innovation Matter?

Open innovation made it possible to build QuietPatch around Google Gemma, with the flexibility to run AI locally through Ollama or use hosted inference through Google's Gen AI API.

This gives developers more choice over how their code is analyzed. Local inference helps keep repository snippets on their own machines, while the hosted version makes QuietPatch accessible through a public demo.

Working with Gemma also let me experiment with how open-weight AI can handle real developer workflows, from understanding maintenance issues to proposing reviewable fixes.

For me, open innovation means having the freedom to experiment, build, and adapt AI to practical problems—while keeping developers in control.

The Lazy Payoff

I tested QuietPatch on its sample repository, where it scanned 8 files and identified 14 maintenance findings. In one run, it also generated two reviewable patches.

The biggest benefit is reducing the repetitive work of finding issues, understanding them, and preparing fixes. I haven't measured the exact time saved yet, and hosted AI can still fail on some patch proposals, so there's more room to improve.

For now, QuietPatch helps turn manual repository housekeeping into a workflow that developers can review instead of starting from scratch.

Prize Categories

Best Use of Render — Hosting and deploying the public QuietPatch application.
Best Use of Gemma — Using Google Gemma for repository analysis and AI-assisted patch proposals.
Best Use of Sentry Agent Tracing — Tracing maintenance runs and monitoring agent-stage performance and failures.

I Built DukaanFlow AI: Turning Customer Chats into Review Ready Orders

Harshit Raut — Sun, 18 Oct 2026 15:21:26 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

DukaanFlow AI is an AI-powered order management assistant built for small business owners, boutique owners, and independent sellers who manage customer orders through chat messages. It uses Gemma to extract order details from informal customer messages, validates product variants and prices, calculates revenue, costs, profit, and margins, and stores orders for review. It also integrates ElevenLabs to generate customer reply voice notes. The goal is to reduce manual data entry, avoid order-processing mistakes, and help small businesses manage orders more efficiently without needing complicated enterprise software.

Demo

dukaanflow-php5.onrender.com

Code

Harshit10-LM / DukaanFlow

AI-powered order management assistant with Gemma, financial calculations, and ElevenLabs voice notes.

DukaanFlow AI

Turn messy conversational customer messages into fulfilment-ready orders with clear financial intelligence.

DukaanFlow AI is an AI-powered order management application for home businesses, boutique fashion labels, and independent merchants who receive customer orders through informal messaging channels such as WhatsApp, Instagram DMs, and chat apps.

Instead of manual spreadsheet entry or unreliable generative math, DukaanFlow AI pairs open-weight Gemma extraction with seller-governed, deterministic Decimal accounting, MongoDB Atlas persistence, and ElevenLabs voice generation.

The Business Problem

Millions of independent Indian merchants sell through direct messaging. A typical customer order arrives like this:

"Hi, I need two navy kurtis, one medium and one large. The price is ₹650 each, right? Can you deliver by Friday? I'll pay half now and the rest on delivery."

Traditional solutions fail these sellers:

Generic Spreadsheets: Require manual copy-pasting, error-prone manual calculations, and separate invoicing.
Autonomous AI Chatbots: Hallucinate discounts, confirm…

View on GitHub

How I Built It

I built DukaanFlow AI using Google's Gemma model, an open-weight AI model accessed through an API rather than running locally. I integrated it into a Python Flask application to convert unstructured customer messages into structured order details, including product names, variants, quantities, delivery requirements, and payment terms.

The application validates extracted information against the product catalogue, while Python's Decimal arithmetic handles financial calculations such as revenue, costs, profit, and margins. MongoDB Atlas stores order and business data, and ElevenLabs provides text-to-speech generation for customer reply voice notes.

The main design principle was to use AI for understanding natural language while keeping financial calculations, validation, order persistence, and business rules in deterministic application code. I also used pytest to test core functionality and deployed the application on Render.

Why Does Open Innovation Matter?

Open innovation mattered because I wanted to build an AI tool that small businesses could adapt without depending entirely on a single proprietary AI provider. Using Gemma gave me access to an open-weight model and the flexibility to explore different deployment options as the project grows. It also helped me build around an open-source Python and Flask stack, making the application easier for other developers to inspect, extend, and contribute to under the MIT License. Although my current version accesses Gemma through an API, the open-weight ecosystem gives the project more flexibility for future customization and self-hosting. This approach encourages collaboration, reduces dependence on a single vendor, and makes it easier to adapt AI technology to the practical needs of small businesses.

Prize Categories

Best Use of Gemma — Gemma powers AI-based customer message understanding and order extraction.
Best Use of Render — DukaanFlow AI is deployed as a live web application on Render.
Best Use of ElevenLabs — ElevenLabs generates customer reply voice notes.
Best Use of MongoDB Atlas — MongoDB Atlas provides persistent storage for application data and orders.

GrassQuest : An Open-Weight AI That Gets You Outside, Not Scrolling

Harshit Raut — Sat, 10 Oct 2026 13:13:00 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

I built GrassQuest 🌿, an app that gives you a reason to step away from your screen and do something outside.

The idea came from a simple thought: we use AI for so many things on our phones, but what if we used it to help us spend less time on them?

With GrassQuest, you choose your mood, how much time you have, and the kind of activity you want to try. The AI generates an outdoor quest based on your choices. It could be exploring a new route, noticing things around your neighbourhood, or going on a small nature hunt.

It also has ElevenLabs voice guidance, GPS-based distance tracking, and a completion screen to wrap up the quest.

The part I like most is that once you start a quest, you're encouraged to put your phone away and actually do it.

Demo

grassquest-5mfr.onrender.com

Code

Harshit10-LM / GrassQuest

GrassQuest 🌿

“AI that gives you a mission, then gets out of your way.”

📌 Project Overview

Modern AI products are almost universally designed to maximize engagement: chat boxes that lure you into infinite conversation, recommendation algorithms that keep your eyes glued to glass, and synthetic companions that replace outdoor living.

GrassQuest is the antithesis of the screen-addiction trap.

Instead of keeping you talking to an AI on your phone or laptop, GrassQuest uses an open-weight AI model (GPT-OSS 20B) to synthesize your current emotional state, time availability, and physical environment into a realistic, playful outdoor mission. Once your mission is generated, ElevenLabs speaks a concise starting instruction into your ears:

“Your GrassQuest has started. You have 20 minutes. Walk outside and find three things you normally overlook. Put your phone in your pocket and start walking.”

…

View on GitHub

How I Built It

I used GPT-OSS 20B through Groq to generate quests based on the user's mood, available time, and activity preference.

The app is built with Flask on the backend and HTML, CSS, and vanilla JavaScript on the frontend. I used ElevenLabs for voice instructions and the browser's Geolocation API to track walking distance. The Haversine formula calculates the distance between GPS coordinates.

I deployed the app on Render. I kept the stack relatively simple because I wanted to focus on making the actual experience work rather than adding unnecessary complexity.

The AI returns structured quest data, which the backend validates before sending it to the frontend. I also added fallback handling for cases where voice generation or location access isn't available.

Why Does Open Innovation Matter?

For this project, I wanted to experiment with an open-weight model rather than build everything around a closed model.

GPT-OSS 20B gives me the flexibility to work with the model's prompts, shape its output, and explore different models as the project develops. Using Groq for inference also meant I could build the app without needing to run the model on my own laptop or server.

What matters to me is that the AI is being used for something beyond generating answers on a screen. It creates a small mission that someone can actually go out and complete.

GrassQuest is still a small project, but I'd like to explore how open-weight AI can be used to encourage more real-world experiences instead of more screen time.

My Agent Session

I built GrassQuest with Antigravity and Gemini. I haven't included a saved DevRelay agent session link for this build.

Prize Categories

Best Use of Render
Best Use of ElevenLabs

Team Submissions: @rozoa @akash_70 @sycojoker

VivaBuddy: The AI Viva Partner

Harshit Raut — Sun, 04 Oct 2026 18:14:02 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built VivaBuddy, an AI-powered viva practice partner for a friend who often needs someone to practice oral-exam questions with but doesn't always have someone available.

VivaBuddy lets a student enter a subject, topics, difficulty level, and number of questions, then conducts an interactive viva session. It generates questions, evaluates the student's answers, provides a score and feedback, explains what could be improved, and can simplify difficult concepts with "Explain Like I'm a Beginner."

I built it to solve a simple but common problem: having no one available to quiz you before an important viva. Instead of waiting for a friend or classmate, the student can practice whenever they need and get immediate feedback from an AI partner.

I intentionally kept VivaBuddy focused on one problem rather than turning it into a large AI platform.

Demo

vivabuddy.onrender.com

Code

Harshit10-LM / VivaBuddy

An open-weight AI viva practice partner built for a friend.

VivaBuddy

VivaBuddy is a small, AI-powered viva practice partner built for a friend who needed a patient way to rehearse oral-exam questions when another person was not available.

The Problem

Preparing for a viva is difficult to do alone. A friend, classmate, or teacher may not be available to ask questions, listen to answers, and give useful feedback at the moment a student needs practice.

The Solution

VivaBuddy turns a syllabus into a focused practice session:

Setup → AI question → student answer → AI evaluation → beginner explanation
      → next question → final score

Choose a subject, topics, difficulty, and question count. VivaBuddy asks realistic questions, evaluates each answer, explains confusing ideas simply, and summarizes the session at the end.

Features

AI-generated viva questions that avoid exact repeats
Answer scores out of 10 with strengths, improvements, and a better answer
A short “Explain Like I’m a Beginner” follow-up
Gentle…

View on GitHub

How I Built It

VivaBuddy is built around the open-weight openai/gpt-oss-20b model, using Groq for inference. I chose an open-weight model because AI is the core of the project rather than just an additional chatbot feature. The model generates viva questions based on the subject, topics, and difficulty, evaluates student answers with a score and detailed feedback, and provides simple beginner-friendly explanations when the student gets stuck.

The project uses Python and Flask for the backend and HTML, CSS, and Vanilla JavaScript for the frontend. All AI requests are handled through the Flask backend, so the Groq API key is never exposed to the browser. I also made the model configurable through an environment variable, making it possible to experiment with different compatible models without rebuilding the whole application. The project was built and tested with Codex and deployed on Render.

Why Does Open Innovation Matter?

Open innovation matters to VivaBuddy because I wanted the AI to be more than a fixed service hidden behind a closed API. I used the open-weight openai/gpt-oss-20b model through Groq, which gives the project more flexibility to experiment with the underlying model and change the inference setup in the future.

With an open-weight model, the same application can potentially be adapted for different inference environments, including self-hosted or local inference, without redesigning the entire product around a proprietary model. It also reduces dependence on a single closed AI provider and gives developers more freedom to experiment with how the model is used.

For VivaBuddy, this is especially useful because question generation, answer evaluation, and explanations could all be improved or customized by testing different models over time. The current deployed version uses Groq for inference, but the model itself remains configurable, keeping the application flexible rather than permanently tied to one proprietary AI system.

My Agent Session

I used Codex to build, test, debug, and deploy VivaBuddy in phases, from the initial Flask app to the live Render deployment.

Prize Categories

Best Use of Render: VivaBuddy is deployed and hosted on Render as a live Flask web application. Render handles the production web service and serves the complete AI viva experience to users, making the project publicly accessible through a live URL.