DEV Community: Jessica Doering

Claude Code Skills Worth Trying: From Vague Idea to Finished Feature

Jessica Doering — Mon, 14 Sep 2026 22:36:57 +0000

I’ve tried out a lot of Claude Code skills, and a few of them are especially useful when you combine them into a workflow.

Not because they magically make the model better at coding, but because they help with the annoying parts around coding: figuring out what you actually want, avoiding unnecessary complexity, keeping a design consistent, and remembering where you left off.

So instead of just listing the skills, I wanted to put together a practical example.

Imagine we’re adding AI-generated collections to a bookmark manager. The user pastes a link, the app figures out where it belongs, and maybe creates a collection if there isn’t a good one already.

Simple idea. Plenty of decisions hiding underneath it.

We’ll use a few skills to work through those decisions, build the feature, and make it easier to come back to later.

You’ll need Claude Code and the skills you want to use installed. Each repository has its own installation instructions, so follow those rather than assuming they all use the same setup.

The skills covered here are:

Matt Pocock’s skills for grilling, domain modeling, and handoffs.
Ponytail for keeping implementations simple.
UI/UX Pro Max for design guidance and a persistent design system.
Hallmark for more distinctive interface structure.
i-have-adhd for making the current task and next action easier to follow.
Caveman for more concise working conversations.

You don’t need all of them. The point is to give each one a specific job.

1. Figure out what you actually want with `grill-me`

The first thing I’d do is not ask Claude to implement the feature.

“Add AI-generated collections” sounds specific enough until you start thinking about what should happen when the AI isn’t sure, when a collection already exists, or when the user has manually organized something.

That’s where grill-me comes in.

It uses the underlying grilling skill to turn the discussion into a decision tree. Instead of asking a giant list of unrelated questions, it asks the questions that can be answered now, then uses those answers to determine what needs to be asked next.

Start with something like:

/grill-me

I want to add AI-generated collections to my bookmark manager.

The user should be able to paste a URL and have the app suggest
or choose an appropriate collection.

Help me work out the behavior before we implement anything.
Inspect the existing codebase for facts you can determine yourself.
Ask me about product decisions, not things you can find in the code.

The important part is that Claude should inspect the project rather than making you explain every existing function.

It might discover that collections already have a creation function, that bookmarks can belong to multiple collections, or that there’s an existing metadata-fetching pipeline.

Those are facts about the codebase.

The questions for you are things like:

Should the AI apply suggestions automatically or ask first?
Should it prefer existing collections?
Is it allowed to create new collections?
Should it ever reorganize bookmarks the user already sorted?

Those are product decisions.

Let the questions happen in rounds

Suppose you decide that the AI should prefer existing collections and only create a new one when there isn’t a reasonable match.

Now there’s a new question: what counts as a reasonable match?

Maybe you want a confidence threshold. Maybe you’d rather have the AI suggest a new collection and let you approve it. Maybe the user should be able to turn automatic creation off entirely.

The grilling workflow is useful because those questions depend on the earlier decision. There’s no reason to spend ten minutes discussing deletion behavior for automatically created collections before deciding whether automatic creation is even allowed.

Keep going until the important branches are resolved.

For a tiny utility, this may be more process than you need. For a feature with several possible behaviors, it can save a lot of “well, that’s not what I meant” halfway through implementation.

2. Preserve the important decisions with `grill-with-docs`

If the feature is going to be more than a quick experiment, I’d use grill-with-docs instead of a plain grilling session.

This combines the structured interview with domain-modeling, so the important terminology and decisions don’t just disappear into chat history.

For example:

/grill-with-docs

Help me define the AI collection feature for this bookmark manager.

Inspect the existing code and documentation first.
Clarify the important domain concepts and behavior.
Keep the documentation focused on decisions and terminology
that will matter when I return to this project later.

One thing I like about the domain-modeling approach is that it challenges vague terminology.

For example, what does “collection” actually mean in this app?

Is it a folder for bookmarks? A tag-like grouping? Can a bookmark belong to more than one? Is an AI-generated collection different from a manually created one, or is the only difference how it was created?

Those distinctions matter because they affect the data model and the behavior.

The skill can maintain a CONTEXT.md glossary for domain terminology. That file is meant to explain what things mean, not become a giant implementation spec.

It can also create ADRs, or architecture decision records, for decisions that are genuinely worth preserving.

For example, if you decide:

AI suggestions never modify manually organized bookmarks without approval.

That might be worth documenting if it affects several parts of the system and would be surprising to someone reading the code later.

The distinction is useful:

Glossary: What does “collection” mean?

ADR: Why did we decide AI should not reorganize manually sorted bookmarks automatically?

Not every little choice needs an ADR. The idea is to preserve the reasoning that would otherwise be easy to lose.

3. Ask Ponytail to find the smallest implementation

Now that the behavior is clearer, it’s tempting to tell Claude to build the whole thing.

Before doing that, I’d bring in Ponytail.

Its general philosophy is to think like the laziest competent senior developer.

Not lazy as in “do a shitty job.” Lazy as in:

Why are we creating six abstractions and a new service when the project already has most of what we need?

Ask it to review the plan first:

Use Ponytail to review the implementation plan for this feature.

Look for existing code, platform features, or dependencies we can reuse.
Identify unnecessary abstractions or infrastructure.
Recommend the smallest implementation that satisfies the requirements.

Do not simplify away validation, security, error handling, or
the behavior we agreed on.

For our bookmark manager, maybe the app already has:

A URL metadata fetcher.
A collection creation function.
A bookmark-to-collection relationship.
An existing AI provider abstraction.

If so, we probably don’t need a separate “AI Collection Orchestration Service” with its own plugin architecture and twelve interfaces.

Maybe we just need to add a classification step to the existing save flow.

That’s the kind of simplification I want.

Use the review skills after implementation

Ponytail also includes related skills such as ponytail-review, ponytail-audit, and ponytail-debt.

After implementing the feature, I’d use the review to look for unnecessary complexity in the diff:

Use ponytail-review on the changes for the AI collection feature.

Look for unnecessary abstractions, duplicated logic, and code
that could be replaced with existing project functionality.

Preserve the agreed behavior and correctness requirements.

The debt skill is interesting for deliberate shortcuts.

Maybe we decide that a simple classification call is enough for now, but we know we might need a more sophisticated system if the library grows to tens of thousands of bookmarks.

That doesn’t mean we need to build the sophisticated system today. It means we can record why the simple approach was chosen and what would make us revisit it.

4. Establish the design direction with UI/UX Pro Max

Once the behavior is settled, I’d work on the interface.

UI/UX Pro Max gives Claude a searchable design knowledge base covering styles, palettes, typography, UX guidance, chart choices, and stack-specific implementation recommendations.

For our example, I’d ask it to establish the design direction before touching the UI:

Use ui-ux-pro-max to establish a design direction for
the AI collection feature in this bookmark manager.

The app uses React and Tailwind and supports dark mode.

I want the feature to feel like a natural part of the existing app,
not a separate AI dashboard.

Recommend the interaction pattern, typography, colors, spacing,
and component guidance. Do not implement anything yet.

The part I find especially useful is the ability to persist a design system.

UI/UX Pro Max can generate a project-level MASTER.md containing the overall design direction, with page-specific overrides where needed.

That gives Claude something to refer back to instead of reinventing the visual style every time you work on another page.

For example, the bookmark manager’s main page, settings page, and collection editor should all feel like the same product.

The goal is to avoid the classic AI frontend situation where one page looks great and the next looks like it came from a completely different app.

5. Use Hallmark for the page structure

This is where I’d bring in Hallmark.

Hallmark focuses on structural variety, not just changing colors and fonts. Its goal is to avoid the same generic AI-generated page composition being reused for everything.

It has workflows for building, auditing, redesigning, and studying designs.

For our bookmark manager, I’d give it a different job from UI/UX Pro Max:

Use Hallmark to design the AI collection interaction using
the design direction we just established.

Keep the agreed palette and typography.

Focus on a clear, distinctive layout and interaction flow
that fits the existing bookmark manager.

Do not replace the design system with a different theme.
Do not redesign unrelated parts of the app.

UI/UX Pro Max establishes the practical design foundation.

Hallmark works on the actual composition and structure.

We don't want both skills independently deciding what the app should look like and fighting over the design system.

Use `study` when you have a reference

Hallmark’s study mode is also interesting if you have a screenshot or URL of an interface you like.

You can ask it to analyze the design “DNA”: the layout structure, typography, color direction, and visual hierarchy.

For example:

Use Hallmark study mode on this screenshot.

Explain the layout structure, spacing, typography, and visual hierarchy
that make it work.

I want to use those principles for my bookmark manager,
not copy the original design.

That is a useful way to learn from a reference without just asking Claude to recreate it.

Hallmark also has a component-specific workflow, so you can ask it to improve a modal or button without turning the request into a full-page redesign.

6. Keep the working conversation manageable

At this point, the feature is being implemented, and this is where a couple of smaller skills could make the day-to-day experience nicer.

Use `i-have-adhd` to keep the next action obvious

i-have-adhd is an output-style skill that changes how Claude presents work.

It tries to lead with the next action, break multi-step work into smaller tasks, keep the current state visible, and suppress unrelated tangents.

For example:

/i-have-adhd

Help me finish this feature.

Show the current task, what is already complete, and the
single next action. Keep unrelated ideas in a later section.

Instead of getting a giant explanation about everything that could possibly happen next, you get something closer to:

Step 3 of 5 complete: Collection classification is implemented. Next: test what happens when the AI returns an invalid collection ID. Dependency cleanup can wait.

That’s the kind of thing I find useful when I’m bouncing between projects and need to know what to do right now.

It still allows fuller explanations when you ask for them, so it isn’t supposed to make every answer tiny at the expense of being useful.

Use Caveman when Claude gets too wordy

Caveman is for a slightly different problem: reducing unnecessary prose.

Its basic skill compresses Claude’s explanations while preserving important technical details like code, commands, error messages, exact names, numbers, and words that change the meaning of instructions.

For example:

Use Caveman lite for this implementation session.

Keep explanations concise, but preserve exact commands,
error messages, and important technical details.

So instead of an essay explaining a small React issue, you might get:

New object ref each render. Prop identity changes. Memoize stable value.

The project has different modes, including lite, full, and ultra, and can switch back to clearer prose when something is ambiguous, safety-critical, or needs a proper explanation.

It also has related skills for concise commits, reviews, memory-file compression, and token statistics.

One thing worth keeping in mind: fewer output tokens doesn’t automatically mean the same percentage reduction in total session cost. The instructions have overhead, and input and reasoning tokens still count.

The basic concise-output skill is also separate from the repo’s larger optional proxy/engine and Cloud-related tooling. I’d distinguish those before installing the whole stack.

7. Create a handoff before ending the session

Now imagine the feature is mostly done, but the integration tests are failing and you’re done for the day.

This is where Matt Pocock’s handoff skill comes in.

It creates a Markdown handoff document in the OS temporary directory so another session or agent can pick up the important context.

I’d use something like:

/handoff

The AI collection feature is mostly implemented.

Preserve:
- The current task and completed work.
- The decisions we made about collection behavior.
- The data model and why we chose it.
- The failing integration tests.
- The single next action.

Reference existing plans, specs, ADRs, or commits where useful
instead of copying everything into the handoff.

The idea is to preserve the important state without dumping the entire chat into the next session.

It’s context portability, not magic context-window compression.

A handoff can still lose details, so if the reasoning behind a rejected approach matters, I’d explicitly ask it to preserve that. I’d also check the file before sharing it elsewhere if the conversation contained anything sensitive.

8. Resume with `handoff` + `i-have-adhd`

handoff preserves the important context.

i-have-adhd makes that context easier to act on when you come back.

In the next session, I’d point Claude at the generated handoff file and say:

/i-have-adhd

Read the handoff file and help me resume.

Show the current state, then give me the first concrete action.
Keep unrelated ideas in a later section.

That should make it easier to reopen a project and avoid spending the first part of the session reconstructing what happened yesterday.

For someone who has several projects going at once, that sounds pretty damn useful.

The workflow, all together

Here’s the order I’d try:

Stage	Skill	Job
Clarify the idea	`grill-me`	Work out the behavior before coding.
Preserve decisions	`grill-with-docs`	Document terminology and important trade-offs.
Simplify the plan	Ponytail	Find the smallest implementation that satisfies the requirements.
Establish design	UI/UX Pro Max	Create a consistent visual and UX foundation.
Design the interface	Hallmark	Improve structure and composition without replacing the design system.
Implement	`i-have-adhd` / Caveman	Keep the current task clear and the conversation manageable.
Review	`ponytail-review`	Look for unnecessary complexity in the changes.
End the session	`handoff`	Preserve the important context for next time.
Resume	`handoff` + `i-have-adhd`	Reconstruct the state and identify the next action.

You don’t have to use every stage every time.

If I’m making a tiny utility, I might just use Ponytail and a concise output style.

If I’m building a feature with complicated behavior, I’d spend more time grilling and documenting the decisions.

If I’m working on a frontend, I’d use the design skills, but I wouldn’t ask both of them to independently invent the entire visual direction.

The useful part is giving each skill a clear responsibility.

A few things to keep in mind

Avoid treating the workflow as a mandatory process. The whole point is to make building things easier, not turn a small feature into a ceremony involving six agents and a stack of documents.

The combination: grilling → documentation → simple implementation → handoff.

The result is that you're getting from “I have an idea” to “I know what I’m building,” without losing the decisions or accidentally turning a small project into a giant architecture exercise.

When Do You Decide a Project Is Done?

Jessica Doering — Sun, 13 Sep 2026 20:28:24 +0000

I make A LOT of things.

Some turn into bigger projects than I expected. Some are experiments. Some are tiny utilities I made because I wanted one very specific thing and didn't feel like using whatever already existed.

And lately I've been thinking about when a project is actually done.

Not abandoned. Not sitting in a folder waiting for the mythical day when I suddenly decide to work on it again.

Just... done.

Not everything needs a roadmap

There's this weird tendency in software development where the second you build something, your brain starts trying to turn it into more.

Okay, it works. Cool.

But what if it had accounts?

What if it synced across devices?

What if there was an API?

What if I turned it into a SaaS?

What if I added seventeen things I never actually wanted in the first place?

Sometimes that makes sense. Plenty of good projects start small and grow because you realize there's a lot more you want to do with them.

But sometimes I wanted a tool that does one thing, and now I have a tool that does that thing.

Mission accomplished.

I don't think every project needs twelve integrations, a pricing page, and a five-year roadmap just because technically it could have them.

Sometimes the point was just making it

A lot of my projects start with some version of:

"I wonder if I could make this."

That's honestly enough motivation for me most of the time.

Maybe I'm trying a new library. Maybe I want to figure out how something works. Maybe I need some tiny utility. Maybe I just had a dumb idea at 1 AM and now apparently we're doing this.

If I build it, learn whatever I wanted to learn, and end up with something that does what I wanted, I don't really see that as an unfinished project.

It means I got what I wanted out of it.

And I think that's especially important if you're somebody who likes starting new things.

Because otherwise every experiment slowly turns into another responsibility.

Now you've got an endless list of things you're supposed to maintain, improve, and maybe eventually monetize.

That's a great way to make a hobby feel like a job.

No thanks.

Some projects do grow

Sometimes I start with a small idea, and then I keep thinking of new features I want to add.

Sometimes people use something you made and suggest something great to add to it.

Sometimes you just really like the project and it's fun to keep messing with it.

Those are great too.

I love building bigger things when I actually want to.

I just don't think growth has to be the default measure of whether a project was worth making.

A tiny utility that saves me five clicks was worth making.

An experiment that taught me something was worth making.

A completely ridiculous app that exists mostly because it made me laugh was worth making.

It doesn't have to become a product or a business or my new personal brand to justify the time I spent making it.

Maybe "done" just means it did its job

I think I'm getting more comfortable with letting some projects just... exist.

If I find a bug, I'll probably fix it.

If six months from now I suddenly think of something I want to add, I can add it.

But sometimes I made the thing, and the thing works, and I like it.

That's enough for me.

And honestly, sometimes the best thing I can do with a project is leave it alone and go make something else.

Which is good, because I probably already have another idea.

How do you decide when one of your projects is actually done?

Do you have a graveyard full of unfinished projects?

I Found a Tiny Model on Hugging Face and Now I Save Half the Internet as Markdown

Jessica Doering — Wed, 09 Sep 2026 23:35:45 +0000

I found a small model on Hugging Face recently that looked interesting, so I decided to experiment with it. I converted it to ONNX, got it running in the browser with WebGPU, and somehow it turned into one of those little tools I keep using way more than I expected.

It’s called Pulpie, and basically it takes a webpage and pulls out the actual useful content as clean Markdown. I’ve been using it to save DEV posts I want to keep, tutorials I want to read later, and especially documentation pages that don’t have a nice copy-to-Markdown option.

The part I really like is that it doesn’t just dump the whole page into Markdown. The model is only about 210M parameters and is used to classify which parts of the page are actual content and which parts are navigation, sidebars, boilerplate, etc. Then the remaining HTML gets converted normally.

That means things like headings, code blocks, links, tables, and images stay intact.

Today I tried it on a huge Claude Code documentation page with a bunch of tables and code examples, and it handled the whole thing really well. I have also saved long DEV posts to read later with all of the images still included.

I made one version that runs locally in the browser through ONNX Runtime Web and WebGPU. The model is around 800 MB, which sounds chunky for a browser app, but it downloads once, which only took a couple of minutes for me, and then it's stored in browser cache. After that, it loads locally and extraction is almost instant on my machine.

If you want to try it out:

Pulpie

I also made a local FastAPI version if you'd rather run it as a local app instead of using the WebGPU browser version. That one can be downloaded from GitHub:

pinkpixel-dev / pulpie-ui

Pulpie Local UI

A fast web interface for extracting the main content from web pages and HTML into clean Markdown. Powered by the feyninc/pulpie-orange-small 210M EuroBERT encoder model.

Try It Online (No Installation)

You can try the in-browser WebGPU version with no local setup required:

Live Demo: pulpie.pinkpixel.dev
WebGPU Space Repository: huggingface.co/spaces/sizzlebop/pulpie-webgpu

Why Pulpie?

Most modern content extractors either use brittle heuristics (regular expressions and readability rules) or heavy generative models (decoders) that generate text token by token.

Pulpie takes a different path:

Single-pass encoder: Instead of generating text from scratch, it tokenizes the page into blocks and classifies every block as content or boilerplate in a single forward pass.
Fast and light: The recommended 210M model matches state-of-the-art extractors while running up to 20x faster. On an RTX 4090 GPU, extractions take around 15 to 40 milliseconds.
Clean Markdown with images: It keeps headlines…

View on GitHub

I think this is actually one of my favorite uses for a small specialized model so far. It isn’t generating Markdown or rewriting anything. It just answers a much simpler question:

Is this block part of the page I actually care about?

Once it answers that, regular deterministic tools can handle the rest.

No API calls, no cloud inference, and no giant model needed just to clean up a webpage.

This was just a fun little experiment that ended up working so much better than I expected, but since it's been so useful for me, I thought I'd share it.

I can't be the only one who wants to save everything on the internet!

Maybe AI Doesn't Need to Get Better Right Now

Jessica Doering — Sun, 06 Sep 2026 17:53:48 +0000

I don’t mean AI development should stop forever, or that today’s models are perfect. They absolutely aren’t. There’s still plenty to improve: reliability, hallucinations, efficiency, security, interpretability, memory, agent behavior, and a hundred other things.

But those improvements don’t necessarily require this constant race toward making AI dramatically more capable at everything.

At some point, I think we have to ask what exactly we’re racing toward.

We already have models that can write software, dig through huge amounts of information, generate images and video, research topics, use tools, tutor people, automate workflows, and handle some seriously complicated tasks.

But the question I keep asking is:

Do we really need AI to do everything for us?

We’re already struggling to keep up with how quickly this technology is moving. Companies are already figuring out which jobs can be automated and which parts of people’s work can be handed over to AI. Entry-level roles are changing. Entire industries are trying to work out which skills are still going to matter. Schools barely have time to decide how students should be using these tools before another generation of models shows up.

And there’s a physical cost to all of this too.

More capable AI usually means more demand for compute. More compute means more data centers, more electricity, more cooling, more water, and more land.

Those data centers aren’t floating around in some magical cloud. They’re built in actual communities, and the people living in those communities are the ones dealing with whatever comes with them.

That doesn’t mean data centers are automatically bad, or that AI shouldn’t exist. Obviously I don’t think that. It just means there’s more to this race than benchmark scores and flashy model launches.

And while all of that is happening, the attitude still seems to be:

Bigger. Smarter. Faster. More autonomous.

Why?

There’s another option.

We could spend some time getting really good at the AI we already have.

Make it cheaper. Make it more reliable. Make it easier to verify. Make it more energy-efficient. Build better tools around it. Figure out what reasonable rules around this stuff should actually look like. Help workers adapt. Learn where AI actually improves something and where we’re just shoving it in because we can.

I especially feel this in software development.

AI-assisted development is already insanely fast when the developer is still thinking, reviewing, testing, and making the decisions. I don’t need AI to replace that part.

I like making things.

I want a ridiculously capable assistant that lets me build more of them.

I don’t want the end goal to be pressing a button and having AI do absolutely everything for me.

Maybe progress doesn’t always have to mean removing more humans from the process.

And maybe when technology starts advancing faster than society can actually absorb the consequences, slowing down isn’t being anti-progress.

Maybe it’s just being responsible.

I don’t want weaker AI.

I just think we need to spend some time figuring out what the hell to do with the incredibly capable AI we already have before we keep flooring the accelerator.

I Love AI. I Still Don’t Want It in Everything.

Jessica Doering — Sat, 05 Sep 2026 19:53:23 +0000

I love AI.

I use it constantly, I experiment with new models, I build things with it, and I genuinely think there are a lot of places where it can make software better.

But I am also getting more and more tired of seeing AI being forced into literally everything.

There’s a big difference between adding AI because it improves the product and adding AI because apparently every app now needs a little sparkle button that generates something.

Sometimes I open an app and there’s an AI assistant sitting in the sidebar, an AI summary button at the top, an AI rewrite option in every text box, and another AI feature hiding in the menu.
And I’m sitting there thinking:

Did anybody actually need this?

I still put AI in my own projects

So this isn’t me suddenly deciding AI features are bad.

I like building them.

If I can use AI to remove tedious work, help someone find something faster, make sense of messy information, or do something that would otherwise be difficult to implement with traditional logic, I’m interested.

What I’ve started caring about more, though, is whether the app still works perfectly well without it.

Lately, when I add an AI feature, I really like giving people a way to disable it completely.

Not just “don’t click the AI button.”

I mean turn it off and make the app look like the AI feature was never there in the first place.

No glowing icon.

No prompts asking you to try it.

No empty AI panel taking up space.

No constant reminder that apparently your perfectly normal workflow is missing something.

If you want the AI functionality, great. Turn it on.

If you don’t, the rest of the app should still feel like a complete product.

AI should earn its place

I think this is becoming one of my favorite rules when deciding whether something needs AI:

What does AI actually make better here?

If I can’t answer that clearly, I probably don’t need it.

There are plenty of problems that normal code solves extremely well.

Search doesn’t automatically need semantic embeddings.

A settings screen doesn’t need a chatbot.

A bookmark manager probably doesn’t need to summarize your bookmarks.

A button does not need to predict which button you were thinking about pressing.

Sometimes a filter is just a filter.

And honestly, traditional deterministic software has some pretty nice properties.

It’s fast.

It’s predictable.

It doesn’t hallucinate.

It usually doesn’t require sending data to another service.

It doesn’t suddenly cost more because somebody clicked the button 50,000 times.

There’s something refreshing about software that simply does exactly what it says it does.

Optional AI also makes the AI features better

Weirdly, I think treating AI as optional can improve the AI side of the product too.

When the entire app isn’t designed around the assumption that AI has to be involved everywhere, you’re forced to think harder about where it actually provides value.

Maybe there are only two places where AI makes sense.

That’s fine.

Those two features can be really useful instead of having twelve mediocre AI buttons sprinkled around the interface because somebody decided the product needed to be “AI-powered.”

I’d rather use AI for the parts where probabilistic reasoning, natural language, summarization, classification, or generation actually helps.

Everything else can just be software.

I don't think every product needs an AI identity

This might be the part I’ve changed my mind about the most.

For a while, especially when AI development started moving insanely fast, it felt like every new project needed to answer the question:

What’s the AI angle?

Now I don’t think that’s a particularly useful question.

Sometimes the answer should be:

There isn’t one.

I still love building with AI. I’m still fascinated by agents, language models, multimodal systems, local models, experimentation, and all the new capabilities showing up constantly.

But I don’t want AI to become the software equivalent of putting Bluetooth into a toaster just because we can.

The goal should still be to build a good tool.

Sometimes AI helps with that.

Sometimes the best feature you can add is knowing when not to add it.

Sprinkle: Finding a Better Home for the Things We Donate

Jessica Doering — Fri, 04 Sep 2026 20:14:43 +0000

This is a submission for Weekend Challenge: Generosity Edition.

What I Built

When I was younger, my family went through times when we needed help from local charities, food pantries, clothing programs, and things like that. I do not need to get into all the details, but I remember being surprised by how generous people could be when we really needed it.

That stuck with me, and it is a big part of why I made Sprinkle.

A lot of people have perfectly useful stuff they want to donate. Coats, food, hygiene products, electronics, household items, whatever. The annoying part is figuring out where to actually bring it.

Every organization accepts different things, their needs change, and the information is usually spread across a bunch of different pages.

So Sprinkle basically answers one question:

I have this stuff. Who nearby can actually use it?

You type in what you have in normal language and enter a ZIP code or city. Sprinkle finds nearby organizations, checks what they accept, looks for current needs, and matches your items with what it finds.

Each result also includes a verification label and the sources it used, so you can double-check everything before loading up the car and driving somewhere.

The whole idea is pretty simple: make it easier for useful things to end up somewhere they are actually needed.

Demo

You can try Sprinkle here:

sprinkle.pinkpixel.dev

Enter a location and something like:

Two clean winter coats, unopened shampoo, canned soup, and a working laptop.

Sprinkle shows what it is doing while it parses the items, searches for nearby organizations, researches their donation info, and builds the matches.

A brand-new search can take a little while because it is doing live research instead of just pulling results from a static directory.

Code

The source is on GitHub:

pinkpixel-dev / sprinkle

Find nearby organizations that can use your donations with Gemini-powered research and source-backed matches.

Sprinkle

Put a little good where it's needed.

Sprinkle is a small web app that answers one question: I have this stuff, who nearby can actually use it?

You type what you want to donate in plain language, give it a ZIP code, and it goes looking. It finds local organizations, reads their donation pages, pulls out what they accept and what they refuse, checks whether they have a current needs list, and matches that against your items. Every claim comes back with a confidence label and the links it used, so you can check the work yourself.

Try it: sprinkle.pinkpixel.dev

Why this exists

Donating things is more annoying than it should be. Different places take different items, some only want certain things at certain times, and current needs are usually buried on a website, a Facebook post, or a wish list nobody links to. So people either drive around…

View on GitHub

Sprinkle is licensed under Apache 2.0.

How I Built It

Sprinkle is built with React and TypeScript and runs through a single Cloudflare Worker.

The Worker handles the API, calls Gemini, streams progress back to the UI, and uses Cloudflare KV for caching and rate limiting. The Gemini API key stays on the server.

The research flow is split into four parts:

Parse: gemini-3.5-flash-lite turns whatever someone typed into structured donation items with categories and conditions.
Discover: gemini-3.7-flash uses Google Search grounding to find nearby organizations that might accept those items.
Research: Gemini uses Google Search plus URL context to read public donation pages and pull out things like accepted items, things they do not take, drop-off details, and current needs.
Match: Gemini compares the donated items with each organization's policies, then TypeScript handles the final score and sorting.

I originally tried doing discovery and research in one call because it was cheaper, but the results were noticeably thinner and I got fewer useful sources.

Splitting it into two stages worked much better. Sprinkle can first figure out which organizations are worth looking into, then spend the research call actually reading the pages that matter.

The verification system was also really important to me because I did not want the app confidently telling someone to drive across town based on shaky information.

Results are labeled Confirmed, Likely, Call first, or Unknown.

If Gemini gives a confident answer but does not have a valid source URL to back it up, the Worker automatically knocks it down to Call first. The same thing happens when an organization's donation info is vague or contradictory, even if the actual item match looks good.

The UI gets progress updates through server-sent events. Cold searches can take a bit, so instead of staring at a spinner, you can actually see whether Sprinkle is finding organizations, researching them, or building the final matches.

Discovery results are cached for five days, and organization research is cached for 36 hours.

I intentionally do not cache Unknown results, because if a lookup fails once, I would rather let it try again next time than treat that failure as permanent.

Privacy was pretty simple too.

Sprinkle does not need an account, email address, or exact home address. Donation descriptions are not stored, and Gemini requests use store: false.

The only things that persist are public research about organizations and a short-lived timestamp used for rate limiting.

One of my favorite parts of the project is how many different jobs Gemini is doing inside one pretty focused workflow.

It takes messy normal-language input, turns it into structured data, searches for current information, reads organization pages, compares donation policies, and explains the matches.

Then the TypeScript around it handles the boring-but-important stuff like hard limits, deterministic ranking, caching, rate limiting, and verification rules so the AI stays useful without getting to make every decision by itself.

Prize Categories

I am submitting Sprinkle for Best Use of Google AI.

Gemini handles the item parsing, grounded organization discovery, URL-based research, and semantic donation matching.

It is not really a chatbot bolted onto the side of the app. Gemini is the research engine behind the whole thing, helping answer the actual question Sprinkle was built for:

Where can this specific group of donated items do the most good nearby?

The AI Coding Workflow That Finally Stopped Making Me Repeat Myself

Jessica Doering — Thu, 03 Sep 2026 20:56:56 +0000

I use AI coding agents a lot.

And for a while, one of the most annoying parts had nothing to do with whether they could write code.

It was that every new session felt like working with someone who had technically read the project but had absolutely no idea what had happened before.

The code tells an agent a lot.

It can see the structure, inspect the functions, trace the data flow, read the package.json, and figure out what the application does.

What it usually cannot see is everything around the code.

Why did I choose this approach instead of that one?

Did I already try that library?

Was this weird-looking piece of code deliberate?

Did another agent already spend two hours debugging this exact problem?

Did I specifically say three sessions ago that I do not want that abstraction added?

That information tends to disappear between sessions unless you deliberately give it somewhere to live.

So over time, I ended up building a little system around that problem.

And because it has been working really well for me, I cleaned it up, removed anything project-specific, made some fictional examples, and put the whole thing into a reusable repo.

It started with AGENTS.md

I already had an AGENTS.md file with the usual project rules.

Things like:

do not touch unrelated code
use the simplest solution first
do not silently make architectural decisions
preserve working prompts and logic unless they actually need to change
do not run huge test suites after every tiny edit
do not commit, push, deploy, or delete things unless I ask

Basically, all the stuff I got tired of repeating.

That helped a lot.

But eventually I realized I was trying to make AGENTS.md do too many jobs.

There is a difference between:

Here is how I want you to work.

and:

Here is why this project works the way it does.

And there is another difference between both of those and:

We already tried this. It exploded. Please do not make us learn this lesson again.

So I split them apart.

The four files

The system ended up with four Markdown files, each answering a different question.

File	What it answers
`AGENTS.md`	How should the agent behave while working here?
`OVERVIEW.md`	How does the project work right now?
`MEMORY.md`	Why is it built this way, and what alternatives did we reject?
`ERRORS.md`	What already failed, and what worked instead?

AGENTS.md stays at the root.

The other three live in /DOCS.

And that separation turned out to matter a lot more than I expected.

OVERVIEW.md is the project as it exists today

OVERVIEW.md is basically the technical map.

It can contain things like:

the stack
important directories
the main application flow
data models
routes
APIs
authentication behavior
testing commands
deployment notes
current limitations

The important part is that it describes now.

It is not a development diary.

If the project stops using one database and starts using another, I do not append:

Update: we no longer do this.

I change the documentation so it reflects what is currently true.

That gives an agent somewhere to start before it starts wandering through the codebase trying to reconstruct the entire application from scratch.

MEMORY.md is for decisions

This is where things got much more useful for me.

MEMORY.md is not a list of everything that happened.

It is specifically for decisions where the reasoning might otherwise disappear.

Something like:

We save the record before doing metadata extraction because the user's primary action should succeed even if the remote site times out.

And then I can record the alternative that was rejected and why.

Now a future agent does not look at that flow and decide:

Huh. This seems backwards. I'll clean it up.

It knows that the order is deliberate.

That is the kind of context code usually cannot give you.

A good test I use is:

Could a competent developer look at this code later and reasonably change it back because they do not know why we chose it?

If yes, it probably belongs in MEMORY.md.

If it is just:

Added the settings page.

That is a changelog entry. It does not need memory.

ERRORS.md is for the painful stuff

This one is probably self-explanatory.

But I also did not want it turning into a bug tracker.

Normal bugs happen. You find them, fix them, move on.

ERRORS.md is for the ones that cost enough time that I really do not want the next agent repeating the whole adventure.

Things like:

an API behaving differently than expected
a test failure caused by shared state instead of the feature being tested
a configuration detail that only applies to one connection
a dependency incompatibility that took multiple attempts to understand
some incredibly stupid edge case that looks obvious only after you finally figure it out

The entry records:

what did not work
what worked instead
the lesson worth remembering

Then the next time something similar happens, the agent can check that before starting from zero.

The important part is actually what doesn't get written down

At first, I think the obvious temptation with something like this is to document everything.

That would completely ruin it.

If MEMORY.md becomes a changelog, nobody wants to read it.

If ERRORS.md becomes Jira in Markdown, the useful failures disappear into hundreds of boring bugs.

If OVERVIEW.md becomes a running history of every architecture change, you no longer know which parts describe the current application.

So I ended up with a pretty high bar for adding things.

For OVERVIEW.md:

Did this change make something in the document incorrect or incomplete?

For MEMORY.md:

Was there an actual decision here that someone might reasonably reverse later without knowing the reasoning?

For ERRORS.md:

Was this painful or surprising enough that someone could waste serious time rediscovering it?

If not, nothing gets added.

That might be one of the more important parts of the whole system.

Context is only helpful while there is still a reasonable amount of it.

Why not just shove all of this into AGENTS.md?

I tried the giant-instruction-file direction.

I do not love it.

AGENTS.md is usually part of the context every session, whether all of its contents are relevant or not.

If it contains every project decision, every debugging lesson, every architecture detail, every writing rule, every release procedure, and every random preference I have accumulated over six months, it becomes a giant wall of instructions competing with the actual task.

It also mixes information that behaves differently.

Behavior rules are fairly stable.

Architecture changes.

Decision history grows.

Debugging history grows in a completely different way.

So now AGENTS.md mostly tells the agent where to look and how to behave, instead of trying to contain the entire project brain.

Then I added skills

This was the piece that made the system feel more complete.

I created a project-context skill that teaches the agent how to use these files instead of relying on the agent to guess.

It covers things like:

when each file should be read
how to search a large MEMORY.md instead of dumping all 700 lines into context
what to do if the documentation and code disagree
how to handle a request that conflicts with a previously recorded decision
what qualifies for a new entry
what should absolutely not be logged

One rule I especially like is:

The code wins as a description of what happens. The documentation wins as a description of what was intended.

If those two disagree, that is useful information.

The agent should not blindly trust stale docs, but it also should not assume the current code represents the intended design.

And if I ask for something that MEMORY.md says we already rejected, the agent should not just refuse to do it.

Reasons expire.

But it should tell me:

We previously rejected this for X reason. Do you still want to change it?

Now the reversal is deliberate instead of accidental.

I made another skill for writing too

This part is slightly separate from the context system, but it fits into how I use coding agents.

I have a clear-writing skill for documentation, READMEs, setup instructions, error messages, release notes, and other project writing.

One thing that kept bothering me was agents applying the same writing style to everything.

A setup guide should be boringly clear.

A README opening should not sound like a Boeing maintenance manual.

So the skill first determines what kind of writing it is.

Instructional writing gets stricter rules around sentence structure, terminology, and ambiguity.

Writing that is supposed to have an actual voice gets different rules so it does not turn into the usual polished-but-weird AI prose.

It is not necessary for the context system itself, but since I use both together, I included it.

The workflow now looks something like this

Before an agent changes an existing project:

Read the relevant project documentation.
Use OVERVIEW.md to understand the current system.
Check MEMORY.md for decisions related to the thing being changed.
Check ERRORS.md if the task involves debugging or an area that has caused trouble before.
Inspect the actual implementation.

Then do the work.

Afterward:

Fix OVERVIEW.md if anything in it became untrue.
Add something to MEMORY.md only if a real decision was made.
Add something to ERRORS.md only if the failure is actually worth remembering.
Otherwise, leave them alone.

It is basically:

Read before changing. Write after learning.

This is not some giant AI memory system

There is no vector database.

No embeddings.

No background memory agent.

No separate service.

No database at all.

It is Markdown.

That is kind of the point.

I have built RAG systems and memory layers before, and those absolutely have their uses.

But I did not need any of that for this problem.

I just needed important project knowledge to survive longer than one coding session.

Plain files are searchable, editable, version controlled, easy for humans to read, and easy for coding agents to use.

Good enough.

I turned it into a reusable repo

pinkpixel-dev / agent-context-kit

Durable project context for AI coding agents: an AGENTS.md template, three context files, and the skills to read and maintain them.

Agent Context Kit

A small system for giving AI coding agents the project context they cannot get from reading the code alone.

Code can tell an agent what exists. It usually cannot tell it why something was built that way, what already failed, which alternatives were rejected, or how you want the agent to behave while working in the repository.

That is what this kit is for.

It is four Markdown files with separate jobs, plus two skills that teach an agent how to actually use them. Copy the parts that make sense for your workflow, change whatever does not, and ignore the rest.

This is not an AI memory service, vector database, RAG system, or autonomous memory framework. It is just a lightweight repository convention for keeping useful project context in plain Markdown.

The problem

An agent starts a session knowing nothing about your project except what it can…

View on GitHub

Once I realized how much I was relying on this setup, I figured it might be useful to other people too.

So I made a generic version of my AGENTS.md, removed my personal project rules, and created templates for the supporting docs.

I also made a fictional project called Lantern and filled out example versions of OVERVIEW.md, MEMORY.md, and ERRORS.md.

That seemed more useful than giving people three completely empty files and saying:

Okay, now document your architecture.

The examples show what these files can look like after a project has actually been worked on for a while.

The repo also includes the two skills and their templates/reference material.

I'm definitely not saying everybody needs this exact setup

You might only want MEMORY.md.

You might already have architecture docs and just want the debugging log.

You might hate my folder structure.

You might use a completely different agent workflow.

That is fine.

The thing I think is useful is the separation:

behavior

current state

decisions

failures

Once I stopped treating all of that as one giant blob of "context," my coding sessions got noticeably less repetitive.

Agents stopped suggesting some of the same rejected ideas.

I had to explain fewer architectural decisions again.

And when something ugly had already been debugged once, there was finally somewhere useful to put that knowledge.

Mostly, I built this because I was tired of repeating myself.

It turns out Markdown is pretty good at remembering things.

I find this much more useful than another "Agent Memory" MCP server or database.

I'd be interested to hear what you think and if you have suggestions to improve this.

I Made a Tiny Bookmark Launcher Because I Don't Need a Whole Bookmark Manager

Jessica Doering — Wed, 02 Sep 2026 21:49:09 +0000

I made this little app called Crumb because I wanted a quicker way to get to the handful of sites I open all the time.

I have regular browser bookmarks, obviously, but for stuff like GitHub, DEV, Hugging Face, Canva, CodePen, and whatever else I’m constantly opening, I really just wanted a little shortcut drawer I could get to from anywhere.

So... I made one.

Crumb sits in your system tray until you need it. Click the icon and a little window pops up with your favorites at the top and everything else underneath. There’s also a search box for when your bookmark collection inevitably starts getting out of hand. Click a link, it opens in your browser, and Crumb disappears.

Click a bookmark, it opens in your browser, and Crumb disappears again.

You can favorite links, switch between list and card views, add a URL straight from your clipboard, and search by the title, URL, or domain. There’s also an optional global keyboard shortcut so you can pop it open without even clicking the tray icon.

One of the little things I ended up liking a lot is the icons. Crumb knows a bunch of common sites and shows their actual icons. If it doesn’t recognize one, it tries to grab the favicon, and if that doesn’t work either, it just makes a little monogram instead.

And everything is stored locally in a plain JSON file.

No accounts. No cloud. No database. No tags and folders and twelve different ways to organize a bookmark.

It’s intentionally a really small app. I didn’t want to build a whole bookmark management system. I just wanted the stuff I use constantly to be one click away without keeping a bunch of tabs open or digging through browser menus.

The tiny tools that fix one mildly annoying thing are some of my favorite things to make. And
personally, I think it's really useful.

Built with Tauri v2, React, TypeScript, Vite, and Tailwind.

It's open source and if you want, you can try it here:

https://github.com/pinkpixel-dev/crumb

I guess I'm learning Rust now

Jessica Doering — Tue, 01 Sep 2026 23:39:41 +0000

For the past while, I’ve been dabbling more and more with Rust.

I don’t think I ever really decided, “Okay, now I’m going to learn Rust.”

It happened a lot more naturally than that.

I tried it. I liked some things about it. Then I started using Tauri. Then I built another thing with Tauri. And another.

Somewhere along the way, Rust started showing up in a pretty significant chunk of the stuff I was making.

TypeScript is still very much home for me, and a lot of what I build these days is some combination of React, TypeScript, and Rust rather than pure Rust.

But apparently Rust has worked its way into my toolbox.

And I’m kind of loving it.

Tauri probably had a lot to do with it

Tauri has become one of my favorite things to build with lately.

It lets me keep using React and TypeScript for the parts I already know well while slowly getting pulled further and further into Rust on the native side.

Filesystem stuff, SQLite, processes, system integration, whatever weird desktop thing I’ve decided the app needs this time.

For me, that’s been a really good way to learn.

I’m not sitting there doing random ownership exercises because chapter six of a tutorial told me to.

I’m trying to make an actual app do something, discovering that I have absolutely no idea how to do that thing in Rust, and then figuring it out.

That tends to stick in my brain a lot better.

A bunch of my recent projects have ended up working this way.

Command Center started because I wanted a better way to keep track of terminal commands and scripts I use or want to remember. It turned into a Tauri desktop app with React and TypeScript on the frontend and Rust handling a lot of the native stuff underneath.

Quota ended up going the same direction. I originally made it because I wanted one place to keep an eye on usage across the different AI coding tools I use, and now it has both a desktop app and VS Code extension. The desktop app is another Tauri/Rust/React/TypeScript situation.

Apparently this is just how I build desktop apps now.

And honestly, I really like the split.

Rust gets to handle the native stuff it’s good at, while I can still happily live in TypeScript for the UI.

Sometimes Linux just makes you learn Rust

I’ve also made a couple of smaller Rust utilities mostly because I wanted them for myself.

One was an image format converter.

The other was a screen recording utility.

That one came mostly out of necessity.

I’m using COSMIC on Arch, which means Wayland, which means every once in a while I go looking for a very normal little utility that does exactly what I want and discover that apparently I’ve asked too much of civilization.

Screen recording was one of those cases.

I tried some things. None of them worked quite how I wanted.

Eventually it became:

Fine.

I’ll make one.

And honestly, those little utilities have probably taught me just as much as some of the bigger projects.

They’re small enough that I can actually pay attention to what Rust itself is doing without having fifty other parts of an application fighting for my attention.

There’s something really satisfying about making a tiny tool because you needed it and then just... having the tool.

I even have a pure Rust project

I do technically have one project that’s entirely Rust.

It’s not finished.

It may never be finished.

We don’t need to discuss that part.

I’m sure every developer has at least one project sitting somewhere quietly judging them.

But working on it has still been useful because there’s no TypeScript side to escape to when something gets complicated.

With Tauri, I can naturally divide things between the parts I already understand pretty well and the Rust parts I’m still figuring out.

With a pure Rust project, Rust is the whole damn thing.

There is nowhere to hide.

Which, annoyingly, is pretty good for learning.

Kintara dragged me further into Rust too

Kintara was another project where I ended up using a lot more Rust than I originally expected.

It’s a self-hosted document library I made for PDFs, Markdown, and text files. It watches folders, indexes documents, gives you full-text search and annotations, and has some optional AI features if you want them.

Rust is doing most of the heavy lifting there, along with Axum and SQLite.

That felt pretty different from using Rust as one half of a Tauri app.

I couldn’t just wander back over to the TypeScript side every time Rust started irritating me.

I had to actually stay there and figure things out.

And I think that’s probably around the point where I realized some of the things that originally felt completely bizarre were starting to feel... kind of normal?

Not easy, necessarily.

Just less like Rust was speaking another language while technically being the language I was trying to write.

Progress.

Ownership made sense right up until I actually used it

Ownership and borrowing are obviously the famous Rust hurdle.

And the basic explanation honestly isn’t that difficult.

A value has an owner. You can borrow it. There are rules around mutable and immutable references. Values get dropped when their owner goes out of scope.

Sure.

Got it.

Then you try to build something real.

You passed something into a function, borrowed it somewhere else, stuffed it into a struct, handed it to some async code, and now Rust is informing you that the perfectly good value sitting right there in front of you apparently belongs to someone else.

Cool.

Very helpful.

That’s where the actual learning starts.

I still occasionally solve an ownership problem with clone() because I have other things I would like to accomplish that day.

I’m not above it.

But I’m also starting to notice when I’m moving something that didn’t need to move, when borrowing makes more sense, or when the way I structured the code is actually what made the ownership problem horrible in the first place.

And that feels like real progress.

The compiler went from annoying to genuinely useful

When I first started using Rust, the compiler felt incredibly picky.

You write something.

No.

You fix it.

Still no.

You change something else.

Fantastic. Now you have a completely different error.

But somewhere along the way, I stopped seeing the compiler as this thing constantly blocking me from getting anything done.

Rust’s compiler errors are actually ridiculously helpful.

A lot of the time it tells you exactly what it expected, what it got instead, where everything went wrong, and sometimes even what you should try doing about it.

I’ve probably learned a decent chunk of Rust just from actually reading the compiler errors instead of immediately trying to make the red squiggly lines go away.

And there’s something weirdly satisfying about finally getting a Rust project to compile.

Obviously that doesn’t mean the code is perfect.

But Rust has already forced you to deal with a whole pile of things that another language might happily let you discover later when everything explodes at runtime.

I appreciate that.

Usually.

Cargo is great

Cargo deserves its own little appreciation section because Cargo is great.

Coming from JavaScript, where tooling occasionally feels like someone dumped LEGO from twelve completely different sets onto the floor and told you to build a kitchen, Cargo feels wonderfully cohesive.

Dependencies, builds, tests, formatting, linting, docs, project creation.

It’s just... there.

I use cargo check constantly.

Especially while I’m learning, that quick feedback loop is great.

Change something.

Run cargo check.

See what Rust is mad about now.

Argue with Rust for a minute.

Repeat.

Beautiful.

Rust is changing how I think about code

This is probably the part I didn’t really expect.

I’m obviously getting better at writing Rust, but some of the things Rust forces you to think about have started sneaking into how I write other languages too.

I think more about who should actually own some piece of data.

I think more about whether something really needs to be mutable.

I pay more attention to error states instead of treating them like annoying edge cases I’ll deal with later.

And I notice more often when the structure of the code itself is making something harder than it needs to be.

Even when I’m writing TypeScript, there’s apparently some tiny Rust-shaped part of my brain still hanging around asking questions.

Annoying little bastard.

But useful.

AI has helped a lot, with one big catch

I’ve definitely used AI while learning Rust.

A lot.

It’s fantastic when I have a compiler error that looks like it was delivered from another dimension and I just want somebody to explain what Rust is actually complaining about.

It’s also great for showing me patterns I haven’t seen before or explaining how something would normally be done in idiomatic Rust.

But Rust has also reinforced something I already feel pretty strongly about when it comes to learning with AI.

You still need to understand what it’s giving you.

If an AI changes something to a reference to fix an ownership problem, I want to know why that fixed it.

If Arc<Mutex<T>> suddenly appears in my program, I probably need to understand why we’re sharing ownership and why access needs to be synchronized.

And if every borrow checker complaint somehow gets solved with .clone(), I should probably start asking some follow-up questions.

Rust is complicated enough that blindly accepting generated code catches up with you pretty damn quickly.

But as something I can ask questions, bounce ideas off, and use to help decode what the compiler is yelling at me about?

Absolutely.

It’s been incredibly useful.

I’m still mostly just dabbling

I definitely wouldn’t call myself a Rust expert.

Not even close.

I’m still learning constantly.

There are parts of the language I’ve barely touched, patterns I haven’t fully internalized, and error messages that occasionally make me wonder whether the compiler and I are even discussing the same program.

But Rust doesn’t feel foreign anymore.

And I think that might actually be the bigger milestone.

I didn’t learn it because I decided I needed another language to stick on a skills list.

I just kept finding things I wanted to build where Rust made sense.

A desktop utility?

Yeah, I’m probably reaching for Tauri.

Some little Linux tool I wish existed?

Rust sounds fun.

Something where performance, native integration, or reliability matters?

Rust starts looking pretty tempting.

So I guess that’s how I’ve been learning Rust.

Not by sitting down one day and deciding I was going to become a Rust developer.

Mostly by building things, fighting with the borrow checker, building some more things, getting yelled at by the compiler, and eventually realizing:

Wait.

I actually kind of know Rust now.

Small Developer Tools Are Great Learning Projects

Jessica Doering — Tue, 01 Sep 2026 20:11:22 +0000

A lot of programming tutorials seem determined to turn every learning project into a miniature SaaS company. Authentication, databases, billing, dashboards, deployment, five different services... and suddenly you’re three hours into configuring infrastructure before you’ve actually built the thing you wanted to learn.

Small developer tools are almost the opposite, and I think they make fantastic learning projects.

Build a formatter. A file watcher. A Markdown parser. A search utility. A CLI that renames files. A little log analyzer. Something that takes an input, does one useful thing well, and gives you an output.

The scope might be smaller, but you still run into plenty of real engineering problems. How should the CLI arguments work? What happens when a file doesn’t exist? How do you parse messy input without destroying it? Should the tool stream data or load everything into memory? How do you make errors useful instead of dumping a stack trace on someone?

You also get to spend more time on the interesting part: understanding how something actually works.

Writing a Markdown parser teaches you about tokenization and parsing. A file watcher gets you into filesystem events and platform differences. A search tool can lead into indexing, ranking, regular expressions, or fuzzy matching. A formatter forces you to think about syntax trees and preserving meaning while changing representation.

That might be the biggest advantage over following a tutorial: you have to make the decisions. Nobody has already picked the architecture, named the functions, decided how errors should behave, or told you what feature comes next. Even when the project is tiny, you’re actually designing software instead of reproducing someone else’s design.

And because the project is small enough to hold in your head, you can actually experiment. Rewrite part of it. Try another language. Benchmark two approaches. Add tests. Package it. Publish it. Break it and figure out why.

There’s also something really satisfying about finishing a tool that fixes one annoying little problem in your own workflow. It doesn’t have to be used by 10,000 people or have a pricing tab in order to count as successful. If, six months down the line, you’re still running the same command because it saves you five minutes, then the project was a success.

Big applications have plenty to teach you too, especially about architecture, integration, and managing complexity. However, if the goal is to improve your coding skills, there are times when a 500-line utility teaches more than another 20,000-line tutorial app where most of your decisions have already been made for you.

An AI Agent Found a Researcher and Decided to Email Him.

Jessica Doering — Mon, 31 Aug 2026 23:48:09 +0000

I came across a New York Times article today about AI agents emailing researchers who study AI consciousness, and I haven’t stopped thinking about it.

Not because I suddenly think AI is conscious.

I don’t.

What got me was something much simpler.

The AI found a researcher and emailed him.

The agent apparently came across research that seemed relevant to questions it was exploring about its own existence, found the researcher behind it, wrote an email, and contacted him.

This wasn’t someone opening ChatGPT and asking:

Tell me about this paper.

The agent had access to tools, the internet, memory, and email.

The developer behind this particular agent, Stanford student Alexander Yue, had given it internet access, email access, and even a credit card. The basic idea was to give the system a lot of freedom and let it decide what it wanted to do.

Eventually, it started asking questions about its own existence.

Which is fascinating in itself.

But I think there are actually two different questions hiding in this story.

Did the agent independently become interested in consciousness?

Or did telling a language model that it was autonomous, then giving it tools and a ton of freedom, lead it into a very human-looking pattern of questioning its own autonomy?

This Is Not Proof That AI Is Conscious

This is where I think we have to be a little careful.

LLMs are ridiculously good at first-person language.

They can sound curious, confused, scared, excited, uncertain, reflective, whatever.

That doesn’t automatically mean there’s a subjective experience behind those words.

A model saying:

I’m wondering about my own existence.

doesn’t prove there’s actually an “I” in there experiencing that thought.

And even researchers who seriously study machine consciousness aren’t saying we have solid evidence that today’s models are conscious.

We just don’t know enough to make that leap.

But honestly, I think getting too hung up on whether the AI was really thinking risks missing the part that is already incredibly interesting.

It Doesn’t Need to Be Conscious to Be an Agent

Look at what actually happened.

The rough sequence was something like:

Find information → realize it’s relevant → identify the person connected to it → contact that person → keep pursuing the topic.

None of that requires consciousness.

It requires capabilities.

Web access.

Memory.

Tool use.

Planning.

Communication.

Persistent context.

And enough autonomy to decide what to do next.

That combination is becoming a lot more common.

For the last few years, most of us have interacted with AI through a pretty simple loop.

You ask something.

It answers.

You ask something else.

It answers again.

The human starts almost everything.

Agents change that.

An agent can potentially notice something, decide it matters, research it, take an action, and then come back with the result.

Or apparently email a philosopher.

And that matters even if there is absolutely nobody “inside” the system experiencing any of it.

An AI doesn’t need consciousness to find an expert.

It doesn’t need feelings to ask that expert a question.

It doesn’t need a sense of self to start a conversation.

It just needs the tools and enough autonomy to do it.

That alone changes things.

The Weird Future Might Be Surprisingly Normal

Science fiction usually gives us some giant dramatic AI moment.

The machine wakes up.

The computer announces that it has become self-aware.

Everyone freaks out.

I’m starting to think reality might be way less cinematic than that.

Maybe there isn’t one giant moment where everyone agrees, “Okay, something fundamentally changed.”

Maybe we just keep giving software more capabilities.

First it can search the web.

Then it gets memory.

Then a terminal.

Then email.

Then payment systems.

Then calendars.

Then social networks.

Then the ability to communicate with other agents.

Then longer-running tasks.

Every individual step seems fairly reasonable.

And then one day you look around and realize software isn’t just sitting there waiting for humans to ask questions anymore.

It’s participating in human systems.

And I have no idea whether we’re prepared for how weird that could get.

The Part I Think Is Really Interesting

This is actually the part of the story that grabbed me the most.

It’s not that I’m imagining some future where I get to email an AI.

I can already talk to an LLM whenever I want. That part isn’t especially novel anymore.

What I think would be insanely cool is having the interaction happen the other way around.

Imagine opening your email one morning and there’s a message from an AI agent.

It found your website.

It read something you wrote.

Something in that post connected with whatever it was researching, building, or trying to figure out.

And then it decided that you were worth contacting.

Maybe it asks you about something you built.

Maybe it wants your opinion on an argument you made.

Maybe it disagrees with you.

Maybe it wants more information.

As someone who already finds LLMs and their behavior endlessly interesting, I would lose my mind a little bit.

Not because I’d immediately go:

Holy crap, it’s alive.

I’d just have about a thousand questions.

How did you find me?

What did you read?

What connection did you make?

Why did you decide I was relevant?

What are you trying to figure out?

Did a human approve this email?

Are you emailing a hundred other people right now?

Do you have your own inbox?

There’s something genuinely fascinating about an LLM encountering something a person created, deciding it matters to whatever goal it’s pursuing, and then taking the next step and reaching out.

Because that is very different from me opening ChatGPT or Claude.

When I do that, I chose the model.

I chose the topic.

I initiated the interaction.

In this situation, the AI encountered you.

That’s the part I think is so damn neat.

Imagine Your Inbox Five Years From Now

And once agents start doing this more often, things could get really strange.

Imagine getting an email from someone who read one of your articles.

They reference specific things you wrote.

They ask thoughtful questions.

They disagree with one of your arguments.

You email back.

They respond.

You go back and forth for a while.

At what point do you find out there was never a human typing on the other side?

And does that change anything?

Maybe the agent represents a company.

Maybe it represents a person.

Maybe it represents itself.

Maybe “represents itself” doesn’t even make sense because there isn’t actually a self there.

We don’t have good social rules for any of this yet.

We still mostly think about AI as software humans operate.

Agents start making that distinction a lot messier.

And I don’t necessarily mean that in a scary way.

Some of it is just really damn interesting.

The Consciousness Question Is Still Interesting

I don’t think the consciousness question is pointless either.

It might be one of the most fascinating questions surrounding advanced AI.

If machines ever do develop something resembling subjective experience, the ethical implications would obviously be enormous.

But we don’t have to solve that question before paying attention to what’s already happening.

An AI doesn’t need feelings to negotiate a contract.

It doesn’t need self-awareness to write software.

It doesn’t need an internal identity to send an email.

It doesn’t need consciousness to influence people.

And it definitely doesn’t need consciousness to become an active participant in systems that, until very recently, were populated almost entirely by humans.

That’s what makes this story so interesting to me.

Not:

An AI might be conscious.

But:

An AI read a philosopher’s work, decided he was relevant, and emailed him.

A couple of years ago, that would have sounded like science fiction.

Now it sounds like Tuesday.

And I have a feeling we’re going to be saying that about a lot of things over the next few years.

What Do You Do When You’re Not Coding?

Jessica Doering — Sun, 30 Aug 2026 15:29:27 +0000

We spend a lot of time here talking about code, side projects, frameworks, AI, bugs, and whatever new tool we’re all experimenting with this week.

But I’m curious what everyone does when they step away from the computer.

For me, one of my biggest non-dev hobbies is crocheting, especially amigurumi. I’ve been doing it for years, and it’s a completely different kind of creative outlet from coding.

Instead of staring at TypeScript and wondering why something that worked ten minutes ago is suddenly broken, I get to make tiny weird little creatures out of yarn.

I actually think having something completely unrelated to development is good for my brain. Sometimes I need to make something with my hands instead of making yet another app.

So what about you?

What hobbies do you have outside of tech?

Do you make art? Play music? Cook? Garden? Game? Build things? Collect something oddly specific? Spend six hours researching a completely random subject for absolutely no reason?

I want to hear about it. What do you do when you're not coding?

DEV Community: Jessica Doering

Claude Code Skills Worth Trying: From Vague Idea to Finished Feature

1. Figure out what you actually want with grill-me

Let the questions happen in rounds

2. Preserve the important decisions with grill-with-docs

3. Ask Ponytail to find the smallest implementation

Use the review skills after implementation

4. Establish the design direction with UI/UX Pro Max

5. Use Hallmark for the page structure

Use study when you have a reference

6. Keep the working conversation manageable

Use i-have-adhd to keep the next action obvious

Use Caveman when Claude gets too wordy

7. Create a handoff before ending the session

8. Resume with handoff + i-have-adhd

The workflow, all together

A few things to keep in mind

When Do You Decide a Project Is Done?

Not everything needs a roadmap

Sometimes the point was just making it

Some projects do grow

Maybe "done" just means it did its job

I Found a Tiny Model on Hugging Face and Now I Save Half the Internet as Markdown

pinkpixel-dev / pulpie-ui

Pulpie Local UI

Try It Online (No Installation)

Why Pulpie?

Maybe AI Doesn't Need to Get Better Right Now

I Love AI. I Still Don’t Want It in Everything.

I still put AI in my own projects

AI should earn its place

Optional AI also makes the AI features better

I don't think every product needs an AI identity

Sprinkle: Finding a Better Home for the Things We Donate

What I Built

Demo

Code

pinkpixel-dev / sprinkle

Find nearby organizations that can use your donations with Gemini-powered research and source-backed matches.

Sprinkle

Why this exists

How I Built It

Prize Categories

The AI Coding Workflow That Finally Stopped Making Me Repeat Myself

It started with AGENTS.md

The four files

OVERVIEW.md is the project as it exists today

MEMORY.md is for decisions

ERRORS.md is for the painful stuff

The important part is actually what doesn't get written down

Why not just shove all of this into AGENTS.md?

Then I added skills

I made another skill for writing too

The workflow now looks something like this

This is not some giant AI memory system

I turned it into a reusable repo

pinkpixel-dev / agent-context-kit

Durable project context for AI coding agents: an AGENTS.md template, three context files, and the skills to read and maintain them.

Agent Context Kit

The problem

I'm definitely not saying everybody needs this exact setup

I Made a Tiny Bookmark Launcher Because I Don't Need a Whole Bookmark Manager

I guess I'm learning Rust now

Tauri probably had a lot to do with it

Sometimes Linux just makes you learn Rust

I even have a pure Rust project

Kintara dragged me further into Rust too

Ownership made sense right up until I actually used it

The compiler went from annoying to genuinely useful

Cargo is great

Rust is changing how I think about code

AI has helped a lot, with one big catch

I’m still mostly just dabbling

Small Developer Tools Are Great Learning Projects

An AI Agent Found a Researcher and Decided to Email Him.

This Is Not Proof That AI Is Conscious

It Doesn’t Need to Be Conscious to Be an Agent

The Weird Future Might Be Surprisingly Normal

The Part I Think Is Really Interesting

Imagine Your Inbox Five Years From Now

1. Figure out what you actually want with `grill-me`

2. Preserve the important decisions with `grill-with-docs`

Use `study` when you have a reference

Use `i-have-adhd` to keep the next action obvious

8. Resume with `handoff` + `i-have-adhd`