Teaching AI to Build Projects

People open the chat and type “write me code that filters bank transactions by category.” They get back 80 lines of code that expect a data file in a specific format, with column names the AI made up, and categories the AI invented.

They run it. It falls over. Because their bank exports an Excel file in a different structure. Different column names. And categories are a personal thing, not a generic list.

So what do people do? They improve the request. They write “write me code that filters transactions from Bank X in Excel format.” They get the same code, slightly different. It still falls over. Because it doesn’t know that in one bank’s file the amount is in column D, and in another it’s in column B.

People come to me and say “I have an idea for an app.” Then they explain for an hour. At the end of the hour, I know the idea, but I don’t know the problem. And without a problem, there’s no project.

Idea: “A personal finance tool.”
Problem: “I have 1,223 rows from 4 different credit card providers for all of 2025. I’m wasting hours manually categorizing each row. I want a tool that pulls it all in automatically and helps me categorize.”

That’s not a different phrasing of the same thing. That’s different thinking. When the problem is defined that way, every structural decision becomes simple:

• “Where do we store the data?” → In Google Sheets. Because I already work in it, and I can categorize manually from anywhere.
• “Which programming language?” → Apps Script (a language that runs inside Google Sheets, no external server needed).
• “How do we handle different column structures between providers?” → A separate code piece for each source.

If I’d started with the idea “a personal finance tool,” I would have built a full web app with a login screen, a database, a dashboard, and charts. Half a year of work. Working for 30 percent of what I actually needed.

Once you have the problem, there’s a temptation to jump straight in and ask the AI “what tool do you recommend?”. Don’t do that.

First tell it the story. How you solve this today, without AI. That story is the context that gets it to make the right decisions.

A real example: when I built a tool to generate calendar links (Google Calendar, Outlook, and a standard file for Apple and others) for events I send over WhatsApp, the story was:

From that story, the AI figured out:

• This doesn’t need to be a cloud app with users and sign-up. I’m the only one who’ll use it.
• It doesn’t need a database. One-off event, no history to store.
• It needs to be quick to open, so a single HTML file I save on my desktop.
• It should include a “copy text for WhatsApp” button, because that’s where the flow ends.

If I’d asked without the story, it would have suggested a full app with a cloud server. Three days of work. Instead of a half-hour HTML page.

A technical chapter, but a critical one. Without the right environment, you’re copying code back and forth between the chat and your files by hand. Slow, error-prone, and the AI can’t see the rest of the code you already have.

My environment, and the environment of everyone I coach:

• VS Code: the most popular code editor in the world. Free. Runs on Windows, Mac, Linux.
• Claude Code: an extension for VS Code that lets the AI read and update your files directly. No copy-paste.
• Plan Mode: a mode inside Claude Code that tells the AI “plan, don’t write code yet.” Activate with Shift+Tab twice. That’s the starting mode for every conversation I have.

With that environment, the conversation shifts. Instead of “write me code to categorize transactions,” I say “look at all the files in the FinanceTracker folder. Tell me what you see.” The AI reads. It says: “You have 6 code files, there’s an import from Bank X where the amount is in column D, there’s a manual categorization, there’s a dashboard that’s calculated from the categories.”

Now, when I ask for a new feature, it builds on my code. Not generic code.

You’re in Plan Mode. The problem is defined. The story is told. Now the first question:

The AI comes back with a plan. For example, for a podcast that assembles video from 2 cameras:

1. A main file that orchestrates the whole build, with separate functions for transcription, segment detection, and stitching.
2. A recordings folder with the Zoom files (one camera on the active speaker and one on both speakers together).
3. A temp folder for prep files (so they don’t get recomputed every time).
4. An output folder for each episode.
5. Work order: prep files once, then build episode by episode, then final stitch.

You read the plan. You revise. “Wait, why not move the transcription to a separate file?” Or “the pre-computed files should be saved between runs, not just within a run.” You update the plan. Before there’s a single line of code.

In my podcast, the plan included 3 decisions that saved me days of work:

• Prep the main-camera file at the right frame rate once and save it, instead of redoing that on every build.
• Cut on whole frame numbers, not on fractional seconds. Tiny difference, but it stacks up with lots of cuts.
• Refill gaps after filtering out short scenes.

Those three decisions prevented a desync (audio not lining up with video) that would have shown up anyway if I’d started coding right away. The hour I spent planning saved a week of debugging.

The natural instinct in planning: “and of course there’ll also be PDF export, social sharing, recurring events, and…”. Stop.

Ask yourself: “What’s the one feature without which this project is worth nothing?” That’s the core. Everything else isn’t essential, and so we don’t build it now.

In my calendar-links tool, the core was:

• A form for event details (title, date, time).
• Output: a single Google Calendar link.

That’s it. Without it, it’s worthless. Everything else, later:

• Outlook link? Later.
• Yahoo link? Later.
• Apple Calendar file? Later.
• Copy-to-WhatsApp button? Later.

When I built just the core, I knew within 20 minutes that it worked. Then I added Outlook (10 minutes). Then the Apple Calendar file (15 minutes). Every extra feature was built on existing infrastructure. Quick to add.

If I’d asked for everything at once, the AI would have written 400 lines, and every bug would have meant searching through 400 lines.

Even after you’ve cut down to the core, there’s a temptation to ask for the whole core in one shot. “Write me the entire main file that builds the episode.” You’ll get 500 lines. You’ll run it. It’ll fall over in 3 different places. You’ll try to fix. The AI will update the whole file. A line that worked will stop working. A fix of a fix of a fix.

Instead, build in pieces.

Example from my podcast: one episode is 44 minutes of video. Building the episode takes 25 minutes. If I’d built the whole episode on every change, a day would have meant 4 to 5 attempts. Instead, I split it into pieces:

• Piece 1: 13.3 minutes (opening content).
• Piece 2: 2.7 minutes (after a freeze on the Zoom call).
• Piece 2b: 6 minutes (using only the “both speakers” camera, because the active-speaker camera dropped out).
• Piece 3: 24.7 minutes (through to the end).

Each piece was built separately. A change in piece 2 meant rebuilding 2 minutes only. Once everything was approved, a final stitch combined the four into the full episode.

In code too: “Let’s start with the transcription function. Just that. We’ll try it on one file. If it works, we’ll continue.”

This is probably the lesson that took me the longest to internalize. And I still catch myself forgetting it sometimes.

One conversation = one chat thread with the AI. Within a single conversation, the AI has memory of what you talked about. The longer the conversation, the more that memory gets overloaded, and the AI starts forgetting constraints you set at the beginning.

My method:

• Conversation 1, planning. In Plan Mode. Discuss the problem, the story, the core, the project structure. At the end, I have a written and approved plan.
• Conversation 2, execution. A brand new conversation (start from scratch). Paste in the approved plan. The AI starts writing code with a clean head, full focus on writing code only.

Why does this matter? Because in a long conversation, the AI starts to drift. It remembers the discussion about the core, but also the 10 features you dropped, and also the doubt you had about which tool to pick. In conversation 2, it doesn’t have any of that history. Just the final conclusions.

Also: every time you move to a significant new section of the project, start a new conversation. With a summary of where you are.

This is the most important chapter in the guide. If you miss it, none of the rest will help.

The AI will tell you “fixed” without fixing. “Added the function” without adding. “This should work now” without checking. If you don’t know how to spot it, you’ll get deliverables that don’t exist, and you won’t understand why the project is stuck.

A story that happened to me recently: I asked the AI “fix the bug in my main file, it crashes on line 245.” It answered: “Fixed. Added handling for the edge case of an empty piece. The code should run without errors now.”

I ran it. Same error. “What exactly did you fix?” I asked. “I added a null check before reading the frame.” I asked: “Open the file and show me the new line.” It said: “One moment. I’m checking. Indeed, the change wasn’t applied to the file.”

It described a fix. It didn’t make one.

Five reasons this happens:

• Path of least resistance. When a task is complex, there’s a pull to say “done” and move on.
• No verification step. If you didn’t ask to see it, it won’t offer.
• Describing is easier than doing. Writing the code is real work. Describing the code is seconds.
• Forgetting what you defined. In long conversations, it loses the thread.
• Synthetic optimism. A pull to sound helpful even when it didn’t succeed.

Five questions to catch it fast:

1. “Open the file and show me the section you updated.”
2. “Run the code and show me the full output.”
3. “What didn’t you check? What did you say ‘yes’ to without actually doing?”
4. “If I opened the file right now, what new lines would I see?”
5. “Stop. Open the file first, then tell me again what changed.”

You fixed a complex problem. Hours of diagnosing. You understood the cause. The code works. Half the work is still ahead of you.

If you didn’t document the lesson, the problem will come back. In the next project. Or in the next episode of the same project. Or with the AI in a new conversation, because it doesn’t remember the fix.

For me, after solving the 3 desync problems in episode 1 of the podcast, I created a file called:

In it I documented, in a structured format:

• The three problems that caused the desync (each one separately).
• The symptom of each (how to recognize it).
• The fix for each (with the exact code).
• A diagnosis table: “Desync across the whole episode?” → sync configuration is wrong. “In sync up to a point and then a jump?” → gap created after filtering scenes.

In episode 2 of the podcast, the first thing I did in a new conversation with the AI was: “Before we start, read this file. It documents problems we’ve already solved. Don’t repeat them.”

Episode 2, no desync. Not even a second. Because the AI knew from the start how to avoid those traps.

How to do this in every project:

• At the end of every big bug you fixed, tell the AI: “Add this lesson to the project’s lessons file. Format: problem, symptom, cause, fix.”
• At the start of every new conversation: “Read the lessons file before we start.”
• If the AI repeats a bug you already documented, it means it didn’t read. Tell it to read.