DEV Community: Ranit Das

Lazy Developer's Second Brain: Let Your AI Remember What You Forgot

Ranit Das — Tue, 20 Oct 2026 06:50:52 +0000

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

What I Built

Ever returned to a project after a few days and spent the first 20 minutes trying to remember what you were doing?

Which files did you modify? What bug were you fixing? Which tasks were left unfinished? And, most importantly, what should you work on next?

That's the problem I wanted to solve with Lazy Developer's Second Brain.

It's a local-first AI-powered developer assistant designed to remember project context, summarize development activity, track unfinished tasks, and help developers resume their work without starting from scratch.

What it does

Project Memory: Keeps track of development sessions and important project information.
Git Activity Analysis: Examines recent commits, branches, and working-tree changes to understand project progress.
Resume My Work: Generates a summary of the last known development state and recommends a next action.
Task Tracking: Helps organize unfinished work and keep track of pending tasks.
Project Assistant: Lets developers ask questions about their project history and saved memories.
Local AI Inference: Uses an open-weight model running locally rather than requiring a paid cloud AI API.

The goal is simple: spend less time remembering what you were doing and more time actually building.

The application is designed to run locally. A demonstration video or screenshots can be added once the application has been tested end to end.

Code

GitHub Repository: https://github.com/Uncooperativecase225/lazy-developers-second-brain

The project uses an open-source-friendly architecture built around React, Spring Boot, MySQL, and Ollama.

How I Built It

I wanted to build something useful for developers while exploring how open-weight AI models can power practical automation.

Here's the technology stack:

Technology	Purpose
React + TypeScript	Frontend interface
Vite	Frontend development and build tooling
Tailwind CSS	Responsive styling
Java + Spring Boot	Backend REST APIs and business logic
Spring Data JPA	Database access
MySQL	Persistent project memory and task storage
Ollama	Local AI inference
Qwen 3.5 9B	Project analysis, summarization, and contextual assistance
Git CLI	Repository history and change analysis
Flyway	Database schema migrations

How it works

The backend collects relevant project context from Git repositories and previously saved development sessions.

That context is passed to Qwen through Ollama, allowing the model to generate a summary of recent activity, identify potential unfinished work, and suggest what the developer should do next.

The application stores project metadata, session summaries, and tasks in MySQL so that useful context persists between sessions.

Rather than treating AI as a chatbot bolted onto a dashboard, the project uses local inference as part of its core workflow.

Why Does Open Innovation Matter?

For a tool that analyzes source code and development history, privacy matters.

Developers may work with proprietary repositories, unpublished projects, private debugging notes, and sensitive configuration details. Sending all that information to an external AI service is not always desirable.

Using Qwen 3.5 9B through Ollama gives this project a different approach.

1. Local-first processing

The AI can run on the developer's own machine. Project context does not inherently need to be uploaded to an external inference provider.

2. No mandatory per-request AI fees

Once the model is downloaded, developers can run inference locally without paying a cloud AI provider for each request. Hardware and electricity costs still apply.

3. Model freedom

The application can be adapted to support other compatible models without rebuilding its entire architecture around a proprietary AI API.

4. Offline potential

After the necessary software, dependencies, and model have been downloaded, the core workflow can be designed to operate without an internet connection.

5. Customization and transparency

Developers can inspect the application code, modify prompts, experiment with different models, and adapt the system to their own workflows.

Open innovation makes it possible to build a developer assistant that prioritizes user control rather than making a third-party AI service a permanent dependency.

My Agent Session

I haven't published a DevRelay session yet.

I'll add a session link here if I capture and publish one during development.

The Lazy Payoff

Imagine returning to a project after a week away.

Instead of manually reviewing commits, opening multiple files, searching through notes, and trying to reconstruct your thought process, you open your Second Brain.

It gives you a summary of your last known development state, shows outstanding tasks, and recommends a next step.

Less context switching. Less repetitive investigation. More time spent coding.

I'm still validating the complete workflow, so I don't have measured time-saving results to report yet. The next step is to test it against real development sessions and compare how long it takes to resume work with and without the application.

Prize Categories

I'll select the applicable partner categories after checking the challenge's official rules and eligibility requirements.

The idea behind this project is straightforward:

Your computer should remember your development context, even when you don't.

Built around open-weight AI, local inference, and persistent project memory, Lazy Developer's Second Brain aims to make returning to unfinished work less painful.

Because sometimes the most productive thing an AI can do is help you pick up exactly where you left off.

RepoMedic: An AI Debugging Assistant That Runs Locally 🔧

Ranit Das — Sun, 18 Oct 2026 19:04:59 +0000

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

What I Built
RepoMedic is a local-first AI debugging and code repair assistant designed to help developers diagnose and fix broken JavaScript and TypeScript projects.

Every developer has experienced the frustration of a project that suddenly stops building. Dependency conflicts, TypeScript errors, broken configurations, and ESLint failures can consume hours that could have been spent building something useful.

RepoMedic aims to make that process faster.

Instead of simply explaining an error, RepoMedic follows a structured repair workflow:

Scan: Inspect a local repository and identify common build, dependency, and lint errors.
Diagnose: Use an open-weight AI model to explain the likely root cause.
Propose: Generate a targeted code repair.
Validate: Apply the proposed changes in an isolated Git worktree and run relevant checks.
Review: Show the developer the proposed changes and validation results before they decide whether to apply the repair.
The goal is to move beyond an AI chatbot that suggests code and toward a tool that can provide evidence that a proposed fix actually works.

Who would pay for it?
RepoMedic is designed for freelance developers, independent programmers, students, and small development teams who regularly troubleshoot existing projects.

For freelancers maintaining multiple client repositories, reducing repetitive debugging work can save valuable time.

My long-term plan is to explore a free local version alongside paid features for advanced repair workflows and developer teams.

The current project is being developed as a local application. It requires the appropriate backend dependencies, MySQL, and a compatible Qwen model running through Ollama.

I plan to demonstrate the complete workflow using a deliberately broken JavaScript or TypeScript repository, from the initial diagnostic to the proposed patch and validation results.

Code
GitHub repository: https://github.com/Uncooperativecase225/repomedic

The project uses a modular architecture with separate frontend, backend, AI integration, repository analysis, and repair components.

The repository includes setup documentation and instructions for running the application locally.

How I Built It
I chose a stack that combines familiar web technologies with local AI inference.

Technology stack
Frontend: React, TypeScript, Vite, Tailwind CSS, and shadcn/ui.
Backend: Java and Spring Boot.
Database: MySQL with Spring Data JPA and Hibernate.
AI model: Qwen 3.5 9B.
AI runtime: Ollama.
Repository analysis: Git, TypeScript diagnostics, ESLint, and npm.
Repair isolation: Git worktrees.
Database migrations: Flyway.
How the system works
The React frontend communicates with the Spring Boot backend through REST APIs.

When a developer starts a scan, the backend inspects the selected repository and collects diagnostic information from the available development tools.

Relevant error messages and source context are then sent to Qwen 3.5 9B through Ollama.

The model generates a diagnosis and proposes a repair. The backend validates the proposed changes and can apply them in an isolated Git worktree before running the relevant checks.

MySQL stores repository metadata, scan history, diagnostics, repair proposals, and validation results.

The developer can then review the proposed changes and decide whether to apply them to the original repository.

An important architectural decision is that the AI model does not determine whether a repair succeeded. The actual build, lint, and test results provide that evidence.

Why Does Open Innovation Matter?
I wanted RepoMedic to make local AI useful for a real development problem rather than use an open-weight model as a thin wrapper around a chatbot.

Repositories can contain proprietary source code, client business logic, internal APIs, and configuration details. Sending all of that information to an external AI service may be undesirable for some developers and organizations.

By using Qwen 3.5 9B through Ollama, RepoMedic can perform its AI inference locally, provided the model and its dependencies are installed on the user's machine.

This creates several opportunities.

Privacy through local inference

Repository context can remain on the developer's machine rather than being sent to a third-party model API. Local inference does not eliminate every security risk, but it reduces the need to transmit source code externally.

Control over model selection

The AI layer can be designed to support alternative compatible models. Developers can experiment with different models and quantizations without rebuilding the entire application.

Reduced dependence on per-request API charges

Once the local runtime and model are installed, inference does not require paying a separate hosted-model API fee for each request. Hardware, electricity, and maintenance still have costs.

Freedom to experiment

I can evaluate different prompts, context-selection strategies, and model configurations against the same diagnostic cases.

For example, I want to compare how different local models handle dependency conflicts, TypeScript errors, and broken build configurations.

A practical hybrid architecture

RepoMedic combines AI reasoning with conventional development tools. The model proposes a solution, while Git, compilers, linters, and test commands help verify it.

This is where I believe open innovation is especially valuable: developers can inspect the workflow, choose their model, and adapt the system to their own development environment.

Final Thoughts
RepoMedic started with a simple observation: developers often spend too much time understanding and fixing routine project failures.

AI can help explain those failures, but an explanation is not the same as a working repair.

My goal is to build a tool that connects local AI reasoning with real development tools and verifiable results.

Using an open-weight model makes it possible to explore that workflow while retaining greater control over source code, model selection, and inference costs.

The next step is to evaluate RepoMedic against a repeatable set of broken repositories and measure how often its proposed repairs actually pass validation.

Build locally. Diagnose intelligently. Verify every repair.

Hacktoberfest #OpenSourceAI #Ollama #Qwen #Java #SpringBoot #React #DeveloperTools

NatureLens — An AI That Tells You to Touch Grass.

Ranit Das — Thu, 08 Oct 2026 22:15:26 +0000

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

What if your phone could help you notice the world instead of distracting you from it?

We spend hours looking at screens to discover things that are literally sitting outside our windows.

A bird on a branch.

A strange leaf.

A mushroom beside a trail.

A flower you've walked past a hundred times.

So I built NatureLens — a local-AI-powered outdoor field guide designed around one simple idea:

Touch grass. Notice more.

Instead of asking people to search the internet every time they see something interesting, NatureLens turns their phone into an interactive field guide.

Point your camera at something.

Observe it.

Let local AI help you understand it.

Then go outside and look again.

🌱 What I Built

NatureLens is a mobile-first PWA + desktop companion for outdoor exploration.

It combines your phone's camera and location capabilities with local multimodal AI to create an exploration loop:

See → Identify → Investigate → Observe Again → Discover

The core experience

📸 Point your camera at something

Take a photo of a plant, insect, object, or other outdoor discovery.

🤖 Ask local AI what you're looking at

NatureLens sends the image to Gemma 4 E4B running locally through Ollama.

🧠 Get a confidence-aware identification

Instead of pretending AI is always certain, NatureLens communicates uncertainty and encourages verification.

🔎 Get evidence guidance

The app doesn't just say "that's probably X."

It gives you things to look for so you can investigate the identification yourself.

👀 Observe Again

Go back to the object.

Look closer.

Compare what you see with what the model suggested.

That's intentional.

The goal isn't to replace observation.

The goal is to make observation more interesting.

🤖 The AI Runs Locally

This is the part of NatureLens I'm particularly excited about.

Instead of sending every image to a proprietary cloud AI API, NatureLens uses:

Gemma 4 E4B + Ollama

The model runs locally on the user's computer.

             ┌─────────────────────┐
             │      Your Phone     │
             │                     │
             │  Camera + GPS + UI  │
             └──────────┬──────────┘
                        │
                        │ HTTPS
                        ▼
             ┌─────────────────────┐
             │   NatureLens App    │
             │      Next.js        │
             └──────────┬──────────┘
                        │
                        │ localhost
                        ▼
             ┌─────────────────────┐
             │       Ollama        │
             │                     │
             │    Gemma 4 E4B      │
             │  Multimodal Model   │
             └─────────────────────┘

For development and phone testing, the laptop acts as the local AI host.

The phone doesn't need direct access to Ollama.

It talks to the NatureLens application, which communicates with the locally running model.

That means the intelligence powering the experience can stay under the developer's control.

No AI API key is required for the core identification workflow.

No per-image API bill.

No requirement to upload every observation to a third-party AI service.

Just:

Your hardware + Ollama + Gemma 4 E4B.

🧠 Why Gemma 4 E4B?

NatureLens isn't just using Gemma because it's an AI model that can look at images.

The project is specifically designed around the idea of local multimodal intelligence.

Nature exploration is inherently visual.

A text-only model would require the user to describe what they're seeing:

"There is a small green insect with transparent wings sitting on a leaf..."

That's already defeating the purpose.

With a multimodal model, the interaction becomes:

Here. Look at this. What should I notice?

That's a much more natural interface for exploration.

Gemma 4 E4B makes that possible while keeping inference local through Ollama.

And that changes the architecture of the application.

Instead of:

Phone → Cloud API → AI → Phone

NatureLens can work around:

Phone → Your Computer → Local Gemma → Your Computer → Phone

The AI isn't some mysterious service somewhere on the internet.

It's a model running on your machine.

🗺️ More Than an Image Classifier

I didn't want NatureLens to become:

Upload image → AI gives species name → Done.

That would just be another AI wrapper.

So the application is built around exploration rather than identification.

🧭 Discovery Map

Your discoveries can be associated with locations and explored through a map interface.

📍 GPS Capture

Observations can include where they happened, turning individual discoveries into a personal field journal.

🔍 Confidence-Aware Identification

The AI isn't treated as an unquestionable source of truth.

If the visual evidence isn't strong enough, NatureLens encourages another observation.

🧩 Evidence Guidance

The application can tell you what visual characteristics to inspect to validate an identification.

🔄 Observe Again

One of the most important interactions in the app.

Instead of ending the experience after an AI answer, NatureLens sends you back outside.

🕵️ Mystery Mode

Don't immediately reveal everything.

Explore first.

Guess.

Then reveal.

📝 AI Field Journal

Your observations can be transformed into natural field-journal entries using the local AI workflow.

🎯 Outdoor Quests

NatureLens can generate small four-step exploration quests.

For example:

Find something with an unusual texture.
Photograph it.
Look for three visual characteristics.
Compare your observation with the AI's hypothesis.

The AI becomes a guide, not the destination.

📱 Built for the Phone

The interface is intentionally mobile-first.

The intended interaction isn't:

Sit at your desk → upload a photo → read an AI response.

It's:

Walk outside → see something → take out your phone → investigate.

NatureLens is an installable PWA, so the experience can feel much closer to a native mobile application.

The desktop interface acts as the companion environment for exploring discoveries, reviewing observations, and developing the application.

🛠️ How I Built It

The stack is deliberately modern but relatively lightweight:

Frontend

Next.js 16
React 19
TypeScript
Tailwind CSS 4
Lucide React

Local Data

IndexedDB
Dexie

This lets NatureLens keep exploration data locally instead of requiring a traditional cloud database for the core experience.

Maps

Leaflet
OpenStreetMap

AI

Ollama
Gemma 4 E4B

Architecture

                         NATURELENS
                              │
             ┌────────────────┴────────────────┐
             │                                 │
       Mobile Explorer                  Desktop Explorer
             │                                 │
       Camera / GPS                         Dashboard
             │                                 │
             └──────────────┬──────────────────┘
                            │
                      Next.js App
                            │
                 ┌──────────┴──────────┐
                 │                     │
             IndexedDB             Local Vault
                 │                     │
                 │              .naturelens/
                 │                     │
                 └──────────┬──────────┘
                            │
                       AI Analysis
                            │
                          Ollama
                            │
                     Gemma 4 E4B

🌍 Why Does Open Innovation Matter?

This project would be very different if the only option were a closed AI API.

Open models make it possible to experiment with a different question:

What happens when AI becomes part of the user's own environment instead of another cloud dependency?

For NatureLens, that matters because the application deals with:

Camera images
Personal observations
Location information
Field journals
Exploration history

Running the model locally gives developers and users more control over where inference happens.
It also makes experimentation dramatically easier.
I can change the model.
I can change the prompt.
I can change the inference pipeline.
I can inspect what is happening.
And I don't have to build the entire project around someone else's API billing model.
Gemma 4 E4B isn't just a component inside NatureLens.
It makes the project's local-first AI architecture possible.

🔥 The Interesting Part: AI That Sends You Away From the Screen

Most AI applications are optimized for keeping you inside the application.

🎮 A Typical NatureLens Session

Imagine you're walking through a park.
You notice something strange growing beside a tree.

01 — Discover

You open NatureLens.
📸 Capture an image.

02 — Identify

Gemma 4 E4B analyzes the image locally.

03 — Question

NatureLens gives you a likely identification with confidence information.

04 — Investigate

The application tells you what characteristics to look for.

05 — Observe Again

You physically inspect the object.

06 — Record

Save the discovery with its location and notes.

07 — Keep Exploring

NatureLens generates another small exploration challenge.
And suddenly...
You aren't scrolling through your phone anymore.
You're using it to pay attention to the world around you.

💻 Code

The entire project is open source:

GitHub:
https://github.com/Uncooperativecase225/naturelens

The repository contains the complete NatureLens application, including the local AI integration and setup instructions.

🧪 Local Setup

You can run NatureLens without a paid AI API.

1. Install Ollama

Install Ollama on your computer.
Then download Gemma 4 E4B:

ollama pull gemma4:e4b

Test it:

ollama run gemma4:e4b

2. Clone NatureLens

git clone YOUR_REPOSITORY_URL
cd naturelens

3. Install dependencies

npm install

4. Configure the local AI

Create .env.local:

OLLAMA_URL=http://127.0.0.1:11434
OLLAMA_MODEL=gemma4:e4b

5. Start NatureLens

npm run dev

Then open:

http://localhost:3000

That's it.
Your AI inference is running locally.

📲 Taking It Outside

For phone testing, the development machine can expose the Next.js application through a temporary HTTPS tunnel.

The architecture becomes:

Phone
  ↓
HTTPS
  ↓
Cloudflare Tunnel
  ↓
Next.js on Laptop
  ↓
Ollama
  ↓
Gemma 4 E4B

This lets you actually take the interface outside and use the phone camera and GPS while the model remains on your computer.

For a real deployment, this would be replaced with an appropriate production hosting/local-edge architecture.

🔐 Privacy by Design

NatureLens is designed around a local-first architecture.

The core AI workflow does not require sending observations to a commercial AI API.

Local exploration data can be stored using IndexedDB, with an optional local vault.

That makes the project particularly interesting for applications involving personal observations and potentially sensitive location data.

Of course, users should still understand that when using a temporary public development tunnel, the web application itself is reachable through that tunnel.

Development tunnels are not a substitute for production security architecture.

⚠️ One Important Limitation

Gemma 4 E4B is an AI model.
That means its identification can be wrong.
NatureLens deliberately does not treat AI output as ground truth.
Especially with plants, fungi, insects, and potentially dangerous wildlife:
AI identification should be treated as an observation aid, not a safety authority.
Don't eat something because an AI said it's edible.
Don't approach wildlife because an AI said it's harmless.
Don't treat an AI-generated species identification as scientific confirmation.
The model helps you notice and investigate.
It doesn't replace expertise.

🧠 My Biggest Takeaway

Building NatureLens changed how I think about AI applications.
The easiest way to build an AI product is often:

Put a text box in front of an API.
But multimodal local models open a much bigger design space.
You can build experiences around:
seeing, listening, moving, observing and interacting with the physical world.
That's what I wanted to explore with NatureLens.

Not another chatbot.
Not another productivity assistant.
Not another application designed to maximize screen time.
Something that uses AI to encourage you to leave the screen behind.

🌿 Touch Grass. Notice More.

There are millions of things outside that we've stopped noticing.
NatureLens is my attempt to build a small bridge between local AI and the physical world.

And at the center of that bridge is Gemma 4 E4B — running locally, looking at the world through your camera, and helping turn ordinary walks into small investigations.

The ultimate success condition isn't:

"How long did you use NatureLens?"

It's:

"What did you notice after you put your phone down?"

🌿 Touch grass. Notice more.

🧑‍💻 My Agent Session

https://chatgpt.com/share/6ac80fbd-0574-83ee-bb79-b8cf54297cb4

This section documents the development session and AI-assisted building process used while creating NatureLens.

🏆 Prize Categories

Open-Source AI
Local AI / Open-Weight Models
Gemma / Google AI
Developer Tools / AI Applications

👥 Team

Built by: @ranit_das_2005

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

NatureLens — Touch grass. Notice more.