How to Talk to a Computer

For my partner, talking to a computer is almost as instinctive as talking to you or me. Put simply, it's a skill he's built up over many years, and a lifetime of being interested in computers. Not me though. I was the arts and craftsy one, the reader, the teen who learned to knit because I thought it would be fun to make my own clothes and learned to juggle because I loved seeing other people do it. I learned best by talking to other people, by watching them do things, by asking mountains of questions.

Millennials and younger generations are mostly considered to be digital natives, and I do just about fit into that category! I loved TV, and it was a treat to play on my friends' computer games, but other than a 1st gen Game Boy that I was definitely a bit addicted to, I didn't have much interest in computers.

I got my first phone aged 17, the golden age of the Nokia brick, and it definitely took me a while to get used to texting, muddling my way through lol (no, it doesn't mean "lots of love") and the like. Actual emojis (rather than using thoughtfully placed punctuation) would've seemed futuristic to me. I did use a computer in school, but we were rarely asked to produce work on it, and it wasn't until I went to university that I got my first laptop.

The technological changes came thick and fast then. I went to uni with a stack of floppy disks, this oversized highly breakable item that you had to have spares of in case the one you saved that all important essay on got corrupted somehow. By graduation the USB stick was everywhere and people were inviting me to things via Facebook, rather than just talking to me in person.

Technology and I didn't get on particularly well together for a while; I used a computer willingly to write essays, but I still took all of my notes by hand and preferred a highlighted photocopy and a curated list of handwritten essay plans before my thoughts made it to the computer. My first smart phone was an iPhone 4, though I would have to admit that I've never looked back from having a phone since.

"Just ask the agent to make you an app" says my partner, incredulous that I wouldn't know how to do this. "But how do I talk to a computer?" I reply, slightly petulantly. At first I tried to talk to it in its own language, but since I have a very very basic knowledge of HTML at best, this doesn't really work.

The interesting thing about living with an engineer is you become very familiar with technical terms and phrases, but you have no idea what they mean or what the context for them is. I have spent many years (he was an early adopter) listening to talk of LLMs, APIs, concurrency, onboarding and far more things than I can think of right now, but crucially I don't know what any of them actually mean. I occasionally ask what's that, I learn something in the moment, and promptly forget it all again a few days later.

So when I try to use technical language to describe the thing I want the AI agent to do, I find myself at sea. I don't really know what I'm talking about, and it's confusing the issue. Eventually I begin to describe in detail in plain English what I want it to do.

I want to create an app, I say, that takes information from my local leisure centre about when the lanes are available in the swimming pools. I detail the different pools and their names, how many lanes they each have and what information I need to know.

My partner tells me to sketch out what I want the app to look like, and I do so, but for some reason it looks like I've never seen an app before! It is surprisingly hard for me to visualise what bits of information go into the finished product. As a person who loves good design, I think I have an understanding of what makes something well-designed, and even why, but I was thrown when I had to think from the foundations up. Functionality, simplicity and clarity are such huge elements of UI design, every step of the way. When he then shows me his sketches, I realise that I'm trying to be too clever, and not thinking enough about those three core principles. His is just better (damn him, he already has a good job, already knows how to make computers do his bidding)!

Learning 1: You can talk to an AI agent in plain language, describe a technical problem you would like it to solve, and it will write the code for you. The agent is a translator of sorts - you talk to it, then it talks to the computer, and everyone's happy.

Well, almost. The next issue I encounter is how to talk to the agent once it has produced something that I don't like or that didn't work. How to get it to change that thing without breaking other things, or just coming up with the same result again. I realise that in addition to describing things in plain English, I have to be ruthlessly specific. If there is one use case that works and one that doesn't, I tell the agent that it works in case a but not in case b. I ask questions of the agent frequently: Is this possible? Why is this doing this? Why doesn't it work? What is it about this code that is breaking? And so on.

Learning 2: Be as specific as possible. If something doesn't work first time, tell the agent. Maybe ask it why it thinks it didn't work. Give examples of what is going right and what is going wrong. Take photos of the issues and upload them to the AI to show them the problem. And ask questions whenever you're not sure. If you don't understand something the agent has said, ask it to clarify.

Be aware that sometimes there are just things it can't do. Sometimes it will come up against a specific limitation in the software you are using - for example, occasionally I found that XCode couldn't do the thing I wanted it to do. This was how Apple had designed it, and no amount of talking around the issue with the agent or asking it to do different things was going to work. I find it useful to take a break in those moments, or start working on something else instead, so I can let my brain process the problem for a while and not get stuck in a frustration loop.

Learning 3: It's ok to take a break. Sometimes talking to the computer can be really annoying and it just doesn't do what you want it to. There may be solutions to this, there may not be, but it's not helping me or anyone else to sit at my desk shouting at the agent or my laptop (even if this feels appealing in the moment).

Be prepared to ask the agent to revert the changes. It might feel like a step back or counterintuitive to get the AI to undo what you've just spent a while trying to do, but it's much better to have a clean foundation that works than to try and add things onto a base that is fundamentally flawed.

If there's one thing my partner gets frustrated with at work, it's an agent just trying to come up with a band-aid solution to a problem and thinking that if it just keeps adding code that will fix it (I wonder who the computers learned this from?!) This is rarely true, and it's always best to try and make the product work in the best way with the simplest foundations. In my experience, older people are a lot more concerned than younger people about breaking things. They are scared to mess around with technology in case they break it and they can't fix it again. I've been there, got the t shirt… and the mug, the magnet, the lanyard, you name it. But it's ok, we go again, we learn and we improve.

Learning 4: Don't be afraid to tell the computer to remove things that don't work, or don't add anything to the design. Even if you've spent time and energy on creating something, it's ok to admit that it isn't helping or isn't working. The amazing thing about using AI to code is that they can do things unbelievably quickly. Where once a developer would have to go back through pages of code and check it methodically, your agent can do it in seconds. Embrace this, it's brilliant, and it enables you to focus on what matters more to you as a designer.