La programación por "vibe" no puede ser una excusa para hacer trabajo de baja calidad
(addyo.substack.com)- La programación por vibe impulsada por IA es innovadora, pero este texto advierte que la velocidad sin calidad es peligrosa
"Muévete más rápido y rompe más cosas"
"vibe coding, la forma en que dos ingenieros pueden crear deuda técnica para 50 personas"
- Esta reformulación irónica de un viejo eslogan de Silicon Valley ha estado circulando recientemente en la comunidad de ingeniería bajo el concepto de "vibe coding"
- Es cierto que el desarrollo impulsado por IA está revolucionando la forma de crear software, pero eso no es una licencia para abandonar el rigor, las revisiones y la artesanía
- El "vibe coding" no puede ser una excusa para justificar trabajo de baja calidad
- Reconociendo sus ventajas, la programación asistida por IA puede ser un game changer
- Reduce la barrera de entrada para nuevos programadores o personas no técnicas, y les permite crear software funcional con solo describir lo que necesitan
- Esto libera la creatividad y permite que más personas resuelvan sus propios problemas directamente con software a medida
- Esta corriente se considera parte de la tendencia de desagregación del software personal (usar pequeñas herramientas impulsadas por IA en lugar de apps prefabricadas)
- Los ingenieros experimentados también pueden beneficiarse
- Pero, como diría cualquier ingeniero con experiencia, la velocidad no sirve de nada si al final se te sale una rueda
- Y justo ahí es donde empiezan a aparecer las grietas: la diferencia entre el vibe y la realidad, es decir, la realidad de construir software mantenible y robusto
La verdad incómoda: la calidad no viene automáticamente
- Hay mucho hype, pero el escepticismo de los desarrolladores veteranos frente al vibe coding tampoco es menor
- La crítica central es esta: que la IA produzca código rápido no significa que ese código sea bueno
- De hecho, confiar y usar código generado por IA tal cual puede ser bastante riesgoso
- La broma de que “dos ingenieros crean deuda técnica equivalente a 50 personas” no es del todo una broma
- El código de IA no revisado puede multiplicar la deuda técnica a gran escala
→ Esa deuda vuelve el código vulnerable y difícil de mantener, y a largo plazo genera costos enormes
- Los proyectos hechos con vibe coding a menudo se ven bien por fuera ("¡funciona bien, despleguémoslo!")
- Pero en realidad esconden riesgos como estos:
- No tienen manejo de errores
- Tienen bajo rendimiento
- Sus mecanismos de seguridad son inestables
- Su estructura lógica es débil y frágil
- Ese tipo de proyectos son como estructuras construidas sobre arena
- Y, como me gusta llamarlos, son "house of cards code" —
parecen terminados por fuera, pero colapsan fácilmente bajo presión real - Si alguna vez viste la primera gran funcionalidad de un desarrollador junior que casi funciona pero se rompe de inmediato con una sola entrada inesperada, ya sabes de qué sensación se trata
- La IA puede producir grandes cantidades de código rápidamente, pero cantidad no significa calidad
- "La IA es como un desarrollador junior muy entusiasta que se sumó al equipo"
- → Esta idea queda bien explicada en una ilustración de Forrest Brazeal
- Este riesgo no es solo una hipótesis; también es un problema real desde el punto de vista del mantenimiento
- Si un módulo generado por IA es demasiado complejo o difícil de entender, ¿quién se va a encargar de mantenerlo?
- Incluso si el desarrollador que lo escribió originalmente tampoco entiende por completo el código generado por IA,
ese código puede convertirse en una pesadilla para futuras modificaciones o ampliaciones
- La seguridad es otro gran problema
- La IA puede producir código que en apariencia funciona bien, pero por dentro puede esconder vulnerabilidades críticas como inyección SQL
- O también puede tener un manejo de errores deficiente
- Si esos problemas llegan a producción sin una revisión exhaustiva, pueden terminar provocando incidentes reales
- Otro problema más es el sobreajuste al prompt (overfitting to the prompt)
→ La IA hace exactamente lo que le pides, pero eso puede ser distinto de lo que realmente se necesita - Los desarrolladores humanos detectan errores de diseño o malentendidos mientras implementan y los corrigen
- En cambio, la IA no detecta en absoluto esos malentendidos, y si una persona no los identifica y corrige, el problema queda ahí
- Por supuesto, nada de esto significa que la IA nunca pueda escribir buen código —
- A veces la IA produce código excelente
- Pero para decidir si ese código realmente se puede usar, siempre hacen falta estas tres cosas:
- contexto (context)
- revisión crítica (scrutiny)
- experiencia y criterio (expertise)
- En 2025, la IA que usamos se parece más a un asistente lleno de entusiasmo pero con poca experiencia
- Así como no le encargarías a un desarrollador recién llegado el diseño completo de un sistema sin supervisión,
tampoco deberías aceptar código de IA sin revisarlo - La expectativa del “AI magic” ahora tiene que armonizarse con la realidad de la ingeniería de software
- Entonces, ¿cómo se logra el equilibrio?
- Lo importante es que no hace falta rechazar por completo el vibe coding
- El vibe coding a veces puede ser muy útil
- Pero lo clave es integrarlo de forma disciplinada; es decir, ver la IA como una herramienta con límites claros
- Eso implica que la persona debe seguir dentro del loop, y que usemos la IA de una manera que respete nuestros estándares de calidad y principios de ingeniería
La IA no es reemplazo, es pasante (la persona debe seguir dentro del loop)
- Para aprovechar bien el vibe coding, hace falta un cambio de mentalidad: tratar a la IA como “un pasante de desarrollo muy rápido, pero inexperto”
- Es decir, tú —como ingeniero senior o líder de equipo— sigues siendo la persona con la responsabilidad final sobre el resultado
- La IA puede sacar un primer borrador rápidamente, pero hay que revisarlo con ojo crítico, corregirlo y verificar que cumpla los estándares de calidad
- Los desarrolladores experimentados siguen este proceso de manera intuitiva
- Cuando la IA propone código, no presionan “Accept” y siguen de largo; en cambio, hacen lo siguiente:
- Primero leen y entienden el código escrito por la IA — lo tratan como si lo hubiera escrito un desarrollador junior
- Si el código viene en un solo bloque o está desordenado, lo modularizan y refactorizan — lo dividen en unidades más pequeñas y claras
- Agregan por su cuenta el manejo de excepciones o edge cases faltantes — null checks, validación de entradas y demás son cosas que la IA suele omitir
- Refuerzan tipos flexibles o abstracciones incompletas — convierten supuestos implícitos en contratos explícitos
- Evalúan si la arquitectura o el enfoque elegido por la IA es ineficiente — por ejemplo, procesamiento por fuerza bruta o introducción de estado global
- Escriben pruebas o hacen pruebas manuales — si la IA generó unit tests, también hay que revisar obligatoriamente si esas pruebas son válidas
-
Todo este proceso permite inyectar criterio de ingeniería (wisdom) al código generado por IA
-
Esa combinación puede ser muy poderosa: la IA aporta velocidad y las personas garantizan confiabilidad
-
De hecho, según investigaciones y experiencia práctica, los desarrolladores senior obtienen más valor de las herramientas de programación con IA que los junior
-
La razón es que los senior tienen el conocimiento y la experiencia para guiar correctamente la salida de la IA y corregir sus errores
-
En cambio, los junior corren un riesgo mayor de confiar erróneamente en la IA como si fuera una autoridad absoluta
- Por eso surge una regla importante:
→ El código escrito por IA siempre debe incorporarse solo después de una revisión - Igual que al revisar el PR de un desarrollador nuevo, hay que leerlo línea por línea y hacer merge solo después de entenderlo por completo
- No asumas que la IA es más inteligente; en la mayoría de los casos, no lo es
- Si hay partes que no entiendes:
- conviene volver a afinar el prompt para pedirlo con más claridad, o
- reescribir tú mismo ese código
- La salida de la IA es solo un “borrador” y siempre debe pasar por revisión
- En un entorno de desarrollo en equipo:
- si alguien usó IA para crear código,
- debe poder explicarlo y defenderlo directamente en la revisión
- “es que simplemente funciona” no alcanza — solo es código de verdad si una persona puede entenderlo y mantenerlo
- Otra práctica recomendada: el diseño lo hace una persona, la implementación la hace la IA
- Es decir, la IA se aprovecha para implementar rápidamente tareas ya definidas, como una API CRUD
- En cambio, solicitudes como “diseña una arquitectura de microservicios escalable” deben quedar en manos humanas
- El diseño de alto nivel y las decisiones clave deben seguir siendo responsabilidad de las personas
- En resumen: dejemos a la IA el trabajo repetitivo (grunt work) y a las personas el pensamiento y el criterio (brain work)
- La comunicación y la documentación también se vuelven muy importantes
- Si le pediste a la IA un algoritmo complejo o una biblioteca poco familiar,
- es imprescindible documentar la razón y la intención de esa elección
- quien mantenga el código en el futuro, o tu yo del futuro, debe poder entender por qué se hizo de esa manera
- Algunos equipos incluso registran el prompt en sí usado para generar código importante con IA
→ eso resulta útil porque, al depurar, se puede consultar el “historial de conversación” con la IA
- En conclusión, la intervención humana no es opcional, sino obligatoria
- Usar solo código de IA sin una persona de por medio es como lanzar los dados con la calidad del software
- Todavía no estamos en una era en la que la IA pueda reemplazar la comprensión integral de un ingeniero senior
- La vibe coding debe ser una colaboración —
→ la IA puede aportar velocidad, y la persona se encarga de ponerle el cinturón de seguridad a esa velocidad
Reglas prácticas para una vibe coding de alta calidad
- Organicemos la discusión hasta ahora en reglas accionables y mejores prácticas
- Esto puede verse como un manual de la nueva era de “muévete rápido, pero no lo arruines todo”
- Son reglas que funcionan como barandales para mantener la calidad incluso al hacer vibe coding
- Rule 1: Always Review AI-Generated Code / Revisa siempre el código generado por IA
- Sin excepciones. Todo código escrito por IA debe revisarse como si lo hubiera escrito un desarrollador junior
- Debe hacerse sí o sí, ya sea una revisión individual o por pares
- Da igual si es Copilot, ChatGPT, Cursor o cualquier otra IA
- Si no tienes tiempo para revisar ese código, tampoco tienes tiempo para usarlo
- Hacer merge de código de IA sin revisarlo equivale a aceptar el riesgo tal cual viene
- Rule 2: Establish Coding Standards and Follow Them / Define estándares de código y cúmplelos
- La IA refleja los estilos de código con los que fue entrenada, así que si el equipo no tiene criterios consistentes, la calidad se vuelve irregular
- Hay que definir con claridad la guía de estilo del equipo, los patrones de arquitectura y las reglas de codificación
- Ejemplo: “todas las funciones deben tener JSDoc y pruebas unitarias” → eso también aplica al código generado por IA
- En proyectos que usan jerarquías o arquitectura por capas,
es imprescindible refactorizar para evitar que la IA meta llamadas a la base de datos dentro del código de UI - Se recomienda introducir reglas de lint o análisis estático para detectar errores comunes de la IA (por ejemplo: funciones complejas o uso de API deprecated)
- Rule 3: Use AI for Acceleration, Not Autopilot / La IA es un acelerador, no un piloto automático
- La vibe coding debe usarse para resolver más rápido tareas que ya conoces bien
- Buenos casos de uso:
- generación de boilerplate
- scaffolding de componentes
- conversión entre lenguajes
- redacción del esqueleto de algoritmos simples
- Casos de uso riesgosos:
- pedirle que diseñe un módulo completo con una explicación ambigua
- intentar generar código en un dominio que no conoces bien
- Si el código va a quedarse de forma permanente, hay que cambiar obligatoriamente del modo vibe al modo engineering
- Rule 4: Test, Test, Test / Hay que probar sí o sí
- Que la IA haya generado el código no significa automáticamente que esté correcto
- Es obligatorio escribir pruebas para todos los flujos principales
- Si la IA también generó las pruebas, hay que revisar si esas pruebas realmente son válidas
- Sobre todo en funciones de UI o partes con mucha entrada de usuario, es indispensable hacer clics reales y probar entradas anómalas
- Las apps hechas con vibe coding suelen funcionar bien solo en el happy path y ser frágiles ante entradas excepcionales
- Rule 5: Iterate and Refine / Itera y refina
- Si el primer resultado que dio la IA no te satisface, no lo dejes pasar: vuelve a intentarlo o refactorízalo
- La vibe coding es un proceso iterativo basado en conversación
- Por ejemplo:
- “haz este código más conciso”
- “divídelo en funciones más pequeñas”, etc., ajustando el prompt
- O también: refactorizas tú mismo → identificas puntos a corregir → vuelves a hacer prompt → repites
- Es efectiva una estrategia de trabajo en ciclos con la IA
- Rule 6: Know When to Say No / Hay que saber decir que no
- La vibe coding no siempre es la mejor opción
- En situaciones que requieren diseño crítico o seguridad, es mejor escribirlo directamente
- Ejemplos:
- diseñar directamente los módulos relacionados con seguridad y usar la IA solo en partes puntuales
- si la IA complica una respuesta para un problema simple, es más rápido escribirlo tú mismo
- Cuando la IA no resuelve bien el problema, no insistas y cambia a modo manual
- “Como lo hizo la IA” no es una excusa para no entender tu propio código
- Rule 7: Document and Share Knowledge / Documenta y comparte conocimiento
- El código generado por IA debe estar tan bien documentado como el que escribes tú mismo (y a veces más)
- Si hay decisiones poco intuitivas o implementaciones inusuales, hay que dejar comentarios
- Comparte claramente con el equipo qué partes fueron generadas por IA
- Algunos equipos incluso guardan tal cual los prompts usados en código importante de IA → útil para depuración
- Siguiendo estas reglas, los equipos pueden aprovechar al máximo la productividad de la vibe coding y al mismo tiempo minimizar los riesgos
- La clave es que la IA no reemplace a las personas, sino que las complemente
- La IA acelera el trabajo repetitivo, mientras que las personas aportan pensamiento crítico y creatividad
- Vivimos en una era en la que co-creamos código junto con la IA
Cuándo funciona bien la vibe coding vs cuándo se desmorona
- También es importante tener claro dónde brilla la vibe coding y dónde no
- No todos los proyectos ni todas las tareas se adaptan igual de bien a un flujo de trabajo basado en IA
- A continuación, una clasificación de usos basada en experiencias y casos de la industria
- 👍 Casos donde funciona bien (Great Use Cases)
- Rapid prototyping (creación rápida de prototipos)
→ el punto ideal del vibe coding. Cuando tienes una app pequeña o una idea de funcionalidad
→ puedes usar un asistente de IA para crear rápidamente una prueba de concepto o un prototipo
→ no pasa nada si el código queda algo tosco — lo importante es validar la idea
→ hay muchos casos de proyectos de fin de semana donde se crea una app solo con IA y se pone a prueba el concepto - One-off scripts / Internal tools (scripts de un solo uso, herramientas internas)
→ por ejemplo, parsear archivos de logs, automatizar tareas personales o crear dashboards internos
→ en entornos donde el riesgo no es alto aunque falle, el vibe coding es eficaz para ahorrar tiempo
→ en situaciones donde no se necesita calidad de nivel producción, puedes construir rápido “algo que funcione ya” - Learning and exploration (aprendizaje y exploración)
→ al aprender un lenguaje nuevo o una API, puedes pedirle a la IA que genere ejemplos
→ aunque el código no sea perfecto, sirve de sobra como material de aprendizaje
→ se siente como tener un TA virtual (asistente docente) que muestra distintos intentos, y luego una persona los pule - Boilerplate-heavy tasks (tareas con mucho boilerplate)
→ por ejemplo: generar 10 clases de datos similares, implementar CRUD
→ si la estructura está clara, la IA puede seguir patrones repetitivos con precisión
→ permite despachar rápido el trabajo mecánico, y que la persona se concentre en lo importante
- Rapid prototyping (creación rápida de prototipos)
- 👎 Casos donde aparecen problemas (Not-So-Great Use Cases)
- Enterprise software / Complex systems (software empresarial, sistemas complejos)
→ sistemas con lógica de negocio compleja, concurrencia, seguridad y requisitos de compliance
→ la IA no conoce esas condiciones si no se le dicen explícitamente, e incluso si las conoce puede no reflejarlas bien
→ por ejemplo: sistemas de pago fintech o software de control aeroespacial nunca deben dejarse solo en manos de la IA
→ en estos entornos solo puede ayudar parcialmente, y la calidad final requiere QA humana y experiencia profesional - Long-term maintainability (mantenibilidad a largo plazo)
→ en una base de código que durará años, la estructura importa desde el inicio
→ el código armado a puro parche con IA tiende a ser inconsistente, y luego se vuelve una gran carga de mantenimiento
→ es mejor invertir tiempo al principio para definir un framework y un diseño claros
→ muchos usuarios tempranos comparten la experiencia de que el tiempo ahorrado con vibe coding
luego se termina perdiendo otra vez en refactorización y limpieza - Critical algorithms / Optimizations (algoritmos de alto rendimiento u optimización)
→ por ejemplo: gestión de memoria personalizada, algoritmos de ordenamiento ultrarrápidos
→ la IA puede funcionar bien con entradas pequeñas, pero suele carecer de consideración por la escala
→ puede volverse lenta o funcionar mal sin advertencia
→ en estas partes sigue haciendo falta la creatividad y la comprensión profunda de una persona - Explainability and clarity (claridad y capacidad de explicación)
→ situaciones donde el código debe poder leerse claramente para otros desarrolladores o auditores
→ si la IA abstrae demasiado o aborda el problema de forma innecesariamente compleja, la legibilidad y la mantenibilidad se deterioran gravemente
→ hoy la IA no siempre apunta a “código corto y conciso” → a veces resulta demasiado verbosa o abstraída sin necesidad
→ en estos casos, hacen falta refactorización humana y escritura clara del código
- Enterprise software / Complex systems (software empresarial, sistemas complejos)
- En resumen, el vibe coding es una herramienta poderosa de aceleración, pero no una solución universal
- Es muy eficaz cuando la velocidad importa y el resultado puede corregirse varias veces
- En cambio, dejar software mission-critical de una sola vez en manos de la IA es un intento riesgoso
- Una analogía sería: como poner a un piloto de carreras a manejar un autobús escolar — buena herramienta, uso equivocado
- Tal vez algún día la IA llegue a ser la herramienta base de todo el desarrollo, pero hoy no lo es
- Lo que nos toca hacer hoy es usar la IA en el problema correcto, de la manera correcta y bajo la responsabilidad correcta
Conclusión: vibea con cuidado — disfruta la velocidad, pero no pierdas la artesanía
- el vibe coding y el desarrollo de software impulsado por IA representan un salto enorme en la evolución de las herramientas
- esta corriente no es una moda pasajera, sino una realidad ya establecida, y seguirá volviéndose más sofisticada
- un equipo de ingeniería que piensa en el futuro no debería ignorarlo
- así como las herramientas de automatización anteriores y los frameworks avanzados superaron métodos previos de desarrollo,
es muy probable que los equipos que sepan aprovechar bien la IA superen a los que no - el mensaje de este texto no es rechazar el vibe coding —
→ sino abordarlo con los ojos abiertos y respetando los fundamentos de la ingeniería
- La lección más importante: la velocidad no significa nada sin calidad
- Desplegar rápido código lleno de bugs e imposible de mantener no es más que acelerar hacia un precipicio
- Los mejores desarrolladores son quienes aumentan su velocidad con IA sin derrumbar el sistema
- La IA levanta el peso, y la persona verifica que todo esté bien sostenido
- La clave está en encontrar ese punto de equilibrio (sweet spot)
- Puntos de acción para líderes técnicos y managers:
→ hay que instalar en el equipo una cultura donde la IA sea una herramienta que se usa con responsabilidad- fomentar el vibe coding, pero también establecer expectativas y reglas claras para proteger la base de código
- todo código generado por IA debe pasar sí o sí por code review,
- y construir una cultura donde la pregunta “¿entiendes este código?” salga de forma natural
- invertir en fortalecer las capacidades del equipo para que pueda colaborar eficazmente con la IA
- incorporar nuevas habilidades, como escribir buenos prompts y evaluar sugerencias de la IA
- esto es un cambio de paradigma, como lo fue antes el paso a lenguajes de alto nivel o la adopción de Git
→ los equipos que se adapten rápido serán los que ganen
- Lo que de verdad debemos seguir valorando en la ingeniería de software es lo siguiente:
- resolver problemas de los usuarios
- construir sistemas confiables
- seguir aprendiendo
- el vibe coding es un medio, no un fin
- si ayuda a entregar valor más rápido y mejor a los usuarios, es una gran herramienta
- pero si en el proceso nos lleva a sacrificar la calidad y la seguridad en las que debemos confiar, hay que moderar su uso
- Lo esencial sigue siendo válido:
→ pensamiento claro, comprensión de requisitos, diseño preparado para el cambio y pruebas rigurosas
- Para cerrar, grabemos este espíritu:
→ “muévete rápido, pero no rompas nada — y si lo rompes, asegúrate de poder arreglarlo.” - Hay que escribir código con velocidad, pero sobre una base sólida de ingeniería
- La IA puede ser un cincel poderoso en manos de un artesano
→ pero quien sigue manejando ese cincel es la mano humana
- Así que, desarrolladores: vibeen — pero vibeen con cuidado
- Abracemos el futuro, pero sin soltar los principios fundamentales que nos trajeron hasta aquí
- el vibe coding no es una excusa para justificar baja calidad,
→ sino una oportunidad para mostrar cuánto más podemos construir cuando se combinan el juicio humano y la capacidad generativa de las máquinas
- Los equipos que interioricen este principio no solo se volverán más rápidos,
→ también construirán software que valga la pena mantener vivo durante mucho tiempo
> Happy coding — y que el vibe esté alto, pero la calidad todavía más.
3 comentarios
+1
Coincido.
Advertencia: texto largo
Opiniones de Hacker News
Se redefinió el significado de "vibe coding"
El hype alrededor de la programación con IA ha crecido tanto que parece imposible que cumpla de forma realista
Esto recuerda a la época de principios de los 2000, cuando las grandes empresas intentaban subcontratar desarrollo a países de bajos ingresos
Tratar a la IA como si fuera un desarrollador junior del equipo puede tomar más tiempo
Depende del caso de uso
Existen distintas perspectivas sobre la calidad del software
Existe la pregunta de si la programación asistida por IA afectará negativamente el crecimiento de los desarrolladores
El vibe coding sirve para medir la dificultad de una tarea
La gente tiende a conservar energía, y el vibe coding permite un desarrollo de bajo esfuerzo
Todo el artículo parece haber inflado la idea de que "un humano debe revisar el vibe code antes de desplegarlo en producción"