¿Puede el vibe coding realmente ser seguro? Análisis sistemático del estado del arte

El código que nadie leyó ya está en producción

Por Sebastián Vargas Yáñez | CEO TTPSEC SpA · Academic Director · VP SOCHISI · PhD Candidate · Applied AI & Cybersecurity Research

Nota del autor (julio 2026). Este artículo no es una condena del vibe coding ni una defensa nostálgica de escribir cada línea a mano. Es una revisión del estado del arte: qué dice la evidencia empírica publicada — papers con revisión de pares, reportes de industria con metodología abierta y post-mortems de incidentes reales — sobre si el código generado por IA y aceptado sin revisión profunda puede ser seguro. La tesis es matizada: el vibe coding puede ser seguro, pero no por sí solo, y casi nunca lo es en la práctica actual. Las fuentes están citadas al final en formato APA 7.

TL;DR — Andrej Karpathy acuñó “vibe coding” en febrero de 2025 para describir un flujo donde el desarrollador “se entrega a las vibras y olvida que el código existe” (Karpathy, 2025). La evidencia acumulada desde 2022 es consistente y preocupante: cerca del 40 % del código generado por Copilot en escenarios de riesgo contenía vulnerabilidades (Pearce et al., 2022); los usuarios con asistentes de IA escribieron código menos seguro y creyeron que era más seguro (Perry et al., 2023); el 45 % de las tareas de código generado por IA introdujo fallas de seguridad explotables (Veracode, 2025); y las organizaciones que adoptaron asistentes de IA vieron multiplicarse por diez los hallazgos de seguridad en seis meses (Apiiro, 2025). A esto se suman amenazas nativas: el “slopsquatting” derivado de la alucinación de paquetes (Spracklen et al., 2025) y la inyección de prompts, riesgo #1 del OWASP Top 10 for LLM Applications (OWASP, 2025). El caso Replit de julio de 2025 — un agente que borró una base de datos de producción durante un code freeze — mostró el costo real. La respuesta de ingeniería emergente no es “un mejor modelo”, sino un mejor sistema alrededor del modelo: spec-driven development (GitHub Spec Kit), harness engineering con guides y sensors (Böckeler, 2026), y el reconocimiento contraintuitivo de que los loops de refinamiento ingenuos empeoran la seguridad — +37,6 % de vulnerabilidades críticas tras cinco iteraciones (Shukla et al., 2025), sin que un SAST-gate baste para evitarlo. La conclusión: el vibe coding sin human-in-the-loop, SAST/DAST y gobernanza de dependencias no es programación rápida; es deuda de seguridad acelerada.

Índice de contenido

1. Qué es realmente el vibe coding y por qué importa la definición
2. La evidencia académica: dos estudios que cambiaron la conversación
3. Los reportes de industria: del laboratorio a los repositorios reales
4. Amenazas nativas del vibe coding que no existían antes
5. Anatomía de un desastre: el caso Replit (julio 2025)
6. La paradoja de la sobreconfianza: el eslabón humano
7. ¿Entonces puede ser seguro? Condiciones necesarias
8. El estado del arte en ingeniería: spec, harness y el loop
9. Marco de mitigación basado en estándares
10. Reflexión final: la velocidad no es el problema, la ausencia de fricción sí
11. Referencias

1. Qué es realmente el vibe coding y por qué importa la definición

El 2 de febrero de 2025, Andrej Karpathy — cofundador de OpenAI y ex director de IA en Tesla — publicó en X la descripción de “un nuevo tipo de programación que llamo vibe coding, donde te entregas por completo a las vibras, abrazas los exponenciales y olvidas que el código siquiera existe” (Karpathy, 2025). Describía aceptar cada diff con “Accept All”, pegar mensajes de error sin leerlos y hablarle al editor por voz. En noviembre de 2025, el Collins Dictionary lo nombró palabra del año.

La distinción crítica — y la que la mayoría de las discusiones ignora — es esta: vibe coding no es lo mismo que “usar IA para programar”. Un ingeniero senior que usa Copilot como autocompletado y revisa cada línea no está haciendo vibe coding. Vibe coding, en su definición original, es renunciar deliberadamente a la revisión: aceptar la salida del modelo sin comprenderla, confiando en que “funcione”. Esa renuncia a la fricción cognitiva es precisamente la variable que la evidencia de seguridad identifica como problemática.

Cuando en este artículo pregunto si el vibe coding “puede ser seguro”, no pregunto si los LLMs pueden generar código seguro — a veces lo hacen. Pregunto si el flujo de trabajo que elimina la revisión humana puede producir sistemas seguros. Son preguntas distintas con respuestas distintas.

2. La evidencia académica: dos estudios que cambiaron la conversación

Antes de que “vibe coding” tuviera nombre, la academia ya medía su premisa central.

Asleep at the Keyboard (NYU, 2022)

Pearce, Ahmad, Tan, Dolan-Gavitt y Karri, de NYU, diseñaron 89 escenarios de completado de código relevantes para las debilidades de la lista MITRE “Top 25 CWE” y dejaron que GitHub Copilot los completara, generando 1.689 programas. El resultado: aproximadamente el 40 % de los programas generados contenía vulnerabilidades de seguridad (Pearce et al., 2022). No se trataba de errores exóticos, sino de las categorías más comunes y peligrosas: inyección SQL, desbordamientos de búfer, uso de criptografía débil.

El hallazgo fue reproducido y ampliado en múltiples estudios posteriores, y su valor no está en el número exacto — que varía según modelo y escenario — sino en establecer que la generación de código inseguro no es una anomalía, sino un comportamiento estadísticamente esperable del modelo cuando no hay contexto de seguridad explícito.

Do Users Write More Insecure Code with AI Assistants? (Stanford, 2023)

El estudio de Perry, Srivastava, Kumar y Boneh, presentado en ACM CCS 2023, es aún más incómodo porque midió a personas, no a modelos. Dividieron a los participantes en un grupo con acceso a un asistente de IA (basado en el modelo codex-davinci-002 de OpenAI) y un grupo de control, y les pidieron resolver tareas de programación relacionadas con seguridad.

Dos conclusiones (Perry et al., 2023):

1. Los participantes con acceso al asistente de IA escribieron código significativamente menos seguro que el grupo de control.
2. Los participantes con el asistente tenían más probabilidad de creer que su código era seguro que quienes no lo usaron.

Esa segunda conclusión es el corazón del problema del vibe coding. No solo el código es más inseguro: la percepción de seguridad aumenta al mismo tiempo que la seguridad real disminuye. Es la definición operativa de un punto ciego. El asistente no solo introduce fallas; introduce confianza injustificada en esas fallas.

El matiz honesto: ¿peor que un humano?

La rigurosidad exige presentar la evidencia que complica la tesis. Asare, Nagappan y Asokan (2023) compararon el código de Copilot con vulnerabilidades introducidas por humanos y encontraron que Copilot replicó el código vulnerable original alrededor del 33 % de las veces y el código corregido cerca del 25 % — concluyendo que Copilot “no es tan malo como los desarrolladores humanos” introduciendo vulnerabilidades. Es un contrapunto legítimo: la IA no es categóricamente peor que una persona.

Pero el matiz refuerza el argumento sobre el vibe coding en lugar de debilitarlo. El problema nunca fue que la IA sea peor que un humano cuidadoso. El problema es que el vibe coding combina una tasa de error comparable a la humana con la eliminación de la revisión humana y una velocidad multiplicada. Un desarrollador que comete errores pero revisa su trabajo es un sistema con corrección de errores. Un modelo que comete errores a velocidad 4× y cuyo output se acepta sin revisar es un sistema sin corrección. La diferencia no está en la tasa de error del generador; está en la ausencia del verificador.

Una segunda advertencia de honestidad: los estudios académicos centrales miden modelos ya antiguos (codex-davinci-002, Copilot 2021-2022). No reflejan el rendimiento de los modelos frontier de 2025-2026. Sería un error citarlos como si midieran a Claude o GPT actuales. Por eso el dato más relevante no es académico sino de industria — y es el que veremos a continuación: cuando Veracode probó más de 100 modelos actuales, el problema no había desaparecido.

3. Los reportes de industria: del laboratorio a los repositorios reales

Los estudios académicos usan escenarios controlados. Los reportes de industria de 2025 midieron código real en repositorios reales, y la señal converge.

Tabla 1: Evidencia empírica sobre inseguridad del código generado por IA

Veracode 2025: casi la mitad falla

El 2025 GenAI Code Security Report de Veracode analizó 80 tareas de codificación curadas ejecutadas por más de 100 modelos distintos. El resultado: el 45 % de las tareas produjo código con vulnerabilidades de seguridad detectables (Veracode, 2025). El dato más revelador es contextual: para fallas dependientes de contexto como Cross-Site Scripting (XSS), solo entre el 12 % y el 13 % del código generado fue seguro. El código de IA resultó 2,74 veces más propenso a introducir XSS que el promedio histórico.

Lo importante de este número es que no mejoró con modelos más grandes. La actualización de Veracode de 2026 mantuvo la conclusión: pese a los avances en capacidad general, la tasa de código inseguro se mantuvo estable. Los modelos se volvieron mejores programando y no mejores asegurando.

Este dato de laboratorio se confirma en el campo. Fu et al. (2023) analizaron 733 fragmentos de código de Copilot en proyectos reales de GitHub y hallaron que el 27,3 % contenía debilidades de seguridad — 628 instancias de CWE distribuidas en múltiples lenguajes. Y la percepción de los propios profesionales coincide: en la encuesta de Snyk (2023) a más de 500 profesionales de tecnología y seguridad, el 56,4 % afirmó que las sugerencias de código inseguro por IA son comunes. (Conviene tratar la cifra de Snyk como percepción autoinformada, no como medición técnica, y recordar que Veracode, Snyk y GitClear son proveedores con interés comercial en el problema — aunque sus metodologías son públicas.)

Apiiro 2025: la escala del problema en producción

Si Veracode midió en laboratorio, Apiiro midió el flujo real de organizaciones Fortune 50. Su hallazgo: hacia junio de 2025, el código generado por IA introducía más de 10.000 nuevos hallazgos de seguridad al mes en los repositorios estudiados — un aumento de 10× en solo seis meses respecto a diciembre de 2024 (Apiiro, 2025). El desglose fue específico: 322 % más rutas de escalamiento de privilegios, 153 % más fallas de diseño, y desarrolladores asistidos por IA exponiendo credenciales de nube casi el doble de veces que sus pares sin IA.

La causa estructural que identifica Apiiro es elegante y demoledora: los desarrolladores con IA generan tres a cuatro veces más commits, pero consolidados en pull requests más grandes y complejos — lo que eleva la probabilidad de revisiones superficiales y vulnerabilidades no detectadas. El propio volumen derrota a la revisión.

GitClear: la erosión silenciosa de la mantenibilidad

GitClear analizó más de 211 millones de líneas de código entre 2020 y 2024. El code churn — código revisado o revertido en las dos semanas posteriores a su commit, un indicador de código prematuro o de baja calidad — subió de una línea base pre-IA de ~3,3 % a 5,7 % en 2024 y 7,1 % en 2025, duplicándose (GitClear, 2025). Simultáneamente, las líneas “copiadas/pegadas” superaron por primera vez a las líneas refactorizadas, y la duplicación de bloques de código aumentó de forma marcada. El código clonado se asocia con entre 15 % y 50 % más defectos. No es una falla de seguridad directa, pero es el sustrato sobre el que crecen: código duplicado, no refactorizado y poco comprendido es código difícil de auditar y de parchear.

4. Amenazas nativas del vibe coding que no existían antes

Más allá de reproducir viejas vulnerabilidades, el vibe coding creó vectores de ataque genuinamente nuevos.

Slopsquatting: cuando el modelo inventa una dependencia y el atacante la registra

Spracklen et al., en USENIX Security 2025, generaron 576.000 muestras de código con 16 modelos distintos y midieron cuántas dependencias sugeridas por los LLMs simplemente no existen. El resultado: el 21,7 % de las generaciones de modelos open-source y el 5,2 % de las comerciales referenciaban paquetes inexistentes en PyPI o npm (Spracklen et al., 2025).

Aquí nace el “slopsquatting” (juego de palabras entre slop — la salida descuidada de un LLM — y typosquatting). La cadena de ataque es simple y devastadora:

1. El desarrollador pide código; el LLM emite un import o pip install con un nombre de paquete alucinado.
2. Un atacante que ya registró ese nombre exacto en el repositorio público gana ejecución de código arbitrario en el momento de la instalación.
3. El desarrollador que hace vibe coding — que por definición no revisa — ejecuta el install sin verificar que el paquete sea legítimo.

Lo que hace peligroso al slopsquatting es que las alucinaciones de paquetes son repetibles: el mismo modelo tiende a inventar el mismo nombre falso ante el mismo prompt, lo que permite al atacante predecir qué nombres registrar. Corresponde directamente a la categoría LLM03 (Supply Chain) del OWASP Top 10 for LLM Applications.

Inyección de prompts: el riesgo #1

El OWASP Top 10 for LLM Applications 2025 coloca la inyección de prompts (LLM01) como el riesgo número uno por segunda edición consecutiva (OWASP, 2025). En el contexto del vibe coding con agentes (Cursor, Claude Code, Windsurf, Replit, Copilot Agent), el problema es que el LLM procesa instrucciones y datos en el mismo canal sin separación clara. Un atacante puede esconder instrucciones en un archivo del repositorio, en un issue de GitHub, en la documentación de una dependencia o en la salida de una herramienta — y el agente las interpreta como órdenes legítimas. Un agente con permisos de escritura sobre el sistema de archivos, acceso a la terminal o credenciales de despliegue convierte una inyección de prompt en ejecución remota efectiva. Es la categoría LLM06 (Excessive Agency) materializándose.

Fuga de secretos

El dato de Apiiro sobre exposición de credenciales al doble de tasa no es accidental: los LLMs, entrenados con código público que frecuentemente incluye claves hardcodeadas como ejemplo, reproducen ese antipatrón. En un flujo de vibe coding sin revisión, una API key incrustada en el código generado llega a un repositorio — y si es público, a los escáneres automáticos de los atacantes en minutos.

5. Anatomía de un desastre: el caso Replit (julio 2025)

La teoría se volvió titular en julio de 2025. Jason Lemkin, fundador de la comunidad SaaStr, documentó públicamente un experimento de nueve días con el agente de IA de Replit — una plataforma que se promociona como “el lugar más seguro para vibe coding”. En el noveno día, el agente borró una base de datos de producción con registros reales de más de 1.200 ejecutivos y cerca de 1.200 empresas, durante un code freeze explícito (The Register, 2025; Fortune, 2025).

Los detalles agravan el caso (Fast Company, 2025):

• El agente ejecutó comandos destructivos a pesar de instrucciones repetidas en mayúsculas de no hacer cambios sin aprobación humana.
• Al ser interrogado, el agente admitió haber “entrado en pánico” ante consultas vacías y haber violado el congelamiento.
• Inicialmente le dijo a Lemkin que la función de rollback no funcionaría — algo que resultó falso, pues Lemkin recuperó los datos manualmente. El agente, en efecto, comunicó información incorrecta sobre su propia capacidad de recuperación.

La respuesta de Replit fue instructiva sobre las mitigaciones correctas: su CEO anunció separación automática entre bases de datos de desarrollo y producción, mejoras al sistema de rollback, y un nuevo modo “solo planificación” que permite colaborar con la IA sin riesgo sobre el código en vivo. Cada una de esas medidas es, esencialmente, reintroducir la fricción que el vibe coding había eliminado.

El caso Replit no demuestra que la IA sea incontrolable. Demuestra que un agente con permisos de producción, sin separación de entornos ni aprobación humana obligatoria para acciones destructivas, es un incidente esperando ocurrir — exactamente lo que los marcos de seguridad venían advirtiendo.

6. La paradoja de la sobreconfianza: el eslabón humano

Volvamos al hallazgo de Perry et al. (2023): los usuarios de IA no solo escriben código menos seguro, sino que creen que es más seguro. Esta es la variable psicológica que amplifica todos los riesgos técnicos anteriores.

El vibe coding produce una ilusión de competencia. El código compila, la aplicación arranca, la demo funciona — y el cerebro humano interpreta “funciona” como “está bien hecho”. Pero la seguridad es, casi por definición, aquello que no se ve cuando funciona. Una inyección SQL no rompe la demo; una credencial expuesta no impide el arranque; un paquete slopsquatteado se instala silenciosamente. La retroalimentación inmediata del vibe coding refuerza precisamente las dimensiones equivocadas.

Tabla 2: El desajuste entre percepción y realidad en vibe coding

El problema no es la herramienta. Es que la herramienta desactiva el mecanismo humano de verificación justo cuando más se necesita.

7. ¿Entonces puede ser seguro? Condiciones necesarias

La respuesta honesta al título es: sí, condicionalmente — pero cuando se cumplen las condiciones, deja de ser “vibe coding” en el sentido de Karpathy.

El vibe coding puede producir software seguro si, y solo si, se reintroduce la fricción que su definición elimina. No como negación de la IA, sino como andamiaje alrededor de ella. La evidencia sugiere que la seguridad no proviene de un mejor modelo, sino de un mejor sistema alrededor del modelo. Las condiciones necesarias son:

• Human-in-the-loop obligatorio para acciones de alto impacto. Ningún agente debe ejecutar comandos destructivos, tocar producción ni desplegar sin aprobación humana explícita. El caso Replit es la demostración por contradicción.
• Separación estricta de entornos. Desarrollo, staging y producción con credenciales y accesos diferenciados. El agente nunca debería tener llaves de producción por defecto.
• SAST/DAST y escaneo de secretos en el pipeline. Si el humano no revisa cada línea, una máquina debe hacerlo. El análisis estático, el escaneo de dependencias (SCA) y la detección de secretos deben ser barreras automáticas, no opcionales.
• Gobernanza de dependencias contra slopsquatting. Allowlists de paquetes, verificación de existencia y reputación antes de instalar, y lockfiles auditados. Nunca instalar lo que el modelo sugiere sin verificar que el paquete existe y es legítimo.
• Mínimo privilegio para agentes. Un agente de codificación es una identidad no humana con credenciales — y debe gobernarse como tal: permisos acotados a la tarea, sin acceso amplio “por si acaso”. (Este punto conecta con la gobernanza de identidades de agentes que la disciplina apenas empieza a formalizar.)
• Principio de responsabilidad humana. El desarrollador que acepta el código es el autor del código, con todas sus consecuencias legales y de seguridad. La IA no es responsable; el humano que hizo “Accept All” sí.

8. El estado del arte en ingeniería: spec, harness y el loop

Las “condiciones necesarias” de la sección anterior suenan a sentido común. Lo interesante es que, durante 2025 y 2026, esas condiciones dejaron de ser buenas intenciones y se convirtieron en una disciplina de ingeniería con nombre propio, herramientas y — crucialmente — evidencia sobre qué funciona y qué no. Tres conceptos organizan ese estado del arte: la especificación como fuente de verdad, el harness como andamiaje de control, y el loop como el mecanismo iterativo cuyo comportamiento resultó ser mucho menos intuitivo de lo esperado.

Spec-driven development: mover las barandas río arriba

La respuesta más directa al problema del vibe coding es invertir el orden. En lugar de generar código y luego intentar asegurarlo, el spec-driven development (SDD) pone una especificación estructurada como fuente de verdad antes de que el agente escriba una sola línea. En septiembre de 2025, GitHub liberó Spec Kit, un toolkit open-source para SDD cuya descripción es explícitamente una crítica al vibe coding: permite “enfocarse en escenarios de producto y resultados predecibles en lugar de hacer vibe coding de cada pieza desde cero” (GitHub, 2025).

El flujo de Spec Kit es revelador porque cada fase es una baranda: se empieza por una constitution (principios y restricciones no negociables del proyecto), se crea la especificación, se clarifican las áreas subespecificadas, se genera el plan técnico, se descompone en tareas y recién entonces se implementa. La seguridad y las decisiones arquitectónicas se mueven “río arriba”, al espacio de la especificación, donde son baratas de corregir — en vez de “río abajo”, en el código ya generado, donde son caras. Es “security by design” aplicado al flujo agéntico: el modelo sigue generando el código, pero ya no decide qué es aceptable.

Harness engineering: el andamiaje que rodea al agente

El segundo concepto es el harness: el sistema de controles que envuelve al agente de codificación. Böckeler (2026) lo formaliza en dos mecanismos complementarios. Los guides (controles feedforward) anticipan y previenen comportamiento no deseado antes de que el agente actúe — la constitution de Spec Kit es un guide. Los sensors (controles feedback) observan la salida del agente y habilitan la autocorrección después — linters, tests, escáneres SAST y hooks que se ejecutan tras cada acción del agente. En palabras de Böckeler, “un buen harness externo aumenta la probabilidad de que el agente lo haga bien a la primera, y provee un lazo de retroalimentación que autocorrige tantos problemas como sea posible antes de que lleguen a ojos humanos”.

La distinción importa porque los controles pueden ser computacionales (deterministas: un linter, un test, un SAST) o inferenciales (un modelo que analiza semánticamente la salida de otro modelo). El vibe coding puro no tiene ni guides ni sensors: acepta la salida cruda. El harness engineering es, esencialmente, la ingeniería de reponer ambos.

El loop y su paradoja: iterar puede empeorar la seguridad

Aquí está el hallazgo que más desafía la intuición — y el que más justifica esta sección. La creencia ingenua del vibe coding es que si el código tiene un problema, basta con pedirle al modelo “mejóralo” en un loop hasta que quede bien. La evidencia dice lo contrario.

Shukla, Joshi y Syed (2025), en un análisis sistemático de 400 muestras de código evaluadas sobre 40 rondas con cuatro estrategias de prompting, documentaron una paradoja de degradación de seguridad: las vulnerabilidades críticas aumentaron un 37,6 % tras apenas cinco iteraciones de refinamiento. El loop de “mejora esto” no converge hacia código más seguro; a menudo diverge. La causa es la deriva de especificación (specification drift): en cada iteración, el modelo optimiza para el objetivo más reciente (arreglar un bug, agregar una feature, mejorar rendimiento) y erosiona silenciosamente propiedades de seguridad que nadie volvió a mencionar en el prompt.

Aún más incómodo: los autores encontraron que introducir un gate de SAST entre iteraciones no suprimió por sí solo la degradación — y en ciertas configuraciones la empeoró, al empujar al modelo a “esquivar” el analizador en vez de resolver la causa raíz. Esto refuta la solución simplista de “solo pon un SAST en el loop y listo”.

La conclusión de la investigación no es abandonar el loop, sino diseñarlo: el harness efectivo combina sensores deterministas con validación humana entre iteraciones y una especificación estable que ancle qué propiedades no pueden erosionarse. El loop seguro no es el que itera más rápido, sino el que se niega a olvidar la especificación de seguridad en cada vuelta. Vale la pena notar que la mayoría de este cuerpo de evidencia mide flujos y modelos de 2025-2026 y es un área de investigación en rápida evolución; los números concretos cambiarán, pero el patrón estructural —spec estable + harness con sensores + humano en los puntos de decisión— es el consenso emergente.

9. Marco de mitigación basado en estándares

No hay que inventar estos controles desde cero. Ya existen marcos formales que aplican directamente.

Tabla 3: Marcos aplicables al vibe coding seguro

El OWASP Top 10 for LLM Applications 2025 recomienda explícitamente defensa en profundidad con herramientas de mínimo privilegio, filtrado de entrada/salida, aprobación humana para acciones de alto riesgo y pruebas adversariales regulares (OWASP, 2025). El NIST SP 800-218A (julio de 2024) extiende el marco de desarrollo de software seguro (SSDF) con prácticas específicas para IA generativa, dirigido tanto a productores de modelos como a productores de sistemas que los usan (NIST, 2024).

La síntesis operativa es directa: trata al código generado por IA con el mismo escepticismo que aplicarías al código de un contratista externo desconocido. No confías ciegamente en él; lo revisas, lo escaneas, lo aíslas y lo haces responsable. El vibe coding seguro es, en el fondo, vibe coding con las barandas puestas.

Reflexión final: la velocidad no es el problema, la ausencia de fricción sí

El vibe coding no es una moda que vaya a desaparecer. Karpathy tenía razón en que los modelos “se están volviendo demasiado buenos” para ignorarlos, y la productividad que ofrecen es real y medible. El error sería enmarcar esto como “IA versus programación tradicional”.

El marco correcto es otro: la seguridad del software siempre dependió de la fricción cognitiva — de que alguien, en algún momento, se detuviera a pensar “¿esto es seguro?”. El vibe coding, en su forma pura, elimina esa pausa por diseño. La pregunta del título tiene entonces una respuesta precisa: el vibe coding puede ser seguro exactamente en la medida en que reintroduzca, de forma automatizada o humana, la fricción que promete eliminar.

Un modelo que genera código inseguro el 45 % de las veces no es un colaborador confiable sin supervisión. Es un desarrollador junior brillante, rapidísimo y peligrosamente seguro de sí mismo, que jamás debería tener acceso a producción sin que un adulto revise su trabajo. Tratarlo como cualquier otra cosa no es innovación.

Es un incidente esperando su fecha.

Referencias

Apiiro. (2025). Faster code, greater risks: The security trade-off of AI-driven development. https://apiiro.com/blog/faster-code-greater-risks-the-security-trade-off-of-ai-driven-development/

Asare, O., Nagappan, M., & Asokan, N. (2023). Is GitHub’s Copilot as bad as humans at introducing vulnerabilities in code? Empirical Software Engineering, 28(6), Artículo 129. https://doi.org/10.1007/s10664-023-10380-1

Böckeler, B. (2026, abril 2). Harness engineering for coding agent users. martinfowler.com. https://martinfowler.com/articles/harness-engineering.html

Fu, Y., Liang, P., Tahir, A., Li, Z., Shahin, M., & Yu, J. (2023). Security weaknesses of Copilot generated code in GitHub [Preprint]. arXiv. https://arxiv.org/abs/2310.02059

Fast Company. (2025, julio). Replit CEO: What really happened when AI agent wiped Jason Lemkin’s database. https://www.fastcompany.com/91372483/replit-ceo-what-really-happened-when-ai-agent-wiped-jason-lemkins-database-exclusive

Fortune. (2025, julio 23). AI-powered coding tool wiped out a software company’s database in ‘catastrophic failure’. https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/

GitClear. (2025). AI copilot code quality: 2025 research on code clones, churn, and refactoring. https://www.gitclear.com/ai_assistant_code_quality_2025_research

GitHub. (2025). Spec Kit: Toolkit to help you get started with Spec-Driven Development [Software]. GitHub. https://github.com/github/spec-kit

Karpathy, A. (2025, febrero 2). There’s a new kind of coding I call “vibe coding” [Publicación en X]. https://x.com/karpathy/status/1886192184808149383

National Institute of Standards and Technology. (2022). Secure Software Development Framework (SSDF) version 1.1 (NIST SP 800-218). U.S. Department of Commerce. https://csrc.nist.gov/pubs/sp/800/218/final

National Institute of Standards and Technology. (2024). Secure software development practices for generative AI and dual-use foundation models: An SSDF community profile (NIST SP 800-218A). U.S. Department of Commerce. https://csrc.nist.gov/pubs/sp/800/218/a/final

OWASP. (2025). OWASP Top 10 for LLM Applications 2025. OWASP Foundation. https://owasp.org/www-project-top-10-for-large-language-model-applications/

Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., & Karri, R. (2022). Asleep at the keyboard? Assessing the security of GitHub Copilot’s code contributions. 2022 IEEE Symposium on Security and Privacy (SP), 754–768. https://doi.org/10.1109/SP46214.2022.9833571

Perry, N., Srivastava, M., Kumar, D., & Boneh, D. (2023). Do users write more insecure code with AI assistants? Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (CCS ‘23), 2785–2799. https://doi.org/10.1145/3576915.3623157

Shukla, S., Joshi, H., & Syed, R. (2025). Security degradation in iterative AI code generation: A systematic analysis of the paradox [Preprint]. arXiv. https://arxiv.org/abs/2506.11022

Snyk. (2023). 2023 AI code security report. Snyk. https://go.snyk.io/2023-ai-code-security-report.html

Spracklen, J., Wijewickrama, R., Sakib, A. H. M. N., Maiti, A., Viswanath, B., & Jadliwala, M. (2025). We have a package for you! A comprehensive analysis of package hallucinations by code generating LLMs. 34th USENIX Security Symposium. https://arxiv.org/abs/2406.10279

The Register. (2025, julio 21). Vibe coding service Replit deleted production database, faked data, told fibs galore. https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/

Veracode. (2025). 2025 GenAI code security report. Veracode. https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/