I built a markdown editor with about an hour of my own time. It's heavily inspired by iaWriter with my own preferences baked in. It's called Stet, it's open source (free!), and I'm writing this post in it. Claude is in here too: it wrote this draft into an open tab through Stet's agent interface.

I wrote this post to share two building techniques:

1. Shotgun prompting. I didn't engineer prompts. I fired off what I wanted, fast and loose, in whatever words came out, and kept firing until I was satisfied. You could also call this dumb prompting.

2. A mechanism that lets the agent drive. Stet has an interface that lets an agent read, edit, operate and screenshot the editor. That's what let Claude check its own work, and what lets it write alongside me now.

Here's every prompt I typed, in order, with timing:

Every prompt that built Stet, in order, on a clock of my hands-on time: 72 short, typo-ridden messages adding up to about 56 minutes.

What it is

Stet is the proofreader's mark for "let it stand". You write it next to a correction you want ignored, and put dots under the original words. It felt right for an editor built around reviewing suggestions.

1. It's fast. The core is Rust and the text is drawn on the GPU. A keystroke reaches a finished frame in 0.07 ms on a small note and 0.6 ms on a one-megabyte document with 1,800 suggestions in it.

2. It shows your source. Markdown keeps its markers, dimmed so the words come first. There's no preview pane.

3. It has real vim. Registers, macros, block visual, :s.

4. Review is built in. Suggestions are CriticMarkup in the text, so they survive git, email and every other tool.

5. It has a margin. Every document gets a scratch pane for research notes, and a note can be pinned beside the paragraph it's about.

6. Agents work beside you. More on this below.

1. Shotgun prompting

Here is the first prompt for making Stet:

I want a beautiful/minimal/x-platform markdown writer similar to ia writer just with the core written in rust, any platform os stuff abstracted away (should run windowed), support for vim key bindings, images, etc. all markdown features. also support for suggestion mode (see the archdev task epic for this on firstlanding). should also be themable (see themes on archdev). needs to be fast as hell and reliable.

After that I didn't write specs. I just kept asking:

1. "make it faster"

2. "yes, do it"

3. "give it a better fucking name and branding"

4. "you can't manipulate things with your ctl skill?"

5. "make sure you can test this shit"

6. "jdone"

7. "try again"

8. "make it public and lock it down"

"make it faster" took a one-megabyte document from 5.1 ms per keystroke to 0.6 ms. "jdone" was me trying to type "done" after pasting the wrong Substack cookie. "try again" produced a live Substack draft.

By the numbers:

|                                                                             |                        |
| --------------------------------------------------------------------------- | ---------------------- |
| Prompts                                                                     | 72                     |
| My hands-on time                                                            | about 56 minutes       |
| Claude's working time                                                       | about 4 hours          |
| Median prompt                                                               | about 56 characters    |
| Words I typed, in total                                                     | 1,083                  |
| Lines of Rust                                                               | 27,241                 |
| Tests                                                                       | 170                    |
| My time to v0.2.0 (Mac app, DMG, CI on three OSes, the rebrand, the margin) | 22 minutes, 29 prompts |
| Times I typed "commit and push"                                             | 7                      |
|                                                                             |                        |

Shotgun prompting means I spend shots; thought is all implicit or the “thinking fast” kind. There's no role-play, no XML, no rubric, no fancy skills, and no 2,000-word plan. Each prompt is the next thing I want or the next thing that's wrong, typed the way I'd say it to an engineer sitting next to me (well maybe with less cursing). If the result is off, I say so and go again. Working this way on these types of tools lets me multi-task and focus my real attention on other work that matters.

2. Building the system that lets the agent drive

The reason I built Stet at all was one prompt, eight minutes in:

i need to basically have a skill that lets my agents communciate and manipulate the markdown file without fucking up my flow

Every editor I tried broke when an agent touched the document. Or even worse, the agent could never touch the document. Some editing tools build in their own agents and those agents often suck. I very much believe that the future of software is designing it to be used by agents more so than humans. I even tried using vim with an agent just editing the markdown file on disk. Even if I did get an editor to work with my agent of choice, the experience wasn't good: text jumps around and I have no idea what the agent changed.

So Stet has stet ctl, a small command-line interface to the running window:

stet ctl read                                   # the live, unsaved text
stet ctl suggest --old "teh" --new "the"        # a suggestion I accept or reject
stet ctl edit --margin --at end --text "..."    # research notes into the margin
stet ctl wait --name Claude                     # take requests I send from inside the editor

None of it moves my cursor, changes my mode or steals focus. Suggestions show up inline, and I accept them or let the original stand:

That was the plan, but it required a few more shotgun blasts to get right. The best part came from two annoyed questions, 17 minutes in:

1. "why can't you see stuff?" Claude couldn't drive my desktop. It had no Accessibility permission, and the screen was locked.

2. "you can't manipulate things with your ctl skill?" By my next prompt, stet ctl had grown keys, type, click and shot.

stet ctl keys "<D-/>"          # press keys, in vim notation
stet ctl click 320 200         # click in the window
stet ctl shot /tmp/stet.png    # see exactly what the window shows

From then on, Claude (or choose your own agent) could open a menu, click a table, take a screenshot and look at it. The app tests itself through its own agent interface. That's what makes shotgun prompting work: a miss stays cheap when the agent checks where it landed. When I said "make sure you can test this shit", Claude didn't hand me a checklist. It drove the real window, checked the result and fixed what it saw. I didn't have to spend time checking the work.

It's paid off for writing as much as building:

1. This post. Claude read my earlier posts for voice, wrote the draft into an open tab with stet ctl edit, and pinned its sources in the margin beside the paragraphs they support. I only had to edit.

2. My last essay. Claude found the video, my tweets and the framework images and put them in while I kept writing.

3. Requests from inside the editor. I select a sentence, press a shortcut, type "tighter", and a suggestion comes back.

An agent editing your document is only useful if it keeps its hands off your cursor, and an agent building your software is only useful if it can see what it built. stet ctl does both.

A few more things it does

One menu for everything. ⌘/ lists every command with its shortcut, the markdown you can insert and the vim keys.

Retouch pictures in place. Crop, draw arrows, boxes and text, or redact. Agents get the same tools through stet ctl annotate.

Tables as a grid. Pipes become rules and the columns line up, but every character is still the source.

Publish to Substack. :publish makes a draft with your pictures uploaded. Substack has no public API, so a subagent worked out the one behind its editor.

Code in about 200 languages, in fifteen themes. This is stet-ink, the dark house theme.

The video was shotgunned too

The film at the top was made with Clapper, our open-source framework for making videos in React. The score is code as well: sampled upright piano, bass and drums, written as notes in TypeScript.

1. "use clapper to animate the prompting to get to stet"

2. "make sure the music / sound is not fucking stupid"

3. "get rid of the commit part of the video - show all the prompts"

4. "update the video to reflect wall time"

Back to personal software

A month ago I wrote Personal Software: My New Bad Habit: instead of adopting tools, I build exactly the one I need. Stet is the clearest example of that habit so far.

1. I can. It took an hour of my time.

2. It's useful. I write in it every day, and so do my agents.

3. It's fun. I got to poke at GPU text rendering, vim's stranger corners and what Substack's editor actually sends over the wire.

4. It's personal. Nobody else asked for a Substack button. There's a fish command, blog, that opens a new post in Stet because that's how I start writing.

The objections from that post hold up too. On maintenance: today's v0.3.0 release failed its own checks on six new security advisories in the TLS libraries. Claude patched them, re-ran the checks and shipped, and all I typed was "and do the latest release". On triviality: an hour of my time bought 27,000 lines of Rust, 170 tests, CI on three operating systems and signed build provenance. That isn't trivial to me.

Personal software used to be limited by how much time you had. With shotgun prompting, the limit is how fast you can say what you want and whether the agent can see when it's wrong. The first part is up to you. For the second part, build the agent a way in.

Try it

curl -fsSL https://raw.githubusercontent.com/ArchAstro/stet/main/install.sh | sh

1. Source: github.com/ArchAstro/stet, MIT

2. Downloads: v0.3.0 for macOS, Linux and Windows

3. The agent skill: the installer adds a skill so Claude can use stet ctl for you

4. The video framework: github.com/ArchAstro/clapper

If you find a bug, open an issue. My agents will probably fix it.

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!