DEV Community: SUNNY TIWARI

LeaveNote: an AI that writes your handover note so tomorrow-you can be lazy

SUNNY TIWARI — Sun, 25 Oct 2026 13:11:23 +0000

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

What I Built

LeaveNote is for the moment you stop coding mid-task. You paste your git diff plus one line about what you were doing, and it writes the handover note: what changed, what's unfinished, the first thing to do tomorrow, and what to watch out for - leftover TODOs and debug lines included.

Rebuilding your own context the next morning is the most boring part of coding. LeaveNote captures it before you close the laptop, so tomorrow-you reads one note and starts. That is the laziness this week asked for.

Demo

Live: https://leavenote-app.netlify.app

The AI needs WebGPU (a recent Chrome or Edge on a device with a supported GPU). Devices without it get an honest message and a manual template - never a fake demo. The model downloads once (a few hundred MB) and then stays cached in the browser.

Note: the live demo currently serves the first version, where the model writes all four sections. The v2 redesign described below is on a pull request and the demo updates when it lands.

Screenshots

The current live demo (v1), on desktop and on a phone:

The v2 code on PR #1 (not merged yet - its prompt is validated against the real model weights on CPU, but it has not run in a browser end-to-end):

Code

Repo: https://github.com/Sanny1921/leavenote - the v2 rework is on PR #1: https://github.com/Sanny1921/leavenote/pull/1

The whole app is one index.html plus a two-line WebLLM worker. The heart of v2 is this split:

// The app, not the AI, finds the facts in your diff.
function todosOf(files){
  const out=[];
  for(const f of files)for(const l of f.added){
    if(/\b(TODO|FIXME|HACK|XXX)\b/.test(l))out.push(f.name+': '+l);
  }
  return out;
}
// UNFINISHED and WATCH OUT are built from these, never from the model.
// The model only phrases CHANGED and a suggested TOMORROW first step.

How I Built It

The AI is Qwen2.5-0.5B-Instruct (Apache 2.0) running fully in the browser through WebLLM (Apache 2.0). No server, no API key, no account, no analytics. Your code never leaves your device.

The first version asked the small model to read a raw diff and write all four sections. It failed the way small models do: it once reported a leftover TODO as done. A bigger model might fix that, but I wanted to keep the download at a few hundred MB, so I shrank the model's job instead:

Plain JavaScript parses the diff first: file names, added and removed line counts, TODO/FIXME markers, console.log and debugger lines.
The UNFINISHED and WATCH OUT sections are built from that direct reading: they quote recognized markers (TODO/FIXME, console.log, debugger) verbatim instead of letting the model paraphrase them. The parser only recognizes those markers, so unmarked half-done work can still slip past it - the note is a memory aid, not a guarantee.
The model only writes the two lines it handles well: a plain-English summary of what changed, and a suggested first step for tomorrow, phrased from the facts it is handed.
Checks reject malformed answers and "nothing to do" replies when TODO flags exist. Each line falls back to the parsed version if needed, and the note's footer says exactly which lines are AI-written and which are parsed.

I validated the prompt pipeline against the real Qwen2.5-0.5B-Instruct weights on CPU: 3 out of 3 test diffs produced the required two-line format. The in-browser inference path (WebLLM on WebGPU) is unchanged from the first version, which ran on my phone.

Why Does Open Innovation Matter?

The whole point of LeaveNote is that your code stays yours. A closed API means pasting your private repo's diff onto someone else's server and trusting their retention policy. Because the model is open-weight and runs locally, the diff never leaves the device - no account, no logs, nothing to leak. It costs nothing to run, works offline after the first download, and anyone can swap Qwen2.5 for another open model by changing one constant.

The Lazy Payoff

Five to ten minutes of "wait, what was I doing?" saved every time you pick a project back up, and fewer debug lines surviving into the next session because the note calls them out.

CutBrief: the paid edit should not start with a guessing game

SUNNY TIWARI — Fri, 16 Oct 2026 21:30:00 +0000

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

What I Built

"Make it engaging. Add captions. Something clean."

That is a message, not an editing brief. It does not tell an editor which footage to use, what the opening should do, or what the viewer should do next. When the first cut fills those gaps differently from the client, the revision starts before the real work has settled.

I run a short-form editing agency. For this week's Side Hustle theme, I chose a problem close to the work: getting from a rough client request to a handoff an editor can actually use.

CutBrief is a small browser tool. Paste a request, select an editing direction, and a local open-weight model suggests a hook, cut plan, caption notes and a CTA check. The result is editable and downloadable as plain text.

The important choice is what it does not blend together:

The client's exact request stays at the top.
AI ideas are labeled as suggestions, not client instructions.
A fixed checklist asks about assets, deadlines, scope, revisions, rights and fees.

The model does not quote a price, promise results, contact the client or edit the video. It helps prepare the brief. The editor still owns the decisions.

The buyer hypothesis is a freelance editor or small editing studio doing repeated short-form work. They would pay for a better handoff if it reduces clarification and rework. I have not validated that hypothesis with a paying customer. A plausible product is a one-time studio setup with its own brief format and vocabulary, rather than another per-token subscription. That is a business idea to test, not revenue I have earned.

Demo

Try it here: https://sanny1921.github.io/cutbrief/

The first load downloads model files (hundreds of MB) and needs a WebGPU-capable browser, so older phones may not work. Nothing is sent to an inference server.

The included cafe request is fictional. It asks for a 30-second brunch reel, a warm style, food close-ups, licensed music and a visit-us CTA. It is example input, not customer feedback.

The intended flow is: load model, paste request, generate, review against the original, edit, then export. The two review boxes are a reminder to check facts and the final agreement, not a claim that the model can verify them.

Code

Repo: https://github.com/Sanny1921/cutbrief (public, MIT). The README lists the limits.

The app code is MIT licensed. Qwen and WebLLM have their own Apache 2.0 licenses and are credited below. CutBrief is a new Week 2 project, not a change to my Week 1 app.

How I Built It

The UI is HTML, CSS and JavaScript, with inference in a module worker so model work does not need to block the interface. It uses Qwen2.5-0.5B-Instruct, an open-weight model from the Qwen team, through WebLLM 0.2.84, MLC's open-source in-browser inference engine. The selected MLC build is Qwen2.5-0.5B-Instruct-q4f32_1-MLC.

The prompt is deliberately narrow. It asks for four short sections and tells the model not to invent client facts, prices, offers or guarantees. User input is marked as request data. That reduces accidental instruction mixing, but it is not a guarantee against bad output. The app keeps the original source visible so the person reviewing has something to check.

A small model is a tradeoff. It is cheaper to load than a much larger model, but it is not a reliable substitute for an experienced editor. The product is useful only if reviewing its ideas is less work than writing the handoff from scratch.

What has actually been tested

The responsive UI was checked at 320px, 390px and desktop widths. Example loading and clearing work. In a test with an explicitly labeled model substitute, edited output exported exactly and the review gate blocked unchecked export. That checks the app mechanics, not the quality of AI.

I also ran it on a real phone: a Motorola edge 60 pro in Chrome on Android. The model downloaded and loaded, and I loaded the fictional cafe example and tapped "Make an editing brief". It produced a real AI-generated brief with the client's exact request at the top, the selected direction, and a separate "AI SUGGESTIONS (not confirmed client instructions)" section. The screenshots below are from that run.

That is one device and one fictional example. It shows the whole local flow can work on a current Android phone. It does not show that the suggestions are good, that other phones will cope, or how fast it runs on them. I did not benchmark it. Earlier, on a software GPU, completion did not finish within my bounded test, so hardware matters.

Why Does Open Innovation Matter?

The brief may contain a client's unreleased offer, creative direction or launch plan. For a text task this small, shipping those words to a hosted model should be a choice, not the only way the product works.

With local inference, the client request is passed to the model in the browser. The app has no message database, analytics or inference server. Hosting, JavaScript-CDN and model servers still receive ordinary file requests and IP metadata. The first model download needs internet, and I do not claim that a page reload always works offline.

Open weights also change the cost structure. There is no hosted-model charge for each generated brief. That does not make the product free to operate: the user's device, storage, electricity, setup and support still cost something. It does make a one-time studio tool more plausible without attaching a token bill to every client's request.

The model and prompt can be changed without rewriting the handoff workflow around one proprietary inference provider. Qwen's Apache 2.0 license and WebLLM's Apache 2.0 license make that path inspectable. I have not fine-tuned this model; studio-specific tuning is a future option, not an implemented feature.

The open approach is better for this design's data boundary and per-request API costs. I have not demonstrated that it writes better briefs than a closed model. A larger hosted model might produce stronger suggestions and work on more devices. Local inference has a real entry cost: hundreds of MB to download, a WebGPU-capable browser, and hardware-dependent speed.

That is the constraint I want to test honestly. A small, private draft assistant might be enough for the handoff. It does not need to become a video editor or a general chatbot to earn its place.

Credits

Qwen2.5-0.5B-Instruct model card and its Apache 2.0 license.
MLC model conversion.
WebLLM, Apache 2.0, by the MLC team.

Built with AI assistance. Customer validation is still a next step. No first-user, payment or partner-prize claim is included.

Touch Grass Bingo: an AI that runs in your browser and sends you outside

SUNNY TIWARI — Sun, 11 Oct 2026 20:53:33 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Touch Grass Bingo is a small web app. You type your city or area, pick how much time you have (15 minutes to 2 hours) and a vibe (chill walk, photo hunt, street food and people, nature and wildlife). An open-weight AI model then writes a 5x5 bingo card for you: "Spot a street dog", "Hear a temple bell", "Find a flower".

Then you put the phone in your pocket and go tick the squares off. The middle square is free. Get a line and you get a BINGO.

The idea is simple: the app should be the shortest part of your day. You open it for 30 seconds, then you leave.

Demo

Live app: https://sanny1921.github.io/touch-grass-bingo/

The second screenshot is a real card, generated on my own Android phone in Chrome. It is not a mock.

Code

https://github.com/Sanny1921/touch-grass-bingo

How I Built It

Model: Llama 3.2 1B Instruct, an open-weight model.
Runtime: WebLLM, which runs the model inside the browser on WebGPU.
App: one plain HTML file with no framework, no backend and no API key. It is hosted free on GitHub Pages.

The first time you press "Generate my card", your browser downloads the model (about 700MB). After that it is cached on your device. Everything after that happens on your phone.

The struggle (v1 to v3)

I built this overnight, and the first version did not work on my phone.

v1: I asked the model to return a JSON array of 24 strings. On my phone the model loaded fine, but it kept returning broken JSON. After 3 retries the app gave up and showed a built-in starter card instead. So I had an "AI app" that was not using the AI.

v2: I figured a 1B model is just bad at strict JSON. I changed the contract to a plain numbered list ("1. Spot a street dog") and wrote a forgiving parser. It ignores numbering styles, bullets, markdown and duplicates, and drops junk lines. I also tried a bigger model, Qwen2.5 1.5B. But that was a 1GB download and it kept failing on my wifi with a cache error. Lesson: on a phone, model size is part of the product.

v3: I went back to Llama 3.2 1B, which my phone had already downloaded, and kept the numbered list. I also added a salvage step: the app keeps the best of 3 attempts, and if the model gives at least 14 good squares, it fills the rest from a starter list instead of throwing everything away. I also added retries for the model download and a visible progress percentage.

That worked. The card in the screenshot above came from the model on my phone.

Honest limits: a 1B model writes simple squares, and they can be generic ("Find a flower"). It is not a travel guide. A bigger model would write sharper, more local cards, and that is the first thing I would change with more time.

Why Does Open Innovation Matter?

Your location stays with you. You type where you are. That text goes to a model running on your own phone, not to someone else's server.
It costs nothing to run. There is no API bill, so I can leave it up for anyone. Hosting is a single static file.
I could swap the model. While building this I changed models and prompts several times by editing one line. With a closed API I would have been stuck with whatever it gave me.

What I Would Do Next

Let people pick a bigger model if their phone and wifi can handle it.
Save a card and share it with friends so you can race on the same one.
Use the time and weather to tune the card.

Prize Categories

This project does not use any partner tool. It is an open-weight model (Llama 3.2) running in the browser with WebLLM, so I'm entering for the overall prize.

Thanks for reading. Now go touch some grass.