How to Build
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.
For a small change, you describe and Claude builds. For a bigger one, you can move the Review step earlier: switch to plan mode (press Shift+Tab, or type /plan) and Claude lays out its approach before touching a single file. You review the plan, refine it, then let it build. Same loop, just reviewing the direction before the work instead of after. See Claude Code in Action for the mechanics.
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
The first version is never the final one. Build in small steps, checking each before you ask for the next. That’s where your control lives.
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 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.
”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 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.
Ship Before It’s Perfect
You won’t know what the second version needs until you’ve used the first. So get something working, use it for real, and let that tell you what to fix. You already trust this from design: real feedback beats theoretical perfection. Code isn’t permanent. Shipping “it works” today beats polishing “it could be better” forever.
This works well enough for now. Let’s move on and come back if needed.