Leading up to Microsoft Ignite, I wanted to pressure-test something the community keeps talking about: vibe coding. It’s a style of AI-assisted development where you describe outcomes in natural language and your assistant does most of the scaffolding, refactoring, and glue. You keep momentum by talking through the work, and you only drop to raw code when you need to tighten the screws.If you’ve ever written music, the metaphor fits: you’re chasing a riff, not over-theorizing scales. A writing partner sits beside you, nudging phrasing, trimming bars, and pushing you through the bridge. After a few loops, you’ve got a demo worth sharing. That’s the goal here: prove that I can get to a demo in ~an hour. That's including building and troubleshooting—purely via conversation with the assistant.What follows is the playbook I used to generate the app quickly, the exact prompt patterns that helped, and how I validated the result inside VS Code without leaving the editor.Tools I used (and how they fit the flow) Visual Studio Code — editing, terminal, and inline chat. Azure Cosmos DB Linux-based Emulator (vNext Preview) — a local Docker container so I can iterate fast without provisioning anything. Azure Databases (VS Code extension) — attach to the local emulator and browse databases/containers/documents directly in the sidebar. GitHub Copilot Chat (VS Code) — the “writing partner” that turns intent into code, then helps me iterate.🎸 What is “vibe coding,” in practice? Intent first. You describe the outcome (“Add a numbered delete flow with a confirmation”) rather than issuing line-by-line directives. Tight loop. Ask for a change → run it → immediately validate → ask for a tighter or safer version. Human judgment. You still own testing, security, and maintainability; the assistant speeds up scaffolding and edits.My objective: prove a real demo lands fast when you work this way—and document the conversational moves that make it work.The code-generation playbook I usedBelow are the actual kinds of prompts that moved the work forward. Feel free to copy/paste them into your own flow.1) Kickstart: “Plan → code” two-stepAsk for a plan first, then ask it to implement.“Outline a minimal Python console app that uses the Azure Cosmos DB Python SDK against a local emulator. Features: add/list/delete ‘vibes’. Partition key is /id. Use friendly, colorized console output. Then propose a file layout and any environment variables you expect in a .env file.” Follow with:“Great—now generate a single-file implementation in vibes_manager.py using your plan.” Why it works: The assistant reveals assumptions and dependencies before it writes code. You catch problems early (SDK choice, partition key, error paths).2) Constrain the diffDon’t ask for “a bunch of changes.” Ask for one change.“Add a delete-by-number workflow: - list existing vibes with numbers - prompt to choose one - show a detail preview - confirm before delete Keep the rest of the file intact. Only return the new/changed functions and any changes in main().” Why it works: Tiny diffs are easy to review, and the assistant stays focused.3) Describe UX, not codePaint the experience you want, not the implementation you imagine.“When removing a vibe, I should be able to scroll through them and delete one at a time. Use a numbered menu and a final ‘Are you sure?’ confirmation. If there are no vibes, return to the main menu with a friendly message.” Why it works: You get behavior that feels right, and the assistant chooses idiomatic APIs to achieve it.4) State runtime facts up frontGive the assistant the operating context to avoid dead ends.“Runtime facts: Python 3.10, VS Code on Windows (WSL available), Cosmos emulator running locally. We use a .env file for COSMOS_ENDPOINT, COSMOS_KEY, COSMOS_DATABASE_NAME=vibes, COSMOS_CONTAINER_NAME=items. Add an optional DISABLE_SSL_VERIFICATION flag for local dev.” Why it works: Removes guesswork around certs, ports, and configuration.5) Ask for guardrailsBake in reliability and readability early.“Wrap Cosmos calls with clear exception handling (not walls of tracebacks). Return user-friendly messages and keep logging concise. Add type hints and small docstrings to public methods.” Why it works: You won’t have to retrofit error handling later.6) Debug by symptom, not speculationWhen something’s “red in VS Code,” don’t guess. Describe what you see.“vibes_manager.py is red in VS Code and won’t run. Investigate likely causes (docstring markup, imports, missing env values). Propose minimal fixes and show diff-only results.” Why it works: The assistant considers environment, syntax, and imports—not just one line number.7) Refactor with explicit acceptance criteriaWhen changes get bigger, set tests/checks as the target.“Refactor the main menu to use a single loop with a choice dispatcher. Accept if: - add/list/delete all work - invalid input returns to the menu without throwing - exit path prints a friendly goodbye.” Why it works: “Done” becomes testable, not subjective.8) Documentation on demandKeep your repo coherent with prompts that maintain docs as you go.“Update README.md to reflect the numbered delete flow and the .env requirement. Update copilot-instructions.md with the runtime facts and the prompt patterns we’ve been using.” Why it works: Future you—and collaborators—get context without spelunking through commits.Minimal setup (without the deep dive) Python venv: create/activate, pip install -r requirements.txt. .env: endpoint, key, database, container, optional SSL flag. Emulator: run the start script (Docker required). Run: launch the app (or use the helper script that sets up and runs it).That’s all you need to start prompting and iterating.A quick validation loop—inside VS CodeI did one crisp, reproducible check to confirm the flow end-to-end without leaving the editor: Add a new vibe in the console app; note the printed ID (UID). In the Azure panel: Cosmos DB Accounts → Local Emulators → NoSQL Emulator : 8081 → vibes → items → Items. Open the document whose id matches the printed UID and confirm the fields. No browser required; the Azure Databases extension keeps you in flow.Troubleshooting playbook (prompts I actually used) Environment & syntax “It’s red in VS Code. Investigate malformed docstrings, imports, and missing env values. Propose fixes; show diffs only.” Feature regression “The delete-by-number functionality is gone. Reintroduce it, integrating with the main loop and confirmation prompts. Return only the sections that changed.” Connection issues “On connect, show a short ‘make sure the emulator is running’ hint if we can’t reach the gateway. Don’t print stack traces by default.” Polish “Tighten user messaging: friendly success ticks, short error lines, and a ‘no vibes yet’ note when the list is empty.”Patterns worth keeping Plan → code in two messages. One change per prompt (constrain the diff). UX first (“how it feels” beats “how to implement”). State runtime facts early. Acceptance criteria for bigger edits. Docs prompts to keep the repo fresh.What mattered less (and why) Dumping large code blocks into chat. It’s faster to select a region in the editor and say “make this do X,” or paste short excerpts with the exact change you want. Premature architecture. For a one-hour demo, the assistant’s “good enough” scaffolding is exactly what you want—save grand designs for later.Closing riffYou can find the complete output of my work in this GitHub repository. Feel free to fork it and then iterate upon it! Have any other improvements you created with vibes? Submit a PR! Vibe coding doesn’t replace engineering; it accelerates the path to understanding. By treating the assistant like a capable writing partner—and by giving clear, incremental prompts—you can stand up a credible demo fast, fix issues conversationally, and validate everything without leaving VS Code. From there, you can tighten reliability, security, and structure at your own pace.If you try this approach, use the playbook above. Start small, describe the experience, constrain each change, and keep your loop tight. You might be surprised how quickly that riff turns into a track you’re proud to share.About Azure Cosmos DBAzure Cosmos DB is a fully managed and serverless distributed database for modern app development, with SLA-backed speed and availability, automatic and instant scalability, and support for open-source PostgreSQL, MongoDB, and Apache Cassandra. To stay in the loop on Azure Cosmos DB updates, follow us on X, YouTube, and LinkedIn.