The Vibe Coding Trap and Intent-Based Collaboration
The Sweet Temptation of "Just Let AI Do Everything"
"GPT can build that in five minutes." Whenever I hear this, I feel conflicted. It's not wrong. Tell an AI "build me a tarot app" and you get working code. Cards appear on screen. Click one and it flips. An interpretation shows up. Five minutes is an exaggeration, but thirty minutes is realistic.
The problem comes next. "I want to change the card animation." "I want to add reading history." "The layout breaks on mobile." The moment these requests arrive, a developer working on top of code that AI produced in five minutes can do almost nothing. They don't understand the code.
That's the vibe coding trap. And this post is about the core theme running through the entire Tarot Master project: the difference between vibe coding and intent-based collaboration.
What Is Vibe Coding?
Vibe coding means "letting AI write the code and checking the vibe -- whether the output looks right -- without understanding the internals." You don't examine the code's structure. If the result works as expected, you move on. It's fast, comfortable, and delivers instant gratification.
There are legitimate use cases. One-off scripts, quick prototypes, learning exercises. If the code will be used once and discarded, deep understanding of its internals isn't necessary. The problems emerge when you apply this approach to a project that persists.
Tarot Master was developed over more than a month, with features incrementally added, designs changed, and bugs fixed. New code layers on top of earlier code. Code built on a foundation that isn't understood is a castle on sand.
The Critical Difference: "Build This" vs. "Design It This Way"
The difference between vibe coding and intent-based collaboration is most visible in the shape of the questions you ask AI.
Vibe coding: "Build me a tarot app."
Intent-based collaboration: "Define the data schema for 78 cards like this. Separate the 22 Major Arcana from the 56 Minor Arcana. Include upright and reversed interpretations for each card."
The outputs might look similar. But what the developer takes away from the process is entirely different. In vibe coding, the developer gets "code that works." In intent-based collaboration, the developer gets "code they understand."
The difference surfaces when problems arise. Say card data displays as undefined. A developer who understands the data schema immediately spots it: "The reversed interpretation field is optional but there's no default value handling." A vibe coder tells AI "the card data isn't showing" and waits for a fix. AI patches it, but the next similar problem requires another trip to AI. A permanent dependency forms where you can never move without AI.
What Happens When You Don't Understand the Code
There was a specific moment in Tarot Master's development where I deliberately invested in understanding code. It was the Celtic Cross spread's 10-card layout. Claude proposed layout code combining CSS Grid with absolute positioning.
The vibe coding approach would have been to copy the code, confirm it works, and move on. Instead, I asked why each card position was set the way it was, why the grid area names were divided as they were. I listened to AI's explanations and manually changed values to see how the layout responded.
That time investment paid off when I needed a separate mobile layout. Because I understood the desktop layout's structure, I could independently judge what needed to change for mobile. Without that understanding, I would have asked AI to rebuild the mobile layout from scratch.
The difference is even more dramatic in debugging. When a service worker caching issue prevented updates from appearing, my understanding of how service workers operate let me set the right direction: "I need to check the cache invalidation logic." That ability to set direction is the most practical difference between vibe coding and intent-based collaboration.
Understanding the "Why" Behind AI-Generated Code
Every line of AI-generated code has a reason behind it. Or rather, it should. But AI often doesn't volunteer those reasons. It presents a result with "here's how to do it" and moves on.
In intent-based collaboration, the developer's role is to persistently ask "why." "Why did you split this component this way?" "What's the reasoning behind this state management approach?" "What are the tradeoffs compared to alternatives?"
Ask these questions and AI provides remarkably detailed explanations. What alternatives existed, the pros and cons of each, why this particular choice suits the current context. Through this process, the developer gains understanding not just of the code but of the design rationale.
Choosing localStorage for Tarot Master. Choosing Framer Motion. Choosing vite-plugin-pwa. Each selection had reasons, and because I understand those reasons, I can now make informed decisions like "Should I migrate to IndexedDB?" Without understanding the why, you can't make the judgment.
Practicing Intent-Based Collaboration
Here's the framework I developed during Tarot Master for intent-based collaboration.
First, I own the structural design. How to decompose components, how to structure data flow, how to manage state. I draw the big picture. I ask AI to "build it with this structure." When AI proposes a structure, reviewing and revising it is also my responsibility.
Second, I delegate execution to AI. Once the structure is set, AI writes concrete code far faster than I can. Repetitive patterns, boilerplate, library integrations -- these are AI's strengths. Saving time here is the core value of AI collaboration.
Third, I never move forward without understanding. Before copying AI-generated code, I read it. If something is unclear, I ask. "What does this line do?" "What's this pattern called?" Each verification feels slow, but that investment returns tenfold later.
Fourth, I always ask about alternatives. AI's first suggestion may not be optimal. "Are there other approaches?" "What's the downside of this method?" These questions surface better solutions and broaden the developer's perspective.
Fifth, I make the final call. AI's suggestions are input, but the final decision -- considering the project's context and priorities -- belongs to the developer. AI doesn't grasp the full picture. What matters most right now, where to invest time -- only the person running the project can judge that.
The Core Skill for Developers in the AI Era: The Ability to Define "Why"
Humans can't outpace AI at writing code. That much is clear. But there's a domain AI can't replace: deciding "why this should be built."
In Tarot Master, the decision to add a free-choice mode with 78 cards. The decision to generate shareable Instagram Story images. The decision to overhaul the UI in Linear's style. None of these were AI's ideas. They came from observing user needs, considering the project's direction, and judging effort-to-impact ratios. My decisions.
Ask AI "What should I add to this project?" and it will answer. The answer might even be decent. But it's a generic suggestion, not a decision that reflects this project's context and this project's actual users.
The ability to define "why" comes from experience. Writing code, observing user reactions, failing, iterating. AI can accelerate this cycle, but it can't experience it for you.
What Is a Developer, Ultimately?
The conclusion I reached through Tarot Master is this: in the AI era, a developer isn't "a person who writes code." It's "a person who decides what to build and why, then collaborates with AI to make it real."
Vibe coding is surrendering that role. "Let AI handle everything" is comfortable, but it halts growth as a developer. Intent-based collaboration leverages AI's speed while preserving the developer's understanding and judgment.
It's not the easy path. The temptation of "why bother understanding when I can just copy?" arrives constantly. But the time invested now compounds across every future project. Code you understand becomes an asset. Code you don't understand becomes debt. Knowing this difference is the first weapon for developers navigating the AI era.
What's Next
The final part. I look back on the entire 20-part Tarot Master journey, honestly assess what AI did well and what it couldn't, and reflect on what building a side project with AI left me with and the possibilities ahead.
댓글
댓글 쓰기