DEV Community: Huzaifa Rehman

Prilizer: stop rereading every pull request

Huzaifa Rehman — Fri, 23 Oct 2026 21:05:34 +0000

My entry for Hacktoberfest Week 3: Slow and Steady.

What I Built

A reviewer asks for a test. You read the message, push another commit, and come back later.
The thread has moved on. Was the request satisfied, withdrawn, or simply buried?

Prilizer is a local catch-up desk for up to three public pull requests by one contributor.
It reads PR bodies, comments, reviews and inline comments, then uses a local Qwen3 model
to identify requests and explain changed discussion. Each action carries the original
quote and a GitHub link.

The piece I care about most is what happens on the next refresh. An outstanding request
stays visible even if the next summary omits it. Marking a digest reviewed only records
that you read it. A request leaves the active list after explicit source confirmation,
a local dismissal, or a fresh closed/merged state. Closing a PR does not prove the requested
code was fixed.

If collection is partial or the model fails, the card says Check manually and keeps
the older evidence. The app never posts a reply or resolves a GitHub thread.

Demo

Source and setup ·
Watch the uncut walkthrough

This is the actual app with fictional discussion and simulated GitHub/model responses.
The uncut walkthrough shows review, local dismissal, edited evidence and a partial-fetch
failure. It is fixture playback, not a live model or customer session.

Code

Prilizer on GitHub.
The repository includes setup, evaluation inputs, raw outputs and failed runs.

How I Built It

A React page talks to a loopback Node server. A bounded anonymous collector
keeps discussion channels separate and compares complete snapshots. Qwen3 1.7B
proposes structured requests; application code validates quotes and provenance,
then persists requests independently of the next model summary.

The intended shortcut is opening one small desk instead of reconstructing several
conversations. Refresh is manual, unchanged successful analysis is cached, and older
requests remain visible. There is no notification feed to keep watching.

I have not measured how much human review time this saves. I would rather leave that
question open than turn a fast cache read into a claim about someone's working day.

What Worked, and What Didn't

The first frozen evaluation failed: 8/12 correct outcomes, including one false Waiting.
The model missed indirect requests and confused who was asking whom.

I added source-role and fresh-confirmation constraints, retained the failures, and froze
twelve different synthetic cases before the next run. The revised pipeline scored
12/12, with zero false Waiting results and zero invalid action quotes. A fixed keyword
baseline scored 10/12, with one false Waiting. The model picked up an approval
condition that the keyword baseline missed.

That result belongs to the full pipeline, including deterministic persistence and
validation. It does not establish general reliability. Summary wording was not scored;
manual inspection still found misleading actor attribution in two summaries.

Speed is another limit. Fresh-set model calls took 8.4–47.1 seconds. A real Docker CLI PR
took 47.3 seconds, then reused its analysis on an unchanged refresh. A Node.js PR hit
the 60-second timeout twice. The app kept it at Check manually. My 30-second target
remains unmet. Raw results and the earlier failures are retained.

Why Does Open Innovation Matter?

Qwen3's open weights and
Ollama let the interpretation run on the same laptop
as the saved discussion. GitHub still needs a network connection for fresh data;
cached evidence remains readable offline.

The model proposes meaning; inspectable application code checks source IDs, exact
quotes, actor eligibility, freshness and request persistence. I can change those rules
or test another local model without depending on a hosted inference endpoint.

There is no per-request inference API bill. Hardware, electricity, memory and waiting
still cost something. The open approach makes this local workflow possible, while the
measurements show where it is still too slow.

Checkilex: Local AI for the Final Handoff

Huzaifa Rehman — Wed, 14 Oct 2026 15:24:10 +0000

My entry for Hacktoberfest Week 2: Side Hustle.

What I Built

A landing page can look finished while its contact link points to the wrong address. Another promise is harder to judge: a form can have the right fields without delivering a message.

Checkilex helps a freelance web developer turn a brief into a reviewed checklist and a record of what the page actually proves.

Paste an English or Roman Urdu brief. A local Qwen model proposes up to eight checks, each attached to the client's original wording. Review the list, correct mistakes, then inspect a developer-controlled local page. The result includes desktop/mobile captures and an exportable Markdown report.

The intended customer is a freelancer preparing a small-business site for delivery. The value to test is less checklist preparation and a clearer handoff. Paid setup or support could be a side hustle around it. I have no customer, payment or measured time-saving evidence yet.

Demo

Watch the 45-second walkthrough.

This is automated operation of the real local app with synthetic data, not a customer session. The recording is silent and uncut, including the 32.1-second inference wait. It was recorded before the Checkilex rename, under the name Site Delivery Check. The screenshot above uses the current name, replays that recorded model draft, and collects fresh browser measurements.

The defective café produces three Failed checks: hidden hours, the wrong email destination and mobile overflow. Switching to the good fixture produces three Verified checks. The email-delivery promise stays Unverified in both.

That last outcome matters. No form was submitted; nothing established that a message reached an inbox. The report preserves that limit beside its findings.

Code

Source, setup instructions and evaluation evidence.

The application is MIT licensed. All application code, café fixtures and evaluation briefs were written during this challenge window. Previously downloaded runtime, weight and browser caches were reused locally.

How I Built It

The app uses TypeScript, React, a small Node HTTP server, Ollama 0.40.0, the qwen3:1.7b tag and Playwright 1.63.0.

The model returns structured check data. Literal text, link labels and destinations are grounded in the source quote. Known optional and negated wording restricts concrete proposals. Every draft still needs review for omissions and meaning.

Fixed checks measure visible text, exact link destinations, specified form fields and horizontal overflow at 1366 × 900 and 390 × 844. The browser uses fresh contexts and bounded requests to one explicit local origin. Forms are never submitted. Editing the brief, checklist or target discards the report.

My first evaluation was disappointing:

Frozen set	Complete pipeline	Keyword comparator
Original held-out 16 briefs	12/16	14/16
Fresh 16 briefs after grounding revision	16/16	8/16

The original model dropped required form fields and misread vague or contradictory Roman Urdu requests. I retained those failures, tightened grounding, then froze new cases before rerunning.

A stronger comparator using the same grounding rules scored 11/16 on the fresh set. The revised 16/16 result belongs to the complete pipeline. These small, targeted synthetic sets do not establish general reliability, and they are different populations.

Four planted browser defects failed, while an unsupported delivery promise stayed Unverified: zero false Verified outcomes across those five assertions.

Performance is unfinished. The single-requirement revision cases took 5.2–13.3 seconds on my i5-8350U laptop. Both eight-check requests hit the 45-second timeout. The planned 30-second eight-check target remains unmet.

Why Does Open Innovation Matter?

Qwen's open weights and Ollama keep inference on the developer's laptop. The app does not send client briefs to a hosted inference API. I can inspect and change the schema, revise the grounding rules, or test another model without depending on a provider's endpoint.

Playwright supplies reproducible browser measurements and captures. The repository records the model’s weight digest, runtime settings, frozen inputs and raw outputs.

The tradeoff is visible in the demo: local inference on this machine is slow. There is no per-request API bill, but hardware, electricity and setup still cost something. Open components made this particular local workflow possible; they did not remove the need to measure it.

Next I want a consenting freelancer to compare it with their existing delivery checklist. That would test the business idea better than another synthetic success count.

PocketPause: one local AI card, then outside

Huzaifa Rehman — Wed, 07 Oct 2026 17:42:41 +0000

This is my submission for Week 1: Touch Grass.

What I built

PocketPause is a small local app with one job: give you one outdoor
observation, then get out of the way.

Choose roughly 5, 10 or 15 minutes and a broad setting such as a street,
terrace, courtyard or campus. A local open-weight model picks a few
observation cues. PocketPause turns them into one fixed card that you can
read, save as plain text, and take outside.

The app does not need an account, GPS, photographs, bird recordings or a
journal. You choose the safe, permitted spot yourself. PocketPause cannot see
it, so its instructions use conditional wording: if a sound or sight is
already there, notice it; otherwise skip it. A terrace selection never grants
roof access, and the time is a suggestion rather than a timer.

The intended flow is short:

Choose a time and setting.
Generate one card locally.
Read it, save it if useful, and put the screen away.

Demo

Download the 26-second demo (.webm)
or view it on GitHub.

The recording shows the real local model generating a card and then saving it
as plain text. It is a desktop software demonstration, not an outdoor trial.
I have not measured any change in well-being or screen time.

Code and evidence

Source code and setup instructions.

PocketPause was created locally on 6 October 2026, within the Week 1 window.
The repository includes tests, all raw measurement runs, setup instructions
and an MIT licence. Model weights, browser binaries and runtime profiles
are excluded from Git.

The measurement evidence
preserves the raw output and failed runs.

How it works

React handles the two selectors, loading and error states, and the download.
A small Node server validates the request and calls Ollama on loopback. Qwen3
uses the qwen3:1.7b tag in non-thinking mode to select the cues. It is the
runtime generation engine, not just a coding aid.

The model returns one exact JSON field containing distinct values from a
six-cue enum. The domain parser checks the fields and the one/two/three cue
count for 5/10/15 minutes. The renderer maps each cue to fixed conditional
sentences, so model text never reaches the card and the model cannot invent a
scene the laptop cannot see. One request runs at a time with a two-minute
deadline. A failed generation shows an error instead of a disguised fixed
card.

What I measured

The cue report covers one cold request and three warm samples for each of the
12 combinations: 37/37 cards were valid. Warm requests took 1.85–6.91 seconds
(3.71 seconds average); the cold request took 16.89 seconds. The 36 warm
cards produced 11 distinct rendered step sets. Eleven of the twelve
combinations repeated across all three warm seeds; only 15-minute terrace
varied. The finite vocabulary limits variety, so this is desk evidence about
the software rather than a claim about an outdoor outcome.

The fixed non-AI baseline also supplies 12 usable cards and remains simpler.
The cue cards pass the desk checks for optional stationary observation, but I
would not claim AI made this a better outdoor experience on the evidence
available.

Why local open-weight AI matters

Once the weights are downloaded, PocketPause generates locally without sending
the prompt to a hosted inference API. That keeps the activity private and
removes the provider account from the generation path. It also makes the
generation engine replaceable: another local model can be selected, although
only Qwen3 has been measured here.

Qwen's upstream weights use Apache-2.0, Ollama uses MIT, and the app's code
is MIT. The measured model identifier and digest are recorded. Local metadata
labels the parameter size as 2.0B while the upstream card names 1.7B; I have
left that discrepancy visible rather than hiding it.

The trade-off is setup. The weights alone are about 1.36 GB, and generation
uses the laptop's resources. This is a local-first project, not a hosted AI
demo.

Starting My Hacktoberfest 2026 Journey

Huzaifa Rehman — Mon, 05 Oct 2026 10:12:12 +0000

Hi DEV! I'm Huzaifa, a computer science student from Karachi, Pakistan.

I've joined Hacktoberfest 2026, completed the pre-event survey, and connected with the MLH Discord community. I've also earned the physical sticker pack.

Now I'm exploring the DEV Challenges and looking for a practical project to build with open-source AI. The first version needs to be something I can finish and test.

I haven't chosen the project yet. First, I need a real problem to solve. Then I'll check whether it fits the challenge theme.

If you're participating too, I'd like to hear what you're working on. What's one repetitive task in your daily life that you wish a small tool could handle?