Arguably 3x productive: anecdata on LLMs for personal projects

If you have been following me on BlueSky or have read my recent posts here you will be aware I am a happy LLM user for coding projects.

To give you a concrete example, last Friday I found some issues during the morning (while at work) with my custom Chrome extensions, and I wanted a new feature to my custom Obsidian search plugin. I sent myself a Whatsapp message with what the problem/feature was and kept working. I would tackle these after work, leisurely. Here’s the non-me readable version to give you context:

1. bestBefore: looks like the default duration is not correctly stored in extension storage, but human-set durations are (important for restarts)
2. nt: disable rendering iframes while dragging (iframe lagging is choppy if it’s kept rendered)
3. obsidian-clau-plugin: add partial text match on titles too

Here is the description of each project, so you know what the problems or features are about.

1. bestBefore is a Chrome extension that lets you add expiry dates to tabs (and assigns a default one, too). The goal is to keep the number of open tabs under control.
2. nt is my “new tab” extension, highly customizable. Some of the “extras” include being able to embed custom iframes and dragging them around.
3. obsidian-clau-plugin is a custom search plugin to replace the default QuickSwitcher. It uses (mostly) MiniSearch for search purposes. MiniSearch does not handle partial text well, since it generates inverted indexes. But searching by a part of a word in titles is required for me since I keep “people notes” with names without spaces, as @firstnamelastname. Hard to find by lastname otherwise!

All of these are “easy” to fix. If I was the one doing them, they’d boil down to:

1. Check when data is persisted to Chrome’s extension storage, and make sure it is done when assigning default durations. This might take longer than just a quick check if it turns out there is a bug somewhere in the area.
2. Hide the iframe when drag starts, and recover it at drag end, placing a nice-looking image placeholder. I did something similar with Pinta, for images.
3. The plugin is in Typescript, a language I can just “get by” with effort. I know what all the code does, but the code itself has been written by Gemini, and as such this is likely the hardest. On the pure code side, it implies creating a new search provider and mixing search results across providers. The provider itself is trivial, but being Typescript and needing a mixer for providers increases the complexity.

Before LLMs, tackling just one of these would have been a productive evening’s worth of personal work. This estimate comes from past experience with similar projects and my usual level of after-work energy. The search provider for clau would have needed to wait until a weekend to have a bit more time for experimenting and failing.

But on Friday, with the help of Gemini, I got the three done after work and I started to sketch how I wanted a “portfolio” of recent things I have done to look (it’s here, I finished it over the weekend).

We could argue that this is 3x productivity. Of course productivity “during free time” makes little sense, does it…?

In a way, yes, it makes little sense. On the other hand, opening up this mental (and time) space frees you up to do other things. Just compare these two scenarios

Imaginary scenario:

Friday:

• Fix nt issue (easiest of the lot).
• Think about having a portfolio-like page.

Saturday:

• Before the hike: take a look at the bestBefore codebase while I cooked hike-lunch
• 20 km hike
• After the hike:
  • Fix bestBefore issue in the afternoon.
  • Think about that portfolio again.

Sunday:

• Too hot to go out.
• Get the search provider working.
• Shit, didn’t move forward with the portfolio. Next week for sure.

Monday:

• Start work on the portfolio, it will likely take the whole week on and off until completion.

Output:

• nt fixed
• bestBefore fixed
• clau:
  • Full text in title provider
• portfolio just started

Real scenario

Friday:

• Fix the 3 issues.
• Start work on the portfolio, and get a basic page layout and editing workflow I liked.
• Ask Gemini (app) about a potential design for a semantic search approach in the abstract (i.e. as a new Obsidian plugin, not an addition to the existing one).

Saturday:

• Before the hike: tell Gemini CLI to give a shot to the design. Cook hike lunch while it is on it. In the end, that approach didn’t work.
• 20km hike
• After the hike:
  • Explore another 2 options. The latter (my idea) worked. Polish it a bit.
  • In parallel, add a nice filter to the portfolio (taken from Salta). It will be reusable in other projects.

Sunday:

• Integrate semantic search into clau, release.
• Finish portfolio.
• Decided to try adding a UMAP visualization given the document embeddings. It worked, so released that.
• Think about my current workflow and imagine of yet another Obsidian plugin that can make it more efficient.

Monday:

• Write and release the Obsidian plugin I thought about yesterday

Output:

• nt fixed
• bestBefore fixed
• clau:
  • Full text in title provider
  • Semantic search using GloVe
  • UMAP plot for the embeddings
• portfolio complete
• new plugin created

Conclusion

In the end, it is not just the speed. Being able to make some things faster gives you the ability to think of other things you can do. In your personal projects you are wearing 3 hats:

• The customer hat,
• The project manager hat, and
• The developer hat.

By speeding up the cycle time for the developer, you open up time your project manager and customer hats to think of new ideas, projects or features. And then you can put on your hiking hat and go for a walk in the mountains.

• Programming
• Writing