DEV Community: Ayush Shandilya

LocalBiz Scout: Building Safer Business Data Cleaning with Python and Local AI

Ayush Shandilya — Mon, 19 Oct 2026 02:24:42 +0000

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

What I Built

I built LocalBiz Scout, a Python tool for analyzing business CSV data, reviewing potential data-quality issues, and applying explicitly approved corrections.

Business data cleaning is not just about finding inconsistencies. An incorrect phone-number correction or a false duplicate match can be worse than leaving a record untouched. I wanted to build a workflow where automation identifies problems, but the person responsible for the data retains control over changes.

LocalBiz Scout has three main stages:

Analyze: Generate structured findings, a Markdown report, and duplicate candidates.
Review: Create correction proposals and a decision template. Proposals default to deferred.
Remediate: Apply only accepted, allowlisted formatting corrections and produce an audit trail.

The tool preserves the original input, protects existing outputs, and does not merge or delete records as part of duplicate handling.

The intended users are developers and data teams working with business directories, lead lists, and other CSV datasets that need a reviewable data-quality workflow.

Demo

I verified the complete analyze → review → remediate workflow using synthetic business records.

The workflow produced the expected reports, review templates, corrected CSV, and remediation audit. I accepted two proposed corrections, deferred one, and rejected another. Only the two accepted corrections were applied, and a SHA-256 check confirmed that the original input remained unchanged.

I also ran the web interface locally and verified that it rejected invalid Host and Origin requests. The interface is loopback-only and analyze-only.

There is no hosted demo at present. The project can be run locally using the instructions in the repository.

Code

GitHub repository: ayushshandilya-dev/LocalBiz-Scout

The implementation includes the CLI, CSV analysis, correction review, controlled remediation, audit generation, a local web interface, and automated tests.

How I Built It

The project uses Python, RapidFuzz for fuzzy matching, Pytest for testing, and a small local web interface.

I designed the workflow around a distinction between proposing a change and being authorized to apply it.

Correction proposals are not automatically applied. The user must explicitly accept them, and only predefined correction rules are permitted. The remediation process writes a separate output and records what was proposed, what decision was made, and whether the correction was applied.

Duplicate candidates are treated as items for review rather than permission to merge records. The matching logic also accounts for address details such as house numbers and unit identifiers, which can distinguish businesses with otherwise similar information.

I added safeguards for input/output path conflicts, existing output files, malformed decisions, CSV quoting, and embedded newlines. These are easy to overlook in a small utility, but they matter when the input contains data that must not be silently changed.

Where AI Fits

AI is optional rather than a prerequisite for the core workflow.

I integrated local inference through Ollama for ambiguous duplicate-candidate adjudication. I verified an offline run using the locally available gemma3:1b model, which adjudicated three ambiguous candidates without falling back.

The deterministic workflow remains usable without AI. The model does not directly rewrite business records or bypass the review and remediation safeguards.

Why Does Open Innovation Matter?

Open innovation makes it possible for developers to inspect, test, adapt, and challenge the design rather than relying on an opaque data-cleaning service.

For this project, the important benefit is transparency. The correction rules are explicit, decisions are reviewable, and remediation produces an audit trail. Developers can inspect how candidate matches are generated and decide whether the safeguards fit their own datasets.

Local inference also provides an option for experimenting with AI-assisted adjudication without sending the sample data to a hosted model API. It does not eliminate the need to validate model outputs, which is why the AI path remains optional.

My Agent Session

I used OpenCode as a coding agent during development and verification.

The process included implementation reviews, regression testing, data-integrity checks, and a final audit of installation and command-line behavior. I kept the final verification separate from implementation changes so the reported results could be checked against the committed revision.

I do not have a published DevRelay or agent-session link to include here.

Testing and Results

The final verification reported:

406 tests passed
1 test skipped because IPv6 loopback binding was unavailable in the environment
Installation through pip install . verified in an isolated virtual environment
Installed console-script entry point verified
End-to-end analysis, review, and remediation verified on synthetic data
Local web-server smoke tests passed
Optional Ollama adjudication verified offline

These results establish that the tested workflow works in the verification environment; they are not a claim of production deployment or real-world adoption.

Prize Categories

This project is submitted to the Hacktoberfest Open-Source AI Challenge Week 2. The relevant themes are Python tooling, practical AI integration, and open-source developer tools.

Closing Thoughts

The central lesson from building LocalBiz Scout is that useful automation needs boundaries.

Finding a likely correction is one problem. Deciding whether the system is allowed to apply it is another. By separating analysis, human review, and remediation, I wanted to make data cleaning more auditable and less likely to silently damage the original dataset.

The implementation is complete and available for review on GitHub. Feedback on the correction workflow, duplicate matching, and safe handling of CSV data is welcome.

MicroWild: Find the Wild in the Places You Already Are

Ayush Shandilya — Mon, 12 Oct 2026 02:41:19 +0000

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

What I Built

MicroWild — Find the wild in the places you already are.

Nature doesn't have to mean a national park, a hiking trail, or a weekend trip. Sometimes it's a plant growing through a pavement crack, lichen on a wall, a repeating pattern in balconies, or a small sign that an animal passed through.

MicroWild turns these overlooked details into short, personalized observation quests. You choose your surroundings, available time, energy level, focus, and whether you're exploring alone or with someone. The app gives you three concrete steps to try outdoors, then encourages you to put your phone away and experience the world directly.

The idea is simple: use AI to help someone leave the screen, not stay on it.

MicroWild is designed for people in ordinary urban environments, including those who don't have easy access to large parks or nature trails. It doesn't require GPS, a camera, photo uploads, or an account.

Demo

Source code: MicroWild on GitHub

Live demo: No hosted demo is currently available. MicroWild runs locally using Ollama and Gemma 3 1B.

To run it, you need Node.js 22 or later and Ollama with gemma3:1b available. From the project directory:

npm install
npm test
npm run dev -- -p 3100

The application has been tested locally. Automated checks pass, but comprehensive browser and mobile-device testing remains unverified.

Code

The core implementation is organized around a small, testable quest pipeline:

app/page.tsx — user flow, preferences, quest display, outdoor mode, and reflection.
app/api/quest/route.ts — quest-generation endpoint, input validation, and timeout handling.
lib/quest.ts — prompt construction, model-output normalization, strict quest validation, saved-quest parsing, and curated fallbacks.
tests/quest.test.ts — automated tests for quest behavior, validation, and fallback handling.

The key design choice is that generated output is not trusted just because a model returned it. Quests pass through validation, and the app can select a curated quest when inference fails or the output is unusable.

How I Built It

MicroWild uses Gemma 3 1B locally through Ollama. The app is built with Next.js and TypeScript, with the quest-generation logic separated into testable functions.

The pipeline is:

The user selects preferences such as environment, duration, energy, focus, and company.
The server builds a prompt for the local model.
The response is normalized and checked against the quest schema and content constraints.
If generation fails or the result is invalid, a curated quest is returned instead.
The user takes the quest outdoors and can return to reflect on the experience.

The model is deliberately not treated as an infallible source of instructions. The validator is the enforcement layer; the prompt alone is not the safety guarantee.

Why include curated fallbacks?

Local inference is not consistently fast on every machine. During testing on a 2015 MacBook Air, a valid model response took approximately 91.7 seconds, while earlier successful generations took approximately 26–33 seconds. The server timeout was raised from 90 to 150 seconds after the slower valid response demonstrated the need.

That improves the chance of allowing slower generations to finish, but it does not make inference instant or guarantee that every request will succeed. When generation is unavailable, MicroWild can return a clearly labeled curated quest instead of pretending the model succeeded.

The latest automated validation reported 25 passing tests, a clean TypeScript check, and a successful production build.

Why Does Open Innovation Matter?

MicroWild depends on being able to inspect, run, and adapt the model locally rather than treating intelligence as an opaque remote API.

Using an open-weight model through local inference makes experimentation possible without requiring a hosted model API key for quest generation. It also keeps the core experience local-first: the app doesn't need to send a user's location, photographs, or account profile to a remote AI service to produce a quest.

Open innovation also means being able to inspect the whole pipeline—from prompt construction to validation and fallback behavior—and change the parts that fail in practice.

There are trade-offs. Local inference depends on available hardware and can be slow, as the latency measurements showed. MicroWild handles that limitation with a curated fallback rather than claiming the model is always available.

My Agent Session

I used an AI coding agent during development to help implement and test the application. I don't have a published DevRelay session to embed in this submission.

What I Learned

The first real outdoor test was useful precisely because it wasn't a perfect success story. I completed a curated quest and found the steps understandable, but the experience made the walk only a little more interesting. The wording was the main friction point.

That feedback led to a small change in one quest: replacing the vague instruction to order marks “by feel” with visible clues such as wear depth, underlying paint layers, and softened edges. The updated wording passes the automated tests, but I have not yet verified that revision in a second outdoor test.

That distinction matters to me: a passing test can establish that software behaves as expected under tested conditions. It cannot establish that an experience is genuinely engaging for a person outside.

MicroWild is an experiment in using AI as a bridge to the physical world. The goal isn't to generate more content for someone to consume on a screen. It's to give them one good reason to look up.

RepoMedic: An AI Field Engineer That Proves Its Fixes

Ayush Shandilya — Sun, 04 Oct 2026 15:43:42 +0000

What I Built

What if an AI coding assistant didn't stop at “I think I found the bug”?

What if it had to investigate an unfamiliar repository, build an evidence-backed explanation, propose a change, and then prove that the repository actually works after the change?

I built RepoMedic for a friend who was trying to contribute to an unfamiliar open-source repository and was stuck on a failing test without understanding the codebase well enough to confidently debug it.

RepoMedic is an evidence-driven AI field engineer for unfamiliar open-source repositories.

Its workflow is:

BUG REPORT
    ↓
REPOSITORY ANALYSIS
    ↓
FAILURE REPRODUCTION
    ↓
INVESTIGATION
    ↓
HYPOTHESES + EVIDENCE
    ↓
ROOT CAUSE
    ↓
PATCH
    ↓
REAL TEST EXECUTION
    ↓
VERIFICATION
    ↓
READY TO CONTRIBUTE

The core principle is:

AI proposes. Evidence decides.

The model can investigate, reason, and propose changes. It cannot declare its own fix successful.

Deterministic tooling reads the source, validates and applies changes, executes the tests, and uses the actual process exit codes to determine whether the fix worked.

A real debugging scenario

For the challenge demo, I used the open-source Python project neithere/argh.

Under Python 3.14, this test:

python -m pytest tests/test_integration.py::test_prog -v

fails.

But:

pytest tests/test_integration.py::test_prog -v

passes.

That difference is the important clue.

The repository isn't simply “broken.” The way the test suite is invoked changes the observed behavior.

The failing output contained:

usage: python -m pytest [-h] {cmd} ...

while the test expected:

usage: __main__.py [-h] {cmd} ...

RepoMedic investigated the relevant source and test files, generated competing hypotheses, gathered evidence, and traced the behavior to Python 3.14's handling of the default prog value in argparse during python -m invocation.

The test was independently reconstructing its expected program name from sys.argv[0], making that expectation brittle.

The useful result wasn't simply:

“Change this line.”

It was:

Why does this happen, which source establishes that explanation, and what evidence distinguishes it from the alternatives?

That's the kind of reasoning I wanted RepoMedic to expose.

Demo

Demo Video: https://drive.google.com/file/d/1djNOexyGXihN_YkK6-_dwoQo-N6qTXpU/view?usp=sharing

The demo walks through the complete workflow:

Bug Report
    ↓
Repository Analysis
    ↓
Failure Reproduction
    ↓
AI Investigation
    ↓
Root Cause
    ↓
Patch
    ↓
Verification

For the verified run:

Targeted test        ✓ PASS
Alternate invocation ✓ PASS
Full test suite      ✓ 170 passed

The verification shown in the demo is independently re-executed against the previously verified patched workspace and makes zero model calls.

The result comes from actual pytest execution and process exit codes.

Not from the LLM.

Not from a "success": true response.

Not from a generated screenshot.

The tests decide.

Code

GitHub Repository:
https://github.com/ayushshandilya-dev/RepoMedic

The repository contains the frontend, backend, investigation system, deterministic repository tools, patch validation and application pipeline, and verification system.

The project is intentionally built as a separate tool rather than modifying the repository being investigated. The target repository is cloned into an isolated workspace, changes are applied there, and verification is performed against that workspace.

How I Built It

RepoMedic is built around Gemma 3 running locally through Ollama.

Gemma is used for the investigation layer:

interpreting the bug report
examining repository evidence
generating competing hypotheses
evaluating explanations
contributing to root-cause reasoning

The architecture deliberately separates AI reasoning from deterministic execution:

OBSERVATION
     ↓
DETERMINISTIC EVIDENCE
     ↓
AI REASONING
     ↓
DETERMINISTIC PATCHING
     ↓
DETERMINISTIC VERIFICATION

The model never receives unrestricted shell access.

Instead, it works through structured repository tools and evidence.

The stack is deliberately straightforward:

Frontend

Next.js
React
Tailwind CSS

Backend

Python
FastAPI

Gemma 3
Ollama
provider abstraction

Repository intelligence

tree-sitter
structured source analysis
deterministic repository tools

Execution

Git
pytest
isolated workspaces
deterministic patch application
real test verification

There is no vector database, no multi-agent framework, and no unnecessary orchestration layer.

The goal was to build the actual engineering workflow rather than assemble a collection of AI buzzwords.

One of the most important design decisions was what happens when the AI is wrong.

An AI model can produce an invalid or ambiguous patch proposal. RepoMedic rejects it rather than silently converting it into a successful fix.

For example, one model-generated proposal produced a source span whose ending line did not exist in the file:

end_line 80 is outside file containing 79 lines

RepoMedic rejected the proposal.

That's not a failure of the safety architecture.

That's the safety architecture working.

During development, the small local Gemma 3 1B model was useful for investigation and root-cause reasoning, but structured patch generation was not consistently reliable on my older hardware.

I kept that limitation visible rather than hiding it.

Why Does Open Innovation Matter?

Open innovation matters here because RepoMedic explores what happens when the AI reasoning layer can be open, local, and replaceable.

Using Gemma through Ollama means repository code does not inherently have to be sent to a closed third-party inference API.

Local inference provides:

greater control over source-code privacy
offline capability
lower marginal inference cost
model flexibility
inspectable infrastructure

The provider boundary also means that the rest of RepoMedic does not need to depend on a single model vendor.

The deterministic parts of the system — source inspection, patch validation, patch application, and test verification — remain independent of the model.

That creates a clear trust boundary:

The AI can reason about the repository, but the repository itself determines whether the proposed fix works.

This is particularly relevant to open source because developers may be working with sensitive or private code where sending an entire repository to a hosted AI API isn't desirable.

Open models make it possible to experiment with AI assistance that can run closer to the developer's own environment while remaining replaceable and inspectable.

Prize Categories

Best Use of Gemma

RepoMedic uses Gemma 3 through Ollama as a local investigation provider.

Gemma analyzes repository evidence, generates hypotheses, evaluates competing explanations, and contributes to root-cause reasoning.

The final patch validation and verification are handled independently by deterministic tooling and real test execution.

I am intentionally not claiming that Gemma generated the final verified patch. The model's role is the investigation and reasoning layer; the system surrounding it establishes whether the resulting change is valid and whether the repository actually passes.

What's Next?

If I continued RepoMedic beyond the challenge, I'd focus on:

stronger sandboxing for arbitrary repositories
persistent workspace management
more reliable structured patch generation
model-assisted code navigation
repository-wide dependency reasoning
incremental investigation instead of repeated scans
richer contribution guidance
stronger provenance tracking for every piece of evidence

The objective would remain the same:

Make AI-assisted software engineering more inspectable and more trustworthy.

AI proposes. Evidence decides.

Hello Everyone

Ayush Shandilya — Thu, 01 Oct 2026 09:25:21 +0000

Hey! I'm Ayush Shandilya, a software engineer working in data engineering and AI/ML. I'm really interested in understanding how things work under the hood from data pipelines and distributed systems to LLMs, RAG, and model infrastructure.

I like building things, breaking them, figuring out why they broke, and then going way too deep into the rabbit hole trying to understand what's actually happening behind the scenes.

I'm still learning, experimenting, and occasionally overengineering things that probably didn't need to be overengineered but that's half the fun, right?