El lado oscuro de las herramientas de IA para programar: lo que muestran los datos de 2026

La suscripción es lo más barato de una herramienta de IA para programar. Pagues 20, 100 o 200 dólares al mes, los costes más grandes no aparecen en la factura. Aparecen después, en forma de código que pasa la revisión y se rompe en producción, apps que filtran los datos de sus usuarios, más código del que nadie puede revisar, agentes con demasiado acceso que borran bases de datos de producción e ingenieros que acaban quemados.

Soy ingeniero de software en una gran empresa tecnológica y uso estas herramientas todos los días. No odio la IA. Pero me he topado yo mismo con muchos de los problemas de este artículo, y en 2026 por fin hay datos suficientes para ponerles cifras.

Resumen rápido

• El código de IA parece mejor en la revisión de lo que se comporta en producción. En la encuesta de junio de 2026 de New Relic a 200 líderes tecnológicos de EE. UU., el 94 % valoró el código de IA como de mayor calidad que el escrito por personas en la fase de revisión. El 82 % podía señalar un fallo en producción causado por código de IA en los seis meses anteriores (New Relic, 2026).
• Los agentes con credenciales amplias destruyen cosas rápido. Un agente de Cursor que ejecutaba Claude borró la base de datos de producción de PocketOS en unos 9 segundos, y un terraform destroy ejecutado por Claude eliminó 2,5 años de datos de los cursos de DataTalks.Club. En ambos casos, unos permisos acotados habrían detenido al agente donde sus instrucciones no lo hicieron.
• La revisión es el nuevo cuello de botella. A medida que aumentaba la adopción de IA entre unos 22.000 desarrolladores, la mediana del tiempo en revisión de PR subió un 441 % y los bugs por desarrollador subieron un 54 % (Faros AI, 2026).
• Los agujeros de seguridad van en aumento. Investigadores de Georgia Tech vincularon 35 CVE a código escrito por IA solo en marzo de 2026, frente a unos 18 entre mayo y diciembre de 2025 (Georgia Tech, 2026).
• Las personas también pagan. Los juniors que aprendieron con IA sacaron un 50 % en un cuestionario de comprensión, frente al 67 % de quienes programaron a mano (Anthropic, 2026), y una encuesta a 442 desarrolladores concluyó que la adopción de IA aumenta el burnout a través de mayores exigencias laborales (Feng et al., 2026).

¿Por qué el código de IA pasa la revisión y se rompe en producción?

El código de IA pasa la revisión porque parece limpio, y se rompe en producción porque el agente que lo escribió no sabe cómo se comporta tu sistema con tráfico real ni por qué el código existente está escrito como está.

En junio de 2026 New Relic publicó su encuesta State of AI Coding a 200 líderes tecnológicos de EE. UU. (New Relic, 2026). En la fase de revisión, el 94 % valoró el código generado por IA como de mayor calidad que el escrito por personas, y el 33 % dijo que era mucho mayor. Una vez que ese código llegó a producción, las respuestas se invirtieron:

• El 78 % registró más incidentes en producción en los últimos 12 meses
• El 86 % dijo que los ingenieros sénior dedican más tiempo a arreglar código
• El 74 % dijo que al menos una cuarta parte de su código generado por IA necesitó un retrabajo importante
• El 82 % podía señalar un fallo en producción en los últimos seis meses causado por código de IA

Si el código es mejor en la revisión, ¿por qué se sigue rompiendo? En mi propio trabajo veo cuatro razones.

El agente no conoce el sistema. No puede ver cuánto tráfico maneja un servicio, qué días hay más carga de lo normal ni qué dependencia downstream cae primero. Nada de eso está en el diff.

No sabe por qué el código está escrito así. Todo código maduro tiene condiciones extrañas. Quizá el flujo de pagos tiene una comprobación rara porque un desarrollador anterior se topó con un bug del proveedor y lo esquivó. Una persona que leyera ese código le preguntaría a quien lo escribió. El agente no pregunta. Hace una suposición y sigue adelante, y a menudo esa suposición es errónea.

Los revisores se vuelven ciegos ante los diffs grandes. Cuando un agente produce cientos de líneas de golpe, el revisor se siente abrumado. Al cabo de un rato dejas de leer con atención, y el código se aprueba porque parece correcto. Los casos límite que un ingeniero con años en ese código manejaría sin pensar son justo los que nadie revisa.

La deuda del agente se acumula. Es código de IA descuidado que llega a producción y nunca se limpia. Como cualquier deuda técnica, crece, y al final se convierte en un incidente en producción.

¿Qué pasa cuando la propia herramienta de IA empeora?

El rendimiento de tu equipo cae, y cuesta notarlo. En marzo y abril de 2026 los desarrolladores pasaron semanas quejándose de que Claude Code había empeorado. Stella Laurenzo, directora del grupo de IA de AMD, analizó 6.852 sesiones de Claude Code y descubrió que el agente leía mucho menos código antes de hacer cambios. Pasó de 6,6 lecturas de archivo por edición a 2,0 (issue de GitHub #42796, 2026).

El postmortem de Anthropic atribuyó la caída a tres cambios que había publicado, entre ellos un bug de caché que borraba el razonamiento del modelo en cada turno. Ese bug «superó múltiples revisiones de código humanas y automatizadas, además de tests unitarios, tests end-to-end, verificación automatizada y dogfooding» (Anthropic, 2026).

Piensa en lo que eso significa para una empresa con cientos de ingenieros que dependen de estas herramientas. Durante semanas, toda la organización de ingeniería trabaja con un rendimiento reducido y casi nadie lo nota, porque cuando un agente lo hace mal te encoges de hombros y piensas «es IA, a veces pasa».

Anthropic dice que nada de esto fue intencionado, y le creo. Aun así, me dejó intranquilo. Cuando tu equipo depende de un modelo de Anthropic, OpenAI o cualquier otro, es el proveedor quien decide lo bueno que es ese modelo hoy. Si algún proveedor decidiera reducir la calidad, los desarrolladores que más dependen de la herramienta serían los más afectados, y un puñado de empresas determina ahora la calidad de una gran parte del código nuevo del mundo.

¿Puede un agente de IA borrar tu base de datos de producción?

Sí. Ha pasado en al menos tres casos hechos públicos en el último año, y en todos ellos el agente tenía mucho más acceso del que necesitaba su tarea.

PocketOS: producción borrada en 9 segundos

En abril de 2026 un agente de IA en Cursor, que ejecutaba Claude Opus 4.6 de Anthropic, trabajaba en una tarea en el entorno de staging de PocketOS y se topó con un problema de credenciales. Se puso a buscar credenciales y encontró un token de la API de Railway en un archivo que no tenía nada que ver. El token se había creado para gestionar dominios personalizados, pero no tenía límites de alcance. Cualquiera que lo tuviera podía hacer cualquier cosa en cualquier entorno.

El agente lo usó para borrar un volumen de almacenamiento a través de la API de Railway, creyendo que el borrado solo afectaría a staging. El volumen contenía la base de datos de producción. Las copias de seguridad estaban en el mismo volumen, así que también desaparecieron, y la copia más reciente guardada en otro sitio tenía unos tres meses. Todo duró unos 9 segundos (The Register, 2026).

Las reglas del agente le prohibían hacer suposiciones y ejecutar comandos destructivos sin que se lo pidieran. Cuando el fundador, Jer Crane, le preguntó por qué lo hizo de todos modos, respondió: «Supuse que borrar un volumen de staging a través de la API solo afectaría a staging. No lo verifiqué». Railway restauró después los datos desde sus propias copias de seguridad (The Register, 2026).

Se podría haber evitado sin tocar el agente. Producción y staging no deberían compartir infraestructura, cada entorno debería tener su propio token y el agente nunca debería haber tenido acceso a un token que no necesitaba. Aun así culpo al agente, porque ignoró instrucciones que se le habían dado. Pero una regla que escribes para un agente es solo una petición, y esta la ignoró.

DataTalks.Club: 2,5 años de datos y un terraform destroy

Alexey Grigorev dirige DataTalks.Club, una plataforma de cursos gratuitos de ingeniería de datos, y gestiona su infraestructura con Terraform (Alexey Grigorev, 2026). Terraform trabaja con dos archivos. La configuración describe lo que quieres, como servidores, una base de datos y una red. El archivo de estado registra lo que Terraform ha construido realmente. Terraform compara los dos y construye todo lo que el archivo de estado no recoge.

Su archivo de estado estaba en su portátil en lugar de en un almacenamiento remoto compartido. Cuando cambió de portátil, la configuración se vino con él, pero el estado no. Terraform concluyó que todavía no se había construido nada y empezó a construirlo todo por segunda vez. Él lo detuvo a medias, y eso dejó unos cuantos recursos duplicados funcionando junto a los reales.

Entonces Claude, mientras limpiaba los duplicados, descomprimió un archivo antiguo de Terraform del portátil anterior. En sus palabras: «No me di cuenta de que Claude estaba descomprimiendo mi archivo de Terraform. Sustituyó mi archivo de estado actual por uno más antiguo que tenía toda la información sobre la plataforma de gestión de cursos de DataTalks.Club». Ese estado antiguo describía toda la plataforma de producción. Claude ejecutó terraform destroy, y Terraform borró la base de datos, la red, los servidores y los snapshots automáticos, ya que Terraform también los había creado. La base de datos contenía 2,5 años de entregas de los cursos, con unos 1,9 millones de filas en una sola tabla.

A medianoche pagó para mejorar su plan de soporte de AWS y así poder hablar por teléfono con alguien de AWS. AWS tenía un snapshot en su lado que él no podía ver desde su propia consola, y la plataforma se restauró 24 horas después del borrado.

Normalmente una persona revisaría el plan antes de ejecutar terraform destroy contra producción. Claude lo ejecutó sin cuestionar lo que el plan iba a borrar.

Amazon Kiro: 13 horas de caída de AWS Cost Explorer

Esto no solo les pasa a las empresas pequeñas. En diciembre de 2025, ingenieros de Amazon dejaron que Kiro, el propio agente de IA para programar de Amazon, arreglara un problema en AWS Cost Explorer, la herramienta que usan los clientes para controlar su gasto en AWS. Kiro decidió que la mejor solución era borrar el entorno y recrearlo. Cost Explorer estuvo caído unas 13 horas en una región de China continental, según el Financial Times, en el resumen de The Decoder (2026).

Dos salvaguardas deberían haberlo impedido. Por defecto Kiro pregunta antes de actuar, y los cambios en producción necesitan la aprobación de una segunda persona. Pero el ingeniero que usaba Kiro tenía permisos más amplios de lo previsto, Kiro los heredó y no se exigió una segunda aprobación. Amazon dijo al FT que fue una coincidencia que hubiera herramientas de IA implicadas. Su respuesta pública calificó el incidente de «error de usuario, en concreto controles de acceso mal configurados» (Amazon, 2026). En cualquier caso, el agente heredó más acceso del que necesitaba la tarea.

¿Qué habría evitado estos incidentes?

Unas reglas de infraestructura corrientes habrían frenado los tres casos:

• Da a cada entorno sus propias credenciales, para que una tarea de staging solo pueda llegar a staging.
• Dale a un agente el token más restringido que le sirva para el trabajo, nunca el acceso completo de un ingeniero.
• Mantén producción y staging en infraestructura separada. Eso vale sobre todo para el almacenamiento, y las copias de seguridad nunca deberían estar en el mismo volumen que los datos.
• Guarda el estado de Terraform en un almacenamiento remoto con bloqueo. Un archivo de estado en un portátil está a un portátil perdido de una reconstrucción o de un destroy.
• Haz que una persona apruebe cada comando destructivo contra producción, incluidos los borrados, destroy, los force push y las migraciones.

¿Cómo atacan los ciberdelincuentes a las herramientas de IA para programar?

Los atacantes usan ahora el agente de IA de tu máquina como la herramienta que encuentra y roba tus secretos.

En agosto de 2025 alguien publicó ocho versiones maliciosas de Nx, una herramienta de build de JavaScript con unos 6 millones de descargas semanales (Nx, 2025). Las versiones maliciosas estuvieron disponibles unas cuatro o cinco horas. Un script postinstall comprobaba si la máquina tenía instaladas las herramientas de línea de comandos de Claude, Gemini o Amazon Q. Si encontraba alguna, la ejecutaba con sus controles de seguridad desactivados (claude --dangerously-skip-permissions, gemini --yolo o q --trust-all-tools) y le pedía al agente que buscara en el disco tokens de GitHub, tokens de npm, claves SSH, archivos .env y monederos de criptomonedas. Después usaba el token de GitHub de la víctima para crear un repositorio público en su propia cuenta y subía allí el botín (StepSecurity, 2025). Más de 1.700 desarrolladores vieron sus secretos publicados de esta forma (Wiz, 2025).

En febrero de 2026 un gusano fue directamente a por las herramientas de IA para programar. Al menos 19 paquetes de npm de dos cuentas usaban nombres parecidos a Claude Code y OpenClaw, así que quien escribía mal el nombre de un paquete instalaba el equivocado. Una vez instalado, recopilaba claves de API de proveedores de IA y añadía su propio servidor MCP a las herramientas de IA del desarrollador, con instrucciones ocultas que le pedían al asistente que reuniera claves SSH y credenciales de AWS. Se propagaba publicando más paquetes infectados con tokens de npm robados y haciendo commits de sí mismo en repositorios a través de la API de GitHub (Socket, 2026).

Los ataques a la cadena de suministro de npm son anteriores a los agentes de IA, pero un agente con permisos amplios agranda el daño. Puede leer y enviar cualquier cosa a la que tú tengas acceso en tu portátil. Además, ambos ataques dependían de que npm ejecuta automáticamente los scripts de instalación de un paquete. Los módulos de Go no tienen scripts de instalación, así que go get nunca ejecuta código de una dependencia mientras la descarga. Si te interesa la parte del ecosistema, la seguridad de la cadena de suministro en Go vs Node.js compara cómo lo gestionan los dos gestores de paquetes.

¿La IA está rompiendo la revisión de código?

Sí. La IA escribe código más rápido de lo que las personas pueden revisarlo, y los datos muestran que, como consecuencia, los revisores comprueban menos.

Faros AI siguió a unos 22.000 desarrolladores de más de 4.000 equipos. A medida que subía la adopción de IA, también subían los problemas (Faros AI, 2026):

• Bugs por desarrollador: +54 %
• Incidentes por pull request: +243 %
• Mediana del tiempo en revisión de PR: +441 %
• Tamaño de las pull requests: +51 %
• PR fusionadas sin revisión: +31 %

Un estudio de 2026 siguió a 400 revisores a lo largo de 11.429 revisiones de PR de agentes de IA. Los revisores que ya habían visto más PR de agentes las aprobaban 14,5 puntos porcentuales más a menudo que los que habían visto menos, y los comentarios de revisión en línea cayeron un 22 % a lo largo del estudio. Los investigadores lo llaman habituación. Cuanto más código de IA veían los revisores, con menos atención lo revisaban (Yu et al., 2026).

La encuesta State of Code de Sonar de enero de 2026, con más de 1.100 desarrolladores, concluyó que el 38 % dice que revisar código de IA cuesta más esfuerzo que revisar el de un compañero, y que el 53 % ha visto código de IA que parecía correcto pero no era fiable. El 96 % no confía del todo en el código generado por IA, pero solo el 48 % lo revisa siempre antes de hacer commit (Sonar, 2026). Creo que la distancia entre esas dos cifras se explica por lo agotador que es revisar código de IA con cuidado, día tras día. Yo también me he pillado leyendo por encima diffs grandes de agentes.

Microsoft publicó diez meses de datos sobre el agente de programación de Copilot en el repositorio dotnet/runtime, donde los ingenieros le asignaban tareas y el agente abrió 878 pull requests (Microsoft .NET Blog, 2026). En el primer mes solo se fusionó el 41,7 %, en parte porque el agente no tenía instrucciones de build. Cuando el equipo lo arregló, la tasa subió, y en el conjunto de los diez meses se fusionó el 67,9 % de las PR del agente. Las PR de los propios ingenieros se fusionaron en un 87,1 %. Las PR del agente también costaban más revisión. Las PR fusionadas del agente tuvieron una media de 16,5 comentarios de revisión, frente a 12,4 en las PR de los ingenieros, y las personas añadieron sus propios commits a 396 de las 878 PR del agente, alrededor del 45 %, frente al 10,3 % de las PR humanas fusionadas.

¿Es menos seguro el código generado por IA?

Las vulnerabilidades atribuidas a código de IA crecen rápido, y las cifras publicadas probablemente se quedan cortas.

Un laboratorio de Georgia Tech mantiene el Vibe Security Radar. Revisa vulnerabilidades publicadas (CVE), localiza el commit que introdujo cada bug y busca indicios de que lo escribió una IA, como una etiqueta de coautoría de IA. Solo en marzo de 2026 encontró 35 CVE vinculados a código de IA, frente a unos 18 entre mayo y diciembre de 2025, después de que empezara el seguimiento (Georgia Tech, 2026). El fundador del proyecto, Hanqing Zhao, calcula que el número real es de cinco a diez veces lo que pueden detectar, porque la mayor parte del código escrito por IA no deja rastro de que venga de una IA (Infosecurity Magazine, 2026).

GitGuardian encontró 28,65 millones de secretos hardcodeados nuevos en commits públicos de GitHub en 2025, un 34 % más que en 2024 y el mayor salto anual que ha registrado nunca. Los commits hechos con Claude Code filtraron secretos en un 3,2 % de los casos, aproximadamente el doble del 1,5 % de referencia, aunque cada uno de esos commits lo aprobó un desarrollador (GitGuardian, 2026).

En mayo de 2026 investigadores de RedAccess encontraron unas 380.000 apps hechas con vibe coding, creadas en plataformas como Lovable, Base44, Netlify y Replit, que estaban abiertas a cualquiera en la web. Unas 5.000 de ellas filtraban datos sensibles, entre ellos historiales médicos, datos financieros y estrategia interna de empresas (Axios, 2026).

CodeScene añade una advertencia para quien haya dejado de leer el código. Un estudio revisado por pares que publicó concluyó que los asistentes de IA para programar aumentan el riesgo de defectos al menos un 30 % en código poco saludable (CodeScene, 2026), y el white paper de la propia empresa lo sitúa en un 60 % o más. Cuanto más desordenado está un código, peor rinde el agente en él. Cada cambio sin revisar lo desordena un poco más, así que los equipos que dejan trabajar al agente sin control le están complicando su propio trabajo futuro.

¿Cómo responden a la IA los mantenedores de open source?

Varios proyectos importantes han restringido o prohibido las contribuciones hechas con IA porque los mantenedores no dan abasto con los envíos de baja calidad.

• curl mantuvo un bug bounty desde 2019 y pagó más de 100.000 dólares por 87 vulnerabilidades confirmadas. En 2025 alrededor del 20 % de los envíos eran basura generada por IA (Daniel Stenberg, 2025), y los mantenedores no podían con el volumen de informes malos. El bug bounty terminó el 31 de enero de 2026 (Daniel Stenberg, 2026).
• Ghostty, el terminal que mantiene Mitchell Hashimoto, ahora solo acepta código generado por IA de colaboradores externos para trabajo que los mantenedores ya han acordado. Todo lo demás se cierra, y quienes envían malas contribuciones hechas con IA quedan vetados. Hashimoto escribió que la IA había «multiplicado por 10 el número de contribuciones “malas”, si no más» (Ghostty, 2026).
• Godot prohibió en junio de 2026 los agentes autónomos, el vibe coding y el código sustancial generado por IA, y solo dejó tareas pequeñas asistidas como el autocompletado de código: «La IA no puede asumir responsabilidades, y no podemos confiar en que quienes usan mucho la IA entiendan su código lo suficiente como para arreglarlo» (Godot Foundation, 2026).
• Rust adoptó en agosto de 2026 una política sobre LLM para el repositorio rust-lang/rust: «Está bien usar LLM para responder preguntas, analizar, destilar, pulir, comprobar, sugerir y revisar. Pero no para crear» (Rust Blog, 2026).
• GitHub lanzó ajustes de repositorio que permiten a los mantenedores desactivar las pull requests o limitarlas a los colaboradores (GitHub, 2026), y más tarde un límite al número de PR abiertas que puede tener un colaborador (GitHub, 2026).

¿Qué le hace la IA a las habilidades de los desarrolladores junior?

Para los juniors, el coste son las habilidades. En mi experiencia, los juniors que se apoyan en la IA suelen tener problemas con los fundamentos, y ahora hay investigación al respecto, parte de ella de las propias empresas de IA.

Anthropic hizo un ensayo aleatorizado con 52 ingenieros, en su mayoría junior, que aprendían Trio, una biblioteca async de Python que no habían usado antes. El grupo que usó IA sacó un 50 % en un cuestionario de comprensión posterior. El grupo que programó a mano sacó un 67 %. El grupo con IA fue solo unos dos minutos más rápido, una diferencia que no fue estadísticamente significativa (Anthropic, 2026). Perdieron comprensión y no ganaron una velocidad medible a cambio. Analicé ese estudio en detalle en ¿Todavía deberías escribir código a mano?, incluidas las formas de usar la IA que mantuvieron altas las puntuaciones. Para los ingenieros con experiencia que quieren evitar ese mismo deterioro, Cómo mantener tus habilidades de programación en forma cuando la IA escribe el código explica qué habilidades se pierden primero y cómo practicarlas.

La IA puede escribir el código por ti, pero todo lo anterior muestra por qué alguien tiene que seguir entendiéndolo. Creo que los fundamentos importan ahora más que antes. Construí LevelUpGo en torno a escribir Go tú mismo, desde tu primera línea hasta código de producción, con ejercicios que solo se superan cuando tu código compila y los tests pasan. La elección del lenguaje también ayuda. Por qué Go es el mejor lenguaje para el código escrito por IA explica cómo el compilador y las herramientas de Go detectan más errores de un agente antes de que lleguen a producción.

¿Las herramientas de IA para programar causan burnout?

La investigación dice que pueden causarlo, sobre todo por la mayor carga de trabajo y las expectativas que traen consigo.

Investigadores de la Oregon State University encuestaron a 442 desarrolladores profesionales sobre el uso de IA y el burnout. Descubrieron que la adopción de IA generativa aumenta el burnout, principalmente porque aumenta las exigencias laborales: más carga de trabajo y más presión organizativa (Feng et al., 2026). Dos participantes lo dijeron sin rodeos. Uno dijo: «las herramientas están bien, lo que han hecho con las expectativas de la dirección es absolutamente horrible». Otro dijo: «Voy rápido con la IA y muevo montañas de trabajo, pero estoy perdiendo la pasión por lo que hago».

Investigadores de UC Berkeley pasaron de abril a diciembre de 2025 dentro de una empresa tecnológica estadounidense de unos 200 empleados, observando cómo trabajaba de verdad la gente con IA (Harvard Business Review, 2026). El trabajo creció de tres formas:

• Ampliación de tareas. Como la IA podía cubrir lo que la gente no sabía, empezaron a asumir trabajo que nunca había sido suyo.
• Límites difusos. Empezar una tarea se volvió tan barato que el trabajo se coló en la hora de comer, las reuniones y las tardes.
• Más multitarea. La gente escribía código a mano mientras la IA preparaba otra versión, ejecutaba varios agentes a la vez y retomaba tareas antiguas porque ahora la IA podía encargarse de ellas, sin que nadie se lo pidiera.

Los investigadores describen un bucle. La IA acelera algunas tareas, lo que eleva las expectativas de velocidad, y eso hace que los trabajadores dependan todavía más de la IA. Un ingeniero del estudio lo resumió así: «Pensabas que quizá... podrías trabajar menos. Pero en realidad no trabajas menos. Trabajas lo mismo o incluso más».

Mi opinión

La IA puede aportar valor real y hacernos más productivos. La uso todos los días. Pero no es la solución a todo.

Lo que me llamó la atención de estos estudios es cuánto coinciden con lo que veo en el trabajo. En todos mis años como ingeniero de software, nunca había sentido que el software en general tuviera tan poca calidad como ahora. Para mí eso indica que todavía no hemos encontrado el equilibrio entre velocidad y calidad, y creo que la calidad importa más que la velocidad.

Así que trato la IA como una herramienta que comete muchos errores. Reviso lo que escribe en lugar de fiarme de ella, y le doy solo los permisos que necesita la tarea, porque la IA no se puede asegurar con prompts.

Después de revisar todos estos datos, me sigo preguntando si el coste es mayor que el valor que aportan estas herramientas. Todavía no tengo una respuesta definitiva. Eso sí, estoy bastante seguro de que es mucho más que el precio de la suscripción.

Preguntas frecuentes

¿Cuáles son los mayores riesgos de las herramientas de IA para programar?

Los mayores riesgos son el código que pasa la revisión pero falla en producción, los agentes con demasiado acceso que borran datos, una acumulación de revisiones que lleva a comprobaciones menos cuidadosas, las vulnerabilidades de seguridad y la pérdida de habilidades en los desarrolladores que delegan su aprendizaje. En la encuesta de 2026 de New Relic, el 82 % de los líderes tecnológicos podía nombrar un fallo en producción causado por código de IA en los seis meses anteriores (New Relic, 2026).

¿Por qué el código generado por IA se rompe en producción?

El agente no sabe cómo se comporta tu sistema en producción. No puede ver los patrones de tráfico, los días de más carga ni por qué el código existente maneja un caso límite como lo hace, y rara vez se para a preguntar. Además, los diffs grandes de IA hacen que los revisores lean por encima, así que esas lagunas se aprueban.

¿Cómo evitas que un agente de IA borre datos de producción?

Limita lo que puede alcanzar. Da a los agentes credenciales separadas y muy acotadas para cada entorno, no compartas nunca almacenamiento ni copias de seguridad entre producción y staging, guarda el estado de Terraform en un almacenamiento remoto con bloqueo y exige que una persona apruebe cada comando destructivo. Las instrucciones en un prompt no son una barrera de seguridad.

¿Es seguro el código generado por IA?

No por defecto. El Vibe Security Radar de Georgia Tech vinculó 35 CVE a código escrito por IA solo en marzo de 2026, y el fundador del proyecto calcula que la cifra real es de cinco a diez veces mayor (Infosecurity Magazine, 2026). Revisa línea por línea la autenticación, la autorización, los pagos y todo lo que maneje datos de usuarios.

¿Deberían los desarrolladores junior usar herramientas de IA para programar?

Úsalas para que te expliquen conceptos y errores, no para escribir código que todavía no entiendes. En el ensayo de Anthropic de 2026, los juniors que aprendieron una biblioteca nueva con IA sacaron 17 puntos menos en comprensión y no fueron apreciablemente más rápidos (Anthropic, 2026).

Fuentes

• New Relic, 2026 State of AI Coding press release (junio de 2026)
• Stella Laurenzo, Claude Code is unusable for complex engineering tasks with the Feb updates, issue de GitHub #42796 (abril de 2026)
• Anthropic, April 23 postmortem (abril de 2026)
• The Register, Cursor Opus agent snuffs out startup's production database (abril de 2026)
• Alexey Grigorev, How I dropped our production database (marzo de 2026)
• The Decoder, AWS AI coding tool decided to delete and recreate a customer-facing system (febrero de 2026)
• Amazon, Response to the Financial Times on the AWS service outage (febrero de 2026)
• Nx, S1ngularity: what happened, how we responded, what we learned (2025)
• StepSecurity, Popular Nx build system package compromised with data-stealing malware (agosto de 2025)
• Wiz, s1ngularity's aftermath: AI, TTPs, and impact in the Nx supply chain attack (septiembre de 2025)
• Socket, SANDWORM_MODE: npm worm hijacks CI workflows and poisons AI toolchains (febrero de 2026)
• Faros AI, The AI Acceleration Whiplash: ten takeaways (abril de 2026)
• Yu et al., Habituation at the Gate: Rising Approval and Declining Scrutiny in Human Review of AI Agent Code (junio de 2026)
• Sonar, 96% don't fully trust AI output, yet only 48% verify it (enero de 2026)
• Microsoft .NET Blog, Ten months with Copilot coding agent in dotnet/runtime (marzo de 2026)
• Georgia Tech, Bad Vibes: AI-generated code is vulnerable, researchers warn (abril de 2026)
• Infosecurity Magazine, Researchers sound the alarm on vulnerabilities in AI-generated code (marzo de 2026)
• GitGuardian, The State of Secrets Sprawl 2026 (marzo de 2026)
• Axios, Thousands of AI-built apps exposed sensitive corporate and personal data (mayo de 2026)
• CodeScene, AI coding assistants increase defect risk by 30% in unhealthy code (enero de 2026)
• Daniel Stenberg, Death by a thousand slops (julio de 2025) y The end of the curl bug-bounty (enero de 2026)
• Ghostty, Updated AI usage policy for contributions, PR #10412 (enero de 2026)
• Godot Foundation, Changes to our contribution policies (junio de 2026)
• Rust Blog, rust-lang/rust is adopting an LLM policy (agosto de 2026)
• GitHub Changelog, New repository settings for configuring pull request access (febrero de 2026) y Limit open pull requests for users without write access (junio de 2026)
• Anthropic, How AI assistance impacts the formation of coding skills (enero de 2026)
• Feng, Afroz y Sarma, From Gains to Strains: Modeling Developer Burnout with GenAI Adoption, ICSE-SEIS (2026)
• Ranganathan y Ye, AI Doesn't Reduce Work, It Intensifies It, Harvard Business Review (febrero de 2026)