DEV Community: Mayukh Jyoti Sarkar

Lazy Coder

Mayukh Jyoti Sarkar — Sun, 25 Oct 2026 13:38:54 +0000

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

What I Built

"Future you doesn't remember what past you wrote."

Every developer knows the struggle of reopening a side project after two weeks away—or cloning an unfamiliar repository—and having to inspect dozens of files just to remember how everything works.

What was I working on before I closed my laptop?
Where is the actual entry point?
How do I install and run this project?
Which TODOs, FIXMEs, and HACKs did past-me leave behind?
Where should I start if I want to modify a particular feature?

LazyCoder is a local-first AI coding companion that helps developers understand, navigate, and resume existing codebases without manually investigating every file.

Instead of building another generic chatbot with a code-themed interface, I built a repository-aware developer workbench combining deterministic static analysis, local code retrieval, persistent storage, and open-weight AI through Ollama.

LazyCoder supports local models such as qwen2.5-coder:1.5b-base and qwen2.5-coder:7b, depending on the model available on the user's machine.

What can it do?

1. 📊 AI Project Overview

Generate a structured architectural briefing covering the project's purpose, technologies, directory structure, important source files, entry points, dependencies, tests, documentation gaps, and suggested starting points.

The report is grounded in discovered repository files, with local SQLite caching to avoid unnecessarily regenerating results.

2. 🔍 Multi-Mode File Explainer

Understand unfamiliar code using seven explanation modes:

Beginner-friendly summary
Line-by-line walkthrough
Functions and APIs
Advanced technical explanation
Potential bugs and edge cases
Refactoring suggestions
Dependencies and imports

3. 💬 Ask Your Codebase

Ask natural-language questions about the repository, such as:

Where is task creation handled?
How does the application store data?
Which files are involved in authentication?
Where might this bug originate?

Local TF-IDF retrieval identifies relevant code snippets and provides file and line-range references to help developers investigate the actual implementation.

4. 🛠️ Technical Debt and TODO Hub

Discover unfinished work by locating comments such as TODO, FIXME, BUG, HACK, and OPTIMIZE.

LazyCoder organizes these findings and calculates a technical-debt score to help prioritize areas that need attention.

5. ⏱️ Session Catch-up

Get back into a project by inspecting Git working-tree changes, recent commits, and recently modified files.

Instead of trying to remember everything from your previous coding session, you get a useful starting point for continuing your work.

6. 🚀 Smart Run Guide

Inspect project manifests such as requirements.txt, pyproject.toml, package.json, Cargo.toml, and go.mod to help identify installation, testing, and execution commands.

The goal is to make returning to an unfamiliar project less intimidating.

Demo

Live application: https://lazycoder.streamlit.app/
GitHub repository: https://github.com/mayukhjyotisarkar/Hacktoberfest/tree/main/WEEK3

The deployed Streamlit version demonstrates LazyCoder's repository-analysis workflows using its bundled sample project and deterministic fallback capabilities.

For local AI inference, run LazyCoder on your machine with Ollama and a compatible model installed.

This distinction matters: the cloud demonstration and the local Ollama-powered experience have different execution environments.

Code

mayukhjyotisarkar / Hacktoberfest

The complete implementation is available in the WEEK3/ directory.

The project is organized into focused modules:

WEEK3/app.py — Streamlit interface and developer workbench.
WEEK3/lazycoder/safety.py — Filesystem safety checks, secret filtering, and file-size limits.
WEEK3/lazycoder/scanner.py — Repository scanning, language detection, manifests, entry points, tests, and TODO extraction.
WEEK3/lazycoder/local_ai.py — Local Ollama integration and model communication.
WEEK3/lazycoder/overview.py — Evidence-grounded project overview generation.
WEEK3/lazycoder/explainer.py — Multi-mode source-code explanation.
WEEK3/lazycoder/query_engine.py — Code chunking, TF-IDF retrieval, and repository-aware question answering.
WEEK3/lazycoder/session_tracker.py — Git activity and working-session context.
WEEK3/lazycoder/todo_tracker.py — Technical-debt scoring and unfinished-work tracking.
WEEK3/lazycoder/run_guide.py — Project setup and execution guidance.
WEEK3/lazycoder/storage.py — SQLite persistence and caching.
WEEK3/tests/ — Automated tests.

The implementation details above describe the intended module responsibilities; consult the repository for the current source code and test coverage.

How I Built It

LazyCoder combines deterministic repository analysis with local AI inference. Each component has a specific responsibility, rather than sending an entire codebase to a language model and hoping for the best.

1. Deterministic Repository Scanning

The scanner discovers source files, programming languages, project manifests, dependencies, entry points, tests, and unfinished-work markers.

This provides a structured foundation for subsequent AI operations.

The scanner is designed to exclude generated directories and sensitive files, enforce file-size limits, and avoid executing repository code.

2. Filesystem Safety and Privacy

Repository inspection requires access to potentially sensitive source code, so filesystem safety is a core part of the design.

The safety layer is intended to validate paths against the selected repository root, filter credential files, ignore generated directories, and restrict the files that can be inspected.

LazyCoder is designed to analyze code without automatically modifying or executing the user's project.

3. Local Code Retrieval

For repository-aware questions, LazyCoder divides source files into overlapping chunks and indexes their contents using scikit-learn's TfidfVectorizer.

When a developer asks a question, the retrieval engine selects relevant snippets and passes their contents and line ranges to the answering component.

This keeps the context focused on potentially relevant code instead of overwhelming the model with the entire repository.

4. Open-Weight AI Through Ollama

LazyCoder uses Ollama as its local inference runtime.

Compatible models can analyze retrieved code, explain unfamiliar functions, summarize architectural relationships, and help developers investigate potential problems.

The application can also use deterministic fallback behavior when local inference is unavailable, allowing supported analysis workflows to remain useful without an active model.

5. Persistent Local Storage

SQLite stores reusable analysis results and cached explanations.

Caching helps reduce repeated work when revisiting the same project. Repository state and file-content hashes can be used to determine whether cached information remains relevant.

Together, these components create a workflow in which deterministic analysis establishes the facts, retrieval supplies relevant evidence, and the language model provides contextual interpretation.

Why Does Open Innovation Matter?

For a coding assistant that inspects source code, open-weight models and local inference are more than a technical preference. They change the privacy, cost, and accessibility of the tool.

🔐 1. Your Code Can Stay on Your Machine

Developers regularly work with proprietary projects, personal experiments, client code, and unreleased products.

Sending entire repositories to an external AI service may be undesirable or prohibited.

By using Ollama for local inference, LazyCoder can analyze source code without requiring a remote LLM API.

The local-first architecture is especially valuable when privacy matters more than access to the largest available model.

💸 2. No Per-Token API Bills

Repository exploration can involve repeated scans, file explanations, and dozens of follow-up questions.

With a locally installed model, inference does not require paying a third-party provider for each token. Users still need to account for their hardware, electricity, and storage costs.

This makes repeated experimentation more accessible to students, independent developers, and open-source contributors.

📴 3. Useful Without an Internet Connection

Once the application, dependencies, and model are installed, its local analysis and inference workflows can operate without an internet connection.

That means developers can work during a campus Wi-Fi outage, while travelling, or in environments where network access is restricted.

Initial setup and model downloads may still require connectivity.

🔄 4. Freedom to Choose Your Model

Different developers have different hardware constraints.

A smaller model can be appropriate for a laptop with limited memory, while a larger coding model may provide better results on a more powerful machine.

Ollama makes it possible to experiment with different compatible open-weight models without redesigning the entire application around a proprietary API.

🧩 5. Transparent, Composable Building Blocks

LazyCoder combines open-source components such as Python, Streamlit, scikit-learn, SQLite, and Ollama.

Developers can inspect the implementation, change the retrieval strategy, replace the model, or extend the scanner to support additional languages and frameworks.

Open innovation makes a coding assistant more adaptable, more accessible, and easier to keep under the developer's control.

My Agent Session

I used AI-assisted development to help design and implement LazyCoder's repository-analysis workflows.

The focus was on building a practical developer tool rather than a generic conversational interface.

If a DevRelay Agent Session is available, its link can be added here.

The Lazy Payoff

Imagine returning to a project you haven't touched in a month.

Before LazyCoder, you might:

Run git status and git log to reconstruct your previous work.
Search the repository for TODO and FIXME comments.
Open dependency manifests to remember the required packages.
Trace imports across multiple files to understand how a feature works.
Read unfamiliar functions before attempting even a small change.

With LazyCoder, you can start with a project overview, inspect unfinished work, review recent changes, ask questions about relevant code, and generate setup guidance from the project's manifests.

Instead of treating every return to an old repository as a fresh investigation, you have a structured starting point.

The aim is simple: spend less time remembering your code and more time improving it.

And because LazyCoder uses local retrieval, persistent caching, and an optional local language model, its workflows can be adapted to different projects and hardware configurations.

Prize Categories

Challenge: Hacktoberfest Open-Source AI Challenge — Week 3: Slow and Steady.

Additional partner prize categories can be listed here if they apply to the final submission.

Built for developers who love writing code but don't particularly enjoy rediscovering code they wrote three weeks ago.

PaperPilot!

Mayukh Jyoti Sarkar — Wed, 14 Oct 2026 14:00:23 +0000

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

I Built PaperPilot: Turning Previous-Year Question Papers into an AI-Powered Revision Plan

As an engineering student, I've learned that preparing for semester exams isn't just about studying the syllabus. It's also about figuring out what to prioritize.

Previous-year question papers can be incredibly useful, but going through multiple PDFs, finding repeated questions, identifying recurring topics, and organizing everything into a revision plan takes time.

So I decided to build something to make that process easier.

Meet PaperPilot, an AI-assisted exam preparation tool that turns previous-year question papers into a structured revision workflow.

My goal was simple: help students spend less time organizing their study material and more time actually studying.

What I Built

PaperPilot lets students upload previous-year question papers and helps them:

Extract questions from PDFs, including scanned pages when OCR is configured.
Find exact and similar questions across multiple papers.
Identify recurring questions and analyze topic frequency.
Review evidence linked to the original source papers.
Generate a revision checklist and export useful results.

Instead of asking a generic AI chatbot to predict what might appear in an exam, PaperPilot focuses on evidence from the papers students already have.

It doesn't promise to predict future question papers. It helps students make more informed revision decisions using historical question patterns.

I built it primarily for engineering students, but the same idea could be useful for tutors, coaching centres, and students preparing for other examinations.

The side-hustle opportunity

Imagine a student with five years of question papers and only a few days left before an exam. PaperPilot helps turn that collection into something easier to navigate and revise.

A possible business model would be a free basic version with optional paid features for larger paper collections, advanced analytics, or additional revision tools.

That opportunity still needs validation. I haven't established that students are willing to pay, and finding out whether the tool genuinely saves them time is the next important step.

Demo

Try PaperPilot: https://mayukhjyotisarkar-hacktoberfest-week2app-bn7o6x.streamlit.app/

The intended workflow is straightforward:

Upload your papers.
Find recurring and similar questions.
Explore topic frequencies and source evidence.
Build your revision plan.

The hosted demo depends on the capabilities and dependencies available in its deployment environment. The local application supports optional Ollama-based AI inference and OCR when the required software is installed.

Code

GitHub repository: https://github.com/mayukhjyotisarkar/Hacktoberfest/tree/main/WEEK2

PaperPilot is built with Python and Streamlit, with separate components for document extraction, question processing, similarity analysis, data storage, and optional AI features.

How I Built It

I wanted to understand how the different pieces of an AI application work together instead of building just another interface around a remote AI API.

The first important decision was to keep the core question-analysis pipeline deterministic.

PaperPilot extracts text from PDFs, normalizes question text, uses TF-IDF and cosine similarity to compare questions, groups similar questions, and analyzes their recurrence across papers. SQLite stores the question-bank data, while Streamlit provides the user interface.

For the open-weight AI component, I integrated Qwen2.5-Coder 1.5B through Ollama to support optional features such as topic labeling for existing question groups and revision-note generation.

The AI doesn't replace the underlying question-matching system. Instead, it adds another layer to the workflow. Keeping these responsibilities separate means the core analysis doesn't depend on an AI response for every operation.

I also added OCR support for scanned PDFs. The application attempts ordinary text extraction first and can use OCR on pages that don't yield enough text. This introduced another practical challenge: Python dependencies alone aren't enough when an application also relies on external software such as Tesseract.

Along the way, I worked on the interface, local storage, setup scripts, dependency documentation, and automated tests.

One of my biggest takeaways was that building an AI application isn't just about choosing a model. The surrounding engineering — handling messy documents, validating outputs, managing dependencies, and explaining errors — is what makes the model useful to someone.

Why Does Open Innovation Matter?

For PaperPilot, open innovation means having more control over how AI is used, where it runs, and how the application can evolve.

A hosted AI API can be convenient, but repeated requests can introduce ongoing costs and a dependency on a provider's pricing, availability, and service policies.

Using an open-weight model through Ollama gives PaperPilot another option: run supported AI features locally instead of sending every request to a hosted model.

That matters in a few ways.

More control over recurring costs

Once the model is downloaded, local inference doesn't require a separate hosted-model API payment for every request. Hardware, electricity, and setup still have costs, but the economics can be more predictable for a small student-focused tool.

A more private local workflow

When students run PaperPilot locally and process their documents locally, their papers don't need to be sent to a third-party AI API for its local AI features. For students working with personal notes or institutions handling sensitive documents, that distinction can matter.

Freedom to experiment

I can evaluate alternative models, adjust prompts, and change how AI-generated labels and notes work without tying the entire application to one hosted provider.

Independence from a single AI service

The core similarity and recurrence analysis works separately from the language model. That reduces the extent to which the primary workflow depends on an external AI service being available.

Open-weight models aren't automatically better at every task. They have hardware requirements, setup complexity, and their own quality limitations. Model licences also matter, and the permissions associated with a particular model should be checked before redistributing or commercially using it.

There's another important distinction: the public Streamlit demo runs in a remote hosting environment. Its privacy and offline characteristics aren't the same as running the application entirely on your own computer.

For me, the value of open innovation isn't simply that a model is available to download. It's that I can make deliberate choices about cost, privacy, deployment, and model behavior while building a tool for a specific problem.

What I Learned

PaperPilot taught me that a useful AI product doesn't need to put a language model at the centre of every operation.

Sometimes, traditional text-processing techniques are better suited to the core task. Sometimes, a language model adds value on top. Knowing where to use each approach is part of the engineering.

I also learned that supporting real documents is messy. PDFs can contain unusual layouts, scanned pages, broken text extraction, and inconsistent question formatting. A feature that works on a clean sample isn't automatically ready for every student's material.

And passing tests is only one milestone. A tool can be technically functional without necessarily being useful enough for someone to adopt or pay for.

What's Next?

The next milestone for PaperPilot is real-world validation.

I want to see how it performs on different university question papers, whether students find the recurring-question analysis useful, and what they would change after using it.

From there, I can prioritize improvements based on actual needs rather than adding features just because AI makes them possible.

PaperPilot started as a way to solve a problem I understood personally. Building it has also been an opportunity to explore open-weight AI, local inference, document processing, and the engineering required to turn an idea into a usable application.

The goal now is simple: make it genuinely useful to the students it was built for.

Built for students. Powered by Python, traditional text analysis, and optional local open-weight AI.

Raid Outside!

Mayukh Jyoti Sarkar — Sun, 11 Oct 2026 12:13:06 +0000

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

What I Built

Raid Outside turns a short break into a co-op, tabletop-RPG-style outdoor quest. Pick a vibe, set how much time you have, enter a nearby public place, and get a mission with a story hook, clue, objective, ending, and collectible badge.

It’s for people who spend too much of the day at a desk and want a more fun reason to meet friends and go outside than another reminder to take a walk. The app is designed to make the screen a quick briefing before the real adventure.

The prototype has a complete solo flow from creating a raid through completing it. Party codes and joining are currently demo interactions; there isn’t a server syncing players across devices yet.

Demo

No hosted demo yet. You can run the prototype locally using the instructions in the README.

Code

Raid Outside source code

How I Built It

Raid Outside is built with React, TypeScript, Vite, and Tailwind CSS. For mission generation, it connects to a configurable OpenAI-compatible endpoint intended for a locally hosted open-weight model, such as one served by Ollama. The model receives the selected vibe, time, effort, and place context, then returns structured JSON for the mission. The app checks that the required fields are present and falls back to hand-written missions if the model is unavailable or its response is invalid.

The prototype also uses OpenStreetMap’s Nominatim service to look up the place name entered by the player. That lookup can return a broad mapped place classification; it does not verify individual features on site. The app doesn’t request GPS. Settings, completed raids, and badges are stored in browser local storage.

Why Does Open Innovation Matter?

The open-model approach lets the person running the app choose and change the model, adjust the mission prompt, and run inference locally instead of sending mission details to a closed AI provider. That matters for a location-based activity: if the model endpoint is local, the place context used to generate a quest stays on the player’s device.

This isn’t fully offline today: the local model must be installed and running, and place-name lookup uses Nominatim over the internet. If AI generation is unavailable, the app can still create a raid using its hand-written fallback missions.

I haven’t benchmarked it against a closed model. The advantage I’m aiming for is control: being able to swap models and shape the mission behavior without tying the app to one hosted AI provider.

Delicious Eats: a food-delivery concept built for a friend

Mayukh Jyoti Sarkar — Sun, 04 Oct 2026 14:16:42 +0000

Delicious Eats: a food-delivery concept built for a friend

What I Built

I built Delicious Eats, a food-delivery website concept for a friend who loves finding good food without the hassle. It brings a few restaurant options together with ratings, estimated delivery times, and a clear way to start browsing.

It’s currently a front-end prototype. The restaurant listings and ordering flow show the concept; search, ordering, and live delivery tracking aren’t connected yet.

Demo

Try the live demo

Code

View the project on GitHub

How I Built It

I built the site with HTML and CSS, and used Gemma 4 as the open-weight AI model during development. The page includes featured restaurant cards, food imagery, a search bar, a call to action, and a “How It Works” section. The layout adapts to smaller screens.

Why Does Open Innovation Matter?

Open innovation makes it possible to experiment with capable AI models and adapt them to a specific project without relying entirely on a closed API. Using Gemma 4 helped me explore how open models can support building a practical, friend-focused web experience.