DEV Community: Paras Garg

Invisible Neighbors: An AI Field Notebook for the Sounds Around Us

Paras Garg — Tue, 06 Oct 2026 12:39:05 +0000

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

What I Built

A familiar walk can become background noise. Invisible Neighbors starts with a different question: who might be sharing this neighborhood, even when we cannot see them?

I built a sound field notebook for curious walkers and beginner birders. The idea is simple: go outside, pause somewhere, collect a short recording, and return to it with fresh ears. BirdNET suggests possible birds, and each suggestion links back to the moment in the recording that produced it.

There is no chatbot to keep talking to and no feed to keep scrolling. The recording happens outdoors; the closer examination can happen afterward.

The application has three pages:

Notebook: record with the microphone or import audio and video from a walk.
Listening stop: play the original media, analyze its audio, and add a place and field notes.
Sound passport: collect possible neighbors across stops and export a report with the original recordings.

A video recorded on a phone can be useful too: the app analyzes its soundtrack, while the original video remains available for playback. It does not identify animals visually.

The important word is possible. These are acoustic matches, not confirmed sightings. The app shows model scores and timestamped evidence so the user can listen and make their own judgment.

Demo

Demo video: Watch or download the browser walkthrough (also available at demo/demo.mp4).

This screen recording demonstrates the application in a browser. It is a product walkthrough, not an outdoor field trial or evidence of confirmed bird identifications. The application can be run locally using the setup instructions in the repository README.

The walkthrough is intended to show:

Importing a short outdoor recording or a video with an audio track.
Opening its listening-stop page and requesting analysis.
BirdNET downloading at runtime, followed by local inference.
Playing timestamped evidence and adjusting the minimum score.
Adding field notes and exporting a sound passport.

The application runs locally at http://127.0.0.1:5175/ during development. That address is not a public demo link.

Code

Repository: https://github.com/ParasGarg2k/invisible-neighbors

The application code is MIT licensed. Model weights are not included in the repository or bundled into the application; they retain their separate upstream license.

How I Built It

The AI core is BirdNET v2.4, developed by the Cornell Lab of Ornithology and Chemnitz University of Technology. Its TensorFlow.js release makes browser inference possible without an inference server.

The interface uses React and Vite, with React Router connecting the three pages. Notebook data stays shared during navigation and is saved locally in IndexedDB.

When someone requests analysis, the browser fetches the official model archive from Zenodo. TensorFlow.js runs inference in a worker, keeping the work separate from the interface. There are no API keys and no media-upload endpoint.

Mediabunny reads the recording's audio locally. The app renders mono audio at 48 kHz, splits it into three-second clips, and analyzes the first 60 seconds. Short trailing clips are padded, while their evidence timestamps preserve the actual recording length.

The app retains the top five predictions per clip and groups species using their highest segment score. Changing the score threshold filters the saved results rather than rerunning the model. It does not estimate how many birds were present or claim to measure ecosystem health.

Export creates a ZIP containing original recordings, a readable HTML report, and structured JSON. That makes the passport something the user can take away, rather than a result trapped inside an account.

One practical boundary: cached weights are not the same as a fully offline application. The first model download requires internet, browser storage can be evicted, and the app is not an offline PWA. Google Fonts also creates a network request; local inference does not mean zero network activity.

Why Does Open Innovation Matter?

For this project, access to the model changes the architecture.

I can bring the model to the recording instead of sending the recording to a service. A closed hosted API could analyze sound, but it would introduce an external processing dependency; here, inference takes place on the user's device.

That matters for recordings made near homes or conversations. The app does not need precise GPS, an account, or a server holding someone's media. Users decide whether to share anything by exporting it.

The model release also makes the processing inspectable. Its input format, preprocessing, scores, and evidence windows are part of the implementation rather than hidden behind an API response. Developers can examine the pipeline and improve it within the applicable license terms.

There are no paid inference API calls. Local processing still uses bandwidth for the initial download and the device's own compute resources.

The licensing distinction matters: BirdNET-Analyzer's code is MIT licensed, but its repository describes the models as CC BY-NC-SA 4.0. The Zenodo record has differing license metadata. This is a freely available model with noncommercial restrictions, not an unrestricted model license. My application does not relicense or redistribute the weights. Contest-use permission and the metadata discrepancy remain matters to clarify with the maintainers and organizers.

Open innovation made this local, evidence-linked workflow possible. It did not remove the responsibility to respect licenses or explain the model's limitations.

Prize Categories

Best Use of GitHub Copilot: Copilot's agent mode in VS Code was used to implement and refine the application. Copilot assisted development; BirdNET is the model used by the application at runtime.

I built my friend a private interview coach that runs in the browser

Paras Garg — Sun, 04 Oct 2026 20:14:53 +0000

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

What I Built

My friend Aarav is preparing for a Frontend Engineer role. He knows his
work, but he often freezes when someone asks for a clear, structured answer
without a script in front of him.

I built Interview Espresso, a focused practice app that turns a candidate's
background and a real job description into a six-question interview round. The
candidate writes answers in their own words, then a small open model gives
specific coaching about the evidence they used, what needs sharpening, and what
to practice next.

The important constraint is privacy: résumés and interview answers can contain
personal career history and employer details. The model runs inside a Web Worker
in the browser. There is no account, API key, application backend, analytics
script, or transcript database.

Demo

Video: https://github.com/ParasGarg2k/Interview-Espresso/blob/main/demo-recording/submission.mp4

The shortest useful demo is:

Add a target role, candidate background, and a few job requirements.
Generate a tailored practice round.
Answer at least one question.
Generate a coaching card.
Show the real-user feedback capture.

Code

Repository: https://github.com/ParasGarg2k/Interview-Espresso

Run it locally:

npm ci
npm run dev

How I Built It

The UI uses React and Vite. Inference is isolated in a module Web Worker so
model loading and generation do not freeze the main interface.

Candidate input
     │
     ▼
React interface ──postMessage──▶ Web Worker
     │                              │
     │                              ▼
     │                    Transformers.js + SmolLM2
     │                              │
     ◀──────── generated text ──────┘
     │
     ▼
Practice transcript and coaching (memory only)

The open core is SmolLM2 360M Instruct, loaded in quantized form with
Transformers.js and run through portable browser WASM. The model files are
cached after the first download, but candidate input and answers remain in React
state and disappear on refresh.

Small models do not always obey formatting instructions. Rather than hide that,
the app extracts valid questions and fills a short round with transparent,
role-aware backup prompts when needed. If the model cannot load at all, the UI
falls back gracefully instead of pretending AI ran successfully.

Why Does Open Innovation Matter?

For this project, "open" changes what is possible rather than decorating the
stack.

Privacy: interview content does not need to cross an application server.
Inspectability: anyone can inspect the prompt, worker boundary, and exact model.
Replaceability: the app is not coupled to one closed provider or pricing plan.
Resilience: after the browser cache is warm, practice does not depend on an inference API being available.

The trade-off is honest too: a 360M-parameter model is compact enough for the
browser, but its coaching can be less nuanced than a large hosted model. I
designed the app around one narrow task, bounded inputs, and evidence-based
feedback instead of asking the model to be a general career oracle.

What my friend said

Usefulness rating: 4.5/5
Their words: "This felt like a real practice run, not a generic AI chatbot. I liked that it pushed me to explain my work with examples and results."
What I changed after watching them use it: I shortened the onboarding flow and made the answer prompts more specific so they could answer in a more natural, interview-like voice.

What I learned

The first model I tested technically worked, but generated an unusable question.
I replaced it with an instruction-tuned model and kept a deterministic fallback.
That was a useful reminder that a successful inference call is not the same as
a useful product.

I also learned to treat the write-up and user test as part of the build. The
most persuasive evidence is not a long feature list; it is one person completing
one useful practice round and telling me what should improve.

My Agent Session

I used a Copilot-style coding session to iterate quickly on the UI flow,
troubleshoot model-loading timeouts, and tighten the fallback behavior. The final
product was reviewed for privacy, usability, and interview usefulness before
submission.

Prize Categories

No partner category is claimed. Interview Espresso is entered for the overall
challenge because open-source AI is central to the product.