This update adds change tracking. When your agents change a file you’re working on, their changes are automatically highlighted as they appear. It looks like this: Each agent's changes are highlighted in its own colour. A best effort attempt is made to label the agent, otherwise it gets a generic label, either way you can edit labels in the legend in the corner. Highlights stay with the agent's text while you keep working and are not saved to the file. […1 min read]
I’ve been working on building a personal agent that is both useful and secure and have come to the conclusion that it needs a new kind of harness, specifically one without a shell. A personal agent comes with the lethal trifecta by default — in order to be useful, it needs access to your data and the internet, which is full of untrusted content and ways to exfiltrate information. […14 min read]
I made a markdown editor for MacOS! With Claude writing most of my code now I spend a lot more time than I used to editing docs. I prefer working in markdown, and wanted a really simple wysiwyg editor that works like a word processor but saves files as markdown. I often work with agents on docs now, so I needed an editor that would not break my workflow if the file was edited while open. […5 min read]
This release adds a read-only viewer for slack canvases that pops over most of the screen and looks like this: It also adds an unread section that surfaces unread messages to the top of the side bar, which I needed because many of my workspaces have far too many channels so unread get buried. It looks like this: […1 min read]
These two releases fix a few small bugs and bring in two recent improvements from upstream. This one fixes some data races in the workspace sidebar and finder lists. There was a bug in the threads and activity views where keys could act on a message that wasn't visible anymore, and some jankiness rendering selected cards in the threads, the background selection tint now runs the full width of the line of each row in the threads view. […1 min read]
This essay was originally written for and submitted to the Pragmatic Engineer essay contest in October 2026. At some point earlier this year I realized I was not enjoying work the way I used to. I'm the kind of person who likes solving problems for a living. On a good day I might even go so far as to say I enjoy the work of getting to the bottom of an issue and fixing it from first principles. […38 min read]
I made a test runner for Clojure! Clojure is still my language of choice and I've been writing most of my personal projects with it (or babashka) lately, and especially in the babashka projects have been wishing for a better test running experience. I use vitest at work, so it inspired a lot of the functionality of volley. […4 min read]
This really resonates with me. I’ve found myself reading less and less code and spending more and more time building what could broadly be described as verification systems. I wonder sometimes if that’s crazy, but at the same time I’m getting better results than ever.
Throughout history, we’ve written code so that it is clear and concise; so that it’s easily read and maintained. We do this to be nice to the people who come after (including ourselves). We do this so that we can write tests and make sure they work and so that when something fails, we can troubleshoot it.
It’s worth reflecting on why we cared so much about code quality. I always cared more than anyone on any of my teams. I was the biggest advocate for open standards and best practices and idiomatic code. I still am, though, I just don’t think I need to see the source code to judge these things anymore.
The idea of an AI generating code that is reviewed by another AI that is then possibly deployed by yet another AI terrifies me…
I’ve learned to conquer that fear by releasing more often. By automating things and releasing more frequently, I have to build code that I trust.
I’ve come to the same conclusion. Shipping more frequently forces a discipline it was easy to get by without before. It used to be so slow to write code that preparing a release and shipping it used to be a relatively minor extra step. Now you can have new releases ready to verify and ship as frequently as you want, so it really forces us to be specific and clear about how we know the release is ready. It’s not feasible to manually QA every release end to end — it never was — so we have to invest in automated verification.
If the code does what it’s supposed to, it does it as fast as it’s supposed to and as reliably as it’s supposed to, and it deploys properly and holds up to stress and fuzz testing and benchmarks… do I still care what the code looks like?
This is where I’ve landed too. If the code demonstrably works, do I need to personally review every line? I’d say no.
If we can automate confidence measuring in human-generated code, then we can do the same for AI-generated code.
I’ve basically accepted that this is my job now, i.e. building these automated verification systems. In a way it’s not all that different than before, it’s just a much bigger part of the job. We use closed-source software and systems in our software all the time, sometimes on critical paths. I thought about how I used to handle integrating some database or other proprietary library or third party service. There are many ways I would convince myself it was doing what I wanted. I don’t see this way of working as all that different.
I've been having issues lately with my machine running out of RAM because of too many agents doing too many things at once. I know I know I need to get on the cloud-agent bandwagon, I'm working on it, but in the meantime I have become very productive with a dozen or so claude sessions running locally all the time. Anyway all that to say, I have started to pay a lot more attention to what is using up all my RAM because I ran out for the first time the other day. […5 min read]
I started building a useful personal agent. What makes it useful is that it runs on my computer, but this immediately raises concerns about data exfiltration. I use Apple reminders (among other things) to organise my life so I had it write a little script to be able to interact with those, which works great. One of the main things I want help with is getting a handle on my chaotic piles of todos. They are scattered all over the place and all mixed up. […2 min read]