How to actually work with an AI coding agent

Right now you have Xcode in one window and Claude in another, and you're moving code between them by hand. That's the single biggest thing slowing you down, and it costs you money.

Here's why. When you paste code into a chat window, Claude sees that snippet, alone, with no idea what else is in your app. So you spend half your typing re-explaining your project every time. Then you paste the answer back into Xcode and hope it lands in the right place. Every round trip, you pay again for the same context.

Claude Code is the same Claude, running in a terminal inside your project folder. It opens your files, reads them, changes them, creates new ones, and runs commands. You say "the prayer times are an hour out after daylight saving" and it goes and finds the bug itself.

Before you start: you need a paid plan

Getting it running

You need macOS 13 or later. If your Mac runs a current Xcode, you're fine.

1. Open Terminal — Cmd+Space, type "terminal".
2. Paste curl -fsSL https://claude.ai/install.sh | bash and hit Enter. That's the whole install — it downloads a self-contained program, so you don't need Node.js or anything else first, and it keeps itself updated.
3. Check it worked with claude --version. If you get "command not found", close Terminal and open a fresh one — the installer adds itself to your path and that only takes effect in a new window.
4. Type cd (with the space), then drag your project folder from Finder onto the Terminal window and hit Enter. It fills the path in for you.
5. Type claude. It'll open a browser to log in the first time.

If something goes wrong, run claude doctor — it checks the install and tells you what's broken without starting a session.

Two alternatives, if you'd rather. Homebrew, if you already use it: brew install --cask claude-code — though that one doesn't auto-update, so you'd run brew upgrade claude-code yourself now and then. Or the desktop app, if you'd rather not use a terminal at all; there's a VS Code extension too. Same tool underneath, links on the docs site.

Either way you keep Xcode open alongside it. Xcode is where you hit Run and watch the simulator; Claude Code is where the code gets written.

What changes immediately

• You stop pasting. You just describe the problem.
• It reads the actual files, so it stops guessing at what your code looks like.
• It can build your app itself and read the compiler errors — then fix them without you relaying red squiggles back and forth. Ask it once: "what's the xcodebuild command to build this scheme to the simulator?" Then tell it to run that after every change. This is the loop that makes it fast.

InDesign makes pictures of apps. It can't make an app.

Every hour you spend laying out a screen in InDesign, you spend again translating it into SwiftUI by hand — and it never quite matches, so you go back and forth. You're doing the work twice and getting a worse result.

For an iOS app, the design is the SwiftUI code. Describe the screen and let Claude write it:

Then hit Run and look at it. Spacing too tight? "The gap between rows is too tight, and make the countdown twice as big." Ten seconds, not ten minutes of re-layout.

Where visual tools still earn their place

• Sketching on paper before you start — two minutes, and it stops you building the wrong screen.
• Icons and artwork. An app icon is real design work.
• App Store screenshots. Also real design work.

Not screen layout. Screen layout goes in code.

And use what iOS gives you free — navigation, lists, date pickers, dark mode, Dynamic Type, VoiceOver. Apple's Human Interface Guidelines are worth an hour. An app that looks like an iOS app feels better than a custom-designed one fighting the platform, and it's a tenth of the work.

Here's what trips everyone up: Claude has no memory between sessions. Close the terminal, come back tomorrow, and it's a brand new Claude who's never seen your app. So you spend the first twenty minutes re-explaining. That's where most of the frustration comes from.

The fix is four plain text files that live in your project. Claude reads them at the start of a session and writes to them at the end. They're the app's memory.

You'll hit the same problem again in six weeks, and so will Claude. A lesson you didn't write down gets paid for twice, at full price. That file is the reason experienced people move fast — not because they're smarter, but because they're not re-solving last month's problem.

The most important thing to put in CLAUDE.md

Everything else in that file is detail. This is the part that changes how every session goes, so it's already written into the template. Copy it as-is:

Why that last paragraph matters more than it looks. Claude only ever gets your text. Even when you dictate, something turns your voice into words first — the audio never reaches it. So every bit of tone is gone: the pause before a word, the one you leaned on, whether you were joking or frustrated or just thinking out loud.

It's very good at filling in that gap, and that's the problem. It fills it with a guess, the guess sounds confident, and you don't find out it guessed wrong until forty minutes of code later. The rule above turns the guess back into a question, which is the cheapest trade you'll ever make.

Then every session starts like this:

Twenty minutes of re-explaining becomes twenty seconds. Do this and everything else gets easier.

1 · Orient

Get it to read the docs and describe the state of things before you ask for anything. If it describes your app wrongly, fix that before you let it write code.

2 · Plan before code

For anything bigger than a small change: "Don't write any code yet. Tell me how you'd approach this, which files you'd change, and what could go wrong." Reading the plan takes a minute and catches the misunderstanding before it's spread across eight files. Claude Code has a plan mode — press Shift+Tab twice — where it can look but not touch until you approve.

3 · Build in small pieces

One screen, one feature, one bug. Not "build the settings screen and the notifications and the widget." Small changes are easy to check and easy to undo. Big ones are neither.

4 · Verify — every time

Build it. Run it. Look at it. Claude will tell you it's done, and it usually is — but "usually" isn't good enough when the alternative is ten seconds in the simulator.

5 · Commit

See the next section. Non-negotiable.

6 · Write it down

Before you close the laptop: update todo.md, add anything painful to lessons.md, write two lines in handover.md. Ninety seconds, saves you twenty minutes tomorrow. You can just ask — "update todo.md, lessons.md and handover.md for what we did today" — then read what it wrote and correct anything it got wrong.

If you're not using git yet, this is the most urgent thing on this page.

Git saves snapshots of your project. Broke something and can't work out what? Roll back. Agent went rogue and rewrote nine files you liked? Roll back. Without it, "undo" means Cmd+Z until your hand cramps, and it doesn't reach across files.

Xcode has git built in, but honestly: just ask Claude Code to set it up and commit for you. You don't need to learn the commands on day one.

Then, after anything that works: "Commit this." Commit when things work, not when you're finished. A commit is a save point. Make lots of them — they're cheap, and they're the difference between an annoying afternoon and a lost weekend. Then push to a private GitHub repo so a dead laptop isn't a dead project.

Two rules with real teeth

Never put a password, API key or secret in your code. Not temporarily, not in a file you plan to delete. Git remembers everything forever — deleting the file later doesn't remove it from history. Secrets go in a gitignored file. Ask Claude to set this up properly the first time you need a key.

If you ever do paste a key somewhere public, assume it's burned and generate a new one. Bots scrape GitHub for keys within minutes. That's not paranoia, it's Tuesday.

Every plan has limits. Here's where it actually goes, roughly in order of impact.

Context is the budget. Claude reads your conversation plus every file it's opened, every time it replies. A long session with lots of files open costs more per message than a fresh one. That's why the four memory files matter — they're a compressed summary instead of an hour of re-explaining.

Start a new session for a new task. /clear wipes the slate. Finished the settings screen and moving to notifications? Clear. Don't drag two hours of unrelated conversation behind you.

Say what you want, once, properly. The most expensive thing you can do is give a vague instruction, get something wrong, and go three rounds correcting it.

Point at files. "Look at PrayerTimesView.swift" is cheaper and more accurate than letting it search your whole project.

Screenshots are expensive — and it's the dimensions that cost, not the file size. Compressing the PNG saves nothing; cropping saves almost everything.

And if the thing is already a file on your Mac, give it the file path instead of a picture of it — reading a file off disk is essentially free.

Use the cheaper model for boring work. Renaming, adding comments, mechanical edits — that doesn't need the top-tier model. /model switches. Save the expensive one for architecture, weird bugs, and anything where being wrong is costly.

Know your plan's limits. Claude Code needs Pro or above — there's no free tier for it. Even on Pro there are usage limits and you can hit them. Type /usage to see where you stand — worth knowing before you're mid-debug at 11pm.

Most of these cost someone a real day.

Claude sounds equally confident whether it's right or wrong. There's no wobble in its voice when it's guessing. So when it tells you something surprising — "that library doesn't support that", "the API changed" — check it. Especially about anything recent; its knowledge has a cutoff and it doesn't always know what it doesn't know.

"It's done" means "I think it's done." Look at it yourself.

It will happily invent a function that doesn't exist. If it uses an API you've never heard of, search Apple's documentation before you build a feature on top of it.

Don't let it wander. If you ask for a bug fix and it also reformats three other files and "improves" your naming, that's a mess to review and a mess to undo. Say "only change what I asked for" — and put it in your CLAUDE.md so it applies every session.

Simplest thing that works. AI loves building elaborate structures for problems you don't have yet. If a screen comes back as 300 lines and feels like it should be 80, say "this is over-engineered, simplify it." It will, and you'll understand your own app better.

When it's stuck in a loop, stop. If it's tried three fixes for the same bug and none worked, it's guessing. Break the loop: "Stop fixing. Add print statements to show me what's actually happening at each step, and let's look at the output." Then run it and paste what you see. Nearly every stuck bug is a wrong assumption about what the code is actually doing — and you can't fix that by trying harder, only by looking.

Don't build the whole thing before you use it. Get the five prayer times showing correctly and one notification firing. Put it on your own phone. Live with it for a week. You'll learn more from that than from three weeks of adding features nobody's tested.

First: does this app need a backend at all?

No. And that's worth deciding deliberately, because it's a security decision.

Prayer times are calculated from a latitude, a longitude and the date. That's maths, and it runs on the phone. What do you actually need to store? The user's location, their calculation method, their notification settings — all per-device preferences. UserDefaults or SwiftData. No server, no accounts, no network.

The moment you add a database with people's details in it, you've created a privacy policy you now need, a breach you're capable of having, a dependency that can go down and take your app with it, and an app that stops working on a plane. In exchange for nothing, because no feature here needs it.

And local-only isn't the cheap option — it's the better product. "Works completely offline. Your location never leaves your phone." For an app someone opens five times a day, that's a genuine selling point.

When you eventually do need one

Use Supabase — a managed Postgres database with authentication and a free tier. The reasoning is simple: writing your own login system is one of the reliably worst things a beginner can do, and this means you don't have to.

But be clear about what it does and doesn't do. It hosts the data. It doesn't take responsibility for it — you're still the one accountable. Three things bite people, in order of how often:

Then: the calculation traps

Prayer time calculation has genuine complexity. Different calculation methods — ISNA, Muslim World League, Umm al-Qura and others — give different times, and which is correct depends on where the user is and what their community follows. Don't let Claude write this from scratch and don't assume its output is right. Use an established library (Adhan-Swift is the standard open-source one), make the method a user setting rather than a decision you bake in, and check the output against a source you trust for a few locations before you ship.

High latitudes break the maths. Above roughly 48°, there are times of year with no true Isha or Fajr. Established libraries have rules for this — make sure you picked one deliberately rather than shipping whatever the default was.

iOS limits you to 64 pending local notifications. Five prayers a day is about twelve days of scheduling, so you can't schedule a year ahead. You need a rolling window, re-scheduled each time the app opens. This catches people out weeks in, when notifications silently stop.

Get the permissions flow right. Notification and location permission both need asking properly, and you need to handle the user saying no. Ask when it makes sense — explain why you need location before the system dialog appears, not as a cold prompt on first launch.

Time zones and daylight saving. Test by changing your simulator's date and time zone. This is where the bugs live.

Test on a real phone early. The simulator lies about notifications, background behaviour and battery. Put it on your own iPhone as soon as it does anything useful.

Not yet — get the basics running for a month first. But so you know they exist:

• Skills and custom commands — teach Claude Code a workflow once, then invoke it with a slash command.
• Subagents — spin off a separate agent to research or review while you carry on.
• MCP servers — plug Claude Code into other things: your database, GitHub, a browser it can drive and screenshot.
• Hooks — run something automatically on every change, like a build check.

It's all at docs.claude.com/claude-code. Type /help in Claude Code to see what's available right now.

About a year ago I was where you are: one project, one chat window, working it out as I went. Here's where it's got to — not to show off, but so you can see that the four boring text files in Part 3 are the foundation everything else sits on, and that the order you do things in matters more than the speed.

More than thirty projects

E-commerce sites. A cultural platform for a First Nations organisation. A band's stage app that drives a live teleprompter off the audio. A forensic chain-of-custody ledger. A couple of Android TV apps. A field-service platform for a commercial air-con firm.

They all share one brain

Every project has the same four files you've just been handed. Above them sits a hub — one master document that knows every project, every server port, where every credential lives, and a catalogue of every reusable thing I've built.

That hub loads automatically at the start of any session, in any project. The agent knows the whole portfolio before I've typed a word. That's Part 3, just scaled up.

Which means I stopped rebuilding things

Payments, login, email agents, a barcode and QR tracking system — each built once, written into a catalogue, then lifted into the next project that needed it. There's a search across all thirty projects, so I can ask "has anyone already built this?" and get an answer in seconds instead of rebuilding it over a day.

Half of what feels like new work already exists somewhere. You just have to be able to find it — which means you have to have written it down.

And the lessons compound

Every project's lessons.md feeds a master lessons file. A mistake I made in June doesn't get repeated in August — not by me, and not by any agent working on any project, because they all read it.

Then agents

Not one clever agent that does everything. Several narrow ones, each genuinely good at a single job, running on a server on a schedule. One watches a mailbox and drafts replies. One handles booking enquiries for the band. One pings the databases so the free tiers don't fall asleep and take a site down with them. They report their status to a dashboard rather than being chased.

And a command centre on top

A dashboard showing all thirty-odd projects at once — what stage each is at, what the next action is, what's blocked, what's gone stale. It talks; I can ask it out loud where things stand and it answers. Half of that is a toy and I'll admit it. But it does one serious thing: it makes it impossible to quietly forget a project.

The point

None of that was possible on day one, and none of it was the plan. It happened because the foundation went in early, and then each step was a small step from the last. A CLAUDE.md. A todo. A lessons file. Git. Everything above is built on those four things.

And here's the part that actually matters to you right now: the foundation is what makes it cheap. Every hour I don't spend re-explaining a project is tokens I don't burn. Every problem I solved once and wrote down is a problem I don't pay for twice. Every feature I lift from the catalogue instead of rebuilding is a day I get back. The discipline isn't overhead — it's the thing that makes this affordable enough to keep doing for a year.

Skip it and you'll spend that year re-explaining yourself, re-solving solved problems, and paying again and again for the same context. That's the tax this whole document is trying to save you.

The rest is practice. There's a folder of ready-to-fill templates for the four memory files to go with this — drop them in the root of your project next to the .xcodeproj. Build something you'd actually use every day; that's the only reliable test.