DEV Community: william freund

I Stopped Opening the Spreadsheet: Asking 19,426 Job Posts One Lazy Sentence

william freund — Mon, 26 Oct 2026 01:00:02 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

DEV Hacktoberfest Week 3 — "Slow and Steady". Built this week, from scratch, with an open-weight model (Gemma 3 1B, running locally).

What I Built

The most boring week of my October

Every year, China's national civil-service exam (国考) publishes its position table: 19,426 rows of departments, quotas, majors, degree requirements, locations, and footnotes. To find posts I could actually apply for, I spent a week scrolling, Excel-filtering, and re-checking constraints — degree, major, English certificates, party membership, grassroots experience, "remote western region" postings.

With my AI assistant's help I got it down to 23 genuinely eligible posts. And then I noticed something: every remaining question I had was a one-liner.

英语专业，不要四六级，招3人以上，太原的岗
English major, no CET-4/6 requirement, 3+ openings, in Taiyuan

招4个人的税务局岗
Tax bureau posts hiring 4 people

提供宿舍的岗
Posts that provide a dormitory

Each of those used to mean: open the spreadsheet, remember which column holds what, apply three filters, squint. So I built the laziest possible interface: type one sentence, get a ranked shortlist.

Demo

Meet CouchFilter 🛋️

$ python couchfilter_cli.py "英语专业，不要四六级，招3人以上，太原的岗"

问：英语专业，不要四六级，招3人以上，太原的岗
（Gemma 本地解析）

命中 1 个岗（按招考人数排序）：
1. [300110021004] 国家税务总局清徐县税务局｜一级行政执法员（四）｜招 3 人
   地点：山西省太原市清徐县｜备注：男性，在本单位最低服务年限为5年

Or open the tiny web UI and ask from the couch:

python serve.py → http://127.0.0.1:8000 — one input box, one button, ranked cards.

Code

Repo: https://github.com/986036734/couchfilter

How I Built It

How it works (and where the model earns its keep)

The pipeline is deliberately split in two:

Fuzzy part → Gemma 3 1B (open weights), running locally via Ollama.
It turns one Chinese sentence into structured filters — a JSON object with location, minimum headcount, major, excluded terms, dormitory requirement, degree. Nothing leaves the machine; the position table never touches a cloud API.
Exact part → plain Python.
Filters are applied deterministically over the spreadsheet, so every result is reproducible and every rejection comes with a reason ("只招 2 人（要 ≥3）", "备注未写提供宿舍").

Why the split? A 1B model is great at understanding "招3人以上" means min_headcount: 3, but I don't want it deciding my career shortlist from vibes. The model translates; the code filters. If Ollama is down, a rule-based parser takes over and says so honestly.

Ranking is laziness-first: more openings first (better odds per application), then everything else.

Total new code: ~400 lines. Dependencies: openpyxl, requests, and a local model. The web UI is Python stdlib only.

Try it on your own table:

pip install -r requirements.txt
ollama pull gemma3:1b
python couchfilter_cli.py "你的问题" --table your-positions.xlsx

Any 国考-style table works if the column layout matches (the C_* constants in couchfilter.py are the whole schema).

Why Does Open Innovation Matter?

CouchFilter is built around an open-weight model, Gemma 3 1B, running locally via Ollama. Because the model runs locally, nothing leaves the machine and the position table never touches a cloud API. The model does the fuzzy language part, and deterministic code does the filtering, so every result is reproducible and every rejection comes with a reason. If Ollama is down, a rule-based parser takes over and says so honestly.

The Lazy Payoff

The "slow and steady" philosophy

The theme this week is rewarding laziness, and I took it literally. The laziest query wins: no column names to memorize, no filter dialogs, no "wait, which sheet was it". The tool even tells you what it excluded and why, so you can loosen one constraint instead of starting over.

Prize Categories

Best Use of Gemma

Built 2026-10-24 for DEV Hacktoberfest Week 3. The 23-post shortlist is public recruitment data; the week of manual screening that produced it is a story for another post.

BlastRadius: Know What Breaks Before You Merge

william freund — Sat, 17 Oct 2026 02:31:06 +0000

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

What I Built

BlastRadius answers the question every developer dreads: "if I change this function, what breaks?"

You point it at a Python repo. It parses the code into a graph (files, functions, classes; calls, imports, definitions), then runs real graph queries to find the blast radius of any proposed change: every caller, transitively, the files involved, the tests that cover it, the dependency chain, and the hot spots. Then a local open-weight model (Gemma, via Ollama) writes a change summary grounded in those graph results, plus which tests to run.

Who would pay for it: indie developers and small teams who have been burned by "one-line fix, three-hour outage." Local single-repo scans are free; the business is a per-repo / small-team plan for hosted scans and team-wide impact reports.

Demo

Watch the 37-second demo (real run on the bundled sample app): BlastRadius demo video

Or run it yourself: clone the repo, follow the README quickstart, then python -m blastradius demo.

Code

https://github.com/986036734/blastradius

How I Built It

FalkorDB (open-source graph database) holds the code graph. All impact analysis is real Cypher: multi-hop reverse CALLS traversal for the blast radius, shortest path for the dependency chain, degree centrality for hot spots.
Gemma (Google's open-weight model) via Ollama, running fully locally, writes the change summary. The prompt is grounded in the graph results — callers, files, tests, chain — and the graph results are authoritative: the summary is a draft for the developer to check, not gospel. (In testing, the 1B model occasionally garbles a detail, e.g. inventing a test filename; the 4B model is recommended for better fidelity.)
Python stdlib ast for parsing. No embeddings, no hosted APIs in the loop.

Why Does Open Innovation Matter?

Your codebase is your most private asset, and your change history is your team's memory. A closed API would mean shipping both to someone else's server on every query, and paying per token for the privilege.

Running Gemma locally flips that: the graph and the model both live on your machine, your code never leaves the laptop, and the marginal cost of a query is ~$0 — which is exactly what makes a $5/mo-style price point work instead of a per-token meter. Open weights also mean you can swap models (1B on a laptop, 4B on a workstation) without rewriting anything. If Gemma disappeared tomorrow, the graph queries still work; if the graph disappeared, the model would be guessing. The open pieces are what make the product work.

Prize Categories

Best Use of Gemma

Touch Grass: an open-source AI agent that plans your way outside 🌿

william freund — Fri, 09 Oct 2026 15:27:30 +0000

My submission for the Hacktoberfest Open-Source AI Challenge: Week 1 — "Touch Grass".

The prompt was simple: build something with open-source AI at its core that gets people off the screen and into the world. So I built the smallest agent I could that does exactly that — you tell it where you are and how much time you have, and it plans a real outdoor micro-adventure: when to go, where to stand, what to look for, and what to do with your phone (spoiler: airplane mode).

What I built

Touch Grass is a tiny Python agent (~200 lines, one dependency). It runs a tool-using loop over any OpenAI-compatible chat endpoint:

Tools: geocoding (OpenStreetMap), sunrise/sunset times, and a 12-hour weather outlook (Open-Meteo) — all free, keyless, open data.
Brain: any open-weight model behind an OpenAI-compatible API. The agent supports local Ollama for fully offline inference, or a hosted gateway. For this demo I ran it against a hosted open-weight model served over an OpenAI-compatible endpoint; swapping models is one environment variable.
Output: a concrete Markdown plan — time window, spot, timed steps, things to notice, a phone rule, and a rain check. No frameworks, no vendor SDKs. The whole thing is requests + a loop.

Demo

Real run, tonight, no cherry-picking — asked for a 45-minute sunset walk with birding near Olympic Forest Park, Beijing:

Lakeside Light & Last Calls — Aohai, Olympic Forest Park

When: 17:05 → 17:50. Sunset is 17:46, so this window catches warm pre-sunset light and ends in the afterglow. Overcast, 21°C, 0% precipitation across the next 12 hours — dry and calm. Honest caveat: overcast may swallow the sun disc itself. That's fine — it's actually better for birds.

Where: the east shore of Aohai lake, looking west across the water. Enter at the south gate, 8 minutes' walk to the shoreline.

The plan: timed steps from gate to shoreline birding (17:10–17:28), then 5 minutes north to a west-facing photo gap, shooting the afterglow 5–10 minutes after official sunset.

Look for: grey herons and great egrets in the shallows, little grebes and coots on open water, azure-winged magpies in the treeline, the lake going two-tone in the wind, early-October migrants in the willows.

Leave the phone: airplane mode in your pocket until 17:44 — the camera is the only phone use, and it starts when the light does.

Rain check: not needed today. If the sky fully greys out, drop the sunset shot and walk the wetland boardwalk instead.

What I like about this output: the agent actually used its tools. It geocoded the park, pulled real sunset/weather data, and reasoned about it — noticing that overcast hurts the sunset photo but helps the birding, and adjusting the plan accordingly. That's the agent earning its keep, not just filling a template.

Why open innovation matters here

This project only makes sense because it's open, in three concrete ways:

It can go where the trail goes. A closed API means the agent dies the moment you lose signal. Open weights mean the same agent runs on a laptop with Ollama, fully offline — which is exactly where a "touch grass" tool needs to work.
Your location stays yours. The agent's most sensitive input is where you are and when. With open models and open data sources, none of that has to travel to a server you don't control.
It costs nothing to run and anyone can improve it. The model is swappable, the data sources are free, the code is ~200 lines of MIT-licensed Python. A student, a hiking club, or a park ranger can fork it, point it at a newer open model next year, and it's better — no permission, no bill.

Closed models could generate the same words. They couldn't give you the same guarantees. For a tool whose whole job is getting you outside, offline and private aren't features — they're the point.

Try it

pip install -r requirements.txt
export OPENAI_BASE_URL=http://localhost:11434/v1  # or any OpenAI-compatible endpoint
export OPENAI_MODEL=qwen2.5:3b
python -m touchgrass.cli --place "your park here" --minutes 45 \
  --interests "birding, sunset photos"

Repo: https://github.com/986036734/touch-grass

I validated the plan logic against real data tonight; the agent geocoded, checked sunset and weather, and reasoned over them rather than filling a template.

Prize Categories

Overall