[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-75454":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":10,"languages":10,"totalLinesOfCode":10,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":16,"stars30d":17,"stars90d":15,"forks30d":15,"starsTrendScore":18,"compositeScore":19,"rankGlobal":10,"rankLanguage":10,"license":20,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":23,"hasPages":21,"topics":24,"createdAt":10,"pushedAt":10,"updatedAt":33,"readmeContent":34,"aiSummary":35,"trendingCount":15,"starSnapshotCount":15,"syncStatus":14,"lastSyncTime":36,"discoverSource":37},75454,"how-to-vibe-code","ai-for-developers\u002Fhow-to-vibe-code","ai-for-developers","A complete  vibe coding guide with python as a complete beginner.","",null,121,11,3,2,0,4,7,12,3.24,"Creative Commons Zero v1.0 Universal",false,"main",true,[25,26,27,28,29,30,31,32],"ebook","vibe-code","vibe-coding","vibe-coding-book","vibe-coding-guide","vibe-coding-python","vibe-coding-tips","vibecoding","2026-06-12 02:03:34","# How to Start Vibe Coding\n### A Complete Guide with Python\n\n> *\"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.\"* — Andrej Karpathy, February 2025\n\nVibe coding is the art of building software by conversing with an AI model. You describe what you want, the AI writes the code, you run it, and you iterate — often without reading every line the AI produces. It sounds irresponsible. It can be. But when done with discipline, it is also the single biggest multiplier of individual output in the history of software, and it is transforming who gets to build things.\n\nThis guide will take you from zero to productive vibe coder with Python. It is long on purpose. Skim the sections you know, read the ones you don't.\n\n---\n\n## Table of Contents\n\n1. [What Vibe Coding Actually Is](#1-what-vibe-coding-actually-is)\n2. [Mindset and Philosophy](#2-mindset-and-philosophy)\n3. [Prerequisites: What You Actually Need to Know](#3-prerequisites-what-you-actually-need-to-know)\n4. [Setting Up Your Environment](#4-setting-up-your-environment)\n5. [Choosing Your AI Coding Tools](#5-choosing-your-ai-coding-tools)\n6. [The Vibe Coding Workflow](#6-the-vibe-coding-workflow)\n7. [Prompting: The Core Skill](#7-prompting-the-core-skill)\n8. [Your First Vibe-Coded Project (Walkthrough)](#8-your-first-vibe-coded-project-walkthrough)\n9. [Debugging With AI](#9-debugging-with-ai)\n10. [Version Control and Safety Nets](#10-version-control-and-safety-nets)\n11. [Security and Secrets](#11-security-and-secrets)\n12. [When Vibe Coding Works, and When It Doesn't](#12-when-vibe-coding-works-and-when-it-doesnt)\n13. [Common Pitfalls and How to Avoid Them](#13-common-pitfalls-and-how-to-avoid-them)\n14. [Scaling From Toys to Real Software](#14-scaling-from-toys-to-real-software)\n15. [A 30-Day Practice Plan](#15-a-30-day-practice-plan)\n16. [Resources and Further Reading](#16-resources-and-further-reading)\n\n---\n\n## 1. What Vibe Coding Actually Is\n\nThe term \"vibe coding\" was coined by Andrej Karpathy (co-founder of OpenAI, former director of AI at Tesla) in a tweet in early 2025. The core idea: instead of *writing* code, you *describe* code. The AI writes it. You read the output, try it, and if something breaks, you paste the error back and ask the AI to fix it.\n\n**What makes it different from just \"using AI to help code\":**\n\n- **Intent over syntax.** You think in terms of what the program should *do*, not how each line should be written.\n- **Iteration over planning.** You don't draw up architecture diagrams. You build something ugly, run it, and shape it through dialogue.\n- **Trust, but verify.** You let the AI drive most of the keystrokes. Your job is to steer, test, and course-correct.\n- **The diff is the conversation.** Your \"source of truth\" isn't the code — it's the sequence of prompts that produced the code.\n\n### A Spectrum, Not a Binary\n\nVibe coding is a spectrum:\n\n| Style | Description | Good for |\n|---|---|---|\n| **Pure vibe** | You never read the code. You just check if the app works. | Throwaway scripts, personal tools, prototypes |\n| **Supervised vibe** | AI writes, you skim and approve. You catch obvious issues. | Weekend projects, side apps, exploration |\n| **Collaborative vibe** | AI writes, you read carefully, ask for changes, refactor together. | Real products, learning, anything shipped to users |\n| **AI-assisted** | You write most of the code. AI helps with snippets and boilerplate. | Production systems, security-critical code |\n\nA healthy vibe coder fluidly moves up and down this spectrum depending on what they're building. A birthday card generator for their niece? Pure vibe. A payment processing backend? Collaborative at best, and frankly you should probably read every line.\n\n### Why Python?\n\nPython is the best language to vibe code in, and it's not close:\n\n- **AI models are fluent in it.** Python is the single most-represented language in AI training data. Models write better Python than any other language.\n- **Readable by design.** When you do read the code the AI wrote, Python doesn't punish you. It looks close to pseudocode.\n- **Batteries included.** The standard library and PyPI mean \"there's a package for that\" is almost always true.\n- **Forgiving.** Dynamic typing, interpreted execution, a REPL. You can iterate fast.\n- **Ubiquitous.** Data, ML, scripting, backends, automation, scraping, games, CLIs — it's everywhere.\n\n---\n\n## 2. Mindset and Philosophy\n\nBefore any setup, get your head right. The tools are easy. The mindset is the hard part.\n\n### Embrace \"Good Enough\"\n\nThe single biggest unlock in vibe coding is accepting that code doesn't have to be elegant to be useful. A working 80-line script that solves your problem beats a beautiful 30-line script that you never finish. Shipping beats perfecting.\n\n### Think in Outputs, Not Code\n\nBefore asking the AI for anything, ask yourself: *what do I want to see when this works?* A file on disk? A webpage at localhost:8000? A number printed to the terminal? A CSV with five columns? The clearer your mental image of the output, the better your prompts will be.\n\n### Talk to the AI Like a Sharp but Literal Intern\n\nThe AI is very capable but has no context about your project unless you give it. Over-explain. Paste error messages in full. Show it the file structure. Describe the user. The best vibe coders write prompts that read like mini-briefs: *who* is this for, *what* should it do, *what* does success look like, *what* are the constraints.\n\n### Read the Code Eventually\n\nPure vibe is fine for a weekend. But if you want to grow as an engineer, circle back. After a session, skim what the AI wrote. Ask it to explain any line you don't understand. This is how you level up while shipping.\n\n### Keep Your Sense of Smell\n\nEven if you don't read every line, develop instincts for when something is *off*. Clues:\n- The AI adds dependencies you've never heard of\n- The code is suspiciously long for a simple task\n- It hallucinates function names or APIs (easy to spot — they don't exist when you run it)\n- It silently ignores parts of your request\n- It's doing something security-sensitive (auth, payments, file deletion) without you asking carefully\n\n---\n\n## 3. Prerequisites: What You Actually Need to Know\n\nYou do not need to be a programmer to vibe code. You do need *some* foundation, or you will drown in errors you can't interpret. Here's the minimum.\n\n### Concepts (not skills — just awareness)\n\n- **What a file is.** Where it lives on disk. What extensions mean.\n- **What a terminal\u002Fcommand line is.** You will type commands into one.\n- **What a script is.** A file you run top to bottom.\n- **What a function is.** A named chunk of code you can call.\n- **What an error looks like.** Red text is information, not a failure of the universe.\n- **What a package is.** Code someone else wrote that you can install and use.\n\n### Python-Specific Minimum\n\nYou don't need to master Python before starting. But being able to read it helps. Can you roughly interpret this?\n\n```python\ndef greet(name):\n    if name:\n        print(f\"Hello, {name}!\")\n    else:\n        print(\"Hello, stranger!\")\n\ngreet(\"Alice\")\n```\n\nIf yes, you're set. If no, spend two hours on a free intro (Automate the Boring Stuff with Python, or Python in freeCodeCamp's 4-hour video). Come back. You'll be fine.\n\n### Terminal Minimum\n\nBe able to:\n- Open a terminal on your OS\n- Change directory with `cd foldername`\n- List files with `ls` (macOS\u002FLinux) or `dir` (Windows)\n- Run a Python file with `python filename.py`\n- Install a package with `pip install packagename`\n\nThat's it. The AI can guide you through the rest.\n\n---\n\n## 4. Setting Up Your Environment\n\nSkip this section if you already code. Otherwise, do this once and never think about it again.\n\n### Step 1: Install Python\n\nGo to [python.org\u002Fdownloads](https:\u002F\u002Fwww.python.org\u002Fdownloads\u002F). Download the latest stable Python (3.12 or later). Install it. **On Windows, check the box that says \"Add Python to PATH\"** — this is the single most common setup mistake.\n\nVerify:\n\n```bash\npython --version\n# or on some systems\npython3 --version\n```\n\nYou should see something like `Python 3.12.x`.\n\n### Step 2: Install a Code Editor\n\nYou need a place to see and edit code. The standard choice is **Visual Studio Code** (free, from Microsoft). Download from [code.visualstudio.com](https:\u002F\u002Fcode.visualstudio.com\u002F). Install it. Open it. Install the \"Python\" extension from Microsoft when it prompts you.\n\nAlternatives worth knowing about:\n- **Cursor** — a fork of VS Code with AI baked in deeply. Excellent for vibe coding.\n- **Windsurf** — similar philosophy, different flavor.\n- **Zed** — fast, modern editor with AI features.\n\nFor your first week, VS Code is totally fine. You can graduate to Cursor once you know what you like.\n\n### Step 3: Make a Projects Folder\n\nCreate a folder somewhere sensible:\n\n```bash\nmkdir ~\u002Fcode\ncd ~\u002Fcode\n```\n\nThis is where all your vibe-coded projects will live. Keep it tidy. Every project gets its own subfolder.\n\n### Step 4: Learn the Virtual Environment Habit\n\nEvery Python project should have its own isolated environment. This prevents \"package X version Y breaks package Z\" hell. For each new project:\n\n```bash\nmkdir my-project\ncd my-project\npython -m venv .venv\n\n# Activate it:\n# macOS\u002FLinux:\nsource .venv\u002Fbin\u002Factivate\n# Windows:\n.venv\\Scripts\\activate\n\n# Now pip install inside this project won't pollute your system\npip install requests\n```\n\nWhen your terminal prompt shows `(.venv)` at the start, you're inside the environment. To leave: `deactivate`.\n\nIf this feels like too much overhead, a modern alternative is **[uv](https:\u002F\u002Fgithub.com\u002Fastral-sh\u002Fuv)**, a fast Python package manager that handles virtual environments automatically. `uv init`, `uv add requests`, `uv run script.py`. Many vibe coders prefer it.\n\n### Step 5: Install Git\n\nInstall [Git](https:\u002F\u002Fgit-scm.com\u002Fdownloads). You will use it as your safety net. More on this in Section 10.\n\n---\n\n## 5. Choosing Your AI Coding Tools\n\nThere are three categories of tools you'll pick from. Most vibe coders use one from each.\n\n### Category A: Chat-First (paste and iterate)\n\nYou chat with an AI in a browser tab, copy code back to your editor, run it, paste errors back. Slow but universal.\n\n- **Claude.ai** — widely considered the strongest model for coding, especially for multi-file reasoning and subtle bugs. Excellent at Python.\n- **ChatGPT** — fine, widely available.\n- **Gemini** — good, especially for long context (big files).\n\n**Pros:** Free tiers exist. Works for any language, any project. Easy to learn.\n**Cons:** Lots of copy-pasting. The AI doesn't see your whole codebase.\n\n### Category B: Editor-Integrated (AI inside your IDE)\n\nThe AI lives in your editor and can read your files, write directly into them, and run your terminal.\n\n- **Cursor** — the flagship vibe coding editor. A fork of VS Code with deep AI integration. Cmd-K to generate, Cmd-L to chat with your whole project. Paid, with a free tier.\n- **Windsurf** — similar to Cursor, with an \"agentic\" mode where the AI takes multiple actions on its own.\n- **GitHub Copilot** — inline completions as you type, plus a chat panel. Works in VS Code and JetBrains.\n- **Zed** — fast editor with AI features, lighter-weight than Cursor.\n\n**Pros:** The AI has context. Much less copy-paste. Faster iteration.\n**Cons:** Subscription cost. Learning curve. Can cause over-reliance.\n\n### Category C: Terminal\u002FAgent-First (AI as a command-line tool)\n\nYou run a command, the AI reads your project, makes changes, runs tests, and reports back.\n\n- **Claude Code** — Anthropic's official CLI. You run `claude` in your project, describe a task, and it works on it. Very good for multi-step changes.\n- **Aider** — open source, works with various models.\n- **OpenAI Codex CLI** — similar category.\n\n**Pros:** Genuinely agentic — can handle multi-step tasks end-to-end. Great for refactors, migrations, test writing.\n**Cons:** Less hand-holding. Requires comfort with the terminal. Easy to let the AI do things you didn't intend.\n\n### My Recommended Starter Stack\n\nIf you're just starting:\n\n1. **Claude.ai** (free or Pro) for planning, debugging, learning — the \"thinking partner.\"\n2. **VS Code + GitHub Copilot** or **Cursor** for writing code with AI assistance.\n3. Once comfortable: add **Claude Code** for agentic tasks.\n\nYou can do everything in this guide with just Claude.ai and a text editor. Fancier tools are an optimization, not a prerequisite.\n\n---\n\n## 6. The Vibe Coding Workflow\n\nHere's the actual loop, step by step. Internalize this and you're 80% of the way there.\n\n### The Loop\n\n```\n┌─────────────────┐\n│ 1. Describe     │\n│    what you     │ ──┐\n│    want         │   │\n└─────────────────┘   │\n        ▲             ▼\n┌─────────────────┐   ┌─────────────────┐\n│ 5. Refine       │   │ 2. Get code     │\n│    (paste       │   │    from AI      │\n│    errors,      │   └─────────────────┘\n│    ask for      │           │\n│    changes)     │           ▼\n└─────────────────┘   ┌─────────────────┐\n        ▲             │ 3. Run it       │\n        │             └─────────────────┘\n        │                     │\n        │                     ▼\n        │             ┌─────────────────┐\n        └─────────────│ 4. Observe what │\n                      │    happens      │\n                      └─────────────────┘\n```\n\n### Step 1: Describe What You Want\n\nBefore you type a single prompt, answer these in your head (or on paper):\n\n- What is the input? (A file? A URL? Nothing?)\n- What is the output? (A printed number? A new file? A webpage?)\n- What's the happy path? (If it works perfectly, what does the user experience?)\n- What's the rough shape? (A script? A web app? A CLI tool?)\n\nNow write the prompt. Be specific. Be concrete.\n\n### Step 2: Get Code From AI\n\nPaste the prompt into your AI of choice. Read the response. Don't just copy-run — at least skim:\n\n- Does it make sense structurally?\n- Is it using weird libraries you don't recognize?\n- Is it addressing all the parts of your request?\n\nIf something looks off, ask. \"Why did you choose library X?\" or \"Can you do this without any external dependencies?\"\n\n### Step 3: Run It\n\nSave the code to a file. Run it. Actually run it — this is the most-skipped step and the most important one.\n\n```bash\npython myscript.py\n```\n\n### Step 4: Observe What Happens\n\nThree possible outcomes:\n\n- **It works.** Great. Move on, or ask the AI to extend it.\n- **It errors.** Copy the entire error message. The *whole* traceback.\n- **It runs but does the wrong thing.** Describe what you expected vs. what you got.\n\n### Step 5: Refine\n\nGo back to the AI. Paste the error or describe the wrong behavior. Ask for a fix. Loop.\n\n### Loop Discipline\n\nA few rules that separate good vibe coders from frustrated ones:\n\n- **One change at a time.** Don't ask for five improvements in one prompt. You'll lose track of what caused what.\n- **Commit working code.** Every time something works, `git commit`. This means you can always roll back.\n- **Read the diff.** When the AI changes your code, ask \"what did you change and why?\" before moving on.\n- **Kill the thread when it gets confused.** If the AI is going in circles, start a fresh conversation with a clean summary of where you are.\n\n---\n\n## 7. Prompting: The Core Skill\n\nPrompting is 90% of vibe coding. These are the patterns that work.\n\n### The Anatomy of a Good Coding Prompt\n\nA strong prompt has four parts:\n\n1. **Context** — what the project is\n2. **Task** — what you want done right now\n3. **Constraints** — what it should or shouldn't do\n4. **Output format** — what you want back\n\nExample:\n\n> **Context:** I'm building a CLI tool in Python that helps me organize my downloads folder.\n>\n> **Task:** Write a function that takes a folder path and moves every file into a subfolder named after its file extension. For example, `report.pdf` goes into a `pdf\u002F` subfolder.\n>\n> **Constraints:** Use only the standard library (no extra pip installs). Handle files with no extension by putting them in a folder called `no_extension`. Don't move folders, only files. Print what you're doing for each file.\n>\n> **Output:** Give me a single Python function called `organize_folder(path)` and a short example of how to call it.\n\nCompare that to: \"write me a python script to organize downloads.\" Both get you code. The first gets you code that actually works on your first try.\n\n### Useful Prompt Patterns\n\n**The \"act as\" pattern:**\n> \"Act as a senior Python engineer reviewing a junior's code. Here's the code: [paste]. Point out issues and suggest fixes.\"\n\n**The \"minimum viable\" pattern:**\n> \"Give me the absolute minimum code to do X. I want to understand the core idea. No error handling, no edge cases — just the essence.\"\n\n**The \"one file\" pattern:**\n> \"Write this as a single Python file I can run with `python script.py`. No config, no setup, no framework.\"\n\n**The \"explain then code\" pattern:**\n> \"First explain how you'd approach this in 2-3 sentences. Then write the code.\"\n\n**The \"teach me\" pattern:**\n> \"I don't understand why this works. Walk me through it line by line as if I were learning Python.\"\n\n**The \"step by step\" pattern:**\n> \"Don't write all the code yet. First, list the steps you'll take. I'll confirm, then you'll write them one at a time.\"\n\n### Good vs Bad Prompts\n\n**Bad:** \"my code doesnt work\"\n**Good:** \"Here's my code: [paste]. When I run it with input 'abc', I expect 'cba' but I get 'abc'. What's wrong?\"\n\n**Bad:** \"make it better\"\n**Good:** \"This works, but it's slow on files over 1GB. Can you rewrite it to stream the file instead of loading it all into memory?\"\n\n**Bad:** \"add error handling\"\n**Good:** \"Add error handling for two cases: (1) the file doesn't exist, print a friendly message and exit cleanly; (2) the file exists but isn't valid JSON, print the bad line number.\"\n\n### When Stuck: The Reset\n\nIf you've been in a conversation for a while and the AI is tangled up, do this:\n\n1. Start a new chat.\n2. Paste your current code.\n3. Describe, in plain English, what it does now.\n4. Describe what you want it to do next.\n5. Ask the AI to proceed.\n\nA clean context window often solves what 20 more messages won't.\n\n---\n\n## 8. Your First Vibe-Coded Project (Walkthrough)\n\nLet's do one together. We'll build a **word frequency counter** that reads a text file and prints the top 10 most common words. Then we'll extend it.\n\n### Prompt 1 — Initial Build\n\n> I want a Python script that reads a text file and prints the top 10 most common words, along with their counts. Make it a single file called `wordcount.py`. The filename should be passed as a command-line argument. Use only the standard library. Convert everything to lowercase and ignore punctuation.\n\nYou'll get something like:\n\n```python\nimport sys\nimport re\nfrom collections import Counter\n\ndef main():\n    if len(sys.argv) != 2:\n        print(\"Usage: python wordcount.py \u003Cfilename>\")\n        sys.exit(1)\n\n    filename = sys.argv[1]\n    with open(filename, \"r\", encoding=\"utf-8\") as f:\n        text = f.read().lower()\n\n    words = re.findall(r\"\\b[a-z']+\\b\", text)\n    counts = Counter(words)\n\n    for word, count in counts.most_common(10):\n        print(f\"{word}: {count}\")\n\nif __name__ == \"__main__\":\n    main()\n```\n\n### Run It\n\nGrab any text file. Project Gutenberg has free books — download one as a .txt.\n\n```bash\npython wordcount.py moby_dick.txt\n```\n\nYou'll see something like:\n\n```\nthe: 14620\nof: 6732\nand: 6502\na: 4799\nto: 4707\n...\n```\n\n### Prompt 2 — Make It Better\n\n> The top words are all common English words like \"the\" and \"of\". Can you add an option to ignore a standard list of English stopwords? Add a `--no-stopwords` flag.\n\n### Prompt 3 — Extend\n\n> Now instead of printing, save the results to a CSV file called `wordcount.csv` with two columns: \"word\" and \"count\". Write all unique words, not just top 10. Keep the option to print top 10 to the screen as well.\n\n### Prompt 4 — Make It Pretty\n\n> Can you add a progress bar using `tqdm` for large files? And print the total word count, unique word count, and most-common word as a summary at the end.\n\n### What Just Happened\n\nYou shipped a real, working tool in four prompts. You now have:\n- A script that processes text\n- Command-line arguments\n- A library dependency\n- CSV output\n- Progress reporting\n\n**More importantly:** you learned the rhythm. Describe → receive → run → iterate. That's the whole job.\n\n### Homework\n\nTry these next, each as its own small vibe-coded project:\n- A script that renames all the photos in a folder using their EXIF date.\n- A tiny Flask web app that shows a random joke from a text file.\n- A Markdown-to-HTML converter using only the standard library.\n- A CLI tool that fetches the weather for a city using a free API.\n\nEach one should take 20–60 minutes. Do three this weekend.\n\n---\n\n## 9. Debugging With AI\n\nDebugging is where vibe coding most often breaks down — and where it most often shines if you do it right.\n\n### The Golden Rule of Error Reporting\n\n**Paste the entire error message. Every line. Verbatim.**\n\nNot \"I got an error.\" Not \"it says something about a NoneType.\" The full traceback. It looks like:\n\n```\nTraceback (most recent call last):\n  File \"wordcount.py\", line 12, in main\n    words = re.findall(r\"\\b[a-z']+\\b\", text)\n  File \"wordcount.py\", line 9, in main\n    text = f.read().lower()\nAttributeError: 'NoneType' object has no attribute 'lower'\n```\n\nEvery line of that is information the AI needs.\n\n### The Debug Prompt Template\n\n> Here's my code: [paste full code]\n>\n> Here's the command I ran: `python wordcount.py test.txt`\n>\n> Here's the error I got: [paste full error]\n>\n> What's going wrong and how do I fix it?\n\nThis template will solve 90% of your errors without drama.\n\n### When the AI's Fix Doesn't Work\n\nIf the AI's first fix doesn't work, *don't* just say \"didn't work.\" Instead:\n\n> I applied your change. Now I get this different error: [paste]. Here's the current state of the file: [paste].\n\nAlways give the current state. The AI has no memory of what it told you five minutes ago, especially across sessions.\n\n### Print Debugging\n\nA surprisingly effective technique: ask the AI to add print statements.\n\n> Can you add print statements at the key points in this function so I can see what values the variables have at each step?\n\nRun it. Paste the printed output back. Ask \"does this tell you what's wrong?\"\n\n### Binary Search the Problem\n\nWhen the AI is flailing, help it narrow down:\n\n> Let's narrow this down. Here's a minimal version of the code that isolates the problem: [paste]. When I run it with this exact input, I get this exact output. Expected: X. Got: Y.\n\nThe more you can shrink the reproducer, the faster you'll find the bug.\n\n### Logical Bugs (When It Runs But Does the Wrong Thing)\n\nThese are harder. The code doesn't crash — it just lies to you. Give the AI:\n\n1. What the code does\n2. A specific input\n3. What you expected to happen with that input\n4. What actually happened\n\n> My function `discount(price, pct)` should return the price after a percent discount. `discount(100, 20)` should return 80. It's returning 120. Here's the code: [paste].\n\n---\n\n## 10. Version Control and Safety Nets\n\nIf you vibe code without version control, you will eventually lose work. Not maybe — *will*. The AI will rewrite a file you needed. You'll accept a change that breaks three other things. You'll close a tab.\n\n### Git in 60 Seconds\n\nInside your project folder:\n\n```bash\ngit init                          # one time, at the start\ngit add .                         # stage all changes\ngit commit -m \"working version\"   # snapshot them\n```\n\nRules of thumb:\n- **Commit every time something works.** Even if it's small. Especially if it's small.\n- **Use descriptive messages.** \"working version\" is fine sometimes. \"added CSV output\" is better.\n- **Before a big AI refactor, commit first.** That way you can always `git reset --hard` back.\n\n### Key Recovery Commands\n\n| Situation | Command |\n|---|---|\n| Undo all uncommitted changes | `git reset --hard` |\n| See what changed since last commit | `git diff` |\n| See commit history | `git log --oneline` |\n| Go back to a previous commit | `git checkout \u003Ccommit-hash>` |\n| Create a branch to try something risky | `git checkout -b experiment` |\n\n### GitHub (Optional but Recommended)\n\nPush your projects to [GitHub](https:\u002F\u002Fgithub.com). It gives you:\n- Offsite backup\n- A portfolio\n- Easy sharing\n- A natural checkpoint rhythm\n\n`git push` after every meaningful commit and you'll never lose work.\n\n### The Branching Habit for Risky Prompts\n\nBefore you ask the AI to do something big (\"refactor this whole file to use async\"), branch:\n\n```bash\ngit checkout -b try-async\n# ... vibe code the change ...\n# if it works: merge it back\ngit checkout main\ngit merge try-async\n# if it doesn't: just delete the branch\ngit checkout main\ngit branch -D try-async\n```\n\nThis one habit has saved more vibe-coded projects than any other.\n\n---\n\n## 11. Security and Secrets\n\nVibe coding makes security mistakes easy to make and hard to notice. A few non-negotiable rules.\n\n### Never Paste Secrets Into Your Code\n\nAPI keys, passwords, database URLs with passwords — none of these go in your source files. Use environment variables:\n\n```python\nimport os\napi_key = os.environ[\"OPENAI_API_KEY\"]\n```\n\nThen set it in your shell:\n\n```bash\nexport OPENAI_API_KEY=\"sk-...\"\n```\n\nOr use a `.env` file with the `python-dotenv` package, and **add `.env` to your `.gitignore`**.\n\n### `.gitignore` is Mandatory\n\nCreate a file called `.gitignore` in your project root. Paste this in:\n\n```\n.env\n.venv\u002F\n__pycache__\u002F\n*.pyc\n.DS_Store\n*.sqlite3\n*.log\nsecrets\u002F\n```\n\nWithout this, you will eventually commit a secret to GitHub. It happens to everyone. Prevent it up front.\n\n### If You Ever Commit a Secret\n\nRotate it *immediately*. Don't delete the file and push — the secret is still in git history. Generate a new key, revoke the old one, and be more careful next time.\n\n### Be Suspicious of AI-Suggested Packages\n\nSometimes AIs invent package names. Sometimes attackers register those invented names with malicious code (this is called \"slopsquatting\"). Before `pip install`-ing something the AI told you about:\n\n- Check it on [pypi.org](https:\u002F\u002Fpypi.org). Is it popular? How old? Who maintains it?\n- Search its name + \"github.\" Is there a real repo?\n- If it feels off, ask the AI: \"is this a real, widely used package, or did you make it up?\"\n\n### Don't Let the AI Run Destructive Commands Blindly\n\nIf an agent tool (Cursor's agent mode, Claude Code, etc.) proposes commands like `rm -rf`, `DROP TABLE`, `git push --force`, or anything that modifies things outside your project folder — **read it, understand it, and confirm it manually**. Agents are powerful. Powerful tools cut you.\n\n### User Input is Always Hostile\n\nIf you're building anything that takes user input — a web app, a CLI that reads files, a script that runs SQL — assume someone malicious will use it. Ask the AI explicitly: \"what security issues does this code have?\" and take the answer seriously.\n\n---\n\n## 12. When Vibe Coding Works, and When It Doesn't\n\nHonest assessment. Vibe coding is not a universal solvent.\n\n### Where It Shines\n\n- **Personal tools.** Things only you will ever use.\n- **Scripts and automation.** Anything under 500 lines.\n- **Prototypes.** Getting to \"is this idea even worth pursuing?\"\n- **Web scraping, data cleaning, file processing.** Bread and butter.\n- **Learning.** Trying things in new languages, new libraries.\n- **Glue code.** Connecting API A to service B with transformation C.\n- **Internal tools.** Things a small team uses where \"it works for now\" is fine.\n\n### Where It Struggles\n\n- **Large codebases.** Once the project is too big for the AI to see at once, quality drops.\n- **Subtle business logic.** Financial calculations, legal compliance, medical dosing.\n- **Concurrency and distributed systems.** Race conditions are hard for humans; they're hard for AI too.\n- **Performance-critical code.** The AI writes \"works\" code, not \"blazing fast\" code.\n- **Novel algorithms.** If the solution isn't on Stack Overflow or GitHub, the AI often flounders.\n- **Production security.** Auth systems, payment processors, anything handling sensitive data.\n- **Long-lived code.** Code you'll maintain for years benefits from being written by humans who understand it.\n\n### The Honest Default\n\nUse vibe coding freely for the first category. Use it carefully, with code review and testing, for in-between cases. For the hard category, treat the AI as a helpful tool inside a traditional engineering process — not as the process itself.\n\n---\n\n## 13. Common Pitfalls and How to Avoid Them\n\nThings that will bite you. All have been experienced by nearly every vibe coder.\n\n### Pitfall: The Endless Fix Loop\n\n**Symptom:** You keep asking for fixes. Each fix breaks something else. The code grows more baroque with each turn.\n\n**Cause:** The AI is patching without understanding the root problem. Probably you are too.\n\n**Fix:** Stop. Revert to the last known good version. Re-describe the problem from scratch in a new conversation. Often the right fix is a rewrite, not more patches.\n\n### Pitfall: The Phantom Dependency\n\n**Symptom:** You install a package the AI recommended. It doesn't work, or worse, it's not what you thought.\n\n**Fix:** Always verify packages on PyPI before installing. Prefer the standard library when possible. Pin versions in a `requirements.txt`.\n\n### Pitfall: The Silent Rewrite\n\n**Symptom:** You ask for a small tweak. The AI returns a completely restructured file with your careful changes gone.\n\n**Fix:** Ask explicitly: \"only change the X function. Don't touch anything else.\" Or use a tool that shows you diffs, not full rewrites. Or just `git diff` every change before committing.\n\n### Pitfall: Built-In but Rebuilt\n\n**Symptom:** The AI writes 40 lines to do something that `pathlib` or `itertools` does in 2.\n\n**Fix:** When you see a lot of code, ask: \"is there a standard library function that does this?\" Often there is.\n\n### Pitfall: The Works-On-My-Machine Trap\n\n**Symptom:** Your script works. You send it to someone else. It doesn't work.\n\n**Fix:** Always create a `requirements.txt` (`pip freeze > requirements.txt`). Always mention your Python version. Always test on a clean virtual environment before sharing.\n\n### Pitfall: The Confident Lie\n\n**Symptom:** The AI explains its code in great detail. The explanation is wrong.\n\n**Fix:** Test behavior, not explanations. If the AI says \"this function returns a sorted list,\" call it with a messy input and see if the output is actually sorted. Don't trust claims — verify.\n\n### Pitfall: Copy-Paste Archaeology\n\n**Symptom:** Three months later, you open a project and have no idea how any of it works.\n\n**Fix:** Add comments as you go. Ask the AI: \"explain this code with comments, and add a README describing how to run it.\" Your future self will thank you.\n\n### Pitfall: Over-Engineering\n\n**Symptom:** You asked for a script. You got a class hierarchy with a factory pattern and a config loader.\n\n**Fix:** Say \"make this as simple as possible. One function, no classes, no config files.\"\n\n---\n\n## 14. Scaling From Toys to Real Software\n\nAt some point, you'll want to vibe code something bigger than a script. Here's how the discipline changes.\n\n### Project Structure\n\nA real Python project looks roughly like:\n\n```\nmy-project\u002F\n├── .venv\u002F                  # your virtual environment (gitignored)\n├── .gitignore\n├── README.md\n├── requirements.txt        # or pyproject.toml\n├── src\u002F\n│   └── my_project\u002F\n│       ├── __init__.py\n│       ├── main.py\n│       └── helpers.py\n├── tests\u002F\n│   └── test_helpers.py\n└── scripts\u002F\n    └── run.sh\n```\n\nAsk the AI to set this up for you when starting: \"Scaffold a standard Python project layout for [description].\"\n\n### Tests Become Your Friend\n\nIn a one-file script, you can just run it to see if it works. In a real project, you need tests. Tests are also the single best way to keep the AI honest — you can run them before and after a change and catch regressions.\n\nAsk:\n> \"Write pytest tests for this function. Cover the happy path, an empty input, a malformed input, and an edge case.\"\n\nThen run `pytest` after every AI change.\n\n### Type Hints\n\nType hints help you *and* the AI. They make bugs visible earlier and give the AI more information to work with.\n\n```python\ndef discount(price: float, pct: float) -> float:\n    return price * (1 - pct \u002F 100)\n```\n\nAsk the AI to add type hints to your code. Use `mypy` or `pyright` to check them.\n\n### Linting and Formatting\n\nOnce your project has more than a few files:\n\n```bash\npip install ruff\nruff check .        # find issues\nruff format .       # auto-format\n```\n\nRuff is a fast, modern linter that replaces several older tools. Run it regularly.\n\n### Documentation\n\nEvery project needs at minimum:\n- A `README.md` explaining what it is and how to run it\n- Docstrings on public functions\n\nAsk the AI to write both.\n\n### Architecture Conversations\n\nFor bigger projects, before coding, *talk through the design*:\n\n> I want to build [description]. Before we write any code, walk me through three possible architectures. For each, explain the tradeoffs. Then recommend one.\n\nYou'll often catch bad design choices before they become 2,000 lines of code.\n\n### Splitting Work Into Chunks\n\nBig features are hard for AI to one-shot. Break them down:\n\n1. \"List all the pieces this feature needs.\"\n2. \"Let's build piece 1 first. [details]\"\n3. [Build and test piece 1]\n4. \"Now piece 2, which depends on piece 1. [details]\"\n\nThis is how professional engineers work, too. Vibe coders just do it in conversation instead of on a whiteboard.\n\n---\n\n## 15. A 30-Day Practice Plan\n\nThe only way to get good at this is to do it. Here's a four-week plan.\n\n### Week 1: Scripts\n\nOne small Python script per day. Each one should take 20–45 minutes. Ideas:\n\n- Day 1: Word counter (follow the walkthrough above)\n- Day 2: Rename files in a folder based on a pattern\n- Day 3: Scrape a simple webpage and save data to CSV\n- Day 4: Merge multiple CSVs into one\n- Day 5: Convert all images in a folder to a new format\n- Day 6: Generate a random password\n- Day 7: Build a flashcard quiz from a text file\n\nGoal: get comfortable with the loop. Describe, generate, run, fix.\n\n### Week 2: Slightly Larger\n\nProjects that span multiple files or use a library you don't know. 1–2 hours each.\n\n- Day 8: A Flask web app that shows you the weather\n- Day 9: A Telegram or Discord bot that does one simple thing\n- Day 10: A command-line todo app that saves to a JSON file\n- Day 11: A script that summarizes your day from your calendar\n- Day 12: A tiny personal blog from Markdown files\n- Day 13: A data visualization with matplotlib or plotly\n- Day 14: Rebuild one of week 1's projects from scratch, from memory\n\nGoal: learn to split problems into steps.\n\n### Week 3: With Tests and Git\n\nPick one idea and actually *maintain* it for the week. Use git. Write tests.\n\n- Day 15: Scope the project. Write a README *before* coding.\n- Day 16: Build the first working version. Commit.\n- Day 17: Add tests for the core functions.\n- Day 18: Add a new feature. Don't break the tests.\n- Day 19: Refactor something ugly. Tests should still pass.\n- Day 20: Add error handling and logging.\n- Day 21: Polish the README. Push to GitHub.\n\nGoal: learn the rhythm of real software.\n\n### Week 4: Go Off-Road\n\nPick a project *you actually want to exist in the world*. Something useful to you or someone you know. Spend the whole week on it. Ship it.\n\nGoal: experience the full arc from idea to shipped thing, with AI as your partner.\n\n---\n\n## 16. Resources and Further Reading\n\n### Official Documentation\n\n- **Python docs** — [docs.python.org](https:\u002F\u002Fdocs.python.org) — the authoritative reference\n- **PyPI** — [pypi.org](https:\u002F\u002Fpypi.org) — package registry\n- **Real Python** — [realpython.com](https:\u002F\u002Frealpython.com) — high-quality tutorials\n\n### AI Coding Tools\n\n- **Claude.ai** — [claude.ai](https:\u002F\u002Fclaude.ai)\n- **Cursor** — [cursor.com](https:\u002F\u002Fcursor.com)\n- **GitHub Copilot** — [github.com\u002Ffeatures\u002Fcopilot](https:\u002F\u002Fgithub.com\u002Ffeatures\u002Fcopilot)\n- **Claude Code** — [docs.claude.com](https:\u002F\u002Fdocs.claude.com) — Anthropic's official CLI\n- **Aider** — [aider.chat](https:\u002F\u002Faider.chat)\n\n### Python Fundamentals (if you want more grounding)\n\n- **Automate the Boring Stuff with Python** by Al Sweigart — free online, perfect for beginners\n- **Fluent Python** by Luciano Ramalho — for when you want to go deep\n- **Python Tricks** by Dan Bader — bite-sized patterns\n\n### Vibe Coding Community\n\n- **[Awesome Vibe Coding](https:\u002F\u002Fgithub.com\u002Fai-for-developers\u002Fawesome-vibe-coding)** — where the term originated; still a good signal source\n- **r\u002Fvibecoding** on Reddit\n- **Hacker News** — search for \"vibe coding\" threads\n- **Simon Willison's blog** — [simonwillison.net](https:\u002F\u002Fsimonwillison.net) — one of the most thoughtful writers on practical AI coding\n\n\n### When You Want to Stop Vibing and Start Engineering\n\n- **Designing Data-Intensive Applications** by Martin Kleppmann\n- **The Pragmatic Programmer** by Hunt & Thomas\n- **A Philosophy of Software Design** by John Ousterhout\n\n---\n\n## Final Thoughts\n\nVibe coding isn't magic and it isn't cheating. It's a new interface to an old craft. The craft is still about understanding what you're building, caring about the people who'll use it, and being honest with yourself about what works.\n\nThe AI is a genuinely incredible collaborator — faster, more patient, and more widely read than any human could be. But it doesn't know your users. It doesn't know your constraints. It doesn't care if the code ships. You do. That part of the job isn't going anywhere.\n\nStart small. Ship things. Break things. Read the code you generate, eventually. Keep a `git log` of your learning. In six months you'll be shocked at what you can build.\n\nNow close this document, open your editor, and make something.\n\n---\n\n*Good luck, and welcome to the vibes.*\n","该项目是一个面向初学者的完整氛围编程指南，使用Python语言。其核心功能在于教授如何通过与AI模型对话来构建软件，用户只需描述需求，AI负责编写代码，用户测试并迭代改进。技术特点包括强调意图而非语法、重视迭代而非规划、以及信任但验证AI生成的代码。适合希望提高开发效率、尝试新编程方式或对利用AI辅助编程感兴趣的开发者使用。","2026-06-11 03:52:51","CREATED_QUERY"]