tl;dr; I put a call out for folks to schedule a 30 min 1:1 with me to talk about their backgrounds, agentic workflows, and anything else on their mind. I shared a calendar link that had my entire calendar open on it. Within 30 minutes, after seeing the pace of bookings, I realized this was a mistake and locked things down. The interest was beyond my expectation.

When I told my wife I did this, she looked at me like I’m crazy.

Wife: “You’re talking to strangers on the internet!?!”

Me: “Yes”

Wife: “Why?”

Me: “Research. I want to know who’s using AI and how.”

Wife: “What if they do weird stuff?”

Me: “Then I’ll hang up the call.”

Wife: “…”

I don’t think I convinced her this was a good idea.

I’m now on day 3 of the interviews with another week and a half to go. I’ve talked to about 15 people so far and every single conversation was great. The amount of diversity in background and workflow was aligned with my hypothesis going into this, and at the same time, so many of these folks were inspiring to talk to! AI and agentic coding in particular is changing the trajectory of lives and companies.

Also, in case you were wondering, everyone is super normal and professional.

I plan on sharing a lot more about what I’m learning and sharing over the next couple of weeks, and then I’ll publish a full report on what I learned after the conversations are done. Definitely stay tuned for more!

Subscribe now

PS. I know I still owe you an update on my agentic workflow. I’m working on it. There is a lot to cover.

I developed a pretty bad habit since coding assistants have gotten to be so good. Instead of finding existing tools or open source software and reusing it, I just build whatever I need, from scratch.

Why do I do this? Well, there are a few reasons:

1. I can. I’ve been in the industry long enough that I have a pretty good idea of how to build most types of software and with agents there’s basically no barrier to doing so.

2. It’s useful. Whenever I reach for a tool, it’s because I have a particular problem. When I build my own piece of software to solve that problem, it’s useful. I now can solve this problem. Maybe I can solve adjacent problems and maybe other people have the same problem and will find my software useful.

3. It’s fun. Now what does fun mean? Well if you read the book Theory of Fun, fun = learning and I definitely learn a lot by building things. It’s also just really interesting to see what you can create and how it works.

4. It’s personal. I can make the software exactly how I want it. If I want a particular feature I can add it. If I don’t want a particular feature I don’t need to add it. As I use it, I can evolve it very quickly. Having total control of the software is extremely useful.

Now there are plenty of arguments that even with amazing coding assistants, this is a bad thing to do. Let’s go through a few:

1. Maintenance. Now you have to maintain all this software.

2. Focus. Doesn’t this take away your focus from other things you should be doing?

3. Hubris. Do you really think you can build better software than people who have dedicated years to focusing on particular domain or type of application?

4. Triviality. Does the software matter if it can be built so easily?

Let’s discuss these one by one.

Maintenance

Maintenance is mostly solved with coding agents. It is fairly straightforward, either locally or on a server, to hook up a loop, look for GitHub issues, and for each GitHub issue spawn a sandbox, go address the issue, and merge it. Test suites help keep this process on track and ensure their are no regressions. You could even have your local coding agent build a workflow to do this for you with cron.

Also, this workflow really only matters when you make your software public. If the software is only ever for you, there’s not much difference between maintenance and just evolving it to work better for whatever use case you start it with. It has the same overhead as writing the software in the first place.

Focus

Don’t you have a day job? Don’t you need to spend more of your time focused on your day job?

The thing with coding assistants is that, for side projects and for tools where you don’t really care about reading the code (provided it works for your particular use case and you can write a good test suite or set of evals to understand how well it works), the overall cognitive overhead is extremely low.

Maybe you spend 10 minutes typing up your problem, some high-level solution direction, and an example issue you want to solve. You then let the coding assistant go to town and direct it to work until it can actually solve that particular problem.

You can then give it adjacent problems or even ask it to generate adjacent samples and make sure it works on those as well. Some would call this loop engineering. The agent creates its own focus.

Hubris

What makes me think I can write any software I want and that it will be better than folks who have worked on that type of software for many years?

Well I don’t think my software will be better than theirs. They’re solving a much larger set of problems in that particular domain compared to me.

I do think that I’m much better suited to solve the problem that I have at hand than someone who’s built software to try to solve a much more generic view of that problem (and has to deal with things like the lowest common denominator of that problem).

And then let’s say I’m writing software in a domain I’m actually not an expert in. I would urge you to go back and look at my original reasoning. For this particular piece of software, doing it myself lets me learn that particular domain and makes it fun.

Triviality

There’s an argument that any software you can “vibe code” isn’t actually useful, is trivial, and doesn’t matter. I think that if the software doesn’t actually solve any problems, and you’re not building it for fun, and you’re just doing it to burn electricity, that’s probably the correct view.

But if the software solves a particular problem you have, then it matters. It’s not trivial, at least to you. Triviality is in the eye of the beholder.

If someone else has your same problem and they like your very simple, focused solution, then the software presumably isn’t trivial to them either.

So you see, most of the arguments that might have been completely valid before the era of coding assistants don’t really matter anymore.

I don’t really care if you think that my personal tool is useless. It was fun to build and it solved a problem. I can iterate it in whatever way I want. Over time it’ll become quite interesting. It might become complex in ways that are not really easy to vibe code.

In fact, this is how normal software is written before assistants: you start simple, you solve more problems and more problems and more problems, and you finally get something that is hard to replicate and does important jobs for people.

Limits

Now obviously, there are limits to this mindset. I haven’t vibe-coded my own operating system. When I need a database I use Postgres. I haven’t reinvented every distributed system out there just because I can.

No, there are certain problems in computer science where you really do want the system you adopt to be battle-tested and time-tested: operating systems, databases, distributed systems. These are the sorts of systems where you really do want that collective attention and wisdom, time spent hardening, to be the backbone of what you do.

The beauty of all this is that I could work on one of those things if I wanted to. I’d start simple, solve one narrow problem, and evolve it from there.

Ending Where We Started

If we return to Clapper and compare it against some alternatives out there, you can see where my opinion shows up.

I wanted Clapper to not just be a React to Video tool. I wanted it to be an opinionated DSL that makes video production as declarative as possible. It has many built in components for various animations, as well as a React DSL to fully compose music. My hypothesis is that by having a richer DSL rooted in video production, my agents will be able to more naturally produce really great looking scenes. I still need to prove this, but frankly, it doesn’t matter, because I built this tool for me.

And maybe, you’ll find it useful for you too. That’s the beauty of personal software.

I began experimenting with coding agents in March 2025, around the time Cursor entered the scene and became popular. Despite being in management for the last nine years of my career, I always found time to stay technical. Cursor being built on top of VSCode made it a natural introduction.

So, I began experimenting with Cursor and its $20 plan (and what a generous plan it was back then). A few things stood out to me.

1. The agent tab — you have a conversation about what you want to build in the side panel and the agent does it—was a game changer relative to the autocomplete tools that had come before.

2. The integrated code review — Cursor tied agent authored code to a hunk-based review, making it straightforward to validate the agent’s output and accept or reject it via a local code review workflow.

I got into a groove with Cursor and really start to build. But I soon found myself opening multiple Agent tabs in one workspace to parallelize work. This is where the interface inside the IDE began to be troublesome: all of this concurrent work happened on a single checkout.

The arrival of Claude Code became a much more natural experience for me. I grew up programming in the terminal—first with Emacs and later Vim/Neovim—so having a TUI that could sit next to all my other terminal apps felt natural. It also made it easier to scale up code production: I could just cd into a new directory and launch a new Claude instance there. Of course, this was always possible with Cursor, but it didn’t feel as natural.

I began running multiple Claude Code instances and doing work in parallel. My screen filled with terminals overlapping terminals. I switched to using Mac’s built-in virtual desktop feature. I moved different threads of work to different screens, but the keyboard navigation sucked, so I needed another solution. Around this time, I experimented with programmable, split, columnar keyboards. I don’t remember exactly why—I think I needed a new hobby or something. I bought a ZSA Moonlander (I later changed to the ZSA Voyager, which remains my favorite keyboard) and started messing with custom keybindings and macros for Neovim. I then discovered the beautiful world of home-row mods.

There must be a better way to manage all these damn windows!

I used window managers in the past, but it had been a while, so I started researching modern options for the Mac and discovered AeroSpace and the broader world of i3-style tiling window managers. This was the system I was looking for. I could customize keybindings and map different workspaces to different keys using mnemonics. Chrome would go to workspace c; all my coding workspaces would go to 1 through 9. My home-row mods made managing all of this very easy. I could now switch context and jump between different threads of work with ease, never taking my hands off the keyboard.

AeroSpace’s workspace flyout, followed by Alt+number shortcuts between terminal windows. The flyout is enlarged and slowed to half spee; the window switching is real time.

As I scaled code production, I experimented with different ways to keep up with the agent and check its work. I really fell in love with Cursor’s hunk-based local code review, so this was the system I leaned into optimizing as I scaled up concurrent agents.

With Claude Code moving the agent to the terminal, I built out my Neovim config, planning to use it to replace Cursor’s built-in code review. I found Neogit to be the best fit for a review plugin and added some custom keybindings for reviewing and staging hunks in the editor. For a long time, my workflow was to have the agent write the code, review the hunks in Neogit, stage the ones I accepted, and then iterate with the agent on the ones that remained.

This worked well for getting quality code out of the agent with quick reviews, but of course, it didn’t scale as the number of agents increased. It became more difficult to contextualize the hunks or deal with changesets that were 1,000s of lines long. To help with this, I created a TUI review system called Filament (open sourcing soon), which implemented a much more opinionated form of review. Filament uses Treesitter to understand the semantic layout of your code, then overlays the diff hunks on top of the AST produced by Treesitter. You iterate through the hunks in a top-down, caller-to-callee fashion, using keyboard shortcuts to move through and annotate your code. It produces a review document you feed back to the agent for another iteration.

Navigating a real changeset in Filament. The overlay shows the keys I’m pressing.

Going All-In on AI

After Claude Code came out, time became blurry. I became addicted to this new way of building—likely my own version of AI psychosis—but I also realized that it was going to change everything about the industry. I needed to frontrun these changes. I transitioned roles at work, moving from an org lead back to an IC. Then, I decided to leave and cofound ArchAstro. I felt that the only way to really learn how to use these tools effectively, and to modernize myself, was to go all in. So I did.

With this system, and with the imperative to build fast and big with a lean startup team, I ramped up the number of agents and sessions. At some point, I added coding workspaces q, then w, then e. I used workspace m for main. For projects unrelated to my primary work, I used other bindings like p for projects. On each workspace, I ran two or three terminal instances: one for my agent, another for Neovim, and a third for general command-line work.

I worked this way for a while, and my productivity rose. But soon, I found myself needing more than 12 agents, and that’s when I got into trouble. I spent my time scanning through all the workspaces, looking to see what was blocked on me. I started forgetting what was on worktree 1 or 2 or 3.

Vibing on Mobile

As an aside, on the way to building the workflow above, I experimented with mobile. I found videos online of people using an app called Termius with tmux to code with Claude on the go. Of course, to feed my addiction, I needed to try this. So I set up Tailscale, Mosh, tmux, and Termius and started to vibe from my phone. But for whatever reason, Termius sucked at scrolling with tmux, and it became a pain in the ass to use. Don’t get me wrong: I was still able to get a lot done, but it wasn’t a good experience.

The Past 3 Months

That brings us to the summer of 2026. I started seeing all these posts about a new tmux-like system called Herdr. I was a bit reluctant to check it out at first. For me, inertia tends to be high when it comes to building workflows and the muscle memory around them. Herdr clearly solved some important problems I was experiencing, so I checked it out.

The most important thing for me was the keyboard bindings. I used Codex to customize them to work similarly to my AeroSpace bindings without colliding. I mapped workspace switching to the same 0 through 9 system, using Ctrl and Alt bound to holds on g and h. I created shortcuts for creating tabs, switching agents, and so on. It took me a couple of weeks to get as fast with Herdr as I had been with AeroSpace, but I got there.

Switching between Herdr workspaces and agents, with my keyboard commands shown above.

The bigger unlock was discovering Moshi as a new mobile PTY app and witnessing how well it worked with Herdr. It solved all the usability issues with tmux and Termius. I could now run just as fast from my phone as I could from my computer. My productivity soared.

Switching between Herdr workspaces from my phone in Moshi.

Once again, I my code review workflow evolved, especially for mobile. I began using GitHub Mobile much more for code review. I would comment on PRs, then jump back into Moshi to tell my agents to fix the comments. I created skills to help them monitor for changes. With the more capable models, I found myself spending much less time in Filament and Neogit. I ended up using GitHub much more because I could skip over inconsequential generated code and focus on the pieces that mattered most. GitHub’s file list was key for this.

Opening a PR in GitHub Mobile, then asking the agent in Moshi what is blocking the merge.

My productivity increased once again, but my problems weren’t solved. I found myself struggling even more to keep track of everything. The agents were inconsistent about babysitting PR feedback, merge conflicts, and CI. I would look at a GitHub review and have no idea which worktree or agent was dealing with it. I was back to chaos.

So I started building more tools to solve those problems and arrived at the workflow I use today.

More on this next week!

This is my new Substack newsletter where I’ll share thoughts, opinions, feelings, vibes, rage bait, clickbait, engagement bait, fish bait, and maybe no bait at all about the evolution of software, engineering management, and what it means to work in this world that is been dramatically changing everyday due to A.I.

So what is a building machine or rather what is THE building machine?

• Is it me?

• Is it this newsletter?

• What is the building machine building?

• Is it a fun riff on software factories, Loop Engineering, Graph Engineering, Hyper Graph Engineering, and Petri Nets that you see all over X? Well maybe not the last two but they’re coming.

• Is it a rebrand of coding machine?

• Is it one of those cool fucking robots that sit on the top of skyscrapers and builds more of the skyscraper?

• Is it a new machine we’ve never seen before that builds the robots that sit on top of the skyscrapers and build more skyscrapers?

I don’t actually know the answer to this question so I started this newsletter to find out. What does the concept of a building machine mean when AI is basically disrupting the entire software industry?

At the end of 2025, I left my big tech job running the Billing team at Stripe to start an AI-pilled, AI-first, super lean company. This was right around the time that Opus 4.5 dropped, a pivotal moment where everything around coding changed.

For me, the journey started before “the singularity.” As early as May of 2025, I began playing with Cursor and Claude Code. It became clear to me that the future of building software and running eng teams would change. Every month I spent in my current role, where all my time was spent in meetings, doing one-on-ones and supporting the team, was costing valuable time to learn and front-run the massive industrial change coming.

I only know a few people who made similar career choices around that time. They either left their big, org-lead roles to go back to ICs, forcing themselves to learn. Or they left their big tech jobs to become a solo builder or start a company. If you look on X, you probably feel the opposite, that everybody’s doing this, but it’s certainly not true. Even for folks who feel early or seem early, if you actually talk to them they say they’re behind. Certainly that’s how I feel.

It’s been 9 months since I left Stripe; I now spend nearly all of my time building. I have never built so much software and product in my entire life. To that end, I definitely feel like a Building Machine. At the same time, I don’t feel like a high functioning one. Steam comes out of my ears too often. My gears grind and efficiency drops after 5PM. Maintaining focus and context is harder than it’s ever been, and software is but a tiny part of what Building is in the most abstract sense. The rest of my team has their own challenges, and there are not a good set of interchangeable parts to really optimize the whole fleet.

I am still learning how to build The Building Machine, whatever it might turn out to be. And that is what makes this new world so much fun - there is so much to learn and do. I intend to use this newsletter to explore and share what I’m learning. I hope to learn from all of you as well, get feedback and compare notes. Ultimate, democratized AI should let all of us find our own Building Machines. So let’s build!