Avi:)

Vibe-coding a feature request

I’ve been moving my photo galleries to Ente with a view to having everything in one place and picking out what I want to make public.

Previously, photos from my phone were in Google Photos immediately and those I took with a camera would probably end up there as part of a wifi or bluetooth sync, but more-properly would go to a disk on my PC, be organised in Shotwell and then selectively uploaded to Piwigo.

I noticed earlier this year that it’s been three years since I’ve got around to doing the organise-and-publish step, so thought I should find a smoother process for that.

Now, I assume everything will go through my phone or tablet, and that which doesn’t just gets uploaded to Ente anyway.

Only part way through did I realise that while Ente has the notion of a public gallery, it doesn’t have a public index of them, so can’t replace Piwigo.

My instinct was to open a feature-request - Ente are active on GitHub - but instead I turned to a mixture of Claude and OpenCode to build it; I could find out what I actually wanted along the way, while also finding out just how good these tools are at writing code.

The result is ente-public-galleries: a pile of Go, written in a few hours of human-time over three days. I haven’t read any of it but it is now what’s providing pics.avi.st.

Building rather than describing

I’ve been around Product Teams for a while, and generally around products that are software for longer; I’m very used to the idea that if you want something built you can build it yourself to demonstrate the possibility.

Usually this is a bit tricky - I don’t have tens of hours to spend understanding a codebase and writing the code, and what we normally do is mock the changes up - a graphic of what I want the thing to look like, with explainers of what happens when you interact just so.

Here, though, Claude does have the resource and ability to do that, and Ente is Open Source so even if there’s no publicly documented API for a thing it can perhaps figure it out.

I gave Claude a really rough spec: a static page of cards, one per public album, built from cron, hosted on my own domain. I then realised that it’d be nice also to have a way to make albums public or private in bulk so added that to the spec.

Then I just sort-of gently directed Claude and OpenCode for the rest - it copy-pasted the crypto code from the CLI rather than reinventing it, figured out what else was necessary to get the images displayed and really the output of the second prompt was an entirely usable site, with a claude-produced list of possible refinements.

Changing my mind

This was the cool bit, and the bit that’s really different to working with humans. Each time I wanted to try a different thing I didn’t mind just pinging another vague sentence describing my ask.

For a human I’ll always tend to ‘yeah, this’ll do’ rather than wasting someone’s time with my half-baked ideas.

  • The cards linked straight to Ente but I felt the UI change was too jarring, so now each card opens a page that embeds the album.
  • It needed search, and grouping by year so I could find specific events quickly.
  • Many of my albums are of trips somewhere, and so each album got a little route-map thumbnail, then a bigger map on the album page.
  • I like to find photos by location more-often than by date - I wanted clicking a point on the map to show that photo. That worked, but it made the output directory enormous, so I asked for the map back as a plain picture.
  • A build stalled, so I asked it to find the loop. When the containerised version rendered tiny, I asked it why.

None of that needed me to read, let alone understand the code.

As an experiment I decided to not use a text editor at all, do everything via prompts and actually I think this is far more complete than I’d have bothered with myself for a proof-of-concept! I was much more likely to try out a thought that only might-be-good than I am when there’s real effort of mine required!

Building rather than writing

If I’d fleshed out my initial ideas into a feature request, it would have been a poor feature. Now, I know any product team wouldn’t have just built to my request, but a good ticket is a thorough one and this adds to the thoroughness.

Also, I don’t expect that this feature gap exists because nobody at Ente knows how to build it; what I expect is missing is the awareness of the want for this as a feature. I think a better way to demonstrate that is with the optimism of “how about we have this” than the more negative list of missing bits.

The catch

The README opens with “Heavily vibe-coded and a work-in-progress!” and I mean it. I know what it does but not in any depth; I don’t even know all that it does.

That’s fine for a prototype that’s static pages on the Internet and a login session to my own photo account on my PC, but there’s whole swathes of use-cases where this isn’t appropriate.

The other big catch is that now I’ve built this and am slowly iterating on it, I’m really not sure when it’ll be “finished” enough that I’m ready to open the feature request! This repo is now a month old; I’ll have to come back and edit this post when I’ve raised it.