DEV Community: Yadnesh Kulkarni

GhostTrace 👻: Finding the Ghost in System Logs with Local AI

Yadnesh Kulkarni — Tue, 27 Oct 2026 09:18:53 +0000

Hacktoberfest Open-Source AI Challenge: Ghost in the Machine Submission

A system error rarely explains itself. You get a timestamp, an error message, maybe a warning that appeared five minutes earlier, and the familiar task of figuring out what went wrong.

What if a local AI assistant could help you investigate those clues without sending your logs to a hosted AI service?

That idea led me to build GhostTrace, a local AI-powered system-log investigator using Python, Flask, Ollama, and Gemma 3 4B.

🔗 GitHub repository: https://github.com/Yadnu14/GhostTrace

👻 What is GhostTrace?

GhostTrace is a small web application that takes system log text and uses AI to produce a structured investigation report.

Instead of returning an unstructured paragraph, it aims to help developers separate what the logs actually show from what might have caused the problem and what to investigate next.

The current prototype includes:

Local AI inference: Gemma 3 4B runs through Ollama on the user's machine.

Log analysis: Users can supply log text for investigation.

Structured reports: Findings, possible causes, and recommended investigation steps are organized into a readable report.

Fallback analysis: Basic keyword-based analysis can provide a fallback when AI inference is unavailable.

Evidence-focused prompting: The model is instructed to avoid presenting unsupported assumptions as facts.

Browser-based interface: Flask serves the application, with HTML, CSS, and JavaScript providing the interface.

Safer report rendering: The frontend escapes HTML before applying Markdown-style formatting to generated reports.

GhostTrace is not a replacement for a monitoring platform or a professional incident-response workflow. It is an experiment in making log investigation more accessible with local AI.

🧠 Why Gemma 3 4B and Ollama?

I wanted the AI component to run locally instead of building another application that depends on a remote model API.

The architecture is intentionally simple:

The application sends the supplied logs to the locally running Ollama service, which uses Gemma 3 4B to generate the report.

If AI inference is unavailable, GhostTrace can fall back to simpler keyword-based analysis.

This approach keeps the application small enough to understand and modify without introducing a complicated cloud architecture.

🔐 Why local AI matters

Logs can contain more than technical errors. Depending on the application, they may include internal hostnames, file paths, account identifiers, tokens, or other sensitive information.

Sending logs to an external service may be inappropriate in some environments.

With GhostTrace's default local setup, inference runs through Ollama on the user's machine rather than a hosted AI API. After the model has been downloaded, the inference workflow does not need to send prompts to a remote model provider.

That distinction matters.

Local inference provides more control over where data goes, but it does not automatically make every application secure. Logs still need to be handled carefully, and the application must be configured and deployed responsibly.

Running an open-weight model also gives developers more flexibility. They can experiment with prompts, inspect the surrounding application code, and explore alternative models without rebuilding the entire project around a proprietary API.

For me, that flexibility is one of the most useful parts of open innovation: the ability to learn by building, changing, testing, and improving the system yourself.

🛠️ The practical engineering behind it

Getting a model to generate text is only one part of building a useful tool.

The surrounding application still needs to handle input, communicate with the model, present results clearly, and behave sensibly when something fails.

GhostTrace addresses a few of those concerns:

Evidence before conclusions

The model is prompted to distinguish observations from hypotheses. A missing heartbeat, for example, may indicate a service problem, but it does not prove the precise root cause or that the issue has been resolved.

A fallback path

If local AI inference is unavailable, basic keyword-based analysis can still offer limited assistance. This fallback is deliberately simple and should not be confused with a full diagnostic engine.

Safer output handling

AI-generated content should not automatically be trusted as HTML. GhostTrace escapes HTML before rendering report formatting, reducing the risk of generated text being interpreted as executable markup.

Keeping the scope controlled

GhostTrace analyzes supplied log text. It does not automatically execute system commands or modify system files. This keeps the prototype focused on investigation rather than giving an AI unrestricted control over a machine.

These are modest design choices, but they matter when building tools that interpret technical information.

🚀 Try GhostTrace locally

The project uses Python, Flask, Ollama, and Gemma 3 4B.

First, install Python and Ollama from their official websites:

Python: https://www.python.org/

Ollama: https://ollama.com/

Then clone the repository:

git clone https://github.com/Yadnu14/GhostTrace.git
cd GhostTrace

Create and activate a virtual environment in Windows PowerShell:

python -m venv .venv
..venv\Scripts\Activate.ps1

Install the dependencies:

python -m pip install -r requirements.txt

Download the model:

ollama pull gemma3:4b

With Ollama running, start the application:

python app.py

Open http://127.0.0.1:5000 in your browser and supply log text for investigation.

The initial model download requires an internet connection. Once downloaded, the model can perform inference locally.

⚠️ What GhostTrace cannot do yet

This project is a prototype, and its limitations are important.

AI-generated reports can be incorrect or incomplete.

Keyword-based fallback analysis is limited and may miss relevant context.

The current workflow depends on users supplying log text; it is not an automated monitoring agent.

It does not replace established observability tools, alerting systems, or forensic investigation.

It has not been presented as a production-ready or security-audited application.

A plausible explanation is not the same as a verified root cause. Any findings should be checked against the original logs.

🌍 The bigger idea: open innovation

The most interesting part of GhostTrace is not simply that an AI model can summarize logs.

It is that the complete workflow can be explored locally: the interface, the Python application, the prompts, the model integration, and the fallback logic.

Open-weight AI makes experimentation more accessible. Local inference can reduce dependence on external APIs, while open-source application code gives developers room to inspect and change how the system behaves.

That does not mean local models are always more capable than hosted models, or that open systems have no trade-offs. Model quality, hardware requirements, maintenance, and reliability still matter.

But for a project like GhostTrace, local inference is a practical fit for exploring AI-assisted troubleshooting while keeping the architecture understandable and the data flow under the developer's control.

🎃 Final thoughts

GhostTrace started with a simple question: can a small local AI model help make sense of system logs without sending them to a remote AI service?

The result is a working prototype built around Gemma 3 4B, Ollama, and Flask. There is plenty left to improve, but the project demonstrates how open-weight AI can be integrated into a practical developer tool without requiring a large cloud stack.

For the Ghost in the Machine challenge, GhostTrace is my take on finding something useful hiding inside the noise.

Sometimes the ghost is just an error message waiting for a closer look.

Explore the code: https://github.com/Yadnu14/GhostTrace

Built for the Hacktoberfest Open-Source AI Challenge, Week 4.

# LazySort AI: Let Local AI Handle the Folder Cleanup You Keep Putting Off

Yadnesh Kulkarni — Tue, 20 Oct 2026 17:45:03 +0000

My Downloads folder has a talent for becoming a digital storage room. PDFs, screenshots, source files, archives and files named final_v2_revised_reallyfinal all end up living together.

The solution sounds simple: organize everything.

Then the folder stays messy for another three weeks.

For Week 3 of the Hacktoberfest Open-Source AI Challenge, themed Slow and Steady, I built LazySort AI: a local-first file organizer that uses open-source AI to suggest categories and cleaner filenames before moving anything.

The goal was simple: automate the tedious part without letting automation take over.

What does LazySort AI do?

LazySort AI lets you select a folder and scan its files. It suggests a category, such as Documents, Images, Videos, Audio, Archives or Code, and can propose a cleaner filename.

You see the suggestions in a preview. You can edit them, deselect files, and approve the changes yourself.

Nothing moves during the scan.

The application only moves selected files after explicit confirmation, and it is designed not to delete files or overwrite existing destination files.

Why use local AI?

A small organizing task does not need to become another cloud integration.

LazySort AI can use Gemma 3 through Ollama, running on the user's own computer. That means the model inference can happen locally instead of requiring a hosted AI API.

This matters when filenames or folder structures reveal personal information. A project folder, a document title or even a badly named screenshot can tell a surprisingly detailed story about its owner.

Keeping inference local reduces the need to send that information to an external AI provider. LazySort AI uses filenames and file metadata for its suggestions rather than uploading file contents for analysis.

Local inference is not a universal privacy guarantee. The application, model runtime and operating system still need to be configured and maintained responsibly.

Open-source AI should be practical

Open innovation is not only about building another chatbot.

It also means making AI available for small, everyday tasks that people can inspect, adapt and run themselves. Open models and local tools give developers room to experiment without requiring a paid API account for every prototype.

For this project, the useful part of AI is not that it can make an impressive paragraph. It is that it can reduce a repetitive task while leaving the user in charge.

The application also has a rule-based fallback. If Ollama is unavailable, file extensions can still provide basic category suggestions. The project should remain useful even when the model is not.

Safety before automation

File management is one of those areas where an incorrect automated decision can turn a small inconvenience into a terrible afternoon.

That is why LazySort AI uses a preview-and-approval workflow:

Scan the chosen folder.
Generate category and filename suggestions.
Review and edit the proposed changes.
Select the files to organize.
Confirm before applying the changes.

The intended workflow is non-recursive, avoids overwriting existing destination files, and does not delete files.

The suggestions are still suggestions. Users should review them and keep backups of important data.

Built with

Python and Flask for the local web application
HTML, CSS and JavaScript for the interface
Ollama for running a model locally
Gemma 3 (gemma3:4b) for AI-powered suggestions

The application is designed to run on a personal computer and does not require a hosted AI API key.

What I learned

The interesting challenge was not simply connecting an AI model to an application. It was deciding how much control the model should have.

For a file organizer, fully automatic action is not necessarily a better user experience. A fast mistake can be worse than a slow manual process.

A preview, editable suggestions and explicit approval make the tool more predictable. The rule-based fallback also helps avoid making the entire application dependent on the availability of a model.

Try it

GitHub repository: https://github.com/Yadnu14/LazySort-AI

The repository contains the application source, setup instructions, tests and MIT license.

LazySort AI is a small experiment in a simple idea: AI should handle tedious work without making users surrender control over their own files.

Sometimes the best automation is the kind that gives you your time back and then gets out of the way.

💼 GigCraft AI: Turn Client Briefs into Actionable Project Plans

Yadnesh Kulkarni — Tue, 13 Oct 2026 10:45:26 +0000

What if a freelancer could turn a messy client brief into a structured proposal without sending their project details to a hosted AI service?

That question inspired me to build GigCraft AI, a local AI assistant that helps freelancers organize client requirements, draft proposals, plan deliverables, consider pricing, and identify what needs clarification before a project begins.

Instead of building another general-purpose chatbot, I wanted to explore a focused tool for a real workflow: going from "Here's what my client wants" to "Here's how I can deliver it."

🔗 GitHub Repository: https://github.com/Yadnu14/GigCraft-AI

🎯 The Problem

Starting a freelance project involves much more than writing code or delivering a design.

Freelancers often need to:

Understand an incomplete or unclear client brief.

Write a professional proposal.

Break the work into deliverables and milestones.

Think through pricing and deadlines.

Identify missing information before committing to the project.

Decide what to do next.

Handling all of this manually takes time. Relying on a hosted AI service can also introduce API costs and additional privacy considerations.

GigCraft AI explores a practical alternative: a dedicated freelance assistant powered by a model running locally.

✨ What Can GigCraft AI Do?

The application focuses on five parts of the freelance workflow:

Feature

Purpose

📝 Proposal drafts

Generate a starting point for a client-facing proposal

📋 Deliverables and timelines

Organize the expected work and project milestones

💰 Pricing suggestions

Help structure pricing considerations

❓ Missing requirements

Identify details that may need clarification

🚀 Next steps

Turn the brief into an actionable plan

The generated content is a starting point, not a substitute for professional judgment. Freelancers should review the output, confirm assumptions, and agree on scope with their clients.

🛠️ The Technology Behind It

GigCraft AI combines a lightweight web application with local AI inference.

Python: Application logic.

Flask: Backend web framework.

HTML, CSS and JavaScript: User interface and interactions.

Ollama: Runs the language model locally.

Gemma 3:4B: Generates responses from client briefs.

GitHub: Hosts the source code and project documentation.

I chose this stack to keep the application straightforward to run and easy for other developers to inspect.

⚙️ How It Works

The workflow follows a simple sequence:

Enter a brief: The freelancer describes the client's requirements.

Prepare the request: The Flask backend formats the request for the local model.

Generate the response: Ollama runs Gemma 3:4B to produce the requested content.

Review the result: The freelancer uses the generated proposal and planning information as a starting point for the project.

The application uses Ollama's local generation API, so it does not require a third-party hosted inference API key.

🔐 Why Local AI?

Client briefs can contain business requirements, budgets, project ideas, and other information that freelancers may prefer to keep private.

Running inference locally offers several advantages:

More control over data: Prompts are processed by the local Ollama instance rather than being sent to a hosted inference provider by this workflow.

No hosted inference API key: The application can generate responses without requiring a paid external AI API.

Open-weight model experimentation: Developers can explore and adapt the application around a model they can run on their own hardware.

A more self-contained workflow: Once the required model is downloaded, inference can run locally without depending on a hosted model endpoint.

Local inference still has trade-offs: the model requires storage and computing resources, and the application depends on Ollama being available. Local processing also does not automatically guarantee the security of the entire device.

🌱 Why Open Innovation Matters

Open innovation gives developers the freedom to explore existing technologies, combine them in new ways, and share what they build.

For independent developers and freelancers, that flexibility can make a real difference. Not every useful AI application needs a closed platform, a recurring API bill, or a dependency on one hosted provider.

With GigCraft AI, I brought together an open-weight model, local inference tooling, and a Python web application to explore a focused use case.

The project is released under the MIT License, allowing others to study, modify, and redistribute the code under its terms.

I see this project as a small example of what becomes possible when developers can experiment with AI tools and turn them into practical applications.

🧪 Running the Project

To run GigCraft AI locally, you need:

Python

Ollama

The gemma3:4b model

The application's Python dependencies

After installing the dependencies and downloading the model, start the application:

python app.py

Open the local interface at:

http://127.0.0.1:5000

The complete source code and setup instructions are available in the repository.

📦 View the source code and README on GitHub

🏁 Final Thoughts

GigCraft AI is my attempt to make local AI useful for a specific, everyday problem: reducing the friction between receiving a freelance brief and planning the work.

The project brings together:

A practical freelance workflow.

A Python and Flask web application.

Local inference with Gemma 3:4B.

An open-source implementation under the MIT License.

The goal isn't to let AI make every decision for a freelancer. It's to help them organize the initial work so they can spend more time evaluating the project, communicating with the client, and delivering something valuable.

Have you built an application using local AI models? I'd love to hear what use cases you've explored.

🔗 Project: https://github.com/Yadnu14/GigCraft-AI

# 🌿 FieldNote AI: An AI That Tells You to Put Your Phone Down

Yadnesh Kulkarni — Tue, 06 Oct 2026 13:51:26 +0000

What if an AI application had one goal that was completely opposite to keeping you on the screen?

Instead of asking you to chat with it for another hour, what if it gave you a reason to close the laptop, put your phone away, and go outside?

That was the idea behind FieldNote AI, my project for the Hacktoberfest Open Source AI Challenge: Touch Grass.

🌱 The Idea

AI is becoming increasingly good at keeping us inside digital environments.

We use AI to write, search, study, code, create images, plan things, and answer questions. All of that can be useful, but it also creates an interesting problem:

What if we used AI to help us spend less time using technology?

FieldNote AI is a local-AI micro-adventure journal designed around exactly that idea.

The user provides three simple inputs:

Available time
Energy level
Outdoor setting

Gemma then creates a small outdoor mission with three things to observe.

The important part is what happens next:

The app tells you to leave the screen.

You go outside, complete the mission, observe your surroundings, and come back when you're finished.

You then write down what you actually noticed, and local AI turns that reflection into a short field note.

The AI is not the destination.

The real world is.

🧭 The Experience

The entire experience follows five steps:

1. Plan

Choose your available time, energy level, and outdoor setting.

For example, someone might have:

20 minutes • Low energy • Nearby park

FieldNote AI uses those choices to generate a suitable micro-adventure.

2. Go Outside

The application enters Screen Exit Mode.

The user is encouraged to put their phone away and actually complete the mission instead of continuing to interact with the application.

3. Observe

The generated mission includes three observation challenges.

These are designed to make the user slow down and pay attention to things they might normally ignore.

4. Reflect

After returning, the user writes a short reflection describing what they actually experienced.

5. Keep the Memory

Gemma transforms the user's reflection into a concise field note.

The generated note is grounded in what the user actually wrote rather than inventing details about their experience.

↓ SCREENSHOTS HERE ↓

📸 See It in Action

🤖 Why Gemma?

FieldNote AI uses Google Gemma 3:4b through Ollama.

The model runs locally on the user's computer, which means the project does not need a paid AI API or a cloud AI account.

There are two main AI interactions:

Mission Generation

Gemma takes the user's available time, energy, and outdoor setting and creates a personalized micro-adventure.

Field Note Generation

Gemma takes the user's reflection and turns it into a polished field note while being instructed to stay grounded in the details provided by the user.

This local approach was especially important to the project because the experience can contain personal observations and reflections.

🔒 Why Local AI?

The project was designed with a local-first approach.

The core AI generation happens through:

Browser → Flask → Ollama → Gemma → Flask → Browser

There is no requirement for a paid AI API.

There is no requirement for a cloud AI account.

The user's reflections do not need to be sent to a remote AI provider.

For a small personal journaling experience, that felt like the right approach.

🛠️ How I Built It

FieldNote AI was built using a deliberately simple stack:

HTML for the interface
CSS for the visual design
JavaScript for the interaction flow
Python + Flask for the backend
Ollama for local model inference
Gemma 3:4b for the AI generation

I wanted to keep the architecture simple enough that the project could be understood and run locally without a complicated setup.

The basic architecture looks like this:

User Choices
     │
     ▼
Flask Backend
     │
     ▼
Ollama Local API
     │
     ▼
Gemma 3:4b
     │
     ▼
Outdoor Mission
     │
     ▼
Screen Exit Mode
     │
     ▼
Real-World Experience
     │
     ▼
User Reflection
     │
     ▼
Gemma 3:4b
     │
     ▼
Field Note

🧠 One Challenge I Ran Into

One interesting problem appeared while testing the field-note generation.

A language model can naturally try to make writing more vivid by adding details.

That is normally useful.

For a journaling application, however, it creates a problem.

If a user says:

"I sat outside and noticed the sound of birds."

The AI should not turn that into:

"Golden sunlight filtered through the trees while cool wind moved the leaves."

Those details sound nice, but the user never said they happened.

So I changed the field-note generation prompt to make grounding a strict requirement.

The model is instructed to use only details explicitly present in the user's reflection and not invent objects, sounds, weather, sunlight, people, events, smells, or emotions.

That made the generated field notes much more appropriate for the purpose of the application.

🌍 Why This Fits "Touch Grass"

The challenge theme is simple:

Touch Grass.

FieldNote AI takes that literally.

Most digital products are optimized to keep users engaged for longer.

FieldNote AI is intentionally designed to break that loop.

The application exists to create a small reason to:

Close the laptop.

Put the phone away.

Go outside.

Pay attention.

The screen is only the starting point.

The actual experience happens away from it.

🔓 Why Open Innovation Matters

I also wanted the project to demonstrate that useful AI experiences do not always require a large cloud service or an expensive API.

With an open-weight model such as Gemma and a local runtime like Ollama, developers can experiment with AI applications where privacy, accessibility, and local processing matter.

Open tools also make experimentation easier.

A student with a laptop can take an idea, run a model locally, connect it to a small web application, and build something useful without first needing a production cloud infrastructure budget.

That is one of the things I find most interesting about the current open AI ecosystem.

📚 What I Learned

Building FieldNote AI taught me a few things beyond simply connecting an application to an AI model.

AI output needs boundaries

A language model can produce convincing text, but convincing does not always mean accurate.

For applications involving personal experiences, grounding the output is important.

The best AI interaction isn't always more interaction

The most interesting part of FieldNote AI is that the application intentionally asks the user to stop using it.

That changed how I thought about AI product design.

Simple architectures can still create interesting experiences

FieldNote AI does not require a huge stack.

A browser, Flask, Ollama, and Gemma are enough to create the complete experience.

🚀 Future Possibilities

There are several directions the project could take in the future:

Local storage for completed field notes
A personal collection of past adventures
More mission types
Accessibility and difficulty options
Optional weather-aware missions
Exporting field notes as a personal journal
Offline-first progressive web app support
Support for additional local AI models

For now, I wanted to keep the core experience focused rather than turning it into another complicated productivity application.

🔗 Project

The complete project is available on GitHub:

FieldNote AI

View the FieldNote AI repository on GitHub

The project can be run locally with Python, Flask, Ollama, and Gemma 3:4b.

🌿 Final Thought

AI does not always have to give us another reason to stare at a screen.

Sometimes it can do the opposite.

FieldNote AI is a small experiment in that direction:

Use AI to create the adventure.

Leave the screen behind.

Experience the world.

Come back and remember it.

Built for the Hacktoberfest Open Source AI Challenge: Touch Grass.

I Built a Local DBMS Study Buddy for My Friend Mayur

Yadnesh Kulkarni — Sun, 04 Oct 2026 09:03:09 +0000

My friend Mayur finds DBMS difficult because the notes are long, theory-heavy, and overwhelming to revise before exams.

So I built Mayur’s Study Buddy: a small web app that turns long DBMS notes into simpler revision material.

What it does

Mayur can paste a long DBMS paragraph into the app and choose one of two options:

Explain simply — creates an easy explanation, key revision points, and a real-life example.
Make a quiz — creates five practice questions with answers.

This makes the same notes less intimidating and gives him a faster way to revise.

How I built it

The project uses:

HTML for the page structure
CSS for the design
JavaScript for the buttons and interaction
Node.js for a small local server
Ollama with the gemma3:4b model for AI responses

Why open AI mattered

The AI is the core of this project.

I used the open-weight Gemma model through Ollama, running locally on the computer. That means Mayur’s notes are processed locally instead of being sent to a cloud AI service.

Using a local model also means the project can keep working without a paid AI API and can be changed to use another compatible model later.

What I learned

This is my first Hacktoberfest project. I learned that a useful project does not need to be huge. It can solve one real problem for one real person.

I also learned how to connect a simple website to a local AI model and turn a small idea into a working tool.

Try it yourself

The source code and setup instructions are available on GitHub:

https://github.com/Yadnu14/dbms-study-buddy

To run it locally:

Install Ollama.
Run ollama run gemma3:4b.
In the project folder, run node server.js.
Open http://localhost:3000.

Thanks for reading, and good luck