Dominar Claude Code Parte 10: Filosofía del Vibe Coding

Has aprendido las herramientas. Comandos, skills, subagentes, servidores MCP, automatización headless—sabes cómo funciona Claude Code. Pero conocer las herramientas no es lo mismo que fluir con ellas.

Este capítulo final trata sobre mentalidad. La filosofía que convierte a usuarios competentes de Claude Code en desarrolladores que se mueven a una velocidad completamente diferente.

¿Qué es el Vibe Coding?

El término viene de un tweet viral de Andrej Karpathy en febrero de 2025:

"Hay un nuevo tipo de programación que llamo 'vibe coding', donde te entregas completamente a las vibes, abrazas las exponenciales y te olvidas de que el código siquiera existe. Es posible porque los LLMs se están volviendo demasiado buenos."

Describió su flujo de trabajo: aceptar todos los cambios sin leer diffs, copiar y pegar mensajes de error sin comentarios, pedirle a la IA cosas triviales como "reduce el padding del sidebar a la mitad" porque le da pereza buscarlas.

Luego añadió la advertencia crucial: "No está tan mal para proyectos de fin de semana desechables, pero sigue siendo bastante divertido."

Esa advertencia importa. El vibe coding no es un enfoque universal—es un modo de trabajar que es apropiado para contextos específicos.

El espectro del desarrollo asistido por IA

Simon Willison lo expresó bien: "No toda la programación asistida por IA es vibe coding."

Hay un espectro:

Vibe Coding puro — Acepta todo, no leas diffs, copia y pega errores, deja que la IA lo resuelva. Genial para hacks de fin de semana y prototipos desechables.

Desarrollo guiado por IA — Tú diriges, Claude implementa, tú revisas. El enfoque que hemos cubierto a lo largo de esta serie.

Ingeniería aumentada por IA — Disciplina de ingeniería tradicional con aceleración de IA. Documentos de diseño, revisiones de código, testing, verificación de seguridad—todo sigue ocurriendo, solo que más rápido.

La mayor parte del trabajo profesional vive en el medio. El vibe coding puro en un extremo es arriesgado para cualquier cosa más allá de experimentos. La programación manual pura en el otro extremo significa desperdiciar velocidad.

La habilidad está en saber dónde del espectro deberías estar para cada tarea dada.

Cuándo hacer vibe

El vibe coding funciona cuando:

• Es un prototipo — Estás explorando una idea, no desplegando para usuarios
• Puedes tirarlo a la basura — Si no funciona, empiezas de nuevo
• La seguridad no importa — Sin datos reales de usuarios, sin credenciales de producción
• Eres el único usuario — Nadie más depende de este código
• La velocidad importa más que la calidad — Estás validando un concepto, no construyendo infraestructura

Ejemplos de tareas apropiadas para vibe:

"Build me a quick dashboard to visualize this CSV data"
"Make a Chrome extension that does X"
"Prototype this feature idea so I can show stakeholders"

Cuándo NO hacer vibe

Frena el modo vibe cuando:

• Hay seguridad involucrada — Autenticación, pagos, datos de usuario. Siempre revisa este código.
• Otros dependen de ello — Compañeros de equipo, usuarios, sistemas en producción
• Hay dinero en juego — Costes de API, facturación, cálculos financieros
• Es difícil de deshacer — Migraciones de base de datos, operaciones destructivas
• Tienes que mantenerlo — Código con el que convivirás meses o años

Para estos casos, cambia a desarrollo guiado por IA: Claude implementa, tú revisas cada cambio, tú entiendes lo que está pasando.

La mentalidad del director

Incluso cuando no estás en modo vibe coding total, la idea central aplica: eres el director de orquesta, no el instrumentista.

Programación tradicional: Tú escribes cada línea.

Programación asistida por IA: Tú diriges la orquesta. Claude se encarga de la ejecución, tú decides qué música tocar.

You: "We need authentication"
         ↓
Your job: WHAT to build, WHY, constraints
         ↓
Claude's job: HOW to implement
         ↓
Your job: VERIFY it's right

Este cambio es la razón por la que la planificación importa más, no menos. Sin una dirección clara, Claude tomará decisiones aparentemente razonables que no encajan en tu arquitectura.

La paradoja: Se necesita más planificación

Esto es lo que sorprende a la gente: el desarrollo asistido por IA requiere MÁS planificación inicial, no menos.

Sin planificación, Claude va a:

• Crear patrones inconsistentes entre archivos
• Pasar por alto restricciones de arquitectura que no has declarado
• Duplicar funcionalidad que ya existe
• Tomar decisiones difíciles de revertir

Cómo se ve una buena planificación

I'm building a dashboard feature. Here's the plan:

Architecture:
- Server component for the page
- Client component for interactive charts
- React Query for data fetching
- Recharts for visualization

Constraints:
- Must work on mobile
- Data refreshes every 30 seconds
- Follow existing component patterns in src/components/

Tasks (in order):
1. Create DashboardPage server component
2. Build StatsCards client component
3. Add charts with Recharts
4. Implement refresh logic

Start with task 1.

Claude es increíblemente bueno en la implementación. Es menos bueno en decisiones estratégicas sobre arquitectura. Juega con las fortalezas: tú arquitectas, Claude implementa.

Dirección efectiva

La diferencia entre sesiones de IA frustrantes y productivas a menudo se reduce a cómo diriges.

Demasiado vago:

"Build me a dashboard"

Sin restricciones, sin arquitectura, sin patrones. Receta para un resultado desalineado.

Demasiado controlador:

"Create a function. Call it handleSubmit. It should take an event parameter.
First, prevent default. Then, get the form data..."

Estás escribiendo código con pasos extra. Deja que Claude programe.

Justo:

"Add a dashboard to the admin section showing user stats.
Use the existing card component pattern from src/components/ui/.
Include: total users, signups this week, active sessions.
Data comes from the /api/stats endpoint."

Objetivo claro, restricciones claras, espacio para que Claude trabaje.

Confía pero verifica

Karpathy puede hacer vibe coding porque inmediatamente ve si el código funciona y puede tirarlo si no. Para cualquier cosa más allá de prototipos, agrega verificación.

Para implementación:

"Implement the feature, then explain the key decisions you made"

Obliga a Claude a articular su razonamiento. Detecta desalineaciones temprano.

Para código sensible en seguridad:

"Implement this, but flag any security considerations I should review"

Hace que Claude sea tu primer revisor de seguridad.

Para lógica compleja:

"Before implementing, explain your approach in 2-3 sentences"

Detecta malos enfoques antes de que se conviertan en mal código.

La mentalidad iterativa

El vibe coding es inherentemente iterativo. El primer intento no será perfecto. Y está bien.

"This works, but the error messages are generic. Make them more helpful."

"Good, now add loading states."

"The mobile layout is broken, fix it."

Las iteraciones rápidas ganan a los intentos perfectos a la primera. Claude es barato y rápido. Aprovéchalo.

Anti-patrones

El que nunca verifica

❌ *Despliega el código de Claude sin leerlo*

Vibe coding puro para producción. Así es como consigues vulnerabilidades de seguridad y casos límite rotos.

El microgestor

❌ "Create a function. Call it handleSubmit. It should take an event..."

Estás escribiendo código con pasos extra. O confías en Claude para implementar, o lo escribes tú.

El acumulador de contexto

❌ *Nunca usa /clear, mantiene un contexto de 50 mensajes*

El contexto desactualizado degrada la calidad de las respuestas. Limpia a menudo, especialmente entre tareas.

El soñador vago

❌ "Build me Twitter"

Demasiado ambicioso, sin restricciones, sin arquitectura. Obtendrás algo, pero no lo que querías.

Encontrar tu flow

Los desarrolladores que más sacan de Claude Code comparten algunos patrones:

Limpian a menudo. Contexto fresco para cada tarea. Ver Parte 2.

Planifican primero. Decisiones de arquitectura antes de la implementación. Ver Parte 3.

Usan comandos para la repetición. Flujos de trabajo codificados, no prompts repetidos. Ver Parte 4.

Verifican la seguridad. Siempre revisan autenticación, pagos y manejo de datos manualmente.

Iteran rápido. Ciclos de feedback rápidos, ajustes pequeños, no intentos perfectos a la primera.

Saben cuándo alejarse. Cuando Claude está en bucle, añaden contexto o usan ultrathink.

La mentalidad de velocidad

Una vez que internalizas el rol de director, algo cambia. Empiezas a pensar en términos de qué construir en lugar de cómo construirlo.

Un vibe coder experimentado podría pensar:

"I need a way to export user data"
→ "CSV and JSON formats"
→ "Use the existing export pattern from reports"
→ "Add it to user settings"

Y luego le dice exactamente eso a Claude. La implementación se convierte en un detalle—importante, pero no donde va tu carga cognitiva.

Este es el desbloqueo de productividad. No que Claude escriba código por ti, sino que puedes operar a un nivel más alto de abstracción mientras sigues entregando software funcional.

Serie completa

Ahora has cubierto el kit completo de Claude Code:

1. Primeros pasos — Instalación, primeros comandos, la mentalidad
2. Modelo mental — Cómo piensa Claude, gestión de contexto
3. Configuración de proyecto — CLAUDE.md y ajustes
4. Comandos personalizados — Comandos slash para flujos de trabajo
5. Skills — Módulos de conocimiento auto-cargados
6. Subagentes — Trabajadores especializados en paralelo
7. Servidores MCP — Integración con servicios externos
8. Flujos de producción — GitHub Actions, patrones de equipo
9. Secretos de usuario avanzado — ultrathink, modo headless, funciones ocultas
10. Filosofía del Vibe Coding — La mentalidad que une todo

Las herramientas son solo herramientas. La mentalidad—saber cuándo hacer vibe, cuándo verificar, cuándo planificar, cuándo dejar que Claude se lance—eso es lo que marca la diferencia.

Ahora ve y construye algo.