DEV Community: Jessica Doering

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

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

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

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

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

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

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

The actual content.

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

pinkpixel-dev / pulpie-mcp

pulpie-mcp

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

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

Why I made it

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

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

View on GitHub

The test that kind of blew my mind

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

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

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

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

I just thought this was so awesome.

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

Why I built it

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

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

But there was one annoying part:

I was still the one pulling the documentation.

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

Which is fine.

But also... why am I doing that?

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

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

What pulpie-mcp gives the agent

There are currently four tools:

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

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

Sometimes an agent just needs to quickly read one page.

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

For example, I can basically tell Claude:

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

And it handles the rest.

Or:

Do we already have the FastAPI docs saved somewhere?

No elaborate prompts required.

It doesn't shove 60 pages into the context window

This part was important to me.

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

That would be completely insane.

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

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

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

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

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

~/.pulpie/library/

Crawling is actually fairly smart too

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

It looks for sitemap information first:

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

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

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

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

The model runs locally

This is probably my favorite part.

pulpie-mcp uses:

feyninc/pulpie-orange-small

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

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

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

When the agent uses one of the tools:

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

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

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

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

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

Adding it to Claude Code

Install it:

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

Then:

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

That's basically it.

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

Codex

Add this to:

~/.codex/config.toml

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

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

There are still some limitations

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

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

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

This is exactly what I want MCP to be used for

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

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

But I really like this smaller category of MCP tools:

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

I used to:

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

Now I can basically say:

Grab the docs you need and figure this out.

And it does.

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

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

moments.

And those are my favorite kinds of projects.

Repo:

pulpie-mcp

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

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

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

What I Built

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

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

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

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

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

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

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

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

Demo

Live: https://hjkl.pinkpixel.dev

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

Code

pinkpixel-dev / hjkl

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

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

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

What's in it right now

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

View on GitHub

How I Built It

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

Every drill is checked in real vim

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

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

The coach: Gemma running on your GPU

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

A few details:

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

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

The coach does two things:

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

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

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

x ×7 (delete character)

instead of xxxxxxx, and

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

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

AI-generated drills

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

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

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

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

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

Deploying

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

Why Does Open Innovation Matter?

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

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

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

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

Prize Categories

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

Turn Your GitHub Contribution Graph Into an ASCII City

Jessica Doering — Sat, 03 Oct 2026 18:26:18 +0000

I decided that a normal GitHub contribution graph is not enough.

So I turned mine into a city.

And I wanted to share it so you can too.

I made Skyline, a small Go CLI that takes your GitHub contribution history and turns it into an ASCII city.

Each week becomes a building.

Each day becomes a window.

If you contributed that day, the window lights up. Busier days get brighter colors, your biggest week gets a little antenna, and the whole thing ends up looking like a tiny city built from your coding activity.

It can render directly in your terminal, but my favorite part is that it can also generate an animated SVG for your GitHub profile README.

I mean my GitHub profile definitely needed infrastructure.

How it works

The contribution graph maps surprisingly well to a skyline.

Each building represents one week of activity, and the height is based on the total contributions from that week.

The windows represent the seven days inside it.

A day with no activity stays dark:

·

A day with contributions lights up:

▪

The color intensity follows GitHub's contribution levels, so more active days get brighter windows.

There are also a few purely decorative bits because I couldn't resist.

Stars are scattered through the sky, some windows flicker in the SVG version, and the brightest stars twinkle.

The animations are deterministic, so regenerating the same contribution data doesn't completely rearrange your city every time.

There are themes of course

I started with neon and then immediately did the completely predictable thing and added more.

There are currently 12:

neon
synthwave
matrix
amber
ice
sunset
toxic
vapor
crimson
mono
prism
rainbow

You can preview them right in the terminal:

skyline -themes

And choose one with:

skyline -theme synthwave your-username

Personally, I am incapable of making terminal software without eventually adding neon colors to it, so this was inevitable.

Running it locally

You'll need Go 1.25 or newer.

Install Skyline with:

go install github.com/pinkpixel-dev/skyline@latest

Then run:

skyline your-username

Skyline needs access to the GitHub API, but it tries to make authentication fairly painless.

It checks:

GITHUB_TOKEN
GH_TOKEN
gh auth token

So if you're already authenticated with the GitHub CLI, there's a good chance you don't need to configure anything else.

The full city is 106 columns wide. If your terminal is a little less enthusiastic about this arrangement, you can render fewer weeks:

skyline -weeks 30 your-username

You can also change the maximum building height:

skyline -height 10 your-username

Generating the SVG

To create the version you can use on a website or GitHub profile:

skyline -svg skyline.svg your-username

Or combine options:

skyline -theme prism -svg skyline.svg your-username

That generates the animated SVG version instead of printing the city to the terminal.

The animation also respects prefers-reduced-motion, so it stays static for anyone who has reduced motion enabled.

Putting it on your GitHub profile

This is probably my favorite use for it.

You can have GitHub Actions regenerate your city automatically every night so your skyline changes along with your contribution graph.

Your GitHub profile README lives in a repository with the same name as your username:

github.com/your-username/your-username

Inside that repository, create:

.github/workflows/skyline.yml

Then add:

name: skyline

on:
  schedule:
    - cron: "17 3 * * *"
  workflow_dispatch:

permissions:
  contents: write

jobs:
  skyline:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-go@v7
        with:
          go-version: stable

      - name: Draw skyline
        env:
          GITHUB_TOKEN: ${{ secrets.SKYLINE_TOKEN || secrets.GITHUB_TOKEN }}
        run: go run github.com/pinkpixel-dev/skyline@latest -theme neon -svg skyline.svg "${{ github.repository_owner }}"

      - name: Publish to output branch
        env:
          TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          mkdir out && mv skyline.svg out/ && cd out
          git init -q -b output
          git add skyline.svg
          git -c user.name="github-actions[bot]" \
              -c user.email="41898282+github-actions[bot]@users.noreply.github.com" \
              commit -qm "Update skyline"
          git push -qf "https://x-access-token:${TOKEN}@github.com/${{ github.repository }}.git" output

You can swap:

-theme neon

for whichever theme you want.

Commit the workflow, open the Actions tab on GitHub, and run the skyline workflow manually once.

That creates the output branch containing skyline.svg.

Then add this to your profile README:

![My skyline](https://raw.githubusercontent.com/YOUR-USERNAME/YOUR-USERNAME/output/skyline.svg)

Replace YOUR-USERNAME with your actual GitHub username.

After that, the workflow redraws it automatically every night.

The generated SVG lives on the separate output branch, so you also don't end up with a year's worth of "update skyline" commits cluttering the main branch of your profile repo.

What about private contributions?

The workflow uses GitHub's built-in Actions token by default.

Depending on what contribution data GitHub exposes through that token, you might notice that your skyline looks a little emptier than the contribution graph you see while logged in.

If that happens, you can create a classic personal access token with the read:user scope and add it to the profile repository as a secret named:

SKYLINE_TOKEN

The workflow will automatically use that instead when it's available.

Unnecessary?

I suppose. But it's fun.

Why not take the data we already look at constantly and turn it into something a little more interesting? Contribution graphs are useful, but seeing an entire year transformed into this little glowing city makes it feel much more personal.

And because it's just an SVG, once the Action is configured there really isn't anything else to maintain. Your skyline just keeps changing as you work.

So yeah, you make one for your profile, I'd genuinely love to see it!

The project is open source here:

github.com/pinkpixel-dev/skyline

AI Coding Has Made Project-Switching Way Too Easy

Jessica Doering — Sat, 03 Oct 2026 01:16:40 +0000

I have a problem.

Actually, I have 84 public GitHub repositories.

I checked.

Eighty-four.

And that's just the public ones.

To be fair, they aren't all active projects. Some are old. Some are experiments. Some are tiny tools. Some have been abandoned, resurrected, renamed, rebuilt, or replaced by another project that I apparently decided absolutely needed to exist.

But still.

84.

I have always been the kind of person who gets excited about a new idea before I've finished the last one. AI coding tools did not create that problem.

They did, however, remove basically every obstacle that used to keep it under control.

It used to be harder to start something

Not necessarily hard, but there was friction.

You'd have an idea.

Maybe you'd think about it for a while. Research a library. Read some documentation. Figure out how you wanted to structure it. Decide whether learning an unfamiliar framework was worth the trouble.

Sometimes somewhere in that process you'd realize:

You know what? I don't actually care enough about this.

And that was probably healthy.

Now I can have a thought like:

It would be cool if there were a terminal MIDI player.

And ten minutes later I have a Rust project, a Ratatui interface, MIDI playback partially working, a name, a logo idea, and opinions about the layout.

The responsible part of my brain never even got a meeting invite.

AI destroyed the activation energy

This might be one of the biggest ways AI coding tools have changed how I build software.

They didn't just make programming faster.

They made starting dramatically easier.

A new language isn't as intimidating because I can ask questions while I work.

An unfamiliar library isn't a weekend of documentation before I can touch anything.

Boilerplate barely matters.

I don't have to remember the exact configuration for every framework I've ever used.

If I want to know whether some weird idea is technically possible, I don't necessarily have to spend three hours researching it first.

I can just try it.

And honestly, that's pretty incredible.

I've built things with Rust that I probably wouldn't have touched yet otherwise. I've experimented with terminal UIs, local AI models, MCP servers, desktop apps, browser APIs, image tools, audio tools, little utilities, developer tools, and an unreasonable assortment of other things.

Some became real projects.

Some taught me something useful.

Some lasted approximately one evening.

I don't think any of that time was wasted.

But there is definitely a side effect.

Every idea can become a project now

This is where things get dangerous for people like me.

Previously, there was a natural filter between:

"That would be neat."

and

"I'm building that."

AI has made that filter extremely thin.

Sometimes nonexistent.

I'll be working on one project and run into a tiny annoyance.

That annoyance gives me an idea for a tool.

I ask an AI coding agent whether the idea would work.

It says yes.

Obviously this is unacceptable.

Now I need to build it.

Two hours later the original project is sitting abandoned in another terminal tab wondering where I went.

It's not even always a big idea.

Sometimes it's:

I wish this command did one extra thing.
It would be nice if I had a little UI for this.
Why doesn't this tool show this information?
I bet I could make this work in the terminal.
What if this accepted pasted images directly?
Could I make this local instead?
I wonder if this model would run in the browser.
This existing tool is almost what I want, except...

That last one is particularly dangerous.

Except.

Nothing has generated more repositories on my GitHub account than "this is almost what I want, except..."

Prototyping has become ridiculously cheap

And I mean cheap in more than just money.

The cost in time, effort, and mental energy has dropped.

I can test an idea before I've fully committed to it.

That's a huge advantage.

There are projects I've started where I realized pretty quickly that the idea wasn't as interesting as I thought. In the past, I might have spent days figuring that out.

Now I can sometimes figure it out in an hour.

Delete it. Archive it. Move on.

That's not failure.

That's a prototype doing its job.

The problem is that the exact same thing also makes it very easy to chase the next shiny idea.

And the next one.

And the one after that.

AI makes getting from 0% to 30% incredibly fast.

Unfortunately, 30% is also right around where another idea starts looking very exciting.

Starting and finishing are completely different skills

This is the part AI hasn't magically solved.

Starting a project is exciting.

You're creating everything from scratch. Every hour produces something visible. The architecture is clean because you haven't had enough time to ruin it yet. There are no users. There are no weird edge cases. Nobody has opened an issue explaining that your perfectly reasonable code breaks when their username contains an emoji and they're running Linux on a refrigerator.

Everything is possibility.

Finishing is different.

Finishing means:

fixing boring bugs
handling edge cases
writing documentation
testing things you already thought worked
cleaning up shortcuts you took during the prototype
packaging
deployment
accessibility
updating dependencies
realizing the feature you added three weeks ago broke something completely unrelated

AI can help with all of that.

But it doesn't make that stage feel like a shiny new project.

And that's the actual trap.

When starting becomes nearly frictionless, finishing has more competition than it ever did before.

But I don't actually want the friction back

This is the weird part.

I don't think the solution is to force myself to stop starting things.

I like experimenting.

A lot.

Some of the most useful things I've learned came from projects I had absolutely no business starting.

Sometimes I'll build something mostly because I want to learn a library.

Sometimes I want to see whether an idea works.

Sometimes existing software annoys me.

Sometimes I just think something would be fun.

Not every repository needs to become a product.

Not every side project needs users.

Not everything needs a roadmap, monetization strategy, launch plan, or compelling answer to "What problem does this solve?"

Sometimes the answer is:

I wanted to see if I could make it.

That's still one of my favorite reasons to program.

AI has made that kind of experimentation ridiculously accessible.

I don't want to lose that.

I just need to occasionally remember that GitHub also allows you to work on repositories that already exist.

Apparently.

I'm trying to separate experiments from commitments

The distinction I've started thinking about more is whether I'm exploring an idea or starting a project.

Those don't have to mean the same thing.

I can spend an evening testing some strange concept without mentally adding it to my collection of Things I Must Finish Someday.

That's harder than it sounds.

Especially when you've already named it.

Naming it is usually where I'm screwed.

Once it has a cute name and an icon, we're in dangerous territory.

But I think there's something useful about allowing yourself to prototype freely while being more selective about what gets promoted into an actual ongoing project.

Maybe the experiment taught me what I wanted to know.

Maybe the idea isn't strong enough.

Maybe another project already solves it.

Maybe it's fun enough to continue.

Maybe I open the repo three days later and immediately think:

Oh hell yes. I still want this.

That's probably a better signal than the initial burst of excitement.

This might be one of AI coding's strangest effects

We talk constantly about whether AI makes developers more productive.

How much faster can it write code?

How many tasks can an agent complete?

Which model gets the highest score?

Those things matter.

But I think there's another effect that's harder to measure.

AI changes what we're willing to try.

Ideas that previously weren't worth the setup cost suddenly are.

Technologies that felt too unfamiliar become approachable.

Tiny personal tools become worth building.

Ridiculous experiments become a Tuesday night.

The distance between curiosity and working code has gotten incredibly short.

For developers who already suffer from chronic "I could build that" syndrome, this is both wonderful and absolutely terrible.

I have learned more because of it.

I've tried things I wouldn't have tried before.

I've built tools I genuinely use.

I've also accumulated enough repositories that GitHub probably thinks I'm several people.

So no, I don't think AI made me a chronic project starter.

I was perfectly capable of doing that myself.

It just gave me a much faster shovel.

And apparently I have been digging.

Managing the Hidden Overhead of AI Software Engineering

Jessica Doering — Tue, 22 Sep 2026 04:43:03 +0000

There is a scene that is becoming more and more common in software development right now.

You have one AI coding agent refactoring something.

Another one is writing tests.

A third is handling some annoying migration you did not want to touch yourself.

You are bouncing between terminals, checking progress, answering questions, approving changes, and generally supervising a tiny army of extremely enthusiastic robot developers.

And then the thought hits you:

I could open another terminal.

I have absolutely done this.

The problem is not that running multiple agents is automatically bad. Parallel work can be incredibly useful. The problem is that the second AI gives us more capacity, our first instinct is often to immediately fill that capacity with even more AI work.

Instead of asking, “What should I do with the time this just gave me?” we ask, “How much more stuff can I cram into this workflow?”

That works for a while.

Then things start getting weird.

AI Coding Tools Really Do Make You Faster

I do not think there is much point pretending otherwise.

AI coding tools can make development dramatically faster, especially for certain kinds of work.

Boilerplate that used to take half an hour can appear in seconds. Setting up basic project scaffolding is almost trivial. Stupid syntax mistakes disappear faster. Tests, utility functions, repetitive components, documentation, migrations, and all kinds of boring little tasks can be delegated.

So naturally, developers start doing more.

That feature you were going to put off until next week? Might as well do it now.

That weird side project idea? Fire up another agent.

That one annoying task nobody wants to do? Toss it at the AI.

Suddenly the amount of work you can start feels almost unlimited.

The amount of work you can actually understand, review, and maintain is another story.

Speed Creates Its Own Problems

If you generate code five times faster, you can also lose track of what the hell is happening five times faster.

One of the strangest signs of this is when you find yourself reading an AI-generated summary of a change just to remember what your own project is doing.

I have caught myself doing this.

The agent finishes some task, gives me a neat little summary, and I am reading it thinking, “Oh right. That is what we were changing.”

That is probably not a great sign.

At that point, you are no longer really engineering the system. You are managing a queue of things being engineered around you.

And that becomes dangerous when the mistake is not obvious.

Imagine you ask an agent to implement a permission system.

The code looks clean.

The naming matches the rest of the project.

The tests pass.

Nothing immediately looks broken, so you approve it and move on.

Except maybe your prompt never clearly defined how restrictive the permissions were supposed to be. The model filled in the missing details itself and chose something more permissive than you intended.

The tests still pass because they only verify that permissions work.

They do not verify that the permissions match the security model you had in your head.

That distinction matters a lot:

Passing tests does not automatically mean the software is doing what you actually intended.

AI Did Not Remove the Bottleneck

It moved it.

For a long time, one of the slowest parts of programming was simply turning an idea into working code.

You had to write the implementation yourself, debug it, fix syntax errors, wire everything together, and slowly turn the design into something executable.

AI can now blast through a lot of that work.

Great.

But now we have a different bottleneck.

Understanding and verification.

The faster code gets generated, the more code somebody has to review.

And generated code still needs review.

Heavy AI adoption among developers correlates with significantly longer PR review times. That makes sense. If everyone suddenly starts producing dramatically more code, human review capacity does not magically increase along with it.

This gets even more interesting with experienced developers working in large, complicated codebases.

AI can feel faster because you are typing less, while actually making the overall task slower because you now have to carefully inspect a bunch of generated code interacting with years of existing architecture.

That is one of the things I think gets lost in a lot of AI productivity discussions.

AI is amazing at some kinds of development.

Small isolated features? Great.

Boilerplate? Fantastic.

A giant legacy system where changing one innocent-looking function somehow breaks seven unrelated things and awakens a forgotten service from 2014?

Different story.

And this creates a strange contradiction.

AI is writing more and more production code, while developers still regularly report hallucinations, incorrect output, and limited trust in what the models produce.

We are delegating faster than we are learning how to verify.

That creates verification debt.

You save time during generation, but some of that time has not really disappeared.

It has just been moved somewhere else.

Maybe into code review.

Maybe into debugging.

Maybe into production incidents six weeks later when somebody finally discovers the assumption the model quietly made.

Why Do We Keep Opening More Agents?

Part of this is technical.

Part of it is also very human.

There is a weird little dopamine hit that comes from watching AI agents crank through tasks.

Feature finished.

Another PR.

Another commit.

Another task crossed off the list.

Visible output feels productive.

Meanwhile, spending two hours understanding an architecture diagram or reading framework documentation might produce exactly zero commits.

Even if it saves you ten hours later.

There is also a measurement problem.

It is easy to count closed PRs.

It is harder to measure “developer now understands the system well enough to prevent three terrible architectural decisions.”

And then there is the career anxiety around AI.

A lot of developers are understandably wondering what all of this means for their jobs.

That creates pressure to become the person running more agents, producing more code, and moving faster.

Almost like we need to prove we can keep up with the machines by becoming extremely efficient machine supervisors.

The irony is that blindly maximizing AI output may make us worse at the exact skills we are going to need most.

So What Should We Do With the Time AI Gives Us?

This is the part I think matters most.

If AI saves you two hours, you do not necessarily need to spend those two hours generating another two hours worth of code.

Use some of that time for the stuff developers never had enough time for before.

Actually Read the Documentation

Not skim it looking for the one code snippet that solves your immediate problem.

Actually read it.

Understand how the framework works.

Read the architecture docs.

Look at the edge cases.

Understand why the API behaves the way it does.

The better your mental model of the system is, the better your prompts become too.

AI works a hell of a lot better when the person steering it understands what they are steering.

Write Better Specs Before You Generate Anything

This is probably one of the biggest workflow improvements you can make.

Before launching an agent, clearly define what the thing should do.

Also define what it should not do.

Write down important constraints.

Define security boundaries.

Mention the ugly edge cases.

Tell the model what must remain unchanged.

A prompt like:

Add a permission system.

leaves a massive amount of room for interpretation.

A specification that explains permission scopes, forbidden wildcard access, role inheritance, failure behavior, expected tests, and review requirements leaves considerably less.

Models are very good at filling gaps.

Unfortunately, they do not always fill them with what you meant.

Talk to Humans

Wild concept, I know.

Sometimes the best thing you can do with your newly reclaimed development time is talk to the product person, designer, teammate, user, or whoever actually understands the requirement you are about to implement.

AI can generate twenty implementations of an unclear requirement.

It cannot magically make the requirement less unclear.

Keep Useful Technical Documentation

Architecture decisions.

Important tradeoffs.

Why something was implemented a certain way.

What absolutely should not be changed without understanding some weird dependency.

This stuff becomes even more valuable when AI agents are touching the codebase.

Good documentation gives both humans and agents better context.

And unlike yet another generated feature, it keeps paying off later.

The basic idea is pretty simple:

The time AI gives you is often more valuable when you spend it doing things AI cannot do well than when you immediately throw another agent at another task.

A Few Rules I Have Started Thinking About

I do not think there is one perfect AI coding workflow, but there are a few principles that make a lot of sense to me.

1. If you cannot explain the feature, do not prompt it yet

If the requirement is fuzzy in your own head, the model is going to fill in the blanks.

Sometimes it will guess correctly.

Sometimes it absolutely will not.

Figure out the boundaries first.

2. Do not merge code you cannot explain

You do not need to memorize every line.

But if an agent gives you a giant diff and you cannot explain what it changed, why it changed it, and how the important pieces work, that is probably not ready to merge.

“Tests passed” is not enough.

3. Be extremely suspicious around high-risk code

Authentication.

Authorization.

Payments.

Database mutations.

Encryption.

Permission systems.

Anything where a mistake could expose data or seriously break something deserves much more careful review.

Those are not great places for the old:

“Looks good from here.”

4. Stop treating maximum parallelism as the goal

Sometimes one agent working on one clearly defined problem is better than four agents generating four separate review queues.

Every additional task has a context cost.

Eventually you become the bottleneck.

5. Count review time as part of the task

If an agent writes something in four minutes and you spend forty minutes verifying it, the task did not take four minutes.

It took forty-four.

That does not make AI useless.

It just means we should stop measuring productivity by generation speed alone.

6. Ask the AI why

Do not only ask for code.

Ask why it chose that approach.

Ask what alternatives it considered.

Ask what assumptions it made.

Ask where the implementation might fail.

Ask what part it is least confident about.

Using AI as something you interrogate is very different from using it as a code vending machine.

7. Still write code yourself sometimes

I am very pro-AI coding tools, obviously.

But I also think there is value in occasionally turning them off and actually building something yourself.

You need enough hands-on understanding to recognize when generated code is bullshit.

That skill gets harder to maintain if you never exercise it.

We Have Been Through This Kind of Shift Before

Software development is basically a long history of building abstractions on top of other abstractions.

Assembly languages gave way to higher-level languages.

Infrastructure became cloud services.

Libraries replaced mountains of custom implementation.

Frameworks automated huge parts of application development.

Every time this happens, somebody announces that programmers are about to become obsolete.

Instead, the job changes.

Developers stop spending as much time on one layer and start working at another.

AI looks like another massive abstraction layer.

The ability to manually type code is becoming less important than it used to be.

But knowing what code should exist, how systems fit together, what tradeoffs matter, and whether the implementation is actually correct becomes more important.

That is not less engineering.

It is engineering happening at a different level.

Maybe You Do Not Need Another Terminal

I started noticing that when I reduced the number of parallel AI sessions I was running, I actually felt more in control of my projects.

I spent more time defining what I wanted before generating it.

I read more of the code afterward.

I documented decisions.

I caught more questionable assumptions.

Did that sometimes make the first thirty minutes of a task slower?

Yep.

But the software usually came out better.

And more importantly, I actually understood what I had built.

AI gives developers an absurd amount of leverage.

I love that.

But leverage works in both directions.

It can help you build faster, or it can help you create an enormous pile of code you barely understand at record speed.

There will always be another terminal you can open.

Another agent you can launch.

Another task you can parallelize.

The harder skill might be recognizing when you already have enough code being generated and the most productive thing you can do is stop generating for a minute and actually think.

I Built a Local AI Music Studio

Jessica Doering — Sun, 20 Sep 2026 21:30:07 +0000

I have a habit of starting projects because I want one very specific thing.

Then somewhere along the way I apparently decide, "Well, if I'm already doing this..."

And suddenly the tiny experiment has a database, Docker Compose stack, job queue, model manager, audio editor, waveform player, and enough GPU models to eat 40 GB of disk space.

So, anyway.

I made Miso.

miso.pinkpixel.dev

Miso is a self-hosted local music generation and remix studio built on top of audio.cpp.

The original idea was pretty simple: I wanted a nice interface for experimenting with local music models without constantly dropping back to command-line tools, juggling generated files, or trying to remember which ridiculous combination of parameters made the song I actually liked.

It got slightly out of hand.

I didn't just want "type prompt, get song"

There are already plenty of ways to generate a song from a text box.

That part is fun, but the thing I kept wanting was everything that comes after generation.

What if I like the song except for eight seconds in the middle?

What if I want the vocals by themselves?

What if I want to change the singer?

What if I want the same melody arranged in a completely different style?

What if I want to turn something into MIDI and keep screwing with it somewhere else?

That became the real idea behind Miso.

A project doesn't just hold the final song. It keeps the takes, prompts, lyrics, stems, scores, transcriptions, and the lineage between them, so I can experiment without losing track of how I got there.

There are a ridiculous number of models involved

Miso currently exposes several different music and audio model families through audio.cpp because they are good at very different things.

ACE-Step 1.5 is the main workhorse. It handles full song generation, covers, and repainting sections of existing tracks.

YuE2 can generate songs too, but it does something I find especially interesting: it plans an ABC music score first and can give that score back to you.

MiniMax Music 3 and HeartMuLa are alternate song generators with their own prompting styles.

Stable Audio 3 handles instrumental generation and sound effects.

Then there are separate models for stem separation, voice conversion, and audio-to-MIDI transcription.

The funny part is that they absolutely do not accept prompts the same way.

One model wants a production-style caption.

Another wants a short description plus comma-separated tags.

ACE-Step wants style information in one place, BPM and key as separate parameters, and lyrics somewhere else.

So Miso has a guided builder that translates the same set of UI controls into whatever syntax the selected model actually expects.

I wanted to be able to think about "upbeat synthpop, female vocal, 120 BPM" instead of remembering which API field each model decided should contain "120 BPM."

Repainting is interesting

One of the features Miso is most built around is repainting.

You load a take, drag across part of its waveform, and replace only that section.

So instead of regenerating a whole song because one chorus went weird, you can select that section and try again.

ACE-Step's repaint route turned out to have some quirks that were interesting to figure out, too.

The surrounding music influences the replacement much more strongly than the text prompt does. Lyrics have more control over a vocal repaint than telling the prompt to suddenly turn the section into something wildly different.

That wasn't something I wanted to guess about, so I ended up testing it.

At one point I ran deliberately opposite prompts through the route and compared the results. The normal text-to-music route reacted dramatically. Repaint barely cared.

Which is one of the reasons I enjoy projects like this. Half of building the interface becomes figuring out what these models actually do rather than what I assume they do from an API description.

Then I started pulling songs apart

Miso can also split a track into stems.

Depending on the model, that can mean:

vocals + instrumental
vocals + drums + bass + everything else

Once the stems exist, they get their own mixer.

You can solo them, mute them, change their levels, swap a vocal using a voice conversion model, mix everything back together, and save the result as another take.

That led to another rabbit hole: voice conversion.

RVC sounds better but only has a small set of packaged voices.

Vevo2 has lower output bandwidth, but it can use basically any other vocal reference in the project.

So both stayed.

I would rather expose two tools with different tradeoffs than pretend one is objectively the "correct" choice.

The part I just finished is more interesting

The current release, 1.4.0, connects MIDI transcription to YuE2's score support.

Previously, Miso could already:

split a song into stems
transcribe audio into MIDI notes
give YuE2 an ABC score and tell it to sing that melody

The pieces just weren't connected.

Now they are.

You can separate a song, transcribe the vocal stem, turn those note events into an ABC melody, inspect the detected tempo and key, correct them if necessary, and feed the score into YuE2 with a completely different style.

So you can take the melody from a recording and use it as the basis for a new arrangement.

I tested that path with a known melody instead of just listening and declaring, "yeah, sounds about right."

I generated a simple version of Twinkle Twinkle Little Star, ran it back through separation, transcription, and score conversion, and recovered the expected pitches across the recording.

Rhythm is less perfect than pitch, and real vocals can produce odd little tied or split notes, but the result is usable by the model.

That was one of those features where suddenly several earlier pieces of the project made much more sense together.

pinkpixel-dev / miso

A local music generation and remix studio built on audio.cpp. Generate, repaint, split into stems and swap voices, with every take kept and traceable.

A local music generation and remix studio. You bring a prompt or a song, and Miso gives you a real workspace for generating, remixing, splitting, and finishing music with models that run on your own machine. Nothing is sent anywhere.

Miso runs on audio.cpp, a C++ inference runtime for audio models. Miso is the studio around it: projects that persist, a history of every take and a record of exactly how each clip was made so you can change one thing and try again.

Miso installs models, keeps your projects and audio, generates with ACE-Step from a guided prompt builder with lyrics written for you if you want them, repaints a section of a track, covers a take, holds any two takes against each other, splits a song into stems you can mix and export, writes full 48 kHz stereo songs with YuE2 and hands back the score it…

View on GitHub

Miso is local-first

The whole thing runs as two Docker containers.

One runs Miso itself.

The other runs audio.cpp and owns the GPU models.

The browser never talks directly to audio.cpp. It talks to Miso, and Miso talks to the inference backend.

That separation became useful almost immediately.

Projects, imports, playback, exports, and editing still work if the model backend is stopped.

It also means the audio.cpp server can live on another machine with the GPU while Miso runs somewhere else.

The app itself uses React, TypeScript, Vite, Node, Hono, and SQLite.

I deliberately kept most ordinary audio editing in the browser rather than turning everything into another server job.

Things like trimming, fading, gain changes, normalization, splitting, WAV conversion, and MP3 export do not need a giant AI model involved.

Sometimes software can just... do the normal thing.

Wild concept, I know.

There's an optional AI assistant too

I did sneak one language model feature in.

Miso can optionally connect to an OpenAI-compatible API or a local llama.cpp server to help write lyrics or expand a music prompt.

But it is completely separate from the music models.

Nothing gets silently rewritten.

It gives you a suggestion, shows it to you, and you decide whether to use it.

That was important to me because I don't want an assistant "improving" a prompt behind my back and then making it impossible to figure out why two generations were different.

If you accept an expanded prompt, Miso keeps both the original and the version that actually ran.

This project taught me a lot about building around AI models

Not really about calling them.

That part is usually the easy bit.

The interesting problems were things like:

models that require different sample rates
models that return multiple huge audio files
models that need several components loaded in sequence to fit in VRAM
jobs that can run for several minutes
uploads that need to survive browser tabs closing
model APIs that technically accept a parameter but quietly ignore it if you put it in the wrong part of the request
keeping enough generation history to reproduce something useful
dealing with a backend that can only run one expensive job at a time
determining which behavior belongs in the UI versus the server versus the inference runtime

And, of course, learning that "the documentation says this option does X" and "the model meaningfully responds to X" are not always the same statement.

That last one is probably applicable to a lot more than music models.

It's still very much a project

Miso is open source, and right now it has mostly been tested on my own Linux machine with an RTX 4090 laptop GPU.

So I am absolutely not going to pretend I have tested every GPU, driver, operating system, or model combination in existence.

But it has grown from "I want a good way to play around with local music models" into something I actually think is pretty awesome.

And that is my favorite kind of project.

The kind where I started building a tool because I wanted to experiment with something...

...and then ended up building the experiment itself.

Bookmarks for Your Terminal

Jessica Doering — Fri, 18 Sep 2026 20:13:23 +0000

If you use Linux and spend a decent amount of time in the terminal, zoxide is one of those little tools that's absolutely worth trying if you haven't already.

It makes jumping between directories ridiculously fast by remembering the places you visit most often.

Instead of typing:

cd ~/Projects/my_project

you can usually just type:

z my_project

and you're there.

The easiest way I can describe it is bookmarks for your terminal, except you don't have to create the bookmarks yourself.

What zoxide actually does

zoxide is a smarter replacement for cd.

As you move around your filesystem, it remembers which directories you visit and how often you use them.

Then instead of typing the full path, you can jump back to a directory using only part of its name.

For example, maybe I have a project here:

/home/username/Projects/my_project

Normally I would type something like:

cd ~/Projects/my_project

With zoxide, after I've visited it before, I can usually just type:

z my_project

And I'm there.

That's it.

No aliases to maintain. No giant list of paths. No remembering exactly where I put the damn thing.

It gets better the more you use it

The nice thing about zoxide is that you don't really have to organize anything.

It builds its own database based on the directories you actually visit.

So if you constantly jump into:

~/Projects/my_project
~/Documents/School
~/Projects/random-experiment-number-847

Eventually:

z my_project

z school

or even something like:

z random

can take you straight there.

zoxide ranks directories based on things like how often and how recently you've visited them, so it tends to get better at guessing where you want to go over time.

Installing it

On Arch:

sudo pacman -S zoxide

Ubuntu/Debian users:

sudo apt install zoxide -y

curl -sSfL https://raw.githubusercontent.com/ajeetdsouza/zoxide/main/install.sh | sh

Then you add the initialization command for your shell.

For Fish:

zoxide init fish | source

For Bash:

eval "$(zoxide init bash)"

For Zsh:

eval "$(zoxide init zsh)"

Put that in your shell config so it loads automatically.

Then just use your terminal normally.

You don't have to stop using `cd`

One thing I like about zoxide is that it doesn't force you into some completely different way of navigating.

You can still use:

cd ..

or:

cd ~/Downloads

whenever that makes sense.

I tend to use normal cd for directories that are nearby and z for jumping across my filesystem.

Something like:

z my_project

is a lot nicer than remembering whether the project is currently hiding under:

~/Projects/apps/my_project

or:

~/Code/projects/my_project

or whatever organizational system I was apparently convinced was brilliant three months ago.

Interactive searching is even nicer

zoxide also supports interactive selection when paired with a fuzzy finder like fzf.

You can run:

zi

and get an interactive list of directories zoxide knows about.

Start typing part of a directory name, pick the one you want, hit Enter, and you're there.

This is especially handy when you know you worked on something with a certain name but have absolutely no clue where you put it.

Which, if you create a ridiculous number of projects, happens a lot.

Tiny tools like this are my favorite

zoxide isn't some enormous productivity system.

It doesn't require accounts.

It doesn't want me to organize my entire life.

It doesn't have a dashboard.

It just notices where I go and makes getting back there easier.

After using it for a while, typing long directory paths starts to feel strangely unnecessary.

So if you spend much time in a Linux terminal and haven't tried zoxide yet, it's worth checking out.

Your filesystem can remain an organizational disaster.

You just don't have to remember where everything is anymore.

Programming Is Mostly Learning How to Investigate Things

Jessica Doering — Fri, 18 Sep 2026 00:47:32 +0000

When I first started learning programming, I thought getting better at it meant knowing more stuff.

More syntax.

More commands.

More frameworks.

More things I could remember without having to look them up.

And yeah, obviously knowing things helps.

But the longer I do this, the more I think a huge part of programming is just learning how to investigate things.

Because half the time, the situation is basically:

Something is broken.

I don't know why.

Cool.

Now what?

You start poking at it

Maybe there's an error message.

Maybe there isn't, which is always fun.

Maybe a function is returning something weird.

Maybe the app works locally and breaks the second you deploy it.

Maybe a library is doing something that makes absolutely no sense based on the docs.

So you start poking around.

Check the logs.

Print some values.

Read the error again.

Actually read the error this time instead of immediately deciding what you think it means.

Look at the data.

Check the docs.

Search GitHub issues.

Change one thing.

Run it again.

Break something else.

Undo that.

Eventually you start collecting enough little pieces that the problem stops feeling like one giant mystery.

Debugging is basically narrowing things down

Usually the first version of the problem is:

"Why the hell isn't this working?"

Which is not exactly actionable.

So you make the question smaller.

Is this function actually running?

Is the request being sent?

Did the server get it?

Is the data shaped the way I think it is?

Did this value become undefined five steps earlier?

Am I even looking in the right place?

Is this actually my bug, or am I misunderstanding how the library works?

Every answer knocks out a few possibilities.

Then eventually you're not debugging "the app."

You're debugging one function.

Then one condition.

Then one stupid value.

And suddenly there it is.

Some tiny ridiculous thing that caused all of it.

Knowing what to search for matters more than I realized

Searching for technical answers is its own skill.

Sometimes you can paste an error message into Google and get the exact answer in thirty seconds.

Sometimes the error is basically useless.

Sometimes the answer depends on your operating system, browser, package version, GPU, runtime, build tool, phase of the moon, whatever.

The better you get at figuring out what part of the problem actually matters, the better your searches get.

That was a big shift for me.

Instead of searching:

"Why is this broken?"

You start searching something much more specific.

And suddenly you stop finding ten pages about completely unrelated problems that happen to contain the same error message.

Docs help, but they're not always the whole story

I probably read documentation more now than I did when I was first learning.

Not because I've become some kind of responsible documentation-reading adult.

Usually because something has gone wrong.

Sometimes the docs give you the answer immediately.

Sometimes they give you enough information to realize you've been thinking about the problem wrong.

Sometimes they're outdated.

Sometimes the answer is buried in a GitHub issue where somebody casually mentions:

"Yeah, this doesn't work when that option is enabled."

Ah.

Cool.

Would have loved to know that an hour ago.

And sometimes I end up reading the source code because at a certain point I just want to know what the damn thing is actually doing.

You don't have to understand the entire library.

Sometimes you just need to follow one function far enough to answer one question.

I think beginners get the wrong idea about experienced developers

When you're new, it's really easy to think experienced developers just know everything.

They look at a problem and immediately understand it.

They know which function to use.

They remember every command.

They never have to search anything.

Meanwhile you're sitting there thinking, "Why do I have to look up the same thing for the fourth time?"

But I don't think that's really what experience looks like.

A lot of it seems more like being better at getting unstuck.

Knowing where to look.

Knowing what information matters.

Knowing how to make a big confusing problem smaller.

Knowing when your assumption is probably wrong.

And being willing to keep digging instead of staring at the code hoping it suddenly explains itself.

AI didn't really remove this part

AI definitely makes investigating things faster.

I use it constantly.

It can explain a weird error.

Help trace through unfamiliar code.

Suggest what to check next.

Point out something obvious that I've somehow looked directly at six times without seeing.

But it can also be wrong.

Sometimes very confidently wrong.

It can give you an answer for the wrong version of a library.

Invent an API.

Miss the actual cause.

Fix the symptom and leave the underlying problem sitting there waiting for you.

So I don't think AI replaced the investigation part.

It just became another thing I use while investigating.

A very useful thing.

But still not something I trust blindly.

I think this might be one of the biggest programming skills

You're never going to know everything.

There is always going to be another library, another framework, another weird edge case, another error message you've never seen before.

And honestly, that used to bother me more than it does now.

Because I don't think the goal is to know everything anymore.

It's being able to hit something you don't understand and think:

"Okay. I don't know what's happening yet. But I can probably figure it out."

Then you start narrowing it down.

Check assumptions.

Collect clues.

Test things.

Read.

Search.

Break stuff on purpose sometimes.

And eventually the weird thing stops being weird.

At least until the next weird thing.

Which is apparently most of programming.

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

A fast web interface for extracting the main content from web pages and HTML into clean Markdown.

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.