Building AI tools with Cursor as a non-developer

Over the past couple of days, I've been using Cursor to build a suite of interactive tools designed to help organisations assess, plan and execute successful AI strategies. Going into it, I was fairly realistic about my own technical limitations. My coding experience amounts to some very basic HTML from about 15 years ago, so I expected the process to be a huge learning curve.

For anyone unfamiliar with it, Cursor is an AI-powered code editor that allows you to build software by describing what you want in natural language. Rather than writing code line by line, you collaborate with the AI to generate, adapt and refine it.

I did start our from a strong technical base: I was making changes to an existing code repository created by our dev team. So when I made changes I could review them locally (on my laptop) and then with one click push them to our live server. All this was in place already, which made the process much simpler.

However, I still had to build the tools on my own. Once I'd spent a few hours learning my way around the interface, it became clear that my work would not be about coding but about thinking clearly and deliberately about what I was trying to create.

What mattered most wasn't technical knowledge, but:

• having a well-formed idea of the problem I was trying to solve;
• being able to articulate that intention precisely and with nuance through prompting;
• and having enough UX awareness to imagine how someone would actually experience the tools

To support the UX side, I used Claude to draft early artifacts showing what I wanted the tools to look and feel like, and I iterated on those until they felt right. Those artifacts then became a kind of blueprint for Cursor, making it much easier to give clear and consistent prompting guidance.

With that groundwork in place, I was able to build ten working tools in a single day, followed by another day refining and improving them. I had to rebuild two of the tools entirely, not because the technology failed, but because once I saw them on the screen, it became clear that my original ideas didn't quite work in practice. The experience reinforced something I've seen repeatedly in learning and design work: the closer your intention is to reality, the less friction you encounter downstream.

Giving Cursor a go really helped demystify the idea that tools like this are only accessible to developers. That said, having a well-prepared code repository made a real difference to a non-developer like me! But what stood out was how much less this was about technical skill, and how much more it was about clarity of intention, prompt iteration and thoughtful design.