[{"data":1,"prerenderedAt":105},["ShallowReactive",2],{"blog-post-es-the-trust-problem-coming-for-vibe-coded-software":3},{"id":4,"title":5,"author":6,"body":7,"category":87,"date":88,"description":89,"excerpt":90,"extension":91,"gradient":92,"icon":93,"meta":94,"navigation":95,"path":96,"seo":97,"stem":98,"tags":99,"__hash__":104},"posts_es\u002Fblog\u002Fthe-trust-problem-coming-for-vibe-coded-software.md","El problema de confianza que se acerca al software vibe-coded","mercedes",{"type":8,"value":9,"toc":80},"minimark",[10,20,23,28,31,34,37,40,44,47,50,58,61,64,68,71,74,77],[11,12,13,14,19],"p",{},"El ",[15,16,18],"a",{"href":17},"\u002Fblog\u002Fwhy-the-200-dollar-seat-exists","artículo anterior"," argumentaba que un equipo pequeño puede ahora construir y operar un producto que antes requería cuarenta personas. Ese argumento es sencillamente cierto, y viene con una consecuencia menos cómoda: el mismo desplome del coste de construcción aplica a todo el mundo, incluyendo a quien publica software que no ha leído.",[11,21,22],{},"Esto no es una queja sobre el desarrollo asistido por IA. Lo usamos intensamente, en todos los productos que operamos. Es una observación sobre lo que ocurre cuando el coste de producir código plausible cae más rápido que el coste de verificarlo, porque esos dos costes no bajaron juntos, y en la distancia entre ambos vive el problema.",[24,25,27],"h2",{"id":26},"los-fallos-a-corto-plazo-son-específicos","Los fallos a corto plazo son específicos",[11,29,30],{},"«El software vibe-coded es malo» no es una afirmación útil. La versión útil nombra las clases de fallo, porque no son aleatorias: se concentran en lugares predecibles.",[11,32,33],{},"El código generado es fiablemente competente en la forma de una solución y poco fiable en sus bordes. La autorización es el caso más claro: si se pide un endpoint que devuelva los registros de un usuario, el resultado funcionará perfectamente cuando ese usuario seas tú. Si verifica que efectivamente eres tú depende de que alguien pensara en pedirlo. El camino feliz es lo que se demuestra, así que el camino feliz es lo que se verifica.",[11,35,36],{},"El mismo patrón aparece en multi-tenancy, donde un filtro de alcance ausente es invisible hasta que hay un segundo cliente; en el manejo de errores, donde la diferencia entre una excepción capturada y una traza que contiene una cadena de conexión es una línea que nadie miró; y en la selección de dependencias, donde un modelo recurrirá con confianza a un paquete que resolvía bien este problema en 2021 y ha tenido tres avisos de seguridad desde entonces.",[11,38,39],{},"Ninguno de estos es exótico. Son el contenido ordinario de una revisión de código. El problema no es que la IA produzca código singularmente peligroso: es que produce un volumen de código que hace que saltarse la revisión parezca asumible, y estos errores concretos son los que sobreviven a una demo.",[24,41,43],{"id":42},"hacia-dónde-va-esto","Hacia dónde va esto",[11,45,46],{},"Esta parte es un pronóstico más que una observación, y vale la pena etiquetarla como tal, porque la predicción confiada es exactamente el fallo del que trata este texto.",[11,48,49],{},"El software ha disfrutado durante mucho tiempo de una presunción de competencia por defecto. Cuando introduces un número de tarjeta o subes un documento, normalmente no estás evaluando si la lógica de autorización de esa aplicación fue revisada por alguien. Asumes que llegar a producción implicaba que alguien competente estuvo involucrado, porque durante casi toda la historia del sector esa suposición era barata y aproximadamente correcta.",[11,51,52,53,57],{},"Esa suposición se encarece a medida que baja el coste de publicar. Yo esperaría que la secuencia fuera gradual y poco espectacular: un volumen creciente de brechas ordinarias en productos pequeños y medianos, pocas de ellas individualmente noticiables; una acumulación lenta de la sensación de que cierta categoría de aplicación no es de fiar con nada sensible; y con el tiempo un criterio de compra que hoy apenas existe, alguna versión de ",[54,55,56],"em",{},"quién construyó esto y qué verificó",".",[11,59,60],{},"La categoría donde esto muerde primero no son las apps de consumo. Es el software que guarda cosas que no se pueden volver a emitir. Una contraseña filtrada es una tarde de molestias. Un historial médico filtrado es permanente. Nosotros construimos en salud, así que esto no es abstracto: la asimetría entre lo barato que fue producir el software y lo irreversible que es el daño cuando falla es el riesgo completo, y no es visible en una demo de producto.",[11,62,63],{},"Podría estar equivocada. Los consumidores han absorbido una enorme cantidad de fatiga por filtraciones sin cambiar mucho su comportamiento, y es perfectamente posible que esto siga el mismo camino: daño real, ningún cambio de conducta, regulación que llega tarde y de forma desigual. Pero la dirección parece clara aunque el plazo no lo esté, y el coste de adelantarse a la prudencia aquí es bajo.",[24,65,67],{"id":66},"qué-implica-esto-para-construir","Qué implica esto para construir",[11,69,70],{},"La conclusión práctica es más estrecha que «hay que tener cuidado». La IA debería escribir la mayor parte del código; esa parte del argumento está resuelta, y rechazarla es simplemente elegir ser lento. Lo que no se puede delegar es el criterio sobre qué partes del sistema son caras de equivocar.",[11,72,73],{},"Para nosotros eso significa un pequeño número de innegociables. Todo lo que toca autorización, aislamiento entre clientes o datos personales lo lee una persona que entiende el modelo de amenaza, no se ojea buscando estilo. El pipeline de pruebas ejecuta unitarias, integración y end-to-end antes de que nada llegue a producción, y un pipeline en rojo detiene la publicación por muy seguro que parezca el cambio. Las dependencias se eligen deliberadamente y se auditan, no se aceptan porque aparecieron en una sugerencia.",[11,75,76],{},"Nada de esto es novedoso. Es lo que hacían los equipos cuidadosos antes de todo esto, y la razón para decirlo en voz alta es que la economía ahora lo desincentiva activamente. Cuando generar una funcionalidad lleva veinte minutos y revisarla bien lleva dos horas, lo que se recorta es la revisión, y nada de esa decisión es visible para el cliente hasta que resulta muy visible.",[11,78,79],{},"La asimetría de la confianza es lo que hace que esto merezca atención. Que te confíen los datos de alguien es lento de ganar, inmediato de perder y prácticamente imposible de reconstruir. Eso no lo ha reajustado nada, y es la única parte de la vieja estructura de costes que vale la pena conservar.",{"title":81,"searchDepth":82,"depth":82,"links":83},"",2,[84,85,86],{"id":26,"depth":82,"text":27},{"id":42,"depth":82,"text":43},{"id":66,"depth":82,"text":67},"engineering","2026-09-14","El artículo anterior argumentaba que un equipo pequeño puede ahora construir y operar un producto que antes requería cuarenta personas. Ese argumento es sencillamente cierto, y viene con una consecuencia menos cómoda: el mismo desplome del coste de construcción aplica a todo el mundo, incluyendo a quien publica software que no ha leído.",null,"md","linear-gradient(135deg, rgba(79,70,229,0.4), rgba(99,102,241,0.2))","i-heroicons-shield-exclamation",{},true,"\u002Fblog\u002Fthe-trust-problem-coming-for-vibe-coded-software",{"title":5,"description":89},"blog\u002Fthe-trust-problem-coming-for-vibe-coded-software",[100,101,102,103],"Calidad de Software","Seguridad","IA","Confianza","oSiZSWVUCX9KkaXvn-lZOhBw1T5qqot9gczrT3G-XF4",1789948888875]