DEV Community: Kusumarani Jana

🌿 Nature Buddy AI

Kusumarani Jana — Sun, 11 Oct 2026 13:09:45 +0000

🌿 Nature Buddy AI: Your AI Companion for Getting Outside

What I Built

Nature Buddy AI is an open-source AI-powered nature companion built for the Hacktoberfest Week 1 “Touch Grass” challenge.

The idea is simple: the screen starts the adventure, but the outside world is the main experience.

Nature Buddy encourages people to step outside, explore their surroundings, discover plants and wildlife, and notice the little things they might usually ignore.

🌱 Key Features

Outdoor Missions: Explore nature through short challenges, from a 15-minute walk to leaf hunting and discovering hidden textures.
AI Nature Identification: Upload a photo of a leaf, butterfly, or natural scene to receive AI-powered observations, interesting facts, and suggestions for your next exploration.
Acoustic Sound Mapping: Listen to birds, rustling leaves, and other outdoor sounds, then explore where they come from.
Pocket Mode: Enjoy a timed outdoor break with relaxing nature sounds.
Nature Journal and Gamification: Track outdoor activities, earn XP, complete quests, and build a streak.

Nature Buddy is designed for students, nature beginners, and anyone who wants to spend less time scrolling and more time experiencing the real world.

While building this project, I started noticing the small things around me differently. Leaves, birds, and tiny creatures that I might have overlooked before became things I wanted to observe and understand. That is the experience I hope NatureBuddy can inspire in others, too.

Demo

🌿 Live Demo: [https://touch-grass-wine.vercel.app/]

🎥 Video Demo: [https://youtu.be/wlU8BGcvDtY]

Code

💻 GitHub Repository: [https://github.com/kusumaranikusumarani3232-hub/TouchGrass]

Nature Buddy AI is built with an open-source-first approach, with a focus on making nature exploration accessible and engaging.

How I Built It

I built Nature Buddy AI using React, Vite, Tailwind CSS, and a FastAPI backend.

The project combines outdoor challenges, a nature exploration interface, image analysis, text-to-speech, and progress tracking.

For its AI capabilities, Nature Buddy supports an open-weight BLIP vision model running locally in the browser through WebAssembly, with optional integrations for vision models through providers such as Groq, Hugging Face, and Ollama.

The application uses AI to help users explore the natural world rather than simply consume more digital content. Users can photograph something they discover outside, learn about it, and receive ideas for their next nature mission.

I also built features such as timed walks, outdoor quests, XP, achievements, and a nature journal to encourage real-world participation.

Why Does Open Innovation Matter?

Open innovation matters because AI-powered nature education should not be limited to expensive services or closed APIs.

Open-weight models give developers the opportunity to experiment, learn, adapt, and run AI models in different environments. Browser-based inference can also reduce dependence on external services for supported features.

By building Nature Buddy with open-source tools and flexible AI integrations, I can explore different models, learn from the community, and make the project easier for other developers to extend.

Most importantly, open innovation allows us to build technology that encourages people to reconnect with the world beyond their screens.

Prize Categories

[- Best Use of Render]

Building an English Learning Voice Agent in 10 Days with Murf Falcon

Kusumarani Jana — Sat, 15 Aug 2026 04:12:42 +0000

Introduction

Over the last 10 days, I built English Learning Coach, a voice AI that helps learners practice English through natural conversations. Instead of being just another chatbot, it can remember users, use tools, escalate to a teacher when needed, track call outcomes, and hand off math questions to a specialist.

This project was built for the Learning & Literacy track in 10 Days of Voice Agents — VoiceForBharat Edition, powered by Murf Falcon.

The Problem

Many learners hesitate to practice spoken English because they don't always have someone available to practice with. A voice-based assistant makes practice feel more natural than typing and gives immediate feedback during conversations.

What My Voice Agent Can Do

By the end of the challenge, my agent includes:

🎙️ Natural voice conversations using Murf Falcon

🛡️ Clear behavior and safety guardrails

🧠 Memory for returning users

🧰 Tool-based actions instead of only generating text

📞 Outbound calling support

👩‍🏫 Human escalation with consent and reference IDs

📊 Real-time call analytics dashboard

🔀 Specialist agent handoff for math practice

How the System Works

The project combines four main components:

Speech-to-Text to understand spoken input

LLM to decide how the agent should respond

Murf Falcon Text-to-Speech for natural voice replies

LiveKit for real-time voice communication

SQLite stores memory, escalation requests, and call analytics.

My Favorite Features
Human Escalation

If a learner becomes frustrated or asks for a teacher, the agent asks permission before sharing a short summary, creates a support request, and provides a reference ID.

Call Analytics

The dashboard tracks:

Total Calls

Successful Calls

Failed Calls

These values come from real conversations instead of hardcoded numbers.

Specialist Handoff

The main English coach hands math questions to a dedicated Math Practice Specialist, keeping responsibilities focused.

The Hardest Part

The biggest challenge was integrating LiveKit's telephony and shutdown callbacks.

I encountered issues such as:

SIP configuration problems

callback errors during shutdown

analytics not saving correctly

API differences between LiveKit versions

Instead of restarting the project, I fixed each issue step by step by testing, reading logs, and making small changes until the workflow became stable.

That debugging process taught me much more than a perfect first attempt would have.

How to Run the Project

Clone the repository.

Install dependencies.

Add API keys inside .env.local.

Start the backend.

Start the frontend.

Open the browser and begin a voice conversation.

Never commit API keys or private user data.

GitHub Repository

👉 https://github.com/kusumaranikusumarani3232-hub/Murf-ai

What's Next

If I continue improving this project, I'd like to add:

Better multilingual conversations

More specialist agents

Smarter progress tracking

Richer analytics

Final Thoughts

This challenge helped me understand that building a voice agent isn't just about generating speech. It's about designing conversations, protecting users, knowing when to ask for human help, and creating experiences that solve real problems.
Thanks to Murf AI for organizing this learning journey.

I built an AI that debugs my logs — then made the AI itself debuggable with SigNoz

Kusumarani Jana — Sat, 25 Jul 2026 11:49:16 +0000

I built AI SRE Copilot for the WeMakeDevs "Agents of SigNoz" hackathon — a Streamlit app that reads raw application logs and tells you the root cause, severity, and fix, using Groq's Llama 3.3 70B model instead of manually scrolling through stack traces.

That solves the log-debugging problem. But it creates a new one: an AI tool that just hands you an answer is a black box. If the model is slow, or fails silently, or behaves worse on certain logs, you'd never know unless you happened to be watching at that exact moment. So alongside the AI feature, I instrumented the AI call itself with OpenTelemetry and shipped the traces to SigNoz — treating the Groq call as a real, observable dependency, the same way I'd treat a database query.

How it's wired up

Every time a log gets analyzed, I wrap the request in an OpenTelemetry span and attach custom attributes to it:

ai.model — which model handled the request
ai.response_latency_ms — how long Groq took to respond
log.size_bytes — size of the input log
analysis.status — success or failure
analysis.type — what kind of analysis ran
user.action — what triggered the trace

These traces get exported through the OpenTelemetry SDK to SigNoz, where they show up as searchable, queryable data instead of disappearing into a terminal log.

What SigNoz actually showed me

To watch this over time instead of one trace at a time, I built a custom panel in SigNoz using the Query Builder, plotting signoz_latency.count over the last three days:

![SigNoz custom panel plotting signoz_latency.count over the last 3 days, showing a sharp spike around 7/24 that settles back down]
There's a clear latency spike around 7/24 that I never would have caught by just watching the app — I wasn't looking at that exact moment. But because the trace data was sitting in SigNoz, I could go back afterward and actually see it happened, and roughly when.

That's the real value of this setup: the AI's behavior doesn't just vanish after each request. It's there, on a dashboard, whenever I want to check it.

Takeaway

The AI half of this project — prompting Groq, formatting a response — was the easy part. The useful lesson was realizing observability doesn't stop at your own app code. If your app calls out to an AI model, that call is a dependency like any other, and it deserves to be traced and measured, not left invisible. SigNoz made that possible without me having to build any tracing infrastructure myself.

Built for the WeMakeDevs "Agents of SigNoz" hackathon.
🌐 Live App: https://ai-sre-copilot-pusprhbhw2vtaa62ojxnjo.streamlit.app/
💻 GitHub Repository:https://github.com/kusumaranikusumarani3232-hub/AI-SRE-Copilot