Working with AI coding tools

Before You Open a File

Before you write a single line of code, the most important decision you can make is where you're working from. The AI coding tool is folder-aware: it reads a PROJECT.md file from your project root and uses it as a permanent briefing. This is how you stop repeating yourself across sessions.

Set up one folder per project. Name it clearly. Inside it, drop a PROJECT.md that tells your AI coding tool: what this project is, what tech stack it uses, what the brand looks and sounds like, and any non-negotiable rules. Then every new session starts with your AI coding tool already oriented — no re-explaining.

The session discipline that saves hours

• One project per client or product. One session per task.
• Name your sessions descriptively ("build contact section" not "session 3").
• Use /compact when a session runs long — it summarizes earlier context to free space, so verify that important constraints remain.
• When a task is done, start a fresh session. Don't sprawl.

Do not repeat setup without reason. A reviewed starter template can reduce boilerplate for folder structure, PROJECT.md, and configuration files. The 8-step workflow that works:

1. Copy the template
2. Install dependencies
3. Build one real page (not placeholder)
4. Add sections top-down
5. Add animations last
6. Test at half speed to catch timing issues
7. Test mobile at 375px
8. Deploy

The biggest difference between a good camp week and a frustrating one: spend 30% of your time on the first 3 seconds of the experience. The load sequence sets the tone for everything that follows.

Choosing the Right Model

AI coding tools come in three tiers. Using the wrong one is like paying a consultant's hourly rate to fold laundry.

Opus — for thinking. Use it when you need taste, judgment, or architectural decisions. Multi-agent competitions, copy strategy, hard debugging, synthesis. If you're deciding what to build or how, use Opus.

Sonnet — for building. Once you know what to do, Sonnet executes it. Routine code edits, find-and-replace, builds, file cleanup, git commits, installs. This should be your default for about 80% of your session time.

Haiku — for bounded, lower-cost work such as simple lookups, formatting, and repetitive tasks. Check current model availability and pricing before choosing by cost.

The practical pattern most professionals use

Start a session in Opus to do the strategy and architecture. Once you've decided what to build, switch:

/model

Switch back to Opus if you hit another decision point. You get Opus thinking and Sonnet execution — the best of both.

Quick decision rule

• Need judgment or taste? → Opus
• Need to execute a clear plan? → Sonnet
• Need to repeat something simple? → Haiku
• Unrelated history no longer helping? → Compact or start fresh

Working Without Wasting Money

Every message you send in a long session re-sends the entire conversation history. That means a session that's 40 turns deep costs twice what a 20-turn session costs — for the same work.

The three habits that fix this

1. Use /compact deliberately. When earlier detail is no longer helping, /compact summarizes it to free context. Because summaries are lossy, check that critical constraints remain.

2. Start fresh sessions aggressively. "But I'll lose context" — you won't, if you have a good PROJECT.md and you summarize the handoff in one message at the start of the new session. "We just finished the hero section. It's using GSAP with clip-path reveals. Now build the about section." That's all you need.

3. Don't spawn subagents for simple tasks. Subagents are powerful but expensive. Before spinning one up, ask: could a grep or a direct question to the main session answer this? If yes, do that. Subagents earn their cost when you need genuine parallelism — three things happening simultaneously that would each take 10+ minutes.

Model routing rule of thumb

• No judgment needed → Haiku or Sonnet
• No parallelism benefit → no subagent
• At a clean task boundary → consider a fresh session

Multiple agents generally use more tokens than one. Reserve comparison runs for work where independent alternatives materially improve the decision.

How to Not Get Stuck in Loops

Your AI coding tool will sometimes get stuck. It'll try the same fix twice, add the same import three times, or spiral into increasingly complex solutions for a simple problem. This is the most frustrating thing about working with AI — and it's almost always preventable.

Rule 1: Call it out immediately. The moment your AI coding tool repeats a fix it already tried, say so explicitly: "You just tried that. It didn't work. Stop and think about why before trying again." This breaks the loop. Don't wait for the third attempt.

Rule 2: Use a lower-cost model for bounded debugging checks. When the task is repetitive and low risk, a cheaper current model may be sufficient. Escalate when the reasoning, security, or production impact requires it.

Rule 3: Evidence before action. Before your AI coding tool theorizes about what's wrong, make it read the actual evidence. "Read the error log first. Then tell me what you think is happening." This single habit eliminates half of all wasted debugging cycles. Read → theorize → act. Never act → theorize → read.

Rule 4: Don't let your AI coding tool install infrastructure to solve simple problems. If your AI coding tool suggests installing a new service, configuring a server, or adding a networking layer — pause. The answer to most problems is simpler than the solution your AI coding tool proposes when it's stuck. The answer is usually one setting, one command, or one file change.

Running Multi-Agent Competitions

The most powerful thing AI coding tools can do isn't run one agent. It's run three agents simultaneously with fundamentally different worldviews — and then synthesize what they found.

Most people approach this wrong. They say: "Agent A, be creative. Agent B, be practical. Agent C, be brief." That produces three flavors of the same answer.

The recipe that works

1. Give them different professions, not different moods. These three always produce something useful:

• A plain-language writer (medical/government background) — protects the reader's understanding
• A product designer (audit and cut philosophy) — protects the reader's time
• A conversion copywriter (emotional state modeler) — protects the reader's emotions

These aren't moods. These are professions with conflicting worldviews. They cannot all be right — and where they disagree is where the insight lives.

2. Give every agent the exact same source material verbatim. No summaries, no interpretations. The same raw input, word for word.

3. Force them to declare reasoning AND output separately. "First explain your thinking. Then write the deliverable." Otherwise you get output without understanding why.

4. Ask for distinct alternatives. Framing the task as a comparison can encourage meaningfully different approaches.

5. Pre-bias one agent toward the heretical answer. "Your job is to cut everything that doesn't need to be there. Be ruthless." The most interesting insights often come from the agent that was told to destroy things.

6. Synthesize, don't pick a winner. The best output almost never comes from one agent wholesale. It comes from combining the structural clarity of one, the emotional accuracy of another, and the ruthless cuts of the third.

When you're not sure how to set up the competition lenses, ask your AI coding tool: "What three conflicting professional worldviews would produce the most interesting tension for this problem?"

When Things Break

Things will appear broken that aren't. Understanding why saves hours of anxiety.

The four-copy problem. When you're developing an app, four versions can exist simultaneously: the source code, the debug build, the installed version, and the browser/WebView cache. If you're looking at the wrong one, you'll spend an hour "fixing" something that was already fixed. The solution: always develop in hot-reload mode (the dev server). It updates in seconds and you always know you're looking at current code. Production builds are only for releases.

Add a build stamp. Put the git commit hash and build time somewhere visible in your app — a small line in the corner, a console.log, anywhere. When you're confused about which version you're looking at, you'll know immediately.

Permission prompts — which ones to trust. AI coding tools will ask for permission before taking certain actions. Some prompts are correct and you should approve them. Some are worth pausing on. Read-only listings are usually low risk, but review every permission in context. Inspect project scripts before pre-allowing package commands, and keep prompts enabled for installs, writes, moves, deletions, credentials, deployments, and other side effects.

When it looks totally broken: check the obvious things first. Is it the right file? Is there a cached version? Did the build actually run? Read the error message word for word before theorizing.

Stop Wasting Time

The single most effective habit change you can make during your week at AI Boot Camp Pai: commit every time something works.

git commit -m "known good"
git tag known-good

When it breaks ten minutes later (and it will), you don't need to remember what changed. You run:

git diff known-good

And you see exactly what changed. What would have been an hour of detective work becomes a two-minute read.

"Done" means verified in the real app. Not "it compiles." Not "it looks right in the editor." Not "your AI coding tool said it should work." Done means you ran it, saw it, confirmed it. Until then, it's just a theory.

One source of truth. When you have a reference document, a design file, an approved copy — build to that artifact. Don't reinvent it from memory. Don't summarize it and build from the summary. Use the actual thing.

Separate hardware problems from software problems. If something is mysteriously broken and the code looks fine, consider whether the problem might not be in the code at all. A dying drive, a bad cable, a network issue — these produce symptoms that look like software bugs and waste days. If you can't explain why the code should fail, look outside the code.

20 Practical Lessons

A reference card. Pin it above your desk for the week.