Wrapping up Our Radical Speed Month

I pre­vi­ously posted about our launch of Harper Desktop. If you have not read that al­ready, I sug­gest you take a peek be­fore read­ing for­ward here.

For those caught un­aware, Harper is a gram­mar checker de­signed to re­spect the fact that your writ­ing should be yours. It is pri­vate by de­sign, no mat­ter where you de­cide to use it. Thou­sands of peo­ple from all walks of life use it to ex­press their thoughts on­line, skip­ping all the fea­tures found in other gram­mar check­ers that sup­press cre­ativ­ity and sell text to the high­est bid­der.

Until re­cently, our most pop­u­lar and ver­sa­tile in­te­gra­tion was through a Chrome or Firefox ex­ten­sion. It plugged di­rectly into your browser and in­ter­acted with the var­i­ous text ed­i­tors you might en­counter while brows­ing the web.

While this gave Harper the abil­ity to en­hance the writ­ing of peo­ple who spent much of their time on­line, it did not do much for the mak­ers and do­ers that use desk­top ap­pli­ca­tions like Scrivener, Slack, or Discord. Harper Desktop sought to solve that.

It was build in only a month, with the com­bined ef­fort of just two en­gi­neers, my­self, and Jason Adams. It was pos­si­ble though ded­i­ca­tion, hard work, and a will­ing­ness to learn. Radical Speed Month held an im­pe­tus to ex­per­i­ment, and ex­per­i­ment we did.

In this post, I want to talk about:

1. The ex­per­i­ments Jason and I ran on our­selves.
2. Which we will keep, and which we will not.
3. Sandwiches.

I will not be talk­ing about:

• Why Harper Desktop is awe­some.
• Why you should down­load and in­stall it.
• Pizza.

The Experiments

“AI”

AI is a tool, one which I have writ­ten about ex­ten­sively. Dis­cus­sion of AI is repet­i­tive and hon­estly pretty bor­ing. Which is why my “AI” ex­per­i­ment was not re­ally about AI or LLMs. It was about the kinds of tools I use.

For an ex­ceed­ingly long time, my work­flow has con­sisted of tmux, nvim, and the Rust com­piler. In the last year, that work­flow has grown to in­clude OpenAI’s Codex. I found my­self more pro­duc­tive with it be­cause I could del­e­gate oth­er­wise la­bor-in­tense tasks to it to be com­pleted in the back­ground while I worked on some­thing else.

Even with codex avail­able in my $PATH, I would still write most mis­sion-crit­i­cal code my­self. Part of this was from fear, but there were other more im­por­tant rea­sons too.

I wanted to see what would hap­pen if I com­pletely changed my work­flow, just for one month. I would com­mit my­self to spend­ing as much time with new tools as pos­si­ble. As it would turn out, the only tool I stopped us­ing was Codex.

This is some­thing I spoke about briefly be­fore, but I have de­vel­oped a more com­pre­hen­sive view of the is­sue since, so I’d like to go over it again.

What I Used Instead

Instead of del­e­gat­ing tasks to Codex, I started del­e­gat­ing tasks to OpenCode. I found it far more ef­fec­tive.

To me, OpenCode’s stand­out fea­ture was how cen­tral it made “plan mode”, which gave it per­mis­sion to view (but not edit) my repos­i­tory while I cre­ated a plan. It could com­pare its un­der­stand­ing of my plan with the re­al­ity of the ex­ist­ing code, and ask clar­i­fy­ing ques­tions when am­bi­gu­ity arose. This stood in sharp con­trast to Claude Code and Codex, which would just go and start edit­ing files, re­gard­less of whether a plan was com­plete.

I liked this, but it still left some things to be de­sired.

OpenCode gave me byte-level con­trol over the code it wrote be­fore it started edit­ing, but it did not give me a whole lot of con­trol over OpenCode it­self. I found my­self typ­ing the same things over and over again, wish­ing for some kind of higher level macro sys­tem.

That’s when I found Pi, an “agent” that in­ten­tion­ally does as lit­tle as pos­si­ble. In a lot of ways, it’s like neovim. It does very lit­tle out of the box, but through cus­tomiza­tion it can be­come more use­ful than any­thing else.

Now, I find my­self us­ing Pi more of­ten, not least be­cause it gives me every piece of con­trol I al­ways wish I had. Pi is the only LLM-based tool I have every tried that did not feel like it was ac­tively slow­ing me down.

So in that way, I sup­posed the “AI” ex­per­i­ment was a suc­cess. I will be con­tin­u­ing to use Pi.

Meetups

Jason and I de­cided to work to­gether for Radical Speed Month in part be­cause we lived in “close” prox­im­ity.

You see, Jason and I both work at Automattic, which is a dis­trib­uted com­pany. That means that al­most every­one works re­motely. There are a num­ber of ben­e­fits to em­pha­siz­ing asyn­chro­nous com­mu­ni­ca­tion, and some down­sides. We wanted to get a bet­ter un­der­stand­ing of both the pros and cons by tem­porar­ily in­creas­ing the num­ber of days we spent in-per­son work­ing to­gether.

So, twice a week, we would hop in our cars and meet some­where, usu­ally Castle Rock, CO. We would spend the day talk­ing about big ideas, work­ing on our in­di­vid­ual tasks, and con­sume a likely un­healthy num­ber of sand­wiches.

I per­son­ally found these in-per­son days mo­ti­vat­ing. I would come home at the end of the day ex­cited to get back to work. I felt like I had a re­newed sense of pur­pose and drive. It was in­tox­i­cat­ing.

I think a huge part of this feel­ing was a con­se­quence from Jason’s per­son­al­ity. We seem to mesh to­gether well, and I have no­ticed that he has a ten­dency to am­plify the best qual­i­ties in the peo­ple he leads.

That said, I do not think that 100% in-of­fice work is sus­tain­able in the long term. I found that the days we were to­gether, I was not quite as able to “lock in”. We had fan­tas­tic dis­cus­sions and our de­ci­sion mak­ing process was a mil­lion times faster than it would have been oth­er­wise, but it was just that lit­tle harder to turn the talk into ac­tion. Sim­i­larly, I found it more dif­fi­cult to con­vey cer­tain kinds of tech­ni­cal in­for­ma­tion. When we needed to ex­plain some­thing in depth, I felt the com­pul­sion (which could be fought, I sup­pose) to send a link later, rather than try to ex­plain it in the mo­ment.

In the end, I think that Matt’s orig­i­nal con­clu­sion on mee­tups is still cor­rect. He says that in the same way that “a lit­tle salt makes the dish”, a few mee­tups every so of­ten can bring to­gether the best parts of both in-per­son and re­mote work.

So, I would say that our sec­ond ex­per­i­ment was also a suc­cess. I per­son­ally feel as though I have earned a bet­ter in­tu­ition for what kinds of work are bet­ter in per­son and what are bet­ter async.

The Fallout

Immediately af­ter an­nounc­ing Harper Desktop, I got a flood of mes­sages from peo­ple who had down­loaded it, in­stalled it, and found all the bugs in it. That was both good news and bad news.

It was good be­cause we could be con­fi­dent that we were in­deed build­ing the right thing. Peo­ple want a desk­top ver­sion of Harper and they want to help us make it as awe­some as it can be.

The was bad be­cause, well, there were a ton of bugs. Over the last few days, I have been bak­ing them out of the soft­ware as fast as pos­si­ble. You should be get­ting a sig­nif­i­cantly im­proved piece of soft­ware in the com­ing hours.

Would I have post­poned the launch, had I knew about these is­sues? Yes. But I did not, which is why we do soft­ware launches like this. There’s no way to fully ex­pect every is­sue that comes up, so you need to do a lit­tle ad-hoc user test­ing. I con­sider this a suc­cess.

Conclusion

I re­ally en­joyed Radical Speed Month. It was a hard stretch of learn­ing a lot about a va­ri­ety of sub­jects, most of which I have not even men­tioned in this post. I am en­er­gized and ex­cited to ap­ply them to my daily work, and in hard­en­ing Harper Desktop.