I published Two Small Wins That Turned Out to Be the Same Win, about moving my resume pipeline onto a Maestri canvas, teaching it to enforce its own two-page limit, and experimenting with local dictation. They looked like separate improvements until I realised each one removed the same mechanical tax between having an idea and acting on it.
Moving a resume pipeline onto Maestri, teaching it to enforce its own
two-page limit, and trying local dictation apps all removed the same thing:
the mechanical tax between having an idea and acting on it.
A new style of working with AI has been clicking for me lately: keeping several projects open at once, letting the main agent spawn off sub-agents per project, then hopping between them as work lands.
The glue is AGENTS.md and CLAUDE.md in each repo, which keeps every spawned agent oriented to that project's conventions while I focus on the next handoff. The loop in each project stays the same: pick a feature, write tests, document progress and findings as it goes, commit atomically.
I shipped v2026.05.2 of dotfiles as a follow-up polish pass on yesterday's tmux and Emacs reset.
This release adds a basic macOS Ghostty config, restores a bunch of the small Spacemacs habits I still wanted like fuzzy M-x, Helm buffer switching, avy motion, kj insert escape, project ripgrep search, restart and pasteboard bindings, plus YAML mode for config editing.
I shipped v2026.5.1 of dotfiles, which pairs a nicer tmux workflow with the move away from the old Spacemacs setup into a smaller hand-rolled Emacs config. The tmux side gives me a one-keystroke 70/20/10 vertical layout plus a safe top-and-middle pane swap, while PR #2 keeps the core editor ergonomics I care about like Evil, leader keys, Magit, Helm-style tracked file finding, and early theme loading without the extra framework machinery. This is the point where the repo feels easier to understand and own, and I want to do a fuller write-up on the tmux and "Subspacemacs" workflow soon.
Published Tmux 70/20/10 Layout Shortcuts, a note about building a one-keystroke tmux layout that creates a stable 70/20/10 vertical stack and only allows pane swapping when the window is explicitly tagged as that layout. The useful part was not just the final run-shell binding, but the testing approach: using detached tmux sessions plus list-keys, list-panes, and show-options as a lightweight TDD harness before touching the real config. This is one piece of a broader terminal and editor workflow cleanup, and I want to write that larger tmux plus lightweight Emacs story up properly soon.
I published Building a Lightweight Emacs Config After Spacemacs, the fuller write-up I promised when I shipped the dotfiles update earlier today. It walks through why I left Spacemacs, what I kept (Evil, leader keys, Magit, Helm-style tracked file finding, early theme loading), and how the new ~/.emacs.d is organized as a small set of explicit modules instead of a framework.
I published My AI-Assisted Terminal Setup: Subspace Emacs and a Tmux Layout Shortcut, the fuller write-up that ties together the tmux 70/20/10 layout and the move off Spacemacs into Subspace Emacs. It covers how Claude and Codex split the work between research and implementation, the tmux-as-TDD-harness approach that unblocked the layout binding, and the tmux/tmux#1839 discovery that finally let swap-pane preserve zoom state. This supersedes the two narrower notes from earlier today.
Two projects in one: a lightweight Emacs config I actually own (Subspace Emacs), and a tmux 70/20/10 vertical layout I can summon and reshape with a single keystroke. Built collaboratively with Claude and Codex.
A small tmux workflow improvement: create a repeatable 70/20/10 vertical stack in one keystroke, then swap the top and middle panes without breaking the proportions.
It uses ProjectSpire as the working example: instructions as project memory, plans for intent, Captain Logs for collaboration taste, devlogs for technical history, and skills or workflows for repeated mechanical steps.
The bottleneck isn't the model. It's whether your repo can explain itself to a fresh agent. Here's how I'm building AgentOS, a project environment that gets smarter the more it's used.
Published The Accelerated Speed of Creation, a reflection on how much faster the path from thought to shipped artifact has become with coding agents handling the translation layer around writing, blog workflow, and routine Git operations. I also kept the earlier Encoding My Blog Workflow for Coding Agents draft as a note rather than a post, because it was useful and concrete but still did not meet my standard for what the real piece needed to be.
This past week I shipped across code and writing at a pace that would have felt unrealistic before AI. The surprising part was that it did not feel frantic; it felt like less friction between thought and artifact. It truly feels like working at warp speed, 😜.
Look at this. This is what I have shipped so far in a single week and growing (full list here):
A preserved draft that did not meet my standard for a full post. I'm keeping it here as a record of something useful and concrete that still missed the cut on human judgment.
I split the blog editing rules into repo-local skills in 22c4d7d. post-and-note-workflow now makes the timeline-entry rule explicit, while frontmatter-editing routes posts/, notes/, and timeline/ to canonical front matter docs instead of burying that guidance in CLAUDE.blog.md. I also cleaned up timeline-entry so its tag guidance matches the repo defaults.
I published Smart AI Token Consumption as a note on matching model choice to task complexity instead of defaulting to the biggest model. It captures the split I keep using in practice: light models for mechanical work, stronger reasoning only when the problem actually needs it.
I wanted a thread-like place for public work notes that stayed fully mine. Threaded timeline entries let Subspace Builder capture progress in Markdown, in Git, and in whatever order the work actually happened.
A practical split between light and heavy models: use the smallest capable model for mechanical work, and reserve stronger reasoning for hard engineering problems.
I moved the timeline-entry workflow into a repo-local skill in f7fceef. It now sits at .claude/skills/timeline-entry/SKILL.md, with the date/time quoting rules, status tags, and commit-based workflow close to the files it writes.
I added a /release skill to 11ty-subspace-builder in f1cb3a3. It captures the release ritual in one place: choose the semver bump, update package.json, commit chore: release vX.Y.Z, push, and create the GitHub release with the right title, body, and compare link.
I published The Limits of AI and Where Humans Shine — a devlog about a tiny timeline sorting bug that turned into a useful comparison between AI confidence, runtime verification, and human judgement. It follows the fix from plausible-but-wrong timestamp changes to a quoted-date guard that keeps the timeline honest.
I hit a bug that looked too small to be interesting: entries on my timeline page were not sorted correctly within the same day.
The page had a date, a time, and a custom Eleventy collection sort. That sounds like the whole problem space. Sort by date plus time, reverse the collection for newest first, done. Instead, April 12 was rendering in a strange order: 00:01, 10:11, 22:16, 15:49, 22:20.
A short reflection on how a few recent blog improvements, small experiments, and notes turned my site into a digital garden that feels calm, cohesive, and genuinely mine.
I've been building a habit-logging iOS app called ProjectDawn. Not because the App Store needs another habit tracker, but because I wanted a personal project that was genuinely mine and open source, and a project that can answer this openly: what does it feel like to build a real, modular, native iOS app with AI as a primary collaborator?
This post is part personal log, part technical retrospective. It covers the tools I used, what surprised me, where the AI fell flat, and the biggest shifts in how I think about building things now.
I’ve had the Umami + Ansible post in my head for ages, but it touched three different repositories and a whole bunch of code snippets. Totally doable, but undeniably tedious — which is why it kept slipping down the backlog. You can read the finished article here: Private Analytics With Umami, Docker Compose, and Ansible.
The idea that finally nudged it forward was simple: why not let GPT (Codex) do the heavy lifting while I steer?
I want tmux to feel like one cohesive environment that never goes away. When I am docked at my desk, I spread iTerm across multiple Mission Control desktops and keep a different project on each space, with some other tools I need for that specific project. Later, when I grab my MacBook Air or open Blink on my iPhone or iPad, I want those exact same panes, command histories, and scrollback.
Plain tmux attach gets close, but the shared "current window" breaks the illusion. When I switch to another window in my main terminal, all other tmux clients jump to the same window and interrupts whatever flow I was in. I wanted tmux to be stateful and multi-focus.
Building small websites with GPT-5 Codex turned out to be less about typing code and more about collaboration. From crude sketches to polished sites, the model took on the heavy lifting while I guided direction and design.
Along the way I discovered both the joy of fast iteration and the limits of relying on an AI partner. These projects became less about the sites themselves and more about exploring a new style of programming — conversational, creative, and sometimes flawed, but always eye-opening.
Last month, my girlfriend mentioned she needed a sleek portfolio site, and I realized I’d been meaning to start a personal tech blog.
I wanted something lightweight—easy to spin up and even easier to tweak. So I dove in: building a small 11ty + Tachyons site from scratch, pushing every iteration live in under a minute, and watching her face light up with each update even though she’s halfway across the country.