To see how it’d go, I used Claude Code to see if I could make a Lightroom Classic plugin to auto-tag photos with visible jersey numbers using the Google Gemini API. Adobe uses Lua as a scripting language. It did end up working but it took quite a while and, in general, I feel mostly unnecessary. I just handed off the error message between Lightroom and Claude Code. It was more an exercise in patience than anything else. I assume that portion would be pretty easy to automate in the future.
I found the Lightroom1 documentation to be pretty bad. I also did not anticipate programming in Lua regularly. That made it a pretty good candidate for this experiment.
I should have timed how long it took to make this but I didn’t. It took a while. There was a weird chunk where I couldn’t get it to decode the JSON response correctly. I ended up having to put in lots of sequential display and error logging to pinpoint things. It’d have been good practice for regular programming but it became essential here. I left it in there.
The plugin works. You can get it on GitHub and add your own Google API key here. You just download the files and rename the folder to .lrplugin. It has an initial prompt to limit/describe which jerseys should get entered. You can see it action below. It’s fine for a photo or two but, in the end, is slow enough to be irritating to me when used with 20 or more photos. I’m considering doing this with Flickr’s API instead and batching the photos to keep me below whatever limit there is for Google’s API. I also want to explore doing it with a local AI model and avoid all the limits entirely. I think I’ll also add some sort of prefix to the numbers to allow me to deal with different teams and years.
Did I vibe-learn2 some stuff doing this? Maybe. Sort of. I probably learned some ways I could have done vibe-coding better in the future. I wonder what would have happened if I gave it the existing Adobe Lightroom example code first. Claude definitely tried to do things Lightroom couldn’t do. I should request more aggressive and sequential logging initially. It was useful to have something that worked to help me figure out what I’d really need/want.
While I got this working, I didn’t feel much satisfaction. I didn’t feel like a useful part of the process. I usually feel a sense of satisfaction when I get something working. Not so much this time. That being said, wanting to feel useful is not always my goal. Often I just want to solve a problem and move on with the looming wall of stuff I need to get done. So you’ve got a mix of people who can program who will use this do deal with the scale of work that needs to get done or work that’s outside their main areas of expertise/interest.3 You’ve also got a world of people who can’t program and this can give them options that are pretty interesting to get tools and workflows worked out that would have been impossible before. It doesn’t necessarily get them anywhere in terms of learning programming. That could matter but there are undoubtedly many people who won’t care. The goal is solving the immediate problem not learning something.
That’s not really any different that using AI for writing or summarizing something or research or data analysis or whatever. There’s just so much work that is required by school or jobs that people either don’t want to do or don’t have the time to do. That’s the place where AI is definitely going to be used extensively. That’s why it’s so attractive to students and people filling out TPS reports. There’s some sort of Ouroboros thing here with capitalism creating bs jobs and then tools to do them to replace the people . . . and then to need more bs jobs of some other sort, maybe training AI models. So many people would probably be happy with a small house in the woods and we could dispense with most of this nonsense.