Published on 2026-03-09
]]>Published on 2026-03-09
Tags: commentary, git, llms, software-eng-auto
Here's my actual take on all of this, the thing I think people are dancing around but not saying directly.
Filesystems can redefine what personal computing means in the age of AI.
Not in the "everything runs locally" sense (but maybe?). In the sense that your data, your context, your preferences, your skills, your memory β lives in a format you own, that any agent can read, that isn't locked inside a specific application.
I like this vision of the future β personal data in whatever form is easiest or convenient, stored as the person chooses, arbitrary computation enabled by the natural language interface of LLMs. As I read this superb summary of the current state of coding agents intersecting with the filesystem, I had a couple thoughts.
]]>Published on 2026-02-18
]]>Published on 2026-02-18
Tags: article, git, llm, ocaml, software-eng, software-eng-auto
I've decided to use this project as a testbed for automatic development, to explore the kinds of techniques described in recent results [1] [2], and to speed up development. I'll be making the vast majority of changes to the codebase via coding agents, exploring what controls are needed to stay hands-off yet maintain code quality.
I've played around with longer AGENTS.md and not seen much value. Agents would ignore pieces, and after a while it felt like simply a waste of context space. I'm keeping AGENTS.md short this time around, "linking" to where more information can be retrieved, with the hope that brevity keeps the content important.
Published on 2026-02-03
]]>Published on 2026-02-03
Tags: article, database, git, ocaml, software-eng
Today's update is brought to you by my lack of motivation π. I decided to work on building out a storage layer for Knowledge Bases objects, and then got burned by lack of interest.
Restating our storage requirements: we need notes, todos, etc to be persisted to disk in a way where git's diff will capably show edits, additions, and deletions, and which allows for easily querying these objects by identifier or by their relation to each other (we want to support parent-child, related-to, etc). To meet those requirements I intend to persist data in two ways. First, in an appropriately-sorted JSON or YAML file, to solve for the git-diff requirement. Second, in a SQLite database to make it easy to add/edit/delete/query. The program will mirror the SQLite database onto the JSON file unless it's determined to be out of date (i.e. when the git branch is changed), in which case we'll rebuild the database from the JSON file. For now I'm starting with the SQLite db, as that can be useful for purely local todo storage, and we'll bolt-on the ability to synchronize them over git later.
]]>Published on 2026-01-28
]]>Published on 2026-01-28
Tags: commentary, erlang, git, llm, software-eng, software-eng-auto
I am gratified to see some of my musings on the direction of coding agents are proving accurate. In September of last year I speculated that, given the non-deterministic and faulty nature of LLMs, folks might be served by adopting fault-tolerant architectures to orchestrate coding agents:
]]>From everything I've seen, we're not yet in a situation where it's either practical or economical to execute multiple coding agents in parallel or orchestrated. However I think in a couple years the technology will be cheap enough that we'll start needing to think about how to orchestrate groups of agents, and the idea of leaning on Erlang's learnings intrigues me. Constructing the agents and their execution frameworks as individual actors for concurrent execution, while arraying some as supervisors and others as workers, seems rich for investigation.
Published on 2026-01-01
]]>Published on 2026-01-01
Tags: article, git, meta, ocaml, static-site
For 2024's New Year's resolution I decided I'd finally build and publish a personal website. That I'd write up my thoughts on the articles I was reading and post them instead of dumping them on friends π. In review, I'm happy to say I succeeded.
I wrote and published 164 blog posts over the past year, not counting this post. September was my most prolific month. I initialized the OCaml project that became the static site generator in late January, writing a test post at the beginning of February to work out frontmatter parsing, markdown generation, and my custom templating language. The first "real" post came at the end of June, a few days after I bought the domain name.
]]>Published on 2025-11-30
]]>Published on 2025-11-30
Tags: article, git, ocaml, software-eng
TypeID is a micro-standard combining a number of well-thought-out decisions.
TypeIDs are a modern, type-safe extension of UUIDv7. Inspired by a similar use of prefixes in Stripe's APIs.
TypeIDs are canonically encoded as lowercase strings consisting of three parts:
- A type prefix (at most 63 characters in all lowercase snake_case ASCII
[a-z_]).- An underscore '_' separator
- A 128-bit UUIDv7 encoded as a 26-character string using a modified base32 encoding.
user_2x4y6z8a0b1c2d3e4f5g6h7j8k
ββββ ββββββββββββββββββββββββββ
type uuid suffix (base32)
Most identifiers, barring a specialized context, should include a "type" for the identifier. Interconnected computer systems are always passing around identifiers β for someone holding an identifier in their database it is really valuable to know who that identifier belongs to as well as what the identifier is for. For example in a financial institution handling investments, md_quote_2x4y6z8a0b1c2d3e4f5g6h7j8k can tell the receiver that they're holding a reference to a stock price quote, owned by the market data (md) system. Identifier types give engineers metadata, which can be especially useful when there's a bug in the system β no need to stress whether the integer identifier you're currently holding came from the user table or news table.
Published on 2025-11-07
]]>Published on 2025-11-07
Tags: commentary, git, llm, software-eng
I learned about git commit footers AKA git trailers, a few years back, from engineers recommending it as a structured commit information strategy similar to conventional commits. None of the jobs I've worked have cared to track information at that level of detail. I think the code review tool at Amazon would stick the review URL as a footer, but that was as far as I've ever seen this feature used on the job. Xe Iaso's recent blog post has drawn my attention to a new usage similar to the code review one β labeling commits as Assisted-by a coding agent.
Published on 2025-10-22
]]>Published on 2025-10-22
Tags: article, git, llm, ocaml
A couple days ago, Steve Yegge wrote about a coding agent tool he's been developing called Beads.
Beads is a lightweight memory system for coding agents, using a graph-based issue tracker. Four kinds of dependencies work to chain your issues together like beads, making them easy for agents to follow for long distances, and reliably perform complex task streams in the right order.
I haven't had an opportunity to see if it works well or not, but the feature set seems straightforward to implement and I've been looking for a project to work on which will involve OCaml and publishing to opam. I'll be documenting the development process here π.
]]>Published on 2025-10-10
]]>Published on 2025-10-10
Tags: communication, git, software-eng, til
The Linux patch submission process has a nice guide (via) on crafting git commit messages:
]]>Describe your changes in imperative mood, e.g. βmake xyzzy do frotzβ instead of β[This patch] makes xyzzy do frotzβ or β[I] changed xyzzy to do frotzβ, as if you are giving orders to the codebase to change its behaviour.
Published on 2025-09-04
]]>Published on 2025-09-04
Tags: git, software-eng, til
I came across "Git exclude, a handy feature you might not know about" by Marijke Luttekes, and TIL that git has a local-only ignore files feature. Unlike .gitignore, you can put file paths to be ignored by git into .git/info/exclude, but there's no file checked into tracked files, so your ignored files aren't shared with people you're working with. Useful for local notes or snippets or your favorite text editor's repo-specific configuration.
Published on 2025-08-20
]]>Published on 2025-08-20
Tags: code-review, commentary, git, software-eng
I saw an interesting concurrence between a couple blog posts that came across my feed:
In both there's a desire to capture the conversations that produced code, alongside the code. For the Tigerbeetle dev, the desire is to reuse git and your usual text editor when doing code reviews, so that the code review comments, answers, and adjustments live in git as part of the history. For the Zed team, they think git is insufficient for capturing the conversations they're having, which I presume would include code review, such that they're going to build a new version control system. I wonder if the Zed team and the Tigerbeetle dev are feeling the same pain around trying to orchestrate communication within git's commit system.
]]>