DEV Community: utkarsh sonawane

I held a séance with dead programming languages — meet seance 👻

utkarsh sonawane — Mon, 26 Oct 2026 20:44:33 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

seance is a small Python CLI that lets you ask a question and get an
answer from the ghost of a long-dead programming language — COBOL (1959),
FORTRAN (1957), BASIC (1964), or ALGOL (1958). Each spirit answers in its
own voice: COBOL in formal ALL-CAPS divisions, FORTRAN in terse numerics
and GOTOs, BASIC in friendly numbered lines, ALGOL in precise
begin/end blocks.

It takes the Week 4 theme two ways at once: it is spooky (a séance, on
Halloween week), and it honors the past (the languages that built
computing, remembered in their own words, in the spirit of Día de los
Muertos).

Repo: https://github.com/sonawaneutkarsh/seance

Demo

Real runs, offline mode, no model needed:

$ python3 -m seance "Will my code outlive me?" --spirit cobol --offline
The spirit of COBOL (1959) speaks:
PROCEDURE DIVISION. I HAVE READ YOUR QUERY, AND I HAVE FILED IT.
Your question — "Will my code outlive me?" — echoes in the machine room.
The dead answer in formal, procedural, ALL-CAPS divisions.
END PROGRAM. I return to the mainframe now. It never sleeps.

[source: offline fallback (deterministic)]

$ python3 -m seance "Why did you disappear?" --spirit basic --offline
The spirit of BASIC (1964) speaks:
30 REM I HAVE BEEN WAITING SINCE 1984. ASK AWAY.
Your question — "Why did you disappear?" — echoes in the machine room.
The dead answer in friendly, numbered lines, eager to help.
GOTO 10. The loop closes. The loop always closes.

[source: offline fallback (deterministic)]

Code

seance/spirits.py — the four spirits and the deterministic fallback
seance/ollama_client.py — minimal stdlib Ollama client
seance/__main__.py — the CLI: summon, list spirits, offline mode
tests/test_seance.py — 9 tests, all passing (Ollama mocked)

How I Built It

The question goes to Gemma, running locally through Ollama, prompted
to answer in the chosen spirit's voice. No accounts, no API keys, no
question leaves your machine. And because a séance should work with the
lights off, there is an honest offline fallback: when no model is
reachable, lines are picked by hashing (spirit, question), so the same
question always summons the same answer — and the reply always labels
its source, so a fallback is never passed off as AI.

Why Does Open Innovation Matter?

The whole project only works because the pieces are open. Gemma is an
open-weight model I can run on my own laptop, so communing with the past
does not mean uploading my questions to someone else's server — and the
dead languages themselves are the original open inheritance: ALGOL's
ideas live on in nearly every language used today precisely because they
were shared, not locked away. A closed model behind an API could vanish
tomorrow and take the séance with it; a local open-weight model and a
stdlib-only codebase will still answer in ten years. The past, kept
open, stays reachable.

Prize Categories

Best Use of Gemma — Gemma (via local Ollama) powers the AI séances.

Tags: #devchallenge #hf26challenge

I built a sloth that cleans my Downloads folder — meet slothsort 🦥

utkarsh sonawane — Mon, 19 Oct 2026 22:10:01 +0000

I built a sloth that cleans my Downloads folder — meet slothsort 🦥

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

What I built

slothsort is a small Python CLI that tidies a messy folder for you. Point it at your Downloads directory — you know the one, with Q3-budget-final-FINAL.xlsx living next to screenshot 2026-10-19.png and an installer from 2024 — and it sorts everything into tidy category folders: Documents, Images, Videos, Audio, Archives, Installers, Code, and friends.

The twist: the sorting decisions are made by Gemma, running locally through Ollama. No accounts, no API keys, no filenames leaving your machine. And because sloths plan for every contingency, there's an honest offline fallback — when no model is reachable, deterministic extension rules do the sorting instead of an error message.

Repo: https://github.com/sonawaneutkarsh/slothsort

Demo

Here's a real run — offline mode, on a folder of 12 genuinely messy files:

$ python3 -m slothsort /tmp/messy-desk --offline
slothsort would move 12 file(s):

  [Archives]
    backup-2024.zip
    font-pack.zip
  [Audio]
    podcast-ep12.mp3
  [Documents]
    meeting-notes.txt
    todo.md
  [Images]
    grandma-recipe-scan.jpg
    screenshot 2026-10-19.png
  [Installers]
    installer-v2.4.1.exe
  [Other]
    app-debug.log
  [Presentations]
    slides-pitch-deck.pptx
  [Spreadsheets]
    Q3-budget-final-FINAL.xlsx
  [Videos]
    vacation-clip.mov

Nothing moved (dry run). Re-run with --yes to apply, or --undo to revert the last run.

That's the whole pitch: one command, zero decisions, twelve files filed. The dry run is the default — slothsort shows you the plan and moves nothing until you say --yes. Changed your mind afterward? --undo puts every file back exactly where it was.

With Ollama running (ollama pull gemma3, then drop the --offline flag), filenames the rules don't recognize get classified by the model instead — app-debug.log stops landing in Other and gets filed where it actually belongs.

How it works

The architecture is deliberately boring, in the good way:

Scan. Lists the files in your folder (top level by default; --recursive descends but never re-sorts folders it already created).
Classify. Each filename goes to localhost:11434 — Ollama, plain HTTP, stdlib only. Default model is gemma3. The model must reply with exactly one category name; anything else — a sentence, an invented category, an empty reply — is rejected and the extension rules take over. The model never gets to invent folders.
Preview. Dry-run prints the full plan grouped by folder. Nothing moves until --yes. Laziness, but make it safe.
Apply + undo. Moves are collision-safe (a second a.pdf becomes a (2).pdf, never overwritten), and every run writes a .slothsort-manifest.json so --undo reverses the whole thing.

The full test suite (19 tests, python -m unittest discover -s tests) covers the extension bands, model-reply validation, fallback behavior, plan building, collision handling, the apply/undo round-trip, the CLI, and the Ollama HTTP layer with mocks — no server needed to verify.

The lazy payoff

The challenge asked for the lazy payoff, so here are the numbers from the demo above: 12 files → 9 folders, 1 command, 0 decisions made, 0 files deleted, and a one-command undo if I don't like where anything landed. The dreaded "I'll organize Downloads this weekend" task now takes eleven seconds, most of which is reading the preview.

Why open innovation matters for this build

This project only makes sense because the AI is open:

Your filenames are personal data. A cloud API sorting your Downloads folder would see every bank statement, medical form, and half-written novel title you own. With local inference, none of it leaves your machine — there is no trust decision to make, which is exactly the point of automating something this personal.
Free forever. Sorting files is precisely the kind of tiny automation a per-token API would make silly to pay for. Open weights make the lazy option the free option: set it up once, nap forever. No accounts, no keys, no subscriptions to babysit — very on-brand for Sloth Day.
Models are swappable, not load-bearing. Don't like Gemma's filing instincts? --model llama3.2 and you're done — no code changes, no renegotiating with a vendor. The deterministic core (extension rules, preview, collision handling, undo) stays identical no matter which weights you plug in.

A closed model could file your PDFs. It couldn't do any of the three things above. That's the whole argument.

What I'd do next

A --watch mode that tidies new downloads as they land, content sniffing (so app-debug.log is classified by what's inside it, not its name), and per-folder rules you can teach it once ("always put screenshots in Images/Screenshots"). All doable without touching the core.

Prize categories

Overall
Best Use of Gemma — Gemma (via Ollama) is the default classifier; the prompt design, strict reply validation, and model-swap architecture are built around it.

Built October 19, 2026 for the Hacktoberfest Week 3 DEV Challenge ("Slow and Steady"). Tags: #devchallenge #hf26challenge

I Fine-Tuned a 4B Model to Write Etsy Listings That Actually Rank

utkarsh sonawane — Tue, 13 Oct 2026 00:49:47 +0000

I Fine-Tuned a 4B Model to Write Etsy Listings That Actually Rank

An open-weights side hustle: turning rough seller notes into optimized Etsy titles, descriptions, and tags — and proving the fine-tune beats the base model.

Every Etsy seller knows the feeling. You have created something wonderful — a hand-poured candle, a vintage tee, a printable wall art — and now you have to describe it on Etsy. Title: 140 characters to encompass every search term a buyer can think of. Description: persuasive but easy to scan. Tags: 13 carefully chosen terms, each one a bet on how strangers search.

Most sellers either stuff keywords until the title reads like a ransom note, or write something poetic that no search algorithm will ever find. I kept thinking: this is a narrow, well-defined text task with tons of examples floating around. It's exactly the kind of thing a small fine-tuned model should be good at.

So for DEV's Hacktoberfest Week 2 challenge (theme: Side Hustle), I built ListCraft — an Etsy listing optimizer powered by a LoRA fine-tune of Qwen3.5-4B on Tinker, Thinking Machines' fine-tuning API. Paste in rough notes about your product; get back an optimized title, description, and tags. And critically: I measured whether the fine-tune actually helped, instead of just assuming it did.

Why fine-tune instead of just prompting?

The honest answer: I wanted to find out if it matters. A base instruction model can already write a decent product description. But Etsy's format has sharp edges — titles need to land in a 120-140 character sweet spot, keyword phrases are pipe-separated, and you need exactly 13 tags. These are conventions a model won't reliably follow from a prompt alone, and stuffing all of it into a system prompt eats context on every single call.

Fine-tuning bakes the format in. The bet: a 4B model with the format burned into its weights beats a much larger prompted model at this specific job — and it's cheap enough to serve that a real side hustle could afford it.

The data

I used the public listybox-etsy-listing-parquet dataset (536 real listing pairs), split 90/10 with seed 42 → 483 training pairs, 53 held out for eval. Each pair maps rough seller notes (product concept, themes, audience, use cases) to a finished listing.

One important note: the source dataset declares no license, so I'm not redistributing the data. The repo ships the code, the eval protocol, and a rebuild script — anyone can download the source dataset themselves and reproduce everything. Open science shouldn't need a lawyer.

Training on Tinker (including the run that collapsed)

Tinker is Thinking Machines' fine-tuning API — you bring a script, it brings the GPUs. I trained Qwen3.5-4B with LoRA rank 32, Adam at 1e-4, batch size 4, for 2 epochs. Total cost: a few dollars of a $10 credit.

Here's what most write-ups don't tell you: my first training run produced a collapsed model. The loss decreased to ~3e-5, which sounded great until I sampled from it and got infinite repetitions of a single token ("izingizingizing..."). The problem was in how I'd constructed my datum — Tinker's cross_entropy doesn't shift labels internally, and I'd fed it unshifted sequences, so the model learned the identity mapping: predict the current token. A perfect loss on a meaningless task.

I caught it by reading Tinker's cookbook source, fixed the shift (model_input=toks[:-1], target_tokens=toks[1:]), and retrained from scratch. The healthy run went 1.17 → 0.36 mean NLL, smooth, no collapse. Lesson relearned: a loss curve that looks too good is usually lying to you. Sample early, sample often.

Does the fine-tune actually help? (measured, not vibes)

On the 53 held-out listings, base model vs. fine-tuned, greedy decoding:

Metric	Base Qwen3.5-4B	Fine-tuned
Keyword coverage	0.77	0.93
Titles in 120–140 char sweet spot	0%	83%
Mean title length	2,591 chars	136 chars
Keyword phrases per title	1.2	4.0
Outputs with a TAGS section	0%	100%

The base model doesn't just underperform — it fails at the task structurally. Zero-shot, it rambles for thousands of characters and never emits the tag section. The fine-tuned model learned the format cold.

Then the blind test: I had Qwen3-8B judge base vs. fine-tuned outputs without knowing which was which, on title SEO, description quality, and tag relevance. The fine-tuned model won 35 of 44 overall judgments (5 for base, 4 ties). It swept title SEO 42–2 and tags 41–2. Descriptions were essentially tied (20–24) — the fine-tune learned Etsy's format, not better prose, and I'm not going to pretend otherwise.

And the honest caveat: the fine-tuned model over-generates tags — about 66 per listing vs. 13 in the references. It learned the shape of a tag list but not when to stop. That's a real limitation, and it's the next thing I'd fix (a length penalty or stop-sequence tuning).

The demo

There's a Gradio demo in the repo with a side-by-side view: type (or pick a preloaded example of) rough seller notes, and see the base model's rambling output next to the fine-tuned model's structured listing. That comparison is the pitch — it's the clearest possible demonstration of what the fine-tune bought.

cd demo
pip install -r ../requirements.txt
python app.py

Why open innovation matters here

Everything in this project is open: the base model weights (Apache 2.0), the training and eval scripts, the metrics, the failure story. Tinker itself is built around open-weight models. A year ago, fine-tuning a model for a niche task like this would have meant either a big GPU bill or a closed API that could change under you. Now a student can do it on a $10 credit in an afternoon, measure the improvement rigorously, and hand the whole thing to someone else to reproduce.

That's the side hustle thesis, too. The moat for a tool like ListCraft was never the model — it's the workflow, the eval, the understanding of what Etsy sellers actually need. Open weights commoditize the intelligence; the product is everything around it. If I were turning this into a real business tomorrow, I'd start with the sellers, not the model card.

What's next

Fix tag over-generation (stop sequences / length penalties)
Try a larger rank or full fine-tune to see if description quality moves
Talk to actual Etsy sellers (the genuine first user this project deserves)
Package it as a real hosted tool

Repo: https://github.com/sonawaneutkarsh/listcraft — code, eval protocol, and reproduction instructions are all public. The $10 of Tinker credit bought something I couldn't have gotten from prompting: a small model that reliably does one job well — and the receipts to prove it.

Tags: #devchallenge #hf26challenge

I built a hiking guide that runs on a laptop with no internet — meet trailbrief

utkarsh sonawane — Sat, 10 Oct 2026 20:25:55 +0000

What I built

trailbrief is a small Python CLI that writes you a personalized hiking briefing. You tell it the trail — name, distance, elevation gain, location, season, your experience level — and it hands back a practical plan: an overview, a pacing plan, a season-aware pack list, watch-outs, and a Leave No Trace reminder.

The twist: the briefing is written by Gemma, running locally through Ollama. No accounts, no API keys, no data leaving your machine. And because the whole point is getting outside, there's a proper offline fallback — when no model is reachable (read: you're already on the trail with zero bars), a built-in template engine still produces a genuinely useful briefing instead of an error message.

Repo: https://github.com/sonawaneutkarsh/trailbrief

Demo

Here's a real run — offline mode, since I don't have a GPU farm in my dorm:

$ python3 -m trailbrief \
    --name "Ricketts Glen Falls Trail" \
    --distance 7.2 --elevation 1200 \
    --location "Benton, PA" \
    --season fall \
    --experience intermediate --offline

# Trail Briefing: Ricketts Glen Falls Trail
*Benton, PA · 7.2 mi · 1,200 ft gain · Fall · Moderate*

## Overview
A moderate day out: 7.2 miles and 1,200 ft of gain asks for steady pacing and a real lunch stop. Expect about 4.2 hours of moving time, plus stops.

## Pacing plan
Start no later than 8 AM — with 4.2 hours of moving time plus breaks, you want a buffer before dark.

## Pack list
- Insulating mid-layer — temps swing 20°F+ through the day
- Headlamp with fresh batteries (shorter days sneak up on you)
- Bright colors — it's hunting season in many areas

## Watch-outs
Daylight is the constraint: sunset comes early and temperatures drop fast once the sun dips. Leaf-covered rocks are slippery.

With Ollama running (ollama pull gemma3, then drop the --offline flag), the same inputs go to the model instead — with a twist I'll get to below.

How it works

The architecture is deliberately boring, in the good way:

Deterministic core. Difficulty and moving time are computed from your numbers with a Naismith-style rule (2 mph + 30 min per 1,000 ft of gain). No vibes, just arithmetic.
Grounded prompt. Those computed numbers are baked into the prompt, and the model is explicitly told to use them and not invent trail features, facilities, or water sources. This is the part most "AI hiking apps" get wrong — a chatbot happily hallucinating a water fountain at mile 6 is how people get hurt.
Local inference. The prompt goes to localhost:11434 — Ollama, plain HTTP, stdlib only. Default model is gemma3.
Honest fallback. Model unreachable? The template engine takes over with season-aware packing (fall gets headlamp + hunter-orange reminders, winter gets microspikes), elevation-aware safety notes, and experience-level tips.

The full test suite (12 tests, python -m unittest discover -s tests) covers the difficulty bands, prompt grounding, fallback content, and the Ollama HTTP layer with mocks — no server needed to verify.

Why open innovation matters for this build

This project only makes sense because the AI is open:

It works where the internet doesn't. A cloud API can't brief you on a ridgeline with no signal. A 3–9B open-weight model on your laptop can. The "touch grass" theme isn't decoration here — offline capability is the entire point, and only open weights make it possible.
Your location stays yours. Where you hike is personal data. With local inference, your trail plans never touch a server you don't control.
It costs nothing to run. No per-token billing for a hobby tool you use twice a month. The economics of a closed API would kill this project; open weights make it free forever.
Models are swappable, not load-bearing. Don't like Gemma's briefing style? --model llama3.2 and you're done — no code changes, no renegotiating with a vendor. The deterministic core (difficulty math, grounding, fallback) stays identical no matter which weights you plug in.

A closed model could write a prettier paragraph. It couldn't do any of the four things above. That's the whole argument.

What I'd do next

Trailhead weather overlays, GPX import so distance/elevation come from the file instead of your memory, and a --compare mode that briefs the same trail with two models side by side. All doable without touching the core.

Prize categories

Overall
Best Use of Gemma — Gemma (via Ollama) is the default briefing engine; the prompt, grounding strategy, and model-swap design are built around it.

Built October 10, 2026 for the Hacktoberfest Week 1 DEV Challenge ("Touch Grass"). Tags: #devchallenge #hf26challenge