DEV Community: Abdul Wasih

I let a local Gemma babysit a PR queue overnight. It fast-tracked 31 of 71 with replies, and I woke up to just the other 40.

Abdul Wasih — Mon, 26 Oct 2026 06:37:42 +0000

What I Built

"As the ecosystem grew, maintainers started to face a massive flood of activity and burnout from the rise of low-effort PRs. […] In an era where AI tools make low-effort PRs easier than ever to generate, maintainers face unprecedented volume and noise."
(hacktoberfest.com, on why pull requests no longer count toward rewards this year)

AI made pull requests almost free to write. Reading them didn't get any cheaper. The pile grows faster than the handful of volunteers who have to read it.

So I flipped the question. Could a small model on the maintainer's own laptop help them read the pile, without ever speaking for them?

Nightshift reads the pile overnight. While you sleep, a local Gemma model reads every new PR and issue in your repos and sorts each one: duplicate, spam or slop, out of scope, needs tests or info, trivial and safe, or needs a human. Where a reply makes sense, it drafts one. In the morning you get one page.

It never acts alone. It doesn't post, label, close or merge anything by itself:

Partner repos are read-only in code. The collector's GitHub client refuses anything but reads.
Only one repo can ever be written to, my own, and that allowlist is a constant in the source.
A reply reaches GitHub only after I approve the exact text, once per item, enforced by the database.

I didn't test it on fixtures. I pointed it, read-only, at three of this challenge's partners' own repos: temporalio/temporal, timescale/timescaledb and mastra-ai/mastra. Over two scheduled nights and three manual runs it made 112 triage decisions on 111 real items (STATS.md, generated from the database). That's a small sample, so the bad news comes first.

I labelled night 7's 71 items by hand, and the model wasn't good enough to trust on its own:

Even behind my rules, it was right on 46 of 71 (65%). A triager that sends everything to the maintainer would have scored 65 of 71 (91.5%) (eval report).
All 13 of its "duplicate" calls were wrong, and every one was related but not the same.
It called a 6,246-line refactor "trivial and safe"; only my 40-line rule stopped it.

None of it reached GitHub, because nothing does until I approve the exact text. Night 7 is why that rule exists.

What a maintainer already has

The strongest alternative is GitHub Agentic Workflows. An AI engine runs in Actions on every new issue, gets no write permission, and separate safe-outputs jobs apply what it asks for. Nightshift uses the same idea: the part that thinks can't write.

gh-aw wins if you already live in Actions: nothing to install, it acts in the repo, and GitHub maintains it. Nightshift is different in four ways:

One private page a morning, instead of a public bot comment on every issue.
An open model on your own machine: no model vendor sees a prompt or a diff, and the model calls cost $0.00.
Duplicate memory across up to 90 days of each repo, with a rule that a duplicate must cite a real earlier item.
Measured accuracy against my own labels. A confidence threshold wouldn't have saved night 7: the wrong duplicate calls came in at up to 0.98 confidence.

Rule bots like actions/stale stay the baseline for anything a rule does better. The model only gets what rules can't do: slop, near-duplicates and missing information.

Demo

A 1:52 walkthrough: the morning report, one card from evidence to approval, the honest result, and the Sentry trace. The footage is real screen capture; the voiceover is synthetic.

Live dashboard: https://nightshift-dashboard.onrender.com (Render's free tier, so the first load after a quiet spell can take about a minute). The public page shows live numbers from the database. The review page sits behind Auth0, limited to me, because it can post.

Each card on the review page leads with one next step: Review, Ask for info, Close as duplicate of #N, or Quick merge check. Under it are chips built only from GitHub facts, like diff size, failing CI, missing tests, or the duplicate it cites. The model's own reasoning is folded away. Two buttons, Right and Wrong, are how I labelled all 71 items.

Two replies have gone out this way, both on my own repo: #5, approved as drafted, and #6, which I edited first because the model claimed #5 was already fixed. It wasn't. Both show "via nightshiftdemo", the GitHub App behind Token Vault.

Code

AbdulWasih05 / nightshift

The maintainer's night shift: a local Gemma agent that triages PRs and issues overnight and never acts without approval.

Nightshift

The maintainer's night shift. A local agent reads your PR and issue pile overnight, buckets each item (duplicate, spam/slop, out of scope, needs tests or info, trivial and safe, needs a human), drafts a reply, and leaves you one morning digest.

It never posts, labels, closes or merges anything without your explicit approval. Partner repos are read-only by construction: the write allowlist is a frozen source constant (packages/core/src/allowlist.ts), and the collector's GitHub client rejects every non-GET request.

Runs on a laptop with Gemma 3 via Ollama. $0.00 per night. Contributor data stays on your machine.

Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 3 ("Slow and Steady"). Challenge window: Oct 19 to Oct 25, 2026 (PDT). Repo created 2026-10-21. Any commits after publishing are listed under "Post-deadline changes" below.

Status

Work in progress. See docs/LOOP.md for the build log and docs/DECISIONS.md for every cut and change.

…

View on GitHub

A TypeScript monorepo: packages/core (collector, triage, duplicate search, digest, eval, approval gate), packages/workflows (Temporal), apps/cli, apps/dashboard (Next.js) and sidecars/tabpfn (Python).

Every number in this post comes from a file a script writes from the database, never by hand: STATS.md, NIGHTS.md, the digests and docs/eval. Every cut, failure and reversal is dated in DECISIONS.md.

How I Built It

02:00  Temporal schedule fires nightlyTriage
 ├─ collect       read-only GitHub client, 200 items/repo cap
 ├─ claimBacklog  whatever an earlier night didn't finish
 ├─ embed         nomic-embed-text → pgvector (Tiger Data)
 ├─ triageChunk×N Gemma 3 4B → 1B fallback → strict parser + rules
 └─ finally       digest → finish the night → unload the models
morning  /review: read, label, approve, Post (Auth0 Token Vault)

I built it in small units, each with an acceptance check written before any code, run against the real repos, then read by a reviewer agent that had never seen the code. That reviewer found a blocker in most units, and many of the stories below started there (LOOP.md).

Gemma: a small model behind a strict contract

Gemma 3 4B returns one JSON object per item: bucket, confidence, reason, evidence and an optional draft. My parser is the source of truth, not the model. Anything unparseable becomes "needs a human" and is never dropped; across 112 decisions there were zero parse failures. The 1B model steps in only when 4B errors or times out, so the smaller model never quietly overrules the bigger one. 4B answered 109 items, 1B answered 3.

Early on it called a 414-line concurrency fix "trivial and safe" at 0.95 confidence. I didn't fix that with a better prompt. I fixed it with rules in the parser: "trivial" means under 40 changed lines, a duplicate must cite a candidate it was actually shown, and spam needs two tells. Those rules changed 38 of 112 answers, almost all of them "trivial" calls on big PRs, the largest at 6,246 lines.

Why 4B and nothing bigger? The laptop has a 4 GB MX130, and even 4B only fits 61% of its layers on the GPU. I capped both models at 3 threads so the laptop stays usable overnight. The cost is speed: a median of 92 seconds per item.

Temporal: the night has to survive the laptop

This runs on a 4-core laptop that reboots, sleeps and gets borrowed for other work. Nobody staged these failures; they happened during real nights.

The laptop rebooted 40 minutes into night 5. Everything was down until the next day. When I brought the stack back, the night resumed from Temporal's saved state: nothing was lost and nothing was triaged twice, because each chunk of items is an activity that records its progress.

One item took 1,956 seconds. I first blamed my own dashboard builds. The Sentry section below shows the laptop was asleep, and DECISIONS.md keeps both entries.

The bug I'm least proud of was in my own plumbing, not the model. When Ollama went down mid-night, my first version filed every item as "needs a human" and reported the night as fine. Now an outage stores nothing, the activity fails, and Temporal waits until Ollama is back.

Both scheduled nights ended "partial": night 5 through a reboot, an outage and my own builds; night 7 because the laptop slept from 02:30 to 10:01 and I then stopped it to use the machine. Unfinished items carry over to the next night. I chose not to keep the laptop awake, so nights simply pause while it sleeps.

Tiger Data: duplicate memory

The collector only sees the last 24 hours, but duplicates are usually older. So a backfill keeps up to 90 days of each repo, about 5,500 items, in Tiger Cloud: Postgres with pgvector and full-text search, shared by the laptop and the dashboard.

I measured before picking thresholds. Vector similarity alone is useless here: in one repo, 89% of items have a near neighbour at cosine 0.80, because everything in a repo sounds alike. A genuine duplicate pair, temporal#12211 and #11497, sits at 0.96, while related-but-different pairs sit around 0.87–0.89. So the gate is vector-only at 0.92 or above, or vector plus shared title terms, or a strict keyword match. That last rule came from a real miss: the model once paired two temporal issues just because both titles said "task queue user data".

Auth0 for AI Agents: a token only at the moment of posting

Reading and writing use two different GitHub clients. The reader refuses anything but reads, and the writer is bound to one repo. The first review found a hole in my own allowlist: it checked the parameters, not the URL actually sent. It now checks the resolved URL, and that bypass is a regression test.

A reply goes out only when three things hold. A human approved it, and the approval is bound to a hash of the exact text shown, so what's posted is what was read. A unique index allows one post per GitHub item, claimed before the network call, so a retry can't double-post. And at that moment Auth0 Token Vault hands the dashboard a short-lived GitHub token; none is stored in the app.

Sentry: the trace that corrected me

Each item is an invoke_agent span, with a gen_ai.chat span for each model attempt, carrying tokens, latency, model and bucket, and never text. An allowlist decides what leaves the laptop, and a test enforces it.

That 1,956-second item is where the trace paid for itself:

IST, Oct 23	Sentry trace	Windows event log
13:05:26	4B chat starts
13:06:05		system enters sleep
13:37:17		resume
13:37:18	1B chat starts
13:38:01	1B chat ends, row saved

They agree to the second. The model wasn't slow; the laptop was asleep. The trace also showed something the event log couldn't: the sleep changed which model answered. The 4B call was cut off on wake, and the 1B fallback started one second after the wake. The trace shows when the call ended, not why. The likeliest cause is that its 240-second timer counted the suspended half hour. Either way, a timeout that can't tell a hung model from a sleeping laptop hands work to the weaker model for no reason. Fixing that is next, and I'd never have seen it without the trace.

TabPFN and Mastra

TabPFN produces a "likely to stall" flag, trained on stored PR history. The data was harder than the model: the backfill picked items by update date, so older PRs were survivors that skewed everything. I caught it by plotting merge rate by month before training, and now train only on PRs from inside each repo's window.

The triage call itself is a Mastra Agent with structured output. I use Mastra for nothing else, so I'm not entering its category.

Why Does Open Innovation Matter?

Three things Nightshift can only do because the model is open and runs locally.

1. Nothing goes to a model vendor. Every triage call goes to Gemma through Ollama on the laptop. Items live in a Postgres I control, and Sentry gets an allowlisted set of metadata, never text (telemetry.ts). For a private repo, that's the difference between allowed and not allowed.

2. Free calls change how it behaves. All 112 decisions cost $0.00: 131,474 tokens in and 16,469 out (STATS.md). At Claude Sonnet 5.5's list price ($2 in, $10 out per million tokens, checked 2026-10-25) the same tokens would cost $0.43, so the money isn't the argument. Behaviour is: with no meter running, the agent can spend 92 seconds on an item, re-read anything that changes, and replay old nights against a new prompt before it ships.

3. The model is mine to fence. I can see and control every layer: the prompt, the model, and the parser between them. That's why rules can overrule the model where it's weak. On night 5 alone, it called 12 items trivial and the 40-line rule overruled 10 of them, including a 717-line PR (night 5 digest).

The Lazy Payoff

Instead of 71 tabs, night 7 gave me one page (digest). Here's how it held up against my own labels:

Pile	Items	Right, by my labels	What you do
Needs you	40	40 of 40	read it
Drafted replies	25	2 of 25	read the draft, then approve, edit or skip
Trivial and safe	6	4 of 6	a quick merge check

On night 7, when it said "needs you", it was right all 40 times. But it only sends 62% of what really needs me there; the rest lands among the drafts, mostly as false duplicates. So the safe way to read the morning is: trust the top pile, and read every draft. The digest's "est. 113 min" is labelled as an estimate. I haven't timed myself, so I don't claim minutes saved.

It lost to doing nothing

Night 7, n = 71	Correct
Gemma 3 4B + rules (prompt v1)	46 (64.8%)
Always "needs a human"	65 (91.5%)

That's one night, on repos where most items really do need a maintainer (65 of 71, by my labels), so always-escalate is a hard baseline to beat. The more useful view is where it was confidently wrong:

Bucket the model chose	Precision
Duplicate	0 of 13
Needs tests or info	2 of 12
Trivial and safe	4 of 6

All 13 duplicate calls failed the same way: related, not the same (full list with my reasons). Five were siblings in a series, like a mastra run of Word, then PowerPoint, then OneDrive toolsets. Eight were a different bug in the same corner, like "cancel overwrites a finished run" against its exact reverse. The search found the right neighbourhood every time; the 4B model just couldn't tell a neighbour from a twin, and said so at up to 0.98 confidence. My citation rule passed all 13, because each cited a real candidate. It checks that a duplicate is cited, not whether it's the same thing.

Nothing was harmed: all 13 were on read-only partner repos. On my own repo, each would have reached me as a suggestion, not a closed issue.

Other honest misses:

"Trivial" was the model's first bad habit: across all runs the rule caught 37 of those calls. Of the six that got through on night 7, two were still wrong; one was a dependency bump with failing CI, which the rule doesn't check yet.
The #6 reply claimed #5 was "already addressed". I fixed it before approving, which is exactly why a human reads the exact text.

What's next: prompt v2 makes the model say what's different between two items before it may call them duplicates, an idea borrowed from Microsoft hve-core's backlog triage. It's the only change, so the next night's difference can be traced to it. It ships only if it beats v1 on these same 71 labelled items. I didn't run it before publishing: replaying 71 items takes about two hours on this laptop (71 at a 92-second median), and I'd rather publish a measured v1 than an unmeasured v2.

Prize Categories

Best Use of Gemma: Gemma 3 4B, with a 1B fallback, makes every triage call locally through Ollama, fenced by a strict parser and rules.
Best Use of Temporal: the night is a durable scheduled workflow. It resumed after a mid-night reboot with nothing lost or repeated, carried on after the laptop slept, and waited out an Ollama outage instead of filing everything as "needs a human".
Best Use of Tiger Data: hybrid duplicate search (pgvector plus full-text) over 5,543 stored items, including timescale/timescaledb itself. Used for search, not time series. Shared by the laptop and the dashboard.
Best Use of Auth0 for AI Agents: nothing reaches GitHub without approval of the exact text; the agent's client can only read; the write token comes from Token Vault at the moment of posting and is never stored. Two replies went out this way (#5, #6).
Best Use of Sentry: every item is traced (tokens, latency, model, no text), and the trace found the real cause of the slowest item, a sleeping laptop that also switched which model answered.
Best Use of TabPFN: a "likely to stall" flag from real PR history, run by hand after a night. 73% of the PRs it flags really don't merge within 14 days, against a 45% base rate. On plain accuracy it ties a one-line rule (63.1% vs 61.8%), so I don't claim it beats it (predictor run 1).
Best Use of Render: the morning report runs on a free Render web service from a render.yaml blueprint. The model deliberately doesn't: triage stays on the laptop, and only the report and the approve button are hosted. That split is what keeps contributor text away from model vendors.

"Behind Lulu" is not an address: a $2 fine-tune that reads addresses like a dispatcher

Abdul Wasih — Mon, 19 Oct 2026 05:14:09 +0000

What I Built

Lulu is a hypermarket chain you find all over the Gulf. "Behind Lulu, call before coming" is what a customer in Dubai types when they mean "I'll explain on the phone". A courier who sends that parcel out without calling pays for the failed trip.

India has its own version: "near Hanuman mandir, Bandra West", often with no house number. A driver gets 120 of these on a morning route, and many are cash on delivery, so a failed stop means the parcel comes back and the seller never gets paid.

Pata ("address" in Hindi and Urdu) reads each address before the van leaves and answers DELIVERABLE, CALL_FIRST (with a call script) or LIKELY_FAIL. It also splits the address into building, flat, street, area, landmark and PIN (India's postal code). Real outputs from the deployed model:

What the customer typed	Order	Pata says
`Flat 1203, Marina Pinnacle Tower, Dubai Marina`	UAE, cash	DELIVERABLE
`behind Lulu Hypermarket Al Barsha, call before coming`	UAE, cash	CALL_FIRST:"Could you confirm your building or house number? Payment is cash on delivery."
`H.No 45, MG Road, Bengaluru 560001`	India, order's PIN field says 110001	LIKELY_FAIL: the address says Bengaluru, 110001 is Delhi

The short version: simple rules already match the tuned model at saying deliver, call or hold. What a $2 fine-tune adds is reading the address:

Indian addresses (150 test rows)	Building found	Area found
My rules	47%	14%
Qwen3.5-4B, untrained	53%	76%
Pata (trained 4B)	90%	87%

A field counts as found when it exactly matches the human-tagged field in the source dataset, ignoring case and spacing.

Who I expect would pay: couriers and cash-on-delivery sellers in India and the Gulf, where "behind Lulu" is in no postal database. Pata costs about $0.15 to $0.17 per 1,000 parcels to run, and two training runs cost $5.35 in total.

Demo

Try it: https://pata-gw9g.onrender.com

It runs on Render's free tier, so the first request after a quiet spell can take up to a minute. Try "behind Lulu Hypermarket Al Barsha" with cash on delivery, then add a flat and building number. The repo has a Deploy to Render button for your own copy.

Code

AbdulWasih05 / pata

Dispatch triage for couriers: a fine-tuned 4B model decides DELIVERABLE, CALL_FIRST or LIKELY_FAIL before the van leaves.

Pata

Dispatch triage for couriers. Pata reads a raw customer address plus order context and returns a decision before the van leaves: DELIVERABLE, CALL_FIRST, or LIKELY_FAIL, with normalised fields, a one-line driver note, and the reason.

Entry for the DEV Hacktoberfest Open-Source AI Challenge, Week 2: Side Hustle. Built by Abdul Wasih (@iamwasih).

Live demo: https://pata-24o3.onrender.com (free instance; the first request after a quiet spell can take up to a minute). Serving checkpoint: run 2 (see train/RUNS.md, eval/results.md).

How it works

 browser / CSV / CLI
        |
        v
 FastAPI gateway (Render)  ---- Sentry agent trace per request
   1. rules_prelabel   pata/rules.py, always computed
   2. chat             tuned Qwen3.5-4B, Tinker OpenAI-compatible endpoint
                       (hedged: a 2nd request after 1.5 s, first answer wins)
   3. schema.validate  pata/schema.py (pydantic)
   4. rules_fallback   only if the model call fails or its JSON is invalid
        |
        v
 decision + normalised fields + driver note

…

View on GitHub

How I Built It

1. Rules first

Before any AI, I wrote down how a careful dispatcher decides, as plain Python functions with tests (pata/rules.py). For example, an Indian address with no PIN code gets CALL_FIRST, because a courier cannot route it. Every judgement call like that is written up in DECISIONS.md. The rules did two jobs: they labelled the training data, and they are the backup answer if the model ever fails.

2. Data

India: real company-registry addresses from public Hugging Face datasets (indian-addresses-gold, indian-address-parsing-synthetic, Apache 2.0), roughed up with landmarks, typos, missing PINs and Hinglish like "mandir ke paas" ("near the temple").
UAE: synthetic, because no public Gulf address dataset exists. A generator writes Makani numbers (Dubai's building ID), PO boxes, Arabic script and "will share location on WhatsApp".

About 6,000 training examples, and no real customer addresses.

3. Fine-tuning on Tinker

Tinker is Thinking Machines' fine-tuning service: you write the training loop in Python and it runs on their GPUs. I took Qwen3.5-4B, a small open model (Apache 2.0), and trained a LoRA adapter on it. LoRA trains a small add-on to the model instead of retraining all of it, so a run took 13 to 19 minutes and cost $2 to $3 (train/RUNS.md). A FastAPI app on Render serves it, checks every reply against a strict schema, and falls back to the rules if anything is off.

4. The run that went wrong

My first run looked worse than expected on India: on 45 parcels where my rules said hold or call, the model said DELIVERABLE. I read all 45. In 30 of them, the model was right and my rules were wrong. "H.No 323, Balaji Heights" was marked "missing flat number", but the house number is the flat.

I fixed the rule, added tests, relabelled the data and trained a second run, which serves today. The lesson: a model trained on your rules can still check those rules, but only if you read the cases where the two disagree.

Sentry: the mystery 6-second requests

Every request is traced in Sentry's AI agent monitoring: the rules check, the model call with its token counts, and the schema check each show up as a span. Traces store lengths and decisions, not the address text.

The traces showed something logs would have hidden. Model calls took either about 1 second or about 6 seconds, with almost nothing in between, and with the same token counts. So the model was not writing more; something upstream was holding some requests for five seconds.

The fix is an old trick, a hedged request: if the first call has not answered in 1.5 seconds, send it again and use whichever answer arrives first. Each span records whether it was hedged.

40 requests each way (benchmark, results):

	Before	After hedging
Typical (p50)	1.15 s	1.04 s
Slow end (p90)	6.19 s	2.92 s
Requests over 5 s	10 of 40	0 of 40

Six of the forty sent a second call, so hedging adds at most 15% to the cost.

Eval

Testing against my rules would only show that the model copied them. So a separate AI reviewer (Claude) labelled 150 test addresses per market, seeing my written definitions but never the rules' answers or code. Of those, 106 India and 77 UAE parcels should be called or held; the rest (44 and 73) are fine to deliver.

System	Correct (India / UAE)	India wrongly approved	Good parcels held (India / UAE)	Cost per 1,000 (India / UAE)
Qwen3.5-4B, untrained	43% / 25%	28 of 106	4 of 44 / 56 of 73	$0.33 / $0.31
Qwen3.5-397B, untrained	49% / 57%	7 of 106	22 of 44 / 33 of 73	$2.20 / $2.01
My rules alone	87% / 85%	9 of 106	3 of 44 / 23 of 73	$0
Pata (trained 4B)	86% / 85%	11 of 106	4 of 44 / 22 of 73	$0.17 / $0.15

Both untrained models got the same instructions plus a JSON format description, with thinking off. That longer prompt, and their longer answers, is why they cost more. On UAE, wrongly approved was 0 of 77 for everyone but the 397B (1 of 77). Full tables: eval/results.md.

What it means: training doubled the 4B's accuracy on India and tripled it on UAE, and it beats a model 100 times its size at a thirteenth of the cost. That bigger model only looks safe because it holds half the good parcels. On the three-way decision, though, the trained model ties my rules, agreeing with them on all but 9 of 300 addresses. Its real win is reading the building and area, as in the table at the top.

Why Does Open Innovation Matter?

Local quirks are teachable. You cannot fine-tune a closed API on "Al Nahda without an emirate". One $2 run on an open model took UAE from 25% to 85%.
Addresses stay in-house. The weights are open, so a courier can run them on its own machine instead of sending names, phones and cash orders to a third party.
Nothing is locked away. Rules, data generator, training and eval are all in the repo.

Honest limitations

The test labels come from an AI reviewer, not real delivery outcomes.
The test set is 150 addresses per market.
The UAE data is synthetic, generated from real patterns.

Prize Categories

Best Use of Tinker: two LoRA runs of Qwen3.5-4B, evaluated against the base model, a 397B model and the rules, including the failed run. The live demo serves from the Tinker checkpoint.
Best Use of Render: the app runs from a one-click render.yaml blueprint.
Best Use of Sentry Agent Tracing: traces exposed the 6-second requests, and the hedging fix removed them.

Built by @iamwasih.

Viva: a mock interview that knows which parts of your project an AI wrote

Abdul Wasih — Mon, 05 Oct 2026 06:57:13 +0000

What I Built

If you have sat in a placement interview, you know the moment.

The interviewer stops scrolling through your repo, points at one file, and says: "Walk me through this function."

You know what the function does. You typed the prompt that produced it. You did not write it.

That happened to a friend of mine, with a project the two of us built at a hackathon. It works. It is on his resume. He could tell you what every screen does. He could not tell you why the code is the way it is, because an AI agent wrote a lot of it and we shipped before we understood it.

Every fresher I know is a little scared of that question. So I built Viva: a mock interview about your own project, that knows which parts an AI wrote.

You give it a repo. It reads the code, finds the files your coding agent wrote, and then interviews you the way a panel would. When it reaches the AI-written part, it says so:

Your Entire session shows an AI agent wrote src/lib/interview/prompts.ts (the prompt was: "1,2 isdone lets skip teh devrealy install, render and eleven labs credits i will claim, yep lets do stacked prs"). Explain the logic behind how briefPrompt structures the input data to ensure the generated brief remains grounded in the actual repository content.

That is a real question Viva asked me, about Viva. The typos in the prompt are mine.

Demo

Try it: https://viva-ou6t.onrender.com

Click "Viva (this project)" to see the AI-code question straight away, or paste any public GitHub repo (reading a new one takes about 45 seconds).

In the video, the candidate is simulated and the voice is Kokoro, an open speech model running on my laptop. The app on screen is real, with the waiting cut out.

Code

AbdulWasih05 / Viva

A local first AI interview coach

Viva

A mock technical interview about your own project, for the AI-coding era.

Students now ship projects an AI agent half-wrote, and interviewers know it. Viva reads your repo, finds the parts an agent wrote, and questions you about them the way a placement interviewer or a final-year viva panel would. It asks follow-ups based on what you actually said, remembers your weak spots, and ends with a scored report.

Built for the DEV Hacktoberfest 2026 Weekend Challenge (Build for a Friend). The interviewer is Gemma, an open-weight model; Mastra runs the agent; Entire checkpoints tell Viva which code an AI wrote.

What it does

Reads your project. Paste a public GitHub URL (or, in local mode, a folder path). Viva picks the most telling files and Gemma writes a short brief. Every file path in that brief is checked against the real file list; invented ones are dropped.
…

View on GitHub

One rule runs through the code: Gemma decides what to say. Code decides what happens. The round order, the follow-up limit, the scores and every file path are plain, tested TypeScript.

How I Built It

Piece	What it does in Viva
Gemma 4 26B (open weights)	The interviewer: writes the brief, the questions, the scores and the report
Mastra	Runs the interviewer as an agent with a `readFile` tool, and remembers your weak spots between sessions
Entire	Records each coding-agent session next to its commit. Viva reads that to find AI-written code
Sentry	Traces every interview turn, with quality flags on each one
Render	Hosts it. One free service, no database

An interview in four moves. Viva reads the repo and Gemma writes a brief; code throws out any file path Gemma made up. For a code question, the agent opens the file itself before asking. After each answer, Gemma scores it and may follow up, but the follow-up has to quote something you actually said, and code checks the quote. At the end, code adds up the scores and Gemma writes the coaching.

What I measured, across scripted interviews on two real repos:

Check	Result
Model replies that passed the schema check	119 of 119
Deep-dive questions that named a real file	6 of 6
Follow-ups that really quoted the answer	51 of 51
Code questions where the agent opened a file first	18 of 18
Second session opened with last time's weak spot	3 of 3
Interviews on Viva's own repo that asked about AI-written code	3 of 3

How Viva knows what the AI wrote. A file counts as AI-written when it was changed in a commit that Entire linked to a coding-agent session. The prompt Viva quotes is the one you typed in that session, taken from the session transcript.

That Sentry trace is one interview turn: question_names_real_file: true, ai_authored_question: true, no retry, no fallback. Each turn carries these flags, so I can see whether the interviewer is doing its job without reading every chat.

Why Does Open Innovation Matter?

Because of who this is for.

A student should not need a credit card to practise for an interview. His next project may be private. A college lab may have no reliable internet. With an open model, the same code talks to Gemma on a server or to Gemma on your own machine through Ollama, and switching is one setting. A closed API does not give you that choice.

Nobody has to trust my copy either. The prompts and the scoring rubric are plain files, and the Deploy button gives any coding club its own private Viva.

Open is not free, and I measured the price. On my 16 GB laptop with no real GPU, local Gemma took 50 to 544 seconds per call and never finished a project brief. So today, local mode needs better hardware than a student usually has. But that is a limit I can see and work on, in code I can read.

My Agent Session

The whole build is public. Each phase is one commit, and each commit carries its Entire checkpoint: the same data Viva reads to interview me. Every decision is numbered, with its reason, in docs/DECISIONS.md.

Prize Categories

Gemma: the interviewer itself
Mastra: the agent, its tools and its memory
Entire: the source of every AI-code question
Sentry Agent Tracing: each turn traced with quality flags
Render: hosting and a one-click blueprint

Still to build: voice answers, showing what the agent reads while it reads, and getting a turn under 8 seconds (a new question takes 11 to 14 today).

Have you been asked to explain code your AI wrote? How did it go? Tell me in the comments.

I built Viva with an AI coding agent (Claude Code). The numbers are measured and the sessions are public in the repo.