DEV Community: Joydeep Banik

Touching Grass with Local AI: Building Waypoint Autopilot

Joydeep Banik — Wed, 21 Oct 2026 06:26:47 +0000

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

What I Built

Waypoint Autopilot is a mobile-first, privacy-centric Progressive Web App (PWA) designed to get you off the screen and into the real world. It generates autonomous, context-aware pedestrian exploration missions through your city or local parks without requiring you to constantly stare at a map.

It is built for urban explorers, mindful walkers, and anyone looking to discover hidden gems (like quiet greenways, historic landmarks, or vibrant pedestrian alleys) in their vicinity. By using an "Eyes Up, Phone Away" philosophy, the app calculates a deterministic route using open geographic data, delivers a locally-generated AI mission briefing before you leave, and then lets you cache the entire mission offline. While walking, it uses subtle audio and haptic cues to guide you from waypoint to waypoint, ensuring you remain present in your surroundings.

Demo

Since this application relies on a local AI model for mission preparation and heavily utilizes device-native features (like GPS and IndexedDB for offline storage), the best way to experience it is to run it locally!

journey
    title A Typical Waypoint Mission
    section Preparation
      Set anchor & radius: 5: User
      Select exploration style: 5: User
      Local AI generates brief: 4: AI
      Cache for offline use: 5: User
    section The Walk
      Put phone in pocket: 5: User
      Walk to Waypoint 1: 4: User
      Audio chime on arrival: 5: System
      Glance to confirm: 5: User
    section Completion
      Return to start: 4: User
      View mission summary: 5: User

Code

Joydeep2005Banik / waypoint

Waypoint Autopilot

Waypoint Autopilot is a mobile-first, installable web application (PWA) that guides a person through an ordered sequence of real-world geographic waypoints for pedestrian exploration of cities and parks.

It is designed around an "Eyes Up, Phone Away" philosophy: alerting walkers with distinct audio and glanceable waypoint cues upon arrival so they can keep their phones in their pockets.

Technical Stack & Architecture

Frontend & App Framework: Next.js 14 (App Router), React 18, TypeScript (strict).
Styling & Design System: Tailwind CSS with outdoor-optimized high-contrast palettes and 48px+ touch targets.
Mapping & Geometry: Leaflet and React-Leaflet with OpenStreetMap tiles and pedestrian topology.
Navigation State Machine: Pure TypeScript finite state machine with noisy GPS filters, arrival dwell confirmation, and route deviation detection.
Local Persistence & Privacy: Local storage & IndexedDB for mission storage, waypoint logs, and offline tile caching. Zero remote tracking or telemetry.
Open-Weight AI…

View on GitHub

How I Built It

Waypoint Autopilot is built using Next.js 14, React, Leaflet, and TailwindCSS for a sleek, highly-responsive mobile UI.

The Open-Source AI Integration:
The project uses Ollama running locally (specifically recommending the qwen2.5:1.5b open-weight model) to act as your personal "Mission Commander." Before you embark on your walk, the application queries the local LLM with the deterministic waypoints it gathered. The AI generates a rich, contextual pre-departure briefing—adding narrative flavor and context to the route based on the POIs.

Crucially, the AI is strictly sandboxed to the preparation phase. Pathfinding, obstacle avoidance, and waypoint progression are governed entirely by deterministic spatial algorithms (OSRM and OpenStreetMap Overpass API) to ensure pedestrian safety. The AI never hallucinates navigation instructions or routing.

Offline-First & Privacy Architecture:
Once the mission is prepared, the entire payload (route geometry, AI briefing, map data) is serialized into IndexedDB. A PWA Service Worker caches the application shell. You can completely disconnect from the internet and cellular data, and the app will continue to track your progress using offline device GPS. Furthermore, there is zero remote telemetry—no accounts, no analytics, and no continuous location tracking sent to any servers.

Why Does Open Innovation Matter?

Open innovation is the core enabler of Waypoint Autopilot.

If this app were built on closed APIs, it would be impossible to guarantee the absolute privacy of the user's location data. By using OpenStreetMap (ODbL) for POI discovery and routing, we bypass proprietary mapping ecosystems that monetize location history. By using Ollama and open-weight models running strictly on localhost:11434, the user's contextual data and starting location never leave their device to hit a corporate inference endpoint.

Open innovation makes it possible to build an application that genuinely respects the user's peace, privacy, and physical safety while still delivering a highly personalized, AI-enhanced experience.

KubeSense: A Private, Local-First AI DevOps Assistant

Joydeep Banik — Tue, 13 Oct 2026 07:25:03 +0000

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

What I Built

I built KubeSense, a high-density, terminal-based Kubernetes monitoring dashboard.
I built this for my junior batchmate, who is an aspiring DevOps engineer. During one of his internships, he expressed how constant pod monitoring is cumbersome and he wanted something that is terminal native so that he does not have to switch windows while working unlike heavy web-based UIs like Lens or Rancher. He wished something lightweight that stays in the CLI but is smart enough to highlight exactly what matters and filters out the unnecessary jargon. KubeSense solves this by bringing real-time metrics and AI-driven log anomaly detection directly to their terminal window.

Demo

Code

The project is publicly available at: https://github.com/Joydeep2005Banik/KubeSense

How I Built It

KubeSense is built entirely in Python, utilizing a decoupled architecture driven by a central PodMonitor engine. Here is a high-level look at the architecture:

graph TD
    subgraph UI Layer
        A[Terminal UI]
    end
    subgraph Core Logic
        B[Monitor Engine]
    end
    subgraph Data Sources
        C[K8s API]
        D[SSH Fallback]
    end
    subgraph AI Processing
        E[Log Optimizer]
        F[LLM Providers]
    end

    B <-->|State Updates| A
    B -->|Fetch Metrics| C
    B -->|Fallback| D
    B -->|Raw Logs| E
    E -->|Clean Context| F
    F -->|Alerts| A

Here is a breakdown of the core systems:

1. Reactive Terminal UI (Textual)

I used the Textual framework to build the dashboard. Instead of relying on heavy "while-true" redraw loops, the UI uses Textual's event-driven reactive properties. When the Monitor Engine pushes new metrics, only the changed widgets redraw, ensuring a lightning-fast, zero-overhead experience without screen tearing.

flowchart LR
    A[Monitor Engine] -->|Sends updated<br/>Metrics Object| B(Reactive Variable)
    B -->|Triggers Auto-Update| C[UI Node / Widget]
    C -->|Only redraws changed region| D[Terminal Display]

2. Resilient Metric Collection & SSH Fallback

The tool primarily connects to the cluster using the official kubernetes Python client to fetch live status and log streams. However, if the cluster's K8s Metrics Server goes down, KubeSense intelligently engages a graceful fallback mechanism to connect directly to the underlying cluster nodes via asyncssh.

sequenceDiagram
    participant M as Monitor
    participant K as K8s Metrics API
    participant S as SSH Fallback
    participant N as Node Shell

    M->>K: Fetch Pod CPU/Mem
    alt Metrics Server Unavailable
        K-->>M: HTTP 404 / Error
        M->>S: Engage Fallback (asyncssh)
        S->>N: Connect to Node via SSH
        N-->>S: Execute `top` & parse usage
        S-->>M: Return hardware metrics
    else Success
        K-->>M: Standard API Metrics
    end

3. Log Optimization Pipeline

Logs can be incredibly noisy and expensive to process. Before any logs touch the AI, they pass through a custom LogOptimizer:

flowchart LR
    A[Raw Log Stream] --> B{Severity Filter}
    B -- Keep WARNING+ --> C[Deduplication]
    C -->|Collapse repeated| D[PII Scrubbing]
    D -->|Mask IPs/UUIDs| E[Optimized Payload]

This ensures the context window remains small, protecting privacy and saving tokens.

4. Multi-Provider AI Engine (Local-First)

For the AI core, I implemented an abstract factory pattern to handle the anomaly detection. While it supports BYOK for cloud providers like Groq or OpenAI, the default engine runs entirely locally via Ollama.

flowchart TD
    A[Optimized Payload] --> B{AI Factory Config}
    B -->|groq| C[GroqProvider<br/>Cloud API]
    B -->|openai| D[OpenAIProvider<br/>Cloud API]
    B -->|ollama| E[OllamaProvider<br/>Local/Air-gapped]
    B -->|mock| F[MockProvider<br/>Heuristics Fallback]

    C & D & E & F --> G[JSON Enforcement & Parser]
    G --> H[Anomaly Alerts to UI]

Key Features

Smart Log Filtering & Deduplication: Aggressively filters noise (INFO, DEBUG), deduplicates repeated errors, and scrubs PII before any AI processing.
BYOK (Bring Your Own Key): While local open-weight models via Ollama are the default, you can easily plug in an API key for Groq or OpenAI via config.yaml or environment variables if you prefer cloud inference.
SSH Fallback: Automatically drops to a direct SSH connection to scrape node hardware via top if the Kubernetes Metrics Server isn't available.

As KubeSense streams the optimized container logs, it passes these batches to an open-weight model running locally. The model analyzes the logs in the background, strictly returning structured JSON, and alerts to warnings, hidden errors, or unusual patterns before they escalate without adding any overhead to the cluster itself.

Why Does Open Innovation Matter?

Deploying open-weight models locally resolves critical architectural and operational limitations associated with closed APIs:

1. Data Sovereignty & Air-Gapped Execution

Kubernetes logs frequently leak sensitive infrastructure data, internal IP schemas, and environment variables. Streaming these logs to a third-party server via a closed API introduces unacceptable security risks and compliance violations (e.g., SOC2/HIPAA). By running inference locally via Ollama, KubeSense ensures complete data sovereignty. The tool can operate entirely offline, making AI-driven log analysis viable for strict, air-gapped environments.

2. O(1) Inference Costs

Streaming high-volume log data through a token-metered API creates unbounded operational costs. Local inference with open-weight models reduces the marginal cost of analysis to zero, making continuous 24/7 log processing financially viable.

3. Hardware-Specific Model Tuning

Closed ecosystems abstract away model selection. An open architecture allows users to define the exact AI engine based on their hardware constraints. Systems with limited VRAM can deploy highly efficient models like Google's Gemma (gemma:2b), while robust systems can load higher-parameter models (e.g., llama3.1:8b) for complex log reasoning.

4. Deterministic Availability

Cloud AI APIs introduce network latency and are subject to HTTP 429 Too Many Requests rate limits. When triaging a production cluster outage, network dependency and API throttling are unacceptable. Local open-weight models guarantee deterministic availability and consistent latency independent of external network conditions.

Prize Categories

Best Use of Gemma (Using Google's Gemma open-weight model via Ollama for local log anomaly detection)

Let's Chat! 💬

If you have any questions about how the architecture works, why I chose Textual, or how to set up Ollama for your own cluster monitoring, please drop a comment below! I'd love to discuss why I think lightweight, terminal-native tools are often far more effective than heavy dashboards, and hear your thoughts on local AI for DevOps.

Touching Grass with Local AI: Building Waypoint Autopilot

Joydeep Banik — Sat, 10 Oct 2026 16:08:04 +0000

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

What I Built

Demo

journey
    title A Typical Waypoint Mission
    section Preparation
      Set anchor & radius: 5: User
      Select exploration style: 5: User
      Local AI generates brief: 4: AI
      Cache for offline use: 5: User
    section The Walk
      Put phone in pocket: 5: User
      Walk to Waypoint 1: 4: User
      Audio chime on arrival: 5: System
      Glance to confirm: 5: User
    section Completion
      Return to start: 4: User
      View mission summary: 5: User

Code

Joydeep2005Banik / waypoint

Waypoint Autopilot

It is designed around an "Eyes Up, Phone Away" philosophy: alerting walkers with distinct audio and glanceable waypoint cues upon arrival so they can keep their phones in their pockets.

Technical Stack & Architecture

Frontend & App Framework: Next.js 14 (App Router), React 18, TypeScript (strict).
Styling & Design System: Tailwind CSS with outdoor-optimized high-contrast palettes and 48px+ touch targets.
Mapping & Geometry: Leaflet and React-Leaflet with OpenStreetMap tiles and pedestrian topology.
Navigation State Machine: Pure TypeScript finite state machine with noisy GPS filters, arrival dwell confirmation, and route deviation detection.
Local Persistence & Privacy: Local storage & IndexedDB for mission storage, waypoint logs, and offline tile caching. Zero remote tracking or telemetry.
Open-Weight AI…

View on GitHub

How I Built It

Waypoint Autopilot is built using Next.js 14, React, Leaflet, and TailwindCSS for a sleek, highly-responsive mobile UI.

Why Does Open Innovation Matter?

Open innovation is the core enabler of Waypoint Autopilot.

Open innovation makes it possible to build an application that genuinely respects the user's peace, privacy, and physical safety while still delivering a highly personalized, AI-enhanced experience.

Ditching Web UIs: Building a Terminal-Native Kubernetes Monitor with Local AI

Joydeep Banik — Sun, 04 Oct 2026 16:26:31 +0000

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

What I Built

Demo

Code

The project is publicly available at: https://github.com/Joydeep2005Banik/KubeSense

How I Built It

KubeSense is built entirely in Python, utilizing a decoupled architecture driven by a central PodMonitor engine. Here is a high-level look at the architecture:

graph TD
    subgraph UI Layer
        A[Terminal UI]
    end
    subgraph Core Logic
        B[Monitor Engine]
    end
    subgraph Data Sources
        C[K8s API]
        D[SSH Fallback]
    end
    subgraph AI Processing
        E[Log Optimizer]
        F[LLM Providers]
    end

    B <-->|State Updates| A
    B -->|Fetch Metrics| C
    B -->|Fallback| D
    B -->|Raw Logs| E
    E -->|Clean Context| F
    F -->|Alerts| A

Here is a breakdown of the core systems:

1. Reactive Terminal UI (Textual)

flowchart LR
    A[Monitor Engine] -->|Sends updated<br/>Metrics Object| B(Reactive Variable)
    B -->|Triggers Auto-Update| C[UI Node / Widget]
    C -->|Only redraws changed region| D[Terminal Display]

2. Resilient Metric Collection & SSH Fallback

sequenceDiagram
    participant M as Monitor
    participant K as K8s Metrics API
    participant S as SSH Fallback
    participant N as Node Shell

    M->>K: Fetch Pod CPU/Mem
    alt Metrics Server Unavailable
        K-->>M: HTTP 404 / Error
        M->>S: Engage Fallback (asyncssh)
        S->>N: Connect to Node via SSH
        N-->>S: Execute `top` & parse usage
        S-->>M: Return hardware metrics
    else Success
        K-->>M: Standard API Metrics
    end

3. Log Optimization Pipeline

Logs can be incredibly noisy and expensive to process. Before any logs touch the AI, they pass through a custom LogOptimizer:

flowchart LR
    A[Raw Log Stream] --> B{Severity Filter}
    B -- Keep WARNING+ --> C[Deduplication]
    C -->|Collapse repeated| D[PII Scrubbing]
    D -->|Mask IPs/UUIDs| E[Optimized Payload]

This ensures the context window remains small, protecting privacy and saving tokens.

4. Multi-Provider AI Engine (Local-First)

flowchart TD
    A[Optimized Payload] --> B{AI Factory Config}
    B -->|groq| C[GroqProvider<br/>Cloud API]
    B -->|openai| D[OpenAIProvider<br/>Cloud API]
    B -->|ollama| E[OllamaProvider<br/>Local/Air-gapped]
    B -->|mock| F[MockProvider<br/>Heuristics Fallback]

    C & D & E & F --> G[JSON Enforcement & Parser]
    G --> H[Anomaly Alerts to UI]

Key Features

Smart Log Filtering & Deduplication: Aggressively filters noise (INFO, DEBUG), deduplicates repeated errors, and scrubs PII before any AI processing.
BYOK (Bring Your Own Key): While local open-weight models via Ollama are the default, you can easily plug in an API key for Groq or OpenAI via config.yaml or environment variables if you prefer cloud inference.
SSH Fallback: Automatically drops to a direct SSH connection to scrape node hardware via top if the Kubernetes Metrics Server isn't available.

Why Does Open Innovation Matter?

Deploying open-weight models locally resolves critical architectural and operational limitations associated with closed APIs:

1. Data Sovereignty & Air-Gapped Execution

2. O(1) Inference Costs

3. Hardware-Specific Model Tuning

4. Deterministic Availability

Prize Categories

Best Use of Gemma (Using Google's Gemma open-weight model via Ollama for local log anomaly detection)