Kitze: Por Qué 'Vibe Engineering' Funciona y 'Vibe Coding' No

Por Qué Kitze Distingue Vibe Engineering de Vibe Coding

Kitze es el creador de Sizzy (un navegador para desarrolladores), Zero to Ship, y varias otras herramientas. Esta charla de conferencia distingue “vibe coding” (aceptar lo que sea que la IA produce) de “vibe engineering” (dirigir agentes con conocimiento técnico). Su tesis: los escépticos en el medio de la distribución de habilidades están equivocados, mientras que los juniors que lo aman y los seniors que lo dominan ambos tienen razón—por diferentes razones.

Sobre el espectro de adopción: “On one hand you have juniors who are like ‘hell yeah, give me the thing, I love doing my own SaaS.’ Then you have super senior people doing libraries and frameworks. And then you have the majority in the middle like ‘this will never be good enough, my code is perfect.’ It’s hilarious, but it’s a pattern.” (Por un lado tienes juniors que dicen ‘diablos sí, dame la cosa, amo hacer mi propio SaaS.’ Luego tienes gente super senior haciendo bibliotecas y frameworks. Y luego tienes la mayoría en el medio como ‘esto nunca será suficientemente bueno, mi código es perfecto.’ Es gracioso, pero es un patrón.) La distribución es bimodal: principiantes entusiastas y practicantes experimentados, con niveles medios escépticos en medio.

Sobre qué es realmente vibe engineering: “I’m not vibe coding. I love this term someone coined—vibe engineering. When you’re actually using agents to code all the time but you just look at your screen like ‘I’m going to catch you.’ You’re suspicious of the code because it’s based on our knowledge.” (No estoy haciendo vibe coding. Me encanta este término que alguien acuñó—vibe engineering. Cuando realmente estás usando agentes para programar todo el tiempo pero solo miras tu pantalla como ‘te voy a atrapar.’ Eres sospechoso del código porque está basado en nuestro conocimiento.) La distinción: los vibe coders aceptan ciegamente, los vibe engineers supervisan activamente.

Sobre cómo Composer One cambió todo: “Composer One made me realize I missed coding. What I would do is let a model run like GPT-5 Codex and it would take 37 years. Now I’m back in the driver’s seat. I can be like ‘Stop. No no no. We do the other thing.’ It feels like coding.” (Composer One me hizo darme cuenta de que extrañaba programar. Lo que hacía era dejar que un modelo corriera como GPT-5 Codex y tomaría 37 años. Ahora estoy de vuelta en el asiento del conductor. Puedo decir ‘Para. No no no. Hacemos la otra cosa.’ Se siente como programar.) La velocidad de los ciclos de retroalimentación importa más que la capacidad del modelo.

Sobre los devs PA (pain-in-the-ass, difíciles de tratar): “You leave a nitpick comment on a two-line PR. You spend more than 2 minutes on a PR review. The thought of agreeing with a colleague causes stomach pain. You say ‘well actually’ in code comments.” (Dejas un comentario quisquilloso en un PR de dos líneas. Pasas más de 2 minutos en una revisión de PR. El pensamiento de estar de acuerdo con un colega causa dolor de estómago. Dices ‘bueno, en realidad’ en comentarios de código.) La mayor barrera para la adopción de IA no es la capacidad—es el perfeccionismo que ya era contraproducente.

Sobre ganancias reales de productividad: “I achieved in two weeks more than I achieved in last year. This was solely due to Composer One. I was about to abandon projects… I moved Benji to Next 16 with App Router, TRPC, Monorepo, Turbo Repo, React Native app, and put in 90% of the features—in less than a week.” (Logré en dos semanas más de lo que logré el año pasado. Esto fue únicamente debido a Composer One. Estaba a punto de abandonar proyectos… Moví Benji a Next 16 con App Router, TRPC, Monorepo, Turbo Repo, app de React Native, y puse el 90% de las características—en menos de una semana.) La velocidad habilita proyectos que de otra forma no existirían.

6 Ideas de Kitze sobre Desarrollo Asistido por IA

• Vibe engineering ≠ vibe coding - Vibe coding es aceptar ciegamente el output; vibe engineering es supervisar agentes con conocimiento técnico y atrapar errores en tiempo real
• Dale IA a seniors, no a juniors - “No le des herramientas de IA a tus pasantes y juniors. Si tomas a tu senior escéptico y lo convences de hacer vibe engineering, obtienes resultados 10x”
• Composer One es un cambio de paradigma - Los ciclos de retroalimentación rápidos te permiten quedarte en el asiento del conductor; los modelos lentos empujaban a la gente a YouTube Shorts mientras esperaban
• Los devs PA son el verdadero bloqueador - El perfeccionismo que demanda abstracciones óptimas y critica PRs de dos líneas es contraproducente con o sin IA
• A los LLMs no les importa el código repetitivo - Esta es una característica: los humanos sobre-abstraen muy temprano, los LLMs felizmente duplican cuando es apropiado
• Los requisitos de habilidad cambiaron, no desaparecieron - Conocer los límites del modelo, gestión de contexto, ingeniería de prompts, y juzgar código “suficientemente bueno” son nuevas habilidades requeridas

Qué Significa Esto para la Productividad del Desarrollador

La charla de Kitze reenmarca el debate de programación con IA: el problema no es la capacidad de IA, es el perfeccionismo humano. “Vibe coding” falla porque es un juego de azar sin supervisión. “Vibe engineering” funciona porque combina la velocidad de IA con el juicio humano sobre qué es suficientemente bueno. La ironía: los desarrolladores que ya eran pragmáticos sobre la calidad del código (vs. perfeccionistas que sobre-abstraen) son los que están prosperando. La habilidad no es escribir en inglés—es saber cuándo el código es suficientemente bueno, que siempre fue la parte más difícil de la ingeniería.