DEV Community: praniket01

👻 The Ghost in Your Organization Isn't a Bug. It's Your Hidden Talent.

praniket01 — Sun, 01 Nov 2026 04:02:38 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.

What I Built

Ever wondered how many talented employees are sitting inside an organization, waiting for the right opportunity?

Meet TalentMesh — a skill-based workforce allocation platform designed to uncover hidden talent within organizations.

In many companies, finding the right person for a project is still a manual process involving spreadsheets, endless conversations, and a lot of guesswork.

TalentMesh tackles this problem by connecting employee skills, experience, availability, and project requirements.

Its internal matching algorithm evaluates potential candidates using three factors:

Skills — 50%: How closely an employee's skills match the project requirements.

Availability — 30%: How much of the employee's capacity is available.

Experience — 20%: How well their experience aligns with project needs.

The result? A ranked list of matching candidates, helping managers discover talent that might otherwise remain invisible.

The platform also includes JWT-based authentication, role-based access control, project management, allocation requests, and an approval workflow.

My interpretation of Ghost in the Machine?

The ghost isn't artificial intelligence. It's the hidden potential already living inside your organization.

Demo

Live Demo: https://github.com/praniket01/TalentMesh

Code

GitHub Repository: https://github.com/praniket01/TalentMesh

Built with an open-source technology stack:

Frontend: Angular 21, TypeScript, Signals

Backend: ASP.NET Core / .NET

Database: PostgreSQL

Architecture: Microservices

Authentication: JWT and role-based authorization

How I Built It

TalentMesh follows a microservices architecture, separating responsibilities into independent services:

Identity Service: Authentication and authorization.

Employee Service: Employee profiles, skills, and availability.

Project Service: Project creation and skill requirements.

Matching Service: Candidate evaluation and ranking.

Allocation Service: Allocation requests, approvals, and rejections.

API Gateway: Central entry point for frontend requests.

The matching engine uses a weighted scoring algorithm rather than an AI model.

I deliberately focused on building an explainable, deterministic matching mechanism. Instead of asking a black box to recommend employees, the platform calculates scores using clearly defined business rules.

No LLM. No AI API calls. Just structured data, a matching algorithm, and a little engineering.

Why Does Open Innovation Matter?

TalentMesh is built using open-source technologies, making its architecture and matching logic accessible for developers to inspect, understand, extend, and improve.

Open innovation makes it possible to:

Customize matching strategies for different organizations.

Introduce new scoring factors and allocation policies.

Extend individual microservices independently.

Integrate future open-source AI models without locking the platform into a proprietary AI provider.

The goal is to build something developers can learn from, contribute to, and evolve together.

My Agent Session

Not applicable — no AI agent session was very less used in this project.

The Spirit of It

Every organization has a hidden talent pool.

Someone who has the exact skills needed for the next big project might be buried under a spreadsheet, assigned to unrelated work, or simply overlooked.

TalentMesh is my attempt to make that invisible talent visible.

Because sometimes, the best person for your next project isn't someone you need to hire.

They're already sitting somewhere in your organization. You just haven't found them yet. 👻

# 🦥 My Codebase Has 847 Files. My Brain Has 2 Remaining Tabs.

praniket01 — Sun, 25 Oct 2026 08:53:56 +0000

Meet CodeSloth — because `Ctrl + Click` is not a software architecture strategy.

Ever opened an open-source repo to make a tiny contribution and ended up questioning your career choices? Yeah, same.

💀 Problem Statement

Unfamiliar codebases are a maze of files, dependencies, APIs, and databases. Understanding how everything connects can take longer than the actual contribution.

🩹 Current Workaround

Open 37 tabs, chase imports, search for API routes, and pray the original developer left a comment. Spoiler: they didn't.

💡 Proposed Solution — CodeSloth

A local-first codebase explorer that turns GitHub repositories into:

🌳 Project Tree — Navigate the codebase without archaeological equipment.
🕸️ Dependency Graph — See which files depend on what.
🏗️ Architecture Flow — Visualize frontend → APIs → backend → databases.
🤖 Ask CodeSloth — Get AI-assisted code explanations using local Ollama models.

**💻 Source Code - https://github.com/praniket01/Codesloth

Demo
🎬 Live Demo: https://www.youtube.com/watch?v=cesLtzG88_s

Live Website: https://frontend-kappa-two-86.vercel.app/

⚙️ Working Model

Paste a public GitHub repository URL → CodeSloth indexes the codebase → explore its structure and connections → ask questions about the code using local AI.

Stack: Next.js · React Flow · FastAPI · SQLite · Ollama

🎯 The Mission

Make open-source contributions less intimidating by reducing the time spent understanding unfamiliar code and increasing the time spent building, fixing, and contributing.

The goal? Less spelunking. Fewer tabs. Faster pull requests.

Because life's too short to reverse-engineer an entire codebase just to fix one bug.

👉 Explore the demo, inspect the architecture, and let the sloth do the digging.

# 🚨 Oops, I Shipped a Secret. ChangeGuard Didn’t.

praniket01 — Sun, 18 Oct 2026 07:56:26 +0000

Challenge Intro

You know what’s fun?

Shipping code.

You know what’s less fun?

Realizing you just committed an API key, gave a Kubernetes container god mode, or turned your infrastructure into a security researcher’s weekend project. 💀

We have code reviews, CI pipelines, tests, and linting. Yet somehow, security issues still sneak into pull requests like they own the repository.

Meet ChangeGuard — because “it works on my machine” is not a security strategy.

What I Built

ChangeGuard is an open-source security scanner that catches risky changes before they become tomorrow’s incident report.

It helps developers detect security issues, review changes, and enforce security policies directly in their development workflow.

What it does:

🔑 Secret Detection: Finds suspicious hardcoded credentials before they get a permanent home in Git history.
☸️ Infrastructure Security: Detects risky Kubernetes and Terraform configurations. Because running containers in privileged mode should be a decision, not an accident.
🔍 Diff Risk Analysis: Highlights newly introduced security findings so developers can focus on what actually changed.
🚦 Policy-Based CI/CD: Integrates with GitHub Actions to fail checks when changes violate configured security policies.
📜 Scan History: Keeps a record of previous scans and findings. Apparently, “I thought we fixed that” isn't an audit trail.
🛠️ Configurable Security Policies: Lets teams define which findings should block a change.
🤖 Optional Local AI Explanations: Supports local Ollama-powered explanations, so developers can better understand security findings without necessarily sending code to a hosted AI service.

The goal isn't to replace security engineers. It's to stop making them discover privileged: true during a production incident.

Demo

🎬 Live Demo: https://drive.google.com/file/d/10Pg-emhwD1h8yTHWsbVniGPdvBexzevd/view?usp=drive_link

Live Website: http://change-guard-beta.vercel.app/

The ideal demo flow:

Introduce an insecure Kubernetes configuration.
Run ChangeGuard and inspect the detected risk.
Introduce a secret-like value and see how the scanner flags it while redacting sensitive evidence.
Review the scan history and policy decision.
Push a risky change and watch GitHub Actions enforce the configured policy.

Green checks are nice. Green checks that actually mean something are better.

Code

💻 GitHub Repository: https://github.com/praniket01/ChangeGuard

The project is built with a separate frontend and backend:

Frontend: Next.js, TypeScript, and a neon-inspired security dashboard.
Backend: Python, FastAPI, and Pydantic.
Security Analysis: Rule-based scanning for secrets and risky infrastructure configurations.
Persistence: SQLite-backed scan history and policy configuration.
CI/CD: Python scanning script integrated with GitHub Actions.
AI: Optional local Ollama integration for explanations.

How I Built It

I wanted to build something that fits into a developer's existing workflow rather than another dashboard that looks impressive and gets opened twice.

So, I built ChangeGuard around a simple idea: security checks should happen when code changes, not when someone finally notices the consequences.

The backend exposes API endpoints for scans, diff analysis, policy management, and history. The frontend provides a dashboard to interact with those features. A standalone scanner can also inspect repository changes in CI and return a failing exit code when the configured policy blocks the findings.

I added secret redaction to avoid echoing detected credential values into reports, and persistent storage for scan history and policies.

The scanner is deliberately designed as a practical first layer of defense. Its rule-based checks are transparent and easy to extend, while optional local AI explanations can help developers understand why a finding matters.

Is it a replacement for a full enterprise security platform? No.

Is it better than discovering a leaked credential after your repository has been starred by half the internet? Absolutely.

Why Does Open Innovation Matter?

Security shouldn't be a luxury feature reserved for teams with enormous budgets and dedicated security departments.

Open-source tools let developers inspect the rules, improve detection, report false positives, and adapt policies to their own environments.

ChangeGuard is my contribution to that ecosystem: a project that developers can learn from, extend, and use to make security a normal part of development rather than a last-minute ritual.

The more people who can improve the tool, the more edge cases we can catch—and the fewer production incidents have to become cautionary LinkedIn posts.

Final Note

ChangeGuard is built on a simple belief:

Your CI pipeline should be the bouncer at the door—not the person filing the incident report the next morning.

If you're building with Kubernetes, Terraform, or secret-heavy application configurations, give ChangeGuard a try, open an issue, or contribute a rule.

Let's make “works on my machine” a development milestone, not a security verdict. 🛡️

# 🌱 GrowWise: An AI Garden Coach That Wants You to Close This Tab and Touch Some Actual Grass

praniket01 — Sun, 11 Oct 2026 09:35:21 +0000

An AI gardening companion powered by a locally running, open-weight model. No API tokens. No cloud AI bill. Just plants, dirt, and a gentle reminder that your houseplants have been waiting for attention since your last software deployment.

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

🌿 What I Built

Meet GrowWise — an AI-powered gardening companion designed to turn screen time into green time.

Here is a problem I think many of us can relate to:

You open your laptop to learn something productive. Three hours later, you have read 17 articles about productivity, watched six videos about building better habits, and somehow become an expert at watching other people grow plants.

Meanwhile, the plant on your windowsill is fighting for its life.

We have AI that can write code, summarize meetings, generate presentations, and help us avoid typing a five-line email. But what if we used AI to help us do something away from our screens?

That is the idea behind GrowWise.

GrowWise helps users start and maintain their gardening journey with an AI Garden Coach, outdoor missions, plant health guidance, and a gardening journal. The goal is simple: make getting outside feel less intimidating, more rewarding, and easier to turn into a habit.

🧩 The problem statement

Modern life makes it surprisingly easy to spend an entire day indoors. Work, social media, streaming, and the endless “just one more video” loop compete for our attention.

Gardening can be a simple way to reconnect with nature, but beginners often face questions such as:

What should I plant if I have never grown anything before?
How do I care for a plant without accidentally giving it the botanical equivalent of a swimming pool?
What can I do in the garden today if I only have 10 minutes?
How do I keep track of my gardening progress and actually build a habit?

GrowWise addresses these challenges by combining practical gardening guidance with small, achievable outdoor activities.

Instead of making AI the destination, GrowWise uses AI as the starting point for a real-world activity. Ask a question, get guidance, step outside, and let the plants have the spotlight.

🌻 Features that make GrowWise grow

1. AI Garden Coach

Get gardening guidance and recommendations tailored to your question. Whether you are a complete beginner or someone trying to keep a suspiciously droopy plant alive, the coach helps you figure out your next step.

Example:

“I'm a beginner with a small balcony and 15 minutes a day. Where should I start?”

Instead of opening 27 browser tabs, you can use the Garden Coach to get a practical starting point.

2. 🌳 Touch Grass Missions

Small, actionable missions encourage users to step away from their screens and do something outdoors.

The idea is to make nature accessible even when you do not have a large garden, expensive equipment, or an entire Saturday free.

Examples include checking the soil of a plant, observing sunlight on your balcony, or spending a few minutes caring for your garden.

Because sometimes the most ambitious outdoor plan you can manage on a Tuesday is watering a plant. And that counts.

3. 🩺 Plant Health Check

Need help figuring out what might be wrong with a plant? The health-check feature helps users think through plant-care concerns and explore practical next steps.

It is designed as a gardening aid, not a magical botanical emergency room. For serious plant problems, local gardening experts and reliable horticultural resources are still valuable.

4. 📔 Gardening Journal

Record your gardening journey and keep track of what you have been doing.

The journal helps turn individual gardening activities into a continuing habit. Mission completion and journal entries are stored in the browser's local storage in the current implementation, so this data is local to that browser rather than automatically synced across devices.

5. 🌱 Beginner-friendly gardening experience

GrowWise brings the gardening coach, missions, health guidance, and journal into one experience, helping users move from “I should probably grow something” to actually doing something about it.

The aim is not to build another app that keeps you scrolling forever. It is to give you enough guidance to close the app and get your hands dirty.

🚀 Demo

Live website: https://grow-wise-rho.vercel.app/

GitHub repository: https://github.com/praniket01/GrowWise

Local AI demo:

https://drive.google.com/file/d/1lF92-iEjizUswAQMT7f1x8om3OSxqjid/view?usp=drive_link

A quick note about the demo

The web application is deployed on Vercel, while the AI inference demo runs locally on my machine using Ollama and Qwen2.5 3B.

The public website and the locally running AI service are not the same deployment. The local AI functionality should therefore be demonstrated using the actual local setup and screenshots rather than implying that the public website is connected to a publicly hosted AI backend.

This setup also demonstrates an important part of the project: a capable AI model can run on your own machine without requiring a paid cloud inference API.

💻 Code

Source code: https://github.com/praniket01/GrowWise

The project is built with a modular architecture so the web application and AI service can be developed and run separately.

The repository includes the frontend, AI service, Docker configuration, and environment-variable examples needed to understand and run the application.

If you explore the code, start with the AI recommendation endpoint and follow how a gardening request moves from the web application to the Python service and then to the local model.

🛠️ How I Built It

GrowWise combines a modern web stack with locally hosted open-weight AI.

The technology stack

Next.js + TypeScript: The web application and user interface.
Python + FastAPI: The AI service and recommendation API.
Ollama: Runs the open-weight language model locally.
Qwen2.5 3B: The model used for local AI inference.
PostgreSQL + Prisma: Database and ORM infrastructure included in the project.
Docker: Helps package and run the AI service consistently.
Vercel: Hosts the public web application.

🧠 The interesting part: AI without API tokens

For the AI component, I chose Qwen2.5 3B through Ollama.

Rather than sending each gardening question to a paid, hosted AI API, I run the model locally and expose it through Ollama's local API. The FastAPI service communicates with that endpoint and provides the response to the application.

The flow looks like this:

User → Next.js → FastAPI → Local Ollama → Qwen2.5 3B → Gardening response

In the local setup, this means:

No external AI API token is required.
No per-request cloud inference charge is required.
The model can run on a suitable local machine.
The model can be changed without redesigning the entire application.
Gardening prompts can stay within the local inference setup instead of being sent to a third-party AI inference provider.

There is one practical detail worth mentioning: the model needs to be downloaded first, and the computer still needs enough resources to run it. Local inference is not the same as having zero hardware costs or never needing an internet connection.

But once the model is available locally, the AI inference itself does not depend on a paid hosted model endpoint.

🔧 Why separate the AI service?

Keeping the AI service separate from the frontend makes the architecture easier to understand and extend.

The frontend handles the user experience. FastAPI handles the recommendation request. Ollama handles local model inference.

This separation also makes it easier to experiment with a different open-weight model or a different inference environment in the future.

🌍 Why Does Open Innovation Matter?

For GrowWise, open innovation is not just a checkbox that says “uses AI.” It changes how the application can be run, understood, and extended.

A closed, hosted AI API would certainly be a convenient way to build the Garden Coach. However, it would also introduce a dependency on an external inference service, its pricing, its availability, and its API credentials.

Using an open-weight model locally gives this project a different set of possibilities.

1. Experiment without an API-token scavenger hunt

Getting started with local inference does not require obtaining a paid model API key. Developers can download a supported model and experiment on their own machine.

2. More control over data flow

In the local configuration, gardening prompts are sent to the locally running model rather than an external model provider. That gives the developer more control over where those prompts go.

This is especially useful when building applications where users may share personal notes or other information they would prefer to keep local.

3. Freedom to switch models

The AI service communicates through an API-compatible interface, so another compatible model or inference provider can be explored without rebuilding the entire frontend.

Today it is Qwen2.5 3B. Tomorrow, it could be another open-weight model that performs better for gardening advice or runs more efficiently on modest hardware.

4. Lower barriers to learning and building

Not everyone wants to pay for cloud inference just to experiment with an idea. Local models let developers prototype, learn, and test without a per-request inference bill.

5. Technology that serves the real world

The most important reason is the project's purpose.

AI is often used to generate more content, more notifications, and more reasons to remain online. GrowWise explores a different direction: use AI to provide enough useful guidance that the user can leave the screen behind.

The ideal user journey is not:

Question → AI response → 40 follow-up questions → 3 hours online

It is:

Question → Practical guidance → Outside → Happy plants 🌱

That is what open innovation makes possible here: not just a different way to access AI, but a different way to use it.

🌱 Final Thoughts

GrowWise started with a simple question:

What if AI helped us spend less time using technology and more time doing something meaningful outside?

It is a small step toward that idea. A garden coach, a few outdoor missions, a place to record progress, and an open-weight model running locally without a paid AI API token.

You do not need a sprawling garden, a greenhouse, or the knowledge of a professional botanist to begin. You might only need a pot, some soil, a little curiosity, and ten minutes away from your screen.

So go ahead. Ask the AI what to plant.

Then close the tab.

Your plants have been waiting for this meeting to end. 🌿

Hacktoberfest #devchallenge #hf26challenge #opensource #AI #Ollama #Qwen #NextJS #Python #Gardening

DEV Community: praniket01

👻 The Ghost in Your Organization Isn't a Bug. It's Your Hidden Talent.

# 🦥 My Codebase Has 847 Files. My Brain Has 2 Remaining Tabs.

Meet CodeSloth — because Ctrl + Click is not a software architecture strategy.

# 🚨 Oops, I Shipped a Secret. ChangeGuard Didn’t.

Challenge Intro

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

Final Note

# 🌱 GrowWise: An AI Garden Coach That Wants You to Close This Tab and Touch Some Actual Grass

🌿 What I Built

🧩 The problem statement

🌻 Features that make GrowWise grow

🚀 Demo

A quick note about the demo

💻 Code

🛠️ How I Built It

The technology stack

🧠 The interesting part: AI without API tokens

🔧 Why separate the AI service?

🌍 Why Does Open Innovation Matter?

🌱 Final Thoughts

Hacktoberfest #devchallenge #hf26challenge #opensource #AI #Ollama #Qwen #NextJS #Python #Gardening

Meet CodeSloth — because `Ctrl + Click` is not a software architecture strategy.