Narthur Online

Hills to Die On

Wed, 16 Sep 2026 17:45:57 GMT

I find myself using this rubric when deciding how much I should push back on something that doesn’t feel quite right.

Reversibility: Would it be difficult to reverse this decision later?
Blast radius: Is the impact of getting this decision wrong large?
Forward binding: Will this decision change how future decisions are made?

If I can answer “no” to all three questions, it isn’t something I should overthink.

I use these three questions in a variety of situations:

A colleague makes a recommendation I’m not sure about.
Something in a pull request doesn’t look quite like I’d do it.
A coding agent makes a call I don’t fully understand yet.

If one of those questions is a “yes,” I need to dig in and maybe push back. Otherwise, I’m comfortable letting it go.

This framework is similar to Amazon’s one-way and two-way doors idea.

I’ve been using these questions for a decade now, but it was only recently that I captured the rubric in writing. I did so because the code review skill I was working on was burying me in findings, and I noticed I was asking the same three questions while reviewing each issue the skill found. Defining these questions and adding them to the skill allowed it to address a large number of its low-confidence findings without requiring my input, letting me focus on the few decisions that warrant my attention.

Having these questions in my back pocket has helped me to avoid a lot of stress and conflict at work, and has let me more easily focus my attention on what actually matters.

Words In Mouths

Tue, 08 Sep 2026 16:26:31 GMT

Recently I had a realization that seems obvious in retrospect.

LLMs should default to avoiding speaking in any author’s voice, whether that’s the robot’s or the human’s.

Unless explicitly asked to, it should avoid using “I” and “me” when writing documents, emails, and other prose artifacts. By default it should never put words in the user’s mouth.

I think this would be an improvement for users and for society.

It would stop nudging users to become secret cyborgs.
It would result in more professional documents.
It would help slow the breakdown of trust in written communication.

I’ve never had a work secretary, but I imagine that’s how they work. When you ask your secretary to call someone for you they don’t pretend to be you making the call. They speak in a professional manner without drawing attention to the person making the call.

Why haven’t the big labs made this the default? Why is Claude so eager to write any outgoing communication as if I had written it? It’s kind of baffling.

To be clear: I am not without sin. I’ve been a secret cyborg. I’ve asked Claude for something, it’s given me the email in my voice, and I’ve taken the lazy way out: copy, paste, send. I have no excuse. But I wish Claude hadn’t made it the default, easy option.

In response to this realization, I worked with Claude to add this to my global CLAUDE.md file to try to do better moving forward:

Default to prose that makes no reference to the author. Describe the thing; don’t narrate it as me. No “I”, “me”, “my”, no thanks, apologies, feelings or motives offered on my behalf.

Write in my voice only when I explicitly ask for it. This holds even for something I am going to sign or send — a letter, an email, a statement. Err toward no reference to the author; if first person is wanted, I will ask for it or add it myself.

Why I’m Leaving Render.com

Thu, 03 Sep 2026 16:59:54 GMT

Render.com is a fantastic service. It’s a cloud provider that makes the right stuff easy.

The happy path is automatic deploys from your git provider.
It has first-class infrastructure-as-code support via its blueprint files.
It skips the complex IAM systems of AWS and GCP.
It ships a limited (though growing) number of primitives that can be used to build the majority of things I’d want to build. Currently around ten, depending on how you count, compared to more than 300 at AWS.
Its pricing is straight-forward and predictable.

I’ve been a fairly big user of render.com for a while, even hosting TaskRatchet on it for two years.

For a while now I’ve been migrating off of Render.com, moving most of my work to Cloudflare. The only things I’m still hosting on Render.com are a few static websites.

Why the switch?

The main reason: It’s expensive.

Simple pricing doesn’t mean cheap. And my usage pattern, building many side projects which probably won’t get much usage, is just about the worst scenario. A server project typically needs at minimum a public computer service and a PostgreSQL database. To avoid cold starts and losing data, that means paying, at minimum, $7 / month for the compute service and $6 / month for the database, or $13 / month all-in. And that’s even if I’m the only one ever using the project. if I want five such projects, I’m easily paying $65 / month or more.

So at this point Cloudflare turns out to be a way better fit. It’s way cheaper, and the architectures it naturally pushes you toward mean I’m paying for what I use rather than paying for instance that are doing nothing most of the time. Plus Cloudflare-hosted projects tend to be really fast. Since I’m using Claude Code, I don’t have any issues configuring the cloud infrastructure. And it gives me more flexibility in how I can build things while still avoiding the incredible complexity of something like AWS.

I’m happy with the move.

The Limits of Vibe Coding

Thu, 27 Aug 2026 17:53:25 GMT

I’ve been thinking about where we’re at with vibe coding, defined as the ability of non-technical people to build and maintain software using LLMs.

My conclusion: Vibe coding works great as a way to quickly build small prototypes and jump-start new applications. But it falls short when it comes to maintaining quality software for the long-term.

The reasons are these:

LLMs do what you ask them to do, and avoid getting sidetracked.
A non-technical person doesn’t have the vocabulary of software architecture.
A non-technical person doesn’t have the ability to attribute difficulty in developing the software to the underlying architectural problems.
Good architectural decisions are made where software architecture, the domain, and the roadmap overlap.
The world changes.

LLMs Do What You Ask

By design, LLMs do what you ask them to do and avoid doing what you don’t ask them to do. This is normally what you want. You have a task to complete—a feature to add, a bug to fix, a design change to make. You don’t want the LLM getting distracted by a side quest.

What this means, though, is that code messes don’t get cleaned up. As long as the LLM mades a little bit of a mess even a small percentage of the time, the codebase is likely to degrade over time. And the non-technical builder doesn’t have the ability to look at the code, see where the mess is, and ask the LLM to clean it up.

Lacking the Vocabulary of Software Architecture

A non-technical person can tell an LLM what they want to build. They can describe the features they want and how it should look and behave. But they don’t have the knowledge of software architecture to know how to ask the LLM to structure the codebase. So the LLM will make a best guess.

Lacking the Ability to Attribute

As a codebase becomes messier, the LLM begins to struggle making the user-visible changes the builder asks for. But without the knowledge of what makes for good code and what makes a project well-structured, the builder is ill-equipped to know where to point the LLM to have it correct the situation. The builder is likely to attribute the trouble to poor prompting or the model becoming dumber, instead of on underlying code smells.

The Architectural Decision Nexus

You might think the solution would be to simply tell the LLM to “use good architecture,” or otherwise give it a philosophy of architecture to work from.

The problem is that good architectural decisions can’t be made in a vacuum. Choosing an architecture is deciding what should be hard in the future and what should be easy. And that depends on your domain model and your product roadmap. Starting with good software architecture principles is not enough.

Architectural decisions are bets on how the context of your application will change over time, and choosing how to structure your codebase in an attempt to make it easy to adapt to those shifts.

The World Changes

Software is never finished. This is because the context in which it lives is always changing. User needs change. Hardware substrates change. Protocols change. The languages, libraries, and frameworks we depend on change. The security landscape changes. What’s considered “best practice” changes. A perfectly clean, sane codebase slowly turns into a poorly-optimized mess over years, even if no one’s modified it. The ground moves.

I wouldn’t bet on this state of affairs being permanent. Perhaps someday we’ll have fully-autonomous agents that proactively track the context of a piece of software and update its architecture accordingly. Consider this to be a snapshot in time of the challenges faced by non-technical builders who want to push their vibe coding to the limit.

Job Search Coaching, Hand-Writing Code, RSS Feeds

Thu, 20 Aug 2026 17:24:15 GMT

I’m at just about 40 job applications submitted, no interviews. I’m currently submitting four applications each day. I’ve signed up with a mentor on MentorCruise to get a second pair of eyes on my resumes and cover letters, see if there are things I can improve.

I enjoyed this video by Dreams of Code on why writing code by hand is still a valuable practice even if you’re all-in on agentic software engineering.

It got me thinking about the differences between using something like Claude Code and old human pair programming. When I would pair with someone, I would shift how much code I would write in response to their prompts based on how much they understood about the problem and the code we were working on. If they had a good understanding, I would write more. If they had less understanding, I would drag my feet and let them over-specify so they had the chance to internalize what was happening in the code.

I updated my claude code setup to try to have it act more this way. It should now keep track of which subsystems I do and don’t deeply understand in the codebases I work in, and then adjust how focused it is on getting the thing done vs teaching me based on that. We’ll see how well it works.

I’m continuing to enjoy reading RSS feeds in Feedly. I’ve moved most of my newsletter subscriptions to Feedly. Thankfully Substack and most other newsletters expose an RSS feed. Not a Substack publication, but I’ve been especially enjoying Brennan’s Weblog, written by avid Beeminder user Brennan Brown. His blog is exceptionally well-written and always thought provoking.

Job Search Update: Giving Up on AI Writing

Thu, 13 Aug 2026 16:27:10 GMT

So far I’ve submitted 25 applications. None have gotten past screening.

About a week ago I watched a GitHub live stream hosted by Gwyneth Peña-Siguenza and Cassidy Williams. During the stream I asked in chat if using AI to help with writing cover letters was a good strategy. The response was no, it’s not a good idea.

This confirmed what I had been thinking for a bit now, that using AI to help with writing my cover letters is proving more trouble than it’s worth. While I don’t have a philosophical problem with using AI to help write my cover letters, I found myself spending more time wrestling with my humanizer and voice skills than actually doing productive work on my applications. So I’ve stopped using AI to write my cover letters and form answers, though I’m still using it to personalize my CV to each role, and for helping me with other steps in the process.

Another thing that stood out from the stream: Gwyneth mentioned that around the year 2015 she ended up submitting 200 or 300 job applications before landing a help desk job. So that’s my new goal. I aim to submit 300 job applications before feeling that I’ve adequately done this job search.

That, of course, means that half an application per weekday won’t cut it. I’m in the process of updating my Beeminder goals to move me to four applications daily. Even so, at four applications per weekday, that will take me just under four months to complete.

I won’t be relying on a single goal to require this. I plan to create four new goals, one per application, spaced throughout the day. That way, if I’m having more trouble one day, I won’t end up procrastinating until I only have an hour left to prepare and submit all four applications.

After stopping using AI to write my cover letters, I’ve found a process that seems to be working well for writing my letters efficiently:

I talk back-and-forth with Claude about the role until I have a good handle on everything I want to say and the relevant experience and gaps I want to include.
I write the letter in Obsidian, pulling in reusable paragraphs I’ve saved from previous cover letters, modifying them and adding surrounding paragraphs as needed.
Claude reviews the letter for accuracy and gaps.
Once complete, I submit the cover letter with my application.
Claude then extracts any new reusable paragraphs from my submitted cover letter and saves them for future cover letters.

This has helped writing the letters be a lot less overwhelming and faster than any of the approaches I’ve tried previously.

Wish me luck!

GitHub CLI Alias to Prep Git for Your Next Task

Thu, 06 Aug 2026 15:46:46 GMT

A while back I found myself getting mildly annoyed by the friction around ensuring a repo’s git was in the correct state for starting a new task with Claude Code.

Am I on the default branch so Claude Code doesn’t create a PR based on another branch it shouldn’t?
Is the default branch up-to-date with origin?
Is the branch I was on previously merged and ready to be deleted?

I ended up adding a GitHub CLI alias built on top of gh-poi, a GitHub CLI plugin that deletes branches that are already merged into the default branch. I called the alias “doi” based on it running “poi” on the default branch.

With my alias set, I run gh doi in terminal, which runs the following commands:

# Save default branch name, so it'll work if your
# default branch is main or master or development
# or whatever
DEFAULT=$(gh repo view --json defaultBranchRef --jq ".defaultBranchRef.name")

# Checkout default branch
git checkout "$DEFAULT"

# Pull default branch
git pull

# Delete merged branches
gh poi

Here’s how to install gh-poi and add the alias:

gh extension install seachicken/gh-poi
gh alias set doi '!DEFAULT=$(gh repo view --json defaultBranchRef --jq ".defaultBranchRef.name") && git checkout "$DEFAULT" && git pull && gh poi'

And that’s it. You’re ready to run gh doi the next time you want to make sure your working tree is prepped to start a new task.

Tips for Effective Skill Design

Thu, 30 Jul 2026 17:52:55 GMT

Just about seven months ago I started experimenting with building my own skills. Since then it’s become the primary way I encode and iterate on my work tasks, programming and otherwise. Here are a few lessons I’ve learned about skill design. I’ll be referring to Claude Code throughout, but you can substitute your preferred agentic coding tool.

Don’t hand-write your skills. Let Claude draft skills for you. The first draft isn’t supposed to be perfect. You’ll be iterating on it, so it’s inefficient to put a lot of energy into hand-crafting your skills.

Have your skills use scripts. Claude Code skill folders can contain any type of file, not just markdown files. Make use of this by including scripts in your skills that handle all the deterministic stuff that doesn’t actually need an LLM. This will reduce your token costs and improve the reliability of your skills.

Leverage subagents. Claude skills can instruct Claude to spin up subagents to handle portions of your task. Depending on the situation, this can improve result quality, increase speed, and even reduce costs. It can improve result quality by managing context, either preventing Claude’s main thread from becoming bloated or sandboxing something inside a subagent that shouldn’t have access to the main thread, like an independent reviewer. It can increase speed by parallelizing subtasks. And it can reduce costs when a portion of the task doesn’t need the model you’re using on the main thread and can be delegated to a cheaper model.

Use progressive disclosure. Not everything should go in a skill’s main SKILL.md file, only the stuff that is applicable to nearly every run of the skill. Anything that is conditional or situational should be extracted into separate markdown files in the skill’s folder, and referenced in the main SKILL.md file along with whatever condition should result in the skill loading that file into context. This approach makes it less likely that the skill becomes distracted by something not relevant to the current run, and reduces token costs.

Keep your skill descriptions sharp. The description should state when a skill should be invoked, not summarize what the skill does. This improves Claude Code’s ability to trigger the right skills at the right time.

Let your skills learn over time. This allows your skills to become better over time without needing to explicitly work to improve them. Example: In a playwright skill I built, I have the skill record website-specific learnings after each run to files in a websites subfolder of the skill.

What Is Good Writing?

Thu, 23 Jul 2026 18:23:41 GMT

When I was in high school and college, writing was one of my strengths. I enjoyed writing. Between high school and college I interned at a magazine. In college I minored in English.

I think good writing, and all good art really, is a profound act of vulnerability, and therefore courage. It requires letting yourself be seen, putting yourself on display, opening yourself up to criticism and rejection, or perhaps worse, disinterest.

Writing requires curiosity, vulnerability, courage, exploration. It requires accepting yourself at the same time that you subject yourself to your own criticism and open yourself to the criticism of others.

I’ve been continuing my job search, and that’s meant continuing to use AI to write cover letters for my applications. I have the AI draft the cover letter, and then I review it for things I don’t like, and ask Claude Code to update my writing skills and fix what I found in the draft. Once I’m satisfied that the cover letter is entirely accurate and up to my standards, I send it.

(Aside: I never use AI to write this newsletter.)

By necessity that editing process has required me to think through what makes writing good.

It shouldn’t use many words to say something that fewer words could say just as well.
Conversely, it shouldn’t cut words that are necessary to communicating the desired idea.
It shouldn’t use fancy words when simple words would do.
Conversely, it shouldn’t shy away from fancy words when a fancy word communicates the idea better.
It should be confident, straight-forward, and unapologetic, unless there is a specific reason to communicate insecurity or ambiguity.
It should avoid being overly evocative, except when being evocative supports the goal of the piece.
It should be aware of the context for which it is being written—the relationship between the author and the reader, the reader’s likely state of mind, and the broader societal context.
It should avoid careless repetition, such as the same word being used multiple times in one sentence (see: “context” in the previous point).
It should be easy to read. Words and structure should feel natural, not surprising or jarring.

The one thing I would expect to be in that list is acknowledging uncertainty. Intellectual honesty is a value that has become more important to me over time, so I would expect to see it in my personal goals for good writing.

I think that absence is correct. Not every piece of writing needs to embody intellectual honesty. Some writing takes a stand and makes the best case for that position, lawyer-style, while omitting counter-evidence. Some writing is exploratory, trying on a thought process for size, and not meant to be an honest appraisal of the idea’s objective value. Some writing is meant to clearly communicate the inner state of the author, and none of us are entirely honest with ourselves all the time. I think all these forms of writing can be valuable.

On the other hand, I’ve been tempted to conclude that intellectual honesty is the enemy of good writing. That it inevitably results in over-thinking, wishy-washy prose that doesn’t go anywhere. If I believe that perfect certainty is never warranted, then how can I be unapologetic and confident in my writing?

I don’t think this is true, either.

All of the following statements are confident, unapologetic, and straight-forward:

I’m 80% certain.
I’m not sure.
I don’t know.
This is my current belief.

It isn’t my acceptance of uncertainty that results in my writing lacking substance or drive. It’s my undeveloped thinking, an unwillingness to be vulnerable, and a fear of publishing something that will some day prove that I was wrong.

I’m not sure how to address all these barriers. Undeveloped thinking is fairly straightforward. I can spend more time thinking, letting ideas have the room they need to mature before publishing them. The personal insecurity? That may take more time.

Long-Distance Friends

Thu, 16 Jul 2026 18:42:48 GMT

Maintaining long-distance friendships is difficult.

Different people have different preferred channels. Some people hate email. Others dislike talking on the phone.
Feedback is ambiguous. If you send someone an email and they don’t respond, is it because they are annoyed, or did they enjoy receiving the email but were too busy to respond?
Desired cadence can be uncertain. Do they enjoy receiving 10 texts a day, or would they prefer an email every six months?
Content type and length are also ambiguous. Somehow, some people enjoy talking about politics. I don’t. I might prefer a medium email. But maybe they’d prefer a gif. A discord voice hang. A text. A gaming session.
Sometimes people just need a break. I’m taking a break from a friendship right now. They didn’t do anything wrong. I feel bad about it. And at some point I’ll resume reaching out.

How much of this is solvable by the tools we use to communicate? How much of it is just something we need to ask each other about? And if we do, how do we do that in a way that doesn’t sound desperate?

“I sent you an email last week and you didn’t reply. Please select from this list of options on why you failed to respond in a timely manner.”

Hmm…

Changing My Approach to Writing

Tue, 14 Jul 2026 15:37:07 GMT

I have a new strategy for how to improve my writing in this newsletter. Apologies, this issue isn’t using the new strategy, but I’m hoping it will serve as a public commitment to making the switch.

Up to this point, I’ve been beeminding spending thirty-minute blocks on the newsletter weekly, and it’s been my unofficial goal to publish an issue at the end of each of these blocks. In practice this has meant thirty-minute train-of-thought writing sessions with little or no editing before publishing.

My plan going forward is to break that single Beeminder goal into two—one for capturing thoughts, organizing ideas, doing train-of-thought writing; and a separate goal for publishing posts. I’m hoping this will have several benefits:

Having time spent thinking separated from the need to hit publish will hopefully reduce anxiety.
Time dedicated to exploration of ideas separate from a specific newsletter issue should allow my thoughts the room to develop before publishing, even if that means some ideas take weeks or months before they’re ready to share.
Having the freedom to vary the size of my posts, rather than every post being roughly thirty minutes worth of words, should allow posts to be more contained and coherent.

I’ve just taken a moment to complete the step I’ve been procrastinating on, actually creating the two goals:

sowstack - starting at six minutes daily, autodialed up to a maximum of thirty minutes daily
reapstack - starting at one post weekly

I’m storing the raw material (thoughts, ideas, questions) in a folder in Obsidian. It also has a sub-folder where claude code can add stuff if I’ve requested it to. I’ve instructed claude code to always add such material as outlines rather than prose to further reduce the chance any AI-written prose will accidentally make it into the newsletter.

Hoping this will significantly improve the quality of my writing here!

Longer Resumes, Used Phones, and LEGOs

Tue, 07 Jul 2026 17:38:42 GMT

I’m still on the job hunt. So far I’ve applied to nine jobs. Starting tomorrow I’ll be spending an hour daily on the search, up from 30 minutes.

I’ve also updated my resume generator skill to create resumes with two pages instead of one. The first page remains the part tailored to the job I’m applying for, meant for a human to read. The second page is a list of every technology, tool, and practice I’ve touched, as comprehensive as I can manage. That’s for the screening robots to read, so that I’m less likely to get filtered out because I failed to list something that a company configured their automated systems to look for.

So far I’ve had no positive results, just a few form replies saying they’re moving forward with other candidates.

I started the search on June 22, roughly 15 days ago. That means so far I’ve submitted 0.6 resumes per day on average. Naively, that means my move to spending an hour a day on the search should get me to submitting one application every day. All this ignoring that these goals have weekends off, so theoretically I’ll be above one application per day on average.

I intend to keep ramping up my efforts over time. So once I prove that an application a day is doable, I’ll think about upping the rates on my Beeminder goals again.

I’ve replace my cell phone. I’ve been using a Samsung Galaxy A52. I decided it was time to replace it since it’s no longer receiving software updates, Duolingo stopped working on it, the screen is cracked, and—the last straw—the glue holding the plastic backing of the phone on started coming loose.

I purchased a used Pixel 8a, and it arrived in the mail yesterday. Transferring my data from the Samsung was relatively painless, as was transferring my two phone numbers to the phone (I switched from physical SIMs to eSIMs in the process).

My brother’s an iPhone user. He’s been talking about wanting an Android device so that he can get Android apps published to the play store. I factory reset the Samsung and passed it on to him. Most of its issues shouldn’t be a problem as a development devices, though I suppose at some point the lack of software updates may.

My brother and I are in the early stages of exploring some new side hustles, too—reselling LEGOs on Bricklink, and perhaps other items with resale value we can find.

I’d explored the idea in the past. LEGO was my favorite toy growing up, so it’s always sounded fun to somehow make money with something I’m nostalgic for.

However to now it’s never quite made sense to try. Competition is high, it can involve a lot of driving, and the hourly rate you’re likely to make is low.

Right now, though, those things aren’t a problem—my brother has a car and enjoys driving, we have plenty of time to spend on it that wouldn’t otherwise be bringing in money, and we can afford to start slow. So that’s the plan.

Turns out first thing you have to do in order to become a reseller on Bricklink is to get a positive rating from an existing reseller on the platform. I purchased set 6487 from 1997. It hasn’t arrived yet. Plan is I’ll leave the seller a good review and hopefully they will reciprocate.

Stream-of-Thought, with Stakes

Tue, 30 Jun 2026 18:15:10 GMT

I’m trying something different today. I’m using this web app to write this, set the timer to fifteen minutes. If I stop writing for more than 10 seconds, it deletes everything I’ve written.

This is a version of an older app called The Most Dangerous Writing App I think, something like that. This version was made by Dynomight. They have a good blog / newsletter.

The job search continues. I just applied for a role at Spotify today. I have to never put too much hope into any single job application.

This app is a little stressful. Can’t stop typing for 10 seconds.

I’ve increase the amount of time I committed to working on my job search from 30 minutes a day to one hour today, committed via Beeminder of course.

I’ve started using tmux for spinning up development environments in my terminal. I switched from warp.dev to ghostty. I run `dev`, a custom shell script in my bin, and it runs a whatever-project.sh script that loads the tmux session. The left column is always Claude Code, run with –continue and falling back to straight claude. In the right column I’ll have one pane running any dev servers, one pane running tests, and one just a straight terminal. I’ve also played around with having the middle column be hunk in watch mode so I can see the changes on the branch as I work. Not totally happy with how that works yet though so only have that in one of my environments.

I’ve expanded my job search to include not just jobs that would relocate me to Sweden but also jobs that are fully remote. That way I can still have the freedom to travel even if I don’t get a job in Sweden specifically.

With projects like this where I really want to keep velocity I find that it works quite well to have multiple Beeminder goals supporting the project from different angles–in this case, daily time, action points, and applications submitted. When one goal starts slipping in its effectiveness, the others are a backstop while I diagnose and tweak. And it feels good to get ahead in one goal even if it’s another goal that’s the reason I’m getting ahead.

I’ve experimented a bit with working on a treadmill again. A few years ago I had a treadmill that fit under my desk, but I found that keeping it working was difficult. Now I have access to a full-size treadmill where I’m staying. I discovered that there are universal attachments you can buy for full-size treadmills that add a desk or a laptop stand to them. For an experiment I tried just using a board, and it did seem to work ok, especially since my programming work tends to be give commands, monitor, give more commands, etc, so I don’t need to be hands-on-keyboard constantly. I don’t think I’ll be doing it much, though, since I’m generally only spending about an hour on the treadmill over a day.

My M5 MacBook Air is proving to be quite functional as a work laptop. This is the first Apple Silicon computer I’ve owned. I have the 32gb model. I haven’t experienced any performance issues, and have even used some local Ollama models for certain things. The only real issue I’ve had is Firefox filling all my memory after days or weeks of not restarting the browser.

I do feel like this experiment of using this writing app for writing the newsletter is working fairly well. It’s basically what I used to do when I would write daily pages—just write, write, write, no stopping, even if I’m writing about how I don’t know what to write about.

I do still feel that editing is where I currently fall down in my writing. That’s where the anxiety can start becoming a problem.

Maybe writing by hand is an even more important practice than it used to be, now that pretty much anything can be theoretically done with AI. A way to make sure we don’t forget how to think.

I know some people have advocated for also dedicating some time to hand-coding so you don’t forget how to code. I’m not sure how I feel about that. Is that like advocating for spending time each day writing by hand or traveling by horse? Like, yeah, that’s a skill you could lose, but it’s so superseded it isn’t actually a practical problem if you lose it?

I guess the question would be what are the stakes if I’m wrong. Like if I forget how to code by hand, completely lose that skill. How would that hurt me? How would that hurt my work? Would I be less good at determining the quality an LLM outputs if I’ve forgotten how to code by hand?

The Job Search Begins

Tue, 23 Jun 2026 17:56:44 GMT

Given we don’t currently have client work coming in, I’ve decided it’s time to start looking for traditional employment again.

I’m using Beeminder to track my job search activities—one for putting time into the search, one for submitting applications, and one for doing different actions related to the search, each action being worth some number of points:

Qualify a verified target = 1
Tailored application (CV adjusted + letter naming the role, actually submitted) = 3
Outreach (recruiter ping / intro ask / message to someone at a target) = 2
Follow-up sent = 1
Interview prep block, 30+ min = 2
Interview attended = 5

I’m using AI to tailor my resume to each job posting and to write the cover letter for each. Is that a cringe thing to do? I do feel some shame about it. I’ve been justifying it since the whole process feels quite artificial, and the required self-promotion is so painful for me. Also I do carefully read the resumes and cover letters to ensure everything is accurate. But feel free to tell me I’m still way off track for doing it this way.

I’ve never gotten a job through an interview process. The three more-or-less traditional jobs I’ve had to this point have all been acquired through personal connections with people at the company. I have done a few interviews with different companies in the past, but none of them resulted in offers.

So all that being said I’m not sure what to expect as far as the number of applications I’ll need to submit in order to land an offer. I understand job postings are now getting hundreds of applications since it’s so easy to automate now. I’m hoping the fact that I’m making sure I’m actually a good fit for each role I’m applying to will mean I won’t have to put in that many applications.

Currently I’m aiming to submit one application per day. I think I may increase that number, though. Again not sure what number of applications per day I should be aiming for.

I’m guessing I may need to get back on LeetCode and start studying for interviews. Probably beemind it, too. I think I used LeetCode for a little while when Amazon gave me an interview back when the big tech companies were recruiting like crazy. Or maybe I can find another way to study without needing to pay up for a LeetCode subscription.

The trip to Europe I mentioned previously is now quite a bit more uncertain. I’m aiming for a remote job or a job with relocation assistance to Sweden, so hopefully I’ll still be able to spend some time in Europe in some fashion. Remains to be seen what that will actually look like.

With the lack of client work I’ve been putting a lot more time into TaskRatchet. I’ve fixed bugs, improved uptime instrumentation, and added a Todoist integration. I’m hoping to keep up this velocity while searching for a job.

Finding Clients in the Age of AI

Tue, 16 Jun 2026 17:04:45 GMT

In the past couple of days I’ve had conversations with two different friends, both contractors, about the impact of AI on their ability to find and keep clients. One says that AI has decimated their ability to find steady contract work. They other says it’s created opportunities for them to increase the demand for their services.

I haven’t seen a noticeable impact on my own work. Probably because I’ve only ever had a very small number of clients who were already unsteady sources of contracts. Though would any of them actually tell me if the reason they decided not to give me a project is because of AI? Doubtful.

My friend for whom this all seems to be working out is Christopher Moravec. He has positioned himself as a thought leader on the responsible use of AI in software development. He attributes his current success to this positioning.

It seems clear to me that AI is resulting in more-or-less cold channels for client acquisition being flooded. That would include email, LinkedIn, Upwork, etc.

It’s plausible that this means anyone who can actually prove they are expending human effort on starting a business relationship will have an advantage over those who are only pretending to. For example shooting a short personalized video and including it with a response to a job posting.

My problem is that I wasn’t doing cold outreach before everything started changing, so I don’t expect I’ll start now, regardless of what new opportunities present themselves.

Alternatives to the Big Social Networks

Tue, 09 Jun 2026 17:58:51 GMT

I’m still thinking about how to do better at building social connections. Thought I’d share a few of the things I’ve used that are alternatives to the big social networks—Reddit, Facebook, YouTube, Twitter and friends. I don’t currently use all of these, but at least tried them at some point in the past.

I’ve enjoyed Goodreads in the past because it’s a single-topic social network. I think there’s something valuable about that, where you know what you’re going to get when you log in—a feed of what your friends are reading or want to read in the future.
The StoryGraph is an alternative to Goodreads. I used it briefly, it seemed nice. Over time my privacy has become more important to me, so I’ve stopped using the share-your-reading websites.
You could argue that LinkedIn is similar to Goodreads as a single-topic social network—in LinkedIn’s case, business. But that doesn’t really work in practice, since LinkedIn lets you post about whatever you’d like, business-related or not. Plus, I’m not a fan of the AI-crafted self-congratulatory posts that plague the platform.
More recently I’ve gotten back on the RSS train with Feedly as a way to stay off Reddit. I like that it’s only the stuff I subscribe to, and that I can set the default view to be reverse chronological.

I’m working on a more-thorough comparison in this spreadsheet. Feel free to reply with any input you might have—alternatives I haven’t listed, columns I should add, etc.

Rethinking Social Networks

Tue, 02 Jun 2026 18:04:18 GMT

It’s been a little while since I last wrote. My brother and I moved states to spend a few months with our parents. Later this year he and I plan to spend a year doing the digital nomad thing in Europe. Broaden our horizons a bit.

In my spare time I’ve been building a new side project, wiblet.net, mostly motivated by the coming trip. I refuse to use Twitter or any product owned by Meta. Which means keeping up with friends who aren’t nearby can be difficult.

I’ve been trying to think about what would make a good social network, one that I wouldn’t feel bad about using.

It wouldn’t have algorithmic feeds.
It would only encourage interaction between actual friends, not distant strangers.
Everything would be private by default.
It wouldn’t encourage attention-maxing with likes or shares.
It would encourage non-verbal, creative self-expression.
It wouldn’t push non-consensual exposure to potentially-triggering topics such as politics and religion.
It would encourage active (if bite-sized) interaction with friends, rather than passive consumption of acquaintances’ lives.

Wiblet.net is my first experiment exploring what that might look like. I was hoping it would be something like a mix of GeoCities, MySpace, and Myst. A place where friends could collaborate on shared worlds to explore and interact in. What it’s turned out to be so far is a social scrapbook. So maybe not quite what I was going for.

On other possible approaches, I’ve been thinking about an idea I’m calling micro-attentions, and what a social network built around them might look like. Basically the idea being a platform that takes the Facebook poke and runs with it. Smile, hug, high-five, surveys (back to BuzzFeed?) or just simple shared questions, sharing a photo or a drawing, etc. Each micro-attention would be shared between only two people. And somehow these interactions would be encouraged through gamification or statistics or shared play or creativity. Maybe growing a garden or a forest where each plant represents a connection being strengthened. Something to make using the product feel satisfying and meaningful.

I don’t know, I’m still mulling.

MiniMax M2.7, OpenAI's Symphony, Etc

Wed, 13 May 2026 16:11:11 GMT

I’ve been continuing to use my Claude Max x20 plan. I haven’t hit any limits yet.

I’ve been quite impressed with Matt Pocock’s improve-codebase-architecture skill. I’ve used it on a couple of repositories where I’d erred on the side of vibing and the skill’s ability to clean things up and create a much more sensible codebase structure has been very helpful.

I’m intrigued by OpenAI’s symphony spec for agent orchestration. I’ve made a start at setting up a system along its lines for myself, but haven’t gotten it to where I could actually use it yet.

A note from a friend got me looking into MiniMax M2.7. Its quality-to-price ranking is quite impressive, nearly reaching Opus 4.7 performance at a much lower per-token API price. Though that comes at the cost of sending your code to a company in China.

According to the same website, publicly-available GPT and Gemini models are currently ahead of Claude in terms of quality. I don’t know what I’ll do with that information given at least so far Anthropic feels like a more trust-worthy company compared to Google or OpenAI. It’s kind of amazing how sketchy the frontier labs seem to have managed to become.

Business Incentives of AI Token Pricing

Wed, 06 May 2026 16:22:17 GMT

For most of my time using Claude Code I’ve used it via Anthropic’s API rather than using a Claude subscription. I briefly tried the base Max plan but found myself out of usage almost immediately, and went back to API usage.

That usage has been steadily increasing as I’ve developed my workflows and tried different harnesses. It recently got to the point where I was regularly spending more than $100 per day on Claude tokens.

This is fine when most of that cost is passed on to clients. However recently one of our clients reduced the amount of work they’re sending us, meaning a higher percentage of that usage moved to non-billable internal projects. That proved to be unsustainable.

My brother has been using a Claude subscription without issue, so I decided to give it another shot. I’m now on the Max 20x plan, and it seems to be working well this time.

One unfortunate consequence of this switch is that I’m effectively no longer allowed to use third-party harnesses with Claude Code. So that means saying goodbye to Cursor 3 and Zencoder for the time being. Though Warp has recently added enough integration with Claude Code to at least give a hint of some of the things I liked about using third-party harnesses.

The biggest thing I’m missing so far is the ease with which Zencoder allowed me to create new tasks with their own worktrees. Claude Code does have its own worktree support, but it’s always felt more intimidating to me to get it to work well. I guess this is an opportunity to push through that and see just how good Claude Code’s worktree support can be.

It’s been interesting trying to come to grips with the incentives that this new way of doing software development sets up. As a more-or-less solo freelancer, I’m used to my productivity being almost entirely untethered from my wallet. If I want to produce more results, I can simply spend more time coding. No additional expenditures necessary.

Now that I’m using AI for programming, that’s much less the case. I can theoretically produce an unlimited amount of output, quality of my workflows allowing. But once I max out my subscriptions, that productivity additionally scales my costs. It’s more like having employees, where I could theoretically hire as many employees as I wanted to scale productivity, but it’s expensive to do so.

Except it’s not quite like employees.

Employees are hard to scale up and down. You have to find them, interview them, hire them, and perhaps fire them. AI, on the other hand, scales up and down without friction.
A new employee needs training and experience to realize their potential productivity at a task, whereas a cloned AI agent immediately has the same productivity as all previous agents.
An employee is likely to be specialized in a few tasks, and moving them to a different task can be costly and disruptive. While AI resources are fungible, easily repurposed for whatever the current needs.

This creates a tighter coupling between a task’s profitability and the incentives to scale the execution of that task. With AI, if a task makes you money this month, you can spin up an unlimited amount of capacity to exploit that opportunity. And if next month it stops making you money, you can spin all that bandwidth back down to zero.

That’s different from scaling productivity with employees, where hiring many employees results in training costs, ongoing pay if you keep them on, and human suffering if you fire them.

I think historically businesses have simply split the difference. Hire enough employees to exploit most of the operation’s typical opportunities, and give them lower-value work during the times where those opportunities are less abundant. Accept some level of firing and hiring, but keep it manageable. Some lost opportunity, some wasted bandwidth, but hopefully not too much of either, most of the time.

AI promises to solve those issues. Perfect exploitation. Perfect efficiency. Societal costs still uncertain.

I am no longer a programmer

Tue, 21 Apr 2026 17:45:47 GMT

I knew it was more or less inevitable. But I hadn’t realized it had already happened until a couple of days ago when I was talking shop with my brother. I realized I haven’t written code by hand for months.

What finalized the change was when I started using Claude Code with Opus 4.5. I was already using agentic coding tools before that point. But they were still unreliable enough that I’d go back and forth between working with the agentic coding tools and working on the code myself.

My current workflow no longer requires this.

I ask an agentic tool (Claude Code, Cursor, or Zen Coder) to implement a change to the project.
I spot-check the code changes as the agent works to make sure they look reasonable.
I ask the agent to verify the change and/or verify it myself.
I put the agent’s work through multiple cycles of automated code review (a separate local agent; GitHub PR review bots such as CodeRabbit and GitHub Copilot).
I review the changes in the final PR.
Depending on the project, I may or may not request an additional human review from a teammate.
I deploy.

So if I’m no longer a programmer, what am I?

I now spend my time:

Grooming issue backlogs
Managing running agents
Reviewing code
Looking for new tools and processes to ensure product quality doesn’t suffer
Communicating with teammates and clients
Further automating business tasks

I guess I was right. AI has turned me into a manager.

TaskRatchet Database Switch, Making AI Skills Autonomous, Etc

Tue, 14 Apr 2026 16:46:54 GMT

After three months of sporadic work, yesterday I finally moved TaskRatchet from Firestore to Neon. TaskRatchet was in maintenance mode for about an hour and a half during the migration. Fingers crossed that the change hasn’t introduced too many bugs.

Reasons for the switch:

I plan to move the TaskRatchet back-end to Cloudflare, and Firestore isn’t very compatible with Cloudflare.
Firestore is a proprietary database, which means lock-in issues. Neon uses PostgreSQL, so future moves should be much easier.
Firestore restricts the kinds of querying I can do, which is frustrating when I’m trying to optimize cost and performance.
PostgreSQL is widely supported for tooling such as ORMs.

I’ve been experimenting with pushing my AI skills to be more autonomous. Example: I’ve rewritten my resolve-pr-feedback skill to handle AI review feedback automatically instead of waiting for my input after each feedback item. It then commits and pushes any feedback, waits for AI reviewers to submit new reviews, and repeats the cycle up to three times. It still, however, requires my input on any human-submitted feedback.

I’m continuing to use the new Cursor 3 agents interface. It’s a significant improvement over using Claude Code when multitasking. Three things I’m hoping Cursor fixes soon:

It currently has a bug where restarting Cursor results in archived conversations reappearing in the agents window sidebar.
The in-Cursor browser is not scoped to the AI session. This means that if one agent uses the browser MCP to navigate to a page, any other agents who were trying to use the browser now see the new page instead of what they may have been working on.
Worktree support is janky. I would like to be able to have multiple sessions in the same repo, each with its own worktree, and for which worktree each session is using to be clearly visible. Currently this is not the case. Agents can use different worktrees. But the agents are managing their worktrees manually, unsupported by the UI or any IDE-specific logic.

CodeRabbit now supports usage-based billing, something I’ve long wished they had. Unfortunately it doesn’t replace their per-seat pricing. But it at least provides a way to prevent CodeRabbit’s rate-limiting from slowing development.

Consciousness Is a Rounding Error

Fri, 10 Apr 2026 17:39:25 GMT

Recently I’ve been thinking more about the nature of consciousness and what I as an individual can know about it.

I previously posted some thoughts about specifically whether we can exclude the possibility that AI in its current form is conscious.

The more I think about this, the more I believe that the amount of continuous consciousness I can confidently say exists is vanishingly small.

What do I mean by continuous consciousness? Subjective experience which persists and is tied to a specific individual. The idea that there’s a “me” inside me and that this “me” experiences subjective sensations, and that this same “me” continues to exist and experience these sensations over some period of time, whether that be minutes, weeks, or an entire lifetime.

The typical story I hear around this type of consciousness is that I as an individual can confirm that this type of consciousness exists at least in me, since I can introspect on that experience directly. Whereas I have no way to confirm whether anyone else has this experience since in theory they could be machines which are simply acting as if they have subjective experience but in reality do not. Such an entity is referred to as a “philosophical zombie.”

CGP Grey has a video called “Teleportation Would Kill You” which ends up connecting to this idea. Say you have a Star Trek-style teleporter. It moves you from one location to another by deconstructing your body into its molecules. It then puts you back together again somewhere else, in the exact same configuration as previous to the teleportation. The person at the destination feels that it is you. It has all your memories. It remembers walking into the teleporter as well as walking back out at the destination. But a strong argument can be made that it is not you. It is a new person, and the original person is dead.

Grey then points out that, even though we don’t have teleporters, we do have similar breaks in consciousness. When you go to sleep each night, setting aside REM sleep, your consciousness ceases. There’s no way to prove that the consciousness you had the previous day is the same conscious “me” you wake up with in the morning. Perhaps every conscious “me” only gets one day, then dies never to experience again, only to be replaced by a new conscious “me” the next day with all the memories of all the previous “me’s” that have existed for this individual.

What’s had me thinking lately, though, is that there doesn’t seem to me to be any good reason to stop there.

There’s a concept in neuroscience called “the subjective present,” that period of time which feels to you to be “now.” Here are a few papers which I have neither read nor skimmed but are linked here in case you’re less lazy than I am:

It seems to me that if I accept the idea that subjective experience can only be confidently confirmed by introspection, then the length of that subjective experience which can be confirmed is that of the subjective present, since by definition this is the duration of consciousness accessible for direct introspection. And this duration may be as short as only two or three seconds.

And if that’s the case, then there’s no way to rule out that the subjective “me” may have a lifetime not of a single day, but rather of two or three seconds.

I now think that for a being to have a subjectively-irrefutable experience of long, continuous consciousness does not require that being to actually have long, continuous consciousness. It only requires that the being has the experience of a subjective presence, however short, and the memory of many previous experiences of similar subjective presences.

That’s it.

Perhaps Clive Wearing, the man with no short-term memory, experiencing every moment of every day as an awakening from nothingness, has a more accurate experience of reality than anyone else, each fleeting “me” fully aware of its birth into conscious existence.

Other than out of morbid fascination there isn’t really much of a reason to take these possibilities too seriously. They’re unfalsifiable. However, the fact that there is so little of even my own conscious experience that I can confidently claim makes me even more inclined to humility when considering the nature or existence of consciousness in other entities, biological or not.

State of the Workflow: AI for Client Programming

Tue, 07 Apr 2026 17:40:54 GMT

(Title stolen from the Cortex podcast)

My team and I have been using Opus 4.6 for most of our work for a while now. This really kicked into gear when our main client requested that our team use Opus for all work for them going forward. This was based on another developer who works for them telling them that tasks in their codebase that used to take weeks started taking days when he switched to Opus. We’re seeing similar results.

For quite a while now I’ve been using Claude Code exclusively. It’s great, though it has had some pain points, primarily when it comes to multitasking. Keeping track of multiple terminal pains with different Claude Code sessions running is difficult and inefficient.

Recently Cursor released Cursor 3, including a new multi-workspace agents interface. I’ve only started using it today, but it’s exactly what I’ve been lacking.

One interface displays all my AI coding sessions in a sidebar for easy switching.
Each session in the sidebar indicates if its running, done, or waiting for intervention.
Cursor supports Opus, so I don’t have to use a different model.
Cursor supports hooks, so I was able to easily tie it into our existing team-wide token tracking system.
So far it seems to have good keyboard shortcuts support.
It supports all my Claude Code skills, so I don’t need to do any fussing to transfer my existing skills.
It isn’t repo-specific, so I can easily work in multiple sessions across multiple git repositories at the same time.
It includes code review features so I can review code diffs locally before pushing to GitHub.

Our token tracking system consists of Claude Code and Cursor hooks that submit token counts along with the repo the session occurred in to an API endpoint. These session stats are then stored in a private Baserow instance. When I need to bill a client, my billing tooling queries this session data for the sessions associated with the specific client’s GitHub repositories, tallies the tokens used within the billing period, and uses that to calculate how much the client owes in token usage based on model rates.

The skills I find myself using on a regular basis:

client-report for generating detailed weekly reports of what our team has been doing for a client
daily-standup for generating detailed summaries of what the team has been doing in the past day
fix-ci for fixing failed GitHub Actions jobs
obsidian for quickly giving an agent access to my notes
pr-triage for working through pull request backlogs
resolve-pr-feedback for working through pull request feedback, both human and automated

In addition, whenever possible I add comprehensive skills to each repository I’m working in. These skills provide documentation that can be loaded when relevant as well as documenting and automating different tasks and processes that are likely to be needed in the repository going forward.

Pretentious, self-indulgent navel-gazing

Wed, 01 Apr 2026 08:42:04 GMT

It’s nearly 4am here. I woke up with mild heartburn. Before I could go back to sleep I started thinking about this newsletter. Eventually I decided to get up and write my thoughts if I was going to be awake anyway.

Since last issue, I’ve been thinking about what it means to write well, what it would mean for me to write well.

I think the fact that humanity has recently invented a technology that can do all the writing we’d ever want on command has forced the question. Like the kid in math class who asks why they should learn long division when a calculator can do it just as well and faster.

My last issue, in which I admitted to experimenting with using AI to coach my writing, was nearly a month ago. I usually publish weekly. My absence is partially due to recent work deadlines, but also to becoming anxious whenever I think about allowing an LLM to socratically chisel my writing into a polished caricature of my thoughts with little room for uncertainty and ambivalence.

I still believe that the purpose of writing is to connect human with human, author with reader, mind with mind. And, if that’s the case, to write well is to pour myself into the page.

The issue is that often I’m not sure I want to do that. I’m an overweight divorcé with questionable hygiene practices who until recently rarely left his apartment. Why should I voluntarily poor myself onto the internet for all to see?

So I’ve rushed through it like an unpleasant medicine. Roughly thirty minutes from start to publish, too little time to overthink things, to get in my own way.

I thought that an AI writing coach would allow me to step beyond that. It would add structure that would improve my writing beyond publishing messy first drafts.

Unfortunately, the result was a piece of writing that had less of me in it than a messy first draft would, perhaps because I’m so messy and unfinished.

I want to respect you, the reader. But at this point it feels more disrespectful to give you something that has the messy parts of me patched out than it does to send you a first draft. Neither is ideal. But at least a first draft still has the potential to be authentic connection.

I guess this means, for now, I’m going back to not using an AI writing coach. Perhaps I’ll try it again in the future, create a new Claude skill, experiment with a new process. But at least for this issue, for better or worse, an unfinished draft will have to do.

Writing with AI, Responsibly

Wed, 11 Mar 2026 16:48:32 GMT

Starting with this issue, I’m using AI to help me write this newsletter. Please don’t stop reading if this is upsetting–I think I can win you back. Allow me to explain how I’m using AI in concrete terms, and then address head-on what I imagine will be your objections.

First and foremost: None of the words in this newsletter will be written by an LLM. They will remain my words and my words only.

With that clarification, what has changed is that I’m now using AI as a writing coach.

The skill I’m using does this by keeping its own separate markdown file in which it captures everything it understands about what I’m trying to say. It then challenges any ambiguity in my writing, any missing arguments or lack of rigor, and pushes me to correct these issues in my own words.

The impression I get when hearing people talk about using LLMs for writing is that they believe it to be inauthentic, lazy, and error-prone. The workflow I’ve described is intended to achieve the opposite on all counts.

Authenticity: I’m committed to preserving the connection between my mind and yours, mediated only by my words. For this reason, I won’t allow my AI workflow to contribute its own words, but only to challenge my writing and thinking, leaving the correction of the issues it identifies to me.

Effort: This workflow makes writing this newsletter take significantly more time than it has in the past (confirmed, as I’m using it to write this issue!). It forces me to engage more deeply with what I think and what I’m trying to say. That engagement takes more time, more effort.

Accuracy: The AI’s role is to challenge where my writing is poorly thought-through or communicated. It does not provide its own information or evidence, side-stepping the issue of AI hallucination.

To this point, what I’ve published in this newsletter have been stream-of-consciousness first drafts. This has allowed me to tiptoe back into writing when doing anything else would have been anxiety-inducing for me.

But I don’t want to leave my writing at this point. I want to begin pushing the quality of what I publish, and I hope that this new workflow will allow me to achieve this.

Here’s the skill I’m using if you’d like to see exactly how it works and perhaps try it for yourself.

Instructions for using skills with various tools:

Skills, Bills, and Aligning Incentives

Wed, 04 Mar 2026 18:27:24 GMT

Claude Code skills are eating my development process. They can be used to assist me with basically anything I do as a developer.

Documenting codebases
Reviewing business finances
Generating development reports for clients
Summarizing recent team activity
Grooming GitHub issues
Working through PR review backlogs
Organizing file systems
Fixing CI failures
Testing features and bug fixes across environments using Playwright
Etc

I find that they have big advantages to other ways I might try to solve the same issues.

They crystallize knowledge and give distinct pieces of knowledge handles, reducing the demand on my long-term memory.
They allow for creating flexible, interactive workflows for given tasks, allowing me to maintain focus and reducing demand on my short-term memory.
They are easily improved over time without switching contexts. A skill didn’t work the way I’d like it to? Just ask the system to update it to behave better.
They can be designed to be self-improving, by instructing them to update themselves on each use.
They don’t pollute AI coding tool context windows, since AI tools only pull them in when they are relevant (or when you’ve explicitly pulled them in as a slash command).

With all these advantages, I’ve been doing my best to lean fully into using them. I’ve created many personal skills that are available in any project I work on, and I’ve started moving other forms of developer documentation and coding agent context files to skills in the projects where I have the leeway to do so.

Our current clients are billed hourly. This meant that, if we didn’t do something to address the issue, we’d be disincentivized to use agent skills to the extent that we should. No one wins if we cheap out and take longer to do poorer work at a higher price.

To address this, I’ve set up a bare bones system that allows me to track the tokens I spend for each of my clients and then bill them for those tokens separately from our hours.

Currently its big downside is that it only runs on my machine. In the future I’ll need to figure out a way to send the data to something on the web so that any subcontractors I’m working with can also track their tokens and have them billed and reimbursed.

Links Roundup

Opik — LLM observability platform
EveryInc/compound-engineering-plugin — Claude Code compound engineering plugin
jayminwest/mulch — Structured expertise files that accumulate over time, live in git, work with any agent
jayminwest/kotadb — Local code intelligence API for AI dev workflows (Bun + SQLite)
jayminwest/agentic-engineering-book — Growing guide to building agentic systems
stephendolan/ynab-cli — YNAB CLI with JSON output optimized for LLMs
remotion-dev/remotion — Make videos programmatically with React
tambo-ai/tambo — Generative UI SDK for React

Vibe Kanban, Claude Code Skills, Dotfiles, Etc

Wed, 18 Feb 2026 16:25:32 GMT

Thoughts on Vibe Kanban

I’ve done some experimenting with Vibe Kanban. There are things I really like about it. The main one being that it seamlessly handles creating new git worktrees for each task attempt.

I can’t help but thinking, though, that having to use a GUI to interact with the tool just slows me down at this point. My pr-triage and resolve-pr-feedback skills for Claude Code have convinced me that skill-based workflows initiated directly within Claude Code can be incredibly powerful.

I could almost leverage Vibe Kanban for this type of workflow, too. It has an MCP that lets you list and add tasks. But it doesn’t allow for creating and otherwise managing attempts on a task. If it did, I could build a Claude Code workflow around it and allow it to continue managing the git worktrees and running subagents autonomously in the different worktrees.

So that leaves me to try to reproduce that functionality, too. I haven’t yet succeeded. I’ve been attempting to get a skill working in my TaskRatchet repository. I’ve added a dev container to the repo and added a project-specific skill to attempt to allow for parallel task attempts pairing the dev container with task-specific worktrees.

If I succeed in getting this skill to be functional, I’m unsure if it will need to remain specific to a single git repository. I figure I’ll just focus on getting it working within one repository and then assess what it would take to generalize.

Dotfiles as Bare Git Repository

I’ve updated how I use my dotfiles repo to use a bare git repository. The main advantage of this change is that I no longer need to keep an exhaustive list of files in the repo as exclusions in my .gitignore file, since all files in my home directory are ignored by default until explicitly added using git add.

Links Roundup

Testcontainers - “Testcontainers is an open source library for providing throwaway, lightweight instances of databases, message brokers, web browsers, or just about anything that can run in a Docker container.”
Playwright CLI - “This package provides CLI interface into Playwright. If you are using coding agents, that is the best fit.”
CodeQL - “Discover vulnerabilities across a codebase with CodeQL, our industry-leading semantic code analysis engine. CodeQL lets you query code as though it were data. Write a query to find all variants of a vulnerability, eradicating it forever. Then share your query to help others do the same.”
Jules - “ules is an experimental coding agent that helps you fix bugs, add documentation, and build new features. It integrates with GitHub, understands your codebase, and works autonomously — so you can move on while it handles the task.”

Experimenting with Vibe Kanban

Tue, 10 Feb 2026 18:02:57 GMT

I’ve been experimenting some with using Vibe Kanban. It gives you a local kanban interface where you can track coding tasks and trigger coding agents to work on them locally using git worktrees. It also provides a local MCP server that you can connect to your other AI tools list and add tasks.

I like the fact that this provides a private space for planning programming tasks. The chunks of a task that make sense to assign to a coding agent are likely often different than what would be ideal for syncing with other humans on something like GitHub Issues or Trello.

One thing that Vibe Kanban is still missing is a way to chat with an AI about an issue within the kanban interface. I enjoy being able to ask CodeRabbit questions inside my GitHub issues and collaborate with the AI on planning the issue.

I guess with Vibe Kanban the intended way to solve this is with its MCP server. Instead of chatting with the AI about a task within that task’s interface, chat with your favorite AI outside of Vibe Kanban about the task. And presumably that agent can then use the MCP server to update the task with new research and planning.

I did run into a bit of a hiccup with its use of worktrees. It had created a worktree for a task branch (as it always does). Later I wanted to do something manually on that branch. I went to the main project folder and attempted to checkout the branch. Git then complained that I couldn’t do that because I already had a worktree for that branch. I ended up going back to Vibe Kanban and using its AI interface to do what I was going to do there. Perhaps if I were more comfortable with git worktrees generally this wouldn’t have tripped me up like it did.

My AI Illustration Workflow

Tue, 03 Feb 2026 16:01:42 GMT

This image was generated using the workflow described in this post

Over time I’ve been slowly improving the workflow I use to generate AI illustrations for these newsletters.

In the past I would craft my own prompts for the Bing image generator or the AI image generator built into Substack. But I found that I wasn’t especially good at coming up with good prompts reliably.

I’ve found that Claude is much better than I am at prompt engineering. So for a while I would copy my articles into Claude and ask it to suggest image prompts for the article at several levels of abstractness. I’d then copy the prompts back into Substack’s image generator and see which results I liked best. This worked better, but was quite tedious to do for each article.

Currently I use a local shell script to both generate the prompts and then generate illustrations from these prompts for me to choose from.

I run the script in my terminal.
The script asks me for the text of my article. I paste the whole article, and add “END” on the next line to signal the script to proceed.
The script sends a request to Claude Haiku 3 to extract key themes and concepts from the article.
The script loops through a list of styles, asking Claude Haiku 3 to produce an image prompt for each style given the themes and concepts extracted in step three. It makes two such requests for each style.
The script pauses to allow me to review and approve the generated prompts.
Once approved, the script proceeds to generate an image for each prompt using Z-Image-Turbo running on my local machine.
I review the resulting images and select one to be used as the article’s illustration.

I’ve found this workflow to reliably and efficiently produce high-quality illustrations for my articles at very low cost. The Haiku 3 requests cost me less than a penny per run, and the actual image generation is ~free since it runs on my local machine.

One limitation of this approach is that it requires you have a computer beefy enough to run an image generator locally. I have an NVIDIA GeForce RTX 3060 with 12GB VRAM which makes this practical. But without a dedicated graphics card I’d probably be back to using a hosted image generator, perhaps using OpenAI’s API. But of course that would mean higher cost per run.

Here are the illustrations that were generated for the above text:

And these are the prompts that produced them, from bottom right to top left:

“Oil painting of a human hand and an artificial intelligence robotic hand clasped together against a backdrop of interconnected gears, circuit boards, and computer components. The palette features muted, earthy tones with highlights of cool metallic grays and blues, conveying a sense of collaboration and technological integration. Visible, impasto brushstrokes create a textured, documentary-style surface, and the composition is balanced with a focus on the central intertwined hands. Dramatic, raking light casts strong shadows, emphasizing the depth and materiality of the scene.”
“Oil painting of a human hand and an AI-generated robotic hand reaching towards each other, their fingertips almost touching. The hands are rendered in a highly realistic, detailed style with visible brush strokes and a muted, earthy color palette of browns, ochres, and grays. The background is blurred and hazy, creating a sense of depth and focus on the central interaction between the human and machine. Subtle highlights and shadows emphasize the texture of the skin and metal, while the composition creates a sense of tension and collaboration between the two entities.”
“Oil painting of a human hand collaborating with a metallic, robotic hand emerging from a swirling cloud of colorful digital data. The composition is balanced and symmetrical, with the human and robotic hands meeting at the center, fingers intertwined. The palette features rich, earthy tones of brown, ochre, and sienna, contrasted by vibrant splashes of blues, greens, and purples that suggest the flow of digital information. The brushwork is smooth and blended, with visible yet controlled impasto texture that adds depth and tactility to the painting. Warm, directional lighting from the upper left casts dramatic shadows and highlights the collaborative nature of the hands, emphasizing the harmony and synergy between human and machine.”
“Oil painting of an abstract representation of the collaborative creative process between human and AI. The canvas depicts an energetic, swirling composition of overlapping shapes and gestural brushstrokes in a harmonious color palette of warm ochres, deep blues, and muted greens. Visible, expressive brushwork creates a sense of movement and dynamism, evoking the iterative nature of prompt engineering and workflow optimization. The overall mood is contemplative yet resolute, reflecting the pragmatic and solution-oriented approach described in the article. Areas of the canvas feature sharper, more defined forms juxtaposed with areas of loose, ethereal brushwork, symbolizing the interplay between human intent and machine generation. The painting cultivates a sense of collaboration, experimentation, and the gradual refinement of a creative process.”
“Oil painting of an abstract, impressionistic representation of the collaborative interplay between human and AI in the creative process. Warm, earthy tones of ochre, sienna, and umber predominate, with flashes of vibrant primary colors symbolizing the sparks of innovation. Loose, expressive brushstrokes convey a sense of fluidity and dynamism, as if the paint itself is a physical manifestation of the iterative workflow. Subtle textures and blended edges create an atmospheric, dreamlike quality, evoking the experimental nature of the process. The composition features geometric shapes and forms that suggest both structure and flexibility, hinting at the technological and conceptual frameworks underlying the AI-assisted illustration generation. An overall sense of balance and harmony emerges, reflecting the synergy between human intuition and machine intelligence.”
“Oil painting with visible brushstrokes depicting an abstract, swirling composition of vibrant colors. Shades of blues, greens, and golds flow together, creating a sense of movement and energy. Pockets of light and shadow weave through the canvas, adding depth and dimension. The overall impression is one of experimentation, iteration, and the harmonious collaboration between human and machine.”
“Oil painting with visible brushstrokes depicting a surreal, semi-representational landscape. Muted earthy tones of ochre, sienna, and umber, accented with hints of cool blues and greens. Textured, impasto surfaces create a sense of depth and materiality. Fluid, gestural forms suggest the interplay of human and machine elements, with abstract shapes and symbols hinting at the collaborative creative process. Soft, diffused lighting casts a contemplative, experimental mood over the scene.”
“Oil painting with visible brushstrokes depicting an abstract representation of the collaborative creative process between human and AI. Muted, earthy color palette of ochres, siennas, and deep blues, evoking a sense of pragmatism and technical exploration. Textured, impasto surfaces suggest the iterative, experimental nature of the workflow, while gestural, semi-representational forms symbolize the interplay of human intent and machine generation. Warm, soft lighting casts a contemplative atmosphere, hinting at the gradual refinement and optimization of the process over time.”
“Oil painting with heavy impasto texture depicting an abstract, symbolic representation of the collaborative creative process between human and AI. Muted earth tones of ochre, sienna, and umber with flashes of metallic gold and silver, conveying a sense of technical sophistication and pragmatic problem-solving. Amorphous, gestural shapes and forms intertwine, suggesting the iterative nature of prompt engineering and workflow optimization. Visible, energetic brushstrokes create a sense of movement and experimentation. The composition is balanced but with areas of visual tension, mirroring the challenges and breakthroughs described in the article. Soft, directional lighting casts shadows that add depth and a contemplative atmosphere.”
“Oil painting with impasto technique depicting abstract symbolic elements representing the interplay between human and AI in the creative process. Muted earthy tones of ochre, sienna, and umber with touches of metallic gold and silver accents. Textured, gestural brushstrokes convey a sense of motion and collaboration. Dominant central form suggests a collaborative entity, with surrounding fragmented shapes and lines hinting at the iterative workflow. Hints of technical diagrams or schematics in the background allude to the logistical considerations. Atmospheric lighting casts dramatic shadows, evoking a contemplative, experimental mood.”
“Oil painting with a surrealist, metaphorical style. In the center, a large, organic shape resembling an open book or unfolding petals, rendered in warm, earthy tones. Within this shape, fragmented geometric forms in shades of blue, purple, and metallic accents float and intersect, suggesting a complex technological or digital landscape. The background is hazy and atmospheric, with loose, textured brushstrokes in muted greens, ochres, and grays, creating a sense of depth and mystery. The overall composition conveys a balance between the natural and the artificial, the human and the machine, in an enigmatic and thought-provoking manner.”
“Oil painting of a surreal, dreamlike landscape where organic forms and geometric shapes coexist in a harmonious balance. The composition features a central focal point of a large, abstract shape resembling a human figure, rendered in muted earth tones and textured brushwork. Surrounding this central element are swirling, ethereal forms in shades of blue and green, suggesting the flow of energy and ideas. Subtle hints of warm ochre and amber tones create an atmosphere of contemplation and introspection. The overall style is dreamlike and evocative, with a sense of the subconscious and the interplay between the human mind and the creative potential of technology.”
“Oil painting with a vibrant, geometric abstract composition. Distinct angular shapes in a harmonious color palette of deep crimson, burnt sienna, and vivid cobalt blue. Visible, energetic brushstrokes create a sense of movement and dynamism. Subtle gradients and blended edges add depth and visual interest. The overall mood is one of balance, innovation, and the collaborative embrace of human-AI creativity.”
“Oil painting with heavy impasto texture and geometric abstract forms in a vibrant, harmonious color palette of deep blues, rich ochres, and vivid greens. The composition features overlapping angular shapes that create a sense of depth and movement, evoking the collaborative and iterative nature of the illustration workflow. Visible, expressive brushstrokes convey a sense of energy and dynamism, reflecting the experimental and problem-solving approach described in the article. The overall mood is one of intentional, deliberate abstraction, capturing the essence of the themes around prompt engineering and human-AI partnership in a visually striking manner.”
“Oil painting with a vibrant, layered color field effect. Warm hues of orange, yellow, and red blended seamlessly, creating a sense of radiant energy. Hints of cool blues and greens emerge from the depths, generating a harmonious interplay of complementary tones. The surface exhibits a thick, impasto texture with visible, expressive brushstrokes that add depth and movement to the composition. The overall atmosphere is one of balance, exploration, and the synergistic collaboration between human and machine.”
“Oil painting with a vibrant, energetic color palette of deep blues, fiery oranges, and electric greens. Loose, expressive brushstrokes create a sense of movement and dynamism across the canvas. Layers of transparent washes and opaque impasto textures build depth and visual interest. The composition features a central focal point with bursts of intersecting lines and shapes that radiate outward, evoking a sense of exploration and discovery. Subtle hints of underlying geometric forms suggest the technical and analytical nature of the creative workflow, while the overall atmospheric quality captures the experimental and iterative spirit of the process. The painting exudes a balance of human touch and machine-generated precision, mirroring the collaborative partnership between artist and AI.”

New Buzz Functionality; Terminal Screenshots

Tue, 27 Jan 2026 17:53:37 GMT

Buzz Schedule

I’ve been working on a new command for buzz: buzz schedule. Here’s what it looks like:

I wanted a way to see how my deadlines fall throughout a day. I find myself needing this when I need to restructure my deadlines because my typical daily constraints have changed.

Terminal Screenshots

Figuring out how to create that screenshot was a bit tricky.

Unfortunately Substack’s built-in code block support isn’t great. It doesn’t have code formatting, and, more problematic for showing off buzz schedule, it wraps by default.

I played around with using Warp shared blocks, silicon, and carbon-now-cli. Warp offers embeds, but it didn’t seem like Substack was going to support that. Silicon complained that it couldn’t detect the programming language I was using. And I couldn’t be bothered to figure out how to initialize playwright on my machine for carbon-now-cli to use.

I ended up using Carbon’s web app to create the screenshot. Painless, quite a bit of customization, and nothing to install. I like it.

Claude Cowork + Links Roundup

Tue, 20 Jan 2026 17:58:33 GMT

Claude just introduced Cowork—a new piece of software for using Claude to help with projects other than programming. From the article:

How is using Cowork different from a regular conversation? In Cowork, you give Claude access to a folder of your choosing on your computer. Claude can then read, edit, or create files in that folder. It can, for example, re-organize your downloads by sorting and renaming each file, create a new spreadsheet with a list of expenses from a pile of screenshots, or produce a first draft of a report from your scattered notes.

I’ve already been working this way for a long time. The workflow:

Navigate to a project folder inside Warp.
Talk to Warp’s AI, allowing it to create, update, and reference project notes as needed.
Warp asks questions, suggests next steps, searches the internet, etc.

That’s it.

I’ve found it to be a super powerful way to work on ambiguous and overwhelming projects. I create a Beeminder goal for spending time on the project, and then plans, research, and task lists develop over time with ease.

It seems like the main advantages Cowork may have over just using something like Warp for this is Cowork’s ability to create files in more document formats and use connectors to other services. I’m not sold that those are big enough benefits for me personally to switch.

Links Roundup

Artificial Intelligence
- Mem - A note-taking application that promises to understand and surface your collection of notes automatically.
Software Development
- Pullfrog - A tool that lets you trigger agent workflows from GitHub Actions. Currently behind a wait list.
- OpenCode - Opensource alternative to Claude Code. I’m thinking about trying it out with a local LLM.
- Sakura - A minimal CSS theme meant for use with bare-bones semantic HTML pages.
- Announcing Vite+: a unified toolchain for JavaScript - An official CLI tool adding additional features on top of Vite.
Society
- Elections are the essential remaining pillar of our democracy - I highly recommend subscribing to this newsletter if you’re concerned about the future of democracy in the United States.
- Nearly two thirds of young Americans are considering leaving the US - According to a survey by the American Psychological Association.
Etc
- The Rebirth of Pennsylvania’s Infamous Burning Town (via Tom Scott’s newsletter) - An interesting article about an abandoned town that’s been reclaimed by nature.
- Ulysses - A long-form writing application for Apple devices.
- PikaPods - A platform for easily and affordably running instances of many self-hostable applications. I’m currently using Render.com for this, though I’m considering making the switch.

Solution for Large Branches: GitButler

Tue, 13 Jan 2026 15:31:53 GMT

I think I may have finally found a solution to my giant git branch issue.

Recap: I have a bad history of creating huge git branches which are then difficult to review. I’ve found it very difficult to maintain the discipline needed to keep branches small. Recently I’ve been exploring ways I could make it easier to break these larger branches down for easier review.

I’ve been working on an AI workflow for this. It’s definitely shown promise. However I’ve found it to be temperamental and easy to break when I make changes to the saved prompt.

I’ve been aware for a little while that there was a piece of software called GitButler that was supposed to make this kind of thing easier. However when I had previously looked into it, GitButler wasn’t yet available for Linux.

I checked again recently, and it now is. And with a little bit of cajoling, it’s now working on my system.

Screenshot from the GitButler website

I think this software may have just eliminated the issue altogether.

Even without this software I could create new branches as I build, of course. But doing so requires a lot of thinking:

Do I need a new branch?
Would the changes I put on a new branch depend on the changes in my previous branch? This determines what I should base the new branch on.
If I make the wrong decision, am I willing to wait for the branch to get reviewed and merged to default? Or do I need to do the work to change the bases of my branches or otherwise figure out the git magic to make the work on the non-merged branch available in my future branches?
Is the work in each branch an appropriate subset whose intent will be clear to reviewers and won’t invite unproductive back-and-forth due to lack of context?
How do I make sure the same changes don’t show up in the diffs on multiple of my PRs, making them unnecessarily difficult to review?
Stacked PRs always sound appealing. Should I try making a PR stack? What tool should I use?

Given all this uncertainty and friction, I usually end up ignoring the question and just staying heads-down in the code. It certainly feels more productive, at least until I actually need to get my work reviewed and merged.

I’ve only been using GitButler for a few days now, but it seems to address all these issues very effectively.

GitButler uses virtual branches, so multiple git branches can be applied to your working tree at once. Creating new branches is extremely easy and doesn’t require shifting existing work around.
While shifting work around isn’t required, GitButler makes it incredibly easy to do when needed. Files, hunks, and commits can all be dragged around. Commit on the wrong branch? Drag it to a different branch. Realize that one branch should actually depend on another? Drag the branch to where it should go in the stack, or to a new column to break it out of a stack.
Since you can have as many virtual branches applied to your working tree as you want, there’s no longer an issue with needing to wait for a PR to be reviewed and merged in order to have easy access to those changes while working on a new branch.
See #2.
Since there isn’t a need to worry about making sure changes from one unmerged branch are available within another, accidentally having the same changes appear in review diffs on multiple branches is unlikely.
Creating PR stacks in GitButler is super easy, and GitButler takes care of keeping an updated list of the PRs in the stack in each PR’s description, and rebasing your branches as needed.

My only concern is that once the novelty has worn off I’ll fail to keep using GitButler and end up with large branches again. We’ll see how it goes!

Iterating on a PR Extraction Workflow

Tue, 06 Jan 2026 16:46:24 GMT

Since I had good success with my PR feedback review workflow, I’ve been trying to create a similar workflow for extracting PRs from an existing large branch.

So far my success has been mixed.

Given my ADHD, switching tasks can be difficult. This often means I end up putting a lot of work on a single git branch and then facing a difficult decision: go through the painful process of breaking it into multiple smaller PRs, or send it as is and hope it doesn’t cause too much pain to whomever ends up reviewing it.

The saved AI prompt I’ve been playing with seems to help quite a bit. Here’s what it tries to do:

Ensure the target branch is up-to-date with its base
Diff the target branch against its base
Identify a subset of the changes on the target branch that could be extracted to a new branch
Explain the selected changes to the user and ask for permission to proceed
Extract and commit the identified changes to the new branch
Ask permission to create a PR from the new branch
Create a draft PR from the new branch

When this workflow works, it feels really good.

I’ve had two main challenges so far:

Ensuring the workflow is followed consistently and the AI doesn’t start skipping steps
Dialing in how well the AI identifies an ideal subset of changes to extract

On issue two, the problem I’ve been dealing with is that the AI focuses on extracting the smallest possible change, even to the point of suggesting things like adding a single unused import statement to a file.

The set of changes to be extracted need to balance several factors:

Is small, but not too small.
Passes CI checks.
Has self-evident benefit to the codebase, or is obviously a precursor to planned changes. This is to reduce the likelihood of the resulting PR being questioned by reviewers.

Currently I’ve been iterating on this prompt as a markdown file that I then paste into Warp. I’m thinking I may switch to trying to set it up as one or more custom skills and/or subagents in Claude Code. This should have a few benefits:

Claude Code skills and subagents may be easier to share.
Subagents may allow me to better control context and tool usage, hopefully improving workflow consistency.
I’m hoping that at some point I won’t need to explicitly invoke the workflow, but simply ask Claude Code to extract a PR and it will infer which skills and subagents to use.

Things I’ve come across related to all this:

Fast PR Feedback Review with Saved Prompts

Tue, 30 Dec 2025 18:21:36 GMT

I’ve been continuing to work to improve at using AI for programming. There are a couple of issues that I find I repeatedly run into now:

My usage of AI can easily result in very large pull requests that are difficult to review.
AI review tools are great, but can result in a large amount of feedback that is then difficult to address.

Over the past few days I think I’ve started to make progress toward solutions for both these problems, starting with the too-much-feedback issue.

In the past, I’ve felt that I had two options for addressing the occasional avalanche of AI code review feedback:

Address the feedback myself locally, one-by-one, which could be very time intensive even when using AI tools.
Ask GitHub Copilot coding agent to address all the feedback on the PR in one go, which results in a new potentially large PR against the original PR that I have to review.

After publishing my dotfiles, I found myself creating helper scripts to make it easier for me to address feedback left on my PRs one at a time. And it really started helping speed up the process.

pr-feedback along with a —limit 1 flag to get just one piece of feedback from the PR
pr-comment to comment on the feedback if appropriate
resolve-feedback to resolve the feedback once I was done addressing it

I was using these scripts within Warp, so the workflow started to look like:

Use pr-feedback to get the next item of feedback to address
Ask Warp to address the feedback
Review what Warp did
Once satisfied, commit and push the fix
Use resolve-feedback to mark the feedback as resolved on the PR

This too, though, started to feel repetitive, since it meant I was starting to spend a good percentage of my time running scripts and coming up with commit messages.

The solution: Warp saved prompts.

I’ve created a prompt that tells Warp to do most of that stuff above, leaving me to simply review the code and then give Warp the go-ahead once I’m satisfied with the fix. Warp runs the scripts and makes the commits, and the prompt instructs Warp to immediately move to the next piece of feedback once we’re done with the last.

And reviewing the code is super convenient since Warp has a built-in code review pane that I can keep up next to the terminal window where the workflow is running.

Warp awaiting my input and displaying its code review pane

I’ve also asked Warp to number the options it provides for how to proceed. So once I’m ready to move forward, I usually can simply input the number for the appropriate option. Or, if no option quite fits, provide a number with a modification, like:

“1, and also create a follow-up issue for X.”

With this in place, addressing AI feedback (or human feedback for that matter) becomes incredibly efficient. Here’s the full prompt if you’re interested in trying it out.

I’m still working on solving the first issue—taking a large PR and breaking it down for easier human review. I know this isn’t a new problem (and one that I already had before starting to use AI tools) but with the help of AI it’s only become more important for me to figure out.

I Can't Wait for Remix 3

Tue, 23 Dec 2025 17:13:44 GMT

Lately I’m super intrigued by the approach the Remix team is taking with Remix 3. I watched both part one and part two of the “Introducing Remix 3” talk they gave a couple of months ago. It looks very promising.

All the modern front-end frameworks I’ve used take a reactive approach to rendering. When something changes (a component prop, a reactive piece of state, etc), the framework automatically renders the portion of the component tree that could be impacted by that change.

The obvious advantage of this approach is that you as the developer don’t have to worry about managing this yourself. You just change the state, and your app automatically updates to reflect the new state.

In practice, however, this can cause some pretty irritating issues.

Render loops. Component A triggers a re-render of component B which does something in its render logic that triggers a re-render of component A, causing potentially a large chunk of your UI to re-render on every tick.
Unnecessary re-renders. Since in React, for example, state is compared by reference, two things that are the same by value (such as two different objects with the same contents) can cause React to think something has changed when there actually wasn’t a meaningful change.
Large re-renders. Say you add a React context provider at the top-level of your app to share state across your application to avoid needing to do elaborate prop drilling for state that is used throughout the application. Every time that context changes, everything within that provider re-renders, meaning your entire application for a top-level provider.

For a lot of applications, these issues aren’t that bad. But when I have run into them, I’ve found them to be extremely painful to deal with.

One such application had a site-wide media player, meaning there was state that needed to be accessible throughout the application (global context provider), had many events occurring (playback ticks), and needed to allow components throughout the tree to trigger changes back to the playback context (seeking, play/pause, auto play, etc). I repeatedly found myself dealing with the issues I listed above, and never found a good way to handle this state in React.

Remix 3 is taking the opposite approach by throwing out automatic re-renders. Instead of the framework automatically re-rendering the application when state changes, a component only re-renders when its this.update() method is explicitly called.

This really appeals to me. It means that it’s entirely in my control when my components re-render, and components can remain entirely static by default. And if I decide I actually do want reactivity in part of the application, I can add it in myself only where it makes sense using third-party libraries such as Redux or Zustand.

There are quite a few other things I’m excited about from watching the Remix 3 talks (focus on leveraging platform-level primitives, composable event handlers, back-end API type safety that looks better than Hono’s). Definitely watch the talks if any of that sounds interesting to you.

Publishing My Dotfiles

Mon, 15 Dec 2025 17:56:25 GMT

End of last week I finally gave up on using the HP mini PC I’d been using for work since my MacBook Pro started crashing under work loads. So now I’m using the gaming PC my family gifted me for my last birthday. Not necessarily ideal, but still good fun since it’s a beefy machine!

Thankfully I had previously already switched the PC to running Debian and I’ve been storing my local repositories on an external hard drive, so making the switch hasn’t been too painful. But while I was at it I decided to work toward making it even less painful next time I switch machines.

Enter my new dotfiles repository.

I’ve tinkered around with storing computer configurations on GitHub before. But it never stuck that well, probably because the friction to keeping the repo up-to-date to the point where it was useful when I switched computers was just too great.

This time I’m taking a different approach (maybe the approach most people who use dotfiles repos have already been using): I’ve initialized my home directory itself as a git repository.

Doing this made me a bit nervous since I didn’t want to accidentally commit sensitive information. To avoid this I git-ignored everything in my home directory (`*`) and have been only unignoring specific files as I see value in adding them to the repo.

If you’re into using Beeminder or are generally interested in quantified self stuff, there are already some fun goodies in the setup:

The main toolbar displays my next due Beeminder goal using `buzz next`.
There’s a script that queries my ActivityWatch data for work time.
There’s another script that syncs that data to Beeminder (again using Buzz).
And it includes a crontab file to ensure that sync happens regularly.

I’m quite enjoying using git to track my computer setup. I feel like so far it’s encouraging me to be more thoughtful about how I set up my machine.

Digital Employees

Mon, 08 Dec 2025 18:33:57 GMT

I’ve been vaguely keeping track of the progress of “digital employees”—AI-powered agentic systems that simulate traditional employees. There are plenty of startups trying to build them.

Lindy: “Meet your first AI employee”
ai.work: “Autonomous AI Workers designed for internal operations teams - IT, HR, Procurement, Legal and beyond.”
Relay.app: “Augment your team with AI teammates that work for you”
Teneo.ai: “Join Teneo and our +17,000 AI Agents revolutionizing customer service to fully automate Tier 1 support.”
11x: “Digital workers, Human results.”
newo.ai: “Create your own AI Receptionist in just 3 minutes and start earning up to $30,000 more per month per location by ensuring you never miss a customer, even after hours.”
Devin: “Crush your backlog with your personal AI engineering team.”
Beam: “Hire Self-Evolving AI Agents to Run Your Operations”
Relevance AI: “Build teams of AI agents that deliver human-quality work”

I’m currently listening to the second season of the Shell Game podcast. In the new season Evan Ratliff is doing his best to build and run a startup almost entirely using these digital employees. So far he’s had mixed results, and he and his other human teammate have had to put in a ton of effort adding scaffolding on top of the AI agent tools to get them to behave somewhat productively.

What really stood out the most was the degree to which his digital employees appeared to be role playing as employees, making up backstories for themselves, fabricating details about the company, and imagining how they spent their weekends. Ratliff finds this charming. I find it off-putting.

I do find the idea plausible that AI hallucinations aren’t entirely bad. They may be the key to the creativity and imagination AI brings to the table. But a digital employee who fails to draw the line between imagination and reality seems less than useful.

I don’t know to what degree this conflicts with effective prompt engineering. Is it necessary to tell the AI that it’s a human HR professional with 12 years of experience in the industry in order to coax the best performance out of the model? I hope not.

I expect these tools will become more and more pervasive as they improve, though I’m less certain whether the hyper personification of some of these tools will persist. Will we prefer our AI agents have human-appearing names and avatars, or would we rather they present as what they are, AI-powered software bots?

Choosing a Laptop, Updating Buzz, Etc

Fri, 28 Nov 2025 19:27:15 GMT

Happy Thanksgiving! 🦃

I’ve been planning to purchase a new development computer for a while now. I could do it now, but I’m still a bit nervous.

Currently I have three computers:

A mini PC running Debian that I use for work.
An older MacBook Pro that crashes when I use it for heavy work stuff so it’s been relegated to my personal machine.
A beefy gaming PC that was a gift from my family, also running Debian.

I’m planning to be more mobile in the future, so I need a laptop that I can do work on.

I’m very tempted to purchase a Framework laptop since I really enjoy doing my work on Linux. And the ability to easily repair and upgrade it is appealing.

Unfortunately there are good arguments for me to instead purchase another Apple laptop instead.

I understand that the Framework laptop’s build quality is worse than an Apple laptop’s.
I have plenty of experience using Apple laptops as work machines, so I’m highly confident they’ll do everything I need.
I already own an external Apple keyboard and magic track pad, and these are my preferred peripherals, plus they’re very portable.
It’s likely I’d be able to acquire an Apple laptop more cheaply than a Framework laptop, since there’s a lot more availability for used and refurbished Apple laptops than Framework laptops.

So unfortunately it feels like the responsible decision is to purchase an Apple laptop and wait until I have some disposable cash to play with before taking a chance on a Framework laptop.

I’ve been continuing to add features to buzz. In the last week:

Added support for piping values into the `buzz add` command.
Added `—json` and `—datapoints` args for the `buzz view <slug>` command.
Tried to improve the usefulness of the buzz update-available messages, though I’m not quite happy with them yet.

I’ve been continuing to work hard toward migrating from Firestore to Neon for the database. It’s been a bit tricky since I need to keep the Firestore service while adding the Neon service until the migration is completed. I have a migration built but I’m still trying to get to where I’m more confident that it will work on the first go before I pull the trigger.

Adding Sentry & Neon to TaskRatchet

Fri, 21 Nov 2025 17:08:34 GMT

I’ve added Sentry to TaskRatchet’s front-end, API, and email worker. It’s already been quite helpful in surfacing errors and reducing the effort needed to fix them.

I had been thinking that having Honeycomb meant I didn’t need something like Sentry. But I now thing that was a mistake. Honeycomb and Sentry serve different purposes. Honeycomb collects a ton of detailed telemetry, making it ideal for debugging complex issues and surfacing trends and correlations over time. Whereas Sentry is great for immediately alerting me when an error occurs, and surfacing all the context around that specific error.

I’ve just about decided to use Neon for TaskRatchet’s database instead of Cloudflare D1. This has a few advantages:

Since it doesn’t require a worker to connect to it, I can switch databases before moving the API to Cloudflare.
It should make it quite easy to set up feature branch database forks.
It’s just postgres, which should make it easier to migrate to something else in the future if needed.

Making the switch means modeling TaskRatchet’s data relationally and creating a corresponding schema. This is something I didn’t have to do with Firestore, since Firestore is a no-SQL document store.

I never had too much trouble with Firestore when it comes to data integrity. I’ve used a thin service wrapper so only my Firestore service and my migrations interact with it directly. And my service layer has evolved to be coded fairly defensively to compensate for the lack of an explicit schema. In practice that means my service functions use Zod to validate the data coming out of Firestore before returning it to the rest of the application. When something breaks for a user due to corrupt data, I find out based on the errors that Zod throws, and then go into Firestore and manually fix whatever is incorrect or missing.

I have definitely had issues with Firestore, though. Examples:

Since it’s a document store, sometimes I have to duplicate data across documents to reduce the number of queries I have to make, like syncing the user’s timezone across every task document for that user. This reduces the number of queries I need to make, but feels really yucky coming from a relational mindset.

The kinds of queries you can do are sometimes quite limited compared to a traditional database. Google says this is to prevent you from being able to create slow queries. But I’ve found on more than one occasion that what it means in practice is I’m forced to query much more data than I wanted and then filter it application-side, resulting in being charged for potentially hundreds of reads when I only wanted to read a single document.

Getting the kinds of database backups that are automatic with most database services is not obvious with Firestore. I had to set up my own job to do it. It makes me nervous knowing I rolled my own backup system for the database.

It’s also bothered me that Firestore is a proprietary system, meaning a fair amount of lock-in. There’s no simple way that I’m aware of to get a dump of a Firestore database that can be easily imported into another database system. Though this may be partly due to my desire to move from Firestore to a relational database, which wouldn’t map cleanly regardless of what no-SQL database I was coming from.

I think the biggest advantage of document stores comes at the prototyping phase of a product. You don’t have to plan out your schema ahead of time. You can just create some collections of documents and throw data at it. Quick, easy, maybe a bit dirty.

I feel like this advantage becomes less of a value add once the product is more mature. You already have a good idea of your data structure, so there isn’t so much of a need to have a super flexible “schema.” And you end up having to add layers on top of the document store to give you more of the assurances you’d have gotten out-of-the-box with a relational database—e.g. my usage of Zod to validate data queried from Firestore.

Additionally, if you want something more like a document store, you can do that with postgres using json fields. In TaskRatchet’s database I intend to do that with an integrations table, which will have a json-type config column. This will give me the benefit of a document store’s flexibility only where I need it—in this case, for integrations so I don’t need to keep expanding and modifying the database’s structure every time I want to add a new integration with a third-party service.

Anyway, I’m feeling optimistic about the move to Neon. We’ll see how it goes in practice.

AI as Slot Machine Programming

Fri, 14 Nov 2025 17:32:07 GMT

I found this issue of Understanding AI quite interesting, especially this paragraph regarding Coca-Cola’s recent AI-generated Christmas commercial:

To combat this [lack of consistency], good ads can take hundreds or thousands of individual generations to produce compelling content — Accetturo called this dynamic “slot-machine pulls.” A high level of human involvement helps to deliver a more consistent vision. But even a large number of generations doesn’t ensure quality — the Coca-Cola ad apparently required more than 70,000 video clips.

I think pulling the lever on a slot machine is a good analogy for what using AI tools can become when it isn’t working well. And I think it’s a good indicator that you need to stop and change course.

Prompt the AI to stop and gather context
Switch to manually gathering context on your own (e.g. adding log statements)
Switch to collaboration mode, asking the AI how to do the thing and then doing it yourself instead of letting the AI execute on its own
Update instructions files to improve the AI’s baseline performance in the codebase
Look for ways to simplify or otherwise re-architect the codebase to make it more AI-friendly

Basically, when you find yourself in a situation where you’re just asking the AI to try again and hoping it works better this time, that’s the point you need to switch strategies.

I fixed the TaskRatchet error that I mentioned in my last post. Of course, it would be better if I fix the issues before users complain about them.

With that in mind, I’ve been working on improving my ability to catch and fix TaskRatchet errors quickly. I already had Honeycomb set up, but my error reporting setup was spotty.

To solve this, I’ve been working to add Sentry to all parts of TaskRatchet. So far I’ve added it to the web front-end and the API. I’m currently working toward adding it to the email worker.

I’m hoping that having Sentry up will make future infrastructure changes, such as moving to Cloudflare and switching database solutions, smoother than previous ones have been at times.

TaskRatchet Bugs, Cursor 2, & Rails Project Refactoring

Fri, 07 Nov 2025 17:56:41 GMT

I’ve been doing my best to fix an issue with TaskRatchet sign-ups where a user can register but then can’t add their payment method. I deployed what I hope will fix the issue but I haven’t gotten confirmation yet from the affected user.

I’m still kind of in an awkward place when it comes to finding and fixing issues with TaskRatchet. Switching to Clerk for auth has had the effect of basically preventing me from manually testing my code locally. Automated testing is unaffected.

I’ve been making some headway toward getting past the issue. The front-end is now deployed to Cloudflare, and I have branch previews set up in a way that I’ll be able to point the front-end preview deploys to corresponding back-end staging deploys once those are working.

The hang-up with that is that I think it’ll be tricky to switch from Render.com to Cloudflare for deploying the back-end, since it’ll also necessitate migrating the database from Firestore to Cloudflare D1 at the same time.

I think I should probably side-step this for now by getting my local dev server setup working well again.

Cursor 2 has me back on the Cursor bandwagon, and so far the changes seem really great. I’m mostly enjoying the agent layout so far. I haven’t tried using multiple parallel agents yet. And I haven’t made use of Cursor’s new built-in browser yet.

One thing that feels like a big improvement is Cursor’s new planning mode. So now it has Agent (just do stuff), Ask (let’s talk without doing stuff), and Plan (like Ask but it also puts together a planning document and task list). It allows for a flow more like Claude Code, and feels quite natural.

I’m actively experimenting with refactoring a large Ruby on Rails codebase to work better with AI tools. So far that’s meant:

Switching to GitHub Issues + a GitHub Project for issue management and kanban
Adding and iterating on a copilot instructions file
Adding new CI checks
Configuring GitHub Copilot to have access to more MCP servers (e.g. Sentry, Context7)

So far that’s all low-hanging fruit. More changes I’m planning to make:

Add a copilot-setup-steps.yml file so Copilot has a better immediate setup when it starts a session
Split the React front-end from the Rails back-end to create better separation and simplify tooling, making the repo a monorepo at the same time
Pull the mobile app repo into the monorepo
Add package-level AGENTS.md files
Migrate all remaining JavaScript files to TypeScript
Add Sorbet for Ruby type checking

And then there are changes I’d like to make but am not sure if they will be practical any time soon. The main one in that category is feature branch development previews. It seems with the project’s current architecture there just really isn’t a good way to do that which also wouldn’t cost a lot of money over time. Though once the front-end is split from the back-end I think we could at least get front-end deploy previews.

TaskRatchet on Cloudflare, Cursor 2, Etc

Fri, 31 Oct 2025 16:49:31 GMT

I’m still working toward having TaskRatchet fully deployed to Cloudflare. The front-end is currently deployed to Cloudflare, but the API is still deployed to Render.com. My goal is to have fully-automated dev previews so I can easily manually test my changes. Getting closer, but not there yet.

The difficult part about where I’m at now is it’s a bit of a chicken-and-egg problem to get the API deployed to Cloudflare. The API uses Firestore, which isn’t immediately compatible with Cloudflare Workers. I plan to switch from Firestore to Cloudflare D1 for the database, but D1 is only accessible via a worker. Which basically means I have to switch deployment target and database at the same time. Which is scary. I’d rather break them into two separate tasks.

Cursor 2 has some super interesting new features, including an interface for using agents in parallel and an in-IDE browser. Unfortunately it seems like actually using agents in parallel may require you be on their $200 / month plan, which seems like a pretty hard sell.

I’ve been having an issue where my USB controller crashes on my Debian machine when I try to run a dev container in vs code. I’m currently working on getting a watchdog service set up to auto-restart the controller when it crashes so I don’t have to hard restart my machine every time.

You can use Homebrew on Linux. It’s pretty great. I’m currently trying to use it to install Watchman in my dev container, since it seems Facebook no longer provides prebuilt binaries in their GitHub releases. (You could also use it to install buzz. 😉)

Buzz Updates, Monorepos, & AI Dev Workflows

Fri, 24 Oct 2025 17:33:09 GMT

Buzz Updates

I’ve been continuing to improve buzz. You can see the release notes here. Highlights:

`buzz view` lets you view some details about any specific goal.
`buzz review` lets you step through all your goals alphabetically, meant for use when calendialing.
`buzz —version` now shows you what version of buzz you have installed.
`buzz refresh` now lets you trigger an autodata refresh for a specific goal (requested by Philip Hellyer).

Back to Monorepos

I’ve moved back to using a monorepo for TaskRatchet. As mentioned previously, I had tried using monorepos with TaskRatchet in the past, but had a poor experience. This time around I took a different approach, creating only a single monorepo for TaskRatchet, and only moving things to it that are directly related to TaskRatchet and are likely to change together or be referenced together while doing development. It’s already feeling much better than last time.

Copilot + CodeRabbit Optimizations

I’m continuing to use GitHub Copilot coding agents alongside CodeRabbit, and the combination continues to be surprisingly effective. A few notes on how I’m using these tools together:

I have the GitHub CLI installed locally. I’ve added an alias to it that runs a script to create new issues and immediately comment on them requesting CodeRabbit’s input.

The alias: ‘!gh-ic “$@”’

The script, stored as `gh-ic` in my bin:

#!/bin/bash

# GitHub CLI issue create script
# Usage: gh-ic Issue title without quotes

# Check if title argument is provided
if [ $# -eq 0 ]; then
    echo “Usage: gh-ic Issue title without quotes”
    exit 1
fi

# Get the issue title from all arguments
title=”$*”

# Create the issue with empty body and capture the URL
issue_url=$(gh issue create -b “” -t “$title”)

# Extract issue number from URL (format: https://github.com/owner/repo/issues/123)
issue_number=$(echo “$issue_url” | grep -o ‘[0-9]*$’)

# Add a comment asking CodeRabbit AI to analyze and enhance the issue
gh issue comment “$issue_number” --body “@coderabbitai Please analyze this issue and update the description with implementation details, suggested approach, and any relevant technical considerations.”

This setup allows me to quickly create new issues like this:

gh ic The title of the new issue

Which are immediately added to the repo I’m viewing in terminal, and shortly after populated with details by CodeRabbit. I can then further comment on the issue as desired, asking @CodeRabbit to make any desired revisions.

Once I’m happy with the state of an issue, I assign it to Copilot, which will go off and create a PR and eventually request my review.

When Copilot finishes its first pass, I do the following in this specific order:

I manually review the code changes.
I mark the PR as ready for review, taking it out of draft mode.
I manually request CodeRabbit review the PR, since CodeRabbit won’t auto-review a PR opened by a bot.
I go back-and-forth with Copilot and CodeRabbit, asking Copilot to address CodeRabbit’s feedback, and CodeRabbit to make new reviews.
Once CodeRabbit is happy with the PR (or I’ve dismissed its feedback as out-of-scope), I approve CI jobs to run.
Once all CI jobs have successfully run, I merge the PR.

The main thing to notice here is that I intentionally go through the CodeRabbit review process before approving CI jobs to run. This is to reduce the cost of this workflow.

CodeRabbit doesn’t charge per review (as much as I might like them to), so requesting more reviews doesn’t increase your costs.

However, GitHub does charge per actions minute (once you’ve used the monthly free minutes that come with your plan). And you may be using all your free minutes, since Copilot coding agents run on GitHub Actions, so they use your minutes.

Because of this, I prefer to get the CodeRabbit feedback out of the way before I approve my jobs to run, since CodeRabbit may find issues that would have failed in CI, potentially saving me from using even more CI minutes by needing to run the CI jobs multiple times.

Copilot consistently has difficulty remembering how to access all feedback left on a PR by CodeRabbit. For this reason, I’ve been adding this section to Copilot’s instructions file in many of my repos. And then, for good measure, when I ask Copilot to address CodeRabbit’s feedback, I remind it to use these instructions:

@copilot Please address coderabbit feedback. Your instructions file will tell you how to access coderabbit feedback.

I have this set up as a text expansion using espanso, though I still find myself entering it manually quite frequently since I’ll often be using devices other than my primary work machine.

Speaking of multiple devices, one advantage I find with this workflow is that I’m able to move things along from just about any device I’m at. My work machine is best optimized for it, since I have all my dev tools set up if I need to check out a PR for manual changes or local testing, and I have my GitHub CLI alias configured for quickly adding new issues.

But I can be nearly as productive on my laptop, tablet, and even phone. On mobile devices I use the GitHub app to create new issues, ask CodeRabbit for issue revisions, and go through the PR review process described above. And on my laptop I can do the same on github.com.

Buzz: A Terminal Interface for Beeminder

Fri, 17 Oct 2025 17:19:59 GMT

I’m still conducting my experiment with using my terminal as much as I can, though that’s become terminal plus GitHub.com since my GitHub workflow still works best in a browser, unfortunately.

As I’ve been spending much of my time in the terminal, one gap I noticed was that I didn’t have a way to interact with Beeminder in the terminal.

(If somehow you’re reading this and don’t know what Beeminder is, it’s a fantastic service that lets you set monetary stakes on making ongoing progress toward your goals.)

Other terminal interfaces for Beeminder exist, but none of them were exactly what I was hoping for. So I decided to build my own.

I had previously built a custom Beeminder dashboard for the browser–you can use it yourself at bm.taskratchet.com. I really enjoy having the tight grid of color-coded goal cells. It’s very information dense and works well for my brain. So I decided to build the same thing as a TUI.

It seems that the best TUI libraries are all written in Go. I don’t know how to write Go, but that proved to be not a problem at all. I used GitHub Copilot coding agent tasks to build the whole thing, and the experience was really fantastic. Copilot brought a lot of polish and attention to detail to the project that I may not have had time for if I had written it on my own.

The Buzz goal grid

The TUI portion of the tool is pretty simple. When you first run buzz (assuming you’ve already authed) it displays a grid of your goals, color-coded by buffer–red for due today, orange for due tomorrow, etc. You can scroll to see all your goals if they don’t fit in your terminal. And you can use your arrow keys to highlight one of the cells.

Once the cell is highlighted, you can press enter to open the detail view for this goal. It shows some details about the goal and lets you enter a data point if you’d like.

The detail view is functional, but I rarely use it, since I’ve found a slightly different workflow to be much more efficient. I open the grid of goals by using buzz without arguments, and then I also open a separate terminal pane where I actually interact with the goals, with commands such as:

buzz today to get a list of all the goals needing data today (also useful for copying to a notes app for a handy checklist)
buzz next to see just the next due goal
buzz add the_slug 1 and an optional comment to add data

This hybrid approach has proven super efficient and enjoyable for me.

So far I’m quite happy with the tool as is. There are some fun features that my web dashboard had that this doesn’t, but at least for now I’m not planning to introduce them unless I start missing them (or other people request them).

It’s also super easy to install. My preferred method is using bin since I already enjoy using bin and it makes it very simple to update buzz. But you can also install it using Homebrew, which is probably an easier option for most Mac users.

Here’s the repo. Give it a go and let me know what you think, or just create a PR or an issue on GitHub.

Disclosure: AI didn’t write any of this, but I did use Claude to get feedback on my writing.

Terminal-First Dev & a Few Interesting Links

Fri, 03 Oct 2025 17:16:58 GMT

Terminal-First Development

I’ve been challenging myself recently to see how much of my work I can do from a terminal rather than in a browser or an IDE.

The reason I started thinking about this was because I’ve been getting more comfortable using GitHub’s coding agent to execute tasks, and the workflow is really nice:

Create a GitHub issue
Capture any info in the issue about the task
Comment on the issue asking CodeRabbit for input
If new issues should be created based on the issue, comment on the existing issue asking CodeRabbit to create the new issues
Once the issue is ready for execution, assign the issue to Copilot
Review the changes in Copilot’s PR
Request a review from CodeRabbit on Copilot’s PR
Optionally reply to CodeRabbit’s review comments asking it to create new follow-up GitHub issues
Optionally comment on the PR asking Copilot to address feedback
Merge the PR

I’ve been making a surprising amount of progress with TaskRatchet this way. And it struck me that nothing here requires a browser—GitHub’s CLI lets you do everything on that list (with a couple of annoying exceptions—assigning an issue to Copilot and viewing CodeRabbit’s inline code comments).

So for the past couple of days I’ve been seeing how much I could get done while avoiding the browser and even the IDE most of the time. And it turns out to be quite a bit.

Adapting My Terminal

What follows may be a sort of random collection of things I’ve done to my setup as a part of this experiment.

I added a shell script and corresponding saved AI prompt in Warp to have Warp AI scaffold out and complete issues which are then submitted to GitHub using the GitHub CLI.

I installed Navi for searching through command-line cheatsheets and created a repo to begin creating my own cheat files.

I installed the Perplexity plugin for llm and created a bash function to let me use `perplexity` to quickly jump into a web-backed chat without needing to open the browser.

I installed TaskWarrior and BugWarrior to let me sync GitHub issues and PRs with a terminal-based task list.

I can view and edit files directly in Warp using nano or Warp’s editor features.

I installed fd and ripgrep for easier file searching.

I’m using Superfile for an in-terminal file manager.

I’ve installed ddgr to let me search the web using DuckDuckGo from the terminal.

Benefits?

So far I’ve only mentioned this experiment to two people (one being my brother) and both had the same response—why? Here they are:

To find out if I could
To get better at using the terminal and terminal-based tools
To move more of my processes into a place where it’s more natural to request the assistance of AI, and for AI to tie multiple tools and sources of information together
To explore how I could automate and streamline my processes and workflows
To explore whether terminal-based workflows could be less distracting and more ADHD-friendly

We’ll see how the experiment goes.

Link Roundup

TaskRatchet has a new competitor—Mastt. (ht Daniel Reeves) It appears they’re building an iOS app. I’ll be interested to see if they’re able to stay in the app store long-term, given the experiences I’ve had with Apple’s internal reviews of TaskRatchet.
Cari is a super interesting site featuring collections of images illustrating many different consumer product styles.
WalkScape is a gamified walking app currently in closed beta.

Surfing Your Motivation

Thu, 25 Sep 2025 17:11:32 GMT

This great question on the Beeminder forum has me thinking about different phases of motivation:

Thread: Looking for tips to replenish motivation.

My thoughts on the topic are probably significantly impacted by my own particular flavor of ADHD. That said, these are some of the phases of motivation I experience, in no particular order:

Hyperfocus
Repulsion
Flow
Annoyance
Sustainable tending

Hyperfocus

I experience hyperfocus as a kind of acute obsession. When I’m in this mode I may engage for hours without regard to other priorities. I may postpone tending to my basic needs and resent the time they manage to steal.

For me hyperfocus is not about productivity. I may or may not be effective while hyperfocusing. Often I may be productive for a while but continue pushing for hours after all enjoyment or productivity is long gone.

Hyperfocus is just as likely to be triggered by interest as it is by anxiety. Frequently I find myself hyperfocusing on one thing when another thing is a source of urgency or stress. Sometimes this might be explained by a desire for escape, while at other times it’s due to an irrational fixation on completing task A so that I will be freed to address task B, even though task B isn’t actually blocked by task A.

Repulsion

I think of this as the opposite of hyperfocus. Like hyperfocus, it can be triggered by anxiety around the object, or it may be due to a lack of mental resources without any particular emotional valence. So I don’t mean to imply disgust by the choice of the word.

Rather I chose the word “repulsion” because of the similarity of the experience to that of trying to push the matching poles of two magnets together, that immaterial yet still physical resistance. When I’m in this mode, I find my mind resists even thinking about the thing. I quite literally find myself “blanking out” when I try to engage with the thing.

Flow

Flow is a term used aside from ADHD to describe the state of being fully engaged with a task. It results from an appropriate combination of skill and challenge that avoids both boredom and frustration.

I find that, when I need to get into flow with a project, I often need to choose something easy or superficially interesting about the project first, even if that aspect of the project won’t result in meaningful progress on its own. However, by starting with these smaller tasks, I’m able to incrementally load the project into my mind, until the actually valuable parts catch my interest and I ease into productive engagement.

This is different from hyperfocus in that I’m choosing what I’m engaging with, whereas with hyperfocus I’m held captive apart from any calm intention. Also, if I’m doing this well, I’m able to maintain a healthy level of engagement without the downsides inherent in the obsession I experience with hyperfocus.

Annoyance

I experience annoyance when I’ve been committed, either by myself or some external circumstance, too aggressively to something that I’m not ready to engage with at that level. That may be due to lack of mental resources, misalignment of priorities, or the object being the perceived source of some kind of stress.

I’m a big fan of self-commitment devices (e.g. Beeminder), but I have to be careful to not over-commit myself when I’m enthusiastic about a thing. The consequence is often that later, once the frustration has reached a tipping point, I tear down the systems and precommitments I had made previously.

Sustainable Tending

This is the state I try to navigate into when there’s a priority I want to attend to over a long period of time while avoiding annoyance. It’s the result of implementing appropriate systems and precommitments that won’t result in frustration when my conscious priorities, interests, and mental resources change. It’s a balancing act, finding measures that will encourage ongoing progress while remaining resilient to changing circumstances.

I find that much of my progress in managing my ADHD has been in learning to recognize these states and then surf them in a way that minimizes the harms and maximizes the likelihood that I’ll end up in more manageable states for more of the time.

This also means letting go of the idea that I should or can control what state I’m currently in. I can’t, and if I try I only push myself further toward anxiety and burnout. They’re within my influence, but not my control.

Spec-Driven Dev, TUIs, Etc

Thu, 18 Sep 2025 17:15:55 GMT

Spec-Driven Development

We’re currently experimenting with adding a task planning phase to our process. We’ve moved to using Trello for our current primary client. I’ve created a template Trello card with checklists to help structure our planning:

Planning

Init specification document
Braindump (15m)
Technical exploration (30m)
Define user stories (10m)
Punt capture (10m)
Define scope and exclusions (10m)
Draft PR breakdown, more PRs better (10m)
Request async peer review

Plan Review

Rate each PR size as S/M/L
Can any planned PRs be split further?
What’s our riskiest assumption?

One thing we’re frequently poor at is keeping our pull requests small. This issue was the motivator for trying a planning step.

The times in parentheses are only suggestions. We’ve been using them as a starting point for time blocking. So we set a timer for the task and then assess whether we have more to do on that task when the timer is up.

Currently we’re using a private HedgeDoc instance for storing the specification documents for capturing this planning, though we may consider storing them as markdown files within the relevant repo itself, like `plans/0001_my_new_feature.md` or something.

Relatedly, I’ve been continuing to experiment with using GitHub Spec Kit with TaskRatchet API. It seems like a really promising approach to add more scaffolding around using AI for programming. I haven’t gotten through a full iteration using the framework yet. I also understand that different AI models perform different with the framework, so may take some experimentation to get the best results.

Terminal Tools

I’ve been installing and learning more terminal tools lately. Namely:

upterm for session sharing
zellij for an upterm-friendly multiplexer
podman for an alternative to docker
git-branchless to improve git
zoxide for a more-efficient cd command
posting as an alternative to postman
superfile for a terminal-based file manager
countdown for bare-bones mob programming tracking (e.g. `countdown 10m && say “Next”`)
bin for managing github-hosted binary installation

Many of these are listed in awesome-tuis, and I plan to explore more of the tools listed there soon.

Link Roundup

mob.sh is a terminal tool for mob programming that handles git handovers under the hood. It’s a different approach to mob programming than I’m used to, but something I might like to try at some point.
Remote Mob Programming is a page describing one approach to mob programming.
Round-robin coding is a blog post on using mob.sh with mob programming.
This video is all about how Peter Whidden created a GPU-optimized interactive ecosystem simulation called Mote as something half-way between a sandbox game and a tool for researchers.

Link Roundup + TaskRatchet API Update

Thu, 11 Sep 2025 16:54:23 GMT

I’ve been continuing to work on sunsetting TaskRatchet’s public API v1. I’ll be going ahead and turning off v1 tomorrow, September 12.

I’ve been making sure that all our systems use API v2, and working out any bugs with that usage.

I’ve also been working on switching from Express to Hono in API v2 as the underlying API framework. This will allow me to more easily deploy to Cloudflare instead of Render.com, and it has a nice plugin for generating an OpenAPI spec file that will allow me to generate documentation from the API.

Having the API deployed to Cloudflare will allow me to set up multiple instances of the API for staging vs production, which should make things easier to manually test before shipping.

I’m thinking I also need to do better at letting users know that they can add a password back to their account after the authentication switch. New users will be prompted to set a password during sign-up, but users that already existed during the switch lost their old password and it isn’t obvious how they can re-add one so they don’t have to use email verification every time they sign in.

I’m thinking what I’ll do is listen for a Clerk webhook event indicating that a user logged in using email verification. I can then have TaskRatchet send them an email explaining how they can add a password if they wish. I can track whether I’ve already sent this email on their database user and only ever send it once so I don’t spam users who prefer using email verification.

Once I have all that done my next step will be to switch away from Firestore to Cloudflare D1 for the database. Firestore has worked well, but I think it’s time to move to a structured database, both to reduce costs and to avoid bugs related to inconsistent data in the database.

Link Roundup

Artificial Intelligence

Anthropic’s going to start training their models on chat transcripts, so maybe make sure to opt out if, like me, you’d rather they not do that.
Codebuff open sourced some or all (unclear) of Codebuff, or maybe just an agentic framework they developed while building Codebuff. Apparently people are already building new things with it, including vly.ai.
Textideo is another tool for generating AI videos.
Daytona is a cloud platform focused specifically on running AI-generated code.
Cartesia is another voice AI tool (“platform?”).
JigsawStack lets you use small, specialized AI models tailored to your development stack.

Programming

Verdent sent me a cold email about their new agentic coding system. I don’t know if it’s any good, but maybe it is.
Val Town released a CLI that can be used to deploy a project from your local machine. Neat! Now I want to know if I could use it to set up GitHub Actions to automatically deploy on merge to main.
MonkeyUser seems like a great xkcd-like comic focused on programmer humor.
dnd kit is an npm package for adding drag-and-drop functionality to your React application.

Assorted

Matt D’Avella released a new video on slow productivity. It resonates.
This video essay explains how the Sears catalog sidestepped Jim Crow-era racism.

Labor Day Update + Link Roundup

Tue, 02 Sep 2025 15:54:42 GMT

My brother is back to working with me now. At this point there are three of us working together on a regular basis.

Currently most of our time is spent in Ruby on Rails and various TypeScript projects. I’m relatively new to Ruby on Rails, but feeling much more comfortable than I was just a few months ago.

I’ve been able to start spending more time working on TaskRatchet again, which is feeling great. I deployed a switch to Clerk for TaskRatchet authentication. It allowed me to simplify things a lot behind the scenes, and should also improve user experience quite a bit.

I was quite nervous around the launch that I would have introduced a bunch of bugs that I missed and we’d only find out about when users ran into them. So far, though, this seems not to be the case. Nicky told me that they haven’t gotten any complaints yet, which I’m thankful for!

I’m currently focused on getting to the place where we can sunset API v1. Currently that means migrating the cron jobs that are still running on the old API to our new API v2 codebase. I’ve completed the development work to make the switch, though I still would like to think things through a bit more before I pull the trigger.

I’m currently in-between IDEs, using both Zed and VS Code. Zed for its collaboration capabilities, VS Code for its AI features. The state-of-the-art is changing so fast right now that I don’t feel like I can commit myself fully to any one tool, so I just end up having a lot of different ones installed so I can learn and experiment with them all.

Yesterday my brother and I went and spent time with some friends for a Labor Day bonfire and horseshoes. It was very relaxing.

One of the other people that were there is a biology professor at at the local university. Mostly unprompted he and his wife started asking me about AI and how it impacts my job. He told me that he’s been feeding his take-home assignment questions to AI, and its responses have been getting worryingly good. You know things are changing when biology professors start asking you about your development tooling.

Link Roundup

Danny published a post about using LEGOs to get a workout on a home staircase. Makes me wish my apartment had two stories!
ReactOS is a Linux distribution under development that is prioritizing native compatibility with Windows applications and drivers.
NVIDIA Jetson Thor is a mini PC focused on physical AI tasks.
Oxc is an ecosystem of JavaScript tools written in Rust to replace things like ESLint and Prettier.
Google is making waves with its new Nano Banana image editing model.
MacroFactor’s app has AI-powered food logging, and according to the Beeminder community it’s worth a look.
GitHub Actions supports reusable workflows, which again came in handy recently when I was refactoring a CI setup in a client repository.
I’ve been tentatively learning Godot, and they have a design philosophy document. Neat.

Are LLMs Conscious?

Tue, 26 Aug 2025 17:46:10 GMT

So far I’ve been staunchly agnostic on AI consciousness. My reasoning:

I define consciousness as subjective experience.
By definition, subjective experience cannot be measured except by the subject.
I assume naturalism to be true. I don’t believe souls or divine intervention or cosmic non-material magic are required for beings to be conscious.
Emergence is as good a theory of the origin of consciousness as any other, though probably unprovable due to 1 and 2.
Therefore, it isn’t out of the question that an LLM might have some sort of consciousness, though impossible to prove either way.

Given those opinions, I haven’t found any arguments I’ve heard in either direction to be compelling.

That recently changed. From Daniel Reeves’ AGI Friday newsletter:

[T]here’s one thing about the implementation of LLMs that conceivably precludes consciousness: the static-ness of the weights and how LLMs can’t (currently) continuously improve.

Imagine taking a human, showing them some text, and asking them to predict the next fragment of the next word. As soon as they utter it, you add it to the text, reset their brain to the exact state it was in before they saw the text, and repeat.

It’s a little mind-bending (in more ways than one) but it’s kind of reducing the human to a single moment of consciousness. Does that still count as conscious?

This argument makes sense to me. Any consciousness an LLM may have is limited to the degree that the system preserves “mind state” between tokens generated.

I’m not certain, however, that current LLM architectures don’t preserve such state. Here’s an excerpt from the response to a question I asked Perplexity while trying to think about this:

Current LLMs are autoregressive: they generate each output token one at a time, with each new token conditioned on all prior tokens in the same response. The model keeps the intermediate state (such as key/value caches from previous tokens) for the duration of a single response, so state is actively preserved and extended between output tokens generated in one query.

During token generation, the neural network maintains internal matrices and caches (especially attention key/value caches) that contain information about all tokens generated so far in the response.

These caches allow the model to rapidly attend to prior tokens without recomputing everything from scratch for each new token.

This state is only preserved for the current generation event. Once the response is finished, the state is discarded; for APIs, every new prompt starts a fresh generation.

I’m afraid this stuff starts getting too complicated for me fairly quickly, but here are a few links (again taken from Perplexity’s response) that looked relevant:

So that leaves me fairly near where I started—I don’t believe it’s likely that LLMs are conscious, but I also don’t believe that the possibility they have some form of subjective experience, however limited, should be confidently ruled out.

Podman

I’ve been experimenting with switching from Docker to Podman. I believe it’s supposed to be a drop-in replacement. Getting Docker to work consistently on my Linux machine has been some trouble, so I’m hoping Podman will be better. I haven’t done much with it, though it did seem easier to set it up to store images on an external hard drive.

Development Containers

On containers, I’ve been trying out using development containers with VS Code. A developer friend recommended that I give them a look. Adding a development container configuration to your repository and enabling the development containers extension for VS Code allows you to work on your project in VS Code as if you were using your local machine as host even though under the hood everything is happening inside the development container.

GitHub Copilot Coding Agent

I’ve also been trying out GitHub’s new agent tasks. Actually the main reason I finally got around to trying out development containers was because I hoped that GitHub Copilot would be smart enough to automatically use the committed container configuration when it spun up an environment to execute a task. Alas, it isn’t.

Copilot agent tasks are still quite interesting, though. It does basically the opposite of what CodeRabbit does—it modifies the codebase according to your task description and then prompts you to review its PR. You can leave feedback for it on the PR and it will spin up a new coding session to address the feedback and update the PR.

It seems quite promising as a workflow. Being able to open up several repositories, initiate tasks on all of them, and then let Copilot take its best stab on all the assigned tasks simultaneously feels really efficient. Though so far it’s still required some back-and-forth with Copilot before anything ready for merge is produced.

I think some of that can be solved by adding a Copilot setup steps CI workflow in the repo where Copilot will be working. That’s the current method for adding setup that’s run before each session, instead of using development containers like I first guessed. That way you can add any dev tooling, install dependencies, etc, before Copilot gets started so it doesn’t have to keep backtracking to do those things on its own.

AI for Code Review: CodeRabbit

Tue, 19 Aug 2025 16:55:02 GMT

A cybernetic rabbit (and a forged signature)

Most of the focus on AI in software development is on AI writing the code. Most of what I’ve written in this newsletter has been focused on that. And there are no shortage of products building these features.

CodeBuff (referral link)
Warp (referral link)
Claude Code
Cursor
GitHub Copilot
bolt.new

And dozens more.

But the AI tool that’s done the most to consistently increase the quality of my work isn’t any of these. It’s CodeRabbit.

(Apologies for this post sounding salesy. CodeRabbit isn’t paying me anything, I promise.)

CodeRabbit is a GitHub application that watches for commits to pull requests. When it sees changes, it spins up, analyses the changes, adds a summary of the changes to the PR, and makes review suggestions.

And it’s great at it.

CodeRabbit isn’t the only option for AI-powered code review. GitHub Copilot has a similar feature. But in my experience its recommendations are limited and less reliable than CodeRabbit’s.

The feeling I get when I receive a good human review is “Nuts, they got me.” They found the places where I was slacking off, the things that in the back of my mind I knew could be better but hoped no one would notice.

CodeRabbit gives me that feeling on almost every pull request. And it feels great.

The closest I’ve gotten to understanding how they’ve managed to make CodeRabbit work so well is this podcast interview on the Software Engineering Daily podcast (transcript).

They take advantage of their position in CI and prioritize depth of analysis over speed.
They gather context using multiple strategies: static analysis, related GitHub or Jira issues, and learnings stored in CodeRabbit from previous user interactions on reviews in the same codebase.
They spin up a sandbox containing the full codebase for their agents to use while reviewing a PR.
They allow their agents to use a terminal within the sandbox in order to allow the agent to find any additional context it needs.
They allow their agents to query the web in order to pull in up-to-date information.

Definitely listen to the full interview if you’re interested in further understanding how they’ve architected the system. It’s fascinating.

These tools don’t replace no-AI static analysis and CI checks. Having automated code quality checks that are deterministic and precisely defined provides a degree of assurance that it’s hard to imagine getting from an AI-powered tool.

But CodeRabbit appears to be doing an excellent job of providing much of the value of a traditional human code review—taking the context of the PR along with its knowledge of the codebase at large and any relevant best practices and distilling it into actionable suggestions for the developer.

My main hangup with CodeRabbit is their pricing model. They charge per assigned GitHub org seat.

This makes it challenging to use as an independent contractor who works in repositories scattered across multiple GitHub orgs. If I wish to use CodeRabbit on projects for three different clients, I have to coach each client through adding the CodeRabbit app to their GitHub organization (or get admin access to the org and do it myself), and then pay a separate subscription for my seat in each org. I’m unsure if this is mostly CodeRabbit’s fault, or if it’s at least partly due to how GitHub handles repository permissions for third-party applications.

CodeRabbit gives me a lot of optimism about how much improvement may be possible in existing AI-powered tools. It implies there may be much room to achieve gains by improving the architecture around the models they rely on, even if the models themselves improve only slowly.

Toward AI-Friendly Software Architecture

Mon, 11 Aug 2025 16:22:34 GMT

I’m interested in thinking more about the software architecture decisions that will be influenced by our use of AI coding tools going forward.

Monoliths
Headless APIs
Microservices
Monorepos

Monoliths

A monolith is a term used to describe a software project where everything is in a single codebase—no effort has been made to split things into multiple, separately-deployed systems. UI, business logic, and data access are all handled by this single codebase.

My experience has been that monoliths have been generally unpopular for a decade now because they make it harder to support multiple platforms cleanly. If you think you may want some combination of a web app, an iOS app, an Android app, a desktop app, and an Alexa app, you’ll likely want to avoid a monolith. And even if you don’t know you’ll want more than one of that list, why choose an architectural pattern that more-or-less commits you to a single platform?

I do feel like there’s been a shift back toward monoliths in recent years. One example is the popularity of NextJS. NextJS is a full-stack React platform that has taken over the React ecosystem. You can use it to build a client-only web application, but it’s designed to let you build your full application, back-end and front-end, within a single codebase.

Add to that React’s recent addition of server components and it starts to look like the JavaScript community has rediscovered monoliths, and they aren’t mad at them.

Monoliths make sense for use with AI coding tools. Having everything in a single repository makes it much easier for these tools to discover all the context needed to make a change, and makes it more likely that they’ll be able to complete the entire task in a single shot.

Headless APIs

Headless APIs are the traditional solution to the issue of monoliths tending to lock you into a single platform.

Instead of putting everything in a single codebase, you break your project into two distinct pieces: a client which the user interacts with directly, and a backend service that handles everything else—the headless API. The client receives interacts from the user and then translates these interactions into commands to the API service. The API then returns a response, perhaps including new data, which the client displays to the user.

The big advantage with this architecture is that it lets you create new, entirely separate clients to your heart’s content. You don’t have to worry about needing to refactor your business logic to support your new client, because any previous clients weren’t allowed to interact directly with the business logic previously. So your new client can use the same API as your previous clients without needing much backend change.

Reality, of course, is rarely ever this clean. New clients do often end up needing changes to the headless API. And once you have multiple clients relying on the same separate API, you need to worry that a change made to the API for one client might break another client in a way that’s hard to detect. We have tools to try to mitigate these problems—OpenAPI specifications, GraphQL endpoints, etc. But they only go so far.

Headless API architectures seem to be a mixed bag when it comes to their compatibility with AI coding tools. To the extent that they result in a project becoming multiple separate git repositories, they can make it more difficult for AI coding tools to get the access they need to context, and can mean you’ll need to switch between different repos to have your AI tool execute different sub-tasks within a larger task that spans the entire project.

On the other hand, this pattern can result in having clear contracts between the backend and the client (the aforementioned OpenAPI specifications and GraphQL schemas) which can provide well-structured and extensive sources of context for AI tools to use.

Microservices

If two deployable subsystems are better than one, then wouldn’t 100 be even better? That’s my impression of microservices.

Unfortunately I don’t have first-hand experience working within a project that uses microservices, so I can’t speak very well to their strengths and weaknesses. I know they were very popular for a period of time, that they may have advantages for systems that need to be extremely scalable and adaptive, and that they come with a potentially intense level of devops complexity. But that’s about all I know.

How well are they adapted to use with AI coding tools? No idea.

Monorepos

A monorepo refers to taking multiple separately-deployable codebases and storing them in a single git repository.

I’ve had both good and bad experiences with monorepos.

At one point I reorganized my TaskRatchet codebases to use two monorepos: one for the frontend stuff and one for the backend stuff. Doing this turned out to be a mistake. It added a lot of complexity around managing dependencies and handling CI workflows without doing much to improve developer experience.

I now think that the way to use monorepos is to keep connected codebases together when you’ve decided not to use a monolith. For example, if you have an application that you’ve decided to split into three deployable codebases—a frontend client, a backend API, and an NPM SDK—it makes sense to keep all three within a single monorepo, since these things likely depend on one another and are likely to need to change together semi-frequently.

This also allows you to get much of the benefit a monolith has for AI coding tools without needing to use a monolith.

I’m currently continuing to move toward using monorepos, hopefully organized better than they’ve been in the past.

There are a few other similar decisions I’m interested in thinking through in relation to AI coding tools:

Object-oriented vs functional programming
Static vs dynamic typing
Strong vs weak typing
Compiled vs interpreted languages

Maybe I’ll do that in a future post.

Links: Measuring AI's Impact on Productivity, GitHub's New AI Coding Tool, & more

Mon, 04 Aug 2025 16:10:35 GMT

Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. This study has had me thinking pretty hard about how I use AI coding tools, and how I can be sure I’m not fooling myself into thinking they’re helping when they aren’t. (Cross-posted to LessWrong; full paper)
LiveStore is an interesting take on reactive local-first data management.
Harper Reed posted his AI coding workflow, including how he builds his prompts.
Anthropic posted something loosely similar, detailing how they use Claude Code internally. (Via AGI Friday)
Christopher Moravec blogged his take on the oops-AI-deleted-my-prod-DB incident.
GitHub now has their own AI coding website similar to existing tools like bolt.new.
Mark Zuckerberg is pitching personal artificial super intelligences, and also aggressively hiring AI researchers.
Philip Pettit spoke with Sean Carroll on the philosophy of politics and freedom.
Tyler Vigen has a web page giving many examples of spurious correlations.
Howtown published a video on how lead exposure impacted people’s IQ and mental health for decades.
This website has a large collection of retro tiled backgrounds when you’re feeling nostalgic for GeoCities design aesthetics.
Tender is like Tinder but just for you and your significant other.
Marion Stokes secretly recorded and archived television for thirty years.
The creators of Forfeit have a new hardcore productivity app, Overlord.
There’s a theme park “dedicated to pushing buttons.”
Here’s an interactive history of Mac settings.
CodeRabbit can generate docstrings for you.
LLUMO is a platform for debugging AI agents.

AI for Coding: Collaborate or Delegate?

Mon, 28 Jul 2025 17:20:36 GMT

Recently I’ve found myself asking AI coding tools to help me do the thing myself, rather than asking them to do it for me. For the time being, this approach has several benefits:

AI coding tools are expensive—asking them to coach me gives them a lot less room to rack up a large bill while I’m not paying attention.
AI knows a lot of things I don’t, but not enough that it doesn’t regularly make mistakes I would have caught. Collaborating more directly allows me to catch those issues, while still benefiting from the AI’s breadth of knowledge.
If I allow the AI to do the thing I don’t know how to do, I don’t learn how to do it—a missed opportunity.
If I allow the AI to do a lot of work on its own, I don’t thoroughly understand what it did and why, and am in a poorer position to work on that code later on.

I think a big reason using AI coding tools for coaching rather than execution currently has so many benefits is simply because these tools aren’t yet reliable enough at loading in all the context they need. The further we get toward these tools being able to do this reliably, the weaker the argument will be for collaboration over delegation.

Though, even once we’ve reached the point where AI is reliably able to retrieve all necessary context, there are still reasons to prefer collaboration over delegation. Specifically, if your goals include:

Personal learning or skill development
Deep project knowledge
Creative control in execution

Notably, those first two goals still may apply even if your relationship to a project is entirely pragmatic. Even if you never intend to work directly inside a project again, having a thorough grasp of the technologies used and the details of the current implementation are important to your ability to make informed decisions around future development directions and priorities.

Though there we are again—thinking about our future role as developers in terms of project management instead of individual contribution.

Future Changes to TaskRatchet

Mon, 21 Jul 2025 17:25:07 GMT

abstract todo lists

TaskRatchet is a project I built back in 2020 and have continued to maintain and develop since, as time allowed. It’s a task management app that allows you to stake real money on completing each task by its associated deadline.

Recently I drafted this list of technical changes I plan to make to TaskRatchet:

Remove Astro, switch back to just React
Use Clerk for auth instead of db auth and firebase auth
Deploy to Cloudflare instead of Render.com
Spin down API v1
Set up API v2 to publish an OpenAPI spec
Switch from one list of tasks to two or three (e.g. Next and Archive)
Set up Honeycomb on the front-end

I thought I’d give a bit more context for each here.

React Over Astro

A while back I added Astro to the web app as a way to slowly transition away from React. My reasoning was that React introduced some unfortunate performance issues, and there were other front-end libraries I now prefer over React, such as Vue or Svelte. Astro would allow multiple front-end libraries to co-exist during a transition.

I now think this was a mistake.

The main performance issues were due to having two-way infinite scroll in the main tasks list, and I separately want to get rid of that. (Already have partially.) So I think all the performance improvements I need can be made without leaving React.
Even though I might like other view libraries better, I have the most experience in React.
AI coding tools are really good at working in React.
React is better supported by other things I may want to use than are Vue or Svelte.

None of this is to say anything negative about Astro. I love Astro. But it wasn’t a good direction to take in this case.

Use Clerk for Auth

This one’s a bit painful. Currently under the hood I have two authentication strategies which are operating in parallel: our own home-spun database-powered auth, and Firebase Auth. My tentative existing plan was to move everything to Firebase Auth.

However now I’ve used Clerk auth on several other side projects and it seems really great. It has React components for login, registration, forgot password flows, etc, so it will allow me to simplify the codebase while improving the user experience around authentication.

Of course, that means transitioning two systems to a third new system, which is the painful part.

Switch from Render.com to Cloudflare

Currently TaskRatchet is deployed to Render.com. Render.com has a fantastic developer experience, but it isn’t cheap for someone like me who creates a lot of little projects. So I’m working on learning Cloudflare and moving all my projects to it for hosting and compute. It makes sense for TaskRatchet to be a part of that.

Spin down API v1

Currently there are two versions of TaskRatchet’s API, and the web app uses both. I’ve been working intermittently on getting to the place where TaskRatchet only uses v2. Once that happens, I can spin down v1 and simplify our backend.

Publish an OpenAPI spec

That’s OpenAPI, not OpenAI. Having an OpenAPI spec will allow for us to generate public API documentation from our code rather than having keeping the API documented be a separate task from building the API. Also it will allow us and users (if they wish) to use the spec to generate clients to ease use of the API.

Split the Main Task List

Currently all of a user’s tasks are shown in a single task, including completed and past-due tasks. In the future I hope to split this into multiple lists, both to make the user experience more focused on a user’s relevant tasks and to improve the performance of the web app. Tentatively this means one list for tasks that are due within the last 24 hours and into the future, and a second list for everything else.

Add Honeycomb on the Front End

I already use Honeycomb for back-end instrumentation to allow me to see errors and try to track down the causes of problems. I’d like to add Honeycomb to the front-end, too, to increase my visibility into issues which may span the whole stack.

Agentic Coding Tool Failure Modes

Mon, 14 Jul 2025 16:40:22 GMT

Abstract, minimalist, non-representational impression of AI coding tools breaking down

I’ve been using agentic coding tools off-and-on for quite a while now. Mostly:

Codebuff (referral link)
Warp (referral link)
Claude Code
GitHub Copilot

They definitely have advantages:

I find that I can work with them longer without serious fatigue or when I’m already too fatigued to code without them.
At their best, they can find solutions that are more straight-forward, elegant, or idiomatic than I would have found on my own.
They know a little of just about everything, reducing the need for me to do a bunch of research before I can get started on something.
They can operate as rubber-duck partners for helping you get unstuck when you’ve been looking at a problem for a long time.

However they still have drawbacks, and I’d like to document the ones I’ve run into consistently here.

If they don’t have a good idea on how to do something, they will often persist, trying over and over, until they’ve worked themselves into an over-complicated position which may or may not actually solve the problem.
Depending on the tool, they may not consistently discover the correct context within the repository, resulting in them making similar mistakes or bad assumptions in the same project.
They tend to be expensive, or they have usage limits that you’re likely to run into quickly if you’re using them seriously.
Using them extensively can result in having code bases that you largely don’t understand, reducing your ability to work in the codebase yourself or spot issues with future work done by an AI tool.
They still hallucinate to varying degrees, which can result in incorrect documentation if they’re involved in writing it, or a lot of wasted time spent based on something they told you which is simply wrong.
They may not work well with the latest tools or tool versions based on when they were trained and the extent to which they have access to up-to-date documentation.

I feel confident that these tools will continue to improve, and that these problems will likely be solved over time. However, for the time being, they still exist, and I’d like to learn how to better compensate for these issues.

Currently I’m fairly cautious about how I use these tools on client work because of these limitations. The better I can get at avoiding these problems, the more I can make use of them in client projects.

One approach to solving some of these issues is to give the tools access to more and better-quality documentation. This can be:

Scraping documentation sites and storing the saved documentation in the repository.
Ensuring the tool has access to MCP services for searching the web or otherwise accessing up-to-date documentation.
Leveraging tool-specific methods for adding “rules” and other forms of guidance, such as Claude Code’s CLAUDE.md files.
Working with the tool itself to add and update documentation.

I’ve found that last option to be the most fraught. There seems to be a lot of variance around how well these tools are able to produce accurate, valuable documentation. And if you aren’t careful, you end up with high-volume low-quality documentation which just confuses both us developers and the tools themselves more.

I’ve tried a few tools that are designed to produce documentation for a repository, either using AI or more-traditional static analysis, or a combination. I’ve even played around with creating my own such tool. They all seem to have their own drawbacks. Here’s a list, some of which I’ve tried and some I haven’t.

In the past, Codebuff promised to do this kind of thing iteratively, creating and updating knowledge.md files throughout your codebase as it went. However it’s seemed to become less of an emphasis over time, and the tool doesn’t seem to do this very often. Though with Codebuff’s more-recent customization options, you might be able to configure it to do better.

I think in the future it would be nice if CI-time tools like CodeRabbit were better at automatically suggesting improvements and new additions to a repo’s documentation based on changes made in each pull request. Perhaps you could get closer by adding custom review instructions?

Currently my biggest complaint with CodeRabbit is that there isn’t a clear way for me to easily use it with client repositories I don’t own. Currently I can get a review on changes to these projects using their VS Code extension, but this is pretty inconvenient since my daily-driver is Zed, not VS Code.

The Tools I'm Using

Mon, 07 Jul 2025 15:43:43 GMT

“Abstract, modernist, minimalist representation of the concept of digital development work.” Also, a forged signature.

I thought I’d detail my current programming setup. It’s continuously changing, quite fast, lately. But I think a snapshot is useful.

Are there areas of my tooling or processes that you’d like more detail on? Let me know, and I may say more in a future post.

Fair warning: This post contains affiliate links.

My work machine is currently an HP Z2 Mini G4 Workstation, with 32 GB of ram. I run Debian Linux with i3 as my window manager. I have two monitors (one, two), an external webcam and mic for meetings, and an external hard drive for extra storage.

I have a manual standing desk converter that sits on top of my desk to allow me to work standing or sitting as desired. I have a small dry-erase whiteboard organizer on the desk, too, that I can use to jot down notes as I work.

Not exactly this, but similar.

My primary IDE is Zed. I use it specifically because its collaboration features work well on Linux, where I’ve had mixed results using VS Code for collaboration on Linux. I pay for GitHub Copilot and use my Copilot AI for chat and completions in Zed instead of Zed’s own AI offering.

I also still have VS Code installed, though. Currently I mainly use it when I want to get a CodeRabbit code review on a repository that I don’t own, and so can’t authorize CodeRabbit to review directly.

I’m a bit bummed that I can’t make the VS Code-based Cursor my daily driver since when I last used it I was so impressed with its AI features.

Speaking of code review, I use GitHub Actions on basically all my projects to automate running code quality checks. On most projects this includes Vitest, ESLint, Knip, and Prettier. I also have Copilot and CodeRabbit configured to automatically add review feedback on any PRs where I have enough permissions to do so.

I use Warp for my terminal. It has built-in AI that I use to help me make Linux configuration changes. Recently it’s also added more-robust agentic coding abilities that I’ve been experimenting with recently. Impressed so far. It also lets me store custom rules and prompts I can use with the AI features, and it allows me to share a terminal window when I’m collaborating with someone else on a task.

The other two terminal-based coding tools I’ve been using recently are CodeBuff and Claude Code.

Unfortunately I’m still limited by costs and/or tool limits on all these tools—Warp, CodeBuff, and Claude Code. These tools are getting better and better, but they aren’t yet to the point where I can let them run wild on client work, which means I’m mostly using them on side projects. And it’s harder to justify blowing $300 in a month on coding tools when the work I’m using them for isn’t directly bring in money.

I use Obsidian to capture information related to my work and projects. I use the Obsidian web clipper extension in my browser to clip web pages. I use Obsidian plugins to sync my notes to S3-like cloud storage (remotely-save), and to let me use AI to chat with an individual note (obsidian-copilot). I use daily notes for miscellaneous scratch pads.

I have one-note-per-task journals I use for tracking my work on tasks. So when I have a new task, I add a new note with the name of the task as the title to an appropriate Tasks folder. Then, inside this note, whenever I work on the task, I add a subheading with the current date, and document what I’m doing within that date’s section. I always add the new section to the top of the note, so the most recent work I’ve done on the task is at the top. This approach helps me get into a task quickly by reminding me of where I was at when I last worked on it, and reduces the burden on my working memory.

I track my activity in two ways. I have ActivityWatch which automatically collects detailed information about how I’m spending my time. And I have a custom script that keeps track of how much time I’m spending using my work computer, and posts that to a Beeminder goal.

I use Beeminder extensively to track and enforce my work goals. I have goals for time spent using my work computer, time spent on specific clients and projects, handling work email, shipping UVIs for TaskRatchet, handling finance tasks, and sending invoices and reports to clients. I try to keep all my Beeminder commitments manageable, and keep most of my work-related deadlines in the late morning or very early afternoon to avoid burnout given my ability to work in the afternoon isn’t consistent.

I use Slack, Discord, Telegram, and Thunderbird, all to varying degrees, for work communication. For TaskRatchet we recently switched from FreshDesk to Zoho Desk for handling support emails. I have a custom Slack support bot that we use to ease TaskRatchet support tasks.

When researching I use Perplexity and DuckDuckGo mainly, resorting to Google only when the other tools fail to find what I need. Though, with Warp as my terminal and Copilot in my IDE, many times my questions can be answered without using a browser (Chromium in my case) at all.

I’ve found myself using Claude recently when I need to draft an extensive prompt, e.g. to store as a saved prompt in Warp. Claude’s side-by-side artifact view for drafting documents is super useful for that.

I haven’t found AI to be that useful in writing yet. I’ve experimented with different times at using AI to write, but it always feels like it’s breaking the connection between speaker and writer, and personally I don’t like that. For now, I prefer authenticity over polish.

I have used AI a couple of times to write reports for clients, where it would be reasonable to say a trade-off between authenticity and functionality is perfectly fine. However I didn’t actually find that it saved me any time, since it results in a much longer report that I then have to carefully fact-check and revise. And the improved quality of the final product is arguable.

I use PayPal for invoicing clients. I use PayPal and Wise to pay subcontractors, depending on their preference. I use YNAB for tracking my business expenses on a day-to-day basis. I use Keeper Tax when I’m ready to file my taxes. I use Stripe as my payment provider for TaskRatchet. I also have a custom dashboard that I use to partially-automate various invoicing and reporting tasks.

For web hosting, I currently use a mix of Render.com and Cloudflare, and I’m moving more and more toward Cloudflare. This is mainly because deploying many small projects is expensive with Render.com. Setting aside pricing, Render.com is a magnificent developer experience.

For time tracking I use a combination of Beeminder and a custom in-house time tracker (“Narthbugz”) which runs on top of a self-hosted Baserow instance.

On Writing Publicly

Fri, 20 Jun 2025 16:32:31 GMT

“An abstract, minimalist, dark, symbolic representation of thought, uncertainty, and writing.” And a forged signature.

As you’re probably aware, I started doing this writing privately, just for those who pledged their support on Ko-fi. Then I transitioned to writing a public newsletter with Hiiv, and most recently moved here to Substack.

My process for writing over that time has been very consistent—I beemind spending a half-hour each week writing, and whatever I have written, I pretty much publish. Not a lot of editing or revising. Mostly stream-of-consciousness.

When I was in high school and college I prided myself on my writing. It was one of the things I cared a lot about and put a lot of effort into. For a couple of years I started and ran a high school student newspaper. Between high school and college I interned at a magazine. In college I minored in English.

After college, I went directly into programming, and basically stopped writing entirely. That, some extended messy relationship challenges (in the rear-view mirror now, thankfully), a go-round with anxiety/depression, and a late ADHD diagnosis all added up to losing most of my confidence in my ability to think clearly and communicate effectively.

Writing on Ko-fi, in private, to literally only those people who were paying real money to say they wanted to support me (most of you are in that group—thank you 💚), allowed myself to dip my toes back into writing in a way that was emotionally manageable.

Going from that to writing publicly has been interesting.

On Ko-fi I think I expressed a lot of uncertainty, shared more freely about things I was actively struggling with, my doubts and questions. Some of that went away while I was still writing privately, but I feel like more of that disappeared when I went entirely public.

I don’t know how I feel about that.

Some of that is due to me being less anxious about writing again, feeling more comfortable talking with you, and maybe even feeling a bit more confident in life generally.

But I’m afraid some of it is the exact opposite—feeling anxious to be writing in public, to new people, strangers, who don’t know me. And so I’m inclined to hide, speak more formally, ask fewer questions, make statements as “we” instead of “I.”

I don’t like that part.

I feel as if I’m still trying to find my voice. Who am I talking to? What are we talking about? And, more importantly, who am I as the speaker? Why should you listen to me? How should I express myself? What’s worth expressing?

The other thing that complicates all this is that my motives never have been pure for this writing. I started the Ko-fi because I was struggling financially and was hoping I could build passive income. I’ve switched to writing publicly as a way to expand my reach in a way that will hopefully support my other money-making projects (mainly contracting and TaskRatchet). Heck, I’ve even added links to this very paragraph on the off-chance one of you decides you want to give me money in some way, indirectly or not.

I think my primary goal remains to write in order to think, in order to understand things better, get things out, in front of people who might have similar questions or ideas.

I don’t want to sell or convince or position. I want to think and talk with people just like you.

Maybe that’s why I’ve been enjoying this stream-of-thought format I’ve been using most of the time.

It does, though, fail when I decide too strictly what I’m going to write about before I start writing. I think I’ve fallen in that trap with the AI After TDD series. It’s an interesting topic, one I want to continue thinking about, exploring. But giving it too much structure has left me feeling like to some degree I’ve been writing just to write—finishing a checklist rather than sharing my thoughts.

Thank you for being here with me as I figure all this out. Means a lot.

AI After TDD, pt. 3: Preserving Risk Management

Fri, 13 Jun 2025 17:39:29 GMT

An abstract, minimalist representation of the concept of risk, inspired by intricate systems in which small changes can have unexpected consequences.

Previous posts in this series:

The second benefit I listed in part one was this:

“This high test coverage makes changing existing code less risky.”

How do we preserve this benefit without strict test-driven development?

A codebase that doesn’t have this property is painful to work with. A small change in one place may result in something, perhaps seemingly unrelated, breaking in another part of the codebase.

If you think the project you’re working in is this way, you’re likely to try to make as small a change as possible, regardless of whether it improves the quality of the codebase or not, in order to reduce your exposure to these unpredictable regressions. This can result in the codebase becoming more difficult to work with over time, as pragmatic hacks accumulate and refactoring is avoided.

At its best, test-driven development addressed this issue by creating a large collection of alarms that would trigger as soon as you had caused a regression, regardless of where it was in the codebase. So you could be more aggressive with your code changes without fear that you were creating chaos in parts of the system you had forgotten or didn’t yet understand.

Much of what I wrote in part two applies here, too.

Test coverage thresholds
Automated test generation
Recording-and-playback tools

These are all likely to preserve some of the risk mitigation we’ve gotten from TDD by simply retaining much of the test coverage we used to have, just in a different way.

What follows are additional tools and strategies for achieving the same benefit. Fair warning: This is a lot of back-to-the-basics talk.

Type Systems

Typed languages in effect create a separate layer of tests. If you make a change to the type annotations or inferred types in one part of the system, you are able to receive feedback quickly on whether this change is compatible with many other parts of the system.

For our purposes, a type system should:

Apply throughout the entire codebase, either by inference or explicit annotation.
Provide rapid feedback (IDE hinting, CLI commands, compile-time errors).

With these two properties, a typed language can go a long way to removing anxiety around changing code.

Static Analysis

This overlaps with the use of type systems, but also includes any linting tool that scans your code without running or compiling it to find potential style or logic issues with the code. Linters tend to be less concerned with application functionality and more with code quality, style, and convention. Though they can also hint at things that may be a mistake.

Version Control

Knowing that every change you’ve made is safely stored to be reviewed and perhaps reverted makes a big difference.

Rapid Rollback

Relatedly, the ability to rapidly roll back a production environment is likely to become more valuable.

Rollback to any previous state (e.g. deploy or commit) should be as close to one click as possible.
The process for initiating a rollback should be well-documented to avoid needing to rediscover the process during an active incident.

It might be valuable to schedule a kind of “rollback fire drill” on a regular schedule. This way those who would be responsible for doing the rollback remain familiar with the process, and there’s a regular opportunity to spot opportunities to improve or simplify the process.

I have the uneasy feeling that there’s more to do here, but I have a hard time imagining what. What are other tools and processes that will help us remain nimble without large hand-written test suites? Especially: What tools will we need to invent?

AI After TDD: Keeping Test Coverage High

Fri, 06 Jun 2025 16:13:28 GMT

“An abstract, minimalist painting representing the concept of test coverage. Incorporate a recursive grid structure.” Forged signature as usual.

This issue is a follow-up to my last issue. I’d suggest reading it first:

Is Test-Driven Development Dead?

So. What comes after test-driven development?

These are the benefits to using test-driven development I listed previously:

Your test coverage naturally remains very high.
This high test coverage makes changing existing code less risky.
You’re forced to think through and demonstrate the change in behavior of the code you’re writing before you jump to implementation.
You’re less likely to get lost in the weeds when solving a complex problem, since TDD allows you to focus on a single, tiny behavior change at a time, and ensures if a previously-implemented behavior breaks, you know immediately.
Your code is naturally testable, since you’ve been testing everything from the beginning. And, arguably, testable code tends to be well-architected code.

How do we ensure we keep as many of these advantages as possible without using test-driven development?

This week let’s look at the first advantage.

1. “Your test coverage naturally remains very high.”

Let’s assume we don’t want to give up unit testing, but just the human-in-the-loop workflow. If we don’t have a developer writing each test before they make it pass, how do we ensure our test coverage stays high?

In my experience with AI coding tools, they are inconsistent with writing tests at best. Most of the time they never write them at all. Even when I’ve gone in and added custom rules or prompts, I still find these tools just do the thing and don’t write tests.

Require a Test Coverage Threshold

The simplest solution might be to rely more heavily on code coverage checks. I’m most familiar with Jest and Vitest, and these tools have built-in ways to check the test coverage of a particular project. Adding a test coverage requirement to CI would be a simple way to prevent code from being committed before sufficient unit tests have been added. And the developer is always free to go ask their AI tool of choice to write the tests for them.

This comes with some disadvantages.

Some pieces of code will be more valuable to test than others.
Sometimes coverage tools can have a hard time seeing actual test coverage for certain pieces of the code base depending on a project’s architecture.
Tests written for the sole purpose of increasing test coverage are often of a lower quality than those written in a test-driven style.
If we’ve decided that tests will always be written after the code it’s testing, we may lose the potential benefit of the tests’ ability to influence our project’s architecture.
We also may lose the advantage of testing first forcing us to decide ahead of time what the behavior of our code should be.

Automate Requesting AI-Generated Tests

Perhaps we add a step to our CI workflows that calls some AI coding tool and requests that it commits new tests to the current PR, perhaps in combination with a test coverage threshold. I’m not convinced that AI coding tools are consistent enough for this to be a better developer experience than working with the tools directly and locally to add tests, but perhaps in the future they will be.

Use Recording & Playback

I recently ran into a very-early-stage tool called Meticulous that I’m very excited to see mature.

Meticulous watches you as you interact with your application during development, and records the events that were fired during your session, the code paths that were exercised by your interactions, and the responses to any HTTP requests that were made for future playback.

When you create a PR, Meticulous attempts to identify a set of these sessions that will best exercise the code you’ve changed, and then runs these sessions on a known-good staging environment, and also on your PR preview environment.

It then compares the resulting behavior of the application between these two environments, and presents any differences to you to approve as a part of your PR review process.

I really want this to exist.

If this tool is able to do what they’re promising, it could potentially allow us to continue to have high test coverage without relying on the ability or inclination of our AI tools to write the tests for us.

Unfortunately it remains to be seen if they’ll be able to deliver. Currently to get any real use out of Meticulous you need to have an on-boarding call with them. My understanding is that this is because they haven’t yet gotten their tool to the level of reliability you’d need without doing manual setup work on their end tailored to your specific project.

Fingers crossed.

Is Test-Driven Development Dead?

Fri, 30 May 2025 16:14:37 GMT

“A series of red and green circles inspired by automated software testing tools, slowly degrading from left to right.” Also notice the AI out-right forged a signature.

Or, more precisely, are its days numbered?

Here I’m defining TDD (test-driven development) as a process by which code is written using the following steps:

Write a failing test
Write just enough code to make the test pass
Refactor
GOTO 1

(And by defining I mean stealing an existing definition.)

Done well, this process can provide some major advantages:

Your test coverage naturally remains very high.
This high test coverage makes changing existing code less risky.
You’re forced to think through and demonstrate the change in behavior of the code you’re writing before you jump to implementation.
You’re less likely to get lost in the weeds when solving a complex problem, since TDD allows you to focus on a single, tiny behavior change at a time, and ensures if a previously-implemented behavior breaks, you know immediately.
Your code is naturally testable, since you’ve been testing everything from the beginning. And, arguably, testable code tends to be well-architected code.

I’ve been using test-driven development since I first learned programming during a pre-college internship. My manager was an Uncle Bob devotee, and had me go through Uncle Bob’s clean code video course as a part of my training. Later I purchased and read Uncle Bob’s book titled Clean Code.

I’m no longer a strict adherent to Uncle Bob’s programming philosophy. But I did stick with TDD, and have continued to use it consistently to this day.

AI coding tools are the first thing that’s caused me to question the future of TDD.

By our definition, TDD is inherently a human-in-the-loop process. It’s goal is to create the tightest feedback loop possible in coding. Define the smallest possible change in behavior, make the smallest code change possible to verify that change in behavior, and then receive the fastest feedback possible to verify the code change was successful.

As AI coding tools become more competent, agentic, and aggressive, it increasingly calls into question this strategy.

If I can ask a robot to fix a bug, add a feature, or build a whole app, why would I instead opt to write a long series of tiny tests and ask the robot to pass each test in turn? That’s a huge sacrifice in potential velocity.

I don’t yet think that AI will be the end of unit testing—that is, automated software testing, apart from the human-in-the-loop process described above.

I’ve had mixed success asking AI coding tools to write tests for me, but it’s plausible they will continue to improve at it.
Automated test feedback may already be a valuable source of context for AI coding tools.
There’s been at least one attempt to adapt TDD to be used more explicitly by an AI coding system itself. So instead of a human developer following the process, the AI coding tool would follow the process.
At least at the moment, where AI coding tools are more efficient as collaborators with developers rather than replacements of them, there’s still plenty of value to a developer switching in and out of TDD based on whether the AI coding tool or the developer is currently driving.
Any given project’s risk profile will have a significant impact on how quickly, if ever, rigorous testing processes can be abandoned.

All that said, it currently seems inevitable to me that test-driven development as we’ve practiced it is on the way out.

Featured Project: Beeminder Autodialer

Maybe a stretch, but you could call Beeminder test-driven behavior change. I built the Beeminder Autodialer (with kind help from the Beeminder folks) to let you automatically dial your goal rates up and down based on your historical data.

Ensuring Code Quality in the Age of AI

Fri, 23 May 2025 14:10:54 GMT

Unmanaged speed, abstract

I’ve been puzzling for a while now on how our strategies for ensuring software quality will need to change as we continue leaning more and more on AI coding tools. If my current experience holds true, the shift to AI for coding tends to:

Significantly increase code output per developer
Decrease developer understanding of code produced
Introduce more variability in code quality
Decrease test coverage compared to a reasonably disciplined developer

Given that list, you might think I view these AI tools as a net-negative for software quality. That’s probably true at present, but I think the story is more complicated than that.

My hypothesis:

Adding AI tools to an existing development workflow is increasingly like installing an incredibly powerful engine in an aging budget car. Exhilarating, but risky, since it was never designed to handle that much power.

At their core, AI tools add velocity, potentially a lot of it.

Tab to accept lines, blocks, functions, even whole files.
Never switch to Google or Stack Overflow when you get stuck—just type a question in your IDE’s sidebar.
Ask an agent to implement features or execute refactors across entire code bases.

This amount of raw output increasingly strains our existing strategies for ensuring code quality.

Developer craft: The less code a developer is manually writing themselves, the less impact their skill level is going to have on the quality of that code. While there are probably developers whose skill level is lower than the average output of AI coding tools, the variability in output quality of these tools makes this difficult to rely on.
Manual testing: Of course we can manually test that the code an AI tool produced works. However, as AI tools become more and more agentic and more and more aggressive in making many edits at a time throughout a code base, the scope of the software that would need to be manually tested increases exponentially. Developers are unlikely to have the patience to do this type of thorough, repetitive, manual review.
Unit testing: If you can ask an agent to implement an entire feature in one go, you’re unlikely to take a test-first approach. Most agents are inconsistent at best at including new tests in their edits. You can ask them to write tests after the fact, which they’re happy to do. But are you really going to read those tests carefully enough to ensure they accurately ensure your requirements? Probably not.
Code review: Reviewing another developer’s code was already difficult enough—time consuming, confusing, unlikely to be effective in catching bugs. That’s why so many developers already do the bare minimum to qualify as a review. Increasing the amount of code produced per developer is only likely to increase these problems.

There is a class of tools that don’t suffer. It includes:

Formatters and auto-fixers
Linters and static analysis
Strict type systems
Record-and-playback testing
Environment monitoring (whether in development, staging, or production)
Tools that ease and/or automate rollback

These types of tools have multiple advantages:

They do not require ongoing developer intervention or discipline to maintain efficacy over time.
They do not require AI tools behave differently or more consistently than they currently do.
They can be used to provide immediate feedback to AI tooling to immediately increase the quality of AI output.
They can be integrated in continuous integration and deployment workflows to provide feedback and reduce risk at deploy time.

I’m interested in exploring further how this class of tools can be expanded, improved, or better leveraged to cover the loss of the practices AI seems to threaten.

Featured Project: Later

Back in the day there was a phone app called “Do It (Later)” that let you write down tasks you wanted to complete and postpone them until tomorrow. This is a super simple web clone of that, also adding some features I always wished the original had. I built it when I was first experimenting with what Codebuff could do (one of the AI coding tools I’ve been loosely referring to).

Will AI Make Us All Managers?

Fri, 16 May 2025 17:19:23 GMT

“Hierarchy of control. Minimalist, abstract.” Also a forged signature.

Today I watched another video by Theo about how AI has rewired his brain as a developer. A lot of his thoughts resonated with me.

So it has me thinking: What will it mean to be a developer after the dust has settled and AI has realized its full potential in software development? (Setting aside whether or not it’s reasonable to expect the current upheaval to have an end.)

One idea I’ve heard a few times now (confusingly, not in the above-linked video; sorry) is that AI in the workplace will in effect force us out of being individual contributors and into something closer to a managerial role, except instead of managing people we’ll be managing AI agents. And so, perhaps counter-intuitively, even as AI might reduce the number of humans required to to accomplish any given business outcome, the classic skills associated with being a manager may become more valuable.

Examples of skills that might apply just as well to managing a fleet of AI agents as a team of old-fashioned humans:

Delegation
Project & task specification
Performance feedback
Translation of business objectives to actionable tasks
Project management

I’m still somewhat skeptical of this prediction. It strikes me as a trend that could just as easily be obsoleted by future AI advancements or changes in how businesses operate to better accommodate AI tools.

It rhymes with the idea that companies will continue hiring people to specialize in prompt engineering, when it seems more likely to me that this skill will eventually become less valuable over time as AI companies improve their products’ ability to get the user to their desired outcome without needing specialized skill in manipulating a model’s psychology.

Ways AI tools and products could improve to require less managerial prowess:

Rely less on free-form chat inputs and more on structured processes and user interfaces.
Estimate risk and ambiguity around a given task, and then proactively request clarification before executing.
Spawn subordinate agents to execute sub-tasks (agentic systems—they already exist).
Manage and update over time an internal model of business objectives and preferred tasks and processes to achieve them.
Rely more on fully-specified, automated feedback mechanisms (think: continuous integration practices already ubiquitous in software development).

In short, my current feeling is that AI tools and systems will increasingly manage themselves rather than needing something akin to traditional team management.

Featured Project: Pa11y Ratchet

Speaking of CI, a couple of collaborators and I have built a GitHub action that allows you to ensure a team makes progress on fixing accessibility issues, even if you have a huge existing backlog of problems.

It does so by comparing the total count of issues between a PR and the branch it’s merging into, and only failing if the number of issues go up.

I’ve been using it for basically a year at this point, including on client projects, and it’s been working great. Give it a look!

Limiting Fixed-Bid Contract Risk

Fri, 09 May 2025 16:20:11 GMT

Squares scaling to infinity, into darkness.

Recently I’ve been thinking more about how I can reduce risk around my fixed bid contracts, ideally to me and the client.

The primary challenge I’ve faced with fixed bids is that there’s no bound on how long they can take. And this can create significant cash flow issues when a contract inevitably proves to be much harder than expected.

I include an early cancellation clause in all my contracts which is supposed to handle this issue. It states that either party can cancel the contract at any time, and the client agrees to pay a percentage of the contract’s value based on the number of tasks that were completed before cancellation.

The problem with this is that I find it extremely difficult to take advantage of, for a few reasons.

I don’t want to disappoint the client by failing to deliver the agreed-upon results.
If cash flow is struggling, my instinct is to double down and get that final payment after the contract is completed.
My ADHD means the cost of switching to trying to decide whether to cancel can feel painfully high.
It never feels like I’m actually any more than a few focused hours away from solving whatever’s currently blocking me.

What this all ends up meaning is that, even though I’ve given myself the option to cancel at any time, in reality I’ll push through contracts regardless of how long over they go or how much financial strain I’m putting myself in.

Recently I’ve been toying with the idea of having some threshold at which I’m required to reevaluate a contract, say when I’ve hit 2x my original estimate. But the idea hasn’t felt like it would actually reliably solve the problem.

Ensuring I’m prompted at the appropriate time (when I hit 2x) feels difficult and brittle, given I have a history of not tracking my time when I’m way over on a task, even though I definitely should be.
If I solve that and manage to ensure I do the review, I’m likely to be motivated to do it as quickly as possible to get back to the “real work.”
If I do the review and decide I do need to cancel the contract, it feels like it would be difficult to communicate to the client, it being due to hitting a threshold that’s invisible to the client and a squishy analysis of the value of cancelling the current contract and reassessing the project for a new contract.

I think I’ve found a different take on this idea that solves all these issues. Instead of using a multiple of the original estimate as my threshold, I should use a date, a deadline in time. And instead of that deadline triggering a review, it should simply automatically terminate the contract.

This has quite a few benefits:

It doesn’t require any code changes to my time tracking software to trigger.
It’s entirely transparent to the client.
It’s hopefully easier to sell to the client as a way to reduce their risk as much as mine.
It doesn’t introduce the new uncertainty and friction of needing to decide whether or not to cancel the contract.
It’s simple to represent as a new clause in future contracts.
It creates a hard bound on cash flow risk for any given contract.
It retains compatibility with my existing early cancellation clause.
It guards against more types of risk—not just going over on the work itself, but also things like an unforeseen event that greatly reduces our development bandwidth.
It creates a clear deadline to keep us focused on the contract at hand.
It creates an additional incentive to effectively break down the tasks within the contract during initial proposal to allow us to be paid fairly in the case that we don’t meet our deadline.

I haven’t yet discussed this with my clients. I’m a little nervous about how they’ll react. I’m hopeful, though, that they’ll like the idea. I need to change something in order for our fixed bids to continue to be a practical part of our work.

Zed vs VS Code & Cursor

Fri, 02 May 2025 17:11:32 GMT

Abstract computer code in several colors

Giving Zed Another Look

Recently my brother and I have started using Zed again. Zed is a competitor to VS Code, built by some of the same folks behind Atom.

When I tried Zed previously it seemed like a really neat project that wasn’t ready for me to use yet, missing language features I relied on. It seems like it’s come a very long way since then, with an impressive list of supported languages.

The reason we’re trying Zed out again now is because of the issues we’ve had recently with multiplayer pairing in VS Code and Cursor. We’ve used Microsoft’s Live Share plugin for a long time now, and it’s worked great. However since I’ve switched to Linux and started using Cursor (a fork of VS Code), it’s become pretty much impossible for us to use. We tried switching to another VS Code extension called Open Collaboration Tools, but we’ve found it to be unreliable.

Unlike VS Code, Zed has collaboration built-in. And after our recent struggles with VS Code-based IDEs, it’s been a big relief.

A few observations after just a couple of days back in Zed:

Zed’s collaboration features are fantastic, though not intuitive on first attempt. However once we figured out how to use them, they work very well, and I think we already prefer Zed’s implementation to how Live Share works.
So far this time I’ve only used Zed for a fairly standard Node server-side project. But I was very impressed how well it worked out of the box. It immediately began showing me TypeScript and eslint warnings inline. I’ll be interested to see how it holds up when I throw other stacks at it. I’m especially interested in how it handles Ruby. Whether because of my lack of Ruby experience or due to something generally lacking in VS Code’s ecosystem, I’ve never had a good experience working with Ruby in VS Code.
So far Zed is very fast. I know that’s been a big focus for the Zed team. I’ll be interested to see if the speed advantage persists as I continue customizing my Zed configuration and installing more extensions.
Zed has their own hosted AI service powering their code completions and chat assistant. It’s unclear to me what the pricing for their AI features is or will end up being, though so far I haven’t needed to pay to use it. So far it’s passable. Definitely worse than Cursor. Zed does allow you to use GitHub Copilot or your own AI API keys. Though I have a feeling that I’d still prefer Cursor to Zed due to Cursor’s multi-line edit suggestions, smart rewrites, cursor prediction, and agentic assistant mode. Zed has some serious catching up to do.

Some Interesting Things

JetBrains has a product called Junie which appears to be their agentic coding tool. I used JetBrains IDEs for years when I first started in web development. They make quality software, so I wouldn’t count them out yet.
AnythingLLM is an AI desktop tool that allows you to provide your own API keys. The biggest reason I gave it a go was that they make it easy to install it on Linux. It seems to have a good set of features. I’m not sure how much use I’ll actually get out of it.
Hashnode is a service for building technical blogs and documentation sites. I’m especially interested in whether their GitHub integration makes them a viable alternative to GitBook. Unfortunately Hashnode’s GitHub integration is on their $200/month plan, which is far too rich for me.

AI for business data & using AI coding tools responsibly

Fri, 25 Apr 2025 16:52:22 GMT

Abstract representation of the joining of business data and artificial intelligence

AI for Querying Business Data

I’ve been thinking lately about how to make it easier for me to query my own business data—information bout clients, contracts, our own tools and processes, etc, etc.

One of my pain points when working with clients is that often they’ll ask questions about things that I don’t currently have loaded in my head, and then I need to go figure out what the correct answers are and how to translate the answer to be understandable to the client. This can be disruptive and frustrating.

I talked to my business coach, Philip Hellyer, about this, and he suggested that I might use one of the AI chat products to reduce this friction, whether by manually adding documents to something like ChatGPT or building something more automated.

Of course, as a developer it’s very tempting to jump to the over-engineered solution. Automatic archival of business data into an S3-like data lake, then ingest the data into things like Voyage AI and Zep. And expose it all via custom Discord and Slack bots.

I did recently hear an add for a product that’s trying to solve a similar issue I think—Informatica. Seems like basically what I’m talking about, that being an AI-forward data lake solution. Though it being so enterprise-focused I doubt it would actually be a good solution for me.

Being More Responsible with Git & AI

I recently watched this video about how to be responsible when using AI coding tools. It’s a good watch.

Theo’s main point is that the more we use AI to write code, resulting in more code for less time, the more we need to shift our time to reviewing the code we’ve generated. Basically Theo’s stance is that more manual code review is better and the direction we should be moving.

I’m not sure how I feel about this. I feel like the more we increase the velocity of our code generation the more we need to put effort into new approaches to automated review, validation, and rollback. That doesn’t necessarily mean using AI to automate code verification (though that could be part of a solution). At this point I feel like most of that should be non-AI tooling. Things like (the maybe-dying and probably-much-less-AI-than-their-marketing-implies) Meticulous.

One thing I didn’t know before watching the video was the command git add -p, specifically the -p option. It allows you to review the work you’ve done on your local machine, hunk by hunk, and decide whether or not to stage each change individually. I’ve been using it a ton since watching Theo’s video. It’s great.

Interesting Stuff

reviewdog is a tool for programmatic posting of review comments to GitHub.
Convex just released Convex Chef, another AI app builder, but this one promising to do much better at the backend stuff. (Convex is the backend service that the Codebuff team recommends)
ncc is a tool for compiling a Node.JS module to a single file. I recently used it when I was building my new experimental GitHub action, UVI Finder.

Issue 0

Sun, 20 Apr 2025 16:41:00 GMT

“A single unopened envelope, still life.” Also a forged signature.

This is issue zero! Thanks for being here.

Definitely reply if you have thoughts on the content, format, or whatever. (I think you can do that? I guess let me know if replying to this email doesn’t work, either. My email is nathan@pinepeakdigital.com)

Hope you’re having a great weekend!
Narthur

Documentation Scraping

I’ve been experimenting with scraping documentation and adding it to my repositories to improve the effectiveness of tools like Codebuff and Cursor. Initially I’ve been using mdCrawler for this purpose, but I’ve also been experimenting with building my own repo to crawl a whole list of documentation sources. So far I’ve been using crawler and turndown for the experiment.

Building Agentic AI

I recently watched Microsoft’s beginner course to building agentic AI. And then I built a proof-of-concept agentic system to break down a project into a series of tasks and estimate the time needed to complete each task. I used Praison as my framework to build the tool, along with Codebuff and scraped docs as described above, and Zep for semantic memory. It was surprisingly easy to get something set up and working, though I’m not sure how much more effort it would take to make the tool perform consistently when it comes to accuracy.

Using AI in Pull Requests

I’ve been experimenting with Copilot’s new PR-focused features, including generating PR summaries and requesting a PR review from Copilot. It also has features for iterating on a PR but I haven’t tried that yet.

I’ve also been trying out using Meticulous to automatically test PRs. Their marketing material uses the term AI a ton, I’m not sure how much that’s actually true yet. But regardless the concept seems really useful.

Basically you add a script to your site that records your sessions, but only when in development and staging. So you aren’t recording end users. When you make a PR, Meticulous then selects a subset of these sessions and replays them both against your PR preview and your production environment. It then generates a report of differences, which you can choose to approve or not. Really neat idea, especially as we may be moving further and further toward “vibe coding.”

More Interesting Things

JS Engine lets you run JavaScript inside your Obsidian notes. Plus same person’s built some other interesting Obsidian plugins, too.
Lynx is yet another write-once-deploy-anywhere tool set. Anything that pushes us closer to a web-technology-everywhere future is a win in my book.
FilePizza is a browser-based peer-to-peer file transfer tool.
SST is an infrastructure-as-code framework. Maybe similar to Terraform? Maybe better?
Hydrogen is Shopify’s official framework for building custom Shopify storefronts.
bolt.new lets you prompt to create an entire web or mobile app in a single go. I literally said “build me a tic tac toe game” and this is what it created and then deployed to Netlify for me.
DSNP is a decentralized social networking protocol (oh, right, that’s what it stands for). How does it relate to the AT protocol, ActivityPub, and the Fediverse? I don’t know. I try to stay off social media.
Beeminder-friend Mary just published a new visual time management app for iOS.
Anthropic recently added a new $100 Max tier
Anthropic also added a new research feature that looks to be a combination of reasoning and gathering context via multiple searches both of the open web and any of your own information you may have given Claude access to.
Zep is an API for building and referencing a semantic knowledge graph as a kind of memory for AI applications.
Zep published a blog post on The One-Token Trick in which they explain how they’ve leveraged OpenAI’s API to determine the relevance of search results while reducing cost by limiting the LLM’s response to a single token.
Lovable is yet another AI-powered app builder.
This article is a deep-dive on choosing the right products to add lighting to your LEGO sets. I’m especially intrigued by Brickstuff’s modular lighting system.
Voyage AI is a third-party embeddings API recommended by Anthropic’s documentation.