DEV Community: Srishti Pandey

CODEOWNERS Is a Lie. I Built a Graph to Prove It.

Srishti Pandey — Sun, 18 Oct 2026 16:11:09 +0000

Every code repository has a file that says who owns each part of the code. Nobody fully trusts that file, and there’s a good reason. People change teams. People leave projects. The file never updates itself when that happens.

I wanted to know how wrong that file actually is, and whether a graph database could measure the gap instead of just storing data.

The setup

I took every pull request merged into Home Assistant’s core repository over 180 days. About 10,000 pull requests, 1,600 modules, 1,500 contributors. I loaded all of it into FalkorDB: people, modules, pull requests, and decisions as nodes. The connections between them (who wrote what, who reviewed what, which modules depend on which, and who’s listed as the owner) became edges.

The first thing I checked was simple: when a pull request touches a module, does the listed owner actually review it?

Across the whole dataset, the listed owner was the real reviewer only about 14% of the time. That’s not a small error. That means the ownership file is wrong most of the time.

Making the graph do the thinking

A normal database can answer “who reviewed pull request #4512.” It struggles with “what breaks if this person stops reviewing,” because that question needs several steps: find the modules this person maintains, find who else has touched those modules recently, find the ones with nobody left, then find everything that depends on those.

That’s a few lines of Cypher in FalkorDB. I used variable-length path matching to trace dependencies several steps deep, and FalkorDB’s built-in PageRank to rank which modules matter most based on how much depends on them.

I also ran into a real bug along the way. Binding a loop variable inside a MATCH pattern silently returned zero rows instead of giving an error. No warning, nothing. It just looked like there was no data, when the data was actually there. I only caught it by building a tiny test graph and checking the query by hand. The fix was switching to a WHERE key IN $list filter instead.

The result I didn’t expect

I ran the “what if this person leaves” query against the most active reviewers in the dataset. For one contributor, removing them left 21 modules with no remaining reviewer who had touched them in the past 90 days. Those 21 modules have 751 other modules depending on them, directly or through a chain.

None of this shows up in the ownership file. That file still lists this person as relevant to modules they haven’t touched in months.

Making sure the answers can be trusted

I didn’t want to just print numbers and hope they’re right. So every answer the system gives is built from small facts, and each fact is tied to the exact query that produced it. Before showing anything to a user, a separate piece of code reruns that query and checks the number still matches. If it doesn’t match, the claim gets dropped, not shown with a warning next to it.

I also built a plain text-search version on the same data, on purpose, to check whether the graph was really adding value or whether I was just convincing myself it was better. The graph wins at picking the top three likely reviewers. The text-search version wins when there’s almost no history to work from. I kept both results instead of only showing the one that made the graph look better.

What’s next

Right now, ownership and dependency connections are snapshots, not dated, so I can’t yet ask “who owned this module back in March.” Adding dates to those connections is the next real improvement. I’d also like to combine the graph ranking with the text-search ranking, since each one wins under different conditions.

The code, setup steps, and full graph structure are linked below if you want to try it yourself or check the numbers.

srishtipandey1 / provenance

A graph-powered tool for understanding code ownership, reviewer expertise, and project risk.

Provenance

See who owns the code and who actually knows it.

Why

I built Provenance to show where a repository's listed owners differ from the people doing the work.

When ownership records fall behind, reviews go to the wrong people and expertise gaps stay hidden. In Home Assistant, if epenet stops reviewing, 21 modules lose expert coverage, affecting 751 dependent modules.

How it works

flowchart LR
  A[Public GitHub data] --> B[FalkorDB graph]
  B --> C[8 typed deterministic tools]
  C --> D[Evidence facts]
  D --> E[Claim]
  E --> F[Plain-code verifier]
  F -->|replay matches| G[Verified answer and UI]
  F -->|mismatch| H[Reject claim]

Architecture

flowchart LR
  GH[GitHub data and local architecture records] --> ING[Resumable ingestion]
  ING --> DB[(FalkorDB)]
  DB --> TOOLS[provenance/tools]
  TOOLS --> AGENTS[Router, verifier, and workflow agents]
  LLM[Optional Groq or Gemini planner] -. typed tool selection .-> AGENTS
  AGENTS --> API[Read-only FastAPI]
  API --> UI[React and TypeScript dashboard]

Graph schema

…

View on GitHub

Second Take: Whisper counts my brother's filler words, Gemma explains the counts

Srishti Pandey — Mon, 05 Oct 2026 05:53:52 +0000

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

What I Built

My brother is 15 and sometimes has to speak in front of people. I asked him what he thought about a small app that could help him practise. He said: "It's good."

So I made one.

Second Take is a small web app that runs on my laptop. You record yourself talking for a short time, and it gives you a few things to look at: speaking pace, pauses of 0.7 seconds or more, and filler words like "um", "uh", "like", "basically", and "you know".

The filler words and pauses have timestamps, so you can click on one and go back to that part of the recording.

It also sends the transcript and the measurements to Gemma through Ollama. Gemma gives practice tips based on them. Each take is saved locally, and the app has a chart showing fillers per minute and long pauses across the takes.

The important part is that Gemma isn't calculating the numbers. Python does that first. The model gets the finished measurements and the transcript and writes the advice.

I also added a check after Gemma responds. It finds numbers in the response and compares them with the numbers calculated by the app. It caught numbers in several of my test responses, although it also produced some false alarms.

Demo

I made five real takes.

The first take was 23.5 seconds long. It measured 99.5 words per minute, 12.8 fillers per minute, and 3 long pauses.

The next take was 27.2 seconds long. It measured 119.2 words per minute, 4.4 fillers per minute, and 5 long pauses.

The app also shows where those pauses happened. In the second recording, for example, it found pauses between "scalability." and "When", "server..." and "What", and "copy." and "It".

The transcription isn't perfect. One part came back as:

ThesecondpointIwanttomakeisaboutscalability

So there is clearly still work to do there. The timestamps are more reliable than the transcript formatting, which is why the measurements are based on the timestamps.

My brother actually tried it. I asked him what he thought.

He said:

"It's good."

That's the whole review.

Code

https://github.com/srishtipandey1/second-take

How I Built It

Transcription uses faster-whisper with the base.en model and word timestamps.

Whisper sometimes removes things like "um" and "uh", which is a problem because those are exactly the things I wanted to count. I turned off the voice-activity filter and gave it a short prompt containing some disfluencies.

That helped. The test recordings included "uh" and "um" in the transcript, although the transcription itself still wasn't always clean.

The metrics are just a Python function that takes (word, start, end) values.

For pace, it counts words in each 30-second window and converts that to words per minute.

For pauses, it looks at the gap between one word ending and the next word starting. Anything at least 0.7 seconds counts as a long pause.

For fillers, it checks the transcript against two lists of words.

I also wrote a small test using made-up timestamps where I already knew what the answers should be. The test passed.

For the AI part, I used Ollama with gemma3:1b. I went with the 1B model because I wanted something that would actually run on my laptop without a GPU.

The prompt gives Gemma the measurements and transcript and asks for three practice tips with timestamps.

The app stores takes in a local JSON file. The chart reads from the same file.

I built the app with GitHub Copilot in agent mode. I gave it the requirements, let it make the first version, then ran it and fixed things that didn't behave the way I wanted.

One thing I caught was the recording button still looking like it was recording after I stopped a take. I also changed the history so it doesn't make old takes look playable when their audio isn't stored.

Results

Here are the five takes currently in the app:

Take	Fillers per minute	Long pauses
1	4.4	5
2	12.8	3
3	2.2	4
4	0.0	1
5	0.0	1

The numbers don't move neatly downward, which is probably what you'd expect from five short recordings.

The 10:30 take had 12.8 fillers per minute and 3 long pauses. The 10:33 take had 4.4 fillers per minute but 5 long pauses. So there were fewer fillers, but more long pauses.

The tips from Gemma were mostly about pauses and explaining things more clearly.

What my brother said after:

"It's good."

What didn't work: the 1B model isn't particularly good at following the coaching format every time. Some responses are generic, and sometimes it puts numbers in the answer that aren't part of the measurements. In the latest take, the number check flagged 1 and 3.

The other problem is transcription. Whisper occasionally runs words together or misses things, so the filler count depends on what makes it through the transcript.

Why Does Open Innovation Matter?

The recordings are a teenager's voice, so I wanted to keep them on my laptop.

Whisper runs locally. Gemma runs locally through Ollama. There is no account, API key, or audio upload involved. The take history is just a file in the project folder.

That also made testing easier. I could record something, run it through the app again, change the prompt, and try again without paying for an API call.

The model name is an environment variable too, so I can swap gemma3:1b for a bigger model later if the computer can handle it.

Prize Categories

Best Use of Gemma: Gemma writes the practice tips from the measurements calculated by the app, using Ollama locally.
Best Use of GitHub Copilot: I built the app with Copilot in agent mode and used it to generate the first version from my specification.