How I Work with AI

After 20+ projects with Claude, I've figured out what works and what doesn't. This isn't theory — these are patterns I use every single day, extracted from real sessions building real software. If there's one module you should really internalize, it's this one.

Start with a clear problem, not a vague idea

The number one mistake: going to Claude and saying "build me an app." That's like walking into a restaurant and saying "make me food." You'll get something, but probably not what you wanted.

Instead, start with the problem. What are you actually trying to solve? Who's it for? What should it do?

Bad: "Build me a dashboard."
Good: "I need a dashboard where I can see email delivery stats — sent, delivered, bounced, opened — for the last 7 days. The data comes from a PostgreSQL database. I'm using Next.js and React."

The more specific you are, the better the result. Every time.

Break big things into small steps

You don't build a house by saying "make me a house." You lay the foundation, then the walls, then the roof. Software is the same.

When I built SMTPCloud Dashboard (44,000+ lines of code), I didn't ask Claude to build it all at once. I started with: set up the project. Then: create the database schema. Then: build the login page. Then: add the API for fetching stats. One piece at a time.

Each step should be something you can test and verify before moving to the next one. If something breaks, you know exactly where it broke.

Give context: "I have X, I want Y"

Claude doesn't know what you've already built unless you tell it. The magic formula is simple: here's what I have, here's what I want.

"I have a Next.js app with a PostgreSQL database. I have a users table and a campaigns table. I want to add a page that shows all campaigns for the logged-in user, sorted by date, with pagination."

That one prompt gives Claude: your tech stack, your existing data model, what you want, and how it should behave. That's a prompt that produces good code.

When stuck, describe what happened vs. what you expected

Bugs happen. Things break. When they do, don't just say "it doesn't work." That tells Claude nothing.

Instead: "I click the submit button and nothing happens. The console shows a 401 error. I expected the form data to be saved to the database and redirect me to the dashboard. Here's the error message: [paste the error]."

What happened. What you expected. Any error messages. That's the debugging formula. Claude can work with that.

Use CLAUDE.md files for persistent context

This is a game-changer most people don't know about. Almost all my projects have a CLAUDE.md file in the root directory. It's a markdown file that Claude Code reads automatically when you start a session. It contains:

- What the project is and what it does
- Tech stack and architecture decisions
- Important conventions (naming, file structure, patterns)
- Known issues or things to be careful about
- Database schema overview
- Deployment notes

Without CLAUDE.md, you have to re-explain your project every session. With it, Claude already knows the context. It's like giving a new team member a briefing document instead of making them guess what the project is about.

You're the architect, AI is the builder

This is the mindset shift that makes everything work. You don't need to know how to write a React component from scratch. But you DO need to:

- Know what you want the component to do
- Review what Claude writes and check if it makes sense
- Test whether it actually works
- Decide if the approach is right for your project

I review every piece of code Claude writes. Not line by line (I couldn't do that at first anyway), but I check: does this do what I asked? Does it follow the patterns we're using in this project? Does it work when I test it?

You are the product person, the architect, the QA tester, and the project manager. Claude is the developer who writes the code. That division of labor is extremely powerful.

The real workflow: idea to production

Here's what my actual process looks like:

1. Idea — I identify a problem that needs solving
2. Describe — I write down what the solution should look like in plain language
3. Setup — I ask Claude to scaffold the project (or I start in an existing one)
4. Build iteratively — One feature at a time, test each one
5. Debug — When things break (they will), describe the problem clearly
6. Refine — Improve UX, handle edge cases, add error handling
7. Deploy — Put it on a server where people can use it
8. Maintain — Fix bugs, add features, keep it running

Each of these steps involves conversations with Claude. It's not one prompt and done — it's a back-and-forth collaboration. A typical feature might take 5-20 messages to get right.

Prompting patterns that work

Things that consistently produce good results:

- Be specific about file paths: "In app/api/users/route.ts, add a GET endpoint that..."
- Mention your tech stack: "Using Next.js 14 with App Router, TypeScript, and Prisma"
- Reference existing patterns: "Follow the same pattern we used in the campaigns API"
- Ask for explanations when you don't understand: "Explain what this useEffect does and why we need it"
- Paste error messages in full — don't summarize them
- When asking for changes, be clear about what to keep and what to change

Prompting patterns that don't work

- "Make it better" — better how? Be specific
- "Fix all the bugs" — which bugs? What's the symptom?
- "Build me a complete SaaS" — too big, break it down
- Changing requirements mid-prompt — finish one thing, then start the next
- Not providing error messages — Claude can't read your screen
- Assuming Claude remembers previous sessions — it doesn't (unless you use CLAUDE.md)

The bottom line: working with AI is a skill, and it's different from programming. It's closer to being a great project manager than being a great coder. You need to communicate clearly, break problems down, provide context, and verify results. Master that, and you can build anything.