As a mostly self-taught coder (apparently that's true for 65% of coders [source]), I enjoy tweaking code, adapting examples found online, and learning by doing. But then comes the part I dread: the hosting, the deployment, the maze of configuration files that stand between my working code and anyone else being able to use it. That’s where Claude Artifacts shines; it doesn’t just write code; it also packages it into a standalone, shareable application. Even better, others can modify it too. Unsurprisingly, I have seen these tools mentioned by product managers and other non-coders who have ideas by the bucket but no time to dive into deployment or devops.
DimURL2DSL
During a recent product discussion, my colleague Emily Koechel mentioned how useful it would be to translate Dimensions URLs into DSL* queries, the language that powers Dimensions' API. This seemed like a brilliant idea: the WebApp URLs include all the filters, so theoretically, we had all the necessary information to reverse-engineer a DSL query. Do you want publications from 2023? Add `and_facet_year=2023`. Do you want publications funded by the US or the UK? Add `or_facet_funder_country=US&or_facet_funder_country=GB`? Now, for more subtlety, if you wanted publications funded by the US and (not or) the UK, then you would replace `or_facet` by `and_facet`.
The question was how to approach this translation. At first, I considered manually listing all the filters in a spreadsheet or even asking the dev team if they had one. But then I realised those filters were already encoded in the HTML of the page, which would be really easy to grab. Before even attempting to do it manually from the HTML, I thought I would try feeding it to Claude. I uploaded it, along with the API documentation, and added a few lines explaining how I thought the translation should work and what the UI should include. Claude wrote the code and created a decent front end to test.

I spent about an hour refining it, adding more document types (publications, grants, datasets, and so on) and testing as I went. Most of the filters in the HTML matched the API filters, so the translation was surprisingly smooth. Even returning facets** was straightforward based on the URL, which means that we can easily get the data from the Analytics view (see on Youtube the old interface) into a table. This means non-coders can now easily move from the WebApp to a Google Sheet using the Google Sheets connector, without needing to learn the DSL (stay tuned for Excel).
Less than two hours after starting, I shared a working version with Emily. She easily added the bits I had missed out, such as searching text and some of the advanced search. It does not include everything yet, but for less than a day of work, it is functional enough to easily translate Dimensions WebApp URLs into a Dimensions API query.
Embracing AI
Working with Emily on the shared prototype underscored the most striking part of the process: how quickly we moved from idea to something testable. Instead of spending weeks planning and waiting for development time, we had a functional tool within hours. The code is not optimised, as ChatGPT noted when prompted, and there is no polished interface yet. But having something that worked, not just in theory, validated the concept and provided colleagues (and now, you) with an immediately useful tool. AI prototyping brings substantial value by accelerating early-stage development and broadening what's feasible. Just don’t mistake prototype code for production code.
*DSL: Dimensions Language Query
** Facets: in the Dimensions API, facets let you quickly see counts and breakdowns: like how many papers were published each year or by which countries, without listing every single result.