enumerator.dev

Post

Wed, 26 Nov 2025 03:08:00 +0000

Safe Claude Code Settings

Wed, 26 Nov 2025 03:08:00 +0000

Here are a few commands I have in my Claude Code deny-list to prevent bad things from happening. I wish Claude shipped with these by default!

The following commands disallow Claude from force pushing and skipping pre-commit hooks.

{
  "permissions": {
    "deny": [
      "Bash(git push -f)",
      "Bash(git push --force)",
      "Bash(git commit:*-n:*)",
      "Bash(git commit:*--no-verify:*)"
    ]
  }
}

To be extra careful, I also have a pretty thorough gitignore that I install globally which includes common patterns for secret credentials.

*.key
*.pem
*.p12
*.pfx
*.cer
*.crt
**/secrets/**
**/credentials/**
.env
.env.*
**/config/secrets.toml

Planning, Building, Reviewing: Why The JJ Workflow Works Better Than Git

Sat, 08 Nov 2025 14:04:00 +0000

After a week of experimenting with using git and jj to plan and build, I’ve landed on jj as the winner.

Rebasing Kills the Git Workflow

Automatic rebases are the winning feature here. When I tell Claude to update a change, it will automatically rebase all its descendants. This is a MASSIVE time saver for both me and Claude.

When I use empty commits in git, Claude performs the same until it has to start editing code. Then things get messy.

Rebasing in git is almost always painful. Claude can clunk through the rebase workflow faster than I can, but it still gets lost at times.

My Current Workflow

Here is the CLAUDE.md that’s been working well for me lately. It teaches Claude how to use the jj workflow.

1. Start plan mode

I start a new session in plan mode and give Claude Code all the information I can think of. I describe what I need, reference files, and explain the outcome.

2. Iterate on the Plan

I almost always refine the plan with Claude. I verify the code samples it provides and verify that the implementation meets my expectations.

3. Turn the plan into commits

I’m still in plan mode, and I ask Claude to break the plan down into empty jj changes.

4. Review the `jj` Plan

This is key. I am still in plan mode here, and I need to ensure the steps Claude has planned make sense and have no gotchas. Iterate on this step.

5. Auto-accept edits

Finally, I let Claude rip. Once the plan looks good, I auto-accept edits and allow Claude to use jj commands as needed.

6. Do Something Else

While I refined this workflow, I watched Claude work to keep it on track and assess whether we had come up with a good enough plan. But I’ve found that with a focused plan, Claude can work away just fine.

7. Code review with Claude

I use a code-review command to kick off code review with Claude. We walk through one change at a time. I sometimes make manual edits, other times I get Claude to refactor things.

8. Use `gh` to create PRs

Depending on the scope of the change, I’ll make a PR stack and ask Claude to manage the stack for me, or I’ll create a single PR with a linear history.

9. Code Review Again

Yes, I do code review again. The code is mine, after all. I go through the GitHub UI and review the code myself. If I want Claude to make a change, I ask it to edit the jj change set where the code was introduced.

The result is a clean commit history that implements a feature one change set at a time.

Why JJ Works So Well

In steps 7 and 9 above, I review code and often want to make changes to specific change sets. In git, this would involve git rebase -i, picking the commits to edit, making the edits, then git rebase --continue. In jj, all that is done for you.

Two Takeaways

Agent or not. These two things are true in software development. Planning and reviewing are the most critical steps.

Plan, Plan, Plan Again

Working with an AI agent emphasizes the importance of planning. Planning your work has always been essential for successful feature development. Now with agents, we have really fast researchers who can help us refine a plan.

The more time you put into planning, the more successful your work will be, regardless of whether you’re using an agent.

Review, Review, Review Again

Like planning, reviewing your work ensures it is accurate, bug-free, and performant. This is YOUR work after all. Even if an agent wrote it, you own the code.

Use Git to Plan and Build With Claude

Sat, 01 Nov 2025 12:57:00 +0000

When I shared my new JJ and Claude workflow last week, I wondered whether JJ was too much friction for developers. It requires learning a new version-control tool in addition to learning to use Claude. I had an idea in the back of my mind to use plain git for this.

And then Claude did it for me!

Towards the end of the week, I was working in a codebase where I hadn’t initialized JJ yet. Claude tried to use the JJ workflow, saw that JJ wasn’t initialized, and started implementing the same workflow using plain old git. We were working on a relatively simple feature, and Claude created planning commits and implemented it.

You Don’t Need to Learn a New Tool

JJ is a good workflow if you need a graph of related features. I find this happens most often when I’m building a new feature or working in an old codebase where I find bugs.

Most day-to-day work can be done in linear branches. Plus, everyone knows git already.

This morning, I worked with Claude to refine a CLAUDE.md that uses plain old git to plan and build features. This looks really promising so far.

Why is Claude Code Different from Cursor if they Both Use Claude?

Mon, 27 Oct 2025 13:30:00 +0000

I get this question often. Here’s how the story goes:

Someone complains that AI is bad because it just does a bunch of stuff for you really quickly and does it wrong.
I ask what tools they’re using, and they say they’re using Cursor because it’s the most familiar IDE for them.
I ask them if they start a new chat for each feature, and the answer is usually “no” because this isn’t intuitive.
I suggest they try a different agent — Claude Code is my preferred tool — and they say, “It’s all Claude, though, how would that be different?”

Few developers have had time to learn these tools. They’ve been forced to use them as productivity enhancers, without the time to learn.

I have seen performance gains in my work. I shipped the first version of Uplift in a few hours! But I’ve also taken an enormous amount of time learning, training others, and trying terrible AI tools.

I work with many developers who use Cursor daily. This is good! Cursor seems to work better with their workflow. While I have a distaste for Cursor, others find it useful. Agents, like IDEs, are a preference, after all.

Going faster means slowing down to learn your tools. Changing IDEs or using a CLI is a BIG workflow change for most people, and if Cursor is your first brush with AI, I do not blame you for thinking it’s a waste of time.

In this post, I want to demystify “It’s all Claude in the end” to help people understand why some agents are good and others are frustrating.

Defining Terms

Let’s start with defining three standard terms. I’m going to use the common nomenclature in this post, but it’s important to note that their meanings are often blended in different contexts.

AI: These two small letters carry the weight of “agents”, “LLMs”, “automation”, “autocomplete”, and everything else. When someone says “AI,” they mean any one of these. In this post, “AI” refers to coding agents that have some autonomy in their work.
Agent: This term comes up in phrases like “agentic workflow” or “coding agent”. The agent is the engine of AI coding. The agent connects the user’s input to the local environment’s context (files, available tools) and provides it to the LLM. In this post, “agent” is a loop that takes user input, provides context to the LLM, and calls tools.
LLM: We all know LLMs like Claude, ChatGPT, or Codex. “LLM” stands for “large language model”. “LLM” is a misnomer. Many of these models accept multiple types of input and produce various outputs. A more accurate name is “Large Multimodal Model”. The models we use for coding are autoregressive, meaning they predict the following sequence based on previous context. For consistency with vernacular usage, I’ll refer to them as LLMs.

AI: Distinguishing the Agent from the LLM

In the diagram below, the “environment” is your computer and the tools you let your agent use. If you’ve given your agent access to find, for example, it will show up in the list. Depending on the agent, it might also collect some project stats to send to the LLM.

When you have a CLAUDE.md or AGENTS.md file, this will get sent with the context, too.

sequenceDiagram
    participant U as User
    participant AS as Agent
    participant E as Environment
    participant LLM as LLM (API)
    
    U->>AS: "Fix bug in auth.js"
    
    box rgba(0,0,0,0.05) Your Computer
      participant AS as Agent
      participant E as Environment
    end
    
    Note over AS,E: Agent Orchestration Layer<br/>Manages loop, provides tools, maintains context
    loop Until task complete
        AS->>LLM: Context + Available Tools + User Request
        Note over LLM: Parse intent<br/>Reason about next step<br/>Choose tool to call
        LLM->>AS: Tool call decision
        AS->>E: Execute tool (view/edit/bash)
        E->>AS: Return result
        AS->>AS: Append result to context
    end
    
    AS->>U: "Fixed: added null check<br/>Tests passing ✓"
    
    Note over U,E: Different agents = different tools, autonomy levels,<br/>and orchestration strategies (even with same LLM)

Notice that most of the work actually happens on your own machine. The agent interacts with your environment to collect information to send to the LLM, makes edits, and reports back.

An agent is not intelligent. This is really important to understand. An agent without an LLM is a loop with conditionals. Much like the code we write every day.

Adding an LLM into the loop gives the agent the ability to reason and make decisions beyond pattern matching.

Every agentic coding company will write its agent differently. The tools available, the actions the agent takes, and the system prompts it sends to the LLM are the product the company builds.

Cursor is different from Claude Code because Cursor’s agent is different, even if they both use a Claude model to reason and make decisions.

The LLM Reads the Entire Conversation Every Time

The LLM is an outside actor. If you are using Cursor or Claude code, every message you send and every agent loop involves API calls to the LLM provider you are using. If you are running a model locally, the model is separate from your agent system.

Every time the agent calls the LLM API, it is the first time the LLM has ever seen your message. The LLM reads THE WHOLE MESSAGE THREAD EVERY TIME.

That’s right. Do you have a long-running conversation where you’ve worked on three or four different tasks? When you ask the agent a question, the LLM reads the whole message thread and can easily confuse instructions you previously gave it with your current task.

In my experience, this is the most common reason agentic coding starts as highly accurate and quickly degrades into chaos.

How do you fix this? Start a new chat. It’s that simple. Start a new chat for every task you work on.

Warp has a great feature in its agent that detects a change in subject and suggests starting a new chat. I wish other agents would do that too.

This is an important distinction to make. The agent’s capabilities and system prompt affect how it works. Cursor tends to be very ambitious, which means the context window can quickly become bloated with failed attempts and misdirection.

More cautious agents will confirm actions with the user and detect when the conversation is drifting, keeping the context focused on the task at hand.

No agent is perfect, which is why I’ve explored using the Jujutsu VCS to give the agent memory between sessions and narrow the context the LLM receives on each turn.

sequenceDiagram
    participant CC as Agent
    participant LLM as LLM (API)
    
    box rgba(0,0,0,0.05) Your Computer

    end
    
    Note over CC: Context:<br/>[System prompt]
    
    CC->>LLM: [System prompt, User: "Fix bug"]
    LLM->>CC: "I'll check the file"
    Note over CC: Context:<br/>[System, User,<br/>Assistant]
    
    CC->>LLM: [System, User, Assistant, Tool: file contents]
    LLM->>CC: "I'll edit line 42"
    Note over CC: Context:<br/>[System, User,<br/>Asst, Tool,<br/>Asst]
    
    CC->>LLM: [System, User, Asst, Tool, Asst, Tool: edit result]
    LLM->>CC: "Fixed! Tests passing"
    Note over CC: Context:<br/>[System, User,<br/>Asst, Tool,<br/>Asst, Tool,<br/>Asst]
    
    Note over CC,LLM: Each API call sends the ENTIRE context<br/>Context grows with every message<br/>and tool result.

Key Principles

The diagram below illustrates the capabilities of a coding agent. The Agent Loop is the central capability. This is the part that each company builds (Claude Code, Cursor, Zed, Warp, etc.)

The LLM is separate from the agent loop. Many different agents can use the same LLM, and most agents let you pick which LLM to interact with.

flowchart LR    
    AgentLoop[Agent Loop] --> LLM[Calls LLM]
    
    AgentLoop --> AL1[Stateful Orchestration]
    AgentLoop --> AL2[Maintains state and history]
    AgentLoop --> AL3[Executes tools]
    AgentLoop --> AL4[Manages context window]
    
    LLM --> L1[Stateless Reasoning]
    LLM --> L2[Processes full context each turn]
    LLM --> L3[Selects tools & plans actions]
    LLM --> L4[No memory between calls]

Conclusion

Try lots of agents! I know this can feel slow and frustrating, but when you do this, you are learning how different agents work. You are learning the new tools you can use in your job.

Take 15 minutes each day to build a small project with an agent. Pick something simple, like a to-do list app. Build the same app with different agents and see how they perform.

In the future, I think we will standardize on a handful of coding agents that developers can pick to work with their preferred workflow, much as we have standardized on a handful of IDEs for different use cases.

I prefer Claude Code for its built-in protections and customization options.

If you want an agent integrated in your IDE, you can run /ide to hook Claude Code up to VSCode. It’s not as deeply integrated as Cursor is, but it works okay. Another good option is to try out Zed, their agent has similar capabilities to Claude Code and is built into the IDE.

I’ve tried Warp a few times, and the deep integration of chat, CLI, and editing is promising to me, but sometimes confusing.

In the end, Vim is my home row, so the setup that works for me is Claude Code in one pane and Vim in the other.

Use Jujutsu to Plan and Build with Claude

Sun, 26 Oct 2025 12:58:00 +0000

This week, I read about Steve Yegge’s Beads.

I was skeptical.

He writes like someone trying to prompt inject your LLM. But he’s always written that way.

I tried beads, and it was pretty good. I wrote all of uplift using beads.

But it was also pretty buggy. I noticed I had multiple bd daemons running and checking git status. Not cool.

Jujutsu

I shared beads with Nate Smith, and he said, “You could do that with Jujutsu.”

We both tried it and it rocks.

Here is my current CLAUDE.md , which teaches Claude to use Jujutsu to plan and track issue progress.

Jujutsu is a Git-compatible version control system. The graph foundation of Jujutsu makes it perfect for this kind of work because Claude can add empty TODO commits along the way and connect them to one or more tasks that also need to be done.

Here is the gist of the instructions Claude gets:

Planning Best Practices

Create Descriptive Empty Commits:

Each commit description should fully explain what needs to be done

Include acceptance criteria in the description

Note any dependencies or prerequisites

Use clear, actionable language

The steps for you are:

Enter plan mode and build a plan with Claude.
When you’re ready, tell Claude to make empty commits for each step in the plan.
Tell Claude to work through one commit at a time until it is done.
If at any point Claude struggles or decides to compact memory. Kill your session and start a new one with “We are in the middle of working through a to-do list created in jj. Find the task you were in the middle of and finish it, then move on to the next task until you are done.

On Friday, I refactored a small Ruby library with Claude and Jujutsu, and it was really nice. I knew what I wanted the end state to look like and described that to Claude. Claude then made a plan with detailed acceptance criteria for 12 distinct steps. Once I approved, Claude turned the plan into jj commits and worked through them.

Around step 7, Claude slowed down and suggested that steps 7 through 12 were tightly coupled. I ran /clear to start a new session and pick up where we left off. Claude still saw that steps 7 through 12 were coupled, but no longer tried to implement them all at once. It methodically worked through the steps.

At the end, Claude suggested a five-PR stack so developers could review PRs implementing the requirement in separate logical steps.

Why This Works (My Theory)

Steve Yegge is right about why this works, but more than a little off base about needing a whole buggy go program to do it.

Claude works better with this workflow because the context you send is focused and clear. A big old markdown doc is fine, but Claude has to read the whole thing multiple times to find the next task.

With the Jujutsu workflow, Claude can read a summary of what is done with jj log and pick up the following task with jj edit

The LLM on the other side of the Claude agent receives a more focused context. As the conversation continues, the thread narrows to specific tasks.

In past work, when I’ve used a plan.md or Claude’s default todo list, Claude struggles because it reads the entire plan every time, multiple times, since the whole chat is sent to the LLM with each message. This means the context gets bloated with planning and loses focus on accomplishing tasks.

With the Jujutsu workflow, planning shows up exactly once in the context. Then jj log shows incremental progress.

I Want This

It’s good! You should try it. Get Jujutsu set up and copy my CLAUDE.md.

If you don’t know how to use Jujutsu, Claude can learn by using jj help.

The most important thing to remember is: if you think the agent is lost, you’re probably lost too!

You can /clear your session, take a break, and start fresh. Claude will pick up where it left off because it knows to use jj log to find the next task.

🎈 Uplift

Mon, 20 Oct 2025 18:59:00 +0000

I recently read Max Stoiber’s post on Gratitude Circles and was inspired to build an app for it! Why an app? First, you can’t see handwriting. I am super embarrassed by my clumsy handwriting. Typing though, thank gosh for auto-correct.

🎈 Try Uplift!

Uplift is an app for running Gratitude Circles. It keeps author names anonymous to emphasize that the whole group lifts one another up. Give it a whirl and let me know what you think.

Navigating to Get Things Done

Tue, 07 Oct 2025 11:55:00 +0000

In engineering culture, we sometimes refer to managers and Staff Engineers as “shit umbrellas” for their team. I’ve never liked this idea. It paints a picture that individual leaders create a peaceful oasis for their team while chaos reigns outside.

Sounds nice to be one of those engineers! Not a care in the world. Just flow. It must feel special to have a shit umbrella manager.

But the shit umbrella is a lie.

If every manager believes they create a sphere of deep focus and flow, where is all the shit coming from? One team’s flow is another team’s dysfunction.

The “shit umbrella” metaphor entrenches an “us versus them” culture and isolates individual teams from the rest of the company. It pits leaders against lowly engineers and ensures communication starts with arguments rather than curiosity.

Be a Navigator

Effective engineers engage across an organization and know how to navigate its complexities. Effective engineers recognize that people are complex, have diverse emotions, make mistakes, and struggle to communicate effectively. And that’s okay because we are all human.

Teams need to understand how an organization operates to be effective engineers, and people leaders are responsible for helping teams focus, navigate complexities, and achieve their goals.

Being a navigator for a team means helping them find their way and letting them do the work to reach their destination by helping the team understand who is who in the organization and what these individuals care about. Working with the complexities in an org is about curiosity and learning.

Helping your team navigate an organization begins with trust and focus: trust that your team can handle what comes their way and that the people they work with understand their part of the organization better than you do.

In Matheus Lima’s recent post on politics, he says:

The engineers who refuse to engage with politics often complain that their companies make bad technical decisions. But they’re not willing to do what it takes to influence those decisions. They want a world where technical merit alone determines outcomes. That world doesn’t exist and never has.

The same goes for managers who choose to be shit umbrellas. Protecting your team from politics isolates them from the business and creates an insular culture where “everything could be better if…” while not improving anything.

Protecting Your Team Protects Dysfunction

When people leaders try to protect their team from organizational chaos, they are unintentionally ensuring the dysfunction stays in place.

The purported “shit” that a shit umbrella protects people from is just people being human. To quote Will Larson:

[T]he reality is that executives are human. You’ll make much more progress by focusing on improving how you communicate with them than by blaming them for their deficiencies.

Larson’s comments apply to anyone you work with in your org. Improving your communication skills ensures that you approach conversations with a clear understanding of the core business needs.

Blaming others for their deficiencies ensures organizational dysfunction is the norm and prevents the business from growing.

People at all levels of an organization need to make mistakes and learn from them. The shit-umbrella culture breaks this feedback cycle. It allows new leaders to fail without receiving feedback and support from their peers, isolates senior leaders from the teams they need to work with, and isolates your team from the business.

Focus

People who talk about being a shit umbrella want to maintain their team’s focus and limit distractions. It comes from a well-meaning place, but creates a culture of isolation instead of focus.

As a navigator, show your team what to focus on and how to reach their destination. Trust them to raise concerns when things get hard, and trust your peers on other teams to support their work.

Provide your team with a map and help them to focus on the business impact of their work, so that they can approach complex parts of the org with curiosity and an ambition to build great things for the business.

willow.camp Updates - October 7, 2025

Tue, 07 Oct 2025 11:25:05 +0000

I’ve spent most of my willow.camp work on finding a new backend language. But I’ve still updated the Rails app! Here’s what’s changed since my last update.

Moved HTML storage out of the post table and into ActionText. It was this deep dive that made me question using Rails. I went down a long rabbit hole, finding a good text editor and then realized this work felt more like building Ikea furniture than I wanted. I’m more interested in having access to the application end-to-end than plugging parts together. Anyway, in the meantime, your posts are now stored in an ActionText table.
Prevented email enumeration attacks by returning an ambiguous error on sign-up. This is my pet peeve with Devise, and I am a bit embarrassed I let this live in production for so long. Previously, the sign-up form would indicate if an email address had already been taken. Since I can’t guarantee people use unique passwords, this means an attacker could use a leaked email/password list to access accounts that use poor password hygiene. No more! I’ve done my best to give ambiguous, helpful messages when something is wrong on the signup page.
Updated dependencies! A whole bunch of Ruby Gems and npm packages got minor version bumps.
Fixed CI errors with vips. This is minor but tests were failing in CI because vips wasn’t installed on the machine.
Cleaned up the Hanami directory. There was a day when I was convinced Hanami was the next framework for willow.camp, and I started a migration in its own directory.
Cleaned up image things I was trying out with images and media handling.

willow.camp: Next

Tue, 07 Oct 2025 01:26:24 +0000

I have spent the past few weeks figuring out the future of willow.camp.

It turns out I love making it, and I love that a handful of people are using it.

I built willow.camp in Rails because I could prototype quickly without having to think about things like auth, logging, or building forms. Rails was great for that.

Now that I have a version of willow.camp I like, I want to be more hands-on with what I’m building, and I find that I’ve spent more time working around the framework and various libraries than I have creating the things I want.

Learning other people’s code isn’t particularly enjoyable.

Aside: Rails and Ruby have also had a public meltdown lately, and I’m tired of feeling like a puny developer watching giants fight and say evil things.

Finding the Next Tech Stack

This was a long journey.

I started with Hanami. It is still Ruby, and the community is much friendlier. Hanami didn’t work for me. It felt like I kept bumping up against the framework, telling me I was doing it wrong. The community is friendly, but the framework is very rigid about “the right way” of doing things.

Then I hopped over to Crystal and tried Lucky, Amber, and Marten. They were all okay to work with, but didn’t strike my fancy.

Lucky was the easiest to get going. I had the data models for willow.camp up and running with a couple of rough-looking views in a few hours.

Marten’s “apps” are nice to work with (think slices in Hanami). But the framework doesn’t natively support subdomain routing, and I didn’t want to fight that design.

Crystal is also very slow to compile. A straightforward Lucky app took over 30 seconds on my M1 to compile! Who has that kind of time when you need to compile multiple times an hour?

Finally, the community. The Lucky devs are really active, which is nice. But Crystal itself seems to have a fragmented community. When I interacted with people, I didn’t really see someone like me in any of the channels.

What I Want in A Language and Framework

An active, welcoming community that builds trust.
Helpful error messages from the language.
Good documentation.

That’s about it. I don’t need huge framework features. I need a language with a helpful design and friendly people.

The Next willow.camp Tech Stack

Once I realized that I valued community and friendly docs more than I valued framework features, I found Gleam.

Backend:
- Gleam with the Wisp Framework on a Postgres database.
Frontend:
- So far, I plan to use Nakai for server-side rendered HTML and HTMX or a similar library for interactive components.

Oh, and I’ve already written a Gleam package! willow.camp needs an accurate domain name parser, so I wrote psl to parse domains using the Public Suffix List.

The Next willow.camp Features

I have a long list of features I want to build for willow.camp, and it’s these features that inspired me to change the language and framework.

A WYSYIG editor that supports markdown. This is the best of both worlds and opens willow.camp up to non-technical writers.
An image library via openverse with an image editor UI.
Email newsletters! I’m excited about this one. You will be able to collect a list of subscribers and send blog posts to your distribution list.
ATProto and ActivityPub support.
An RSS reader so you can follow blogs without a social profile.
Private bookmarks with notes and highlights.

willow.camp Updates September 21, 2025

Sun, 21 Sep 2025 12:58:00 +0000

Quiet on the updates this week. I could rename “Major Features” to “Major Worries” because I’ve spent more time worrying about how images should work than testing them with real users!

I enabled image uploads on the marksmith text editor this week, and a few people tested it out for me. Turns out marksmith doesn’t work how I thought it would with images. Image uploads are still enabled, but I’m going back to the drawing board with the editor UI and media management.

Major Features

Image storage and processing functionality with Active Storage integration, direct uploads, and automatic image processing
I heard you like willow.camp. How about deleting willow.camp? You can now delete your blog and account if you’d like. This will delete all your data and is irreversible. The option is there if you need it.

Improvements

Enhanced navigation to only show blog title or subdomain in menu
Updated testing configuration for quieter pre-commit output
Removed social_share_image functionality

Security & Dependencies

Updated JavaScript dependencies
Updated Ruby gem dependencies
Added new license file

How Much does it Cost to Run willow.camp?

Sun, 21 Sep 2025 12:21:00 +0000

I recently enabled image uploads in the marksmith text editor on willow.camp. I’ve been hesitant to add media management to willow.camp for two reasons: it is hard to get the user experience right, media management adds extra cost.

I am being cost-conscious on willow.camp because it doesn’t make any money. This is a passion project, and I’m having lots of fun doing it. But the more fun I have, the more it might cost.

It turns out adding storage is way cheaper than I thought. I would have to have a whole lot of media and a few really busy willow.camp sites to start getting charged more for data transfer fees.

I will eventually build a pricing plan for willow.camp to cover costs for active sites. In the meantime, if you want to support willow.camp, you can send me a tip on https://ko-fi.com/cassiascheffer.

Claude Code

I include Claude Code in here because it is part of my development process. I’m on the Max plan, and I use it enough that it pays off.

In the past 30 days, I’ve used CAD $188.49 of tokens, and I even took a week off in the woods.

I use Claude Code to scaffold ideas, experiment with features, and improve test coverage. I’ve been able to build willow.camp so quickly because Claude Code is pretty good at scaffolding a blog in Rails.

August Breakdown

service	fee (CAD)
DigitalOcean Droplet (1 vcpu, 1 gb memory)	$8.25
DigitalOcean Postgres ( 1gb ram, 10 gb disk)	$20.82
Hatchbox.io Deployments	$14.13
Claude Code Max	$158.2
Honeybadger Error Tracking	$0
Total	$201.40
Total without Claude Code	$43.20

September Estimate

Here is my estimate for September based on today’s exchange rate.

service	fee (CAD)
DigitalOcean Droplet (1 vCPU, 1 GB memory)	$8.26
DigitalOcean Postgres ( 1 GB RAM, 10 GB disk)	$20.87
DigitalOcean Spaces (half a month)	$3.44
Hatchbox.io Deployments	$14.13
Claude Code Max	$192.84
Honeybadger Error Tracking	$0
Total	$239.54
Total without Claude Code	$46.70

Photo by StellrWeb on Unsplash

Naming Things for What They Do

Tue, 09 Sep 2025 11:23:33 +0000

I just saw the Rails World announcement that flavorjones is working on ActiveRecord::Tenanted and all I can say is, “What a reasonable name!”

When I started willow.camp I chose not to use apartment partially because the name and the metaphor were too confusing. I didn’t like tho have to get used to the idea of requests taking “elevators” and all that. The “apartment” metaphor doesn’t work for databases even though “tenant” does.

Always choose descriptive names over clever ones. It doesn’t matter how well you think the metaphor fits; you’ll always end up with something confusing in the end.

willow.camp Updates September 7 2025

Mon, 08 Sep 2025 00:20:35 +0000

It’s been a busy month! I took some time off for a much-needed vacation and forgot to post about willow.camp. I’ve worked on some fun features in the past few weeks.

New Features

Favicons now use OpenMoji emojis! I think these are adorable icons. I have a few qualms with how they fit in the willow.camp design (they’re all a little bottom-heavy), but it’s not a deal breaker.
New favicon picker! You can now search for an emoji by name to pick for your blog.
Now you can have two blogs! You can click on the profile icon and add a second blog. I’m going to use this to document my garden and remind myself what I want to do next year.

I also fiddled around with auto-generating OG images for each blog. I wrote a script that uses your OpenMoji favicon and your blog’s colours to create an Open Graph image for your blog.

Here’s what the tiled image looks like for enumerator.dev.

Ultimately, the best approach for images is to enable users to upload them instead of doing some clever auto-generation. I’m going to put this on my project board and figure out how to do it. Since storage costs me, I might need to change the license on willow.camp and start charging for image uploads.

Here is the Claude-generated summary of the last few weeks.

Summary - August 17 - September 7, 2025

Major Features

Multi-Blog Support: Complete implementation of “Two Blogs per User” feature (#85) - Major architectural change allowing users to have multiple blogs instead of a single-tenant structure
OpenMoji Favicon System: Implemented comprehensive emoji favicon selector with search functionality using OpenMoji library (2d13fd2e)

Improvements

OG Image Generation: Added automated Open Graph image generation scripts (29ba2359, 290f2372)

willow.camp Updates August 16, 2025

Sat, 16 Aug 2025 12:32:00 +0000

It felt like a quiet week on willow.camp but somehow I still got lots done.

Aside from the release notes below, I’m focusing my energy on getting proper favicons for willow.camp blogs.

My first version of this will use OpenMoji emojis for favicons. I like their simple design principles and especially like that they are CC-BY-SA 4.0, similar to willow.camp’s source code.

Here’s how I think I’ll approach this:

Include OpenMoji assets in the willow.camp source code.
Use their source map to populate a choices.js dropdown on the settings page.
Then save the Unicode reference to the database and use that to fetch the correct favicon files when rendering a page.

OpenMoji provides pngs in two sizes, so I’ll need to resize them for the best cross-device compatibility.

Okay, on to this week’s summary!

Improvements

Migrated system tests from Selenium to Cuprite for better performance and reliability
Optimized ReservedWords with Set data structure for faster lookups
Added post-deploy script to send deploy messages to Discord

Security & Dependencies

Updated Rails from 8.0.2 to 8.0.2.1
Updated ActiveRecord from 8.0.2 to 8.0.2.1
Updated Pagy from 9.3.5 to 9.4.0
Updated solid_cable from 3.0.11 to 3.0.12
Updated Honeybadger from 6.0.4 to 6.0.5
Updated Jbuilder from 2.13.0 to 2.14.1
Updated CommonMarker from 2.3.1 to 2.3.2
Updated Lefthook from 1.12.2 to 1.12.3
Updated GitHub Actions dependencies (actions/checkout v4→v5, browser-actions/setup-chrome v1→v2)
Implemented subdomain validation and bot protection in Rack::Attack
Added user agent and IP logging to Honeybadger error context to better understand bot behaviour

Bug Fixes

Fixed deprecated :unprocessable_entity status code (replaced with :unprocessable_content)
Temporarily disabled auto-save functionality. This isn’t a bug fix. Sorry! I want to get to fixing this soon.
Remove social_share_image JavaScript and HTML. I am going to sit on this a bit. I want this to be rendered server-side instead of in the browser. Once I integrate OpenMoji, this will be much easier because I’ll have png assets available on the server.

End To End Tests with Minitest and Rails

Wed, 13 Aug 2025 22:27:26 +0000

willow.camp has a small system test suite that runs on CI. It used to use the out-of-the-box settings that come with Rails: Capybara, Selenium, etc.

I noticed a flaky test on CI, which launched a journey to replace Selenium with Cuprite.

Fixing the Flaky Test

I worked through the flaky test with Claude Code, and as Claude was running the tests, I noticed this pop-up from Chrome.

A data breach on a site or app exposed your password…

I don’t use Chrome very often, so this jumped out at me. Of course, I use the oh-so-secret password “password” in my test suite, and Chrome flagged it as unsafe.

Disabling password leak detection fixed this for me.

browser_options: { "disable-features": "PasswordLeakDetection" }

But I still got timeouts on CI that looked like the tests were running before the browser was ready.

Waiting for CI is a bit painful. You can see my hilariously bad Git history with Claude’s gleeful overconfidence:

* 0c514d1 - nosandbox (15 minutes ago) <Cassia Scheffer>
...
* 57ac55b - bump timeout to 30 sec for ci (21 minutes ago)
* 9d6e86e - rewirite cuprite/capybara configs (26 minutes ago)
* 39f3238 - fix: simplify Cuprite configuration following best practices (10 hours ago)
* 68bfd53 - fix: simplify Cuprite configuration and fix CI timeout issues (24 hours ago)
* cebfae7 - fix: resolve Cuprite websocket timeout issues in CI (24 hours ago)
* dc288b7 - fix: make Cuprite configuration more robust for CI environments (24 hours ago)
...
* e5bb4df - fix: increase Cuprite timeout and add CI-specific settings for GitHub Acti>
...
* cb36eaa - feat: migrate system tests from Selenium to Cuprite (35 hours ago)
* 39f0ff1 - disable selenium chrome password detection (35 hours ago)

That Looks Bad, Cassia. Why Would You Let Claude Do That!?

Because Claude is faster at making mistakes than I am, and I am tired of waiting for CI. Making mistakes quickly means speedier feedback. So I sent Claude off on a fool’s errand to help me learn from the mistakes I would otherwise have made myself.

In the meantime, I read the Evil Martians article about better system tests.

Using Cuprite in Rails with Minitest

The Evil Martians article on system tests uses RSpec, but willow.camp uses Minitest. Here’s what I had to change to make it work with Minitest.

1. PrecompileAssets becomes a module and gets called when setup runs.

# Precompile assets before running tests to avoid timeouts.
# Do not precompile if webpack-dev-server is running (NOTE: MUST be launched with RAILS_ENV=test)

module PrecompileAssets
  def self.setup
    # Check if we're running system tests by looking at the test files being loaded
    running_system_tests = caller.any? { |line| line.include?("test/system") } ||
      ARGV.any? { |arg| arg.include?("test/system") } ||
      ENV["RAILS_TEST_TYPE"] == "system"

    unless running_system_tests
      puts "\n🚀️️  No system test selected. Skip assets compilation.\n"
      return
    end

    puts "\n🐢  Precompiling assets.\n"
    original_stdout = $stdout.clone

    start = Time.current
    begin
      $stdout.reopen(File.new(File::Constants::NULL, "w"))

      require "rake"
      Rails.application.load_tasks
      Rake::Task["assets:precompile"].invoke
    ensure
      $stdout.reopen(original_stdout)
      puts "Finished in #{(Time.current - start).round(2)} seconds"
    end
  end
end

# Run the setup when this file is loaded
PrecompileAssets.setup if defined?(Rails)

2. BetterRailsSystemTests Becomes a Moduel

module BetterRailsSystemTests
  # Make failure screenshots compatible with multi-session setup.
  def take_screenshot
    return super unless Capybara.last_used_session

    Capybara.using_session(Capybara.last_used_session) { super }
  end
end

3. Modules are included in ApplicationSystemTestCase

require "test_helper"
require "capybara/cuprite"
require_relative "system/system_helper"

class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  include BetterRailsSystemTests
  include CupriteHelpers

  driven_by Capybara.javascript_driver

  def setup
    super
    # Use JS driver always

    # Store original host for cleanup
    @original_host = Rails.application.default_url_options[:host]
    # Make urls in mailers contain the correct server host.
    # This is required for testing links in emails (e.g., via capybara-email).
    Rails.application.default_url_options[:host] = Capybara.server_host
  end

  def teardown
    # Restore original host
    Rails.application.default_url_options[:host] = @original_host
    super
  end
end

Flakiness Still Included on CI

I still see a bit of system test flakiness on CI, but far less than before. I am running on the default GitHub Actions runner, which is pretty small. So there’s a good chance that the flakiness is due to low resources on the machine. So far, tests have consistently passed when I run these on my M1 MacBook Air.

I’ll dig into these flaky tests another day! But this looks like an improvement overall to me!

willow.camp Release Notes August 9, 2025

Sat, 09 Aug 2025 20:51:00 +0000

Really quiet week for willow.camp this week.

I updated a few dependencies and upgraded the server it runs on. Everything’s been running smoothly!

I’ve also been working with an LLM to learn Hanami and might eventually move the backend over to Hanami. I’d lose a lot of “batteries included” stuff switching to Hanami, but I like the philosophy they have.

It’s been nice working on something the LLM doesn’t know well. It often drifts off into Rails land, and I have to learn the right pattern to correct the LLM. I think I learn faster this way because it’s easier to be skeptical of the LLM than it is of my own mistakes.

Please have a look at my first pass at the migration at the willow_camp_2 repo.

willow.camp Release Notes Week Ending August 2, 2025

Sat, 02 Aug 2025 12:43:00 +0000

It was a quiet week for willow.camp. The biggest thing I did was to test out generating Open Graph images using a browser canvas. I also improved logging for Honeybadger Insights, which will help me find performance issues.

Beta Features

Added a beta feature for auto-generating Open Graph images for RSS feeds and social media. I’m still figuring out how I want this to work before releasing it for general use.

Improvements

Added in-memory caching to the blog index page.
Site map generation performance optimizations and test coverage.
Added a few more Rack::Attack configurations for noisy bots.

Infrastructure & Monitoring

Logging Refactor to work better with Honeybadger Insights.
Marksmith Editor: Fixed scroll position issues during autosave.

Three Memory Leak Patterns

Thu, 31 Jul 2025 19:51:51 +0000

Normal Memory Usage

In a typical application, memory consumption should increase when the application boots and then stabilize. This pattern will repeat every time the application is deployed.

Memory
  ^
  |
  |        ███████████████████████        ████████████████████
  |  █████████████████████████████  ██████████████████████████
  |  █████████████████████████████████████████████████████████ > Time
    Boot         Stable Runtime      Deploy        Stable Runtime

Gradual Leak

In an application with a gradual memory leak, the memory usage will increase sporadically. This is usually due to specific code paths that are only executed sporadically, causing memory leaks. This pattern looks like a very gradual increase in memory over time that never plateaus and gets reset every time an application is deployed. This is a challenging memory leak to identify because frequent deploys can mask it.

Memory
  ^
  |
  |                        ███████████                 ████████████
  |                      █████████████              ███████████████
  |                 ██████████████████           ██████████████████
  |     ██████████████████████████████  ███████████████████████████
  |     ██████████████████████████████  ███████████████████████████
  | ███████████████████████████████████████████████████████████████ > Time
    Boot    Gradual Memory Growth      Deploy    Gradual Memory Growth

Spiky Memory Leak

A memory leak that causes a dramatic spike in memory will often cause the application to churn, meaning it boots up, memory increases continually, it hits the limit, it runs out of memory, and reboots. This happens over and over and over. These are very easy to identify memory leaks, although the source may be challenging to locate.

Memory
  ^
  |
  |            ████              ████
  |         ███████           ███████  
  |      ██████████        ██████████
  |   █████████████     █████████████
  |████████████████  ████████████████
  |██████████████████████████████████████████████ > Time
    Boot |Rapid Growth | Repeat
                     CRASH!

Learn AI Workflows by Stealing .claude Files

Wed, 30 Jul 2025 14:09:20 +0000

When Harper Reed first published “My LLM codegen workflow atm”, I was hooked.

I had been working with LLMs for a few months and Harper’s post made it all click. “THIS! This is the workflow that has been taking shape for me!” I dove in head first and now for the past few months, I’ve been AI first in all my work. I hardly type code any more. I read, refine, critique, and guide. I only get hands-on-keyboard when I have a very specific preference for how things should work.

Learning Takes Time

It took me a lot of time to learn this workflow. I was lucky enough to have willow.camp as a side project so I could get into the nitty-gritty. But not everyone has that opportunity.

If I had to learn this all today, here’s the approach I would take:

Steal my .claude files, which I stole from Harper, who borrowed from Jesse.
Install Claude Code
Pick up a ticket and start with Claude Code. This is TRAINING WHEELS OFF! Try it out. If you need an editor on the side, hook claude up to Cursor by typing /ide.
Type /brainstorm into Claude Code.
Work through the brainstorming steps to generate a spec.md.
Then kick off /plan, which will generate a todo.md.
Finally, kick off /do-todo, which will iterate through todos.

Repeat.

The more you do this, the more it will become second nature. Eventually, you might not even need the commands anymore because you’ll know when to plan and when to act.

Break Things

I learn by breaking things!

Modify your commands to suit your needs. Come up with your own commands and see how they work for you.
Try the same thing twice to learn more about keeping the LLM on track and focused.
Try the same task without doing the planning and see what happens.
Try a massively complex task with and without planning.
Try a tiny, simple task with and without planning.

Breaking things is all about finding the boundaries. The best way to know what an AI agent is good at is to find out what it is BAD at!

Keep it cool. If the LLM wanders off into the woods to build a tree fort when you asked it to do something else, that’s okay. We all get off track. Here are a few things I do to learn:

Ask the LLM what went wrong:

“I noticed we struggled to solve this. Analyze our conversation and give me pointers on how to find a solution sooner.” This is a good prompt because sometimes, some incorrect context or weird code misdirects the LLM.
“We have struggled to find a solution. Explain to me why you thought this was the right path forward?” This is an excellent prompt for getting the LLM to reveal its thinking. I have learned from this prompt that it is very important to correct the LLM early and often. If you don’t, you both might misunderstand something. Once the LLM is off track, I ask for a session summary, clear the chat and start over.

Takeways

Try stuff! Try lots of stuff and try it often. Timebox your work so you don’t get stuck in a hole. Check yourself to see if the task you’re doing is valuable. Are you learning something? Are you making progress?

Learning is about making mistakes. Remember to make mistakes safely and adapt to them quickly. AI workflows can accelerate your work, but you have to shift your approach first and know how the tools work.

Testing A New willow.camp Feature

Wed, 30 Jul 2025 13:12:00 +0000

I don’t like competing for clicks. But I do like people reading my blog.

If you landed here form LinkedIn, you probably saw a colorful image showing the title of this post. Where is that image?! It’s in the Open Graph tags in the head of this page.

When I launched willow.camp, I intentionally kept social-media style features out of it. willow.camp doesn’t track views (aside from what’s needed for performance and bug monitoring), and doesn’t have likes or comments.

But it was missing something.

When I shared posts to LinkedIn, my posts would show up as plain text. Despite having no analytics, I get the feeling that some people miss my posts because they are overwhelmed by a sea of images.

So here I am. Writing a social media feature for willow.camp that is in beta (meaning I am the beta tester!) If you are using willow.camp, I’ll release this feature once I’ve put the right polish on it.

I added a canvas to the post editing interface that grabs the theme colours, favicon, and title to create an Open Graph image that LinkedIn can see. This is the first time I have image storage.

The images are stored locally on the server, so I’ll run out of space one day. But for now, I’m going to test this out and polish up the user experience before making it more broadly available.

Taste

Sun, 27 Jul 2025 13:02:00 +0000

I can see really high-skill, high-taste shops like 37signals struggling to adopt [agentic coding] because their very good taste means they are repelled by the slop. Bigger companies and small startups/indies will have an easier time at it, out of necessity. – Nate Berkopec on LinkedIn

With LLMs making leetcode and other whiteboard problems trivial, software hiring IMO should shift towards establishing taste, which LLMs absolutely do not have.

“What do you hate about ActiveRecord? What would you change about Rails if you could?” Review this PR, etc. – Nate Berkopec on LinkedIn

What is “taste”? Does your taste matter as a developer? Do your customers care about ActiveRecord? (Spoiler alert: they do not).

I have been working in an exclusively agentic workflow for about six months now. I hardly write code. Does this mean I have poor taste?

I remember in my early days in software development, I overheard two opinionated Senior Developers argue about white space and wondered why it mattered.

Taste Does Not Matter, Customers Matter

What matters at the end of the day in any business is its customers. Do they like what you’ve made? Will they tell people about it?

You can’t run a business on opinions about ActiveRecord, Rails, whitespace, or any of that. You run a business by selling a product that works well and makes people happy.

But `insert thing here` is BAD!?

It might be! What do we mean by “bad”? What is the impact on our ability to deliver a reliable product? How does it impact our customers?

“Taste” is only important if it affects the customer. Here are the interview questions I’d use in this new world:

How does ActiveRecord affect the software development life cycle?
What impact can the ORM have on the quality of your application?
When do you choose to set your opinions aside and ship quickly vs weighing your opinions against real-world consequences?
How do you measure the quality of good software?

The answers to questions like this will inform technical decisions and will avoid banter about taste.

I’d much rather focus on building great things than getting mired in debates about ORMs.

Conclusion

I care about your views on building fast, reliable software that makes people happy. Let’s leave the bikeshedding to others.

willow.camp Release Notes Week Ending July 26, 2025

Sat, 26 Jul 2025 12:20:00 +0000

Here’s everything I did on willow.camp this week. It blows my mind how much I can get done when I’m having fun! I work on this app for about an hour every morning and evening.

Major Features Added

Featured posts functionality with toggle UI
Tap/click to edit a tag on the tags index page
Terms of Service page
Rack-attack integration for rate limiting and security (blocking PHP requests, credential probes)
Added no-index option to settings page for search engine control

UI/UX Improvements

Replaced inline SVG icons with heroicons gem
Enhanced mobile navigation by moving dashboard tabs to the hamburger menu
Updated tag UI with circular icon buttons
Replaced default Rails error pages with custom DaisyUI designs
Improved post actions UI with a dropdown menu and a modal delete confirmation
Added “Save Draft” and “Publish” buttons instead of a “Published” checkbox

Performance & Testing

Optimized Dashboard::TokensControllerTest (1.97s → 0.31s)
Optimized slow mermaid test by reducing markdown content in tests
Added Bullet gem for N+1 query detection
Fixed N+1 query in API posts controller
Re-enabled parallel test runs

Code Quality

Removed RuboCop entirely and only use StandardRB for code style
Added standard-rails gem for enhanced Rails linting
Updated Brakeman from 7.0.2 to 7.1.0
Merged willow_camp_cli history into cli/ subdirectory

Security & SEO

Enhanced request logging with user agent and subdomain info
Added CC license to GitHub repo

Bug Fixes

Fixed favicon controller error
Fixed mobile tag editing card UI updates
Fixed OG published_time tag for draft posts
Prevented mobile auto-capitalization for domain inputs

What to do When AI Makes a Mistake

Thu, 24 Jul 2025 15:31:00 +0000

Reading Sean Goedecke’s post “Do not yell at the language model”, my first reaction was, “Don’t…what?”

I don’t yell at people. Why would I yell at a non-sentient tool? That’s like yelling at the sledgehammer you dropped on your foot.

There is a good bit of truth in his post:

So what should you do when an AI model makes a big mistake? I recommend correcting it as matter-of-factly as possible and trying to briskly move on. If you haven’t yet built up a lot of context in the conversation, it might be worth starting over entirely. The best approach - only offered by some AI tools - is to go back to the point in the conversation right before the mistake was made and head it off by updating your previous message.

Just start over! Treat mistakes as opportunities to set better guidelines. The quicker you are at catching mistakes, the more accurate the LLM will become.

Here are a few things I do when working with LLMs:

One small task per chat. I know some people build up extensive context in a long chat, but if I don’t catch a mistake, the % of incorrect context can compound over time.
When the LLM or I are stuck, ask it what we are stuck on and ask it to summarize possible solutions.
Try one solution at a time. Sometime in the same chat. Sometimes in a new chat. Depending on how long your chat has gone on.
Verify the proposed solutions and problem space by looking at the code. Sometimes you’ll catch something the LLM misunderstood. Other times, you’ll learn something you had misunderstood!
Find docs to help focus the LLM’s attention.
Write Docs. This is so important. Once you’ve solved something, write the documentation in a docs/ directory and reference it in later chats for similar problems.

Agents don’t have intent. They don’t even have all the context. They can miss things. Treat the agents’ work as directionally correct. Verify implementation details.

To work quickly with LLMs, you need to understand the language, system, and tools you’re working with so that you can get the agent back on track when it inevitably drifts.

One last note about agents making mistakes. We all make mistakes! The best part of working with an LLM is that it can make mistakes quickly, and you can redirect those mistakes. The faster the LLM makes mistakes, the quicker you can refine the task and complete the work.

Anticipating errors is as much a part of working with humans as it is working with AI.

Use Precomputed Hashes Instead of BCrypt in Test

Mon, 21 Jul 2025 00:55:00 +0000

I asked Claude to find the slowest test file again after my success earlier today and Claude found a call to BCrypt in my fixtures that was gobbling up time.

I need user records all over the place in my test and each new user is a new call to encrypt a password.

Here is Claude’s summary, with my Grammarly edits:

Problem: The PreviewsControllerTest#test_should_show_preview_for_own_unpublished_post test was taking 2.95 seconds due to BCrypt password hashing being computed dynamically in fixtures with <%= BCrypt::Password.create("password") %>.

Solution: Replaced the dynamic BCrypt computation with a pre-computed hash $2a$12$dapdHZiOTxAL8OT9yNI6e.hhTjRhWgXq7kx737/xf8tBfQbMD2bi for all user fixtures.

Result: The slowest test now runs in ~0.25-0.52 seconds (82% improvement) and all tests pass. The overall test suite performance has been significantly improved, as this optimization affects all tests that use user fixtures.

enumerator.dev

Post

Safe Claude Code Settings

Planning, Building, Reviewing: Why The JJ Workflow Works Better Than Git

Rebasing Kills the Git Workflow

My Current Workflow

1. Start plan mode

2. Iterate on the Plan

3. Turn the plan into commits

4. Review the jj Plan

5. Auto-accept edits

6. Do Something Else

7. Code review with Claude

8. Use gh to create PRs

9. Code Review Again

Why JJ Works So Well

Two Takeaways

Plan, Plan, Plan Again

Review, Review, Review Again

Use Git to Plan and Build With Claude

You Don’t Need to Learn a New Tool

Why is Claude Code Different from Cursor if they Both Use Claude?

Defining Terms

AI: Distinguishing the Agent from the LLM

The LLM Reads the Entire Conversation Every Time

Key Principles

Conclusion

Use Jujutsu to Plan and Build with Claude

Jujutsu

Planning Best Practices

Why This Works (My Theory)

I Want This

🎈 Uplift

Navigating to Get Things Done

Be a Navigator

Protecting Your Team Protects Dysfunction

Focus

willow.camp Updates - October 7, 2025

willow.camp: Next

Finding the Next Tech Stack

What I Want in A Language and Framework

The Next willow.camp Tech Stack

The Next willow.camp Features

willow.camp Updates September 21, 2025

Major Features

Improvements

Security & Dependencies

How Much does it Cost to Run willow.camp?

Claude Code

August Breakdown

September Estimate

Naming Things for What They Do

willow.camp Updates September 7 2025

New Features

Summary - August 17 - September 7, 2025

Major Features

Improvements

willow.camp Updates August 16, 2025

Improvements

Security & Dependencies

Bug Fixes

End To End Tests with Minitest and Rails

Fixing the Flaky Test

That Looks Bad, Cassia. Why Would You Let Claude Do That!?

Using Cuprite in Rails with Minitest

1. PrecompileAssets becomes a module and gets called when setup runs.

2. BetterRailsSystemTests Becomes a Moduel

3. Modules are included in ApplicationSystemTestCase

Flakiness Still Included on CI

willow.camp Release Notes August 9, 2025

willow.camp Release Notes Week Ending August 2, 2025

Beta Features

Improvements

Infrastructure & Monitoring

Three Memory Leak Patterns

Normal Memory Usage

Gradual Leak

Spiky Memory Leak

Learn AI Workflows by Stealing .claude Files

Learning Takes Time

4. Review the `jj` Plan

8. Use `gh` to create PRs

But `insert thing here` is BAD!?