First Projects

Two Different Starts

A product manager at a retail company decided to try vibe coding. He’d heard about people building tools without programming knowledge and wanted in. His first project: a customer analytics dashboard that would pull data from their CRM, combine it with transaction history, and generate real-time insights with machine learning predictions.

He spent a weekend asking AI to generate code. The AI produced hundreds of lines he didn’t understand. When he tried to run it, errors appeared. He described the errors to the AI. More code. More errors. By Sunday evening, he had nothing working and a growing conviction that vibe coding was oversold hype.

A week later, his colleague tried vibe coding. She had a simpler goal: every Friday she manually copied data from one spreadsheet format into another for a weekly report. It took ninety minutes. She asked AI to build a tool that read her CSV file and reformatted it. The first version worked within an hour. She spent another thirty minutes handling edge cases. By afternoon, she had a tool that did in seconds what had taken her ninety minutes.

Same AI. Same organization. Same level of technical expertise. Completely different outcomes. The difference wasn’t aptitude or luck—it was project selection.

Chapter 20 introduced vibe coding and when it applies. This chapter shows how to succeed with your first project—the practical steps that separate the colleague who built something useful from the one who wasted a weekend.

Choosing Your First Project

Project selection is the single biggest determinant of first-project success. Pick well and you’ll build something useful while learning the process. Pick poorly and you’ll struggle, fail, and possibly conclude that vibe coding doesn’t work.

The Selection Framework

Your first project should meet four criteria:

Solve a real problem. Not a theoretical exercise. Not something that might be useful someday. A real frustration you face regularly. Real problems motivate the persistence that vibe coding requires. Theoretical projects get abandoned when they become difficult.

Have clear success criteria. You should know exactly when it works. “The tool reads my data file and produces output in this specific format” is clear. “The tool helps with data analysis” is vague. Clear criteria enable testing. Vague criteria make everything feel incomplete.

Stay bounded in scope. Definable beginning and end. First projects should take hours, not weeks. You should be able to describe the complete functionality in one or two paragraphs. If you need a requirements document, the scope is too large for a first project.

Use data you understand. Your first project should work with data or processes you know deeply. When something goes wrong—and something will go wrong—your domain knowledge helps you identify whether the problem is with the tool or the test case. Working with unfamiliar data compounds debugging difficulty.

Red Flags to Avoid

Certain project types consistently fail as first attempts:

“It should work like [commercial software].” Commercial software represents years of development by professional teams. Recreating significant functionality is beyond vibe coding’s sweet spot. Your tool should solve one specific problem, not replicate a product.

“It needs to integrate with [enterprise system].” API integrations add complexity that derails first projects. Authentication, error handling, rate limits, data format variations—each integration point multiplies difficulty. Start with local files and manual data exports.

“It should handle [edge cases] automatically.” Edge case handling is where projects balloon. Your first project can have manual workarounds for unusual cases. Perfection is the enemy of getting something working.

“Users will be [people other than you].” Building for yourself means you understand the requirements perfectly and can iterate instantly. Building for others requires coordination, documentation, and handling their specific needs. Save multi-user projects for later.

Good First Projects by Role

Different roles face different tedious tasks. Here are starting points:

Analysts: Data transformation or validation. Converting between formats. Identifying duplicates or anomalies. Generating summary statistics. These projects have clear inputs, clear outputs, and you can verify correctness easily.

Managers: Report generation or status aggregation. Combining updates from multiple sources into a single summary. Calculating metrics you track regularly. Formatting information for distribution. You know what the output should look like.

Executives: Dashboard creation or briefing automation. Pulling key metrics into one view. Generating morning summaries. Tracking changes in data you monitor. Start simpler than you think—a useful daily summary beats an ambitious dashboard that never works.

The Conversation Pattern

Vibe coding happens through conversation with AI. How you structure that conversation significantly affects your results.

Phase 1: Set Context

Begin by establishing who you are and what you’re trying to accomplish:

“I’m not a programmer. I work in operations and spend time every week manually copying data between spreadsheets. I want to build a simple tool that automates part of this process.”

This context helps the AI calibrate its responses. Without it, you might get overly technical explanations or solutions that assume programming knowledge you don’t have.

Phase 2: Request One Thing at a Time

Don’t ask for everything at once. Start with the core functionality:

“I have a CSV file with columns for date, customer name, and order amount. I want a tool that reads this file and creates a summary showing total orders by customer.”

This single, clear request is achievable. Once it works, you can add capabilities incrementally.

Compare to a problematic request:

“Write a Python script that reads CSV files, processes them with error handling, validates data formats, generates summaries, and emails reports automatically.”

This asks for everything at once. The AI will generate code, but debugging becomes nearly impossible because problems could be in any component.

Phase 3: Describe Outcomes, Not Implementation

You might be tempted to use technical language you’ve picked up. Resist this.

Less effective: “Write a Python script using pandas to read the CSV with exception handling for file not found errors.”

More effective: “I want to read data from this CSV file and count how many orders each customer has. If the file doesn’t exist, tell me instead of crashing.”

Describe what you want to happen, not how to implement it. The AI knows implementation. You know outcomes.

Phase 4: Test and Give Specific Feedback

After each AI response, test immediately. Don’t wait until you’ve accumulated multiple features.

When something doesn’t work, describe specifically what happened:

Less effective: “It’s not working.”

More effective: “When I run the script with my test file, I get this error message: [paste error]. The file exists and has data in it.”

Specific feedback leads to specific fixes. Vague feedback leads to guessing.

The Loop in Practice

A typical vibe coding conversation looks like:

You describe the initial capability
AI generates code
You run it and report results
If it works, you request the next capability
If it fails, you describe the specific failure
AI provides fixes
Repeat until the tool works

Most successful projects require three to five full cycles of this loop. Expecting perfection on the first try sets you up for frustration.

Building Incrementally

The instinct is to build everything at once. Resist it. Incremental building is faster, less frustrating, and produces better results.

The Minimal First Step

Your first working version should be embarrassingly simple. If your goal is a weekly report generator, your first version might just read one file and print its contents. That’s fine. Getting something working—anything working—builds confidence and understanding.

Each version should be fully testable before moving to the next. You should be able to say definitively: “Version 1 works correctly.” Then build Version 2 from that solid foundation.

The Expansion Pattern

A typical progression:

Version 1: Core functionality only. Does the one essential thing, ignoring everything else.

Version 2: Add the most important enhancement. Whatever you wished Version 1 could do, add that.

Version 3: Handle common edge cases. The obvious things that break in real use.

Version 4: Polish and usability. Better formatting, clearer output, convenience features.

Each version should work completely before starting the next. This isn’t just about managing complexity—it’s about maintaining motivation. Working tools, however limited, feel like progress. Half-finished ambitious tools feel like failure.

When to Stop Expanding

Feature creep kills projects. Know when to stop:

The tool does what you need. It doesn’t need to do everything possible, just what you actually require.

Marginal improvements aren’t worth the effort. When the next feature would take two hours but save five minutes per use, the math stops working.

Complexity is becoming unmanageable. When you can no longer keep the whole tool in your head, adding more creates fragility.

Stop before perfection. A tool that solves 80% of your problem and actually works beats a tool that would solve 100% but never gets finished.

The Temptation of “Just One More Thing”

The most dangerous moment in a first project comes when you have something working. The tool does what you originally wanted. You should stop. Instead, you think: “While I’m here, I could also add…”

This thinking has destroyed more projects than technical difficulty. Each “one more thing” interacts with existing functionality. Each addition creates new edge cases. What started as a simple tool becomes a fragile mess that breaks in unexpected ways.

Set a boundary before you start: “This project is complete when it does X.” When it does X, stop. Your second project can be more ambitious. Your first project should be finished.

Testing Without Technical Skills

You can’t read code well enough to know if it’s correct. That’s fine. You can test behavior systematically.

Compare to Known Answers

The most reliable test is running your tool on data where you know the correct answer. If your tool calculates totals, create test data where you’ve calculated the total manually. Does the tool match your manual calculation?

This seems obvious but people skip it. They assume the code is correct because it runs without errors. Running without errors means the code executes—not that it produces correct results.

Verify Outputs Make Sense

Even without known answers, you can sanity-check results:

Are the numbers in reasonable ranges?
Do totals actually sum correctly?
Are there obvious missing items or duplicates?
Does the output format match what you expected?

Your domain expertise is valuable here. You know what reasonable data looks like in your field. Use that knowledge.

Test Edge Cases

Edge cases are unusual inputs that reveal problems:

Empty inputs. What happens with no data? Most scripts crash without graceful handling.

Malformed data. Missing fields, wrong formats, unexpected characters. Real data is messy.

Boundary conditions. Very large files, very small numbers, unusual dates.

You don’t need to test exhaustively. But testing a few edge cases catches many problems before they surprise you in real use.

When Something Fails

Debugging is where non-programmers often give up. But effective debugging is mostly about clear communication:

Describe the symptom precisely. “When I run the script with this file, I see this error message.” Not “it crashed.”

Provide the input that caused the problem. “Here’s the specific file (or sample of it) that causes the issue.”

Compare expected vs. actual. “I expected it to produce a summary with three rows. Instead it produced two rows and this error.”

With this information, the AI can usually identify and fix the problem. Without it, you’re both guessing.

Common First Project Patterns

Certain project types work well as first attempts. Here are three patterns with guidance for each.

Data Transformation

What it is: Take data in one format, produce it in another. CSV to formatted report. Multiple files into one summary. Raw data to cleaned data.

Why it works well: Clear input, clear output, easily testable. You can verify every transformation by inspection.

Typical starting prompt: “I have a CSV file with columns [list them]. I want to create an output file that [describe the transformation].”

Common challenges: Date format variations, handling missing values, special characters in text fields.

Report Generation

What it is: Combine information from multiple sources into a formatted output. Weekly summaries, status reports, metric calculations.

Why it works well: You know exactly what the report should look like. Testing is straightforward comparison.

Typical starting prompt: “Every week I create a report that includes [describe content]. I want to automate creating this report from [describe sources].”

Common challenges: Source format variations week to week, calculating percentages correctly, formatting for readability.

Simple Automation

What it is: Tasks you do repeatedly that follow patterns. Organizing files, batch renaming, scheduled data collection.

Why it works well: Repetition means you understand the task thoroughly. Automation provides immediate time savings.

Typical starting prompt: “Every day I [describe repeated task]. I want this to happen automatically.”

Common challenges: Handling exceptions to the pattern, error notification when something fails.

Common Objections

“I tried and got error messages I don’t understand.”

This is normal. You don’t need to understand error messages—you need to communicate them to the AI. Copy the error message exactly. Describe what you were trying to do. Ask the AI to explain what went wrong in plain language. The AI can translate technical errors into understandable explanations.

“It generated code but I don’t know if it’s safe to run.”

For personal tools working on local files, risk is limited. You can’t break your computer by running a Python script that processes spreadsheets. If you’re worried, ask the AI: “Before I run this, explain in simple terms what it will do to my files.” For anything involving network access or system changes, extra caution is warranted.

“It works on my test data but fails on real data.”

Real data is messier than test data. This is actually a sign you’re making progress—you’ve moved from “doesn’t work at all” to “works in some cases.” Identify specific rows or records that fail. Ask the AI to handle those cases. This is normal iteration, not failure.

“I keep going in circles without making progress.”

This happens when the problem is too complex for your current skill level, or the approach is fundamentally flawed. Try breaking the problem into smaller pieces. Or step back: is this the right first project? Sometimes the answer is to simplify scope rather than push through.

Your Monday Morning Action Item

This week, have your first vibe coding conversation:

Step 1: Identify your project. One tedious task you do regularly. Clear input, clear output. You’ll know when it works.

Step 2: Write the description. One paragraph explaining what you want. What does the tool receive? What should it produce?

Step 3: Start the conversation. Open an AI coding assistant. Provide context: “I’m not a programmer. I want to build a simple tool.” Then describe your project.

Step 4: Run what you get. Don’t aim for completion—aim for learning. See what the AI produces. Try to run it. Report what happens.

The goal isn’t a finished tool by Friday. The goal is experiencing the vibe coding loop: describe, generate, test, refine. Everything in this chapter becomes concrete once you’ve done it once.

Your first conversation might take thirty minutes. You might end with something partially working, or you might end with errors you don’t understand yet. Either outcome teaches you more than reading another chapter. Start before you feel ready.