DEV Community: RISHAV ROY

🌿 TerraQuest AI — Touch Grass, Not Screens

RISHAV ROY — Sat, 10 Oct 2026 21:11:47 +0000

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

What I Built

I built TerraQuest AI — Your Offline AI Companion for the Real World, an open-source, privacy-first outdoor exploration platform designed to help people spend less time staring at screens and more time connecting with nature.

Most digital applications are designed to maximize engagement and keep users online. TerraQuest AI takes the opposite approach: it uses AI to help people explore the real world, learn about biodiversity, and put their phones away.

The application combines offline-first functionality, local AI models, nature exploration tools, and gamified outdoor challenges to make stepping outside a more engaging and educational experience.

🌱 Key Features

Pocket Mode: Choose an outdoor quest, review your checklist, and switch to a minimal screen that encourages you to lock your phone and explore.
AI-Powered Nature Identification: Explore plants, birds, trees, and insects using guided morphological questions, image analysis, and optional local vision models.
Smart Adventure Planner: Plan outdoor activities lasting 15–60 minutes, with nature-focused checkpoints and accessibility considerations.
Touch Grass Challenges: Complete screen-free activities, observe wildlife, discover leaf structures, and earn nature-themed XP and badges.
AI Garden Planner: Get seasonal gardening guidance based on sunlight, soil type, and growing conditions.
Private Nature Journal: Save observations, photographs, notes, and optional location information directly in your browser.
Birdsong Analysis: Explore audio waveforms through the browser's Web Audio API.
Offline Field Guide: Continue using local taxonomy information and deterministic identification heuristics when internet access or a local AI model is unavailable.
Data Portability: Export and import journal data in JSON and CSV formats.

TerraQuest AI is designed around a simple philosophy: technology should help us reconnect with the world beyond our screens.

Demo

🌐 Live Application: https://terraquest-ai-murex.vercel.app

Explore the application and try Pocket Mode, the nature identification workspace, outdoor challenges, and the private field journal.

For a meaningful demonstration, start by selecting a quest, activate Pocket Mode, and experience how the application encourages you to step outside instead of continuing to browse.

Code

💻 GitHub Repository: https://github.com/GenX0Gravity/TerraQuestAI

The project is built with an open-source-first architecture, and contributions are welcome. Developers can explore the code, experiment with local AI models, improve nature identification, or add new outdoor activities.

How I Built It

I built TerraQuest AI using a modern web stack and a local-first AI architecture.

Technology stack:

Next.js 15 and React 19 — Application framework and user interface.
TypeScript and Tailwind CSS — Type-safe development and responsive styling.
Ollama — Optional local inference for open-weight language and vision models.
Qwen 2.5 and Gemma 2 — Open-weight language-model options for naturalist reasoning and assistance.
Moondream and LLaVA — Optional local vision models for image-based exploration.
Dexie.js and IndexedDB — Browser-based storage for observations, journal entries, and progress.
OpenStreetMap and Leaflet — Outdoor maps and nature-focused exploration.
Web Audio API — Audio waveform analysis for exploring birdsong.
Vitest — Unit and integration testing.
PyTorch, Torchvision, and ONNX — Supporting tools for the optional species-classifier training pipeline.

One of the central design decisions was to avoid making a cloud-based AI service mandatory. When Ollama is unavailable, TerraQuest AI can fall back to a deterministic local field-guide engine for supported features.

This makes the application more resilient in places where connectivity is unreliable and helps keep personal observations on the user's device.

The project also includes a machine-learning training pipeline for experimenting with datasets such as Oxford Flowers 102, Birds 525, and PlantVillage.

Why Does Open Innovation Matter?

Open innovation matters because AI-powered outdoor tools should not require users to surrender their personal data, depend on a single commercial provider, or maintain a constant internet connection.

TerraQuest AI demonstrates several advantages of an open-source-first approach:

1. Privacy by design

Nature observations, personal notes, photographs, and progress are stored locally in the browser using IndexedDB. The application is designed without mandatory accounts or cloud-based journal storage.

2. Freedom to choose AI models

By supporting local models through Ollama, the architecture gives users more flexibility to experiment with different open-weight language and vision models instead of relying exclusively on one proprietary API.

3. Accessibility beyond reliable internet

The local field-guide engine and offline-capable features help users continue exploring even when connectivity is limited. Some map content and local model capabilities have separate requirements, so not every feature operates identically in every offline environment.

4. Lower barriers to experimentation

Developers can inspect the code, modify the application, experiment with datasets, train classifiers, and contribute improvements without building the entire system around a paid AI service.

5. AI that encourages real-world experiences

Perhaps the most important part is the project's purpose. Rather than optimizing for endless scrolling, TerraQuest AI encourages users to observe birds, learn about plants, explore outdoor spaces, and disconnect from their devices.

Open innovation makes this approach easier to inspect, adapt, and improve collaboratively.

My Agent Session

I used AI-assisted development to help shape the project, refine its architecture, and organize its features into a cohesive application.

The development process focused on turning the challenge's central idea — Touch Grass — into practical functionality: Pocket Mode, offline-first nature exploration, local AI integration, outdoor challenges, and a private field journal.

I also focused on keeping the project maintainable through a clear README, documented setup instructions, testing guidance, and contribution guidelines.

The goal was not simply to add AI to another application. It was to explore how open AI models and thoughtful product design could encourage people to spend more time in the physical world.

Prize Categories

TerraQuest AI is especially relevant to the following themes:

Open-Source AI: The architecture supports local inference with open-weight models and a deterministic offline fallback.
Offline and Privacy-First Innovation: Core nature exploration and journal functionality are designed to work locally in the browser.
Touch Grass: Pocket Mode and screen-free outdoor challenges directly encourage people to step away from their devices.
Community Collaboration: The project welcomes contributions to its code, tests, nature database, and machine-learning pipeline.

Final Thoughts

Building TerraQuest AI reinforced an idea I find important: the best use of technology is not always to make people spend more time using it.

Sometimes, the best technology is the kind that gives people the confidence to put it away.

🌿 Touch grass. Explore your surroundings. Learn something about nature. Let AI be your guide, not your destination.

Project: TerraQuest AI on GitHub

Live Demo: Try TerraQuest AI

Challenge: Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass

Hacktoberfest #OpenSource #AI #MachineLearning #NextJS #Ollama #TouchGrass #PrivacyFirst

Reviving BharatVote AI: From Hackathon Prototype to a Complete Civic Intelligence Platform 🇮🇳

RISHAV ROY — Fri, 05 Jun 2026 14:32:23 +0000

Reviving BharatVote AI: From Hackathon Prototype to a Complete Civic Intelligence Platform 🇮🇳

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

BharatVote AI is an intelligent election guidance platform designed to help Indian citizens understand the electoral process through interactive AI-powered assistance.

The project was originally created as a rapid prototype during a short development sprint. While the core concept worked, many essential features were incomplete, documentation was missing, and the overall user experience needed significant refinement.

The vision behind BharatVote AI is simple: make election information accessible, transparent, and easy to understand for every voter.

Key Features:

AI-powered election guidance
Interactive voting process walkthroughs
Election timeline tracking
Constituency information access
Voter eligibility assistance
Election FAQ chatbot
Mobile-responsive interface
Accessibility-focused design

Demo

Live Application

https://your-live-demo-link.com

GitHub Repository

https://github.com/yourusername/bharatvote-ai

Screenshots

Before

Basic prototype UI
Limited navigation
Incomplete workflows
Minimal documentation

After

Fully responsive modern interface
Enhanced AI interactions
Complete voter journey guidance
Improved accessibility
Production-ready deployment
Comprehensive documentation

The Comeback Story

When I first built BharatVote AI, the project was developed under tight deadlines. The initial version successfully demonstrated the idea but lacked the polish needed for real-world use.

During the Finish-Up-A-Thon, I focused on transforming the prototype into a complete product.

What Was Missing

Inconsistent UI components
Incomplete election guidance flows
Missing mobile optimization
Sparse project documentation
Unoptimized code structure
Limited error handling

What I Improved

✅ Redesigned the user interface

✅ Refactored application architecture

✅ Added complete voter guidance workflows

✅ Improved responsiveness across devices

✅ Enhanced accessibility features

✅ Optimized performance

✅ Expanded documentation and setup guides

✅ Prepared the project for deployment

The result is a significantly more polished platform that better serves its original mission: helping citizens navigate the democratic process with confidence.

My Experience with GitHub Copilot

GitHub Copilot played an important role in accelerating the finishing phase of the project.

Some of the ways it helped include:

Faster Refactoring

Copilot suggested cleaner implementations and helped simplify repetitive code sections that had accumulated during the initial prototype stage.

UI Development

While redesigning components, Copilot generated boilerplate structures and styling suggestions that reduced development time.

Documentation Support

One of the most valuable contributions was helping generate and improve README sections, deployment instructions, and feature documentation.

Debugging and Optimization

Copilot frequently suggested fixes for edge cases, error handling improvements, and performance enhancements that might have otherwise taken significantly longer to identify.

Before vs After

The biggest lesson from this challenge is that unfinished projects often contain valuable ideas. Sometimes all they need is a second chance.

Before:

Prototype
Incomplete experience
Limited usability

After:

Production-ready platform
Improved user experience
Better maintainability
Stronger documentation
Real-world impact potential

Final Thoughts

Finishing a project teaches a different set of skills than starting one. This challenge gave me the opportunity to revisit an idea I still believed in, improve it with modern tools, and finally bring it to a state I'm proud to share.

A huge thanks to GitHub Copilot for helping transform an unfinished prototype into a polished and deployable application.

GitHubCopilot #FinishUpAThon #OpenSource #AI #CivicTech #WebDevelopment #India #Innovation

Gemini Enterprise Agent Platform: A Developer’s First Look at Next ’26’s AI Wave

RISHAV ROY — Wed, 29 Apr 2026 16:17:09 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Google Cloud’s new Gemini Enterprise Agent Platform aims to unify AI development for “agentic” applications. At Next ’26, Google announced that Vertex AI is evolving into this one-stop platform – “a comprehensive platform to build, scale, govern, and optimize agents”. In practice, that means moving beyond calling individual models or APIs to designing full agents that can reason, act, and even collaborate. As a developer, this stood out: the promise is to remove much of the boilerplate and friction we’ve dealt with.

What’s New with Agent Platform

Gemini Enterprise Agent Platform is not just a new name, it’s a redesigned AI toolkit. In Thomas Kurian’s keynote he framed it as “the evolution of Vertex AI,” bringing together all model- and agent-building capabilities with new orchestration and governance features. Key highlights include:

Unified Agent Development: Two parallel workflows – a visual Agent Studio (low-code drag-and-drop) and a code-first Agent Development Kit (ADK) – let anyone build agents. By default I use ADK for full control; the console now cleanly offers either path. In code, an agent is just a Python object with a name, model, instruction, and a list of Tool functions (for example, a lookup_order() API) – all in ~15 lines of logic, no boilerplate or YAML needed.
Serverless Agent Runtime: Once an agent is ready, it runs on a managed runtime (built on Cloud Run). It supports long-running agents with persistent state (backed by a “Memory Bank”). In my trial, deploying an agent was a one-liner gcloud command, and within minutes I had an endpoint. Best of all, this uses Cloud Run’s free tier (first 180K vCPU-seconds/month), so small projects can run at virtually no cost.
Built-in Observability & Control: The platform includes Agent Observability – a dashboard that traces the full reasoning chain (every tool call, model invocation, decision) as the agent runs. It’s literally a debugger for agents: I could click through each step of my agent’s answer to see how it decided to call lookup_order. Under the hood it also provides identity/registry/gateway features to track and secure agents, as well as simulation/evaluation tools for QA.
Model Ecosystem: Agent Platform gives first-class access to Google’s top models (e.g. Gemini 3.1 Pro, Gemini 3.1 Flash/Nano Banana 2, Lyria 3) and many others (Anthropic’s Claude, open LLaMA variants, etc.) . I could easily switch my demo agent’s model (from Gemini 2.0-Flash to Gemini 3.1 Pro) with just a parameter change. The platform also plugs into “Model Garden” for testing/tuning any model.
Multi-Agent Protocol (A2A): Google introduced an Agent-to-Agent (A2A) protocol. In short, multiple agents can now discover and communicate directly on a standard protocol (akin to “HTTP for agents”). I briefly chained my support agent with a simple “refund processor” agent and the built-in A2A routing handled the interaction. No extra API glue was needed – it worked out of the box.

Together, these features show Google aiming for an “agentic enterprise” where AI pieces plug together seamlessly. As Kurian put it, Agent Platform is the foundation of that vision, handling “every aspect of your agents” in one place
.

Hands-On: Building a Simple Agent

Rather than just read docs, I immediately tried building a trivial “customer support” agent. The experience was shockingly smooth:

Install SDK: In my terminal I ran:

pip install google-cloud-agent-platform google-adk

That was it – no extra gcloud projects or API keys at this point. The new SDK bundles everything so I could code right away.

Write the agent: In ~15 lines of Python I defined two simple tool functions (lookup_order(order_id) and escalate_ticket(issue, name)) and created an Agent instance with those tools and a short instruction. For example:

from google.adk import Agent, Tool

def lookup_order(order_id): 
    orders = {"ORD123": {"status": "shipped", "eta": "Apr 30"}}
    return orders.get(order_id, {"error":"Not found"})

def escalate_ticket(issue, name):
    return {"ticket_id": "TKT1001", "status": "escalated"}

support_agent = Agent(
    name="support-assistant",
    model="gemini-3.1-pro",
    instruction="You are a helpful customer support assistant.",
    tools=[
        Tool(name="lookup_order", function=lookup_order),
        Tool(name="escalate_ticket", function=escalate_ticket),
    ]
)

response = support_agent.run("Where is my order ORD123?")
print(response.text)

By coincidence, this example is almost identical to one shared by a fellow dev – they emphasize that it was “15 lines of actual logic. No boilerplate”. And indeed, it ran on the first try!

Test locally: The call support_agent.run(...) returned a response text right away. Behind the scenes it invoked Gemini, parsed the JSON from lookup_order(), and composed an answer. Seeing it work immediately was delightful – I could focus on what the agent should do, not wiring it up.

Deploy to runtime. To make it production-ready, I used the new gcloud commands:

gcloud alpha agent-platform runtimes agents deploy support-assistant \
    --region=us-central1 --display-name="Support Agent" --entry-point=agent.py

About 2 minutes later it was live. From there I could use the Google Cloud console or API to query the endpoint from anywhere. This is handled by “Agent Runtime,” which is just Cloud Run underneath – hence the free tier applies
and I could keep experimenting without incurring charges.

Overall, the Developer Experience feels frictionless. The SDK setup literally took seconds (no juggling multiple libraries or credentials). Writing the agent code was focused only on logic and language prompts. Even deploying was a simple CLI – nothing like wrestling with Kubernetes or servers. As one reviewer noted, this is the kind of UX that makes you say “Wait, that worked on the first try?”
.

Pros and Caveats

What works well: I love that almost everything is managed. Out-of-the-box observability means I can debug agent behaviors visually. The platform scales agents under the hood (honestly, I didn’t have to think about scaling). The free tier usage is real – I got roughly 180k CPU-seconds free per month (same as Cloud Run) – so a solo developer or small project can do a lot at no cost. Also, having a unified place for models and data connections is powerful: the platform even promises a “Knowledge Catalog” and cross-cloud lakehouse to ground agents on data (though I didn’t test those yet).

Challenges: It’s not all perfect. The rebrand from Vertex AI was a bit jarring – documentation and tutorials are still catching up. For instance, Google quietly said Vertex AI services will move exclusively to Agent Platform going forward, and Vertex libraries after June 2026 won’t be updated. That means if you have legacy Vertex code, you’ll need to migrate soon. Some docs still refer to old names, so you have to mentally translate things.

The new Agent Designer (low-code) is cool for quick demos, but in practice it’s limited to simple flows. I found complex logic still pushes me into ADK code. And while the platform gave me power, certain enterprise aspects feel “beta”: there’s not yet clear CI/CD guidance, and advanced features (like fine-grained IAM or model governance) have thin docs. For example, setting up ModelArmor or grounding agents in private data is promised, but I didn’t see step-by-step guides yet.

Finally, there’s always the question of cost and opacity: we traded compute management for model usage. Google’s new infrastructure (like 8th-gen TPUs and custom chips) means we’ll need to watch usage. The underlying pricing (beyond free tier) can still be confusing for new agent workloads.

Why This Matters to Us

Stepping back, Gemini Enterprise Agent Platform signals a shift in AI dev. We’re moving from the “model era” to an “agent era,” as one expert put it. It’s no longer about which model, but how we orchestrate them. For developers, this means treating AI systems more like microservices or workflows: we design agents with tools, loops, memory, and governance. The platform makes that accessible.

My takeaway: The glue (plumbing) is being normalized. If your app needs smart assistants, RPA, or automated workflows, this platform could be a game-changer. You can prototype end-to-end without building a lot of infrastructure from scratch. The developer velocity is real – I spent minutes, not days, on my test agent. In practical terms:

Do try it if you can: Use the free credits and free tier to spin up an agent, even a toy one. You’ll see how straightforward it is to connect LLM reasoning with your own code and data.
Plan migration if you’re on Vertex: Google is basically telling us Vertex AI as a standalone thing is gone. Learn the new ADK and workspace; think about how to re-write existing pipelines on Agent Platform.
Don’t expect magic no-code for all: The no-code studio is neat, but you’ll likely need to code to get complex behavior. Treat Agent Designer as a helper, not a full replacement for developers.

In short, Google Cloud NEXT ’26 didn’t just drop new APIs – it dropped a developer experience. The Gemini Enterprise Agent Platform is an ambitious bet that AI tooling belongs in one place. If that idea resonates with you, it’s worth exploring firsthand. It might feel a bit raw at first, but it’s the clearest signal yet of where cloud AI is headed: not just smarter models, but smarter ways of building with them.