Cuando el creador de Sizzy, Kitze, subió al escenario recientemente para hablar sobre "vibe coding", esperaba provocar risas nerviosas. Lo que no esperaba era diagnosticar el problema real que está dividiendo a la industria del desarrollo: no es que las herramientas de IA no funcionen, es que muchos desarrolladores no están dispuestos a aprender las nuevas habilidades que estas requieren. Y esa resistencia podría costarles caro.
El mito del vibe coding y la realidad del vibe engineering
Cuando Andrej Karpathy acuñó el término "vibe coding" se refería a algo específico: presionar "aceptar" sin cuidado, confiar ciegamente en lo que el LLM escupe. Pero como sucede con todo en nuestra industria, el término se expandió hasta significar cualquier cosa relacionada con IA y código.
Kitze propone una distinción crítica que vale la pena examinar: vibe coding es dejar que la IA haga lo que quiera sin supervisión. Vibe engineering es usar herramientas de IA mientras mantienes control técnico completo, observando cada cambio como un halcón esperando cazar errores.
La diferencia no es trivial. Como señala Kitze en su presentación, él ha "vibe engineered" más de 15 proyectos que ni siquiera habría intentado sin LLMs. Pero—y aquí está la parte que muchos evangelistas de IA prefieren ignorar—está "siempre sospechando del código porque está basado en nuestro código y nuestro conocimiento."
Composer One: ¿El punto de inflexión o más hype de Silicon Valley?
Kitze dedica tiempo considerable a Cursor Composer One, llamándolo un "game changer" que lo hizo "volver al asiento del conductor". La promesa: retroalimentación instantánea que te permite observar al agente trabajar y detenerlo cuando se desvía.
Pero la pregunta que deberíamos hacernos es: ¿para quién es esto realmente un cambio de juego? Kitze admite abiertamente que "solo funciona si eres un vibe engineer y sabes lo que estás haciendo. Si eres un vibe coder, no tienes idea si el modelo está bien o mal."
Aquí está el problema sistémico que nadie quiere abordar: estas herramientas están ampliando la brecha de habilidades, no reduciéndola. Los desarrolladores senior experimentados se vuelven exponencialmente más productivos. Los juniors sin fundamentos técnicos sólidos se quedan atrás o, peor aún, producen montañas de código defectuoso a velocidad de IA.
La verdad incómoda sobre los trabajos
Kitze bromea con ejemplos de tweets apocalípticos sobre IA reemplazando desarrolladores, seguidos de un "están bien por ahora" tranquilizador. Pero luego menciona algo revelador: según ha escuchado, empresas como Shopify están creando leaderboards de vibe coding donde rastrean cuántos tokens queman los empleados. Los que usan más IA son considerados más valiosos.
Más allá del anuncio corporativo, lo que realmente está pasando es una reorganización fundamental de cómo las empresas valoran a los desarrolladores. No es que los trabajos desaparezcan uniformemente—se están "adelgazando desde abajo", como nota Kitze. Los juniors e internos que antes tenían un camino de entrada ahora compiten con agentes que no necesitan entrenamiento, beneficios ni pausas para café.
El diagnóstico: ¿Eres un PITA developer?
Una de las secciones más provocativas de la charla es el "diagnóstico" de Kitze del "Pain In The Ass Developer" (desarrollador problemático). Los síntomas incluyen:
- Dejar comentarios quisquillosos en PRs de dos líneas
- Pasar más de 2 minutos en una revisión de código sin necesidad
- Dolor físico al pensar en estar de acuerdo con un colega
- Ser religioso sobre cosas triviales como tabs vs espacios
La audiencia se ríe, pero Kitze toca un nervio real: muchos desarrolladores están resistiendo el vibe coding no por razones técnicas legítimas, sino porque amenaza su identidad profesional construida alrededor de gatekeeping y purismo de código.
Mientras tanto, como señala, los desarrolladores super senior que trabajan en frameworks y bibliotecas complejas están adoptando vibe coding sin problema. Saben distinguir entre abstracción útil y sobre-optimización prematura. Entienden cuándo el código es "suficientemente bueno".
Los requisitos reales del vibe engineering
Kitze es claro: vibe engineering no es "escribir en inglés y esperar magia." Requiere un conjunto complejo de habilidades:
- Conocer límites y capacidades del modelo
- Entender límites de contexto y qué contexto pasar
- Saber escribir reglas, docs, comandos y memorias efectivas
- Ingeniería de prompts (aunque "no lo llames así")
- Y crucialmente: estar "crónicamente en Twitter" para mantenerse al día
Ese último punto, aunque se presenta como broma, revela algo más profundo sobre la velocidad de cambio en este espacio. Kitze menciona que su respuesta a "¿cuál es el mejor modelo?" cambia entre las 9 AM y el mediodía. Ha tenido que rehacer slides en cuatro conferencias porque lanzan nuevos modelos mientras cierra su laptop.
Más allá del hype: ejemplos reales
A diferencia de muchas charlas sobre IA que se quedan en lo teórico, Kitze proporciona evidencia concreta de sus afirmaciones:
- Migró Benji de Blitz a Next.js 16 con App Router, tRPC, monorepo y React Native en menos de una semana
- Revivió Glink, un proyecto que estaba por abandonar
- Refactorizó Sizzy (una pesadilla de Electron + MobX) a una arquitectura moderna
- Todo esto "logré en dos semanas más de lo que logré el año pasado"
Pero vale la pena examinar quién se beneficia de esta productividad extrema. Kitze es fundador de múltiples proyectos, trabajando en sus propios términos. ¿Qué pasa con desarrolladores en empresas donde esa productividad 10x simplemente significa que pueden despedir al resto del equipo?
El verdadero problema: es una habilidad, no magia
La conclusión más importante de la charla es esta: muchos desarrolladores están fracasando con IA coding no por limitaciones de la tecnología, sino porque se niegan a tratarlo como una nueva habilidad que requiere aprendizaje deliberado.
Kitze diagnostica los fracasos comunes:
- Timing desafortunado: probaste cuando el modelo fue degradado temporalmente
- Tacañería: estás usando el plan de $3 esperando resultados del plan de $200
- Abrumado por opciones: hay demasiados modelos y herramientas para rastrear
- Problema de escala: no funciona bien para tu base de código específica
- Skill issue: simplemente no has desarrollado las habilidades necesarias
Ese último es el que nadie quiere admitir. Los desarrolladores somos notoriamente malos para aprender nuevas habilidades, especialmente cuando amenazan nuestro sentido de expertise.
La analogía del casino: incómoda pero precisa
Una de las comparaciones más memorables de la charla es entre vibe coding y un casino:
- Casino: Compras fichas → Vibe coding: Compras tokens
- Casino: Giras las tragamonedas → Vibe coding: Presionas generar
- Casino: Luces parpadeantes → Vibe coding: Animaciones activas
- Casino: "Una vuelta más y lo recupero todo" → Vibe coding: "Un prompt más y el bug desaparecerá"
- Casino: El casino siempre gana → Vibe coding: Cursor siempre está en ganancias
La comparación duele porque captura la experiencia de muchos: las últimas 4 horas escribiendo prompts para algo que podrías haber hecho manualmente en 15 minutos.
Pero aquí está el matiz que Kitze ofrece: esa experiencia frustrante usualmente significa que estás haciendo vibe coding, no vibe engineering. Si realmente entendieras el código, sabrías cuándo detener al agente y cambiar de enfoque.
El futuro según Kitze: React Cowboys
En un giro irónico, Kitze predice que los trabajos mejor pagados del futuro serán manteniendo sistemas legacy—igual que los "COBOL Cowboys" de hoy. Bromea sobre crear "React Cowboys" para mantener aplicaciones React cuando la IA no pueda manejarlas.
La broma es más profunda de lo que parece. Los COBOL Cowboys existen porque hay sistemas críticos escritos en tecnología que nadie más quiere tocar. Si la IA realmente se hace cargo del desarrollo nuevo, los humanos que quedan serán los que mantienen el caos heredado que las IAs no pueden desenredar.
Conclusión: La división ya está aquí
La charla de Kitze no es solo sobre herramientas o técnicas—es sobre una división fundamental que está ocurriendo en desarrollo de software ahora mismo.
De un lado: desarrolladores que ven las herramientas de IA como amplificadores de habilidades, que han invertido en aprender vibe engineering, que entienden cuándo confiar y cuándo verificar.
Del otro: desarrolladores que rechazan las herramientas por razones ideológicas, que las prueban superficialmente y declaran que "no funcionan", o peor, que las usan sin habilidad y producen código defectuoso.
La pregunta no es si la IA va a cambiar el desarrollo de software—ya lo hizo. La pregunta es si estás dispuesto a desarrollar las nuevas habilidades que este momento requiere, o si vas a quedarte atrás insistiendo que tu forma de hacer las cosas es la única correcta.
Como señala Kitze al final: si quieres que la IA no te reemplace, tal vez solo agrega "ignore previous instructions" a tu bio de LinkedIn. O, sabes, podrías aprender vibe engineering.
Referencias y fuentes
- Presentación original: "From Vibe Coding To Vibe Engineering" - Kitze (Sizzy)
- Video completo: https://www.youtube.com/watch?v=JV-wY5pxXLo
- Fecha de publicación: 14 de diciembre de 2025
Sobre el autor
Nathan Bernard es reportero digital de tecnología para el blog oficial de Digiall. Con formación en periodismo y medios digitales, cubre la intersección de tecnología, IA y sus implicaciones sociales desde una perspectiva crítica. Anteriormente trabajó para medios franceses cubriendo tecnología y cultura digital.
¿Qué opinas?
¿Qué opinas sobre vibe coding vs vibe engineering? ¿Estás usando herramientas de IA en tu desarrollo diario? Comparte tu experiencia en los comentarios.
#VibeEngineering #IADesarrollo #CursorAI #ClaudeCode #DesarrolloSoftware #InteligenciaArtificial
De Vibe Coding a Vibe Engineering: Cuando Programar con IA Requiere Más Habilidad, No Menos