The most useful AI skill I have took me years of living to learn.
Ten years ago, I couldn’t have built what I’m building with AI today. I didn’t know what I wanted, and AI can’t build anything useful for someone who doesn’t.
Ana Dolaš posted this on X last week: “Being able to very precisely articulate what you want and why you want it has never been more valuable.” More than 400 people liked it, and I’m one of them. But articulating is the second half of the skill. Before you can say what you want, you have to know it, and you learn that by living, over years, by getting it wrong first.
No prompt course can sell you that part.
A checklist doesn’t make you a pilot
Chase Hughes makes a point I keep coming back to. Hand someone the checklist for taking off in an airplane and they still can’t fly the plane.
Prompt templates are checklists. Give the AI a role, a goal, context and a format. That’s all correct, and none of it helps if you can’t fill in the blanks with something true. The template asks for your goal. It can’t tell you what your goal is, or whether the one you typed is the real one or the one you think you’re supposed to want.
This year I built the intake my website clients complete when we start working together. Before AI wrote a line of it, I had to answer questions nobody else could answer for me, and those answers were only the start.
What a build needs before anyone writes code
Ask a good developer to build something and they’ll start with questions. The answers become a specification. A strong prompt for building software is a specification written in plain English. Among other things, it defines:
- Who uses it, and what each person is trying to get done. The client finishing their intake at 9 p.m. after a full day, and the business owner checking who’s finished.
- Who can see and do what. Roles and permissions. I can draft and edit a client’s answers. Only the client can confirm a section and send the finished intake. No client can ever see another client’s answers.
- What it won’t do. Non-goals keep a build from sprawling into everything it could be. My intake never asks a website-only client the brand questions they didn’t pay for, and it never asks anyone for the same files twice.
- How you’ll know it works. Acceptance criteria are specific, testable statements. A client opens their intake, finds their answers already drafted, changes one, confirms the section and sends it, and I see what they sent.
A permission rule isn’t a want, and neither is a list of non-goals. They’re parameters, but every one of them traces back to what you’re creating and who you’re creating it for. Without that, there’s nothing to derive them from.
The why decides the how
Knowing what you want tells you what to build. Knowing why you want it tells you how.
Take two experts who each want a booking form. One wants it because her calendar has gaps, so every extra question costs her a client and the form should take thirty seconds. The other wants it because she’s at capacity and only wants to talk to people ready for a substantial engagement, so the questions are the point. They screen, set expectations and make the call better before it starts. Same what, opposite builds. An AI given only the what will build the average of the two, and the average serves neither of them.
It’s logical, but it starts with the heart
From the outside, this looks like linear thinking. If this, then that, consequence after consequence. But the first link in the chain isn’t logic. It’s what you want, what you care about and what you’re trying to make for someone. You can’t spot the pitfalls around an intention you never named, because nothing exists for them to violate.
And you can’t skip it.
Plenty of AI work can be done halfway and called good enough, and a lot of people use it that way. For a caption, fine.
For a tool your clients will touch, a program with your name on it or a system you’ll run your business on, “good enough” means the AI filled your gaps with its own guesses.
Those guesses come from patterns, and patterns are averages. Whatever you leave unsaid, AI fills with the most typical version, and the parts you care about most are the parts that aren’t typical.
It sands them off without ever knowing they were there.
If you can’t put your intentions into words, you lose the heart of what you’re building and the reason you wanted to build it.
You’ll see it in the results: the screening form that lets everyone through, or the signature program that runs like every other program on the market.
Why I couldn’t have done this ten years ago
Ten years ago, before I’d done the work of facing my own defenses, I often couldn’t tell what I wanted from what I thought I was supposed to want.
Try writing instructions for AI from there. Every goal would have been shaped by what I thought I should want, and every “don’t do that” would have been a guess. I couldn’t have told the tool what I wanted it to build, because I couldn’t have told myself.
That work gave me a second thing that matters just as much. Building with AI means spending a lot of time uncomfortable. Something breaks and you don’t know why. The tool does something you didn’t expect. You run into a concept you don’t understand yet, and the screen sits there waiting for your next instruction. Now I can stay with that discomfort long enough to work it out with the tool, because not knowing something doesn’t threaten me anymore. Ten years ago, it would have.
Knowing what you want and staying present when it isn’t working are hard skills in every sense, and no prompt tutorial teaches either one.
I think about the timing a lot. If this technology had arrived a decade ago, I’d have had the tools without the self-knowledge to use them. It arrived now, after the hard work, at a point in my life when I can say what I want and mean it.
I’m grateful to be alive for this strange, enormous moment. I’m more grateful to be meeting it as the person I am now.
I wouldn’t change a thing.
