Link: Build yourself flowers via Vicki Boykis

To explore art in the Rijksmuseum, Vicki Boykis built Rijksearch a semantic search engine of the Rijksmuseum’s public data with the assistance of AI. She’s built versions of a semantic search engine before but implemented Rijksearch differently and tracked the steps where AI helped.

For Rijksearch data, I used multimodal text and image data because I was interested in creating text and image embeddings. This made processing the data trickier because I needed to associate a given set of text metadata to a link of an image, as well as process the images in an efficient way so they’d download quickly and non-disruptively. For the actual embedding inference, I changed from a hosted model to an API, which was easier in some ways, but now required cost and latency considerations. Additionally, test and image processing together was trickier because you have to think about text and image aggregation together. For indexing, I switched to vector sets, though since vector sets don’t require the construction of a search index and are a native structure. This makes it easier in that you don’t need to update fields, but vector sets also don’t support metadata updates in the same way that search indices do because vector sets are schema-free (though you can add JSON through VSETATTR ), so there is a tradeoff. For serving, I changed from Flask to Go, which was a pretty big change because I had to relearn web development in a new language. Go has a lot of tooling for web development out of the box, as well as support for concurrency, and for processing web data. This was probably the innovation token that took me the longest time to overcome.

I used AI to build the front end, which turned out nice. It wasn’t anything out of the ordinary, and I am not sure how solid the actual code is, and whether it’s production-ready, but it was nice to get going since I’m not a front-end person at all and we always want to get to a good demo. Last time, I used a bootstrap template for this that I tweaked slightly, which I guess is not that much different. LLMs also helped me with Go, but they didn’t help me by writing all of the code. How I’ve been learning Go is step by step: first, by reading dead tree books, then by trying out Go by Example, and finally, by asking about different Go concepts from the LLMs, or working with a very small, method-level snippet at a time. LLMs also helped with data formatting and exploration. So writing all of the matplotlib methods, the pandas methods, all that stuff where you need to constantly look stuff up or you need to get data from the API. A lot of that glue stuff, the models, any of them really, are good with.

So where did it not help? Largely with architecture changes and decisions. Understanding that I needed a two-tower model, what two-tower models were, how they’d been used previously in search and recommendations, understanding my latency constraints, knowing that serving this app has to be fast and that the indexing job’s speed didn’t matter as much: all of that came from my head and past experience rather than AI. Picking vector sets as a storage and retrieval primitive was similar. I only learned they existed because I pay close attention to what’s happening in the vector space. (haha) You could probably build a bot to synthesize that kind of knowledge for you, but it was much easier to verify for myself. More complex concepts like Go channels , which I haven’t gotten to, were also a weak spot. I couldn’t verify whether what it gave me in Go was actually correct, and had a lot of non-idiomatic code until I got an actual experienced Go developer to take a look and review “my” code.

Via: https://vickiboykis.com/2026/04/20/build-yourself-flowers/