DEV Community: Jessica Doering

I Retested My MoE Offloading Benchmarks. Some of My Conclusions Changed.

Jessica Doering — Sat, 31 Oct 2026 19:33:06 +0000

A follow-up to my original 16GB GPU experiment, this time with consistent quantization, repeated benchmarks, and a few unexpected results.

I recently published an article about experimenting with Mixture-of-Experts (MoE) offloading on my laptop.

I tested five different models, compared traditional layer offloading against selective expert offloading, and came away with some pretty interesting results.

Some models performed better with selective offloading. Others were considerably faster using traditional layer splitting.

And one model, LFM2.5, performed so badly with selective offloading that I really wanted to figure out what was going on.

Well, the article got some great feedback.

People pointed out things I hadn't properly accounted for, questioned some of my assumptions, and suggested better ways to test what I was seeing.

Which, honestly, is exactly the kind of feedback I love getting.

So naturally, I went right back down the rabbit hole.

And this time, some of the results were very different.

First, what needed fixing?

If you haven't read the original article, you can find it here:

MoE Offloading Isn't Always Faster: I Tested 5 Models on a 16GB GPU

In that experiment, I was testing whether selective MoE offloading could improve performance when running models that were too large to fit entirely in my GPU's VRAM.

The idea is to keep certain operations running on the GPU while offloading selected expert weights and their computation to the CPU.

I used llama.cpp with the --n-cpu-moe option and compared it against traditional layer splitting using -ngl.

But there were a couple of problems with my original testing.

The models weren't all using the same quantization.

I had Phi-3.5 running at Q4_K_M, Apex at Q5_K_M, Qwen at Q6_K, and Gemma and LFM at Q8_0.

That made it difficult to know whether the performance differences were related to the model architectures, quantization, or something else.

A couple of people brought this up in the comments, particularly regarding LFM's terrible performance.

I also wasn't doing enough repeated measurements.

Another person pointed out that laptop thermals, background activity, and ordinary measurement noise could influence the results. He suggested interleaving the configurations rather than running one strategy completely before moving to the other.

That was a really good point.

My original benchmarks were useful for spotting interesting behavior, but some of the smaller differences weren't necessarily meaningful.

So I decided to do another round of testing.

The new test setup

I'm still using the same laptop:

GPU: NVIDIA RTX 4090 Laptop GPU, 16GB VRAM
CPU: Intel Core i9-14900HX, 24 cores / 32 threads
RAM: 32GB DDR5
OS: CachyOS / Arch Linux
Inference engine: llama.cpp with CUDA and Flash Attention enabled

But I changed several things about the testing process.

All five models were now running at Q4_K_M.

I also updated llama.cpp, adjusted the offloading configurations to accommodate the smaller quantized models, and kept enough free VRAM to avoid pushing the GPU right to its memory limit.

For each model, I used the same prompt:

"What are 3 practical benefits of using Arch Linux?

Each configuration received a warmup request before measurement.

I then ran three repeated measurements per strategy in an interleaved order, with short cooldowns between runs.

Instead of relying on a single result, I used the median generation speed.

This doesn't make the experiment perfectly controlled. In particular, changing the quantization, offload settings, and llama.cpp build means I can't attribute every difference to quantization alone.

But it does give me a much better picture of how these models behave under a consistent Q4_K_M setup.

The new results

Here's what happened with the initial 100-token Q4_K_M tests:

Model	Traditional Split	Selective MoE	Result
Phi-3.5-MoE	6.17 tok/s	5.15 tok/s	Traditional +19.8%
Apex-35B	8.20 tok/s	9.70 tok/s	Selective +18.3%
Qwen3.5-35B	7.44 tok/s	9.00 tok/s	Selective +21.0%
LFM2.5-24B	32.96 tok/s	35.44 tok/s	Selective +7.5%
Gemma 4 26B	13.58 tok/s	13.58 tok/s	Tie

Well, that was interesting.

In my original tests, traditional splitting was faster on Qwen, LFM, and Gemma.

Now selective offloading was ahead on Qwen and LFM, and Gemma was essentially tied.

Phi-3.5 had also gone in the opposite direction.

But I wasn't quite ready to declare those results final.

Some of the individual runs had pretty significant variation, including one unusually fast Apex result and one unusually slow LFM result.

So I extended the testing to 512-token generations on a few of the models.

And that's where things got even more interesting.

Qwen: Quantization really does seem to matter

This was probably the result I was most interested in investigating.

In my original tests, Qwen3.5-35B at Q6_K performed better using traditional layer splitting.

But Apex-35B, which uses a related 256-expert MoE architecture, performed better with selective offloading at Q5_K_M.

I wondered whether the quantization difference was contributing to that behavior.

The new Q4_K_M results certainly suggested it might be.

So I went a little further.

I tested the same Qwen3.5-35B checkpoint at Q4_K_M and Q6_K, using the same llama.cpp build and longer 512-token generations.

Here's what I found:

Quantization	Traditional Split	Selective MoE
Q6_K	6.79 tok/s	6.75 tok/s
Q4_K_M	6.47 tok/s	8.38 tok/s

At Q6_K, the two strategies were practically tied.

At Q4_K_M, selective MoE offloading was 29.5% faster.

That's a substantial difference.

And unlike the original Apex-versus-Qwen comparison, this time I was comparing different quantizations of the same model, on the same inference engine build.

I still can't say quantization was the only factor, because the layer placement also needed adjusting to fit the different model sizes.

But this is much stronger evidence that the combination of quantization and memory placement has a major influence on selective offloading performance.

It also changed how I think about fine-grained MoE architectures.

Originally, I suspected that models with 256 routed experts might be particularly problematic for CPU offloading.

These results suggest it's not nearly that simple.

A 256-expert model can perform quite well with selective offloading, depending on the configuration.

LFM: The biggest surprise needed another look

If you read my first article, you might remember LFM2.5.

That was the model that managed a rather miserable 2.11 tokens/sec with selective offloading at Q8_0.

Traditional splitting achieved 9.03 tok/s.

More than four times faster.

It was such a dramatic difference that several people commented on it.

Mudassir suggested that the heavier 8-bit expert weights might be putting too much pressure on CPU memory bandwidth.

I suspected something similar, but didn't have the evidence to separate that from the architecture itself.

Well, switching to Q4_K_M produced a massive improvement.

The initial 100-token run reached 35.44 tok/s with selective MoE offloading.

That's approximately 16.8 times the original result.

Traditional splitting also improved considerably, reaching 32.96 tok/s.

But there was a problem.

One of the selective runs dropped all the way to 11.23 tok/s, while the other two were above 35 tok/s.

That's a pretty ridiculous amount of variation.

So I repeated the experiment using longer 512-token generations.

This time, the results looked quite different:

Strategy	Median Generation
Traditional Split	21.72 tok/s
Selective MoE	21.88 tok/s

Essentially a tie.

The weird 11.23 tok/s dip didn't reappear in those longer runs, but both configurations were considerably slower than their original 100-token medians.

That raises questions about workload length, sustained performance, and what might be changing during generation.

What I can say is that LFM clearly isn't inherently terrible at selective expert offloading.

Under the new Q4_K_M configuration, it performed reasonably well.

But whether the improvement came primarily from quantization, different layer placement, changes in llama.cpp, or a combination of all three still needs more investigation.

And the longer test also reminded me of something important.

A configuration that looks faster over 100 tokens might not have the same advantage over 512.

That's something I'll definitely keep in mind when benchmarking models in the future.

Then I tried speculative decoding with Gemma 4

Because apparently five models and two offloading strategies weren't enough to keep me entertained.

I also wanted to see whether Multi-Token Prediction (MTP) speculative decoding could improve performance when using selective MoE offloading.

Gemma 4 26B-A4B has a separate MTP drafter that can propose multiple tokens for the main model to verify.

The idea is that generating and verifying several tokens together can sometimes be faster than generating them individually.

In theory, that sounded promising.

In practice, my results were not particularly encouraging.

Without MTP, selective offloading reached:

13.58 tokens/sec

With the MTP drafter enabled:

7.24 tokens/sec

So instead of speeding things up, it reduced throughput by approximately 46.7%.

I wanted to understand why.

During a longer 512-token test, I captured the drafter telemetry:

draft acceptance = 0.11678103 accepted / 882 generatedmean len = 1.35

Only 11.68% of the proposed draft tokens were accepted.

That's a pretty awful acceptance rate.

The longer MTP run also measured just 6.03 tok/s.

Speculative decoding has overhead. If the drafter isn't making predictions that the target model can accept often enough, the extra work can outweigh whatever speedup you hoped to achieve.

The low acceptance rate gives me a much more concrete reason to investigate the slowdown than simply assuming CPU/GPU synchronization was responsible.

I still want to check whether the drafter configuration or some other compatibility issue contributed to the poor acceptance rate.

So I wouldn't conclude from this that speculative decoding and CPU offloading are fundamentally incompatible.

Just that this particular configuration definitely didn't help.

Something else the repeat testing revealed: Noise

One of Riccardo's main suggestions was to account for measurement variation.

And after seeing these results, I'm glad I did.

For example, the three Apex selective offloading runs were:

9.21 tok/s9.70 tok/s25.50 tok/s

That last run was affected by early end-of-sequence generation, making it a poor comparison with the other runs.

LFM also produced that unusually slow 11.23 tok/s result.

And Gemma's traditional offloading runs varied from 8.98 to 16.85 tok/s.

Those are not small differences.

Interleaving the configurations helped make the testing process fairer, but it didn't magically remove every source of variation.

Using medians helped reduce the influence of individual outliers, although three measurements still aren't enough to establish a particularly reliable performance distribution.

The longer tests were especially useful because they showed that some of the apparent advantages became much smaller when the workload changed.

Going forward, I think longer generations and more repeated measurements are going to be standard practice for my experiments.

It's a little more work, but clearly worth it.

So what did I actually learn?

I went into the original experiment wanting to find out whether selective MoE offloading was a better way to run large models on a GPU with limited VRAM.

My first conclusion was that it depended on the model.

That still seems true, but now I'd add quite a bit more to it.

Quantization can change the outcome.

Qwen went from traditional splitting performing slightly better at Q6_K to selective offloading gaining a substantial advantage at Q4_K_M.

Offloading configuration matters.

Two configurations using the same model can place very different amounts of work on the CPU and GPU. The amount of VRAM occupied doesn't tell the whole story.

Short benchmarks can be misleading.

LFM's apparent 7.5% selective advantage in the 100-token tests practically disappeared over the longer generations.

Speculative decoding isn't a free speed boost.

Gemma's MTP drafter had a very low acceptance rate and made generation considerably slower under my tested setup.

And perhaps most importantly, a measurement and an explanation aren't the same thing.

I can measure that something runs faster or slower.

Explaining exactly why sometimes requires considerably more testing.

That distinction is becoming more obvious the deeper I get into this.

What's next?

I'm not quite finished experimenting.

I'd still like to test more quantization levels on the exact same checkpoint, ideally with more carefully controlled offloading configurations.

I'm also interested in monitoring actual CPU memory bandwidth and GPU behavior during inference.

That might help answer some of the questions about where these slowdowns are coming from instead of relying on educated guesses.

And eventually, I still want to repeat some of these tests on a machine with 64GB of RAM.

I'm especially curious how much more flexibility that provides for keeping expert weights in system memory without running into swap pressure.

But for now, I think I've learned quite a bit from these two rounds of testing.

Final thoughts

One of my favorite things about sharing experiments publicly is that sometimes people notice things you missed.

I thought my original results were interesting, and I still do.

But several people asked good questions about the methodology, the quantization differences, and whether the measurements were reliable enough to support some of my conclusions.

They were right to ask.

And when I went back and tested those things, some of my conclusions changed.

I'm glad they did.

I'd much rather discover that my original explanation wasn't quite right than keep repeating it because it sounded reasonable.

That's half the fun of experimenting with this stuff.

You start with one question, find an interesting result, and suddenly you're investigating three completely different things you hadn't even considered.

And occasionally you realize you've spent an entire weekend benchmarking language models instead of doing literally anything else.

You know, perfectly normal behavior.

A big thank you to everyone who took the time to read the original article and offer thoughtful feedback. It genuinely helped make this second round of experiments better.

And if anyone has suggestions for what I should test next, particularly around quantization, CPU memory bandwidth, or speculative decoding, I'd love to hear them.

Apparently I haven't spent enough time staring at tokens-per-second measurements yet.

MoE Offloading Isn’t Always Faster: I Tested 5 Models on a 16GB GPU

Jessica Doering — Fri, 30 Oct 2026 14:04:55 +0000

I do a lot of experimenting with local language models, and I just ended up going down a bit of a rabbit hole.

It started when I came across an article about running larger Mixture-of-Experts (MoE) models on GPUs that don't have enough VRAM to hold the entire model.

The idea was pretty simple. Instead of offloading entire model layers to system RAM, you could selectively offload just the MoE experts and leave the rest of the work on the GPU.

I thought that sounded interesting. And since I have a laptop with 16GB of VRAM and 32GB of RAM, I figured I'd give it a try.

Well, one model turned into another, which turned into another, and before I knew it, I was benchmarking five different models, comparing offloading strategies, and trying to figure out why some configurations worked so much better than others.

You know, a perfectly normal way to spend a day.

And I learned quite a bit along the way.

First, what exactly is MoE offloading?

If you've experimented with running local LLMs, you're probably familiar with the problem of trying to load a model that's too large for your GPU.

You can use CPU offloading to make it fit, but there's usually a pretty significant performance penalty.

Traditional layer offloading moves entire transformer layers between the GPU and CPU. That means parts of the model that could benefit from GPU acceleration end up running on the CPU instead.

MoE models give us another option.

Unlike dense models, where essentially all the model's parameters participate in processing each token, MoE models have multiple experts, and only a subset is activated for each token.

For example, Microsoft's Phi-3.5-MoE has around 42 billion total parameters, but only about 6.6 billion are active per token.

That doesn't mean the other parameters disappear. They still need to be stored somewhere.

But since only certain experts are needed for each token, we can potentially keep some of those expert weights in system RAM while leaving attention and other parts of the model on the GPU.

In llama.cpp, this is possible using:

--n-cpu-moe N

Where N specifies how many initial layers will have their MoE expert weights kept on the CPU.

In theory, this should let you run larger models without sacrificing quite as much performance as traditional layer offloading.

But I wanted to see how well it actually worked.

My test setup

All of these experiments were done on my Acer Predator laptop running CachyOS (Arch Linux).

Here's the hardware:

GPU: NVIDIA RTX 4090 Laptop GPU, 16GB VRAM
CPU: Intel Core i9-14900HX, 24 cores / 32 threads
RAM: 32GB DDR5
Inference engine: llama.cpp with CUDA support
Flash Attention: Enabled

I used GGUF models and ran everything through llama-server.

I started with Phi-3.5-MoE because it seemed like a good candidate for testing this technique. From there, I added several other MoE models with different architectures and quantization levels.

For the initial comparisons, I used a 4,096-token context window, a warm-up request, and the same short benchmark prompt.

This wasn't intended to be some exhaustive scientific benchmark. I wanted to see what actually happened on my hardware and whether the differences were significant enough to investigate further.

The models I tested

I ended up testing five models:

Model	Quantization	GGUF size
Phi-3.5-MoE (42B)	Q4_K_M	24GB
Apex-35B V1.0	Q5_K_M	24GB
Qwen3.5-35B-A3B	Q6_K	27GB
Gemma 4 26B A4B	Q8_0	26GB
LFM2.5-24B-A2B	Q8_0	24GB

All of them were larger than my available GPU memory.

That was the whole point of the experiment.

I wanted to compare two approaches:

Traditional layer offloading: Move complete layers to the CPU until the model fits within available VRAM.
Selective MoE offloading: Keep GPU-eligible non-expert operations on the GPU while moving selected expert weights and their computation to the CPU.

I adjusted the settings for each model to fit within my memory limits.

And this is where things started getting interesting.

The results were definitely not what I expected

Here's a comparison of the generation speeds I measured:

Model	Selective MoE	Traditional offloading
Phi-3.5-MoE	5.67 tok/s	4.03 tok/s
Apex-35B	5.18 tok/s	3.69 tok/s
Qwen3.5-35B	4.37 tok/s	5.23 tok/s
Gemma 4 26B	4.40 tok/s	5.77 tok/s
LFM2.5-24B	2.11 tok/s	9.03 tok/s

I originally expected selective MoE offloading to be the better option across the board.

That was definitely not the case.

On Phi-3.5-MoE and Apex-35B, selective offloading improved generation speed by around 40%.

But on Qwen, Gemma, and especially LFM, traditional layer offloading was faster.

And not just by a little.

LFM was more than four times faster with traditional offloading.

That one really caught my attention.

More GPU usage doesn't always mean better performance

One of my favorite discoveries came from testing Phi-3.5-MoE.

I started experimenting with how many expert layers I should keep on the CPU.

At one point, I had nearly all 16GB of VRAM occupied.

Here's what happened:

CPU expert layers	VRAM used	Generation
13	15,945 MiB	5.29 tok/s
16	13,833 MiB	4.66 tok/s
20	11,015 MiB	5.67 tok/s

The fastest result came from offloading more experts to the CPU.

I actually got better generation speed while using significantly less VRAM.

Now, I don't want to claim that leaving more VRAM free automatically makes inference faster. There are plenty of things that could affect these results, including CPU/GPU scheduling, memory bandwidth, caching, and normal variations between runs.

But it was still interesting to see that the configuration using the most GPU memory wasn't necessarily the fastest.

Sometimes the best configuration isn't the one that pushes your GPU to its absolute limit.

Quantization might matter more than I realized

Another thing I noticed was how differently models behaved at different quantization levels.

For example, Qwen3.5-35B at Q6_K performed better with traditional offloading.

But Apex-35B, which uses a related Qwen3.5 MoE architecture and was quantized to Q5_K_M, performed better with selective MoE offloading.

That made me wonder whether the additional CPU memory bandwidth needed for higher-precision expert weights was affecting performance.

It would make sense. When experts are running on the CPU, the amount of data being read from system RAM can become a significant bottleneck.

But I haven't proven that's the reason yet.

These are different model checkpoints, and there may be architectural or implementation differences affecting the results too.

I'd like to test the exact same model at Q4, Q5, and Q6 using both offloading methods. That would be a much better way to isolate the effect of quantization.

For now, it's an interesting observation rather than a conclusion.

Then there was LFM...

I really wasn't expecting this result.

LFM2.5-24B-A2B has around 24 billion total parameters, with approximately 2 billion active per token.

You might think that relatively low active parameter count would make it an especially good candidate for selective expert offloading.

Nope.

With selective offloading, I got:

2.11 tokens/sec

With traditional layer splitting:

9.03 tokens/sec

That's a huge difference.

My suspicion is that the Q8_0 expert weights, CPU memory bandwidth, and repeated synchronization between CPU and GPU may be playing a role.

But again, I would need more detailed profiling to know exactly what's happening.

What this really showed me is that the number of active parameters alone doesn't tell you how efficiently a model will run on your hardware.

The architecture, quantization, and inference implementation all matter.

And sometimes the approach that sounds better on paper performs much worse in practice.

I also experimented with context length

After finding a configuration I liked for Phi-3.5-MoE, I wanted to see what would happen when I increased the context window.

Using Flash Attention, I tested 4K, 8K, and 16K context settings.

Context setting	VRAM used	Generation
4K	11,015 MiB	5.67 tok/s
8K	11,531 MiB	5.56 tok/s
16K	12,563 MiB	5.85 tok/s

The memory increase was much more manageable than I expected.

I also tried the same thing with Apex-35B, where the measured VRAM increase from 4K to 16K was only around 252 MiB.

It's worth mentioning that these tests changed the configured context capacity. They weren't benchmarks of processing prompts that actually contained 16,000 tokens.

That distinction matters, because processing a genuinely long prompt is a different workload.

Still, it was encouraging to see how much room I had for larger context settings without immediately running out of VRAM.

What about putting all the experts on the CPU?

I tried that too.

With Phi-3.5-MoE, I used:

--cpu-moe

And, well, that didn't go particularly well.

The model loaded, but system memory pressure increased enough to cause heavy swapping.

Generation dropped to around 3.14 tokens/sec, and I was seeing approximately 90MB/s of swap activity.

At that point, my 32GB of RAM was clearly becoming a limitation.

This doesn't mean full CPU expert offloading is always a bad idea. With more RAM, a different model, or a different quantization, it might be perfectly reasonable.

But for this particular model and my laptop, selectively offloading only some of the experts worked much better.

So, is selective MoE offloading worth using?

I think the answer is yes, but not necessarily for every model.

That's probably my biggest takeaway from all of this.

When I started, I was mostly interested in seeing whether I could run models that were too large for my GPU.

And I can.

But what I ended up learning was that getting a model to fit in memory is only half the problem.

How you distribute its workload between the CPU and GPU can make a surprisingly big difference.

For Phi-3.5-MoE and Apex-35B, selective offloading gave me better performance.

For other models, especially LFM2.5, the traditional approach was considerably faster.

I don't think there's a single offloading configuration that's going to work best for every MoE model.

At least, that's certainly not what my experiments have shown so far.

A few things I still want to test

I'm not quite finished with this rabbit hole yet.

I'd like to repeat the benchmarks with longer outputs and multiple runs per configuration, rather than relying on one short warm benchmark.

I also want to compare different quantizations of the same model to better understand how much precision affects CPU-side expert performance.

And eventually, I'd love to repeat some of these experiments on a machine with 64GB of RAM to see how much difference the extra memory makes.

There's also the question of actual usability. Tokens per second is useful, but I'd like to compare how responsive these configurations feel during longer conversations and more complicated tasks.

For anyone interested in trying this themselves, here's a basic example using llama.cpp:

llama-server \
  -m /path/to/model.gguf \
  -ngl all \
  --n-cpu-moe 20 \
  -c 8192 \
  -fa on

The 20 is just an example, not a magic number. You'll need to adjust it for your model and hardware, and compare it against traditional layer offloading.

Also, keep an eye on system RAM and swap usage. Just because a model starts successfully doesn't mean it's going to run comfortably.

Final thoughts

I went into this experiment thinking I'd learn a neat trick for running bigger models on my laptop.

Instead, I ended up learning quite a bit about how different MoE architectures behave, how quantization can affect performance, and why CPU/GPU memory placement isn't nearly as straightforward as I originally thought.

And I still have plenty of questions.

That's one of the things I enjoy most about experimenting with local LLMs. You can read all the explanations and documentation you want, but sometimes you don't really understand what's happening until you start testing things yourself.

Even better when the results make you question what you thought you understood in the first place.

If you've experimented with MoE offloading, I'd love to hear what kind of results you've seen, especially on GPUs with limited VRAM.

I'm curious whether anyone else has run into such dramatic differences between architectures.

Is Tech Actually Welcoming to Beginners, or Do We Just Say It Is?

Jessica Doering — Thu, 29 Oct 2026 16:58:14 +0000

We hear it all the time in tech.

Everyone starts somewhere. There are no stupid questions. Don't be afraid to ask for help. Keep learning.

And I agree with all of that.

But I've been wondering lately, are we actually as welcoming to beginners as we like to think we are?

Because telling someone they're welcome is one thing. Making them feel comfortable enough to actually participate is another.

The fear of asking a stupid question

When I first started learning to code, I was pretty nervous about asking questions.

I wasn't necessarily worried that someone would be outright mean to me. I was more worried about looking like I had absolutely no idea what I was doing.

Which, to be fair, half the time I didn't. That's kind of the point of learning something new, right?

But that didn't stop me from overthinking things.

What if this is something I should already know? What if the answer is ridiculously obvious? What if someone wonders why I'm even trying to build things when I don't understand something so basic?

I can't imagine I'm the only person who's ever felt that way.

And apparently, I'm not.

I was looking through the 2026 Stack Overflow Developer Survey, and a couple of numbers caught my attention.

21.1% of respondents said they worry about being judged or criticized when participating in technical or professional communities.

Another 20.1% said they don't feel confident asking questions publicly.

Now, these numbers aren't specifically about beginners. They're from respondents more broadly, and I don't want to misrepresent that.

But still, roughly one in five people answering that question are worried about what others might think of them.

That's a pretty significant number of people who might have something to ask, share, or contribute but hesitate to do it.

It makes me wonder how many people are reading discussions, learning from everyone else, and never saying a word because they're afraid they'll look stupid.

You can correct someone without making them feel stupid

I want to be clear about something. I'm not suggesting we should stop correcting people or pretend everything everyone does is amazing.

That wouldn't help anybody learn.

I've made plenty of mistakes, written some questionable code, and probably approached things in ways that would make a more experienced developer scratch their head.

And I'm sure I'll continue doing all three.

But there's a difference between someone explaining why your approach might not be the best and someone making you feel stupid for trying it in the first place.

You can point someone toward documentation without the whole "Did you even bother reading the docs?" attitude.

You can disagree with someone without turning it into a contest over who knows more.

And you can give someone honest feedback without making them regret asking for it.

I think sometimes people forget how intimidating tech can be when you're new.

Things that seem completely obvious to someone who's been programming for ten years might be something a beginner has spent the last three hours trying to figure out.

And sure, maybe the answer really was in the documentation the whole time.

We've all been there.

But nobody learns everything overnight, and making someone feel stupid isn't going to help them learn any faster.

What about women in tech?

This is another part of the conversation I'm interested in.

I'm a woman who builds things and is still learning all the time, and I can genuinely say that a lot of my experiences in the tech community have been really positive.

Especially here on DEV.

I've met some wonderful people, received helpful feedback, and had other developers encourage me to keep building and sharing my projects.

And I appreciate that more than I probably say.

But getting comfortable enough to put my work out there in the first place? That took some courage.

I'm naturally someone who second-guesses herself, and when I first started sharing my projects, I was constantly wondering what people would think.

Was my code good enough? Was what I built even worth sharing? Would more experienced developers look at it and wonder why I was so excited about something they could probably throw together in an afternoon?

Looking back, I probably worried about those things a lot more than I needed to.

But here's where I get curious.

How much of that hesitation comes from being a beginner? How much comes from personality? And for women, is there sometimes another layer to it?

I can't honestly say I've experienced some terrible amount of sexism in tech, because I haven't. At least not in the communities I've been participating in.

But I also know that my experience doesn't represent every woman's experience.

I'm curious whether other women have felt like they needed to prove they knew what they were talking about before anyone would take them seriously.

Or whether they've noticed people making assumptions about their abilities.

And I'm just as interested in hearing from women who've had really positive experiences.

I don't think this is a conversation where we should assume everyone has had the same experience, because obviously we haven't.

That's what makes it worth discussing.

Finding your people makes a difference

Something I've learned since I started sharing my work is just how much the right community can change things.

There are places on the internet where asking a basic question feels like you're volunteering to be publicly roasted.

And then there are places where people are genuinely excited to see what you're working on, even when it's something small.

I've been lucky enough to find more of the second kind.

When I first started posting on DEV, I was nervous.

Now I'm sharing projects, writing articles, participating in discussions, and occasionally posting something before I've had enough time to talk myself out of it.

Progress!

And it's not because I've suddenly become some expert who knows everything.

Trust me, I definitely haven't.

I look things up constantly. I make mistakes. I run into problems that leave me staring at my screen wondering what I did wrong.

But I've learned that I don't need to know everything to have something worth contributing.

Sometimes you share something you've built and someone teaches you a better way to do it.

Sometimes someone else is working through the exact same problem you just figured out.

And sometimes a little project you're proud of inspires another person to try building something of their own.

That's the kind of interaction that makes people want to participate.

We have to do more than say beginners are welcome

I don't think tech is some universally hostile place where everyone is waiting to tear beginners apart.

There are so many genuinely kind, helpful people out there, and I've met quite a few of them.

But I also think there's room for improvement.

We can tell beginners to ask questions all day long, but if the response they get makes them wish they'd kept quiet, what good does that do?

We can encourage people to share their projects, but if we immediately dismiss anything that isn't particularly advanced, we're not exactly giving them a reason to share the next one.

And I think it's worth remembering that something simple to you might be a huge accomplishment to someone else.

Maybe it's their first working app.

Maybe it's the first bug they managed to track down on their own.

Maybe they finally understand something that's been confusing them for weeks.

That excitement is real, even if the accomplishment seems small from where you're standing.

I still get excited when I figure something out that I probably should have understood ages ago. And I'm not planning to stop anytime soon.

I think most of us can remember what it felt like when we were first learning something completely unfamiliar.

We just need to remember that feeling when we're the ones with a little more experience.

Because a welcoming community isn't really defined by what it says about beginners.

It's defined by how it treats them when they actually show up.

I'm curious what everyone else thinks

I'd really love to hear about your experiences, especially if they've been different from mine.

When you were first learning, did you feel comfortable asking questions or sharing your work?
Have you ever avoided participating in a community because you were afraid of being judged?
For women in tech, do you feel your experience has been any different, good or bad?
Are there particular communities that made you feel genuinely welcome?

I know my experience is only one perspective, and I think hearing from people who've had both positive and negative experiences could make for a really interesting discussion.

After all, if we want tech communities to be welcoming, it probably helps to listen to the people we're trying to welcome.

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!