El culto al vibe coding está fuera de control

• A raíz de la filtración del código fuente de Claude, quedó en evidencia cuánto puede dañar a la calidad real de un proyecto la fe ciega en el "vibe coding"
• El vibe coding parte del principio de no mirar en absoluto el interior del código, pero eso no es más que una superstición pura; en la práctica, siempre requiere diseño estructural humano, como archivos de planificación, skills y reglas
• La IA de verdad es muy buena para tareas como eliminar duplicación de código y ordenar deuda técnica, pero para aprovechar eso, una persona tiene que revisar el código, identificar el problema y explicárselo a la IA
• Rara vez la IA reconoce por sí sola "hay código espagueti, hay que ordenarlo"; los mejores resultados aparecen cuando una persona aporta primero dirección y contexto
• Como dice la frase "el mal software es una elección del desarrollador", el deterioro de la calidad no es culpa de la IA, sino resultado de decisiones
• Es decir, la baja calidad del software no es culpa de la IA, sino de las elecciones que toma el propio desarrollador

---

La filtración del código fuente de Claude y el problema del vibe coding

• Se filtró el código fuente de Claude y muchas personas se burlaron de él porque la calidad del código es baja
• Como causa del problema se señaló el exceso de dogfooding, es decir, una cultura de uso demasiado ciego de su propio producto
• El dogfooding en sí es una buena idea, pero puede deformarse hasta convertirse en una actividad casi de culto que supera cualquier límite razonable

Qué es realmente el vibe coding

• El vibe coding es un enfoque cuyo principio consiste en no aportar nada al interior del código, e incluso no mirarlo
• Sin embargo, el vibe coding puro es un mito: en la práctica siempre existen frameworks creados por humanos, como archivos de planificación (listas de tareas), skills y reglas, y sin esa estructura la IA rinde muy mal
• Aunque el código está escrito en inglés y cualquiera puede leerlo, los desarrolladores se niegan a verificarlo directamente con la lógica de que "mirar adentro es hacer trampa"
• De hecho, cuando una sola persona revisó el código, descubrió que había duplicación masiva entre agentes y herramientas, un problema que cualquiera habría podido detectar con solo mirar un momento

IA y limpieza de deuda técnica

• Los proyectos de software suelen comenzar arrastrando deuda técnica, y antes había casos en los que ordenar eso tomaba hasta un año
• Con IA, ese trabajo de limpieza puede completarse en pocas semanas, o resolverse gradualmente en paralelo al desarrollo de nuevas funciones
• La IA es muy buena ordenando código, pero le cuesta detectar problemas por sí sola: los buenos resultados llegan cuando una persona le dice "aquí hay código espagueti" y le da una guía

La forma correcta de usar IA: un enfoque basado en conversación

• Como forma correcta de resolver el problema de duplicación, se proponen pasos como estos:
  • Hacer una lista de elementos que correspondan tanto a agentes como a herramientas
  • Revisar ejemplos y decidir si cada elemento es un agente o una herramienta
  • Discutir el criterio general y establecer lineamientos generales
  • Auditar todos los elementos y corregir los que estén mal clasificados
  • Para los elementos que existen en ambos lados, revisar ambas versiones y unificarlas en una sola
• El modo Ask existe para este proceso, y la parte clave es revisar ejemplos juntos y corregir a la IA cuando intenta dar la razón en exceso
• Después de suficiente conversación, puede parecer que la IA produjo un resultado tipo one-shot, pero en realidad ese resultado presupone mucha interacción previa con una persona
• El equipo de Claude, sin pasar por ese proceso, llevó el dogfooding al extremo y rechaza incluso el esfuerzo mínimo de mirar un momento dentro del código y explicar el problema

Casos reales de uso

• Ejemplo de su flujo de trabajo: al comenzar una conversación dice "auditemos el código inalcanzable en esta base de código" o "esta función daña la vista", y así inicia el diálogo
• Sigue conversando hasta que aparece una dirección ejecutable, explica qué hay que hacer y continúa discutiendo hasta que la IA deja de decir tonterías
• Después, planificar y ejecutar el build forma parte del trabajo cotidiano

La calidad del software es una cuestión de elección

• Usar IA no significa que haya que aceptar software de baja calidad
• También puede haber bibliotecas de mala calidad hechas por desarrolladores sobrepagados incluso sin ayuda de IA
• El mal software es una decisión que uno toma por sí mismo; hay que asumir la responsabilidad por eso y aspirar a una mejor calidad

[koreacglee]

Mientras hacen FULL AUTO MATION con AI AGENT y automatizan por completo la generación de código, el merge, la revisión y hasta la validación, como si todo quedara totalmente autónomo y no hubiera que preocuparse en lo más mínimo, salvo cuando a veces los agentes se enredan entre sí o cuando apenas tiene que intervenir un desarrollador, se ha vuelto demasiado común ese ambiente donde tratan como anormales a los desarrolladores que no pueden hacerlo, como si fueran gente que no sigue la tendencia... Viendo a esos que, en el día a día, no hacen más que soltar código súper boilerplate y cadenas de patrones simples mientras cobran sueldazos, y luego abren la boca diciendo que con AI ya ni hace falta programar, la verdad es que dan pura pena.

[kurthong]

Hay que micromanejar hasta las partes más triviales para producir código de una calidad más o menos decente. Creo que la automatización completamente autónoma no tiene ningún sentido salvo para producir en masa código realmente de boilerplate. La gente que habla de autonomía total cae en una de dos: o no entiende bien de qué habla, o es una estafadora.

[blacksocks]

Abundan los proyectos a medio hacer…
Y la gente que apenas entiende la programación se entusiasma…

[qwertypotter]

Creo que es mejor entender dogfooding no como acaparamiento exclusivo, sino como "dog pudding".

[caniel]

dog食...

[iolothebard]

¿El título y el contenido son diferentes...?

[summerpicnic]

Parece más bien una crítica que concluye que el vibe coding equivale a no hacer revisión de código y luego le pega razones para justificarlo.

Además, tampoco tiene sentido meter a claude code en esto. Si de verdad vas a exigir un nivel de calidad y principios de ingeniería del calibre, por ejemplo, del mantenimiento de Linux, no abordarías los problemas de calidad de código de una forma tan fragmentaria. Casi todo esto parece un enfoque propagandístico, más de "dicen que es así" que de haberlo probado directamente.

Es parecido a decir que el diseño de los edificios de Samsung no es gran cosa y que todavía está lejos de alcanzar a Sony.

[euphcat]

Cuando probé Claude Code por primera vez, les dije a unos amigos extranjeros: "¡Acabo de probar el vibe coding por primera vez!" Pero después de escuchar lo que les conté, me respondieron: "No, eso no es vibe coding; el vibe coding de verdad es hacer cosas sin siquiera revisar el código". Parece que el "vibe coding" del que se habla comúnmente en nuestro país se define de una forma mucho más amplia que en Occidente. El vibe coding del que se habla en Hacker News sí se define básicamente como "no hacer code review".

[GN⁺]

Opiniones de Hacker News

• Es raro que la gente ponga como ejemplo la calidad del código filtrado de Claude Code para decir que el ‘vibe coding’ fracasó
  Más bien es al revés. Creo que es una prueba de que se pueden crear productos populares y exitosos aunque se rompan las reglas tradicionales del “buen código”

  • La mayor parte del código de producto que he visto también fue impactante a primera vista. Así era tanto en BigCo como en startups
    Muchas veces el código improvisado para cumplir con una fecha límite se queda tal cual en producción
    Incluso en proyectos personales, los primeros commits son un desastre y recién después uno hace una rama de limpieza para ordenarlo
    Pero en las empresas casi nunca hay tiempo para una segunda o tercera versión, así que al final se despliega el primer borrador
    Sinceramente, hasta me preocupa que se filtre código con mi nombre. Pero esa es la realidad
  • El mal código funciona bien a corto plazo, pero a largo plazo inevitablemente causa problemas
    Si al cambiar código sientes que “esto está medio forzado”, corregirlo en ese momento termina ahorrando tiempo
    Todavía no tengo tanta experiencia con los LLM como para estar seguro
  • Eso de que “puedes tener éxito aunque rompas las reglas del buen código” en realidad siempre ha sido así desde antes
  • El “vibe coding” tiene un espectro según el grado de intervención humana
    Claude Code es, en esencia, un producto simple, y el valor real está en el modelo en sí
    Es decir, este caso fue posible porque es un producto de bajo riesgo donde una baja calidad de código no causa un gran problema

• Tampoco rompe el concepto de “vibe coding”. La estructura consiste en dar solo ideas abstractas de alto nivel y que la IA escriba el código real
  Claude Code está en el nivel AI Level 7 (el humano define la especificación, el bot hace el código), y el autor sostiene que el nivel 6 es mejor
  Cada persona tiene un nivel ideal distinto. Algunos creen que el límite está en el nivel 5 o menos, y otros piensan que a partir del nivel 2 ya es peligroso

  • En el campo de visión por computadora donde trabajo, la UI o la app están más o menos en nivel 6~7, pero en cambio en el pipeline de renderizado o los algoritmos la intervención de la IA más bien estorba
    El nivel adecuado cambia según la complejidad y la novedad del área
  • La clave para aprovechar bien la IA es aplicar niveles distintos según la parte
    Por ejemplo, en la app que hago, la parte de algoritmos está en nivel 0, la UI en nivel 7 y el middleware en algún punto intermedio
    La verdadera habilidad está en encontrar el nivel adecuado para cada zona del código
  • Yo trabajo más o menos en nivel 5. Pongo muchas barandillas de seguridad con TDD, seguridad de tipos, redacción de especificaciones, etc.
    En lenguajes dinámicos, ir más allá de eso me da desconfianza. Si fuera a nivel 7 o más, creo que sería mejor cambiar por completo a un lenguaje con tipos estáticos
  • Las personas que más van a avanzar en el futuro serán los desarrolladores que empujen esta escala hasta su nivel más alto
    Programar quedará como la herrería: una parte pequeña seguirá existiendo, pero la mayor parte se automatizará
    Pero gracias a eso, una sola persona podrá hacer lo que antes hacía un equipo completo
  • En el trabajo estoy en nivel 4, pero en proyectos personales me voy colando hasta nivel 6
    La tentación de aceptar una función sin entender por completo cómo funciona es grande

• El autor de este texto es el creador de BitTorrent. No es un bloguero cualquiera

  • Da gusto ver a Bram volver a participar en este tipo de discusiones
  • La mayoría ni siquiera sabe qué es BitTorrent, pero igual parece que sí capta la ‘vibra’
  • Considerando su trayectoria, creo que debió haber mostrado un poco más de fundamento para sus afirmaciones

• El uso que más me gusta de Claude Code es mejorar la calidad del código
  Cosas que si las hiciera una persona parecerían una pérdida de tiempo están bien si la IA las hace casi gratis
  Ordenar patrones repetitivos de tests, mantener consistencia en la serialización JSON, eliminar código duplicado, etc.
  Al final, la base de código se vuelve más pequeña y más fácil de mantener. Es como una especie de linting a gran escala

  • Yo hago algo parecido y pongo varios modelos (Opus, GPT5.4, Gemini) a correr en paralelo para detectar bugs y mejorar código
    Cruzo y verifico los resultados que genera cada modelo, y al final Opus arma la lista final para corregir
    Hay muchos cambios innecesarios, pero los problemas que detecta sí resultan útiles

• La perspectiva de “dogfooding” es interesante
  El punto no es la calidad del código, sino si el usuario puede evaluar críticamente los resultados de la IA
  Una cosa es que un ingeniero con experiencia use IA manteniendo su criterio, y otra muy distinta es delegar ese criterio a la IA
  El problema es que las herramientas no distinguen entre ambas cosas, y el marketing está dirigido a lo segundo

• Quienes apoyan el ‘vibe coding’ sostienen que, como los LLM pueden iterar muchísimo más rápido que los humanos, la calidad del código no importa
  Para los humanos, cada etapa (escribir–verificar–corregir) cuesta caro, pero los LLM pueden iterar rápido pagando solo el costo de tokens
  Pero yo soy escéptico con ese enfoque. He visto demasiados casos donde se rompe en la práctica
  Aun así, si los LLM siguen mejorando, tal vez ellos tengan razón

• En el espectro del “vibe coding” hay dos grupos
  Uno es el de personas sin base técnica a quienes les encanta porque les parece fascinante, y el otro es el de los anti-IA
  En medio hay una capa intermedia, silenciosa pero muy productiva. Son optimistas, pero también tienen experiencia
  Yo también he gastado unos $2500 en créditos de Claude Code durante los últimos 6 meses, y aunque la mayor parte no terminó realmente desplegada, obtuve un valor enorme

  • Hay quien pregunta cómo se mide esa “mejora de productividad”. Es difícil cuantificarla, pero la sensación es clarísima

• No estoy de acuerdo con la afirmación de que “Claude Code es inútil”
  La mayoría de las web apps son CRUD simples. El 99% de las empresas ni siquiera tiene 50 mil usuarios

  • Las apps empresariales tienen pocos usuarios, pero una carga de CPU o base de datos mucho mayor
    En una empresa donde trabajé, por culpa de código ineficiente había que correr un programa 22 horas al día
  • Hay que distinguir entre “usuarios” y “usuarios de pago”. No significan lo mismo
  • De hecho, incluso desplegar para 100 personas ya es un infierno total. No creo que vaya a llegar la era de los ‘desarrolladores ciudadanos’

• Este fenómeno me recuerda a la teoría de la innovación de Clayton Christensen
  Las empresas establecidas se conforman con sus productos actuales, que son rentables, e ignoran nuevas tecnologías de baja calidad, pero al final esas tecnologías mejoran lo suficiente como para darle vuelta al mercado
  Claude Code ya está en un nivel “lo suficientemente bueno”, y si la IA sigue avanzando, al final va a superar al código escrito a mano

  • Incluso si el avance de la IA se detuviera, crearíamos nuevas herramientas y patrones centrados en los modelos actuales
  • Pero el ambiente de ahora es demasiado optimista. Ya se habla de ejecutivos que quieren eliminar testing y code review. Parece que están subestimando el riesgo

• Alrededor del ‘vibe coding’ se pueden distinguir varios tipos de personas
  ① quienes tienen intereses económicos, ② desarrolladores cansados de programar, ③ principiantes que por primera vez están creando algo
  El grupo ② no quiere aprender cosas nuevas, y el ③ está disfrutando de verdad la alegría de crear
  La programación con IA puede ser una buena ruta de entrada para ellos

  • También hay otro grupo. Son personas de alto rendimiento que aman programar pero quieren crear más cosas
    Yo soy de ese tipo. Llevo 30 años amando programar, pero tardaba demasiado en convertir en realidad lo que imaginaba
    Ahora esa brecha desapareció y siento una liberación. Mi objetivo es aprender a mantener la calidad mientras aumento la velocidad
  • Yo también he visto a ingenieros excelentes usar la IA de forma activa y aun así sin bajar sus estándares, logrando más resultados
  • De hecho, la industria del software de los últimos 10 años fue una era de complejidad innecesaria
    Por copiar tal cual los problemas de las grandes empresas, bajó la productividad y solo aumentó el cansancio
    Ahora, gracias a la IA, podemos ignorar esa complejidad y obtener resultados directamente
    Aunque salga un nuevo framework o una nueva forma de desplegar, ya no hace falta preocuparse. La IA se encarga de todo
  • Pero quizá no se trate de “personas que no quieren aprender”, como dices, sino de gente que justamente está aprendiendo cosas nuevas
    Cada vez que ocurre un relevo generacional en la tecnología, este tipo de conflicto se repite
  • Personalmente, la falta de prolijidad de estos días más bien me está haciendo perder el interés