DEV Community: Harsh Vardhan Pandey

DabbaETA: a 'will this tiffin be late?' predictor that never sends a customer's address to the cloud

Harsh Vardhan Pandey — Sat, 17 Oct 2026 07:25:54 +0000

This is a submission for the HF26 Challenge: Side Hustle

It's 1 PM and the phone won't stop ringing

If you run a small tiffin service in India, you know this day. It started raining at 12. One rider is new. Eight orders went out together. By 1 PM, customers are calling: "Bhaiya, khana kab aayega?"

The owner has months of delivery history in a notebook or a spreadsheet. Nobody has ever used it to see this coming. Swiggy has an ML team for that. A 40-order kitchen doesn't, and that owner isn't going to upload customer names, phone numbers and home addresses to a random SaaS to fix it.

So I built the version that runs on the laptop they already have.

What I built

DabbaETA is a local-first dispatch assistant for small delivery businesses: tiffin services, bakeries, local couriers.

Upload past deliveries as a CSV (schema is validated and stored in a local SQLite file).
TabPFN predicts the ETA and the late-delivery risk for every pending order, shown as HIGH / MODERATE / LOW badges.
Gemma runs on Ollama on the same machine. Ask it "Aaj kaunsi orders late hongi?" and it answers. It also drafts polite delay messages in Hinglish, Hindi or English, ready to copy into WhatsApp.
One click on Run dispatch starts a Temporal workflow: load orders → predict all → flag risky → explain bottlenecks → draft messages.
Sentry spans wrap every Gemma and TabPFN call and record latency and token counts.

Code: https://github.com/Harsh63870/DabbaWala

Why open matters here

For this product, open is what makes the business possible at all.

Customer data stays put. Names, phones and addresses never reach an LLM API. Gemma runs locally. The only thing that leaves the machine is a table of numbers (distance, traffic, weather, prep time) sent to TabPFN. The predictor sits behind a BasePredictor interface that already supports both the tabpfn-client API and the local tabpfn package, so going fully offline is a config change, not a rewrite.
No per-message bill. Every ETA question and every drafted message on a metered API costs money. On a tiffin owner's margin, that adds up quickly. Locally, the marginal cost is zero.
Swap the model in one line. OLLAMA_MODEL is an env var. When a better small Hindi-capable model ships, the owner upgrades without touching code.
No lock-in. There is no vendor whose pricing change can break a customer's daily workflow.

The benchmark (and what it does not show)

I didn't have a real tiffin dataset, so I generated 5,000 synthetic orders matching the schema of the Kaggle Food Delivery Times dataset: distance, traffic, weather, vehicle type, prep time, courier experience, evening rush and monsoon effects. Treat these numbers as a check that the pipeline works, not a claim about any real kitchen.

Full data (4,000 train / 1,000 test):

Model	MAE (min)	RMSE	R²	Fit time
TabPFN	3.60	6.05	0.937	0.39s
XGBoost	3.31	5.22	0.953	0.11s
Linear regression	6.27	10.15	0.822	0.003s

With thousands of rows, XGBoost wins. I'm reporting that as is. Both tree-based approaches are far ahead of linear regression, which is expected, since delivery time depends on interactions like distance × traffic × weather.

A small owner doesn't have thousands of rows, though. They have a few weeks of history. That's why the benchmark script also runs a small-data experiment on 50, 100 and 200 training rows, and why the predictor is swappable: if XGBoost is better for your data size, switch to it in one line. The full results and chart are in the repo under docs/benchmark.json and docs/benchmark.png.

How it works

flowchart TD
    A[Owner uploads CSV] --> B[(SQLite, local)]
    B --> C[TabPFN: ETA + late risk]

    subgraph T[Temporal DispatchWorkflow, exponential-backoff retries]
        D[load_orders] --> E[predict_all]
        E --> F[flag_risky]
        F --> G[explain: Gemma]
        G --> H[draft_messages: Gemma]
    end

    C --> D
    H --> I[WhatsApp drafts in Hinglish / Hindi / English]

    J[Chat: Aaj kaunsi orders late hongi?] --> K{Gemma agent, JSON tool routing}
    K --> L[predict_eta]
    K --> M[list_risky_orders]
    K --> N[draft_message]
    L --> C
    M --> C

    O[FastAPI + dashboard] -.-> T
    O -.-> K
    S[Sentry spans: tabpfn.predict, llm.gemma] -.-> C
    S -.-> G
    S -.-> H

A Gemma agent that doesn't depend on native tool-calling. Small local models are unreliable at it, so Gemma is prompted to emit {"tool": ..., "args": ...} and I parse it with regex extraction plus a retry loop. Three tools: predict_eta, list_risky_orders, draft_message. Heuristic routing catches Hinglish queries like "Aaj kaunsi orders late hongi?" even when the model's JSON is malformed.

Temporal for the morning run. A dispatch run chains a prediction step with several LLM calls, and any of them can fail halfway. Each step is an activity with exponential-backoff retries, so one flaky call doesn't mean redoing the whole run. If Temporal isn't reachable, the app falls back to an in-process run so the demo still works on any laptop.

Sentry for visibility. Custom spans around every Gemma and TabPFN call record latency_ms, tokens_in and tokens_out, which makes it clear where time goes when a dispatch run feels slow.

Tests. 8 pytest tests cover order-schema validation, the predictor interface, agent JSON extraction, Hindi-query routing, message drafting, the workflow happy path and the API endpoints.

Who would pay, and how much

My hypothesis, not yet validated: a tiffin or bakery owner will pay a small monthly fee, or a one-time setup fee, for "tell me which orders will be late before the customers call, and write the messages for me." The pitch is saved phone calls and fewer angry customers, not "AI". Because inference is local, my cost per customer is close to zero, so even a very small price leaves margin. A closed-API version would have to charge more just to cover token costs.

First user

I haven't landed a real paying user yet, and I'd rather say that than invent one. Everything above runs on synthetic data, so the first thing I'll do next is run it on a real owner's CSV and see where it breaks.

Limits

The demo dataset is synthetic, so real-world accuracy will differ.
On large data XGBoost beats TabPFN here, as the table shows.
TabPFN's free API key is non-commercial. Selling this requires a commercial licence from Prior Labs, or running the local tabpfn package under its own terms.
Gemma is fine for short drafts but not perfect at Hindi grammar, so owners should skim a message before sending it.

Prize categories

Best Use of TabPFN: TabPFN is the prediction core (ETA and late-risk), benchmarked against XGBoost and linear regression, inside a wider agent that turns predictions into actions.
Best Use of Gemma: Gemma runs locally via Ollama and powers the chat agent, JSON tool routing and Hinglish / Hindi / English message drafting.
Best Use of Temporal: the morning dispatch is a five-activity DispatchWorkflow with exponential-backoff retries.
Best Use of Sentry Agent Tracing: custom llm.gemma and tabpfn.predict spans record latency and token counts.

What's next

Run it on a real owner's data, add rider-level features, build a one-tap WhatsApp send flow, and retrain automatically as new deliveries get logged.

# 🌿 WildQuest AI: Less Scrolling, More Discovering

Harsh Vardhan Pandey — Sat, 10 Oct 2026 17:21:37 +0000

🌿 WildQuest AI — Touch Grass, Powered by AI

Try the live demo: https://wildquest-ai.onrender.com/

🔗 GitHub: https://github.com/Harsh63870/WildQuest-AI
⚙️ Backend API: https://wildquest-ai-api.onrender.com

My submission for the Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass.

Most AI applications are designed to keep us on our screens: generating content, answering questions, and automating digital tasks.

I wanted to explore a different use of AI.

What if AI could help people spend less time interacting with technology and more time experiencing the real world?

That question led me to build WildQuest AI, a privacy-first nature exploration companion that turns outdoor activities into personalized quests and helps users document what they discover.

The idea isn't to make nature more complicated with technology. It's to use technology to make getting outside a little easier.

🌱 What Is WildQuest AI?

WildQuest AI is a full-stack application that combines locally running AI with a nature journal and outdoor activity tracking.

Users can generate personalized nature quests, complete them outdoors, record observations, and revisit their experiences later.

Instead of requiring a hosted AI service, the application can use a local model through Ollama. When the model is unavailable, a deterministic quest catalog provides a fallback.

Key features

Personalized nature quests: Generate outdoor activities based on user preferences and available time.
Nature journal: Save observations, experiences, and reflections.
Session tracking: Keep track of outdoor exploration sessions and completed quests.
Journal history: Search, revisit, and export saved entries.
Achievements: Recognize exploration milestones without relying on manipulative engagement streaks.
Local-first architecture: Store journal data in SQLite and support local AI inference.
Graceful fallback: Continue generating quests through a deterministic catalog when local AI is unavailable.

🔗 Source Code

GitHub: https://github.com/Harsh63870/WildQuest-AI

🧠 Architecture: How It Works

I built WildQuest AI using a React frontend, a FastAPI backend, a local AI inference layer, and SQLite for persistence.

The frontend handles the user experience, while the backend manages quest generation and journal operations. The AI integration is optional at runtime because the application can fall back to predefined quest data.

System architecture

flowchart TD
    A["User"] --> B["React 19 + TypeScript"]
    B --> C["FastAPI Backend"]

    C --> D{"Local AI Available?"}

    D -->|Yes| E["Ollama"]
    E --> F["Qwen 2.5 3B"]
    F --> G["Generated Nature Quest"]

    D -->|No| H["Deterministic Quest Catalog"]
    H --> G

    G --> I["Quest Displayed in UI"]
    I --> J["Outdoor Exploration"]
    J --> K["User Records Observations"]
    K --> C

    C --> L[("SQLite Database")]
    L --> M["Journal History, Search and Export"]
    M --> B

The key design decision is that the AI model is not a hard dependency for the entire experience. If local inference is unavailable, the application can still provide quests through its fallback mechanism.

This makes the application more resilient and avoids making access to an AI model a prerequisite for going outdoors.

🛠️ Technology Stack

Layer	Technologies	Purpose
Frontend	React 19, TypeScript, Vite	User interface and application interactions
Styling	Tailwind CSS, Lucide	Layout, styling, and icons
Backend	Python, FastAPI, Pydantic	API endpoints, validation, and application logic
AI inference	Ollama, Qwen 2.5 3B	Local quest generation
Persistence	SQLite	Local storage for journal data
HTTP client	HTTPX	Backend HTTP requests
Testing	Python test suite, frontend build and type-check	Validate backend behavior and frontend compilation

🔄 Quest Generation and Data Flow

A typical interaction follows this sequence:

The user requests a nature quest.
The frontend sends the relevant preferences to the FastAPI backend.
The backend attempts to use the configured local AI model.
If inference succeeds, the generated quest is returned.
If the model is unavailable, the backend uses the deterministic fallback catalog.
The user explores outdoors and records an observation.
The backend saves the journal entry to SQLite.
The user can revisit, search, or export saved entries.

sequenceDiagram
    actor User
    participant UI as React Frontend
    participant API as FastAPI Backend
    participant AI as Ollama
    participant DB as SQLite

    User->>UI: Request a nature quest
    UI->>API: Submit quest preferences
    API->>AI: Request local inference

    alt Model available
        AI-->>API: Generated quest
    else Model unavailable
        API->>API: Select fallback quest
    end

    API-->>UI: Return quest
    UI-->>User: Display quest

    User->>UI: Save an observation
    UI->>API: Submit journal entry
    API->>DB: Persist entry
    DB-->>API: Confirm saved data
    API-->>UI: Return result

🔐 Why Local-First AI?

Privacy was an architectural consideration, not just a feature to mention in the README.

Using a locally running model means quest generation does not inherently require sending prompts to a hosted AI provider. SQLite also provides local persistence for journal data.

The design aims to provide:

Local inference: Use Ollama rather than requiring a cloud AI API.
Local persistence: Store journal entries in SQLite.
No mandatory GPS tracking: Outdoor exploration does not require continuous location tracking.
No mandatory account: The core experience does not depend on user registration.
A fallback path: The application can still provide quests when local inference is unavailable.

These choices reduce external dependencies and give users more control over their data. They do not, by themselves, guarantee that every possible deployment or network request is completely offline, so the actual behavior depends on how the application is configured and run.

🧪 Testing and Validation

During local development, the backend test suite completed with 14 passing tests. The frontend build and type-check also completed successfully in my local validation.

These checks gave me confidence in the application before preparing it for submission. They are a useful baseline, though they do not replace broader integration, security, or real-world usability testing.

💡 Engineering Decisions and Trade-offs

A few decisions shaped this project.

1. Local inference instead of a mandatory hosted model

Running a model locally reduces dependence on external AI services, but it also introduces setup requirements and hardware constraints. A smaller model such as Qwen 2.5 3B is a practical starting point for experimentation on consumer hardware.

2. Deterministic fallback instead of total failure

AI services can be unavailable, slow, or misconfigured. A fallback quest catalog allows the core quest-generation experience to continue without successful model inference.

3. SQLite instead of a separate database service

The application is designed for an individual user's exploration and journal. SQLite keeps persistence simple and avoids requiring users to operate an additional database server.

4. AI as an assistant, not an authority

WildQuest AI focuses on suggesting activities and recording personal observations. It does not claim that generated content is a scientifically verified species identification system.

These trade-offs keep the initial implementation relatively lightweight while leaving room for future improvements.

🚀 What's Next?

There is room to take the project further:

Expand quest categories and difficulty levels.
Improve personalization using previous quests and user preferences.
Add optional, carefully sourced nature observation guides.
Improve accessibility and mobile usability.
Expand automated tests and integration coverage.
Improve setup documentation and troubleshooting.
Evaluate optional integrations without making cloud services mandatory.

Any future species-identification feature would need reliable references, uncertainty handling, and validation rather than presenting AI-generated guesses as established facts.

🌍 Final Thoughts

WildQuest AI began with a simple idea: AI doesn't always need to help us do more things on a screen.

Sometimes, it can help us find a reason to put the screen away.

Building this project gave me an opportunity to explore local AI inference, backend API design, persistent storage, graceful fallbacks, and privacy-conscious product decisions in one application.

The technology supports the experience. The real objective is what happens after the user closes the app.

Less scrolling. More discovering. 🌿

Tags: #devchallenge #hf26challenge #opensource #ai #python #react

"DevLog: An AI Git Workflow That Keeps Your Code Local"

Harsh Vardhan Pandey — Sun, 04 Oct 2026 08:29:40 +0000

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

What I Built

I built DevLog, a local-first AI Git workflow for my developer friend who wanted AI assistance for everyday Git work without sending private source code and Git diffs to a cloud AI provider.

Developers commit frequently, but writing clear commit messages and pull-request descriptions can become repetitive and interrupt the development flow.

The obvious solution is to send the Git diff to an AI API.

But that raises a question:

Do I really need to send my source code to a cloud service just to generate a commit message?

DevLog takes a different approach.

It runs AI locally using Ollama and an open-weight model, reads the staged Git diff on the developer's machine, generates a commit message or PR description locally, lets the developer review the result, and then optionally publishes the changes to GitHub.

The AI generation itself does not require a cloud AI API.

The Core Idea

Git Repository
      │
      ▼
Staged Git Diff
      │
      ▼
DevLog
      │
      ▼
Local Ollama
      │
      ▼
Open-Weight LLM
      │
      ├──► Commit Message
      │
      └──► PR Description
      │
      ▼
Developer Reviews
      │
      ▼
Commit / Push / Create PR

The goal is simple:

AI assistance without giving up control of the code being analyzed.

Demo

🌐 Live Demo: https://devlog-fawn-omega.vercel.app/

The live deployment lets you explore the DevLog interface and understand the workflow.

The complete local AI workflow is designed to run on the developer's own machine with Ollama.

What DevLog Can Do

View repository status
Inspect staged Git diffs
Generate AI-powered commit messages
Generate AI-powered PR descriptions
Review and edit generated content
Commit staged changes
Push branches
Create GitHub pull requests
View repository activity and statistics
Run AI inference locally

Local AI Demo

For the actual AI inference, DevLog connects to Ollama running locally:

Developer Machine

Git Repository
      │
      ▼
   DevLog
      │
      ▼
   Ollama
      │
      ▼
 Local LLM

Once the model is downloaded, AI generation can work without an internet connection.

GitHub operations still require internet access when the developer explicitly chooses to push code or create a pull request.

Code

GitHub Repository: https://github.com/Harsh63870/Devlog

The repository contains:

React frontend
FastAPI backend
Ollama integration
Git operations
GitHub integration
Docker Compose setup
Local configuration
API endpoints
Deployment documentation

The project is released under the MIT License.

How I Built It

DevLog is split into a frontend, backend, local AI layer, Git integration, and optional GitHub integration.

Technology Stack

Frontend

React 19
TypeScript
Vite
Tailwind CSS
TanStack Query
Zustand
Three.js / React Three Fiber
Framer Motion

Backend

Python 3.12+
FastAPI
Pydantic
Uvicorn
Ollama SDK

Ollama
Open-weight local LLM
Mistral as the current model

Infrastructure

Docker
Docker Compose
Nginx
Kubernetes-ready deployment configuration

Developer Tools

Git
GitHub REST API
Conventional Commits

The AI Workflow

The workflow starts with a normal Git operation:

git add src/features/new-feature.ts

DevLog then reads the staged diff locally.

The backend passes the diff to the locally running Ollama model.

The model generates a commit message or PR description.

The developer reviews the output before anything is committed or published.

For example:

Git Diff
   │
   ▼
FastAPI
   │
   ▼
Ollama
   │
   ▼
Mistral
   │
   ▼
feat: add user authentication module

The generated output is only a suggestion. The developer remains in control and can edit it before committing.

Commit Generation

The developer can open the Commit workflow and ask DevLog to generate a conventional commit message based on the staged changes.

Example:

feat: add user authentication module

PR Generation

The same staged changes can be used to generate a pull-request title and description.

The developer can review the generated content and then choose whether to publish the branch and create the PR on GitHub.

Why Does Open Innovation Matter?

This is the central design decision behind DevLog.

I could have built the same product around a closed AI API.

That would have been straightforward.

But doing so would mean sending source code and Git diffs to an external AI inference service.

For developers working with private repositories, proprietary software, client code, or unreleased features, that can be an important privacy consideration.

DevLog instead uses an open-weight model running locally through Ollama.

🔒 Privacy

The staged Git diff used for AI generation stays on the developer's machine.

The application does not need to send the source code to OpenAI, Anthropic, or another cloud LLM provider to generate the commit message or PR description.

This reduces the amount of sensitive development data that needs to leave the developer's environment.

🌐 Offline AI

Once Ollama and the selected model are installed, AI generation can work without an internet connection.

Internet OFF

Git Diff
   ↓
DevLog
   ↓
Ollama
   ↓
Local Model
   ↓
Generated Commit

GitHub operations are different: pushing code and creating pull requests naturally require network access.

💰 No Per-Request AI API Cost

DevLog does not depend on a paid cloud LLM API for its AI generation.

The model runs on the user's own hardware.

That means there is no recurring per-request inference charge from an external AI provider.

The trade-off is that the user provides the CPU/GPU, memory, storage, and electricity required for local inference.

🔧 Model Freedom

The AI layer is not fundamentally tied to one proprietary provider.

Ollama allows users to run different supported local models.

This makes the AI layer replaceable:

             DevLog
                │
                ▼
             Ollama
                │
       ┌────────┼────────┐
       ▼        ▼        ▼
    Mistral    Llama    Other

The application can evolve as local models improve without requiring the entire product to be redesigned around a single cloud provider.

🧩 More Control

Open-weight models give developers more control over where inference happens and which model powers their workflow.

For DevLog, this matters because the AI is working directly with developer data.

The model isn't simply a remote service hidden behind an API.

It can become part of the developer's own environment.

Building for a Friend

I wanted DevLog to solve a real developer workflow problem rather than become another generic AI chatbot.

I built it for Ritik Ahirwar, who wanted AI assistance for Git workflows but had concerns about sending private code and diffs to external AI services.

The problem is small, but it occurs repeatedly:

Write Code
   ↓
Make Changes
   ↓
Stage Changes
   ↓
Need Commit Message
   ↓
Need PR Description
   ↓
More Repetitive Work

DevLog turns that into:

Write Code
   ↓
Stage Changes
   ↓
DevLog
   ↓
Local AI Understands Diff
   ↓
Commit / PR Generated
   ↓
Review
   ↓
Publish

The goal isn't to replace the developer.

It's to remove repetitive Git-writing work while keeping the developer in control of the final result.

What I Wanted My Friend to Get

The project was designed around three simple requirements:

AI assistance
Keep source code local
Avoid unnecessary cloud AI costs

That combination is what led to the local-first architecture.

Friend Feedback

His feedback helped me understand which parts of the workflow were genuinely useful and which parts could be improved.

For example, you could describe:

What they tried
What part they found useful
What confused them
What they wanted changed
Whether they would actually use it in their workflow

I prefer documenting the real reaction rather than inventing a polished success story.

Security & Privacy

DevLog follows a local-first architecture for AI processing.

What Stays Local

Git diffs used for AI generation
Local repository information
AI inference
Ollama model
Local DevLog configuration
GitHub token storage

What Touches GitHub

GitHub is only involved when the developer explicitly performs publishing operations such as:

Push a branch
Create a pull request

The AI generation step does not require sending the Git diff to a cloud LLM.

GitHub Token

DevLog supports fine-grained GitHub personal access tokens.

The token is stored locally and should be restricted to the repositories and permissions actually required.

Developers should also avoid committing .env files or local configuration containing credentials.

Important Security Boundary

Running AI locally does not automatically make an application secure.

DevLog therefore treats the local machine as the primary trust boundary and avoids sending the source code used for AI generation to a third-party LLM API.

If Ollama itself is exposed over a network, that network configuration should also be secured appropriately.

Architecture

The complete architecture looks like this:

flowchart TD
    A[Developer] --> B[DevLog React UI]

    B --> C[FastAPI Backend]

    C --> D[Local Git Repository]
    D --> E[Staged Git Diff]

    E --> C

    C --> F[Ollama]
    F --> G[Local Open-Weight LLM]

    G --> H[Generated Commit Message]
    G --> I[Generated PR Description]

    H --> B
    I --> B

    B --> J{Developer Review}

    J -->|Commit| K[Local Git Commit]

    J -->|Push / Create PR| L[GitHub API]

    K --> M[Local Repository]
    L --> N[GitHub Repository]

    G -. AI inference stays local .-> O[No Cloud LLM]

Architecture Principles

Local-first AI

The AI inference path is:

Git Diff
   ↓
FastAPI
   ↓
Ollama
   ↓
Local Model

There is no requirement for a cloud LLM API in this path.

Optional Cloud Interaction

The external network boundary is primarily for GitHub publishing:

Local DevLog
     │
     ├── Local AI → No cloud LLM
     │
     └── GitHub API → Only when publishing

No Vendor Lock-in

The application communicates with the local Ollama runtime rather than depending on a proprietary AI API as its core inference layer.

Self-hostable

DevLog can be run directly on a development machine or through Docker Compose.

The repository also contains Kubernetes deployment guidance for users who want to experiment with containerized deployments.

Offline Workflow

One of the things I specifically wanted to demonstrate was that AI-powered developer tooling doesn't necessarily have to mean cloud-dependent developer tooling.

After installing Ollama and downloading the model:

Internet
   OFF
    │
    ▼
┌───────────────────────┐
│      DevLog           │
│                       │
│  Git → FastAPI        │
│          ↓            │
│       Ollama          │
│          ↓            │
│      Local LLM        │
└───────────────────────┘
    │
    ▼
Commit / PR content

The AI generation portion can continue to work locally.

The developer can review and commit locally.

Only actions involving GitHub require network connectivity.

Developer Experience

I wanted the workflow to feel like a developer tool rather than a separate AI chatbot.

The intended flow is:

1. Modify code
       ↓
2. git add
       ↓
3. Open DevLog
       ↓
4. Inspect diff
       ↓
5. Generate commit
       ↓
6. Review / edit
       ↓
7. Commit
       ↓
8. Generate PR
       ↓
9. Push & create PR

This keeps the AI close to the existing Git workflow.

What I Learned

The most interesting part of building DevLog was realizing that local AI changes more than just where the model runs.

With a cloud AI API, the architecture naturally becomes:

Application
     ↓
Cloud API
     ↓
AI Provider
     ↓
Response

With local AI, the architecture becomes:

Application
     ↓
User's Machine
     ↓
Local Model
     ↓
Response

That changes:

Privacy boundaries
Deployment
Cost structure
Offline capabilities
Model selection
Data ownership
Infrastructure requirements

It also made me think more carefully about the difference between:

"AI-powered"

and

"AI that is actually part of the user's environment."

What's Next?

There are several areas I want to explore:

Better model switching from the UI
Support for more Ollama models
Prompt customization
Commit history analysis
Markdown development-log export
Multiple repository support
Better automated test coverage
More efficient inference for lower-end machines
More granular privacy controls
Better handling of very large Git diffs

The long-term idea is to turn DevLog into a local AI layer for everyday Git workflows.

My Agent Session

Optional

If you use DevRelay for this project, you can embed the session here so the judges can see the development process.

I used DevRelay to document the development process behind DevLog, including the implementation, debugging, and iteration of the local AI workflow.

Prize Categories

Open Source / Open Innovation
Hacktoberfest Weekend Challenge: Build for a Friend

Final Thoughts

DevLog started from a small developer workflow problem.

Writing commit messages and PR descriptions is repetitive.

The obvious answer was to connect the application to a cloud AI API.

Instead, I asked a different question:

Why send the code anywhere at all?

Using an open-weight model locally through Ollama made it possible to keep the AI workflow close to the developer's machine.

That gives DevLog a different set of priorities:

Your code.
Your machine.
Your model.
Your decision about what gets published.

For this project, that's why open innovation mattered.

i m here....

Harsh Vardhan Pandey — Sun, 04 Oct 2026 07:46:33 +0000