I Thought I Was Learning How to Talk to AI. I Was Actually Learning How to Think.

In care work, sometimes you have to explain something to another person and hope they understand exactly what you mean. I have spent years giving instructions, but there is something I have learnt from doing this: what you say is not always what the other person hears.

You might say, “Make sure she’s comfortable.” That sounds straightforward. But comfortable how? Does she need another pillow? Is she cold? Is she in pain? Does she need help changing position? Does she want the TV turned down? The instruction sounded clear to the person giving it, but it might be completely vague to the person receiving it.

This week, while learning about AI and building products, I realized that the exact same thing happens when we talk to AI. And that was probably the biggest lesson I took away from the week.

What exactly do you ask AI?

Before joining the Dev and Design bootcamp, prompting to me was basically telling ChatGPT to do something. I type a request and it gives me an answer. I ask again if I don’t like the answer.

Then came this week’s session on prompts and prompt engineering. The word “engineering” made it sound much more complicated than it actually is. At its simplest, I began to understand it as learning how to explain what you want properly.

If I walk into a restaurant and tell the waiter to “give me food”, he would probably look at me strangely because I haven’t told them what I like, what I want to eat, or the quantity. But if I said I would like something filling, not too spicy, with chicken, and I only have about 20 minutes, the waiter will definitely have something to work with.

"I see prompting differently now. AI isn’t the problem; sometimes we simply haven’t explained the problem well enough."

Making the connection with my own project

I worked on an idea called Care Pulse during the bootcamp. It was conceived as a way to check in on care workers after a difficult shift. But the more I questioned it, the more I realized my initial concept was only the very beginning of an idea.

Do I ask, “How was your day?” Do I use a scale of 1 to 10? What happens next if someone says they are exhausted? Who sees the data? Would a care worker even spend five minutes on this after a draining shift?

I wasn’t building yet because those questions were actively reshaping my idea. I was actually thinking.

An idea can sound good until you start questioning it

Refining an idea was the second lesson of the week. In our everyday lives, we tend to resist this step. We get a spark, fall in love with it, and resist anyone questioning it—because we have already pictured in our minds how great it could be.

Building a product is far from it. You have to be willing to poke holes in your own idea. The app is not mine to build for vanity; I don’t just build it because I had an impulse. I need to ask myself:

• Who actually needs it? Identifying the specific human at the end of the wire.
• What exact problem are they having? Distinguishing between symptoms and underlying root causes.
• How are they coping right now? Understanding the manual workarounds already in place.
• What is the simplest thing I could build that would actually help? Cutting away unnecessary bloat.

From an idea to something someone could actually build

Then we moved on to something I had never really thought about before: a PRD, or Product Requirements Document.

The name sounds very technical, but the concept is remarkably down-to-earth. Try going to a builder and telling them you want a house—they can’t really start. You need to give them enough concrete information to understand what they are building: number of rooms, square footage, materials, timeline, and budget.

A PRD does something similar for a digital product. It takes the idea out of your head and puts it somewhere that other people—designers, developers, product managers, and even AI—can understand. That was probably the moment I started seeing the connection between everything we have been learning:

This is where AI gets interesting

It is fascinating to me that AI can now sit right in the middle of this whole process. I give it a rough idea; it asks questions I had not considered; I challenge its suggestions; it helps me organize my thoughts. And eventually, it can help me build the thing.

I need to be careful, though. Just because AI can build something quickly doesn’t mean I should ask it to do it right away.

"It feels productive that you have an idea at 12 noon, and by 12:15 AI has generated an app. But it becomes counterproductive if the wrong thing was built in that 15 minutes."

Coming from care, this feels familiar

Care work has taught me that the person you are helping has to come before the process. You start with what the person actually needs, not what form you need to complete.

So before you ask what technology you should use, you should first understand the problem you are trying to solve. Right now, before I ask AI to create ten screens, I should know whether I even need ten screens. Before writing code, I should understand what the person using the product is actually trying to accomplish.

I came into the bootcamp wanting to learn how to build

I am right on track. I have realized that thinking about the problem, thinking about the person, and thinking about what success actually looks like all come before building.

Prompt engineering isn't a secret code. It is about being clear enough about what you want in the first place.

I will find out a lot more as I keep building.