Learning more tools vs letting AI do the building

For a long time, I’d have an idea and immediately start counting the tools I’d need to learn. Hand-drawn illustrations? Illustrator or Procreate. Motion? Rive or Lottie. Getting it all onto a website was another skill again. AI has made that list less of a barrier for me. I’m spending less time figuring out how to build and more time deciding what deserves to be built.

I think of that learning overhead as a tool tax: the hours between imagining something and being able to experience it. For projects outside my main work, that tax cost me more than time.

The maths didn’t work for me

My website was one of those ideas. I knew how it should look. I’d even designed it. But the illustrations, motion and implementation meant learning several tools that weren’t part of my main work. I couldn’t justify the time for something I’d use so occasionally. So I kept putting it off and settled for a portfolio with a few case studies, built to get me through an interview.

The real cost is the ideas we cut

Looking back, I wasn’t just postponing projects. Sometimes I’d picture something and cut it down before it reached a frame, because I was already thinking about how hard it would be for me or my team to build. I’ve done that at work too. The implementation effort was shaping the idea before I’d had a chance to explore it.

I was deciding what I could imagine based on what I knew how to build.

This site is my test

So when AI made execution easier, I tried it on a project I’d kept putting off. This one.

The old me would have spent days on moodboards, wireframes and colour studies, then weeks on screens and assets in Figma, just to see if it all worked together. That’s before a single line of code.

This time I didn’t make one wireframe. No Pinterest board either. I described the picture in my head to an AI agent, piece by piece, and built it in iterations. In under a week, I had something I could use and feel, rather than just imagine.

The illustrations and motion all started as descriptions instead. Once changing something got cheap, I stopped holding back in what I imagined. I still have a thousand tiny details waiting to go in. This site is a place to try them, not a finished portfolio.

I’ll share the personal influences behind the site in a follow-up note. Getting those ideas onto a page was only part of it, though.

The paper plane worked, but it felt wrong

Take the paper plane that flies out of the postbox in the bottom corner of this website ✈️. It’s better experienced on desktop, where you can watch it fly across the page. The first version flew along a few predefined paths. Technically it worked. It also looked like it was on rails.

I wanted it to feel like a paper plane reacting to the air, rather than following a set route. So instead of asking for more paths, I asked the agent to learn how paper planes actually fly: lift, stalls and how thermals (rising warm air) push them around. Then I took a screenshot of the page and drew on it how random the paths should be. Now no two throws are the same.

I didn’t need to learn a physics engine or a motion tool. I needed to recognise what wasn’t working and explain the change I wanted. The agent helped me work through it, but I still had to decide whether the result matched what I had in mind. That’s what owning the thinking looked like in this small experiment.

Cheap to build doesn’t mean build everything

My website is a personal experiment. In my work as a UX designer, deciding what to build starts with understanding the problems users are facing: who am I building for, and what do they need? Then I need to understand the business, where it’s heading and what value I can bring with my skills. Easier execution doesn’t answer those questions for me.

I’m also spending more time on articulation. It’s a skill I’ve considered underrated in design, and one I’m trying to get better at. An agent needs to understand where I’m coming from, not just what to make. That means explaining the problem and the reasoning behind the solution, not only describing the output. Articulation and storytelling matter when I’m explaining my thought process to people too.

The choices still need to feel like mine, including the ones I reject. I built hand-drawn route postmarks for my work history and threw them out, because where the work happened wasn’t what I wanted to say about it. I keep the reasons for my choices written down so I can distinguish what I chose from what I simply accepted. That’s how I bring my taste into the work and keep ownership of the decisions, even when the agent suggests options.

The thousand details in my head don’t all need to go in now. Some can wait. Being able to build them is no longer the only thing deciding when I do.

So, should you still learn the tools?

I’m not claiming this is how every designer will work from now on. Tools that are central to my craft are still worth learning deeply. But tools change as the industry changes. For the ones I only needed to bring an occasional idea to life, I’d rather describe than master.

I’m optimistic, and I’m enjoying this phase.

I used to ask whether I could build an idea. Now I spend more time asking whether I should.

If there’s an idea you’ve kept putting off because of the tools you’d need to learn, I’d like to hear about it.