The Method

How to actually build things with AI.

The Core Loop

Building with AI follows a simple loop:

1. Describe what you want
2. Review what Claude creates
3. Refine with feedback
4. 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:

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:

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:

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:

1. "Add a button that saves the note"
2. Review the result
3. "Now add a confirmation when it saves successfully"
4. Review
5. "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 screen
• Models/User.swift → user data
• Services/CalendarService.swift → calendar-related functionality

If you want to modify the settings screen, 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, and describe what you want to change. That's it.

When Things Break

They will. This is normal. Even experienced developers spend significant time debugging.

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:

1. Describe what you did
2. Describe what happened (or didn't)
3. Share any error messages

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, and technical patterns. 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?

Push back: over-engineering

Claude sometimes adds complexity you didn't ask for — extra features, abstraction layers, configuration options.

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. Ship something basic. Use it. Learn what's missing. Then improve.
• You can always improve later. Code isn't permanent. 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. Real feedback beats theoretical perfection. Ship, test with real use, iterate.

Putting It Together

Here's the workflow in practice:

1. Start with an outcome — "I want to build [X] that does [Y]"
2. Let the conversation develop — answer Claude's questions, add details as they become relevant, don't specify everything upfront
3. Work in small increments — one feature at a time, review each change, refine before moving on
4. Describe problems, not solutions — "this doesn't feel right" is valid; let Claude propose fixes
5. Ship when it works — "good enough" is good enough; improve based on real use

Exercises

1. Write a "good first prompt" for an app idea — a clear outcome with no implementation details — and notice the clarifying questions Claude asks back.
2. Take a vague piece of feedback like "make it look better" and rewrite it as specific, outcome-focused intent.
3. Practice the small-prompt loop: build one tiny feature, review it, then refine it in a second prompt — instead of asking for everything at once.