I love RSS feeds. I have a reader on my phone (Feeder) and one on my laptop (NetNewsWire). I find it the perfect way to keep up with my blogroll reading list. Imagine my horror, then, when I discovered that my own blog had the RSS feed turned off. 😱 It took a while to get the feed icon and the inline images to show up properly, but with the help of my AI sidekick we eventually figured it out.

My own feeds

My site doesn’t surface the feed variety very well yet, so here’s the list:

Feeds I follow

In case you’re wondering what my feed looks like, here it is:

You may not care for those site designs, but that’s not the point. The point is that they don’t look like so many other generated sites and impeccable did achieve the looks I was after.

From Impeccable.stlye:

Impeccable strips the slop from AI-generated interfaces, gives you precise commands to steer, and iterates visual variants live in your product. Then the dice: pushed out of distribution, your model designs ambitious visual worlds it could never reach alone.

Recommended.

The debate about how much credit to give AI tools for their contributions to software development has been going on for a while now. I only recently, however, became aware of how academic publishers have been handling this issue in the context of research papers.

A number of academic publishers have policies stating that 1) use of AI tools must be disclosed, and 2) AI tools cannot be listed as authors. Here’s an example of the latter from Elsevier Books:

Authors should not list generative AI and AI-assisted technologies as an author or co-author, nor cite AI as an author. Authorship implies responsibilities and tasks that can only be attributed to and performed by humans…[1]

There are good arguments on both sides of the debate, but I tend to agree with the spirit of this policy and would extend it to software development as well.

If I submit code, I am responsible for that code. Full stop. The AI is not an author, it’s not a co-author, and it doesn’t get a byline. I don’t want to be able to say “well, the AI wrote that part, so it’s not really my fault if it has a bug.” If I use an AI tool to generate code, I am responsible for reviewing that code, making sure it meets the coding standards, and being able to defend and explain it to my teammates. If I vibe code a commit and send it off to be reviewed by my team, I am now shifting all of the responsibility for code quality onto them. That creates cognitive debt and burns trust.

At the same time, I think it’s important to be transparent about the use of AI tools. It’s not something to be ashamed of or hide, any more than I’d hide the fact that I used a code generator or a linter. These days it’s a good bet that AI is involved at some point, and I honestly may forget to point that out every time. Maybe I should do better in that area, but I don’t want to pedantic about it. I just want to make sure that when I do use AI, I’m taking responsibility for the output.

Used well, AI can clear space for better judgment. Used poorly, it can move more work onto others and/or create more cognitive debt.

Note: I usually have an AI look over my writing or even brainstorm the initial draft, but I didn’t do that this time. However, I will admit that Copilot was on in my editor and I spent a lot of time dismissing bad auto-complete suggestions before I finally turned it off. Okay, hopefully that’s enough transparency for this short post.

[1] https://libguides.tamusa.edu/AI_for_lit_research/journal_requirements

I was excited to try the new Cowork feature in Claude. The idea of a persistent, safe workspace where I can collaborate with an AI over time sounded great. I set up my space, pointed it at my screenshots directory, and asked Claude to help me organize it. It actually worked pretty well. Claude understood my files, suggested a new folder structure, and moved everything around for me. Cool. What next?

I noticed a sample task offering to help build a background creator based on biological principles. That sounded fun, so I gave it a shot. Claude got started and then… nothing. Some of the presets just didn’t work at all.

I asked Claude to fix it. It tried, and failed, repeatedly. The problem was it had no way to see what the output actually looked like, so I tried to give it a tool to help. Unfortunately, it couldn’t install the tool — no network access — and it also couldn’t reach a locally installed version outside the Cowork VM.

The pattern that emerged was pretty clear. For tasks where Claude can get feedback from the files in its workspace, it works pretty well. For tasks like the background creator, where it needs to see rendered output, it falls flat. I get the safety rationale behind the sandboxing, but I hope they can improve the tooling enough to at least make their own examples work.

The script runs daily with cron and has a configuration file that lets me specify multiple URLs to watch and a regex pattern to look for. When it finds a match, it sends a system nofification to my desktop. A gist with the generated code is available here.

So today, based on advice from Jesse Vincent I upgraded to the Pro plan at $20/month and if I run into limits quickly for some reason, I plan to switch to z.ai’s models which are nearly as capable and much, much cheaper.

Today’s session with Claude went really well, but we’ll continue to see how it goes.

I recently used Jesse’s superpowers plugin to help me add a csv export feature to Stormoji. I started with the brainstorm superpower and followed it’s suggested courses of action all the way to the end. It worked great tech-wise and the results looked good. In the end, I only tweaked the icon appearance a bit. However, this simple feature took 1h 47m (wall time) to implement and cost $7.66. This is not ideal for tiny side project features. I asked Claude what drove the costs and what could be done to reduce them. Here is the response I got:

> /cost 
  ⎿  Total cost:            $7.66
     Total duration (API):  41m 40s
     Total duration (wall): 1h 47m 6s
     Total code changes:    3574 lines added, 19 lines removed
     Usage by model:
             claude-haiku:  516 input, 142 output, 0 cache read, 0 cache write ($0.0012)
            claude-sonnet:  2.1k input, 115.1k output, 9.6m cache read, 813.7k cache write ($7.66)

> Wow. Using the superpowers plugin seem to produce a great result but the cost
  and time were much more than expected. Were there parts of that process that
  might have been excessive or could be pared back? 

⏺ Great question! Looking at the process, there were definitely areas where the
  superpowers workflow was excessive for a feature of this size and complexity.
  Let me break down what contributed to the high cost:

  What Drove the Cost/Time

  Subagent invocations: ~12-13 separate Claude instances
  - 6 implementation subagents (one per task)
  - 5-6 code review subagents (after tasks 1-4, plus final review)
  - 1 fix subagent (CSS issues)

  Each subagent needs to read context, produce comprehensive reports, which
  adds up quickly.

  What Was Excessive for This Feature

  1. Code Reviews After Every Single Task

  - Reviewed HTML changes alone, then CSS alone, then JS alone
  - For straightforward changes like these, could have reviewed HTML+CSS+JS together
  - Savings potential: ~3 fewer subagent invocations, ~$2-3

  2. Overly Detailed Implementation Plan

  - 546 lines with exact code examples for every step
  - For a simple CRUD-like feature, a high-level outline would suffice
  - Savings potential: 10-15 minutes, minor cost reduction

  3. Task 5 (Manual Testing) Used a Subagent

  - Subagent created test artifacts but couldn't actually test in browser
  - A simple checklist would have been more appropriate
  - Savings potential: 1 subagent, ~$0.50

  4. Separate Subagents for Simple Tasks

  - Task 6 (update CLAUDE.md) - straightforward documentation
  - Task 7 (prepare for merge) - just git commands
  - These could have been done directly
  - Savings potential: 2 subagents, ~$1

  5. Brainstorming Asked Questions One-by-One

  - 5 separate question rounds added interaction overhead
  - Could have asked 2-3 questions simultaneously
  - Savings potential: 5-10 minutes

  6. Final Comprehensive Code Review

  - Added after all task-level reviews
  - Either do incremental reviews OR final review, not both
  - Savings potential: 1 subagent, ~$1

  More Efficient Approach for This Feature

  Total cost could have been ~$2-3 instead of $7.66:

  1. Quick brainstorming (2-3 questions at once)
     → 5 minutes, $0.20

  2. Lightweight design doc (outline, not full plan)
     → 10 minutes, $0.30

  3. Implement in 2-3 chunks instead of 7 tasks:
     - Chunk 1: HTML + CSS (menu structure + styling)
     - Chunk 2: JavaScript (menu logic + CSV export)
     - Chunk 3: Documentation + testing
     → 3 subagents instead of 6, $1.50

  4. ONE code review at the end
     → 1 subagent, $0.80

  5. Manual testing checklist (no subagent)
     → 5 minutes, $0.20

  Total: ~$3, 30-45 minutes

  When Is the Full Superpowers Workflow Worth It?

  The rigorous approach is justified for:
  - Large features (1000+ lines of code)
  - Complex architecture (multiple services, new patterns)
  - High-risk changes (authentication, payments, data migration)
  - Team codebases where reviews catch style/pattern issues
  - Learning mode when you want to understand best practices

  For Simple Features Like This

  You could have said:
  "I want CSV export. Skip the detailed planning, just implement
  it in 2-3 chunks with one review at the end."

  Or even more direct:
  "Implement CSV export with menu dropdown. Review when done."

  This would give you 80% of the quality at 30% of the cost.

  The Upside

  Despite the cost, you got:
  - ✅ Zero bugs (5-star production ready)
  - ✅ Comprehensive documentation
  - ✅ RFC 4180 compliant CSV
  - ✅ Full test coverage
  - ✅ Learning the complete process

  Think of it as paying for a tutorial on how to build features with extreme
  rigor. Now you know what "perfect" looks like, and you can dial back the rigor
  for simpler work.

  Recommendation: For features under 500 lines, skip
  subagent-driven-development and just implement directly with one final review.

Yeah, okay. Lesson learned I guess. Don’t use a cannon when a flyswatter will do.

For anyone interested, the github repo for Stormoji is here.

Most recently, I have been testing some Claude Code workflows while working on a grid game project. Unfortunately, the experiments did not always go well and the code is in a bit of a state. When and if I get it cleaned up and working again, I’ll post it here.

I’m trying to get from Apple to Zebra in a traditional, deterministic way, but there’s a lot of fiddly edge cases and conditionals because neither the Apple nor the process is as well-defined as we’d like (first picture). With agents, we give them each a job and maybe a few tools, put them all in a big circus tent, tell them to work together, and toss in the Apple (second picture). We wait a few minutes and, poof, out pops a Zebra. And, very rarely, a Gnu. Okay, it’s slightly more complicated, but it helps me if I can reduce it to emojis and circus tents.