DEV Community: Ankit Pandit

Slow and Steady: An AI Assistant That Leaves You Less to Do

Ankit Pandit — Sun, 25 Oct 2026 17:58:45 +0000

A note on your phone. A reminder in a chat. A file saved somewhere because you'll “deal with it later.” None of these looks like much on its own. Put them together, though, and catching up becomes a chore.

The Hacktoberfest “Slow and Steady” theme is a good excuse to think about that kind of problem. What would an AI assistant look like if its main job were to leave you with less to do?

Here's one idea: a quiet little assistant that turns scattered notes into a short daily catch-up. This is still a concept. There isn't a working app, demo, or set of results behind it yet.

Start with the notes, keep the output short

You would give it the notes you want help with. It would pull out what needs attention, what can wait, and anything too vague to act on.

“Ask about the repair quote on Friday” is fairly clear. “Sort out the booking” isn't. A useful assistant should notice the difference. It could flag the second note for a quick check instead of guessing a date or deciding what booking you meant.

Each suggestion should come with the original text beside it. Nobody should have to dig through a pile of notes just to find out why an assistant put something on their list.

And the list needs to stay short. Turning ten messy notes into a beautifully formatted wall of text hasn't really helped.

Why use open AI?

For this idea, the aim would be to run an open-weight model on the person's own computer. No particular model has been picked or tested yet.

Being able to change the model and adjust how it handles notes would be useful. Someone with an older laptop might need a different setup from someone with more powerful hardware. People also have different ideas of what deserves a reminder.

Keeping personal notes on the device would be another goal. That would need checking in the actual implementation, including any software around the model. Running a model locally alone doesn't prove that the whole app keeps everything private.

It needs to save more effort than it creates

The real test would be ordinary: is reading and correcting the digest quicker than going through the notes yourself?

If it misses an important task, invents a deadline, or needs constant babysitting, a fast response isn't much of a win. Those mistakes would need to count when measuring whether it helps.

It should also stop at suggestions. Preparing a reminder is one thing; sending a message or deleting a file is another. You should get to decide when something actually happens.

A small enough idea to be useful

There's plenty to figure out before this could work well. Even a small pile of notes can contain missing context, repeated tasks, and plans that have already changed.

But the goal can stay simple: open a short catch-up, check it, and get on with your day. A few fewer things to keep in your head would be a worthwhile result.

Fieldnotes AI: a local evidence copilot for maintenance teams

Ankit Pandit — Sat, 17 Oct 2026 07:29:08 +0000

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

What I Built

A maintenance question often has several answers scattered across an inspection note, a shift log, a work order, and a manual. Fieldnotes AI is a small, local copilot that brings those records together for a person reviewing an asset. It retrieves relevant records, flags contradictory numeric readings, and asks an open-weight model to produce an answer with record IDs and caveats.

The potential customer is a small maintenance contractor or asset team that spends time reconciling inspection and operations records but cannot casually send client records to a third-party AI service. A paid version could help them search their own records, surface disagreements, and prepare evidence for human review. That is a proposed use case, not a claim of paying customers or validated demand.

The included demo uses fictional records. For Aster 17, an inspection lists tubing pressure at 182 bar while a same-day operations log lists 147 bar. A valve work order is still pending. The app surfaces that disagreement instead of picking a value or claiming that the repair is complete. It does not make safety or engineering decisions.

Demo

The demo runs locally; there is no public hosted dashboard or video yet. To open it on your machine, follow the quick start in the repository: install Node.js 20+ and Ollama, pull the default Qwen3 model, then run:

ollama pull qwen3:8b
git clone https://github.com/AnkitPandit120/fieldnotes-ai.git
cd fieldnotes-ai
npm run demo

Open http://127.0.0.1:4173 on that same machine. The asset overview and conflict watch use the sample records without a model; answering questions needs Ollama running locally. A local URL is not a public demo link.

Code

Fieldnotes AI on GitHub is MIT licensed. It contains the Node.js package and CLI, local dashboard, fictional sample data, and setup guide. The package has no runtime npm dependencies.

How I Built It

Validate structured JSON records and connect each one to an asset.
Rank records with transparent keyword matching across asset names, IDs, titles, text, and source labels.
Compare measurements for the same asset, date, and metric. Values that differ by more than 5% become a conflict for review.
Send only the selected records and detected conflicts to Qwen3 through local Ollama inference.
Require the model to return structured JSON with an answer, record-ID citations, caveats, and a suggested follow-up. Reject citations that do not match retrieved records.

The source list proves which records were supplied to the model; it does not prove that every generated sentence is correct. Keyword retrieval can miss synonyms, and the demo reads structured JSON rather than parsing PDFs or CSVs. Those are the next areas to improve. I have not run automated tests or a user study for this prototype.

Why Does Open Innovation Matter?

The default runtime can stay on a team's machine: Ollama serves an open-weight Qwen3 model locally, and the app sends its evidence to that local endpoint rather than a hosted model API. After the model is downloaded, questions do not require an AI API key. Teams can choose another installed model without rewriting the evidence pipeline. Local inference still has hardware and operating costs, so I am not claiming that it is free.

That control matters for a niche workflow where records may be sensitive and the format of evidence is as important as a fluent answer. The project keeps retrieval, conflict rules, prompts, and citation checks visible in source code so a team can inspect and adapt them.

Related reading: Local RAG: Chat With Your Documents by Lingdas1 and RAG Beyond the Demo: Pipeline, Citations, Evaluation, and When Not to Bother by Xinyang Wu discuss local document workflows and the limits of citations.

Disclosure: Codex helped implement this prototype and draft this post.

ListSmith: Turning Product Photos Into Better Listings With Open Models (Concept)

Ankit Pandit — Tue, 13 Oct 2026 21:30:19 +0000

A concept for the Hacktoberfest Open-Source AI Challenge: Week 2 — Side Hustle. ListSmith has not been built or deployed yet; the workflow below is the proposed design.

The problem

Writing the fortieth product listing of the week is tedious for a solo seller. A thrift reseller, ceramics artist, or vintage dealer may have good photos and accurate product knowledge but little time to turn them into consistent listings.

ListSmith

ListSmith is a proposed open-source listing writer for small online sellers. A seller would add two to five photos of an item, review facts extracted from the images, and get an editable title, description, key details, and suggested tags for Etsy or eBay. The seller would confirm anything the photos cannot prove, including material, age, condition, and visible flaws.

A separate comparable-price panel could use live market data to suggest a range. Listing copy and market data would remain separate so the model does not invent a price.

Who it is for

Solo Etsy and eBay sellers, thrift and vintage resellers, and small craft businesses who want consistent listings without hiring a copywriter or sending every product photo to someone else's server.

The open-source code could be free to self-host. Potential paid services are a hosted version, setup help for sellers who do not want to run software, and custom brand-voice configuration for shops with an established style. These are business ideas, not services currently offered.

Proposed workflow

Upload photos.
A vision-capable open-weight Gemma model extracts visible product facts and flags uncertainty.
If enabled, SerpApi retrieves comparable listings and search terms.
Gemma drafts a listing using the verified facts and examples of the seller's existing brand voice.
The seller edits and copies the final listing into their shop.

The proposed interface includes drag-and-drop upload, side-by-side editing, Etsy and eBay copy formats, and a batch queue. A Render deployment could handle saved profiles and queued jobs, while a local model option would keep photos on the seller's own machine. These integrations are planned, not implemented.

Why open innovation matters

Small sellers often work on narrow margins. Running an open-weight model could make listing costs more predictable than a per-image API and let a seller process a large batch without watching a usage meter. A self-hosted option would give sellers more control over unlisted inventory photos and sourcing details. Open weights also leave room for category-specific tuning and model changes as better options appear.

What needs to be tested

The key question is whether the model can produce useful copy without inventing product claims. A first prototype should test a small set of real products, measure how much editing sellers still do, and ask whether that time saving is worth paying for. Price suggestions would also need clear comparable sources and human review.

Current status: Concept only. There is no demo, public repository, or first-user result yet.

Outside, briefly: a tiny offline AI coach for getting off the screen

Ankit Pandit — Tue, 06 Oct 2026 18:58:42 +0000

What I Built

I built Outside, briefly, a small outdoor activity planner. You describe your mood in a sentence, choose how much time you have, and get a short mission that sends you outside. The goal is for the screen to be the shortest part of the experience.

I noticed a problem with many wellness apps: even when they encourage a walk, they ask you to keep checking the phone. I wanted the planning step to end quickly. The result gives you a handful of concrete steps and a question to think about when you return. You can print or save the mission card and leave the browser behind.

It offers four kinds of mission: noticing nature, moving, caring for a place, and connecting with someone. There is an accessible or seated option.

Demo

Try the live demo. Type “I want a peaceful walk with birds and trees” to see a noticing mission.

Another example: “I want to water plants in my garden” produces a care mission. The result shows which words influenced the model, so the recommendation is not a mysterious instruction.

Code

View the MIT-licensed source code.

How I Built It

The AI core is a transparent, locally trained multinomial Naive Bayes classifier. Forty labeled example phrases in model.js teach it the four outing types. The model turns input into word tokens, counts how often each token appears in the example phrases, applies Laplace smoothing, and estimates which outing type best fits the sentence. The interface shows matched words so its decision is inspectable. The result is assembled from short mission steps, adjusted for time and accessibility. This is intentionally a small classifier, not a language model.

For instance, words such as “birds,” “trees,” and “listen” point toward notice; “water,” “plants,” and “garden” point toward care. The model is the core decision-maker. Mission steps are written by a human so they remain short, practical, and bounded. If the sentence is vague, the app still makes a best guess and lets you try again.

flowchart LR
  A[Your sentence] --> B[Local word tokenizer]
  B --> C[Open Naive Bayes model]
  C --> D[Mission type]
  D --> E[Time and access adjustments]
  E --> F[Short mission card]

The app is plain HTML, CSS, and JavaScript with no build step or API key. A service worker caches its files after the first visit, allowing the same flow to work offline. There is no geolocation request, analytics call, or account. The initial visit still needs a connection so the browser can download the files; I did not want to imply otherwise.

Why Does Open Innovation Matter?

The model, training examples, and mission rules are all in the public code. Anyone can see what it learned, improve examples for their own community, or replace the classifier without depending on a hosted AI service. The small local model also lets people plan an outing without sending personal text or location to a server. It works without a signal after the first visit.

There is a tradeoff: 40 example phrases do not cover every way someone describes a mood, and the model cannot know local weather, route safety, or accessibility of a particular path. I chose to keep the app small and honest about those limits. Contributors can add phrases, translate the examples, or replace the classifier while keeping the same simple interface. That openness matters more here than producing an elaborate but opaque recommendation.

What Happened Outdoors

I tested all four model intents and the 10-minute accessible mission in automated tests. I also used the live site in Chrome with a gardening prompt and confirmed that it produced the care mission. I have not yet taken a mission outside, so I cannot claim an outdoor field test. That is the next meaningful test: whether the instructions are useful once the screen is away.

Prize Categories

Overall challenge only. No partner technology is claimed.