DEV Community: Shubham Nayak

👻 Meet GhostShell — a spooky AI-powered terminal assistant!

Shubham Nayak — Wed, 28 Oct 2026 14:41:17 +0000

What I Built

👻 Meet GhostShell — a spooky AI-powered terminal assistant!

What if your terminal had a ghost living inside it?

GhostShell is a Halloween-inspired project that explores how open-source AI can bring a little mystery to the developer experience. It is designed to interpret terminal commands, explain what they do, and generate eerie commentary and spooky stories through an AI-powered terminal interface.

Inspired by the Ghost in the Machine theme, I wanted to combine my interest in software development, local AI, and the spooky atmosphere of Halloween into one project.

The goal is to make interacting with a terminal feel a little more alive — without sacrificing developer control.

Demo

🎬 Live demo: [Add your demo link here]

A terminal recording or GIF showing GhostShell responding to a command would be a great way to experience the project.

Code

💻 GitHub Repository: [Add your repository link here]

The project source code, setup instructions, and implementation details will be available in the repository.

How I Built It

The planned technology stack for GhostShell includes:

Python — to build the terminal application and connect its components.
Ollama — to run an open-weight language model locally.
Qwen2.5 3B — a lightweight model candidate for generating responses and spooky commentary.
Rich — to create a colorful, interactive terminal experience.
Git and GitHub — for version control and open-source collaboration.

The central idea is to keep AI inference local rather than depending entirely on a hosted AI API.

The model choice and performance will be validated during implementation, with an emphasis on keeping the application practical for a developer's laptop.

Why Does Open Innovation Matter?

Open innovation is important because developers should have the freedom to understand, adapt, and control the tools they build with.

For GhostShell, local inference offers several potential advantages:

Privacy: Prompts can stay on the local machine instead of being sent to a third-party AI service.
Offline capability: Once the model is downloaded, inference can work without an internet connection.
Flexibility: Developers can experiment with different compatible models and customize the assistant's behavior.
Accessibility: Local models can reduce dependence on paid API usage, although hardware, electricity, and setup still have costs.
Community-driven development: An open-source project gives other developers the opportunity to inspect, improve, and extend the code.

A closed API can be convenient, but a local, open-weight approach gives developers more control over where inference happens and which model powers their application.

That freedom is what makes open-source AI exciting to me.

My Agent Session

🤖 DevRelay session: [Add your session link here, if available]

I'll share the development session here to help others understand the implementation process and the decisions behind the project.

Remove this section if no session is available.

The Spirit of It

Halloween is the perfect time to imagine something unexpected hiding inside an ordinary developer tool.

With GhostShell, the terminal becomes a place where commands meet a little mystery. The ghost is fictional, the AI is real, and the code is open for others to explore.

Beyond the spooky theme, this project represents something I value as a developer: the ability to experiment, learn, and build without being locked into a single platform.

Sometimes, the most interesting thing in the machine is what we choose to build together. 👻💻

Prize Categories

I'll select the applicable partner categories after verifying the project's eligibility against the official challenge rules.

Built with curiosity, open-source AI, and a little Halloween spirit. 🎃

SlothChef: A Local AI Vision Agent That Turns Your Fridge Into a Meal

Shubham Nayak — Wed, 21 Oct 2026 06:03:14 +0000

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

What I Built

I built SlothChef, a local, zero-effort vision agent for anyone who stares blankly into their refrigerator hoping a meal will magically assemble itself.

Instead of manually typing ingredients, scrolling through endless recipe pages, or standing in front of the fridge trying to decide what to cook, SlothChef does the thinking locally:

Snap & Forget: Take a single photo of an open fridge or pantry.
Detect & Decide: SlothChef identifies visible ingredients and uses a local language model to reason about them.
Lazy Meal: It generates a quick, low-effort recipe designed around minimal cooking and minimal cleanup.
Use What You Have: The workflow prioritizes ingredients already available instead of requiring a shopping trip.

The goal is simple: reduce decision fatigue and turn "I don't know what to cook" into an actual meal.

Demo

Here is an example CLI trace of SlothChef processing a smartphone photo:

[SlothChef Intake Monitor Active]

[07:15:22 PM] Image Detected: "fridge_shelf_evening.jpg"
   ↳ Analyzing via SmolVLM-Instruct...
   ↳ Detected items: Eggs (3), half a block of cheddar,
     wilted spinach, corn tortillas, jar of salsa.

   ↳ Querying Qwen2.5-Coder-3B for lazy culinary logic...

[Recipe Generated: 10-Minute Lazy Skillet Migas]

- Effort Level: Low
- Dishes Used: 1 skillet
- Ingredients: Corn tortillas, 3 eggs, spinach,
  cheddar, salsa

- Instructions:
  1. Tear tortillas into the pan with a little oil.
  2. Add the eggs and spinach, then scramble.
  3. Turn off the heat, add cheese and salsa, and eat.

Code

The core Python workflow connects a local vision model with a local language model through Ollama:

import json
import ollama
from pathlib import Path


def analyze_fridge_image(image_path: Path) -> str:
    """Identify edible ingredients visible in a fridge image."""
    response = ollama.chat(
        model="smolvlm",
        messages=[
            {
                "role": "user",
                "content": (
                    "List only the edible ingredients, produce, "
                    "and condiments visible in this fridge photo "
                    "as comma-separated items."
                ),
                "images": [str(image_path)]
            }
        ]
    )

    return response["message"]["content"]


def generate_lazy_recipe(ingredients_list: str) -> dict:
    """Generate a minimal-effort recipe using local AI."""

    system_prompt = """
    You are SlothChef.

    The user is tired and wants to cook with minimal effort
    and as few dishes as possible.

    Based on the available ingredients:
    1. Pick 3-5 compatible ingredients.
    2. Prefer one-pan or one-pot meals.
    3. Keep preparation simple.
    4. Return valid JSON only.

    Format:
    {
        "recipe_name": "...",
        "prep_time_minutes": 10,
        "dishes_used": 1,
        "steps": ["...", "..."]
    }
    """

    response = ollama.chat(
        model="qwen2.5:3b",
        messages=[
            {"role": "system", "content": system_prompt},
            {
                "role": "user",
                "content": f"Available items: {ingredients_list}"
            }
        ],
        format="json"
    )

    return json.loads(response["message"]["content"])


if __name__ == "__main__":
    photo = Path("fridge_shelf_evening.jpg")

    if photo.exists():
        print("Inspecting fridge contents locally...")

        detected_items = analyze_fridge_image(photo)
        print(f"Found: {detected_items}")

        print("Designing low-effort dinner...")

        recipe = generate_lazy_recipe(detected_items)

        print(
            f"\nMeal: {recipe['recipe_name']} "
            f"({recipe['prep_time_minutes']} mins, "
            f"{recipe['dishes_used']} pan)"
        )

        for i, step in enumerate(recipe["steps"], 1):
            print(f"{i}. {step}")

How I Built It

SlothChef uses modular open-source AI components running locally:

Vision: SmolVLM through Ollama for extracting ingredients from fridge/pantry images.
Language Model: Qwen2.5-3B-Instruct for turning detected ingredients into a structured recipe.
Workflow: A simple local Python interface that accepts an image, runs vision analysis, passes the detected ingredients to the language model, and prints the resulting meal.
Output: Structured JSON containing the recipe name, preparation time, number of dishes, and cooking steps.

The important part is that the AI pipeline does not require a cloud API.

Why Open Innovation Matters

Open-weight models make small personal AI utilities practical without requiring every interaction to go through a commercial API.

1. Privacy

A fridge photo can reveal a surprising amount about someone's home and lifestyle. Local inference means the image can stay on the user's machine instead of being uploaded to a remote service.

2. Offline Independence

The application can continue working without an internet connection once the required models are available locally.

3. No Per-Request API Cost

There is no per-meal API charge. Users can experiment with the workflow as often as they want using their own hardware.

4. Developer Control

Running open models locally gives developers control over prompts, output formats, model selection, and inference configuration.

This makes it possible to build small, focused AI agents around very specific everyday problems.

My Agent Session

[DevRelay Session: slothchef-local-vlm-trace]

The Lazy Payoff

SlothChef is intentionally simple.

The problem isn't that people don't know how to cook. Sometimes the problem is simply not wanting to decide what to cook.

One photo of the fridge can become a concrete meal suggestion without typing ingredients, searching recipe websites, or opening another delivery app.

Less thinking. Less scrolling. Less cleanup. More eating.

That's the idea behind SlothChef.

FreelanceFlow AI: A Privacy-Friendly Business Assistant Powered by Open-Source AI

Shubham Nayak — Thu, 15 Oct 2026 13:43:36 +0000

title: "FreelanceFlow AI: A Privacy-Friendly Business Assistant Powered by Open-Source AI"
published: false
tags: devchallenge, hf26challenge, opensource, ai

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

What I Built

Meet FreelanceFlow AI — an AI-powered business assistant designed to help freelancers and small business owners save time on repetitive tasks.

Freelancers often spend hours writing client proposals, creating invoice descriptions, drafting professional emails, and organizing project information. These tasks may seem small, but they take valuable time away from actual work.

FreelanceFlow AI aims to simplify this workflow by helping users:

Generate professional client proposals from a short project description.
Draft client emails and follow-up messages.
Create clear service descriptions for invoices.
Turn rough notes into organized project summaries.
Customize AI-generated content for different clients and business needs.

The idea is simple: give independent professionals a practical AI assistant that helps them work smarter without depending entirely on expensive AI APIs.

The potential customers are freelancers, students offering services, solo developers, and small businesses.

Demo

Live Demo: [Add your deployed demo link here]

Demo Video: [Add your demo video link here, if available]

Code

GitHub Repository: [Add your public GitHub repository link here]

The project source code will document the application architecture, setup instructions, and how to run the AI component.

How I Built It

I am building this project using my experience with full-stack development and exploring how open-source AI can power a practical, user-focused product.

Planned technology stack:

Frontend: React.js
Backend: Node.js and Express.js
Database: MongoDB
AI engine: An open-weight language model such as Qwen or Llama, subject to model compatibility and licensing.
Model runtime: Ollama for local inference.
Development workflow: GitHub and DevRelay.

The application will accept a user's task, prepare a structured prompt, and use the selected language model to generate useful business content.

The goal is to keep the AI component replaceable, allowing the project to experiment with different open-weight models without rebuilding the entire application.

Local inference will be an important option for users who prefer to process their information on their own machine. Hardware requirements and model performance will depend on the selected model.

Why Does Open Innovation Matter?

Open innovation is central to the idea behind FreelanceFlow AI.

1. More control over costs

Relying entirely on paid AI APIs can make a small side project expensive as usage grows. Running a compatible open-weight model locally can reduce per-request API costs, although hardware and hosting still have costs.

2. More control over private information

Client proposals, business notes, and project details can contain confidential information. Local inference can help keep this information on the user's machine rather than sending it to an external AI provider.

3. Freedom to experiment

Different language models have different strengths. An open-weight approach makes it possible to compare models, customize prompts, and choose a suitable model for the task.

4. Less vendor lock-in

The application can be designed around a replaceable AI layer rather than depending on one provider's proprietary API.

5. A realistic path to a side hustle

A focused tool for freelancers can start with a small feature set and grow based on real feedback. A free or low-cost local option could make it useful even for people who cannot justify another monthly subscription.

Open-source AI is not automatically better at every task. The real advantage is the flexibility to choose the right model, deployment method, and cost structure for the users' needs.

My Agent Session

I use AI-assisted development tools to explore implementation ideas, debug code, and improve the development workflow.

DevRelay Session: [Add your saved DevRelay agent session link here]

My First User

The first milestone is to get the tool into the hands of a freelancer or a small business owner and observe how they use it.

I want to learn which repetitive task consumes the most time, whether the generated content is genuinely useful, and whether the user would pay for a more capable version.

I will update this section with real feedback and testing results after the first user trial.

Prize Categories

Hacktoberfest Open-Source AI Challenge — Week 2: Side Hustle

What's Next?

My next steps are to implement the core workflow, test an open-weight model, publish the code, and collect feedback from potential users.

I'd love to hear from other developers: What repetitive task would you automate first if you could run your own AI model without depending on a paid API?

Let's build useful things with open-source AI! 🚀

FrostSprout: I Built a Local AI Garden Assistant That Gets You Outside, Not Staring at a Dashboard

Shubham Nayak — Sun, 11 Oct 2026 10:59:58 +0000

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

The Problem: Your Garden Doesn't Need Another Dashboard

Imagine waking up on a cold autumn morning. The forecast says it might freeze overnight. You have spinach, garlic, carrots, and other crops growing outside.

You have three questions:

Will frost threaten my garden tonight?
Which plants need attention first?
What should I physically do when I step outside?

A weather app gives you numbers. A gardening website gives you generic advice. An AI chatbot gives you another conversation to read.

I wanted to build something different: an AI assistant that tells you what to do, then gets out of your way.

Meet FrostSprout, an open-source, hyperlocal garden planning assistant built around one simple principle: the screen should be the shortest part of the experience.

What I Built

FrostSprout combines local AI, tabular machine learning, live weather data, and hands-free audio to turn microclimate conditions into a practical three-step garden action plan.

Instead of stopping at “There is a chance of frost,” it aims to answer: “Here is what you should check and protect before tonight.”

The default location is Panipat, Haryana, India, and the application supports ten cold-hardy autumn crops, with planting-depth guidance and practical outdoor observations.

1. From Weather Data to Actionable Decisions

FrostSprout collects available environmental features, including elevation, forecast temperatures, humidity, and cloud cover. It combines them with explicitly identified defaults for unavailable soil temperature, pressure, and rolling-temperature history.

The prediction layer estimates frost risk and produces inputs for the garden guide. The interface distinguishes real weather observations from hypothetical scenarios.

2. An AI Guide You Can Listen to Outside

The local Gemma model transforms numerical predictions into a concise, three-step task list.

Using the browser's native Web Speech API, FrostSprout reads the instructions aloud. You can listen while walking around your garden, checking leaves, touching the soil, and protecting vulnerable plants.

No external speech API is required.

3. A Printable Garden Field Card

Sometimes the best interface is paper.

FrostSprout includes print-specific styling that formats the plan into a compact field card. Print it, take it outside, and follow the steps without repeatedly unlocking your phone.

4. What-If Frost Scenarios

Want to explore what might happen if the temperature drops to 2°C?

The simulated mode lets you experiment with hypothetical conditions and observe how the application responds. It is explicitly labelled as simulated, so hypothetical weather is not confused with live observations.

5. An Outdoor Activity Log

A simple garden log records time spent outside and soil observations.

The goal isn't to maximise screen time or build another engagement dashboard. It is to encourage people to observe their environment and learn from their own garden.

Demo

Live demo: A public deployment is not currently linked. Run FrostSprout locally to explore its features.

The application includes live Open-Meteo weather, simulated frost scenarios, an audio walkthrough, printable field cards, and an outdoor log.

Code

GitHub repository: Shubham-cyber-prog/FrostSprout

Run it locally:

git clone https://github.com/Shubham-cyber-prog/FrostSprout.git
cd FrostSprout
pip install -r requirements.txt
python run.py

Open http://localhost:8000.

To reproduce the benchmark:

python backend/benchmark.py

The benchmark uses seed 42.

How I Built It

FrostSprout uses a deliberately lightweight architecture:

Backend: FastAPI
Frontend: Vanilla HTML, CSS, and JavaScript
Tabular ML: TabPFN with a scikit-learn Random Forest fallback
Local language model: Gemma 3 through Ollama
Weather: Open-Meteo
Audio: Browser-native Web Speech API

No API keys are required for the application's documented local workflow, although downloading model weights or obtaining model access may require additional setup.

The Architecture

The application follows a simple pipeline:

Weather and microclimate features → Frost-risk prediction → AI-generated garden guide → Audio and printable field card → Outdoor action

Each component has a defined responsibility.

The prediction layer handles numerical inputs. The language model turns the resulting metrics into understandable instructions. The interface then makes those instructions usable away from the screen.

This separation also makes it easier to replace individual components without redesigning the entire application.

TabPFN: The Prediction Layer

I integrated Prior Labs' TabPFN through backend/tabpfn_engine.py for tabular prediction tasks.

When the required model weights and authentication are unavailable, the application falls back to a scikit-learn RandomForestClassifier.

Importantly, the active model is reported rather than silently substituted. A fallback is a fallback, not a successful TabPFN run.

Verification status: TabPFN is not verified in my environment because model access failed with TabPFNLicenseError. I therefore do not claim that the TabPFN integration has been successfully benchmarked.

Gemma 3: Turning Predictions into Practical Advice

The language-model integration lives in backend/gemma_engine.py.

Gemma 3 runs locally through Ollama and converts numerical predictions into a three-step outdoor action guide, sensory observations, and companion-planting notes.

The application identifies the response source as gemma3 via Ollama when that path is used. If Ollama is unavailable, a deterministic template provides a fallback and reports offline template.

This is important because an application should not pretend that a language model generated a response when it actually used a predefined template.

Live Weather Without an API Key

Open-Meteo supplies the available live weather data.

However, not every feature is a live observation. Soil temperature, atmospheric pressure, and the seven-day rolling minimum currently use documented defaults.

These limitations matter: real weather inputs do not automatically make every prediction scientifically validated.

FrostSprout is an experimental garden assistant, not a certified agricultural forecasting system. Its risk estimates should be treated as decision support rather than a guarantee that frost will or will not occur.

Benchmark Results: What the Numbers Actually Mean

I benchmarked the prediction models using 800 synthetic samples, with a 75/25 train-test split.

Model	ROC-AUC
Random Forest	0.9987
XGBoost	0.9986
TabPFN	Not verified

These numbers look impressive, but there is an important caveat.

The synthetic labels are generated using the same underlying formula that creates the dataset. Consequently, the models can learn that formula and achieve near-perfect scores without demonstrating equivalent accuracy on real-world weather observations.

I report these results as a reproducible synthetic-data benchmark, not evidence of 99.87% real-world frost prediction accuracy.

The next meaningful evaluation step is testing against independently collected weather-station observations and verified frost outcomes.

Why Open Innovation Matters

Open-source AI isn't just a technology choice for FrostSprout. It determines who can run it, inspect it, and adapt it.

Privacy and Local Inference

Gemma 3 runs on the gardener's own machine through Ollama. The garden-guide generation step does not need a hosted language-model API.

This reduces dependence on external AI services, avoids per-request model API charges, and allows the core language-model workflow to run locally once the model is installed.

The application still retrieves weather from Open-Meteo, so the complete workflow is not fully offline.

Freedom to Inspect and Replace Components

The prediction engine, language model, prompts, crop guidance, and fallback logic can be inspected and modified.

Gardeners and developers can adapt the application to local crops, replace models, and eventually train against regional weather-station data.

Graceful Degradation

Local model inference is not always available. Hardware may be limited, weights may be inaccessible, and a service may fail.

FrostSprout is designed to expose these limitations and fall back to deterministic guidance rather than making unsupported claims about which model answered.

Transparency Over Artificial Confidence

Open tooling also made it possible to expose a limitation that would otherwise be easy to hide: my TabPFN integration remains unverified, and my current benchmark is based on synthetic data.

For a project that influences physical decisions, being clear about uncertainty is more valuable than presenting impressive numbers without context.

What I Learned

Building FrostSprout reinforced three lessons.

First, AI is most useful when it changes an action. A prediction is only the beginning. The real challenge is converting it into a decision someone can understand and carry out.

Second, graceful fallbacks are part of product design. A local model that sometimes fails needs an honest, useful alternative.

Third, reproducibility and honesty belong in the same README. Benchmarks should explain their dataset, assumptions, limitations, and verification status—not just display a score.

What's Next?

The next steps are to:

Validate predictions against real weather-station data.
Verify TabPFN inference in a supported environment.
Improve regional crop guidance and document its sources.
Add more robust historical observations and uncertainty reporting.
Test the complete audio-first workflow outdoors with real gardeners.

I also want to test FrostSprout during an actual cold night, document what worked, and improve the field guide using those observations.

My Agent Session

Optional: Add a DevRelay agent-session link here.

Prize Categories

Best Use of TabPFN — Prior Labs: Tabular prediction integration with an explicitly reported Random Forest fallback. TabPFN execution remains unverified.
Best Use of Gemma — Google: Local Gemma 3 inference through Ollama for generating the outdoor action guide.

Final Thoughts

The best AI experience isn't necessarily the one that keeps you chatting for another ten minutes.

Sometimes it is the one that checks the weather, gives you three useful instructions, reads them aloud, and lets you close your laptop.

FrostSprout is my attempt to build that kind of experience.

Less scrolling. More soil under your fingernails. More time outside.

If you garden in a different climate, I'd love to hear what crops, frost conditions, or local observations you'd want FrostSprout to support.

Thanks for reading!

I Built a Local AI Gym Log for a Friend Who Always Forgot His Weights

Shubham Nayak — Sun, 04 Oct 2026 11:28:04 +0000

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

What I Built

Gym Log Buddy — A Local AI Workout Logger Built for a Friend

My friend goes to the gym regularly, but he has one surprisingly annoying problem:

He forgets what weight he lifted last time.

He doesn't want a complicated fitness app with endless menus and forms. During a workout, he just wants to quickly write something like:

bench 60kg 8 reps 3 sets, incline db 22 x 10 x 3, squat 80 5x5

So I built Gym Log Buddy around the way he already takes notes.

Instead of forcing him to structure his workout, the app lets him write naturally. A local Gemma 3 model running through Ollama converts the messy note into structured workout data:

Exercise
Weight
Reps
Sets

Before anything is saved, the extracted data is shown in a review table so my friend can verify and correct it.

The confirmed workout is then stored locally in SQLite.

On the next session, Gym Log Buddy can show what he did previously and suggest a target for his next workout.

AI where it helps. Deterministic code where it doesn't.

I deliberately didn't use AI for everything.

Gemma 3 handles the part that requires language understanding: turning messy human text into structured data.

The progressive-overload calculation is plain Python:

If the previous workout reached 10+ reps, increase the weight by 2.5 kg and target 8 reps.
Otherwise, keep the weight and target one additional rep.

This keeps the predictable part of the application deterministic, testable, and easy to understand.

And the most important feedback?

"Bahut accha hai, keep it up."

My friend said it was very good and encouraged me to keep going.

That's the user requirement that mattered most.

Demo

Gym Log Buddy is intentionally a local application, not a hosted AI service.

It runs on the laptop with Ollama and Gemma 3 installed.

🎥 Video Demo

The demo shows the local Streamlit application processing workout notes and turning them into structured workout data.

Code

The complete project is open source on GitHub:

Shubham-cyber-prog / Gym-Log-Buddy

Local-first gym log: Gemma 3 (via Ollama) turns messy workout notes into structured data.

Gym Log Buddy

Gym Log Buddy is a local-first workout tracking application that extracts structured exercises, weights, reps, and sets from natural language workout notes It is built for a gym buddy who wants quick, friction-free workout logging without manual forms, accounts, or subscriptions It runs entirely on your local machine using an open-source language model (Gemma 3 via Ollama) for text extraction, deterministic Python rules for progressive overload recommendations, and SQLite for storage.

Features

Plain English input: Type workout notes naturally (e.g. "bench 60kg 8 reps 3 sets, incline db 22 x 10 x 3, squat 80 5x5").
Local open-source model: Uses Gemma 3 via Ollama. No cloud APIs, no API keys, and no paid services.
Deterministic progressive overload
- If last reps >= 10: suggest +2.5 kg and 8 reps
- Otherwise: suggest same weight and +1 rep
Dual interfaces
- CLI (cli.py): log, last, suggest, history commands.
- Streamlit UI (app.py)…

View on GitHub

Tech Stack

Python
Gemma 3
Ollama
SQLite
Streamlit
Requests

The model name is kept as a single configuration constant, making it straightforward to experiment with other local models.

How I Built It

The architecture is intentionally simple:

Messy workout note
        ↓
   Gemma 3 / Ollama
        ↓
 Structured JSON
        ↓
 Validation & safeguards
        ↓
 Review / confirmation
        ↓
      SQLite
        ↓
 Workout history
        ↓
 Progressive overload target

The entire AI inference pipeline runs locally.

No workout note needs to be sent to a cloud AI provider.

Why Gemma 3?

The core problem isn't mathematical.

It's language understanding.

A person can write:

bench 60 8x3

or:

did bench today, 60kg, 8 reps x 3

or:

bench 60kg 8 reps 3 sets

A useful workout logger needs to understand that these are describing the same kind of information.

Gemma 3 provides the natural-language understanding needed to turn those messy inputs into a structured representation.

Python then takes over for everything deterministic.

I Tested the Real Model — Including Its Failures

One of the most important parts of this project was not hiding model failures.

Failure #1 — 60 Became 27.2 kg

Input:

bench 60 8x3

Gemma initially interpreted 60 as pounds and converted it to:

{
  "exercise": "Bench Press",
  "weight_kg": 27.2,
  "reps": 8,
  "sets": 3
}

The dangerous part was that the output looked completely valid.

There was no exception.

No malformed JSON.

Just the wrong workout.

I fixed this by making kilograms the explicit default and allowing conversion only when the input explicitly contains lb, lbs, or pounds.

Failure #2 — The Model Invented an Exercise

Input:

did legs today, felt good

The model invented a Squat with null values.

The input contained no exercise.

I added a prompt rule requiring an empty exercise list for non-workout commentary, along with a programmatic validation rule that removes records where weight, reps, and sets are all null.

Failure #3 — My Schema Couldn't Represent `8,8,6`

Input:

bb row 70 8,8,6

The model repeatedly interpreted this incorrectly because my schema only supports one reps value per exercise.

The actual workout has different repetitions across sets:

8 reps
8 reps
6 reps

Instead of manipulating the benchmark to make the result look better, I kept the failure and documented it as a schema limitation.

This also reinforced why the application has an explicit confirmation step.

The AI can suggest. The user confirms.

Then I Found Benchmark Leakage

At one point, the benchmark reached:

18/18 — 100%

That looked great.

It was also invalid.

I had accidentally included exact test inputs as few-shot examples in the prompt.

After removing those examples, I discovered a second leakage issue: parts of the same test inputs were still present in the prompt's rules section.

I removed those as well and added an automated test that checks for test-input leakage.

The final evaluation was split honestly:

Held-out inputs: 15/18 = 83.3%
Original inputs: 18/18, but not counted as evidence because the prompt had been developed around them
36 total live model inferences

I am deliberately not presenting 91.7% as a general AI accuracy number.

The benchmark is small and project-specific.

The important result for me was that the evaluation became cleaner and more trustworthy.

Testing Beyond the Model

I also discovered a bug that the original test suite completely missed.

The parser and database tests were passing, but the Streamlit application could crash on a fresh database with:

NameError: name 'selected_chart_ex' is not defined

The problem was that my original tests never actually executed the Streamlit application.

So I added Streamlit's AppTest framework and created tests for:

Empty database rendering
Workout history rendering
Chart rendering
Exercise-name normalization

The project now has 20 automated pytest tests.

The parser tests use a mocked model, while the actual Gemma 3 evaluation lives separately in:

tests/live_check.py

This distinction matters because mocked tests verify application behavior, while live tests verify the behavior of the actual local model.

Running Gemma 3 Without a Dedicated GPU

I ran the project on a laptop with:

Intel Iris Xe integrated graphics
16 GB RAM
Windows 11
No dedicated GPU

The final live evaluation averaged approximately:

17.9 seconds for first-run inference.

Repeated runs averaged around:

9.5 seconds.

I didn't perform controlled hardware benchmarking, so these should be considered practical observations rather than formal performance claims.

It's perfectly acceptable for logging a workout after training.

It would not be ideal for real-time interaction between sets.

And that's an important trade-off to acknowledge.

Why Does Open Innovation Matter?

For this project, open innovation wasn't just about using an open model because it was interesting.

It changed what I could build.

🔒 Privacy

Workout history is personal data.

With local inference, the workout notes stay on the user's machine instead of being sent to a third-party AI API.

There is:

No cloud AI endpoint
No API key
No per-request AI cost

🌐 Offline Capability

Once Gemma 3 is downloaded, the core parsing workflow can run without an internet connection.

That's particularly useful for gyms where mobile connectivity can be unreliable.

💰 Zero Ongoing AI Cost

A hosted AI API would introduce usage costs and external dependencies.

Running Gemma 3 locally means the model can be used without paying for every workout entry.

🔧 Model Freedom

The application isn't locked to one proprietary AI provider.

The model is configurable, so I can experiment with different open models as they improve.

🧪 Inspectability

Because the inference pipeline runs locally, I can inspect the prompt, model output, validation logic, and evaluation process myself.

I can test failures instead of simply trusting an API response.

The honest trade-off

A larger hosted model would probably be faster and more accurate.

Gemma 3 running locally on my hardware isn't.

I chose:

Privacy + offline capability + zero per-request cost

over:

Maximum speed + maximum model accuracy

The confirmation workflow is how I make that trade-off practical.

One Important Privacy Caveat

I also discovered something important while writing the project documentation.

My project directory is currently inside OneDrive.

That means the SQLite database can potentially be synchronized by OneDrive.

So "local AI" does not automatically mean "private forever."

For the database to remain truly local, the project/database should be stored outside cloud-synchronized folders.

I documented this limitation rather than hiding it.

My Agent Session

I built Gym Log Buddy using Google Antigravity as the coding agent.

The agent helped with implementation and refactoring, while I reviewed the generated code, ran the tests, evaluated the real model, and investigated failures.

A second AI assistant was also used as a reviewer.

That review process helped uncover two particularly important issues:

Benchmark contamination / prompt leakage
The Streamlit NameError that the original tests couldn't detect

The goal wasn't to blindly accept generated code.

It was to use the agent to accelerate development while still treating testing, evaluation, and review as engineering responsibilities.

Prize Categories

🏆 Best Use of Gemma

Gemma 3 is the core AI component of Gym Log Buddy.

It runs locally through Ollama and converts unstructured workout notes into structured workout data.

The project demonstrates a practical use of an open-weight model where local inference provides meaningful benefits in privacy, offline capability, cost, and model flexibility.

Final Thoughts

Gym Log Buddy started with a very small problem:

My friend keeps forgetting his gym weights.

It ended up becoming an experiment in local AI, evaluation, prompt leakage, schema design, testing, privacy, and honest benchmarking.

I didn't build a huge fitness platform.

I built a small tool for one real person.

And that's exactly what this challenge was about.

Build for a friend. Build something useful. Then test whether it actually works.

Thanks for reading, and happy Hacktoberfest! 🚀

"Innovating Tomorrow: How Our Hackathon Project is Powering a Smarter Future"

Shubham Nayak — Sun, 20 Jul 2025 13:36:15 +0000

🧠Our Project: Silent SOS – A Gesture/Voice-Based Emergency Alert System
At the heart of every hackathon lies a purpose—to innovate, solve real problems, and build something impactful in record time. For our team, that purpose took the form of Silent SOS, a safety-focused web application that uses gesture and voice triggers to silently raise emergency alerts.

With growing concerns about personal safety and harassment, especially in public or isolated spaces, we wanted to create a discreet and fast emergency alert system—without needing to unlock a phone or type anything.

🔧** Tech Stack + Bolt Integration**
We built our project using:

Frontend: HTML, CSS, JavaScript (Vanilla)

Backend: Node.js + Express

Database: MongoDB

Realtime Alert System: Bolt API for sending instant alerts (notifications, webhooks, and integrations)

Bolt made a huge difference by allowing us to send fast, reliable emergency alerts, integrating seamlessly with our backend using webhooks and trigger-based flows.

⚙️ How SilentSOS Works
Voice or Gesture Recognition: Detects predefined gestures or trigger words like “Help!” using Web Speech API and Hand Detection Models.

Silent Alert: Sends data to our backend with location & timestamp.

Bolt Trigger: Instantly pushes alert via SMS/Discord/Webhook to saved contacts using Bolt.

Live Dashboard: Admin panel to view active alerts and track responses.

💡Challenges We Faced
Gesture Accuracy: Calibrating for different lighting and hand sizes.

Silent Triggers: Ensuring no UI popups so the alert remains hidden.

Bolt Webhook Timing: Syncing real-time data with the alert system.

Breakthrough moment: When Bolt successfully triggered a live SMS and webhook alert with just a gesture in under 3 seconds.

⭐ Favorite Bolt Features
🔔 Real-time Webhook Triggers – Lightning-fast and developer-friendly

🧩 Easy to integrate – No lengthy setup, minimal code required

📡 Reliable delivery – Worked every time under load

👥 Team Members
@shubham_nayak_ (Me – Frontend & Integration)

Submission posted by @shubham_nayak_ on behalf of the team.

🎯 *What We Learned *
How to balance UX with urgency in safety apps

Integrating Bolt APIs for real-time use cases

Working collaboratively under pressure and making quick architectural decisions

💬 Final Thoughts
Participating in this hackathon was more than just coding—it was about building with purpose. Bolt’s simplicity and power enabled us to create something potentially life-saving. We're excited to continue improving SilentSOS, adding more AI capabilities and mobile support.

Let’s continue building for impact, with speed and safety.

Hackathon #BoltHackathon #DevChallenge #SilentSOS #WebDev #AI #EmergencyTech

DEV Community: Shubham Nayak

👻 Meet GhostShell — a spooky AI-powered terminal assistant!

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

My Agent Session

The Spirit of It

Prize Categories

SlothChef: A Local AI Vision Agent That Turns Your Fridge Into a Meal

What I Built

Demo

Code

How I Built It

Why Open Innovation Matters

1. Privacy

2. Offline Independence

3. No Per-Request API Cost

4. Developer Control

My Agent Session

The Lazy Payoff

FreelanceFlow AI: A Privacy-Friendly Business Assistant Powered by Open-Source AI

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

My Agent Session

My First User

Prize Categories

What's Next?

FrostSprout: I Built a Local AI Garden Assistant That Gets You Outside, Not Staring at a Dashboard

The Problem: Your Garden Doesn't Need Another Dashboard

What I Built

1. From Weather Data to Actionable Decisions

2. An AI Guide You Can Listen to Outside

3. A Printable Garden Field Card

4. What-If Frost Scenarios

5. An Outdoor Activity Log

Demo

Code

How I Built It

The Architecture

TabPFN: The Prediction Layer

Gemma 3: Turning Predictions into Practical Advice

Live Weather Without an API Key

Benchmark Results: What the Numbers Actually Mean

Why Open Innovation Matters

Privacy and Local Inference

Freedom to Inspect and Replace Components

Graceful Degradation

Transparency Over Artificial Confidence

What I Learned

What's Next?

My Agent Session

Prize Categories

Final Thoughts

I Built a Local AI Gym Log for a Friend Who Always Forgot His Weights

What I Built

Gym Log Buddy — A Local AI Workout Logger Built for a Friend

AI where it helps. Deterministic code where it doesn't.

Demo

🎥 Video Demo

Code

Shubham-cyber-prog / Gym-Log-Buddy

Local-first gym log: Gemma 3 (via Ollama) turns messy workout notes into structured data.

Gym Log Buddy

Features

Tech Stack

How I Built It

Why Gemma 3?

I Tested the Real Model — Including Its Failures

Failure #1 — 60 Became 27.2 kg

Failure #2 — The Model Invented an Exercise

Failure #3 — My Schema Couldn't Represent 8,8,6

Then I Found Benchmark Leakage

Testing Beyond the Model

Running Gemma 3 Without a Dedicated GPU

Why Does Open Innovation Matter?

Failure #3 — My Schema Couldn't Represent `8,8,6`