Peter Naur’s “Programming as Theory Building” feels more true than ever. When using claude in a codebase I know deeply, I know which skills and agents to use, when to check the monologue early, and when to run tasks in YOLO mode. That judgment comes only from deep familiarity.

As specs became critical to understanding the implementation, I started using git trailers to reference the relevant ones in commits. I also use Just recipes to easily find commits that reference different types of specs, making the codebase easier to maintain over time.

They’re not that risky if you’re using Haskell.

Claude Code is amazing, but it’s also the buggiest software I use day to day.

There's been a wave of complaints about the command line as claude code has grown popular, often framed as “it’s just an archaic UI.” But I’ve never encountered a complex autocomplete—especially multi-step, interdependent selection—that delivers a better UX than fzf.

That’s been the case for at least the last 10 years, not only the last 10 days.

I spent all day writing specs for a new project. Writing the specs became the hardest part of coding.

I believe specs will become more valuable than code over time. You can’t reliably reverse-engineer intent or requirements from code alone. This raises the possibility that developers could monetize the spec while keeping the code open source.

One of the frustrating parts of using notion or linear for product management is that they don’t support kanban properly. There are no WIP limits, and reporting on flow metrics isn’t straightforward. I added all of that to Rei in a weekend.

The claude code experience has gotten significantly worse since switching to the native installer. It freezes frequently and often consumes multiple gigabytes of RAM, forcing me to kill it.

I’ve never used zig, but seeing both ghostty and bun struggle with severe memory leaks and high CPU usage, even with excellent developers behind them, doesn’t reflect well on zig.

Programmers ignore pure FP because it is hard to appreciate what it enables without experiencing it. Unfortunately, it can take years to master and fully see its benefits. This is the Blub Paradox Paul Graham described in Beating the Averages.

In most FP discussions, it becomes clear that many developers don’t really understand what pure functional programming is, even some who studied PLT in college. A lot of people seem to equate FP with just using map and filter and avoiding mutation. That is only a small part of

Most SaaS products were begrudgingly used by software engineers because they couldn’t justify the time to build a better internal solution. That’s about to change.

I don’t like changing workflows often, but recent regressions in claude code DX have me seriously reconsidering codex.

Personal software development is incredibly liberating. I no longer get frustrated by missing features or bugs that I have no influence over.

in a year, the concept of a pull request will no longer make sense. It will be replaced by commit annotations that clearly indicate the type of review performed and the depth of that review.