DEV Community: Jessica Doering

I Built Mimu Because Even Taking Notes Is Too Much Work

Jessica Doering — Sat, 24 Oct 2026 02:35:32 +0000

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

I have a lot of ideas. Sometimes they're useful. Sometimes they're not. And sometimes I think of something I want to remember while I'm doing something completely unrelated.

The problem is that stopping to organize those thoughts feels like a whole separate task. Give a note a title, decide where it belongs, add tags, maybe set a reminder... suddenly the tiny thought I wanted to save has homework.

So when this week's challenge asked us to build something that rewards laziness, I knew exactly which chore I wanted to avoid.

I built Mimu, a little voice-note companion that lets me say what's on my mind and get on with my day. The note-taking is my part. The note-organizing is Mimu's.

And because I wanted to experiment with open models, the AI runs on devices I control rather than through a paid AI API.

What I Built

Mimu remembers for you.

On my phone, I tap the microphone, ramble for a few seconds, check the transcript, and save it. Whisper transcribes the audio in the browser. Later, a small Gemma model running on my computer turns that raw thought into a note with a useful title, formatted Markdown, a category, and tags.

The original transcript stays intact, so I can always see what I actually said. And if I don't feel like talking, I can type instead.

For example, I might say, "I need to call the dentist Thursday at two." Mimu can save that as an organized note with a due date instead of leaving me to remember which of my 47 scattered notes contains the dentist's appointment.

It also has a few features I added after getting the basic idea working:

Ask Mimu: Ask questions like "Who do I need to call?" and get an answer based on your saved notes, with links to the notes it used.
Morning digest and reminders: The desktop model prepares a short summary of what's due today and what I saved yesterday. Due-time reminders can be sent to the phone without needing the desktop to stay on.
Search and editing: Find notes by words, categories, and tags, or fix anything yourself without having the model overwrite it later.
Offline capture: Notes wait on the phone if the connection drops and sync when it comes back.
Markdown export: Save one note as .md or export everything as a ZIP of Markdown files. My notes don't have to live inside Mimu forever.

It's a responsive web app, so I can capture and browse notes on my phone and work through the library on a bigger screen. I gave it a tiny mascot, too, because apparently I cannot build an app without giving it a face.

[Insert mobile screenshots]

Demo

Try Mimu: https://mimu.pinkpixel.dev

I made a hosted demo because I didn't want the first thing a judge had to do to be "create two cloud accounts and configure a database." You can start a demo account or sign in with GitHub and explore sample notes right away.

To watch your own notes get organized by AI, you'll need Ollama on a computer. Mimu's Desktop page gives you a command to install and connect the Node worker, which downloads the Gemma model the first time. You can pair your phone by scanning a QR code. The app works as a note library without that worker, but Gemma-powered organizing, Ask, and digests need it running.

One important privacy detail: in the hosted demo, note text is stored in a separate database for each demo account under my Turso setup. Audio isn't uploaded; it's transcribed on the device and discarded. The language model still runs on the user's own computer. Anyone who prefers their own infrastructure can self-host Mimu instead.

Code

The source is available here:

pinkpixel-dev / mimu

Speak a thought, and a local AI sorts it into searchable Markdown notes.

Mimu

Mimu remembers for you.

Mimu is a voice notes app for people with too many ideas and not enough patience for note-taking. You tap the mic on your phone, say whatever's on your mind, and it's saved. Later, a model running on your own computer turns those rambling transcripts into tidy Markdown notes with a title, a category, and tags. You can search them, edit them, and export the whole library as plain Markdown whenever you want.

The speech recognition runs on your phone, and the organizing runs on your desktop. No paid AI API is involved anywhere.

See it in action

Here's a quick demo video. Click the thumbnail to watch it on YouTube.

Desktop

Mobile

Try it

There's a hosted demo at mimu.pinkpixel.dev, so you don't need a Turso or Cloudflare account to try Mimu.

Open the site and tap Start a demo (or Continue with…

View on GitHub

The README includes the setup instructions, architecture, and a quickstart for deploying your own copy.

How I Built It

I started on October 20, which happened to be International Sloth Day. Appropriate timing for an app dedicated to doing less.

My first plan was a phone app and a separate Tauri desktop app. Then I looked at the deadline and remembered that I am, unfortunately, only one person. I went with one React PWA that works on both screens and a headless Node worker on the desktop. It meant I could spend more of the week making the whole experience actually work, rather than maintaining two UIs.

The main pieces are:

Whisper tiny (English) through Transformers.js for speech-to-text in the browser.
Gemma 4 gemma4:e4b through Ollama on my computer for organizing notes, interpreting dates, writing digests, and answering questions.
React + Vite for the PWA, Hono on Cloudflare Workers for the API, and Turso/libSQL for note storage and full-text search.
A Node worker that picks up pending jobs, talks to Gemma locally, and sends the results back through the API.

The audio is handled on the phone. The saved text travels through the API to the database, and the desktop worker reads that text to process it. So this is local AI inference, not an entirely offline app. I think that distinction matters.

The bigger model wasn't better

Before settling on Gemma, I tested three sizes against ten messy sample notes, using structured JSON output through Ollama.

Gemma model	Valid JSON	Median time per note
`gemma4:e2b`	10/10	3.2s
`gemma4:e4b`	10/10	3.4s
`gemma4:12b`	10/10	13.7s

The funny thing is that all three were worse at organizing categories when I gave them a bad instruction. I told them to reuse existing categories "even loosely," and suddenly a grocery list was a "General Thought" and a failing CI build belonged with software ideas.

A much more specific rule about types of notes fixed the problem. E4B made six sensible categories in that test, without the extra wait from the 12B model. That was a useful reminder that throwing a bigger model at a vague prompt doesn't necessarily fix the prompt.

My phone had other plans

I initially tried Whisper with WebGPU. It looked promising until I tested it on my iPhone: the model download hit 100%, Safari reloaded, and I got to repeat the whole experience. No visible error. Just goodbye.

I added little diagnostic breadcrumbs that survived a reload and tracked the crash to ONNX session setup. The browser could detect a WebGPU adapter, but that didn't mean the model could actually run on it.

Switching to WASM fixed the issue. On the same phone, the model loaded in about 3.3 seconds and transcribed a three-second audio clip in about 1.8 seconds. For a model this small, WASM was also competitive on my desktop, so I made it the default everywhere.

I learned more from testing on a real phone than from a lot of happy-path desktop tests.

The tricky part wasn't formatting. It was not making things up.

At one point, Whisper misheard a phrase and Gemma confidently cleaned it up into something that meant the opposite of what I had said. The resulting note looked wonderfully polished. It was also wrong.

That's a dangerous failure for an app that's supposed to remember things for me.

I experimented with ways to make Gemma flag suspicious transcript fragments instead of quietly repairing them. In a small repeated test with deliberately garbled and clean phrases, asking for uncertainty inside the main organizing call caught only some of the errors. Giving uncertainty detection its own tiny model pass caught all ten garbled examples with no false alarms in that test, at roughly 0.6 seconds more per note.

Mimu now has a little "Mimu wasn't sure about" section, and the app verifies that a flagged phrase really appeared in the transcript. It doesn't eliminate every possible transcription error, but it gives me a chance to fix something ambiguous instead of trusting a very convincing invention.

I kept giving my lazy app more work

Once the capture-and-organize loop worked, I wanted Mimu to do more than make a neat pile of notes.

I added natural-language due dates, so "Thursday at two" can become an actual date and time. In my test of 16 phrases run twice, giving Gemma the capture timestamp and timezone produced 32/32 correct date-and-time results. Adding a calendar cheat sheet actually made it worse. That one surprised me.

Then came Ask Mimu, morning digests, and reminders. Ask uses full-text search first, then has Gemma answer from the retrieved notes, with references checked against the notes it received. If the search finds nothing, it says so instead of improvising.

The final result still has more moving pieces than my original "just let me talk" idea. But they're moving so I don't have to.

Why Does Open Innovation Matter?

Mimu wouldn't be the same project if every voice note had to go through a paid transcription API and every bit of organizing required another hosted model call.

Using open models let me decide where the work happens. Whisper runs right in the browser, so audio doesn't have to leave the phone. Gemma runs on my own computer through Ollama, so I can experiment with prompts, swap model sizes, and keep using the AI features without paying per note or per question.

It also meant I could test the model's actual behavior instead of treating it like a mysterious service. I could compare sizes, measure timings, change how uncertainty was handled, and build simple checks around what the model returned.

There are trade-offs. You need a computer capable of running the model, and some features aren't available until the desktop worker connects. The app also uses cloud storage to sync text between devices, so I'm not claiming the whole system is private-by-default or offline. But the audio stays on the phone, inference happens locally, and you can deploy the app under your own accounts. And your notes can leave as Markdown whenever you want.

That combination of control, portability, and the freedom to tinker is what made this project exciting to me.

The Lazy Payoff

I haven't done a formal time-savings study, so I'm not going to pretend Mimu saves an exact number of minutes every day. The benefit I was going for is smaller and more familiar: removing the little bits of friction that make me not bother writing something down at all.

Instead of stopping to decide on a title, folder, tags, and maybe a reminder, I can just talk. And later, I can search for the thought without remembering how I named it. That's the kind of laziness I can get behind.

I did test the complete flow with a real phone and laptop: start a demo, connect the worker, pair the phone, speak a note, and watch Gemma organize it. I also tested offline capture and resync. Those aren't hypothetical features in a mockup; they worked in my end-to-end tests.

The part I still want to keep testing is how well it handles real, everyday notes over time. A clean demo with a few examples is one thing. A growing pile of random thoughts from my brain is an entirely different workload.

Which, conveniently, I can provide in abundance.

Prize Categories

I'm entering Best Use of Gemma. Gemma 4 is the core of Mimu's note organization, date extraction, question-answering, and digests, running locally through Ollama.

I Fixed WebGPU on Linux. Then Forgot How I Did It.

Jessica Doering — Wed, 21 Oct 2026 21:13:14 +0000

I spent a ridiculous amount of time trying to get WebGPU working properly on my Linux machine.

I eventually figured it out, wrote a script to launch Chrome with all the necessary flags, and even made a desktop launcher so I could just click an icon whenever I wanted to run browser-based AI models.

Problem solved.

Except recently, I started thinking about all the trouble I'd gone through and realized something.

I couldn't remember how I'd fixed it.

Actually, I couldn't even remember where I'd saved the script.

So I did what any reasonable developer would do in 2026. I sent an AI agent to search my computer for code I'd written myself.

And what did it find?

Not only had I saved the script, I'd also written documentation explaining how it worked and backed everything up in TWO different resource directories.

Apparently, past me was considerably more organized than present me remembered.

Anyway, since I've already done all the hard work (and then forgotten about it), I figured I might as well share what I learned.

I just wanted to run AI models in my browser

I've spent quite a bit of time experimenting with local AI models, particularly small language models running through Transformers.js and ONNX Runtime.

I love the idea of running models directly in the browser. No server to maintain, no API calls to pay for, and inference happens right on your own hardware.

WebGPU makes a lot of that possible by allowing web applications to use the GPU for computation.

Which sounds great, right?

Except my setup wasn't exactly cooperating.

I'm running Arch-based Linux with Wayland on a laptop with hybrid graphics:

Intel Raptor Lake UHD integrated graphics
NVIDIA RTX 4090 Laptop GPU

And getting Chrome, Vulkan, NVIDIA, and Wayland to play nicely together was an absolute pain.

There are several layers involved. Your GPU drivers need to work, Vulkan needs to find the right device, Chrome needs to use the right graphics backend, and WebGPU needs to initialize successfully.

And just because one of those things works doesn't mean the next one will.

I spent a lot of time troubleshooting different configurations before I finally had something reliable enough to use regularly.

The solution that worked for me

Eventually, I ended up with a Bash script that launches a separate Chrome instance configured specifically for WebGPU.

Here's the script I recovered:

#!/usr/bin/env bash

# Launch Google Chrome with NVIDIA PRIME offload + Vulkan + WebGPU on X11.
# Dedicated separate profile so it can run alongside normal Chrome.

set -euo pipefail

CHROME_PROFILE_DIR="${HOME}/.config/chrome-webgpu-nvidia"

mkdir -p "$CHROME_PROFILE_DIR"

VK_LOADER_DRIVERS_SELECT='*nvidia*' \
__NV_PRIME_RENDER_OFFLOAD=1 \
__GLX_VENDOR_LIBRARY_NAME=nvidia \
__VK_LAYER_NV_optimus=NVIDIA_only \
google-chrome-stable \
  --user-data-dir="$CHROME_PROFILE_DIR" \
  --enable-unsafe-webgpu \
  --enable-features=Vulkan \
  --ozone-platform=x11 \
  "$@"

It's not particularly complicated to look at.

But getting to the point where I knew which settings to use was another story.

I also created a .desktop launcher for it, so now when I want to experiment with WebGPU, I can just open that version of Chrome without having to remember any of this.

Which, as we've established, is probably a good thing.

What all those settings actually do

1. Getting Chrome to use the NVIDIA GPU

My laptop has two GPUs. There's the integrated Intel GPU and the dedicated NVIDIA GPU.

With hybrid graphics, applications don't necessarily use the GPU you'd expect.

That's a problem when you're trying to run models on your RTX 4090 and your browser decides the integrated GPU looks perfectly adequate.

So my script sets four environment variables:

VK_LOADER_DRIVERS_SELECT='*nvidia*'
__NV_PRIME_RENDER_OFFLOAD=1
__GLX_VENDOR_LIBRARY_NAME=nvidia
__VK_LAYER_NV_optimus=NVIDIA_only

Here's what they're for:

VK_LOADER_DRIVERS_SELECT filters the Vulkan driver manifests so that the NVIDIA driver is selected.
__NV_PRIME_RENDER_OFFLOAD=1 enables NVIDIA PRIME render offloading.
__GLX_VENDOR_LIBRARY_NAME=nvidia selects NVIDIA for GLX vendor dispatch.
__VK_LAYER_NV_optimus=NVIDIA_only tells NVIDIA's Optimus Vulkan layer to expose only the NVIDIA GPU.

Not all four variables necessarily matter for every application or graphics path, but this combination was part of my working configuration.

The important thing was making sure Chrome could actually access and use the GPU I wanted.

2. Making Wayland cooperate by... not using native Wayland

This one still makes me laugh.

I'm running a Wayland desktop, but my working Chrome launcher includes:

--ozone-platform=x11

That tells Chrome to use its X11 backend, which runs through XWayland inside my Wayland session.

At the time, I was running into problems getting Vulkan and Chrome's native Wayland backend to cooperate with NVIDIA.

Running Chrome through XWayland was the workaround that finally worked for my setup.

So after all that effort to get things running properly under Wayland, part of my solution was essentially telling Chrome to pretend it was running under X11.

Sometimes the practical solution isn't the elegant one.

It's the one that actually works.

3. Giving Chrome its own profile

This was one of the more useful discoveries.

--user-data-dir="$CHROME_PROFILE_DIR"

Chrome normally reuses an existing browser instance when you try to launch it again with the same profile.

So if Chrome is already open and you try launching another window with different GPU flags, you might discover that your new settings aren't actually being applied.

Using a separate profile directory gives my WebGPU launcher its own Chrome process and GPU configuration.

That also means I can keep my regular browser open while running a separate instance for development.

No need to mess with my normal browsing setup every time I want to test something.

4. Enabling Vulkan and WebGPU

Finally, these two flags:

--enable-unsafe-webgpu
--enable-features=Vulkan

The first enables experimental WebGPU support and bypasses certain GPU restrictions.

The second enables Chromium's Vulkan graphics feature.

There's an important distinction here: enabling Vulkan in Chrome doesn't necessarily guarantee that WebGPU itself is using Vulkan through Dawn, Chromium's WebGPU implementation.

The exact behavior depends on your Chromium version, platform, and graphics configuration.

Also, --enable-unsafe-webgpu is intended for development and testing. It's not something I'd recommend casually enabling in your everyday browser.

A note about newer Chrome versions: WebGPU support on Linux has been improving, so you might not need this exact configuration anymore. In particular, newer releases have expanded support for Intel and NVIDIA hardware. Check your current browser and driver support before copying every flag into your own setup.

How to check whether it's actually working

After launching Chrome with the script, open:

chrome://gpu

Look at the Graphics Feature Status section.

Ideally, you want to see hardware acceleration enabled for WebGPU and Vulkan rather than software fallbacks.

It's also worth checking the GPU and driver information to make sure Chrome is using the NVIDIA device instead of Intel or a software renderer like SwiftShader.

But don't stop there.

Being able to see WebGPU listed as hardware accelerated doesn't guarantee your actual application will run correctly.

Try running a real WebGPU sample or the model you're planning to use.

I've learned this the hard way more than once.

For example, while building my recent Mimu note-taking app, Safari on my iPhone reported that WebGPU was available. But attempting to initialize the Whisper model with WebGPU caused the tab to crash and reload.

The WASM version worked fine.

And for that particular small model, WASM was fast enough that using WebGPU wasn't worth the trouble anyway.

That was another useful reminder that the theoretically faster option isn't always the best one.

And then I forgot where I put everything

So here's where this whole thing comes full circle.

Recently, I've started keeping detailed build logs for my projects.

Not just what I built, but what broke, what I tried, why I made certain decisions, and what I'd do differently if I approached the same problem again.

Writing more on DEV has actually encouraged this habit. Thinking about what I might eventually write makes me pay more attention to what I'm doing while I'm building.

And I've already found myself going back through my notes and reconsidering decisions I made just a day or two earlier.

Which got me thinking about all those earlier experiences with WebGPU.

I wished I'd documented them better.

Turns out, I had.

I just couldn't remember doing it.

My AI agent found the original launcher in:

~/.local/bin/chrome-webgpu-nvidia

The desktop entry was in:

~/.local/share/applications/

And the documentation and additional copies were sitting in my PINKPIXEL/RESOURCES directory.

In two different folders.

I had already done everything I was wishing past me had done.

I just hadn't done a particularly good job of making that information easy to find again.

Which is even funnier considering I'm currently building an app designed to help people capture, organize, and remember things.

Apparently, I really do need it.

What I learned from all this

The technical lesson here is that getting WebGPU working on Linux can involve more than just enabling a browser flag, especially with hybrid graphics.

Depending on your hardware and software versions, you may need to pay attention to which GPU is being selected, which graphics backend Chrome is using, and whether your application is actually getting hardware acceleration.

But I think the bigger lesson for me has less to do with WebGPU.

I've built a lot of things over the years. I've solved problems, experimented with technologies, and figured out workarounds that took far more effort than I expected.

And then I moved on to the next interesting thing.

I didn't always stop to think about what I'd learned or how useful that experience might be later.

That's something I've been trying to change.

Keeping build logs has made me more thoughtful about the decisions I'm making, and writing about my experiences has encouraged me to look at them more closely.

Sometimes that means discovering a better way to approach something.

Sometimes it means remembering a useful technique.

And sometimes it means finding out that I already solved a problem, documented it, backed it up twice, and completely forgot about the whole thing.

At least now I know where my WebGPU script is.

For the moment, anyway.

In Defense of Being a Little Lazy

Jessica Doering — Wed, 21 Oct 2026 02:02:53 +0000

This week's DEV challenge is about building something that rewards laziness.

Which did make me laugh a little bit.

We're usually encouraged to be more productive, work harder, get more done, and make better use of our time. And now here's a challenge asking us to reward people for being lazy.

But the more I thought about it, the more I started wondering whether laziness is really such a bad thing.

Because there are different kinds of laziness.

There's the kind where you avoid doing something you really should be doing. I'm certainly guilty of that sometimes.

But then there's the kind that makes you look at a tedious, repetitive task and think, there has got to be a better way to do this.

And I think that second kind deserves a little more credit.

Sometimes laziness makes us creative

As developers, we do this all the time.

We'll spend hours building a tool to automate something that probably only takes a few minutes to do manually.

Does it always make sense? Absolutely not.

Do we do it anyway? Of course we do.

But I think there's something valuable in that instinct. It's not necessarily about being unwilling to work. Sometimes it's about being unwilling to keep doing work that doesn't need to exist.

That kind of laziness can lead to some pretty clever solutions.

But what about doing nothing?

Here's where I think it gets even more interesting.

We've gotten so used to measuring everything in terms of productivity that even our free time sometimes feels like it needs a purpose.

We take breaks so we can come back refreshed and work harder. We track our sleep so we can perform better. We turn hobbies into projects, projects into products, and sometimes products into businesses.

And there's nothing inherently wrong with any of that.

But does everything really need to accomplish something?

What about doing absolutely nothing just because you feel like it?

Not to recharge. Not to improve your focus. Not because it's part of some carefully planned routine.

Just because you want to.

I think there's value in allowing ourselves that kind of freedom, too.

Maybe it's about choosing where our effort goes

I'm starting to think the good version of laziness isn't really about avoiding effort.

It's about being more selective with it.

Sometimes that means finding a smarter way to do something.

Sometimes it means recognizing that something doesn't need to be done at all.

And sometimes it means giving yourself permission to spend an afternoon doing something completely unproductive without feeling guilty about it.

I have been diligently working on my challenge submission, which I suppose is the opposite of being lazy, but the theme for this week got me thinking.

Maybe laziness has a little more going for it than we give it credit for.

What Do You Make When You Can Make Anything?

Jessica Doering — Tue, 20 Oct 2026 16:45:47 +0000

I have more creative freedom than I've ever had.

Some days, I have so many ideas that I can't wait to sit down and start building.

Other days, I open my editor, stare at the empty screen, and can't think of a single thing I want to make.

It's not because I've run out of possibilities.

It's because I've got too many.

When everything sounds interesting

I've always been someone who likes making things. I get curious about something, start wondering how it works, and before long I'm opening a new project folder.

Sometimes it's something practical. A tool that solves a problem I've run into, or something I wish existed but haven't been able to find.

Other times, it's something completely unnecessary that just sounds fun to build.

And sometimes I don't even care all that much about the finished product. I just want to see if I can make it work.

That's one of my favorite things about programming. There's always something new to explore, something to figure out, or a random idea that might actually turn into something interesting.

But there's a downside to being interested in so many things.

I can sit down with every intention of working on something and find myself mentally bouncing between a dozen different possibilities.

Maybe I should finish one of my existing projects.

Maybe I should try that new library I came across yesterday.

Maybe I should build that little CLI tool I've been thinking about.

Or maybe I should make something entirely different.

And somehow, after considering all of those options, I end up doing absolutely none of them.

Not because I don't want to make something.

I want to make everything.

The barriers are disappearing

I think AI has made this feeling even more noticeable for me.

There was a time when an idea came with a fairly substantial list of things we'd have to figure out before we could even start building it.

Do we know the language? Could we work with the framework? Would we have to spend weeks learning something new just to get a basic version running?

Those questions might not necessarily stop us, but they did help narrow down what we were realistically going to attempt.

Now, a lot of those barriers are smaller.

I can experiment with a language I'm unfamiliar with, explore a framework I've never used, or take an idea much further than I could have on my own in the same amount of time.

And I love that.

I still have plenty to learn, and AI certainly doesn't make the hard parts of building software disappear. But it does make more ideas feel within reach.

Which means I have fewer reasons to dismiss an idea before I start.

That sounds great. In theory.

Most of the time, it is.

But it also means that almost every passing thought can turn into a potential project.

And when nearly everything feels possible, choosing what to spend my time on becomes its own challenge.

I don't think it's always a creative block

I've been thinking about the difference between having no ideas and having too many.

Because from the outside, they can look exactly the same.

You sit there staring at an empty editor, not writing a single line of code.

But what's happening in your head can be completely different.

Sometimes I genuinely don't feel inspired. Nothing sounds particularly interesting, and I'd rather go do something else.

Other times, I have so many ideas competing for my attention that I can't settle on one long enough to begin.

It's almost like standing in front of an enormous menu where everything looks good.

You'd think having more choices would make the experience better.

Instead, you spend twenty minutes trying to decide what you want.

And the funny thing is, I know perfectly well that I don't have to make the best thing.

I'm not running a company where every project needs a business case. I'm not trying to build the next big startup every time I sit down at my computer.

Most of the time, I'm just making things because I enjoy making them.

So why does choosing sometimes feel like such a big decision?

The things I could be making

I think part of it is that every project I choose to work on represents a bunch of other projects I'm not choosing.

If I spend the night working on a terminal app, I'm not experimenting with that interesting new UI framework.

If I start something new, I'm not finishing something old.

If I spend three hours exploring an idea that goes nowhere, I could have spent those three hours improving something I already built.

And yes, I realize how ridiculous that sounds when I'm talking about something I do for fun.

But I think that's part of what happens when you're curious about a lot of things and have the tools to pursue them.

You start feeling the weight of all the things you could be doing.

Even when nobody is asking you to do any of them.

I also think there's something strangely exciting about an idea before you start building it.

In your head, it's full of potential. You can imagine what it might become, all the interesting features you could add, and all the things you'll learn along the way.

Once you actually start, you have to make decisions. You run into limitations. Some parts are less interesting than you expected.

The idea becomes a real project, with all the ordinary work that comes with one.

And meanwhile, somewhere in the back of your mind, another shiny idea is waiting.

Maybe I don't need to make anything

I love that I can sit down at my computer and turn some random thought into something real.

I love learning new things, trying unfamiliar technologies, and making tools that probably wouldn't exist if I hadn't decided to build them.

But I'm starting to wonder if I've gotten so used to having something to work on that sitting down without a project feels like a problem I need to solve.

Maybe not every ounce of free time needs to become a new repository.

Maybe sometimes I can just explore something without turning it into an application.

Or spend some time actually using the things I've already made.

Or close the editor and do something else entirely.

I don't think the answer is to stop starting projects. Starting things is one of the ways I learn, and honestly, it's a huge part of what makes programming fun for me.

And I don't think I need to force myself to finish everything I begin, either. Sometimes an experiment has already given me what I wanted from it, even if it never becomes anything more.

Maybe the harder thing for me to learn is that having the ability to make something doesn't mean I have to.

That I can have ten ideas and choose just one of them without worrying about the other nine.

And that sometimes, when nothing feels quite right, I can simply leave the editor closed.

Because the possibilities aren't going anywhere.

Maybe having the freedom to make anything also means having the freedom to make nothing.

The Terminal Made Me a Better Developer (And Not for the Reasons I Expected)

Jessica Doering — Mon, 19 Oct 2026 00:36:51 +0000

When I first started using the terminal, sure, it was useful. I could navigate around directories, install packages, run a dev server, do some Git stuff. But most of those things could also be done by clicking a few buttons.

And clicking buttons seemed perfectly reasonable to me.

I wasn't really sure about being one of those people who does absolutely everything from a terminal just because I can.

But the more I got into development, and especially the more time I spent working with Linux, the more I found myself using it.

Sometimes because it was faster. Sometimes because whatever I was trying to do didn't have a convenient graphical option. And sometimes because I was following instructions and had absolutely no idea what half the commands were doing.

Eventually, I started getting curious about that last part.

What was that command actually doing? Why did it work? Why did it fail? And why was I running it in the first place?

Somewhere along the way, I realized I was learning a lot more than how to use a command line.

I was starting to understand how things worked underneath all the nice interfaces I'd gotten used to.

And that's been far more useful than learning to type commands quickly.

I started paying more attention to the filesystem

I've always understood files and folders. I think most of us have been moving things around in file managers for years without giving it much thought.

But working in the terminal made me pay attention to things I normally wouldn't have noticed.

For example:

pwd
ls -la
cd ..

Nothing exciting there, right?

But when you're working in the terminal, knowing where you are actually matters.

I've lost count of how many times I've tried running something only to discover I wasn't in the directory I thought I was.

Or wondered why a configuration file wasn't showing up, only to remember it was hidden.

Or had something fail because I used a relative path without thinking about what it was relative to.

These are pretty basic things, but they're also things I could get away with not thinking about when I was just clicking through folders.

I started paying more attention to hidden files, symbolic links, absolute versus relative paths, and where applications store their configuration.

And suddenly, a bunch of little things that used to confuse me started making more sense.

Not because the terminal magically made me smarter. I just had to understand what I was doing instead of relying on an interface to handle it for me.

I finally started understanding processes

This was a big one for me.

When you open an application normally, you click an icon and it opens. When you're finished, you close it.

Simple enough.

But there's a lot going on behind that, and I didn't always give it much thought.

Running things from the terminal made processes a lot more visible.

Especially when working on web apps.

If you've spent any time developing with Vite, you've probably encountered the dreaded port-already-in-use situation.

You try to start your dev server, and something is already sitting on the port you wanted.

Sometimes it's another instance of your app that you forgot was still running. Ask me how I know.

Instead of just closing random terminal windows and hoping for the best, I started learning how to see what was actually running.

ps aux
pgrep -af node
ss -ltnp

And if I specifically want to know what's listening on port 5173:

ss -ltnp | grep ':5173'

These commands let me investigate the processes and listening sockets on my system. Depending on permissions, I might not be able to see every process associated with a socket, but it's a useful place to start.

It seems like a small thing, but understanding the relationship between a running application, its process, and the port it's using helped a lot of other concepts click for me.

Before, I knew my dev server was running because the browser showed my app.

Now I had a better idea of what running actually meant.

Permissions started making a lot more sense

Linux permissions were another one of those things I sort of understood in theory.

Read, write, execute. Got it.

Except apparently I didn't always get it, because I'd still run into situations where I couldn't modify a file or execute a script and wonder what the hell was going on.

The terminal made it easier to actually look at what was happening.

ls -l script.sh
stat script.sh

Instead of just getting a permission-denied message and being annoyed about it, I could check who owned the file and what permissions it had.

I started understanding why a file might be readable but not writable, or why a script wouldn't execute even though it was sitting right there.

I also learned that execute permission on a directory doesn't mean quite the same thing as execute permission on a file. On a directory, it's about being able to traverse it.

That's one of those little Linux details that seems weird until you understand it.

And then there's sudo.

I think it's pretty easy when you're learning Linux to see a permission error and think, well, I'll just stick sudo in front of it.

Problem solved!

Except maybe not.

You might get the command to work, but you still don't know why it needed elevated permissions. And depending on what you're doing, you might end up creating files owned by root that really shouldn't be.

I've learned that getting something to work and understanding why it wasn't working are two very different things.

That lesson has come up quite a bit in development, actually.

Networking became a little less mysterious

Networking is one of those subjects where I understood the general concepts long before I felt comfortable troubleshooting anything.

I knew what DNS was. I knew what ports were. I understood that applications communicate over networks.

Great.

But when something wouldn't connect, that knowledge didn't necessarily tell me where to start.

Was the hostname resolving? Was the server actually responding? Was my application even listening on the port I thought it was?

Or had I somehow managed to break something entirely unrelated?

The terminal gave me a way to start narrowing those things down.

dig example.com
curl -I https://example.com
ss -ltn

These commands look at different pieces of the puzzle.

dig lets me check DNS resolution.

curl lets me make an HTTP request and inspect the response.

And ss lets me see which TCP ports are listening on my own system.

None of these commands will magically explain every network problem, obviously. But they give me somewhere to start.

And I think that's what made the biggest difference.

I stopped treating every connection failure as one big mysterious problem and started trying to figure out which part was actually failing.

Because "my app can't connect" could mean quite a few different things.

And knowing which one you're dealing with makes troubleshooting a whole lot easier.

I got better at actually reading errors

This might sound ridiculous, but I think one of the most useful things I've learned from working in the terminal is to actually read what my tools are telling me.

Not just glance at the error, decide something is broken, and immediately start trying things until it works.

I mean really read it.

When you're working in the terminal, you see a lot of output.

Compiler errors, dependency warnings, stack traces, server logs, and sometimes an absolutely ridiculous wall of text because one little thing went wrong.

At first, all that output can be overwhelming.

And sometimes it still is.

But the more I worked with it, the more I started recognizing what was worth paying attention to.

A missing environment variable isn't the same thing as a network request failing.

A dependency conflict isn't a syntax error.

And an application that crashes immediately is a very different problem from one that's running perfectly fine but not responding the way you expected.

I still have plenty of moments where I stare at an error wondering what on earth it's trying to tell me.

But I'm much more likely now to investigate the actual error instead of immediately throwing another possible solution at it.

And when I do have to look something up, I usually have a much better idea of what I need to look up.

That's made a pretty big difference.

The real benefit has been learning how to investigate things

I think this is the part I didn't expect when I started using the terminal more.

I thought I'd learn some useful commands. Maybe speed up a few workflows.

What I didn't expect was how much it would change the way I approached problems.

Now, when something doesn't work, I'm more likely to start asking questions.

Where is this command actually running?

What process is using that port?

Who owns this file?

Is the server responding at all?

What does the error message actually say?

And I don't mean that I always know how to figure these things out.

Far from it.

Half the time I'm still looking up commands, reading documentation, or finding out that the thing I thought I understood works a little differently than I expected.

But that's kind of the point.

I don't think being comfortable with the terminal means memorizing hundreds of commands or being able to type some ridiculous one-liner from memory.

It means knowing that there's probably a way to investigate what's happening, and being willing to figure out how.

Sometimes that means using a command I already know.

Sometimes it means spending twenty minutes reading documentation to figure out why that command didn't do what I expected.

Both are useful.

A few things worth experimenting with

If you're relatively new to the terminal, or you've mostly been using it to install packages and start development servers, here are a few little exercises worth trying.

These examples are mostly aimed at Linux, since that's what I use. Some commands will be different on macOS or Windows.

The goal isn't to memorize them. It's to look at what they show you and try to understand why that information matters.

1. Take a closer look at a project directory

Open a terminal inside one of your projects and try:

pwd
ls -la
find . -maxdepth 2 -type f

Look at where you are, which files are hidden, and how things are organized.

Try running the commands from different directories and see what changes.

Pay particular attention to relative paths. They're simple until they're the reason something isn't working.

2. Find your development server

Start a development server like you normally would.

Then open another terminal and run:

pgrep -af node
ss -ltnp

If you're using a Node-based development server on Linux, see if you can find its process and the port it's listening on.

If you can't see the process information you expected, look into why. It might be a permissions issue, or your server might be running through a different executable.

The investigation is the exercise.

3. Look at file permissions

Pick a file in your project and run:

ls -l package.json
stat package.json

What do all those permission bits mean?

Who owns the file?

What can the owner do that other users might not be able to?

You don't need to go changing permissions just to experiment. In fact, I'd recommend understanding what you're looking at before doing that.

4. See what happens during an HTTP request

Try:

curl -v https://example.com

There's quite a bit of information in that output.

Look at the connection details, TLS negotiation, request headers, and response headers.

You don't need to understand every line right away.

Pick something unfamiliar and look it up.

That's literally how I've learned a lot of this stuff.

5. Experiment with pipes

Here's a tiny one:

printf 'apple\nbanana\napricot\n' | grep '^a'

You should see:

apple
apricot

That little | sends the output of one command into another command.

It's such a simple idea, but it's also one of the things that makes Unix-like command-line environments so useful.

Instead of needing one giant tool that does everything, you can connect smaller tools together.

Once that concept clicks, a lot of terminal workflows start making more sense.

And it's worth experimenting with beyond this little example.

You don't have to do everything in the terminal

I should probably mention this because I know how these conversations sometimes go.

I am not suggesting everyone should abandon graphical applications and spend the rest of their lives staring at a terminal window.

I use graphical applications all the time.

There are plenty of things I'd rather do with a good interface, and I'm not going to make my life unnecessarily complicated just to prove I can do something from the command line.

I also don't think using a terminal automatically makes someone a better developer.

You can copy and paste commands all day without understanding a single thing about what they do. Just like you can click around a graphical interface without really knowing what's happening.

The difference, at least for me, has been curiosity.

When I started paying attention to what commands were doing, why they were working, and why they occasionally failed spectacularly, I started learning a lot more.

The terminal just makes it particularly easy to see some of the things that graphical interfaces usually handle for you.

It's not really about typing faster

I started using the terminal because it was useful.

And sure, I've gotten faster at certain things. There are plenty of tasks where opening a terminal and typing a command is easier than clicking through a bunch of menus.

But that hasn't been the most valuable part.

What's really changed is how I see the software I'm working with.

An application isn't just something that opens when I click an icon anymore. There are processes running, files being accessed, permissions being checked, network connections being made, and all kinds of smaller things happening behind the scenes.

And when something goes wrong, I have a much better idea of where to start looking.

I still have a ridiculous amount to learn. I look things up constantly, experiment with things I don't fully understand yet, and occasionally break something because I was a little too confident.

But I'm getting better at figuring things out.

And that's what working in the terminal has really helped me with.

Not becoming some command-line expert.

Just becoming a better investigator.

Which, the more I learn about development, the more I realize is a pretty important skill.

I Built a New Tab Extension for DEV

Jessica Doering — Sun, 18 Oct 2026 17:13:41 +0000

I spend a lot of time on DEV these days. Reading posts, finding interesting projects, participating in challenges, and occasionally writing something myself.

I also like daily.dev. Having a feed of developer content right there whenever I open a new tab is pretty convenient.

So naturally, I started thinking... what if I had something like that, but just for DEV?

And because apparently I can't have an idea without turning it into another project, I built one.

It's called DEV Tab, and it's a free, open-source browser extension that replaces your new tab page with a feed of posts from DEV.

It's now available on the Chrome Web Store.

Install DEV Tab for Chrome

Firefox support is built too, and the add-on is currently awaiting review. I'll update this post with the link once it's approved.

Firefox was approved!
Install for Firefox

A little more than just a feed

The original idea was pretty simple. Open a new tab, see what's happening on DEV, and click through to anything interesting.

But, as usual, I kept thinking of things to add.

You can browse posts from Today, This Week, Rising, and Latest, along with dedicated sections for trends, events, podcasts, and videos.

There are also tag filters, so you can quickly jump between subjects you're interested in. You can save your favorite tags, hide tags you'd rather not see, and follow posts from specific DEV organizations.

A few other things I added:

Search directly from the new tab page.
Keyboard navigation using arrow keys and Enter.
A compact view if you'd rather see more posts and fewer images.
Reaction counts and previews of the three newest comments.
A shortcut to create a new DEV post.
Feed caching, so opening a new tab doesn't mean waiting for everything to load again.

Nothing particularly revolutionary here. I just wanted a convenient way to explore DEV without having to go looking for things.

Then I decided it needed a dashboard

This part wasn't in my original plan, but I spend enough time writing on DEV that I thought having a better overview of my own activity would be useful.

If you add your DEV API key in the extension settings, you unlock some additional features, including a personal dashboard.

The dashboard includes your follower count, views, reactions, comments, and new followers, with options to look at the last 7, 30, or 90 days.

There's also a daily views chart, an activity heatmap that lets you browse previous years, and a list of your published posts and drafts.

You can see recent followers, top supporters, and where your readers are coming from, too.

I particularly like having the activity heatmap and post statistics together. It's interesting to look back and see when I was active and how different posts performed.

The dashboard screenshot above uses fictional example data, by the way.

Connecting your DEV account is completely optional

You don't need an account or API key to use the extension. The public feeds, search, filters, and other browsing features work without one.

But if you do connect your DEV account, you also get access to your personal feed based on the tags you follow, your reading list, and semantic search.

You can generate an API key from your DEV settings.

The extension doesn't have a backend, analytics, or tracking. Your API key stays in your browser's local extension storage and is only sent to DEV for authenticated API requests.

I wanted to keep it simple and avoid introducing a separate service just to display information DEV already makes available.

A few limitations

There are a couple of things I would have liked to include but couldn't because of the DEV API.

For example, you can't directly react to posts, leave comments, or save articles to your reading list from the extension.

You can view reaction counts and preview comments, but interacting with a post opens it on DEV itself.

I'd love to have those actions directly in the feed someday, but for now, that's a limitation of what's available through the API.

Built with WXT, React, and TypeScript

I used WXT for the extension framework, along with React and TypeScript.

This was my first time using WXT, and I really liked being able to build for Chrome and Firefox from the same codebase.

One thing I spent some time on was making sure the feed wouldn't constantly refetch everything whenever a new tab opened. The first page of each feed gets cached for ten minutes, and previously loaded posts can still appear if you're offline.

It's a small thing, but when you're replacing something as frequently used as the new tab page, I think it matters.

Give it a try!

DEV Tab is open source, so you can take a look at the code, report bugs, suggest features, or contribute if you'd like.

Chrome Web Store

GitHub

The Firefox version is currently awaiting approval, and I'll add the link here when it's published.

This started as one of those little "wouldn't it be nice if..." ideas, and somehow turned into a full browser extension with a personal analytics dashboard.

I guess that's what happens when you keep finding things you want to build.

If you use DEV regularly, I'd love to hear what you think! And if there's something you'd find useful in a future version, let me know.

What I Actually Learn When I Build With AI

Jessica Doering — Fri, 16 Oct 2026 01:06:09 +0000

I've spent entire nights building something with AI, gotten a bunch of features working, and then realized I couldn't really explain half of what I'd just built.

And then there are nights when I spend hours trying to figure out one stupid little problem, and somehow end up learning more from that than I did from the entire night before.

It's kind of funny when you think about it. Both times I was productive. Both times I ended up with working code. But what I actually learned from each experience was completely different.

I wrote a post recently about how AI is making it way too easy to avoid thinking, and it got me thinking about my own habits. Because I use AI coding tools constantly. I love them. They've helped me build things I probably wouldn't have even attempted otherwise.

But I'm also still learning. A lot.

And there is a big difference between just getting something working and actually understanding how it works.

Just because I understand the explanation doesn't mean I understand the code

This probably happens to all of us more than we'd like to admit.

I might ask AI to explain something, and it'll give me a perfectly reasonable breakdown. Everything makes sense. I can follow along, I understand what each part is doing, and I think, okay, got it.

Then 3 days later I need to change something, and suddenly I'm staring at the code like I've never seen it before.

Apparently, I understood it just fine when someone was holding my hand through the entire explanation.

That is not quite the same thing as actually knowing it, though.

And I'm not talking about memorizing syntax or remembering every little API detail. I look things up all the time, and I don't see anything wrong with that.

I'm talking about understanding why something was done a certain way.

If all I can remember about a feature is that AI wrote it and it worked, I haven't really learned much from it.

Sometimes the interesting part is the problem you didn't know existed

I've been working on a text editor called Slate, which has been a really interesting learning experience for me.

One thing I hadn't given much thought to before was what actually happens when you save a file while you're still editing it.

I mean, saving a file sounds pretty simple, right? Write the contents to disk, mark it as saved, done.

Except what happens if the user keeps typing while that save is happening?

The file being written contains the older content, but the editor now has newer changes. So if the save finishes and the editor clears the unsaved indicator, it's basically telling the user everything is saved when it isn't.

Slate uses revision-based save tracking to handle this. When a save starts, it remembers which revision of the document it's saving. That way, any changes made while the save is happening don't accidentally get marked as saved too.

Now, AI could have just implemented all of that for me. I could have tested the save button, seen that it worked, and moved on with my life.

But understanding why that revision tracking matters is what makes it useful to me.

It's not really about the code itself. It's about recognizing that something can change between the time an operation starts and the time it finishes.

And that's a problem that could come up in all kinds of applications, not just text editors.

That's the kind of thing I want to take away from a project.

Actually experimenting makes a huge difference

I've noticed the same thing when working with local AI models.

Let's say I run a model and it takes 30 seconds to complete something.

Okay, so it's slow. Right?

Well, maybe. But what actually took 30 seconds?

Was most of that time spent loading the model into memory? Was the actual processing slow? Would running it a second time be significantly faster?

Those are all things I can test.

And I find that I learn a lot more when I actually start experimenting instead of just asking AI to explain what's happening.

Run it again. Measure things separately. Change something. See what happens.

Sometimes the results are exactly what I expected. Other times they're not even close, which is usually when things get interesting.

I love that I can use AI to help me figure things out. I can ask what else I should try, or why the result isn't what I expected.

That makes learning unfamiliar things so much easier.

But there's a big difference between AI telling me why something should happen and me actually seeing what does happen.

And sometimes AI's explanation is wrong, too. Which I am sure we all know.

I don't necessarily remember the code, but I remember the problem

I think this is probably the biggest thing I've noticed.

When I really spend time understanding something, I might not remember the exact implementation later. But I remember the problem I was trying to solve and why I solved it that way.

And that carries over into other projects.

Maybe I start wondering whether some asynchronous operation could finish after the user has already changed something.

Or whether a performance issue is actually a startup issue.

Or whether I'm storing some piece of state that I could just calculate from something else.

I might still need to look things up. I might still ask AI to help me write the implementation.

But at least I know what I'm looking for and why it matters.

If I just accept the generated code without thinking much about it, I miss all of that. The solution is sitting right there in my project, but I might not even recognize the same problem when I run into it somewhere else.

And considering how often I start new projects, there's a pretty good chance I will run into it somewhere else. Probably next week.

Of course, I don't need to turn everything into a learning experience

I also think there's a balance here.

Sometimes I just want AI to fix the padding on a button.

I don't need to spend 45 minutes investigating the underlying principles of CSS spacing. I just want the button to look right.

And there are plenty of things I'm perfectly happy to let AI handle. Boilerplate, repetitive changes, things I've already done a hundred times, or just tedious work I don't feel like doing.

That's part of why I use these tools in the first place.

But when I'm building something unfamiliar, or working on functionality that I know I'll need to maintain later, I try to be a little more involved.

Sometimes that means just asking questions.

Other times I might just start changing things to see what happens.

I think even something as simple as predicting what a change will do before running it can make a difference. Because if the result isn't what I expected, now I have something to investigate.

Do I do this every time? Absolutely not.

Sometimes I've been staring at something for two hours, AI finally gets it working, and my entire thought process is basically "thank you, finally, moving on."

I'm not going to pretend otherwise.

But I am trying to be more conscious of when I'm actually learning something and when I'm just getting something done.

Because those aren't always the same thing.

Getting something working isn't the same as learning how it works

One of my favorite things about AI coding tools is how much more willing I am to try things I know very little about.

I've experimented with languages, frameworks, local models, desktop applications, and all kinds of other things that I probably would have put off before.

Not necessarily because I couldn't learn them, but because getting started on something completely unfamiliar can be a lot of work.

AI makes that initial hurdle so much smaller, and I think that's genuinely awesome.

But there's also a temptation to just keep building. One feature works, so you move on to the next one. Then the next. Before you know it, you've got a whole application and only a vague understanding of some pretty important parts of it.

And it's so easy to confuse all that progress with learning.

I've definitely done it.

I think the things that stick with me the most are usually the things I had to investigate a little. Something didn't behave the way I expected, or I got curious about why it worked a certain way, and I spent some time figuring it out.

Sometimes that investigation only takes a few minutes. Sometimes it sends me down a rabbit hole for the rest of the night.

Either way, I tend to remember those experiences a lot more than the features that worked perfectly on the first try.

And that's something I want to keep in mind as I continue building with AI.

I don't want to stop using these tools or intentionally make everything harder for myself.

I just don't want to get so caught up in how much I can build that I forget to pay attention to what I'm learning along the way.

So... what about you? Have you learned something useful while building with AI that you can now troubleshoot or explain yourself? Or have you ever gone back to AI-generated code and realized you had absolutely no idea how it worked?

I Built an AI Game That Wants You to Go Outside

Jessica Doering — Sat, 10 Oct 2026 03:58:49 +0000

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

What I Built

I spend way too much time at my computer. Between coding, experimenting with AI models, and starting new projects when I have a perfectly good collection of unfinished ones already, I don't exactly have a shortage of reasons to stay indoors.

So when I saw that the theme for this week's Hacktoberfest challenge was Touch Grass, I immediately thought it would be fun to build an AI-powered game that encourages people to get away from their computers.

Which is a little ironic, considering how many hours I then spent at my computer building it. But anyway.

This is Side Quest!

side-quest.pinkpixel.dev

Side Quest is a little outdoor adventure game powered by Google's Gemma model. The idea is pretty simple: you tell the game a little about where you are and what it's like outside, and Gemma comes up with a small quest for you to complete in the real world.

Maybe you're walking through a park on a fall afternoon. Maybe you're just hanging out in your backyard. Gemma takes your surroundings, the season, weather, and time of day into account and gives you something to go find.

You head outside, find whatever it asked for, and take a picture. Then Gemma examines your photo to decide whether you've actually completed the quest.

When you successfully complete a quest, you hatch a little creature inspired by whatever you found.

Of course I had to add a creature collection. I love games where you can discover and collect things, and I thought it would be great to have something to show for all those little outdoor adventures.

Plus, I liked the idea of making people pay attention to things they might normally walk right past. An interesting looking leaf, an unusual rock, a shape in a tree. The kinds of things you might notice if you weren't staring at your phone.

Yes, I realize the irony of using your phone to play a game that's supposed to get you to stop staring at your phone.

How it works

The gameplay is pretty straightforward:

Set the scene. Tell Gemma where you are, what the weather is like, what season it is, and what time of day. You can choose from the options or describe your location yourself.
Get your quest. Gemma creates a little challenge based on your surroundings.
Go find it! Head outside, explore a bit, and take a photo of whatever you discover.
Get judged by Gemma. The model examines your photo to see whether it matches the challenge. If it doesn't, it'll tell you why, and you can give it another shot.
Hatch a creature. Complete the quest and get a new little companion for your collection.

The creatures were especially fun to work on.

I didn't want to just make ten pre-designed creatures and randomly hand one out whenever someone completed a quest. That felt a little boring.

Instead, Gemma looks at the photo and describes characteristics that could inspire a creature. The app then uses those traits to draw a little SVG character.

The photo also determines a consistent seed, so submitting the same image produces the same creature.

It's not generating a whole new image through an API. The creatures are actually drawn by the app, using the details Gemma provides.

I love this because your reward is connected to something you really found outside. And honestly, seeing what kind of little creature is going to hatch is half the fun.

There's also a collection where you can look through your creatures alongside the original photos. It's basically a nature journal, except everything has adorable little faces.

I also added a Scavenger Hunt mode!

Instead of getting one quest at a time, Gemma gives you a list of things to find during a walk. You can take photos of everything and submit the whole collection for judging.

I wanted Side Quest to be something that kids and adults could both enjoy. Something you could play with your family, or just by yourself when you need an excuse to get away from your desk for a while.

It's not trying to be a fitness app. There are no step counts, exercise goals, or leaderboards.

It's just a little game that makes going outside and exploring your surroundings more interesting.

Demo

Play Side Quest: https://side-quest.pinkpixel.dev

You can try Side Quest right in your browser.

For desktop, you'll need a recent Chrome or Edge browser with WebGPU support. Click Wake Gemma, and the model will load directly into your browser.

One thing to be aware of: the initial model download is around 3.4 GB. So you'll probably want to be on Wi-Fi for that first visit. Once it's downloaded, the model is cached in your browser.

The desktop version is great for trying everything out, but obviously, carrying your computer outside to photograph a leaf isn't exactly practical.

That's where the mobile experience comes in.

You can use your computer as a home base that runs Gemma while you take your phone outside to complete quests.

Just sign in with GitHub on your computer, leave Gemma running in the home-base tab, and scan the pairing QR code with your phone.

Then you're ready to go exploring.

Your phone handles the quests, photos, and creature collection while your computer does all the heavy AI work.

I also made sure the phone can hold onto your photos when you don't have a connection. They'll sit in a local queue and send when you're back online.

Code

GitHub: https://github.com/pinkpixel-dev/side-quest

Side Quest is open source under the Apache 2.0 license.

The repo includes the React frontend, Gemma inference worker, quest generation and creature logic, Cloudflare Worker backend, optional private home-base server, and tests.

If you'd like to run the basic solo version locally, it's pretty simple:

npm install
npm run dev

Then open http://localhost:5173 in a desktop browser that supports WebGPU.

The README has more detailed instructions for setting up the hosted features, account authentication, and the private phone-to-desktop option.

How I Built It

Putting Gemma to work

For the AI side of things, I used Gemma 4 E2B, Google's open-weight multimodal model, running with Transformers.js and WebGPU.

I'm using the 4-bit ONNX version, onnx-community/gemma-4-E2B-it-ONNX, which loads in a web worker so the model isn't blocking the main UI.

I've been having a lot of fun experimenting with models running directly in the browser lately, so I was excited to have an excuse to build something a little different with one.

And Gemma isn't just there to generate some flavor text. It's actually responsible for the main parts of the game.

It handles:

Quest generation: Creating challenges based on your surroundings, weather, season, and time of day.
Photo judging: Looking at your submitted image and deciding whether you actually found what the quest asked for.
Creature traits: Describing features inspired by your photo that the app can use to draw your new creature.
Scavenger hunts: Coming up with multiple things to find and evaluating the collected photos.

I especially like that Gemma evaluates your photo and describes the creature together. Your discovery actually influences what you get as a reward.

For the rest of the stack, I used React 19, TypeScript, Vite 8, and Tailwind CSS 4.

IndexedDB handles the local storage for quests, photos, completed finds, and creatures. And the creatures themselves are generated as SVGs, so there's no need for a separate image generation model or service.

The part that got complicated

There was one pretty obvious problem with my whole idea.

I wanted people to use this game while walking around outside. But the Gemma model runs best with a desktop GPU.

Not exactly ideal for a mobile game.

Naturally, I decided to see if I could get it running on my iPhone 12 anyway.

That experiment ended pretty quickly.

The browser made it about 500 MB into downloading the 3.4 GB model before deciding it had had enough and killing the tab.

So, there goes that idea.

I could have switched to a cloud AI API and called it a day. But I really wanted to keep Gemma running locally, and I wasn't ready to give up on that part.

So I came up with a different approach.

Let the phone do the exploring and let the computer do the thinking.

The desktop browser loads Gemma and acts as a home base. Your phone connects to it and becomes the lightweight interface you actually carry around.

When you submit a photo, it gets sent back to your home base, where Gemma evaluates it and generates the creature traits. The result then comes back to your phone.

The model never has to run on the phone, and there's no cloud AI inference service involved.

I also added some quest pre-generation. The home base prepares a little pool of quests and scavenger hunts ahead of time, so you don't have to stand around waiting for Gemma to think of something every time you want a new one.

If you change your surroundings or conditions, the old quests get discarded and new ones are generated.

And because I wanted the game to work when someone loses their signal, the mobile app saves unsent finds in IndexedDB and retries them once the connection returns.

What started as a simple little outdoor game was suddenly turning into a whole phone-to-desktop AI system.

You know how these things go. One little feature leads to another, and before you know it, you've built three extra systems just to make the original idea work.

Making the setup less ridiculous

My original solution used a local Node server and a temporary Cloudflare tunnel to connect the phone to the desktop.

It worked, and I actually kept that option in the project. You can still run it with npm run home if you prefer a private, self-hosted setup.

But then I started thinking about what it would be like for someone who just wanted to try the game.

Imagine telling someone:

"Hey, I made this cute little game where you go outside and find things. First, install Node, download some dependencies, run a server, start a tunnel, and pair your phone."

Yeah. No.

That's a lot of work just to go look for an interesting rock.

So I added a hosted option to make the whole process easier.

It uses a Cloudflare Worker to relay messages between your phone and the home-base browser, D1 for account and quest data, and R2 for photo storage.

You sign in with GitHub on your desktop, scan a temporary QR code with your phone, and you're connected.

Your creature collection can also sync between your signed-in devices.

The important part is that Cloudflare isn't running the AI model. Gemma still runs locally in your desktop browser using your GPU. The hosted services just handle communication and storage.

I also wanted to be clear about what happens to your data, because I think that's important when talking about local AI.

Solo mode: Your photos and game data stay in your browser's local storage.
Hosted mode: Photos go through the Cloudflare Worker and are stored in R2. You can delete your account, including its associated photos and records.
Private home-base mode: Your photos stay on your own computer instead of being stored in the hosted service.
Location: The game doesn't track your GPS coordinates. If you enter a location, it's just text used to help Gemma create an appropriate quest.

So while the AI inference is local, I'm not going to pretend that every part of the hosted experience is completely offline.

A few things I learned along the way

One thing that surprised me about this project was how little of the actual work involved getting Gemma to generate text.

That part was fun, of course. But once I got into the phone-to-desktop setup, I found myself spending a lot more time dealing with state synchronization, queued requests, connection handling, and making sure everything still behaved properly when one device went offline.

Basically, all the less exciting stuff that has to work before you can enjoy the exciting stuff.

I also ran into a particularly annoying issue with Cloudflare Worker requests.

My tests were passing, but when I tried making requests through the actual Vite development proxy, I kept getting 403 errors.

It turned out that the test harness and development proxy were presenting different combinations of request URLs and Origin headers. My origin validation was fine in the tests, but it was rejecting legitimate requests in the browser.

The fix was to account for the request host or explicitly configured application origin, and to make sure I was testing through the actual development proxy rather than relying entirely on the test harness.

A good reminder that passing tests don't necessarily mean everything works in the real world.

I used Vitest for testing, including Wrangler's test harness with local D1 and R2 bindings for the Cloudflare Worker.

Not quite as exciting as hatching adorable little creatures, but I suppose the plumbing has to work too.

Why Does Open Innovation Matter?

This is actually one of my favorite things about building projects with open-weight models.

I love experimenting with AI, especially when I can run models locally and figure out interesting ways to use them.

And I think projects like Side Quest are a great example of why having access to those models matters.

Sure, I could have built this game using a hosted vision API. It probably would have been easier in some ways.

But then every quest, every photo evaluation, and every creature would mean another request to an external AI service.

With Gemma, I can run the model directly on my own hardware, experiment with how it behaves, and build an entire little game around it without paying for every interaction.

For the core solo experience, there's no account required, no external AI API, and no server processing your photos. The model runs right in your browser.

And because the model is available to run myself, I can actually experiment with it.

I can change the prompts, adjust the structured outputs, fine-tune how quests are judged, and try different approaches to generating creature traits. I could even experiment with other compatible models in the future.

I'm not limited to whatever features a hosted API happens to expose.

But I think the most interesting part of this project is how that freedom influenced the design.

When I realized Gemma wasn't going to run on my phone, I didn't have to abandon local inference entirely.

Instead, I found a way to use my desktop browser as a tiny personal AI server while my phone handles the actual gameplay.

And I think that's pretty awesome.

It also makes me wonder what else you could build using that same approach. A powerful local model running on one device, with lightweight interfaces connecting to it from somewhere else. There's a lot of room to experiment there.

Of course, local AI isn't without its limitations. The model download is pretty hefty, you need hardware that can run it, and the optional hosted features still involve cloud services.

But open-weight models give developers more choices about how to build things, and I love that.

Not everything needs to be another app that sends a prompt to a paid API and displays the response.

Sometimes you can get a little more creative with it.

And in this case, I used an AI model to build a game that encourages people to spend less time interacting with AI.

I still find that pretty funny.

Prize Categories

Best Use of Gemma: Gemma 4 E2B powers the core gameplay, including context-aware quest generation, multimodal photo judging, scavenger hunts, and creature trait generation. It runs locally in the browser using Transformers.js and WebGPU.

Final Thoughts

I had a lot of fun building this one!

It turned out to be a bit more involved than I originally expected, especially once I decided that the game really needed to work on a phone. But figuring out how to make that happen while keeping Gemma running locally was probably the most interesting part of the whole project.

And I genuinely love the little creatures. I could probably spend a lot of time just seeing what kinds of things Gemma comes up with from different photos.

I also think it's nice to build something that's just meant to be fun.

Not every AI project needs to automate your entire life, make you more productive, or solve some enormous problem.

Sometimes it's perfectly fine to build something that just gets people to go outside and take pictures of leaves.

If you give Side Quest a try, I'd love to hear what you think! And especially what kind of creatures you end up hatching.

Play Side Quest | Check out the source on GitHub

Learning GPUI by Building My Own Text Editor

Jessica Doering — Thu, 08 Oct 2026 21:30:39 +0000

I've been wanting to experiment with GPUI for a while now. It's the Rust UI framework developed for Zed, and I was curious what it would be like to use it for something of my own.

So, naturally, I decided to build a text editor.

Because apparently the best way to learn a new UI framework is to pick a project that already has about a million little details to get right.

Anyway, the result is Slate, a lightweight, native text editor for Linux, built with Rust and GPUI Kit.

Why GPUI?

Most of the desktop apps I've worked on have used web technologies, so I wanted to try something different.

GPUI caught my attention because it's the framework behind Zed, and I really like the idea of building native desktop interfaces with Rust.

Rather than having a web frontend wrapped in a desktop shell, GPUI lets you build the interface directly in Rust.

Of course, that also means learning a different way of thinking about UI development.

I was especially interested in seeing how practical it would be to build a complete application with it, rather than just experimenting with a few buttons and windows.

Discovering GPUI Kit

One thing I quickly realized is that GPUI itself isn't a complete collection of ready-made application components.

And writing an entire text editing component from scratch wasn't exactly what I had in mind.

Thankfully, I found GPUI Kit.

GPUI Kit provides a collection of components built on GPUI, including things like tabs, dialogs, menus, trees, themes, and most importantly for this project, an actual text editor component.

That last part made a huge difference.

Building a text editor involves a lot more than displaying text and responding to keyboard input. You need to deal with cursor movement, selections, undo history, syntax highlighting, multiple cursors, and all kinds of behavior that people expect to just work.

GPUI Kit already handles much of that.

It gave me a foundation to build on so I could focus on making the application I wanted rather than spending forever implementing basic editing functionality.

That doesn't mean everything was plug-and-play, though.

Building Slate

I wanted Slate to fit somewhere between a very basic text editor and a full-featured editor like Kate.

Something I could open quickly to edit a config file, work on some Markdown, or browse a few source files without launching an entire IDE.

I also wanted it to look nice. That's important to me, even with small utility apps.

One of the things I particularly wanted was color-coded tabs. When I have a bunch of files open, I like being able to distinguish them at a glance.

GPUI Kit has a tab component, but it didn't support the drag-and-drop reordering or colored accent lines I wanted.

So I built Slate's tab strip myself using GPUI, while still using Kit's components for things like context menus and tooltips.

That ended up being a pretty good example of how I approached the project: use GPUI Kit wherever it made sense, then build the parts that needed something different.

The same thing happened with the find and replace bar. GPUI Kit already has the underlying search functionality, but I wanted the interface to sit neatly above the editor instead of floating over it.

So I reused Kit's search engine and built my own interface around it.

I actually enjoyed that flexibility quite a bit.

Some things I learned along the way

Working with GPUI and GPUI Kit was interesting, but there were definitely some challenges.

One of the biggest lessons was learning to work within the public APIs that the component library exposes.

For example, GPUI Kit supports multiple cursors, but the version I'm using doesn't expose a public method for programmatically adding a selection at a specific range.

That meant a feature I wanted, Ctrl+D to select the next occurrence of some text, wasn't something I could easily implement without modifying the library.

It's on hold for now.

Another interesting challenge was the minimap.

I wanted a little overview of the file along the right side, similar to what you see in VS Code.

The problem was that GPUI Kit's editor doesn't expose all the layout and syntax information needed to draw one directly.

I ended up creating a custom minimap using GPUI's canvas rendering, with a separate syntax highlighter providing the colors.

There's also a catch with wrapped lines. Without access to the editor's exact line layout, the minimap's viewport indicator wouldn't always line up correctly.

Rather than leave something that behaved incorrectly, I decided to hide the minimap when word wrap is enabled.

Not the most exciting compromise, but it works reliably.

I ran into some other interesting issues with theme reloading, file watching, keyboard events, and Linux window behavior.

These are exactly the kinds of details that are easy to overlook until you're building an application that needs to handle them.

And honestly, working through those problems was a big part of why I wanted to try this project in the first place.

What Slate can do now

Even though I started Slate as a way to learn GPUI, it ended up becoming a pretty capable little editor.

Some of the features in the first release include:

Syntax highlighting for 23 languages, powered by Tree-sitter through GPUI Kit
Multiple tabs, including drag-and-drop reordering and customizable tab colors
39 built-in themes, including Catppuccin, Gruvbox, Tokyo Night, and several Slate-specific themes
File sidebar with automatic updates, folder navigation, and hidden-file controls
Find and replace, Quick Open, and a searchable command palette
Session restore, including unsaved edits, so you can pick up where you left off
Live Markdown preview in a split view
Syntax-colored minimap for navigating longer files
Clickable color swatches for editing hex, RGB, and HSL colors
File change detection, including the ability to compare your edits against the version on disk

There are plenty of smaller conveniences too, like line duplication, moving lines up and down, comment toggling, indentation detection, and opening files directly from the terminal.

I also made the themes customizable. You can drop a JSON theme file into Slate's themes folder and edit it while the app is running. Slate watches for changes and updates the appearance automatically.

That was a particularly fun feature to get working.

The first release is available

Slate 1.0 is now available on GitHub.

It's currently Linux-only, and I've been developing and testing it on CachyOS with the COSMIC desktop.

If you're using Arch or an Arch-based distribution, you can install it from the AUR:

yay -S slate-editor

Or, if you'd rather build it yourself:

git clone https://github.com/pinkpixel-dev/slate.git
cd slate
cargo run --release

You'll need Rust 1.92 or newer and a working Vulkan driver. I've included more detailed requirements and instructions in the README.

And since this is the first release, I definitely wouldn't claim it's perfect. I've only tested it on my own desktop environment so far, and I'm sure there are things that will need adjusting as it gets used on other systems.

What's next?

I'm happy with how the first version turned out, but I don't consider Slate finished.

There are still features and improvements I'd like to explore, especially as GPUI Kit continues developing and potentially exposes more of its editor functionality.

At the same time, I don't want Slate to turn into another full IDE.

There are already plenty of excellent editors that do that.

My goal is to keep it lightweight, useful, and pleasant to work with. Something that does the everyday editing stuff really well without needing a hundred additional features.

Final thoughts

Building Slate gave me a much better understanding of GPUI and what it's like to develop a native desktop application with Rust.

I also came away with a lot of appreciation for how much work goes into something as seemingly simple as a text editor.

It's one of those applications where the interface might look straightforward, but there's an incredible amount happening underneath.

GPUI Kit made this project much more approachable, and having the option to mix its existing components with custom GPUI interfaces was probably my favorite part of working with it.

I'm definitely interested in experimenting with GPUI some more.

If you're curious about the project, the source code is available here:

Slate on GitHub

And if you've worked with GPUI or GPUI Kit yourself, I'd love to hear what your experience has been like!

AI Is Making It Too Easy to Avoid Thinking

Jessica Doering — Mon, 05 Oct 2026 21:55:27 +0000

I use AI every day.

I build things with it, experiment with it, write code with it, learn about new things with it, and generally think it's one of the most interesting technologies I've ever had access to.

So this is definitely not an "AI is ruining everything" post.

But I do think AI is creating a problem that we probably need to talk about more:

It has become incredibly easy to avoid thinking.

And that cannot be good for us.

We used to have to struggle a little

Say you have to write an essay about something you don't care about and are not at all interested in.

Maybe it's for school. Maybe it's for work. Whatever it's for, somebody wants you to write 1,500 words about a topic you know absolutely nothing about.

20 years ago that kinda sucked.

You had to research it.

You had to figure out what people were talking about.

Read the same pages over and over again til they stuck with you.

Take notes.

Then you had to decide which information was important.

You had to organize your thoughts.

You had to stare at a blank page for twenty minutes because you had no idea where to start.

You'd write something, hate it, rewrite it, realize you misunderstood something, go look it up again, take a break, come back to it, and eventually, little by little you would piece together something decent.

But you had to think, and you had to do the hard thing because no one was going to do it for you.

And somewhere in all of that annoyance, you probably learned something.

Not just about the subject.

You practiced researching.

You practiced deciding whether a source made sense.

You practiced turning information into your own understanding.

You practiced explaining something.

You practiced writing.

You practiced being stuck.

That last one might be the most important.

And honestly you probably were feeling pretty good at the end of it all because you felt like you had accomplished something.

Now the hard part is optional

These days all you need to do is type:

Write me a 1,500-word essay about this topic.

And thirty seconds later, there it is.

Maybe you edit it.

Maybe you fix a few sentences.

Maybe you read through it closely enough to make sure it doesn't say anything stupid.

But you didn't actually have to do most of the work that used to happen between receiving the assignment and having the finished result.

AI did the research.

AI organized the ideas.

AI figured out the structure.

AI found the words.

The end product might be perfectly fine.

But producing the end product was never the only point.

Sometimes the process was teaching you something too.

I see this with kids

This part really worries me.

If a kid has 10 math problems for homework and doesn't understand number 7, there are two very different ways to use AI.

One is:

What's the answer to number 7?

The other is:

Can you help me understand how to solve this without giving me the answer?

Those might look like tiny differences in prompting.

They're not.

One replaces the thinking.

The other supports it.

And when the easiest option is always sitting three seconds away, I think it takes a surprising amount of discipline to choose the harder one.

Adults definitely do it too.

Why spend an hour figuring something out when you can ask an AI?

Why read the documentation?

Why wrestle with the bug?

Why write the first draft?

Why sit there thinking about how you actually feel about something?

Why learn the formula when something else can calculate it for you forever?

Sometimes the correct answer genuinely is: don't waste your time doing this manually.

I automate things specifically because I don't want to do repetitive crap manually.

But not all difficulty is useless friction.

Sometimes difficulty is the exercise.

I think we've started confusing "hard" with "unnecessary"

This is probably the part I think about the most.

We've spent decades making technology remove friction from our lives.

Usually that's awesome.

I don't particularly miss having to drive to the library to do research.

I don't think programmers need to give up autocomplete and start writing machine code to prove we're still using our brains.

There is no virtue in making something difficult solely for the purpose of making it difficult.

But I think we've started treating any mental friction as a problem technology should solve for us, and we're starting to lose the desire to accomplish something on our own.

Struggling to understand something is uncomfortable.

Sitting with a problem is uncomfortable.

Being confused is uncomfortable.

Writing badly before you learn to write well is uncomfortable.

Trying 3 solutions that don't work is uncomfortable.

Honestly, just being wrong is uncomfortable.

But those experiences also build something.

They build judgment.

They build persistence.

They build the ability to look at something unfamiliar and think:

I have no idea how to do this, but I can probably figure it out.

I'd really hate for us to lose that completely.

AI can either make us better or much worse

The weird thing is that AI might be one of the greatest learning tools we've ever invented.

You can ask it to explain something to you 5 different ways until you get it.

You can ask it to test you.

You can argue with it.

You can tell it your answer and ask what mistakes you made.

You can ask it for hints instead of the answer itself.

Learning can be incredibly fast with these tools.

That's the part of AI I love.

But the same tool can also let you skip the entire learning process.

And the difference isn't really the technology.

It's how we decide to use it.

Sometimes I'll ask AI something and realize afterward that I probably should have spent another ten minutes thinking about it myself first.

Not because using AI was cheating.

Not because the machine somehow contaminated the answer.

Just because I needed the exercise.

Maybe we need to protect some of the struggle

I'm definitely not suggesting we stop using AI.

Good luck prying it out of my hands.

I think maybe we have to be more deliberate about choosing what aspects of our thought process we're comfortable delegating.

Let the AI help you understand the chapter, but maybe don't let it read the chapter for you every time.

Let the AI point out why your math solution is wrong, but maybe try to work out the problem yourself first.

Let the AI help with debugging your code, but maybe take some time to try to understand the bug a little bit before throwing it at an AI chatbot.

Let the AI critique your argument, but maybe figure out what you think before asking it what you should think.

Because if we outsource every difficult thing the instant it becomes uncomfortable, eventually we're going to become very good at operating AI tools and very bad at operating without them.

AI should give us more ability to think.

It shouldn't give us an excuse not to.

I Gave My AI Agents Their Own Documentation Crawler, and Pulled 60 Pages of Clean Markdown in 49 Seconds

Jessica Doering — Mon, 05 Oct 2026 07:40:48 +0000

It's not just that I made a crawler, but it's how the docs actually look that makes me love this so much.

I made an MCP server this weekend, and I am kind of in awe of how well this thing works.

It's called pulpie-mcp, and the basic idea is pretty simple:

Give AI coding agents their own tool for pulling full web pages and documentation into clean Markdown.

Not summarized documentation. Not chopped-up search results. Not "here are the important parts I think you need."

The actual content.

Tables, links, images, code, headings, all turned into Markdown and saved somewhere the agent can use again later.

pinkpixel-dev / pulpie-mcp

pulpie-mcp

An MCP server that gives AI agents their own tools for turning web pages into clean Markdown. It runs the Pulpie content extraction model locally, so tables, code blocks, links, and images come through intact instead of getting summarized away.

The agent can read a page inline, save it as a .md file, crawl a whole docs section into a folder, and check what it already saved before fetching again.

Why I made it

I already had a little local UI for Pulpie that I used to pull docs and articles into Markdown, and it works really well. But I was still the one doing the pulling. Most agent fetch tools run pages through a small model that summarizes or trims them, which is not what you want when the agent needs the actual API reference.

So this gives the agent the same thing I was using. It can…

View on GitHub

The test that kind of blew my mind

I had Claude test crawl_docs against a documentation site with 60 pages.

The backend wasn't already running, so this included starting the server and loading the extraction model onto my GPU.

Phase	Time
Backend cold start	~10s
Crawling and saving 60 pages	~37s
Total	~49s

So in under a minute, Claude went from having none of those docs locally to having 60 clean Markdown files it could search, read, and reference.

I just thought this was so awesome.

And once the model is already loaded, obviously that initial ~10-second startup cost disappears.

Why I built it

I've already been using Pulpie locally to turn web pages into Markdown.

It uses a small content extraction model rather than just grabbing the raw page or trying to summarize it, and I've been really impressed with the results.

But there was one annoying part:

I was still the one pulling the documentation.

If I wanted an agent to work with a library or framework, I might grab some docs, save them into the project, point the agent toward them, and then let it work.

Which is fine.

But also... why am I doing that?

The agent has MCP tools. It knows what documentation it needs. It knows what project it's working on.

So I built an MCP server that lets it do the whole thing itself.

What pulpie-mcp gives the agent

There are currently four tools:

Tool	What it does
`fetch_markdown`	Fetch a page and return clean Markdown directly to the agent
`save_markdown`	Fetch a page and save it as a Markdown file
`crawl_docs`	Crawl an entire documentation section and save it locally
`list_library`	Check which documentation has already been saved

The distinction between fetching and saving turned out to be especially useful.

Sometimes an agent just needs to quickly read one page.

Other times I'm working on a project where I want it to pull an entire section of documentation and keep it around.

For example, I can basically tell Claude:

Pull the uv docs into this project's DOCS/reference folder.

And it handles the rest.

Or:

Do we already have the FastAPI docs saved somewhere?

No elaborate prompts required.

It doesn't shove 60 pages into the context window

This part was important to me.

When crawl_docs saves documentation, it doesn't return the contents of every page to the agent.

That would be completely insane.

Instead, the docs are written to disk and the agent gets useful metadata back. Each file also includes frontmatter with the source URL, title, and fetch time.

So the agent can grab a whole documentation section once and then read only the files it actually needs.

That turns the local filesystem into a pretty nice little documentation library.

For project-specific docs, the agent can save them inside the project.

For general research, pulpie-mcp has a global library at:

~/.pulpie/library/

Crawling is actually fairly smart too

crawl_docs doesn't just blindly click every link it sees.

It looks for sitemap information first:

robots.txt
a sitemap under the documentation path
the site's root sitemap
link crawling as a fallback

It stays on the same host and underneath the documentation path you started with.

There are four concurrent crawling workers, so network requests can overlap while extraction is happening.

That's how it managed to tear through those 60 pages so quickly.

The model runs locally

This is probably my favorite part.

pulpie-mcp uses:

feyninc/pulpie-orange-small

It's only a 210M parameter encoder model, and on my machine it uses around 420 MB of VRAM.

The MCP process itself doesn't load PyTorch or the model.

Instead, there's a tiny MCP server and a separate local backend.

When the agent uses one of the tools:

Agent
  ↓
MCP server
  ↓
Local Pulpie backend
  ↓
Web page
  ↓
Clean Markdown

If the backend isn't running yet, the MCP server starts it automatically.

Once it's running, every agent session shares the same backend, so I don't end up with Claude, Codex, and whatever else I'm abusing that day each loading their own copy of the model.

After 30 minutes without a request, it shuts itself down and releases the memory.

That was one of those little implementation details that took this from "neat experiment" to something I can actually leave installed and forget about.

Adding it to Claude Code

Install it:

uv tool install git+https://github.com/pinkpixel-dev/pulpie-mcp

Then:

claude mcp add --scope user pulpie -- pulpie-mcp

That's basically it.

The first time it runs, the Pulpie model downloads from Hugging Face.

Codex

Add this to:

~/.codex/config.toml

[mcp_servers.pulpie]
command = "pulpie-mcp"

And other MCP clients can use a normal MCP server configuration.

There are still some limitations

I haven't come across any pages that haven't worked yet, but it's possible that some completely client-rendered pages could come back empty. And it doesn't handle PDFs.

I've only personally tested it on Linux with NVIDIA/CUDA so far.

There is also one license note: the pulpie-mcp code is Apache 2.0, but the pulpie-orange-small model is licensed CC BY-NC 4.0, so the model is for non-commercial use unless you arrange something different with its creator.

This is exactly what I want MCP to be used for

I think that's what has me so excited about this project.

MCP gets discussed a lot in terms of connecting agents to giant services and APIs.

But I really like this smaller category of MCP tools:

Give the agent one very specific capability that removes a repetitive step from my workflow.

I used to:

Find the documentation.
Pull the relevant pages.
Clean them up.
Save them somewhere.
Tell the coding agent where they are.
Finally start working.

Now I can basically say:

Grab the docs you need and figure this out.

And it does.

Seeing it pull 60 pages in about 49 seconds, save them as clean Markdown, build an index, and then immediately start using them was one of those wonderful little:

"Oh. Damn. This is actually really useful."

moments.

And those are my favorite kinds of projects.

Repo:

pulpie-mcp

I built my husband a vim trainer with a Gemma coach that runs in the browser

Jessica Doering — Sun, 04 Oct 2026 05:16:41 +0000

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

What I Built

A lot of my friends build their own tools. They hit a problem and just make the thing they want. I wanted to build something for someone else this time, and the answer was sitting right next to me.

My husband has wanted to learn vim for a long time. He's tried a bunch of times, and it always ends the same way: he gives up. When I asked him why, it came down to two things. There are too many commands to memorize, and everything feels slow and awkward compared to what he's used to.

So I built hjkl, a browser app that teaches vim in tiny drills.

Each drill gives you a small buffer, a goal, and a keystroke "par" to beat. You solve it in a real vim editor, not a simulation. A few things I designed around his actual problems:

Only a few commands at a time. Each lesson introduces a small set of commands, with a cheat sheet always on screen.
Every command shows the VS Code habit it replaces. dd is Ctrl+Shift+K, o is Ctrl+Enter, ciw is roughly Ctrl+D and type. If there isn't a real equivalent (like . or f), it just says so.
Par instead of pass/fail. You always finish the drill. If you took the long way, you see the shorter answer right there.
A Review list. Any drill you solved over par goes into Review, worst first, and drops off once you hit par. Those are exactly the commands that haven't stuck yet.
A full Vim reference. The lesson cheat sheet only shows what you're currently learning, but there's also an All Commands reference with everything covered in the app. You can search it by key, action, or the VS Code shortcut you're used to.
Plain names under weird keys. <CR> shows "Enter" underneath and <Esc> shows "Escape". I added this after I had to ask what <CR> meant myself while testing.

Right now there are 17 lessons and 124 hand-written drills, starting with basic movement and insert mode and working up through text objects, counts and combos, search, visual mode, substitutions, macros, registers, and more.

Then there's the AI part, which runs entirely in the browser.

When I handed it over to him, he actually sat there and worked through it for a while, which felt like a pretty good sign considering every previous attempt at learning vim had ended with him giving up. He liked the short drills and being able to see the more efficient answer when he took the long way. More importantly, he kept going without me having to convince him to.

Demo

Live: https://hjkl.pinkpixel.dev

You'll want a desktop browser with a physical keyboard (vim on a phone keyboard is not a good time). The AI coach needs WebGPU.

Code

pinkpixel-dev / hjkl

hjkl is a browser app for learning vim through short drills. Each drill gives you a tiny buffer, a goal, and a keystroke par to beat, and you solve it in a real vim editor.

I'm building it for my husband. He's tried to learn vim a few times, but it always ends the same way: too many commands to remember, and everything feels slow and awkward compared to what his hands already know. So instead of one long tutorial, hjkl teaches two or three commands at a time, shows the VS Code style habit each one replaces, and lets you practice until it sticks.

Try it at https://hjkl.pinkpixel.dev

What's in it right now

17 lessons and 124 hand-written drills. They start with movement and insert mode, then work through word and line jumps, file jumps (gg, G, %, {/}), small fixes (…

View on GitHub

How I Built It

The app itself is Vite and plain TypeScript, no framework. The editor is CodeMirror 6 with @replit/codemirror-vim, so it's real vim behavior: motions, operators, text objects, dot-repeat, registers, search.

Every drill is checked in real vim

Every drill has a reference solution, and par is just its length. The test suite runs every reference solution through the actual vim engine and checks that it really produces the goal. That turned out to matter a lot. My first pass had a few pars that couldn't be hit, and the tests caught them immediately. There are 182 tests now.

It also caught some fun bugs. My favorite: search drills worked fine on their own but broke after pressing Next. The vim plugin keeps search history and jump positions globally, so the second search tried to jump to a position from the previous, longer buffer and crashed. Now vim's global state resets for every drill.

The coach: Gemma running on your GPU

The AI coach is optional and off by default. When you turn it on, it downloads Gemma 4 E2B once and runs it in a Web Worker on WebGPU with Transformers.js. Your keystrokes and prompts never leave the browser. The model files come from Hugging Face, and after that everything is local.

A few details:

It loads Gemma 4 through the text-only path, so it only downloads the text model and skips the vision and audio encoders.
It uses q4f16 when the GPU supports fp16 shaders and falls back to q4 otherwise.
Gemma 3 1B is there as a lighter option you can switch to without turning the coach off.

On my machine, Gemma 4 E2B writes about 6 to 7 tokens a second, so a one-sentence explanation takes a few seconds. Gemma 3 1B is faster (about 10 tokens a second), but when I tested both on the same drills, 1B kept getting the commands wrong, and once it just greeted him instead of giving feedback. So Gemma 4 is the default.

The coach does two things:

After an over-par solve, it explains what the shorter answer does differently.
The Hint button nudges you toward the right command without giving away the whole sequence.

Getting the feedback accurate took some work. My first version sent the model the raw keystrokes, and after a drill solved with x seven times, it confidently told him he'd used dd. A small model reading xxxxxxx doesn't really see seven presses of one key.

The fix was to stop making the model parse vim. Before the keys go into the prompt, the app groups them the way vim reads them and labels each one:

x ×7 (delete character)

instead of xxxxxxx, and

cw (change to word end), typed "blue", <Esc> (back to normal mode)

instead of cwblue<Esc>. After that change, all of my test cases came back accurate, like: "dw deletes the word under the cursor, which is much faster than deleting each character individually."

AI-generated drills

The part I'm happiest with is the 5 more button on each lesson.

My first attempt let Gemma write whole drills: the text, the starting cursor, the solution keys. Only 2 of 12 drafts survived validation. The rest had missing cursor marks, keys that didn't do what the instruction said, or text glued onto other words. I kept adding filters and kept finding new kinds of mistakes.

So I split the job up based on what each side is good at:

Gemma writes a short snippet of text (a SQL query, a shopping list, a CSS rule), plus a short instruction.
The app supplies the keys by reusing the key patterns from that lesson's hand-written drills on the new text. Then it plays them in real vim to get the goal and par.
The instruction gets checked. If Gemma's wording doesn't name what actually changes, the app swaps in a plain one like Change "milk" to "eggs".

Now every batch keeps 5 out of 5, in about 15 seconds. Every generated drill is solvable at par, because the app played it before showing it.

Deploying

It's a static site on Cloudflare Workers static assets. The only wrinkle was ONNX Runtime's wasm file, which is about 27 MB, over Cloudflare's 25 MiB per-file limit. Transformers.js already loads it from jsDelivr pinned to the exact version, so I just left it out of the build.

Why Does Open Innovation Matter?

For this project it's pretty concrete. An open-weight model is the reason the coach can run in his browser at all.

With a closed API, every hint and every generated drill would be a paid request, plus a server and an API key to manage. For a gift that's supposed to stick around, that's a bad fit. Running Gemma locally means it costs nothing per use, it works without an account, and his keystrokes and mistakes stay on his machine.

It also means I could do things a hosted API would make awkward. I picked a model size that fits a laptop GPU, compared two Gemma models side by side on the same drills, and swapped between them with one click. The rest of the stack is open too: Transformers.js, ONNX Runtime Web, CodeMirror, and the vim plugin that made "use real vim" possible in the first place.

If I keep working on it, I’d like to add more lessons and keep improving the generated drills, but I also want to see what happens after he’s used it for a while. The whole point was to build something around the way one actual person was struggling to learn, so whether it really helps those commands stick is probably the best test I could give it.

Prize Categories

Gemma: the coach and the AI drill generator both run Gemma 4 E2B locally in the browser through Transformers.js on WebGPU, with Gemma 3 1B as a lighter option.