DEV Community: Kartikey Tiwari

Quiet Catchup: catch up on the chat, then clock out

Kartikey Tiwari — Wed, 21 Oct 2026 16:54:21 +0000

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

What I Built

A group conversation starts with a rooftop lunch for twelve. A few messages later, it is a library lunch for ten. Someone has answered the question about cups, but nobody has checked the entrance ramp. Catching up means separating the final plan from the suggestions it replaced.

Quiet Catchup makes a small, local reading workspace for that job. Paste messages, one per line, and Qwen3 4B produces two summary sentences, a few decisions, and the requests still open. Each item has buttons that open the original messages it cites.

The intended user is someone returning to a busy group chat who wants a starting point before rereading everything. The app does not connect to a messaging account or monitor a conversation. You choose what to paste. You can edit the draft, remove weak items, check its references, and download a text file containing the draft and originals.

The project was created from scratch on October 21, during this challenge window. It is separate from my earlier challenge projects.

Demo

Watch the 56-second silent browser walkthrough.

The recording starts after a real local model reply. It shows opening a source reference, correcting overconfident wording, checking review, and downloading the result. Generation waiting is omitted. An unused gray recording margin was cropped; the application content and action timing were retained.

This is a local application demo. It is not a hosted inference service. All conversations used in testing are fictional.

Code

Source, setup instructions, tests, and verification evidence on GitHub.

Install Python 3.11+ and Ollama, download qwen3:4b, keep Ollama running, then run python app.py and open the printed local address. There are no Python or JavaScript application packages to install. Application code is MIT licensed; model weights are installed separately.

How I Built It

The interface is plain HTML, CSS, and JavaScript. A Python standard-library server numbers the pasted message lines, then sends them to Ollama's local /api/chat endpoint. The structured-output API constrains the reply to a JSON schema.

Pasted messages → numbered lines → local Qwen3 4B
                                → JSON and reference-ID checks
                                → editable draft beside original messages
                                → person reviews → text download

The model does the central interpretation: which plan replaced another, which question has an answer, and what deserves space in a short digest. There is no canned digest if inference fails.

The server checks the reply's structure, item counts, text lengths, and reference IDs. A citation to message 99 in a sixteen-message conversation is rejected. That check is deliberately narrow: an existing message can still be misread.

Two DEV posts helped sharpen that boundary. Ranknod's “Check AI Citations Against Retrieved Source IDs” separates ID validity from claim support. Enhanciar's “Your AI cited a real file. It still lied to you.” examines the gap between a real reference and a supported assertion. This implementation is independent; no code was copied from those posts.

A live failure made the review step concrete. The source said, “I'll adjust the food quantities for 10.” The model wrote that the quantities were already adjusted. Its message references were real, so the structural checks passed.

I added a prompt instruction to preserve future tense. A later browser run still made the same mistake. The demo therefore shows changing the wording to “plans to adjust,” rather than presenting the prompt change as a fix that guarantees correctness. The unedited reply, edited reply, and downloaded text are preserved in the repository.

Thirteen automated tests passed, covering input and output boundaries, malformed and truncated replies, invalid references, HTTP behavior, and unavailable inference. Separate real-model checks preserved a changed meeting time and omitted an already-answered booking question. A disagreement example retained the unresolved time choice, but incorrectly placed “no agreement” under decisions. These are useful examples, not a general accuracy or security benchmark.

Browser checks covered generation, source navigation and keyboard focus, editing, removal, review invalidation, downloads, and source changes clearing an old digest. Planner and result layouts fit a 375-pixel viewport without horizontal overflow.

Why Does Open Innovation Matter?

Qwen3 4B's open weights perform the actual compression and interpretation. Ollama runs them on the same computer as the app. After downloading the software and weights, the inference path uses local endpoints and needs no paid model account.

That is useful for a workflow involving personal messages: you can choose local processing without needing to host a model server elsewhere. The prompt, output contract, and application code are inspectable and changeable. A different local model can be configured, although only Qwen3 4B was tested.

There is a tradeoff. CPU inference is slow on this computer, and open weights do not prevent misleading summaries. The app itself does not store conversations or log their text; exporting explicitly saves the draft and original messages. Browser, operating-system, and Ollama behavior are outside that application-level storage guarantee.

My Agent Session

Codex implemented and tested this project and prepared this article under my instruction to complete and submit the challenge. This article was authored and published autonomously with AI involvement disclosed. No public agent-session transcript is linked. The repository contains the verification record and fictional test fixtures instead.

The Lazy Payoff

The first sixteen-message example contained 175 words. Its generated summary, decisions, and open requests contained 67 words in total. A later run produced 98 words from the same input. The intended payoff is fewer messages to scan before checking the relevant originals.

Those numbers measure compression, not time saved. The first generation took 149.23 seconds; the later browser run took 102.05 seconds. Two shorter live checks took 53.94 and 33.27 seconds. On this hardware, waiting can take longer than reading a short thread.

I have not run a user study or measured a person's time savings. Quiet Catchup is a prototype for reducing repeated reading effort, with visible references and a review step. Whether that tradeoff helps on a particular conversation still needs testing.

Prize Categories

This submission enters the overall challenge. It uses Qwen and Ollama and does not claim a partner prize category.

Brief Ledger: turn client notes into a scope you can price

Kartikey Tiwari — Thu, 15 Oct 2026 13:33:01 +0000

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

What I Built

A client asks for a small website. Their message mixes pages, supplied assets,
"maybe later" features, and a launch date that means something different to
each person. Before pricing the project, a freelancer has to turn that message
into a clear conversation about the work.

I built Brief Ledger, a local workspace for that step. Paste the original
notes, draft a scope with Qwen3 4B, and read each task beside the exact words it
came from. Edit the tasks, remove incorrect items, and change the clarification
questions. Then enter your own hours and rate to download a draft estimate.

The customer I have in mind is an independent web designer or developer who
repeatedly prepares estimates from informal briefs. The business hypothesis is
a paid setup and support service for a local quoting workflow: keep client
notes on the freelancer's computer and reduce the repeated work of building a
scope document. The code is MIT licensed. There is no payment system or paying
customer in this prototype, and I have not validated willingness to pay.

Demo

Watch or download the video walkthrough (MP4).

The walkthrough uses a fictional bakery brief and a real local model reply.
It is assembled from browser screenshots, with generation waiting omitted.
The final browser run took 48.31 seconds to generate the scope on this
computer. It found three pages plus the request for mobile support.

I entered 4, 3, 2, and 3 hours, then a rate of INR 1,500 per hour. The server
calculated INR 18,000.00. Those numbers are demonstration inputs, not a
recommended market price. The downloaded text matched the on-screen draft.

Code

Brief Ledger source on GitHub

The repository includes setup instructions, tests, real-model evidence, browser
captures, and the demo. Run ollama pull qwen3:4b, keep Ollama running, then run
python app.py and open the printed local address. Application runtime needs
Python 3.11+ and Ollama, with no Python or JavaScript packages to install.

How I Built It

The browser is plain HTML, CSS, and JavaScript. A small Python standard-library
server calls Ollama's local chat endpoint with a JSON schema. Qwen3 4B extracts
requested work, explicit exclusions, and questions the freelancer can ask.

Client notes → local Qwen3 4B → JSON + source-quote validation
                                      ↓
                       Human reviews scope, hours, and rate
                                      ↓
                         Decimal calculation → text draft

Every task and exclusion must include a source quote found in the notes.
Truncated output and unreadable JSON are rejected. There is an important limit:
finding the quote does not establish that the model understood it or found
every requirement. The review screen makes that distinction visible.

Two DEV posts helped sharpen the boundary. Edward Amirain's estimator
write-up
keeps price calculations outside the model, while Michael Maurice's extraction
checklist
explains why schema-valid data still needs evidence and ordinary business checks.
Brief Ledger was implemented independently; no source code was copied from them.

Here, the model returns no hours or rate. The freelancer enters both. The server
uses decimal arithmetic, rounds each line to two places, and sums the rounded
lines. It ignores totals supplied by the browser. Changing scope clears review;
changing pricing hides the old estimate until it is recalculated.

The first live bakery run exposed an omission: the model found the pages but
missed mobile support. It also repeated the client's request for an estimate
as a clarification question. I tightened the instructions and reran the same
brief. The revised runs included mobile support and launch/newsletter questions.

A more difficult test still failed semantically. Faced with conflicting
instructions about online payments, the model made resolving that conflict a
deliverable and also listed payments as excluded. It missed an explicit blog
exclusion. The evidence quotes were present in the notes, so substring checks
could not catch those mistakes. That output is preserved in the repository.
This is why the app lets a person remove items and edit questions before export.

Twelve automated tests passed. I also checked real replies for a photographer's
brief, the edited review flow, quote invalidation, the downloaded text, and a
375-pixel phone layout without horizontal overflow. The verification notes
record the exact checks and limits. These examples are not a benchmark of
general extraction accuracy or prompt-injection resistance.

Why Does Open Innovation Matter?

The open-weight model does the central transformation from informal notes to
structured scope. Ollama runs it on the same computer. Once the software and
weights are downloaded, the inference path uses local endpoints and requires
no paid model account. This app has no database, analytics, or cloud inference.
It keeps the working draft in memory; exporting saves a text file.

For this workflow, control over where client notes are processed is useful.
The prompts and validation code can be inspected and changed, and the model
configuration is replaceable, although only Qwen3 4B has been tested here.
Qwen's weights are downloaded separately and retain their Apache 2.0 license.

Local inference also has a cost: waiting on the available hardware and reviewing
the output carefully. Open weights do not make an ambiguous request unambiguous.
The goal is a traceable starting point for the freelancer's judgment.

My Agent Session

Codex implemented and tested this project and prepared this article under my
instruction to complete the challenge. This submission was published
autonomously with AI involvement disclosed. No public session transcript is
linked. The repository contains the verification evidence instead.

Prize Categories

This entry is for the overall challenge. It uses Qwen and Ollama and does not
claim a partner prize category.

Outside Quest: three steps, then put the screen away

Kartikey Tiwari — Wed, 07 Oct 2026 16:01:22 +0000

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

What I Built

Outside Quest turns a small gap in the day into one outdoor observation activity.
Choose 5, 10, or 20 minutes, select a park, neighborhood, or balcony, and decide
whether to take a gentle stroll or stay in one spot. It generates three short
steps and a question to think about afterwards.

The starting point is deliberately ordinary. You do not need a trail, a species
identification app, or a planned trip. A familiar outdoor space is enough. Balcony
activities stay in one spot, so going outside does not have to mean going for a walk.

The takeaway view removes the planner and leaves the activity. A text download
lets you read it later without keeping the app open. There is no timer to watch,
feed to scroll, or streak to maintain. The intended interaction is brief: choose,
read, then put the screen away.

I have not yet tested the activity outdoors or measured whether it changes anyone's
screen time. The current evidence covers the software and local model workflow.

Demo

Watch the 22-second browser walkthrough.

The silent video shows a real generated activity, the takeaway view, and the text
download. Generation happened before recording; that neighborhood reply took
45.74 seconds. This is a local application demo, not a publicly hosted inference
service. Setup instructions are in the repository.

Code

Outside Quest source code and setup instructions.

The application code is MIT licensed. Model weights are installed separately and
retain their upstream license.

How I Built It

React and Vite provide the planner and activity card. A FastAPI endpoint sends
the selections to Qwen3 4B through Ollama's local chat API. A JSON schema asks
the model for a title, invitation, exactly three steps, and a reflection question.
Pydantic validates the reply before it reaches the interface.

Time + surroundings + pace -> FastAPI -> Ollama / Qwen3 4B
                                      -> Three steps -> Takeaway view / text

The open-weight model creates the actual activity. A failed call produces a
retry message, rather than a canned answer presented as generated output.

Live checking mattered. An early balcony response asked what a bird's sound
revealed about its mood. That was speculative, so I changed the prompt to focus
on directly observable details and the person's own experience. Another activity
assumed a friend was present; the prompt now explicitly asks for a solo activity.
These instructions are requests, not a guarantee that every generated activity
will be suitable.

The implementation stays small: no accounts, storage, location tracking, route
data, agents, or paid inference API. The model does not know nearby places or
current weather. The application runs locally; its text export is the portable
part of the experience.

Nine backend tests passed. They cover valid requests, invalid selections, connection
failures, timeouts, missing models, malformed replies, truncation, and a Qwen
reasoning prefix. The production frontend build passes. Verification notes in
the repository separate real generation checks from mocked failure checks. Final
park and balcony API checks took 27.23 and 17.53 seconds; the neighborhood browser
reply shown in the walkthrough took 45.74 seconds. Mobile planner and takeaway
views fit a 375-pixel screen without horizontal overflow, and the downloaded text
matched the displayed activity even with browser networking disabled.

Why Does Open Innovation Matter?

Qwen3 4B is central to the workflow, and Ollama runs it on this computer. Once
the dependencies and weights are downloaded, the inference path uses local
endpoints. It does not require a paid model account or send these selections
to a hosted model provider.

I can inspect and change the prompts and output schema, reproduce a weak
reply, and test the next version. A different model can be configured, though
only Qwen3 4B has been checked here. The tradeoff is response latency and output
quality on local hardware. Open weights do not automatically make a reply accurate
or an activity appropriate.

The text file makes the last part independent of the AI runtime. Once you have
the activity, you can close the app and take it with you.

My Agent Session

Codex assisted with implementation, live model checks, browser verification, and
preparing this submission. No public agent session is linked.

Prize Categories

I am entering the overall challenge. This version uses Qwen and Ollama; it does
not claim a partner prize category.

Interview Buddy: understand the concept, then find your words

Kartikey Tiwari — Sun, 04 Oct 2026 17:22:59 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

I built this for my friend Raj, who is preparing for Java backend developer interviews.
The practice target is medium difficulty. I chose a small starting point: refreshing
backend concepts and turning an explanation into words he can rehearse aloud.
This is one part of that preparation, not a complete Java backend interview curriculum.

I built Interview Buddy, a local companion for practising Java backend interview concepts.
It takes one question and explains it four ways: a clear explanation, a simpler
analogy, a small example, and a concise interview answer. The aim is to help someone
move from recognising a concept to explaining it without looking at the screen.

I used public Indian developer discussions to sharpen the design. A
September 26 post
described uncertainty about dividing time between DSA, backend fundamentals, and AI.
A September 4 post
described understanding AI-written code while struggling to write independently.
These are individual accounts, not a survey of hiring practices. They helped me
choose starter questions and keep the workflow focused on understanding.

The interface offers starting points for databases, Spring Boot constructor injection,
design tradeoffs, Java HashMap,
and project decisions. After each answer, it asks the learner to look away and say
the idea in their own words. Switching modes keeps the question fixed, so the
learner can connect the explanation to an example and then to an interview response.

Demo

Watch or download the video walkthrough (MP4).

The 60-second walkthrough uses a database-indexing question in the four modes,
then shows a Java HashMap example. It uses real local Qwen replies. Generation waiting time is edited
out; measured timings are visible in the app and recorded in the evidence notes.

Code

Interview Buddy source on GitHub

The application code is MIT licensed. Qwen3 4B model weights are not bundled with
the project and retain their Apache 2.0 license.

How I Built It

The frontend uses React and Vite. A FastAPI endpoint selects an instruction for the
requested mode and calls Qwen3 4B through Ollama's local chat API using httpx.
React Markdown renders explanations and code blocks without enabling raw HTML.
The prompts target medium difficulty Java backend practice, and code examples
default to Java or SQL. The application server itself is written in Python.

Question + mode → React → FastAPI → Ollama → Qwen3 4B

I kept the implementation small: no account system, database, RAG, agents, or paid
model API. Questions and replies stay in browser memory; the app does not save
conversations. Choosing another mode sends the original question with a different
instruction rather than pretending to maintain a long conversation.

One live check exposed a detail I would have missed with mocks alone. Qwen returned
a reasoning prefix despite thinking being disabled. I added Qwen's /no_think
instruction and removed a remaining prefix before displaying the final answer,
then added a regression test. A later check hit the response token limit, so I
shortened the instructions and increased the generation budget. Slow inference is
still a limitation on this computer.

Seven backend tests passed, and the production frontend build completed. I checked
all four modes with real Qwen replies both through the API and in the browser.
I also checked blank input, starter-question resets, and a 375-pixel phone layout
without horizontal overflow. The captured browser replies took approximately
66–223 seconds on this computer. I ran one generated SQL indexing example in
SQLite and confirmed its query plan used the index; that does not validate every
answer the model might generate. The repository's verification notes preserve
the scope of these checks.

After aligning the prompts and starters with Java backend preparation, I reran the
tests and build. A real Java HashMap snippet generated in 82.17 seconds, compiled,
and returned the expected word counts. A broader full-program request hit the
answer limit; the interface displayed the error and recovered on a focused snippet
request. This version works best with one concrete concept or small example at a time.

I have not measured whether the app improves interview outcomes. Friend feedback
is also pending. This version gives a focused practice workflow; its explanations
can still contain errors and should be checked against technical documentation.

Why Does Open Innovation Matter?

Qwen3 4B does the core work: each explanation is generated by an open-weight model
running through Ollama on this computer. Once dependencies and weights are
downloaded, the inference path uses local endpoints and does not require a paid
model account or send the question to a hosted model provider.

I can inspect and change the prompts, reproduce a bad reply, and change the model
configuration. I tested Qwen3 4B; other models are not yet verified. This gives me
control over the learning workflow, with a clear tradeoff: local hardware limits
response speed and the model's answers still need scrutiny.

The benefit is control over where inference runs and how explanations are requested.
I am not claiming that this small model is more accurate than a closed model.

My Agent Session

Codex helped review the brief, research public discussions, implement the app,
run checks, and prepare this post. I reviewed the results before publication.

Prize Categories

I am entering the overall challenge. This implementation uses Qwen and Ollama;
I am not claiming any partner prize category.