-
How I actually work with AI
I don't treat AI as an oracle - I treat it as a brilliant junior engineer with zero taste, then configure it until it ships my standard of code across the production iOS SDKs I build.
This is the talk I gave on exactly how: encode your taste in a file, give it memory, make it prove its work. Step through the slides below - the transcript under each one is what I said out loud. Wherever you sit with these tools, skeptic or power user, every tactic here is copyable today.
Stop Prompting.
Some of you avoid it.
Some of you live in it.
Skeptic, dabbler, or power user - almost all of us hit the same ceiling: AI as a faster search box. Ask, paste, hope. The leverage was never the model everyone shares. It's the system you build around it.
Never touched itAsk & pasteLives in the toolsConfigure & direct
Wherever you sit on that line, the rest is the jump - the exact setup I run, with real examples you can copy today.
It's not an oracle.
It's a brilliant junior with zero taste.
Infinite energy, encyclopedic recall, and no opinion on what good looks like in your codebase. Treat it like an oracle and you get confident guesswork. Mentor it like a teammate, and it compounds.
Your job changed
From author of every line → to director and reviewer. You set the bar; it does the typing.
Taste is the moat
The model is a commodity. What you ask of it - and what you refuse to accept - is not.
Everything here ships in
production iOS SDKs.
An iOS SDK - public API over hidden internals
SDK/
├─ Public/ Protocols · entry points
├─ Domain/ Models · UseCases · Rules
├─ Data/ DTOs · Repositories
├─ Infrastructure/ Network (internal)
└─ Shared/ DI container · utils
11
versioned Swift packages - shipped as SDKs, reused across apps
~160k
lines of Swift behind those public APIs
Public → internal
every surface protocol-abstracted, dependencies point inward
Other developers depend on this code. It can’t be plausible - it has to be right.
Encode your taste in a file.
I stopped re-explaining myself in every chat. My standards live in a global config the AI reads on every task - so every prompt inherits them.
~/.claude/CLAUDE.md - my engineering standards (real)
- Protocol-Oriented Programming is mandatory - every
service, repository & use case has a protocol.
- Clean Architecture - Domain · Data · Presentation, inward.
- Conventional Commits only - feat / fix / refactor, imperative.
- Never force-unwrap. Build before you call it "done".
Result: it writes Swift that looks like I wrote it - protocol-driven, first try, every repo.
Vague in, vague out.
Config carries the constants - your taste, your architecture. The prompt is the variable: the task itself. The detail you put in is the quality you get back.
the lazy ask
> Add caching to the network layer.
It guesses the scope, invents an approach, and edits files you never meant to touch.
the real ask
> Add an in-memory LRU image cache on fetch:
cap 50 MB · evict LRU · key by URL
actor-isolated · clear on memory warning
behind a CachePolicy protocol to swap
Don’t touch the existing retry logic.
Exactly what you meant - in your architecture, first try.
Same model. Same config. The only thing that changed was how much you told it.
Then a Claude file per project.
Global config carries my taste. A per-project file carries the guardrails - which tools the AI may run unattended in this repo. No babysitting, no surprises.
"permissions": { "allow": [
"Bash(xcodebuild:*)", // build & test
"Bash(periphery scan:*)", // dead-code linter
"Bash(git commit:*)", "Bash(git push:*)",
"WebFetch(domain:forums.developer.apple.com)"
] }
Allowlist the safe, repeatable commands - it builds, lints, and commits while you think.
Make it remember.
Most people restart from zero every session. I give it a file-based memory - one fact per file, typed, with an index it loads every time. Teach it once; it never forgets.
memory/.md
---
name: prefers-protocol-first
description: used to decide recall
metadata: { type: feedback }
---
The fact. Link related: [[other-memory]]
- user - who I am, how I work
- feedback - corrections, with the why
- project - goals & constraints
- reference - links, dashboards, tickets
MEMORY.md is the index - one line per fact, loaded every session.
Catch the insight. Promote it to a rule.
The gold is in the corrections. When something clicks - or the AI catches a sloppy habit - I capture it, then graduate the good ones into permanent config.
Trigger
“Capture this”
A reframe, a wrong assumption, or a gotcha worth keeping. Two words to flag it.
Classify
Synthesis · Pattern · Correction
Name what it is. Lands in a scratchpad, or a dedicated note for the deep ones.
Promote
Becomes a rule
Recurring? It graduates into the standards file. Today's correction is tomorrow's default.
This is the flywheel: every session leaves the next one smarter.
One word. A whole workflow.
I don’t re-type procedures. I bind them - to a keyword, or a slash command - so the long flow fires from a short trigger.
Trigger word - my real "fast" git mode
// prompt has "fast" + commit/push →
skip git diff & log inspection
one-line message from the file paths
stage → commit → push → tag, one flow
Slash commands - my iOS team plugin
/setup-dependencies onboard a repo
/create-pr-flow branch → commit → PR
// shared with the whole team -
// my setup becomes the baseline.
The hour you spend teaching it, you spend once.
A skill your iOS team
runs as one command.
A skill is a named procedure with its own instructions - written once, triggered by name. Here's one I'd give every SDK dev: add a module in our house style - clean public surface, internals hidden.
.claude/skills/scaffold-module/SKILL.md
# /scaffold-module - add an SDK module, house style
Given a <Service> name, generate and wire:
1. Public/<Service>Protocol - the only type consumers see
2. Internal/<Service> - final impl, hidden behind it
3. <Service>Error enum + Result returns (no force-unwrap)
4. register in the SDK’s public factory / DI
5. unit-test stub + a usage snippet for the README
/scaffold-module Analytics → a consumer-ready surface in your house style, identical across every SDK. Zero drift.
Where it earns its keep, every day.
Two jobs I hand it before anything else - and it's better at both than I expected. This isn't a demo trick; it's my Tuesday.
A second pair of eyes that never blinks
Point it at a diff or a gnarly function and it surfaces the force-unwrap, the off-by-one, the race, the unhandled error - the edge cases you stop seeing after the tenth read.
The test suite you keep meaning to write
It scaffolds the cases you'd skip - happy path, boundaries, failure paths - in minutes. For an SDK, those tests are the contract every consumer leans on.
The work I used to put off, it does in minutes - and I review it, like everything else.
Plan before. Audit after.
I never let it run blind on production. Plan the approach first - then a non-negotiable checklist before anything is "done."
Check 01
Build
Compile it. Zero errors, zero warnings. No exceptions.
Check 02
Wiring
Is every new type actually injected, registered, and called?
Check 03
Logic
Re-read end to end. Edge cases handled? Correct, not just green?
"It compiles" ≠ "it’s correct."
The auditor can't be the author.
An AI-built chat SDK compiled clean - zero warnings, a flawless demo. So I had it audited by reviewers that never wrote a line of it. Of 17 findings, the three that mattered were invisible until a real backend was on the other end:
Critical · network
Every message, twice
The server echoes each send back - and the SDK appended that echo as a new message. A mock never echoes, so the demo looked perfect.
Critical · data loss
Sent images vanished
After upload it kept the local temp file and dropped the real URL - the photo rendered for the sender and broke for everyone else.
Critical · concurrency
Race + endless reconnect
A data race in the socket layer and a reconnect with no backoff - one dropped connection could spin forever.
Plus 6 config flags & ports wired to nothing, and 8 leaks and duplicate calls. The audit took minutes; shipping these would’ve cost production incidents.
Make it prove it. Don’t let it guess.
A live bug has zero room for a plausible theory. My bug-report protocol forces process - no fix until the cause is shown in the code.
- Trace the root cause end to endfollow the data from trigger to symptom.
- Prove it in the codeno shown lines means no cause, only a theory.
- One targeted fixnot five "try this and see" patches.
- Uncertain? Stop and say soguessing on prod is the actual bug.
The whole talk, in six lines.
- Encode your taste in a config file.
- Give it memory - teach once.
- Capture insights → promote to rules.
- Bind workflows to triggers & skills.
- Plan, then audit - make it prove it.
- Own the output. Your name ships.
AI doesn't replace the engineer
who knows what good looks like.
It multiplies them.
Pick one thing. Today, write the first ten lines of your config file - the rules you're tired of repeating. That's where casual turns into craft.
Transcript
Every person reading this has the exact same AI I do. Same model, same price, same little box to type into. So why does it hand most people confident guesswork - and ship production code for a few of us? That gap is the whole talk. I build iOS SDKs - the libraries other teams ship their apps on - and I closed that gap not by prompting harder, but by configuring. Wherever you land with these tools, this is built for you.
01 / 17