The Method
How to actually build things with AI.
The Core Loop
Building with AI follows a simple loop:
Describe → Review → Refine → Repeat- Describe what you want
- Review what Claude creates
- Refine with feedback
- Repeat until it’s right
That’s it. Everything else is technique within this loop.
Starting a Project
The first prompt matters less than you think.
Don’t overthink it. Don’t try to specify everything upfront. Start with the outcome:
I want to build a menu bar app that shows my calendar events for today
That’s enough. Claude will ask clarifying questions if it needs more information:
- What platform?
- What should happen when you click events?
- Where does calendar data come from?
Answer the questions. The project emerges through conversation.
Bad first prompts
Create a SwiftUI macOS application using AppKit’s NSStatusItem for menu bar presence with a NSPopover containing a List view bound to an array of CalendarEvent structs fetched via EventKit framework with proper permission handling
This is too specific too early. You’re guessing at implementation details before you understand the problem. Let Claude figure out the technical approach.
Good first prompts
I want a menu bar app that shows today’s calendar events. When I click an event, it should open in Calendar.
Clear outcome. No implementation details. Room for Claude to ask questions.
Describing Features Like a Designer
You already know how to do this. It’s the same skill you use when writing specs or user stories.
Think outcomes, not implementation
Don’t say:
Create a function that iterates through the array and filters items where isCompleted equals false
Do say:
Show only the incomplete tasks
You care about what the user sees and experiences. Let Claude figure out how to make that happen.
Reference what you know
Claude understands references to existing products:
Make the sidebar collapse like Notion’s I want a command palette like Linear’s The animation should feel like Apple’s spring animations
These references convey a lot of information efficiently.
Be specific about what matters
Vague:
Make it look better
Specific:
The spacing feels too tight. Add more padding between list items, and make the text slightly larger.
The more specific your intent, the better the output.
The Iteration Loop
Nobody gets it right on the first try. That’s fine — iteration is the point.
Small prompts beat big prompts
Instead of describing five features at once, do one at a time:
- “Add a button that saves the note”
- Review the result
- “Now add a confirmation when it saves successfully”
- Review
- “Make the confirmation disappear after 2 seconds”
Each cycle takes seconds. You stay in control. You catch issues early.
”Not quite” is useful feedback
When the result isn’t what you wanted, describe the gap:
That’s close, but the button should be in the top right, not the bottom
The animation is too fast — it should take about half a second
This works, but I wanted it to also [X]
Claude adjusts. You don’t need to know how to fix it — you just need to know what’s wrong.
You don’t need to understand all the code
When Claude shows you code, you don’t need to understand every line. Focus on:
- Does it work?
- Does it feel right?
- Does it do what I asked?
If yes, move on. If no, describe the problem.
You can always ask Claude to explain something: “What does this part do?” But understanding isn’t required for progress.
Reading Code You Didn’t Write
Sometimes you’ll want to understand what’s happening. Here’s how to navigate without getting overwhelmed.
Files match features
Code is usually organized around features:
Views/SettingsView.swift→ the settings screenModels/User.swift→ user dataServices/CalendarService.swift→ calendar-related functionality
If you want to modify the settings screen, you probably want to look at files with “Settings” in the name.
Ask Claude to explain
What does the CalendarService file do?
Walk me through how the data flows when a user taps “Save”
Why is this component structured this way?
Claude can explain code at whatever level of detail you want.
The goal is navigation, not mastery
You don’t need to understand Swift or SwiftUI or whatever framework you’re using. You need to know enough to:
- Find the right file to talk about
- Understand roughly what’s happening
- Describe what you want to change
That’s it.
When Things Break
They will. This is normal. Even experienced developers spend significant time debugging.
For detailed troubleshooting strategies, see Getting Unstuck.
First move: describe what happened
I clicked the save button and nothing happened
The app crashes when I open the settings
It shows this error: [paste the error]
Error messages look scary, but they’re information. Copy the whole thing and show Claude. It’ll know what to do.
Don’t panic
When something breaks, the instinct is to think “I broke it” or “I can’t do this.” Resist that.
Every bug has a cause. Claude can usually find it. Your job is just to describe what you observed.
”It shows this error” is enough
You don’t need to diagnose the problem. You don’t need to understand stack traces. Just:
- Describe what you did
- Describe what happened (or didn’t)
- Share any error messages
I tried to add a new item to the list, but it doesn’t appear. The console shows this: [error message]
That’s enough information to debug.
When to Trust vs. Push Back
Claude is good, but it’s not perfect. Knowing when to trust and when to push back is a skill.
Trust: implementation details
Claude generally makes good choices about:
- How to structure code
- What syntax to use
- Which APIs to call
- Technical patterns and conventions
Unless you have specific knowledge that contradicts its choice, trust these decisions.
Push back: when results don’t match intent
If the result isn’t what you wanted, say so:
That’s not what I meant. I wanted [X], not [Y].
This works technically, but it doesn’t feel right. The interaction should be [describe it].
You added [feature], but I didn’t ask for that. Can we keep it simpler?
Claude can’t read your mind. It’s working from your description plus its training. When there’s a gap between what you wanted and what you got, that’s your cue to clarify.
Push back: over-engineering
Claude sometimes adds complexity you didn’t ask for — extra features, abstraction layers, configuration options.
This is more complicated than I need. Can we simplify? I just want [core requirement].
Simpler is usually better, especially when you’re learning.
The “Good Enough” Mindset
Shipping beats perfection.
First version teaches you
You won’t know what the second version needs until you use the first version. Ship something basic. Use it. Learn what’s missing. Then improve.
This works well enough for now. Let’s move on and come back if needed.
You can always improve later
Code isn’t permanent. You can change it. The feature you ship today can be refined tomorrow.
Don’t let “it could be better” stop you from shipping “it works.”
Design thinking applies
You already know this from design: real feedback beats theoretical perfection. Ship, test with real use, iterate.
The same principle applies to building. Get something working. Use it. Improve it based on actual experience.
Putting It Together
Here’s the workflow in practice:
-
Start with an outcome
I want to build [X] that does [Y]
-
Let the conversation develop
- Answer Claude’s questions
- Add details as they become relevant
- Don’t try to specify everything upfront
-
Work in small increments
- One feature at a time
- Review each change
- Refine before moving on
-
Describe problems, not solutions
- “This doesn’t feel right” is valid
- “The spacing is off” is useful
- Let Claude propose fixes
-
Ship when it works
- “Good enough” is good enough
- Improve based on real use
- Don’t perfect before shipping