DEV Community: AryanSharma9917

LazySort AI: Drop the mess and let local Gemma sort it out

AryanSharma9917 — Tue, 20 Oct 2026 11:33:26 +0000

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

What I Built

I built LazySort AI, a local-first file organizer for the folder everyone keeps promising to clean “later.”

Give it a cluttered folder and LazySort will:

scan the files without following unsafe symlinks,
extract a limited amount of useful text,
ask a locally running Gemma model what each file represents,
propose a category, subcategory, and descriptive filename,
explain each suggestion and assign a confidence level,
wait for the user to approve or edit the plan, and
safely organize only the approved files.

It is deliberately not another extension-based sorter. A traditional rule can see that two files are PDFs; it cannot tell that one is an invoice and the other is a project report. LazySort uses the meaning of the document to decide where it belongs.

The people who get to be lazier are anyone with an overgrown Downloads folder: developers, students, freelancers, and people who would rather do almost anything than open and rename forty mystery documents.

The safety rule is simple:

Gemma suggests → LazySort validates → the user approves → LazySort moves

The model never receives direct filesystem access. LazySort never deletes files, never overwrites an existing file, and records completed operations so the last organization run can be undone.

Demo

The repository includes a fictional sample folder at demo/upload-this-folder, so the workflow can be demonstrated without exposing personal documents.

The demo covers selecting a folder, checking that Gemma is ready, reviewing its explanations and confidence, editing and approving suggestions, organizing the files, confirming that zero files were deleted, and undoing the run.

Code

AryanSharma9917 / lazysort-ai

LazySort AI

Drop the mess. Let AI sort it out.

LazySort is a local-first file organizer that uses Gemma 3 through Ollama to understand messy files, propose meaningful folders and names, and let you approve every change. It is a submission project for the Hacktoberfest 2026 Week 3: Slow and Steady challenge.

Instead of opening, identifying, renaming, and sorting files one by one, select a folder and review the organization plan Gemma prepares. LazySort never deletes files.

Why open-source AI?

File names and document contents can be personal. When OLLAMA_BASE_URL points to localhost, inference happens on your machine: there is no mandatory proprietary AI API, no analytics, and no permanent storage of extracted content. You can also swap the configured Ollama model. If you configure a remote Ollama endpoint, extracted information is sent to that server—local inference is not an absolute privacy guarantee.

Features

Semantic classification and descriptive renaming…

View on GitHub

Repository: github.com/AryanSharma9917/lazysort-ai

The project is open source under the MIT License. The README includes installation instructions, architecture notes, a safe demo guide, API documentation, security limitations, and testing instructions.

How I Built It

LazySort is a Python application with a focused web dashboard rather than a chatbot interface.

The main components are:

FastAPI for the local application and validated API endpoints
Gemma 3 4B as the open-weight reasoning model
Ollama for local model serving
Pydantic for strict structured-output validation
PyPDF and python-docx for bounded document extraction
HTML, CSS, and vanilla JavaScript for the review dashboard

Understanding files with Gemma

For each file, LazySort sends Gemma the filename, MIME type, size, and a bounded content excerpt. Gemma returns JSON containing:

{
  "category": "Finance",
  "subcategory": "Expenses",
  "suggested_filename": "october-expenses.csv",
  "reason": "The file contains dated vendor and expense amounts.",
  "confidence": "high"
}

Pydantic validates every response. If Gemma returns malformed output, LazySort retries once. If the second answer is still invalid, the file is marked as low-confidence and sent to manual review instead of being silently acted upon.

Treating documents and model output as untrusted

File content can contain prompt injection, so the classification prompt explicitly labels filenames and extracted text as untrusted data—not instructions. It tells Gemma to ignore commands inside documents and never suggest deletion, shell commands, absolute paths, or unsupported details.

Prompt instructions are only one layer. Deterministic application code enforces the real security boundary:

category, subcategory, and filename are sanitized separately;
traversal sequences, path separators, control characters, and reserved names are rejected;
the original extension must be preserved;
every source and destination must remain under the selected root;
symlinks and protected operating-system directories are rejected;
file extraction has configurable byte and character limits; and
conflicts receive deterministic numeric suffixes instead of overwriting data.

Preview, approval, and undo

The default behavior is a dry run. The dashboard shows the current file, proposed destination, suggested name, explanation, and confidence before anything changes. The user can edit suggestions and approve files individually or together.

Execution is a separate API request. Every successful move is written to a transaction log containing filesystem metadata only—never document contents. If one operation fails, LazySort reports the partial result accurately. Undo walks the completed transaction in reverse and refuses to overwrite a file that has appeared at the original location.

The automated suite currently contains 25 passing tests covering scanning, extraction limits, ignored directories, path sanitization, traversal rejection, symlinks, structured-output parsing, malformed responses, retries, conflict naming, moves, partial failures, undo, API validation, and safe folder uploads. Ollama is mocked in automated tests, so CI does not need to download a multi-gigabyte model.

Why Does Open Innovation Matter?

The files we postpone organizing are often the files we least want to send to an unknown server: invoices, resumes, meeting notes, expense records, and personal documents.

With the default localhost Ollama configuration, Gemma processes extracted content on the user's own machine. LazySort requires no proprietary model account, has no mandatory per-request fee, performs no analytics, and does not permanently store extracted document text. The model is controlled by an environment variable, so users can inspect the stack and experiment with another compatible local model instead of waiting for a vendor to expose an option.

Open innovation also shaped the safety design. Because the entire classification and execution boundary is visible in the repository, users can inspect exactly what reaches the model, which paths are rejected, and why the model cannot directly manipulate files. That is especially important for a tool whose purpose is handling private local data.

There are honest limitations. Local inference speed depends on the user's hardware. Scanned PDFs need OCR, which is not included yet. Images and unsupported formats currently rely on filename and metadata rather than full multimodal analysis. Model suggestions can still be wrong, which is why human approval is a required part of the architecture.

If a user changes OLLAMA_BASE_URL to a remote server, extracted information is sent to that server. “Local-first” describes the default configuration; it is not a promise of absolute privacy under every configuration.

The Lazy Payoff

The included demonstration organizes four fictional files into useful destinations such as:

Finance/Expenses/october_expenses.csv
Meeting Notes/Project Management/project_willow_meeting_notes.txt
Project Management/Briefs/project-brief-willow.md
documents/personal_profile/morgan_example_profile.txt

Without LazySort, each file requires the same repetitive loop: open it, work out what it is, choose a folder, invent a useful name, create the folder, and move the file. LazySort turns that into one review screen.

For the demonstrated four-file run:

files classified and organized: 4
manual open/read/rename/move loops replaced: 4
files deleted: 0
organization runs that can be undone: 1

The payoff grows with the mess, while the important decision remains with the user: approve the plan, then get back to doing something better.

Prize Categories

Best Use of Gemma — Gemma 3 4B is the semantic engine at the center of every organization proposal and runs locally through Ollama.

PitchPilot: Turning Rough Client Briefs into Professional Proposals with Local Gemma AI

AryanSharma9917 — Sun, 18 Oct 2026 16:43:44 +0000

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

What I Built

PitchPilot is an open-source AI proposal and quote generator for freelancers.
It turns an informal client brief into a complete project proposal, concise
quote, or client-facing email. The result remains editable so the freelancer
can review every claim, price, and timeline before sharing it.

Freelancers repeatedly translate client messages into scope, deliverables,
milestones, assumptions, pricing, and next steps. PitchPilot reduces that
administrative work without removing the freelancer's responsibility for the
final offer. Drafts can be copied, downloaded as Markdown, or printed and saved
as PDF.

The project fits the Side Hustle theme because it solves a focused problem
directly connected to earning freelance income. It is intended for independent
developers, designers, consultants, marketers, and other professionals who
regularly prepare project proposals.

Demo

PitchPilot is demonstrated locally so client briefs can remain on the user's
computer. The repository includes everything needed to run the demo:

git clone https://github.com/AryanSharma9917/pitchpilot-ai.git
cd pitchpilot-ai

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

ollama pull gemma3:4b
uvicorn app.main:app --reload

After starting the application, open the local address displayed by Uvicorn in
your browser.

The interface includes a Load demo details button that fills the form with
a fictional client brief. Choose Full proposal, Quick quote, or Client email,
then generate a draft. Local generation speed depends on the computer's CPU,
GPU, and available memory.

The demo workflow is:

Confirm that the configured Gemma model is ready.
Load the fictional example or enter a client brief.
Select the desired output type.
Generate and review the structured draft.
Edit a section, then copy, download, or print the result.

Code

AryanSharma9917 / pitchpilot-ai

PitchPilot

Open-source AI proposal and quote generator for freelancers.

Turn a rough client brief into a professional proposal in minutes, with model inference through locally running Gemma and Ollama. No proprietary cloud LLM API is required.

Local inference is not the same as a blanket offline or privacy guarantee Installing Ollama and downloading the model requires internet access. A remotely configured Ollama host receives the prompt.

The problem

Freelancers repeatedly translate informal client requests into a project scope, deliverables, milestones, pricing, assumptions, and client communication. PitchPilot turns that routine drafting into a structured, editable starting point while leaving the freelancer in control of the final proposal.

What it does

Generates a full proposal, quick quote, or client-facing email.
Uses a configurable Ollama model, defaulting to Gemma 3 4B (gemma3:4b).
Requests structured JSON and validates it with mode-specific Pydantic schemas.
Makes one correction attempt if model output is malformed…

View on GitHub

View the PitchPilot repository on GitHub

How I Built It

PitchPilot uses:

Gemma 3 4B as the open-weight language model
Ollama for local inference
FastAPI for the backend API
Pydantic for input and model-output validation
Vanilla HTML, CSS, and JavaScript for the interface
Pytest for automated testing
GitHub Actions for continuous integration

The browser sends project information to the local FastAPI application. The
backend validates the request, creates a mode-specific prompt, and sends it to
Gemma through Ollama's local API.

PitchPilot requests structured JSON but does not assume every model response
will be correct. Separate Pydantic schemas validate proposals, quotes, and
emails. If Gemma returns malformed or incomplete data, the application makes
one bounded correction attempt. If the second response remains invalid, the
user receives a clear error rather than unreliable output.

The application reports whether Ollama is unavailable, the configured model is
missing, or the complete AI workflow is ready. Generated text is inserted into
the page through text-based DOM APIs instead of being interpreted as HTML.

Request-size and brief-length limits are enforced. The application rejects
missing input, unexpected response fields, blank structured values, unavailable
models, timeouts, and invalid model output. Its 27 automated tests cover request
and response validation, readiness reporting, prompt construction, JSON
extraction, correction retries, generation routes, pricing labels, error
handling, and page loading.

When the user has not supplied a budget, generated prices are explicitly
presented as estimates. The interface reminds users to verify scope, rates,
taxes, timelines, and contract terms before sending a draft.

Why Does Open Innovation Matter?

Client briefs can contain private business information. Requiring every brief
to pass through a proprietary cloud API gives users less control over where
that information is processed.

PitchPilot uses Gemma through Ollama, making it possible to run the core
generation workflow on hardware controlled by the freelancer. No proprietary
language-model API is required. Users can inspect the entire generation path,
change the configured Ollama-compatible model, and modify the prompts,
validation, and retry behavior.

Local inference is not a blanket privacy or offline guarantee. Installing
Ollama and downloading Gemma initially requires internet access. A remotely
configured Ollama endpoint receives the prompt, and local machines or reverse
proxies may have their own logging behavior.

There are practical tradeoffs: local models require compatible hardware and
storage, generation can be slower, and output quality can vary between models.
Despite those tradeoffs, open-weight models give freelancers meaningful control
over model selection, cost, deployment, and data handling.

Development Process

I used GitHub Copilot during the initial development of PitchPilot. When that
development session stopped working, I audited the repository, restored its
missing validation models, tested the complete application, and finished its
documentation and continuous-integration workflow.

The final project includes a GitHub Actions workflow that installs the
application and runs its automated tests on pushes and pull requests.

Prize Categories

Best Use of Gemma
Best Use of GitHub Copilot

TouchGrass: A Local AI That Plans Your Next 15 Minutes Outside

AryanSharma9917 — Sun, 11 Oct 2026 15:53:49 +0000

Here’s a draft you can paste into DEV. Replace the Demo placeholder with a real video or deployed link before publishing. I’ve kept the outdoor-testing claims honest.

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

What I Built

I built TouchGrass, a local-first outdoor activity planner. It asks how much time you have, what kind of activity you’d like, your energy level, where you’re going, and any interests or limitations. It then creates a timed outdoor mission.

The idea is to make planning a short step, not another reason to stay on your phone. Once the mission is ready, you can switch to a simple phone-free view, read the steps at a glance, and put your phone away.

Demo

[https://youtu.be/0tacnZu845k]

The demo should show the preferences form, a mission generated by the local model, and the phone-free view.

Code

TouchGrass on GitHub

How I Built It

TouchGrass uses a small vanilla HTML, CSS, and JavaScript frontend with a FastAPI backend. The backend sends the user’s preferences to a locally running Ollama instance using the qwen2.5-coder:3b model.

The model returns structured JSON for the mission: preparation, timed steps, safety notes, and a completion message. The backend validates the response, including checking that the step durations add up to the selected time. If the model returns an invalid response, the app retries once and then reports an error instead of presenting it as a valid plan.

The app doesn’t require an account or save mission preferences. Model generation runs through the configured Ollama server; downloading the model requires internet, but inference can run locally once it’s installed.

Why Does Open Innovation Matter?

Running the model locally made it possible to build the core feature without relying on a proprietary cloud AI API. The user’s preferences can stay on their own machine when Ollama is configured locally, and the model can be changed through configuration rather than tied to one hosted service.

That comes with trade-offs: users need to install Ollama and download a model, and local models can return generic or unsuitable suggestions. TouchGrass validates the mission structure and includes safety reminders, but those safeguards can’t guarantee that an activity is right for every person or situation.

OpsBuddy: An Open-Source AI Troubleshooting Assistant for DevOps

AryanSharma9917 — Sun, 04 Oct 2026 14:54:22 +0000

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

What I Built

I built OpsBuddy for my best friend, who is learning DevOps.

When a Kubernetes pod keeps restarting, a Docker container exits unexpectedly, or a CI/CD run fails, it can be difficult to understand which part of the error matters or what to check first.

OpsBuddy is a small troubleshooting assistant for those situations. You choose the area you are working on, paste an error or diagnostic output, and ask for help understanding it. It returns a plain-language summary, possible causes, recommended next checks, and commands to review.

My friend has tried the app and shared feedback with me while I was building it. I'm keeping their name and personal details private.

OpsBuddy is designed to help someone decide where to investigate next, rather than claim a definitive diagnosis. It does not connect to a Kubernetes cluster, execute commands, or make changes to a system.

Demo

Demo video: [https://youtu.be/ZXHzGoTD3U0]

The demo shows a sanitized troubleshooting example being entered into OpsBuddy and the resulting explanation, possible causes, and suggested checks.

The application currently runs locally, so there is no public deployment link. The video demonstrates the complete working flow instead.

Code

View OpsBuddy on GitHub

How I Built It

OpsBuddy has a small browser-based interface and a FastAPI backend. The backend sends the submitted diagnostic text to Ollama running on the same computer and asks the open-weight model to produce a structured troubleshooting response.

The default model is qwen2.5-coder:3b.

While testing the application, I found an interesting problem. The model suggested restarting a Kubernetes pod even though the prompt specifically asked it to stick to read-only troubleshooting. That made it clear that prompt wording alone was not enough.

I added backend safeguards that remove known system-changing actions and common shell commands from suggested steps. I also limit displayed commands to a small read-only allowlist and ask for more information when the input is too vague to support a useful analysis.

These checks are safeguards, not a guarantee that every response is correct or suitable for every environment. OpsBuddy never executes the suggested commands, and users should review them before deciding whether to run them.

Diagnostic text is sent to the local Ollama service. Users should still remove passwords, tokens, API keys, and other secrets before sharing logs or diagnostic output.

Why Does Open Innovation Matter?

Troubleshooting logs and diagnostic output can contain information that people may not want to send to a hosted AI service.

With the default setup, OpsBuddy sends the request to Ollama running on the same computer instead of sending it to a hosted AI API. Once Ollama and the model are installed, the analysis can run locally.

Using an open-weight model also means the project is not tied to one proprietary AI API. A user can choose another compatible local model and decide what works best on their own machine.

The trade-off is that local inference requires enough computing resources, and the model can still produce incorrect or overconfident answers.

For this project, open innovation made it possible to build a local-first troubleshooting tool that gives the person using it more control over their diagnostic data and model choice.

I Built a DevOps CLI Tool in Go – Meet Codewise-CLI

AryanSharma9917 — Mon, 14 Jul 2025 07:49:52 +0000

Hey Devs,

I'm Aryan, and over the past few weeks, I’ve been working on a project that turned into something pretty useful — a command-line tool I named Codewise-CLI. If you're into DevOps, YAML/JSON shenanigans, or just want to automate tedious tasks, you might find it handy too.

Let me take you through what Codewise-CLI is, why I built it, and how you can use it.

Why Codewise?

Let’s be real — dealing with formats like .yaml, .json, or .env in DevOps workflows can get annoying. And if you’re switching between projects and need Dockerfiles, GitHub Actions workflows, or Kubernetes manifests often, you end up copy-pasting a lot.

So, I thought:

“Why not build a CLI that automates these bits and lets me focus on writing actual code?”

And that’s how Codewise was born.

What Can Codewise-CLI Do?

Codewise is a terminal-first tool written in Go using Cobra and Viper, and it does quite a few things:

✅ Convert between JSON ↔ YAML
✅ Convert .env to JSON
✅ Encode/decode Base64 strings
✅ Scaffold Dockerfiles for different languages
✅ Generate Kubernetes manifests
✅ Render .tpl templates using .yaml input
✅ And more features coming soon...

Getting Started

To try it out, simply clone the repository, build the tool, and move it to your path:

git clone https://github.com/aryansharma9917/Codewise-CLI.git
cd Codewise-CLI
go build -o codewise main.go
sudo mv codewise /usr/local/bin/

Now, just run:

codewise --help

A Few Quick Examples

Convert JSON to YAML:

codewise encode --input input.json --output output.yaml --type JTY

Generate a Dockerfile:

codewise generate dockerfile --output Dockerfile

Render a GitHub Actions .tpl file using values:

codewise template --template template.tpl --values values.yaml --output rendered.yaml

🐳 Docker Support

You can also run Codewise-CLI via Docker:

docker pull aryansharma04/codewise-cli:latest
docker run --rm aryansharma04/codewise-cli:latest --help

Roadmap

Here’s what’s coming next for Codewise:

✅ TOML/XML conversions
✅ Interactive prompts (instead of just flags)
✅ Auto-generate GitHub workflows
✅ --force flag to overwrite existing files

Final Thoughts

This is just the beginning. I built Codewise to solve a problem I faced often — and if it helps even a few more developers speed up their DevOps work, that’s a win.

Feel free to check it out, use it, break it, suggest improvements, or open a PR if you’re feeling generous!

🔗 GitHub: https://github.com/aryansharma9917/Codewise-CLI

Thanks for reading!

Containerization with Docker: A Beginner’s Guide

AryanSharma9917 — Wed, 09 Oct 2024 05:32:24 +0000

Containerization has transformed modern software development, making it easier to build, ship, and run applications. One of the most popular tools for containerization is Docker. This guide will introduce you to Docker and provide a step-by-step tutorial on creating and managing Docker containers.

What is Docker?

Docker is an open-source platform that automates the deployment of applications inside lightweight containers. These containers package an application with all its dependencies, ensuring that it runs consistently across different environments. The main benefits of using Docker include:

Portability: Applications can run on any machine that has Docker installed.
Isolation: Each container operates independently, preventing conflicts between applications.
Scalability: Containers can be easily replicated or scaled up/down based on demand.

Getting Started with Docker

Prerequisites

Before diving into Docker, ensure you have the following installed:

Docker Desktop (available for Windows, macOS, and Linux)
Basic knowledge of command-line interface (CLI)

Step 1: Building a Docker Image

A Docker image serves as a blueprint for your container. It contains everything needed to run your application, including code, libraries, and dependencies.

Create a Dockerfile: This file contains instructions for building your image. Here’s a simple example for a Node.js application:

   FROM node:20-alpine
   WORKDIR /app
   COPY . .
   RUN npm install --production
   CMD ["node", "index.js"]

Build the Image: Navigate to the directory containing your Dockerfile and run the following command:

   docker build -t my-node-app .

Step 2: Creating and Running a Container

Once you have built your image, you can create and run a container from it.

Run the Container: Use the following command to start your container:

   docker run -d -p 3000:3000 --name my-running-app my-node-app

-d: Runs the container in detached mode (in the background).
-p 3000:3000: Maps port 3000 on your host to port 3000 in the container.
--name my-running-app: Assigns a name to your container.

Verify the Container is Running: Check if your container is up and running using:

   docker ps

Step 3: Managing Docker Containers

Docker provides several commands to manage your containers effectively.

List All Containers:

  docker ps -a

Stop a Running Container:

  docker stop my-running-app

Remove a Container:

  docker rm my-running-app

Step 4: Accessing Your Application

After running your application in a container, you can access it via your web browser at http://localhost:3000. This URL corresponds to the port mapping you set up earlier.

Conclusion

Docker simplifies the process of developing and deploying applications by utilizing containerization technology. With this beginner's guide, you should now be able to create and manage Docker containers effectively. As you grow more comfortable with Docker, consider exploring advanced features such as Docker Compose for managing multi-container applications or integrating Docker into CI/CD pipelines.

By adopting Docker in your development workflow, you'll enhance both productivity and consistency across environments, paving the way for smoother deployments and better collaboration among teams.

Citations:
[1] https://www.hostinger.in/tutorials/docker-start-a-container
[2] https://docs.docker.com/reference/cli/docker/container/create/
[3] https://learn.microsoft.com/en-us/visualstudio/docker/tutorials/docker-tutorial
[4] https://docs.docker.com/compose/gettingstarted/
[5] https://docs.docker.com/get-started/workshop/02_our_app/
[6] https://learn.microsoft.com/en-us/dotnet/core/docker/build-container?pivots=dotnet-8-0&tabs=linux
[7] https://docker-curriculum.com
[8] https://www.geeksforgeeks.org/docker-tutorial/

My First Hacktoberfest...

AryanSharma9917 — Thu, 05 Nov 2020 09:46:00 +0000

✨My First Hacktoberfest... ✨

Introduction

This was my first Hacktoberfest and I thoroughly enjoyed it. I exchanged 4 pull requests as per the guidelines and learned how to use GitHub.

Background

The idea and inspiration were given by my elder sister who is a software engineer and has been associated with the fest for the past 3 years. I have been taught by her how to proceed with the fest and what all has to be done.

Progress

I am a beginner. I like the way GitHub has helped me to get my self introduced to various open-source code over the platform I wish to explore it more and would continue contributing to it.

Contributions

I contributed in a project on CALCULATOR. I initially added percentage, average, power, remainder and sent pull requests for the same. Therefore, I completed 4 pull request successfully.

Reflections

Overall, I enjoyed the Hacktoberfest 2020, it was really nice working with the open-source for the first time. I will surely participate again in the coming years. I have learned how to use GitHub successfully and also how to work with open-source. Yes, I have made a few connections while working with the project CALCULATOR @riya-17 @RakshitKumar04 . I am looking forward to building some new projects and contribute to GitHub and take help from GitHub for my upcoming project completion.