Spot the Vibe-Coded Thing

You can talk about vibe coding all day, but pattern recognition is sharpened by practice. In this lesson we look at real scenarios, prompts, and project descriptions and work out which approach — intent-driven vibe coding or traditional hand-coding — best fits the situation. By the end, you will have a reliable mental checklist. This is not about one approach being superior. It is about reading a situation clearly enough to choose wisely.

The Signals to Look For

When you encounter a software project or a description of how something was built, certain signals point toward vibe coding. Others point toward traditional hand-coding. Learning to read these signals makes you a better builder and a better collaborator. Signals that suggest vibe coding was a good fit: - The project was created quickly by someone without a programming background - The brief for the project was given entirely in natural language - The goal was to test an idea, not to build a production system - The project does one main thing, for one type of user - Iteration and refinement happened through conversations rather than code edits Signals that suggest traditional hand-coding was involved: - The project handles sensitive data with strict security requirements - The codebase is maintained by a team and changes frequently - Performance is critical — milliseconds matter - The project has been running in production for years and has complex history - Every detail of behavior must be exactly specified and auditable

Let us walk through four scenarios: Scenario A: A 13-year-old wants to make a birthday reminder app for her family. She describes it to an AI, gets a working version, adjusts the colors and adds two more relatives by describing the changes, and shares a link. Verdict: Vibe-coded. Single user, single purpose, non-sensitive data, no hand-coding needed. Scenario B: An engineer at a hospital maintains software that schedules surgical teams. Each team member has specific certifications, and the wrong assignment could have serious consequences. Verdict: Traditional coding with deep human oversight. The stakes, complexity, and responsibility demand it. Scenario C: A small team is building a new marketing website for their bakery. They use an AI to generate the initial layout, then hand-edit the CSS to match their exact brand colors. Verdict: Both. Vibe-coded prototype + traditional refinement — the most common real-world pattern. Scenario D: A student produces a history quiz for their class project. The teacher evaluates the questions and the app itself. Verdict: Vibe-coded. Ideal scope, low stakes, fast to produce and refine.

Reading a Prompt for Clues

You can also spot vibe coding by reading the prompt someone used. A vibe-coded project usually starts from a prompt that reads like a description of a product for a user, not a technical specification. Vibe-coding prompt: 'Build me a to-do list where I can type in a task, press Add, and see it appear in a list below. Each task should have a checkbox I can tick when it is done. Done tasks should show a strikethrough.' Traditional coding spec (excerpt): 'Task objects shall be stored in a relational database. Each task record must include: id (UUID, primary key), body (varchar 500, not null), created_at (timestamp), completed_at (nullable timestamp), user_id (foreign key referencing users.id). API endpoints shall follow REST conventions.' Both describe a to-do list. The first is intent in plain language — perfect vibe-coding input. The second is a technical specification written for engineers — it assumes knowledge of databases, APIs, and data types.