La programación con IA está haciendo que el código fuente sea abundante, pero la verificación sigue siendo escasa
Google News puso de relieve una afirmación contundente sobre la inteligencia artificial y el software: el código se está volviendo de solo escritura y desechable. La expresión refleja un cambio real. Los agentes de programación pueden generar implementaciones más rápido de lo que muchos equipos pueden comprenderlas, revisarlas o incorporarlas de forma segura.
El conflicto no es simplemente humanos contra máquinas. Es velocidad de generación frente a comprensión organizacional. La IA puede reducir el coste de producir código mientras eleva el coste de demostrar que el sistema resultante sigue siendo correcto, seguro y mantenible.
Esta distinción importa porque la evidencia más sólida no respalda una historia simple sobre código de IA que se descarta rápidamente. En cambio, apunta a una inversión más profunda. El código fuente se está volviendo abundante, mientras que las especificaciones, el criterio arquitectónico, la verificación y la rendición de cuentas siguen siendo escasos.
Lo que realmente cambió con la historia de Google News
La tesis del código de solo escritura desplaza el debate sobre la programación con IA, de la velocidad de tecleo al control de todo el sistema de software.
El término ganó visibilidad gracias a Joseph Ruscio, socio general de Heavybit. Su ensayo de febrero de 2026, write-only code, describe un futuro empresarial en el que los agentes generan tanta implementación que los humanos dejan de leer cada línea.
“De solo escritura” no significa que el código sea literalmente ilegible. Significa que leer cada línea generada deja de ser el principal mecanismo de control. En su lugar, las personas revisan especificaciones, restricciones, pruebas, arquitectura y comportamiento observable.
Es una afirmación más precisa que decir que los desarrolladores usarán un autocompletado mejor. Un programador en pareja basado en IA todavía presupone que un humano escribe o revisa estrechamente la implementación. Un agente de programación puede inspeccionar un repositorio, editar varios archivos, ejecutar comandos, realizar pruebas y revisar su trabajo con una intervención limitada.
El artículo destacado por Google News también encaja en un debate más amplio que ya se desarrolla en conferencias de ingeniería. En QCon London 2026, Hannah Foxwell sostuvo que revisar grandes volúmenes de código generado no es ni agradable ni sostenible.
Su respuesta propuesta fue adelantar la revisión entre pares. Los equipos examinarían la especificación, la estrategia de pruebas y la arquitectura antes de que un agente escriba la implementación. La cobertura de QCon de InfoQ vinculó directamente esa propuesta con el concepto de código de solo escritura de Ruscio.
Por tanto, el acontecimiento significativo no es el lanzamiento de un producto. Es la aparición de un modelo operativo coherente para el desarrollo asistido por IA.
Bajo ese modelo, los desarrolladores definen la intención y los límites aceptables. Los agentes traducen esos límites en código. Los sistemas automatizados prueban el resultado, mientras que las personas se concentran en decisiones que requieren contexto empresarial o criterio arquitectónico.
Este modelo cambia la unidad de revisión. Una solicitud de extracción que contiene miles de líneas generadas se vuelve menos útil como principal límite de confianza. Los artefactos importantes pasan a ser el requisito, el modelo de amenazas, la suite de pruebas, la política de dependencias, el plan de despliegue y la evidencia en tiempo de ejecución.
El código de IA desechable se sitúa en el extremo más agresivo de este modelo. Un agente podría generar una migración temporal, una herramienta de diagnóstico, un convertidor de datos, una fixture de pruebas o un prototipo. El equipo puede descartar el código fuente una vez finaliza la tarea inmediata.
Sin embargo, los efectos rara vez desaparecen con el archivo. Un script de corta duración todavía puede modificar una base de datos, exponer un secreto, crear recursos en la nube o incorporar una suposición errónea a los datos de clientes. El código fuente puede ser desechable, mientras que las consecuencias siguen siendo duraderas.
Por eso el encuadre de Google News merece atención. Da un nombre memorable a un cambio genuino, pero el nombre también puede inducir a error. La pregunta central no es si los humanos leen cada línea. Es si los equipos conservan suficiente evidencia y conocimiento para gobernar lo que hacen esas líneas.
La generación más rápida somete a presión a las organizaciones de ingeniería
La IA convierte la implementación en un insumo más barato, pero no hace que la entrega de software sea igual de barata.
Los procesos de ingeniería tradicionales suponen que la generación de código es una restricción significativa. Los equipos asignan trabajo, implementan cambios, revisan solicitudes de extracción, ejecutan pruebas y llevan las compilaciones aprobadas a producción.
Los agentes de programación comprimen la etapa de implementación. No comprimen automáticamente la aclaración de producto, la revisión de seguridad, las pruebas de integración, la preparación operativa ni la coordinación organizacional.
La investigación DORA de Google Cloud describe la IA como un amplificador. Refuerza a las organizaciones capaces y magnifica las debilidades de las que tienen dificultades. El informe DORA de 2025 sostiene que los resultados dependen más del sistema organizacional que rodea a la herramienta que de la herramienta por sí sola.
Ese hallazgo somete a los líderes de ingeniería a una presión inmediata. Si los agentes producen más cambios, los revisores afrontan colas mayores. La infraestructura de pruebas recibe más carga. Los equipos de plataforma deben respaldar más experimentos, entornos e intentos de despliegue.
El antiguo cuello de botella se desplaza en lugar de desaparecer. La implementación deja paso a la capacidad de absorción, es decir, la capacidad de la organización para comprender, integrar, verificar y operar un flujo creciente de cambios.
Aquí es donde el código de solo escritura adquiere importancia operativa. Un desarrollador puede pedir a un agente que añada un endpoint, repare una prueba, migre una biblioteca o cree una pequeña aplicación interna. Cada solicitud puede producir código plausible antes de que el desarrollador haya explorado por completo el sistema circundante.
La plausibilidad no es lo mismo que la corrección. El código generado puede satisfacer el prompt mientras incumple una convención no documentada. Puede duplicar un servicio existente, elegir una dependencia inadecuada, debilitar una comprobación de autorización o crear una ruta operativa costosa.
Antes, los humanos aprendían muchas de estas restricciones mientras implementaban el cambio. Se encontraban con interfaces incómodas, leían código cercano, hacían preguntas a los mantenedores y descubrían por qué existían decisiones anteriores.
Un agente puede omitir buena parte de ese proceso de aprendizaje. A menudo esto es útil, pero también elimina una fuente de comprensión organizacional. La implementación llega sin garantizar que nadie haya asimilado el conocimiento necesario para mantenerla.
La carga recae primero sobre los desarrolladores sénior y los mantenedores. Ellos poseen el contexto necesario para distinguir un parche localmente correcto de uno perjudicial para el sistema en su conjunto. Cuando la generación se acelera, su criterio se convierte en un servicio compartido y cada vez más escaso.
Los equipos de seguridad afrontan un problema similar. El código de IA desechable puede entrar a través de prototipos, paneles internos, scripts de migración, utilidades de soporte y automatizaciones temporales. Estos artefactos a menudo eluden los controles aplicados a las aplicaciones orientadas al cliente.
Un prototipo puede volverse permanente porque los compañeros empiezan a depender de él. Un script de un solo uso puede volver a ejecutarse meses después. Las credenciales temporales pueden llegar a los registros. Los datos de prueba pueden filtrarse a un entorno activo.
La presión también alcanza a los ingenieros júnior. Si los agentes se encargan de la implementación rutinaria, los desarrolladores más nuevos pierden parte del trabajo mediante el cual antes aprendían la estructura de la base de código, la depuración y la disciplina de producción.
Los equipos no pueden resolver ese problema prohibiendo la IA o exigiendo que los humanos inspeccionen cada token generado. Necesitan trayectorias de aprendizaje deliberadas, propiedad explícita y cambios más pequeños que puedan revisarse.
Un registro consultable de decisiones arquitectónicas puede ayudar a preservar el contexto faltante. Los equipos que crean una base de conocimiento técnico pueden conectar especificaciones, informes de incidentes y restricciones de diseño con el código que modifican los agentes.
La presión organizacional es, por tanto, clara. Las herramientas de programación con IA recompensan a los equipos que ya cuentan con pruebas sólidas, límites documentados, interfaces estables y retroalimentación rápida. Exponen a los equipos que dependen de conocimiento no escrito y de revisores heroicos.
El código de solo escritura invierte el contrato tradicional de revisión
El antiguo contrato decía que los humanos confían en el código después de leerlo; el contrato emergente dice que confían en el comportamiento después de restringirlo y probarlo.
Durante décadas, la mantenibilidad significaba que otro ingeniero podía leer una función, comprender su intención y modificarla de forma segura. Los nombres, la estructura, los comentarios, la modularidad y la documentación estaban al servicio de la comprensión humana.
El código de solo escritura cuestiona la economía que sustentaba ese estándar. Si un agente puede regenerar un componente a partir de una especificación precisa, conservar cada detalle de la implementación puede resultar menos valioso.
Eso no elimina la mantenibilidad. Cambia qué debe mantenerse.
El activo duradero puede ser la especificación, en lugar de la implementación actual. Las pruebas pueden convertirse en declaraciones ejecutables de intención. Los contratos de interfaz pueden importar más que la elegancia interna. Las reglas de arquitectura pueden convertirse en restricciones aplicadas por máquinas, en lugar de orientación en un documento.
Esta inversión se parece a cambios anteriores en la abstracción del software. La mayoría de los desarrolladores ya no inspeccionan las instrucciones de máquina generadas antes de lanzar una aplicación. Confían en compiladores, sistemas de tipos, pruebas, sistemas operativos y monitorización en tiempo de ejecución.
El código generado por IA difiere en un aspecto importante. Un compilador realiza una traducción acotada y determinista. Un agente de programación toma decisiones probabilísticas sobre diseño, dependencias, API y comportamiento.
Esa diferencia impide que los equipos traten a un agente como si fuera simplemente otro compilador. El agente necesita un arnés, es decir, las herramientas, permisos, contexto, pruebas y ciclos de retroalimentación que restringen su trabajo.
Un buen arnés puede rechazar dependencias prohibidas, aplicar límites entre módulos, limitar el acceso a la red, ejecutar escáneres de seguridad y exigir pruebas antes de aceptar un cambio. También puede mantener las ediciones generadas lo suficientemente pequeñas para una revisión significativa de código de IA.
La revisión en sí debe volverse escalonada. Las comprobaciones automatizadas rápidas deberían cubrir formato, tipos, política de dependencias, vulnerabilidades conocidas, pruebas y reglas de arquitectura. Los revisores humanos deberían centrarse en la intención, las compensaciones, los límites de amenazas y los modos de fallo.
Esto no autoriza a fusionar un parche enorme y opaco porque la suite de pruebas haya pasado. Las pruebas solo verifican los casos que expresan. No pueden proteger supuestos que nadie identificó.
Las especificaciones afrontan el mismo límite. Un agente puede seguir una solicitud detallada y aun así construir el producto equivocado. El requisito puede omitir una necesidad de accesibilidad, una política de retención, una norma regional o una restricción operativa.
Por tanto, el contrato de revisión emergente tiene varios puntos de control. Las personas aprueban qué debe cambiar. Las máquinas comprueban si se cumplen las restricciones definidas. La telemetría de producción revela si el comportamiento resultante coincide con la realidad.
Cada punto cubre una clase de fallo distinta. Ninguno es suficiente por sí solo.
El cambio también transforma cómo los equipos deberían evaluar la productividad de los desarrolladores. Las líneas generadas, las tareas completadas y las solicitudes de extracción abiertas miden actividad. No muestran si los usuarios recibieron valor ni si el sistema se volvió más difícil de operar.
El análisis posterior de DORA concluyó que una mayor adopción de IA se asociaba tanto con mayor rendimiento como con mayor inestabilidad. Su análisis de las tensiones de entrega de IA señala que el tiempo ahorrado durante la creación suele reasignarse a la auditoría y la verificación.
Ese resultado explica por qué programar puede sentirse más rápido sin que la entrega se acelere de forma proporcional. Los desarrolladores perciben el beneficio inmediato de la generación. Las organizaciones heredan el coste diferido de la integración.
La línea divisoria práctica no está entre código escrito a mano y código generado. Está entre cambio gobernado y cambio no gobernado.
El código de IA desechable y gobernado puede ser razonable para una transformación aislada que se ejecute en un sandbox. El código generado sin gobernanza puede ser peligroso incluso cuando cada línea parece convencional y permanece en el repositorio durante años.
La evidencia complica la afirmación sobre el código de IA desechable
El código creado por IA no es automáticamente de corta vida, de baja calidad ni más rápido de producir en todos los entornos reales de desarrollo.
Un preprint de 2026 de Musfiqur Rahman y Emad Shihab examinó más de 200.000 unidades de código en 201 proyectos de código abierto. Su estudio sobre supervivencia del código llegó a un resultado que contradice la narrativa del código desechable.
A nivel de línea, el código creado por agentes mostró una tasa de modificación 15,8 puntos porcentuales menor y un riesgo de modificación un 16 por ciento inferior al del código creado por humanos. En otras palabras, el código de IA observado sobrevivió más tiempo.
Eso no demuestra que el código de IA fuera mejor. El código puede permanecer sin cambios porque funciona, porque nadie lo usa o porque los responsables de mantenimiento dudan en tocarlo. La longevidad por sí sola no puede distinguir entre esas explicaciones.
El estudio también halló una tasa ligeramente mayor de modificaciones correctivas para el código creado por agentes: 26,3 por ciento frente al 23 por ciento del código humano. La variación entre agentes individuales superó la diferencia global entre agentes y humanos.
Estos resultados sugieren que la etiqueta de origen es demasiado burda. La elección del modelo, el tipo de tarea, la calidad del repositorio, la supervisión humana y las prácticas organizativas pueden importar más que el hecho de que una IA produjera el primer borrador.
Otro experimento llegó a una conclusión igualmente incómoda. METR reclutó a 16 desarrolladores con experiencia que trabajaban en sus propios repositorios maduros de código abierto. El ensayo cubrió 246 incidencias reales y permitió o prohibió aleatoriamente las herramientas de IA.
Los desarrolladores que utilizaron herramientas de IA de principios de 2025 tardaron un 19 por ciento más en completar las incidencias asignadas. El ensayo de productividad también detectó una llamativa brecha de percepción.
Antes de completar el trabajo, los participantes esperaban que la IA los hiciera un 24 por ciento más rápidos. Después, seguían creyendo que los había acelerado en un 20 por ciento, pese a la ralentización medida.
Los investigadores advirtieron contra generalizar el resultado a todos los desarrolladores o tareas. Sus participantes conocían bien repositorios grandes y las herramientas representaban un periodo concreto de un mercado en rápida evolución.
Incluso con esas limitaciones, el estudio expone una debilidad clave en las afirmaciones sobre el código de IA desechable. La generación rápida no equivale a una finalización rápida. Formular instrucciones, esperar, comprobar, corregir e integrar puede consumir la ganancia aparente.
La opinión de los desarrolladores refuerza esa cautela. La encuesta de 2025 de Stack Overflow informó de que el uso de IA seguía aumentando mientras la confianza descendía. Solo el 29 por ciento de los encuestados confiaba en la precisión de la IA, frente a cerca del 40 por ciento en encuestas anteriores.
Su análisis sobre la confianza de los desarrolladores indica que más del 84 por ciento de los encuestados utilizaba o planeaba utilizar herramientas de IA. La adopción y la confianza avanzaban en direcciones opuestas.
Estos hallazgos no invalidan el código de un solo uso. Aclaran las condiciones que requiere.
En primer lugar, la regeneración debe ser realmente más barata que comprender y reparar la implementación actual. Eso es más plausible para un pequeño adaptador o una fixture de prueba que para un libro mayor de pagos.
En segundo lugar, la especificación debe capturar una parte suficiente del requisito real. Una instrucción que describa solo el camino feliz no puede respaldar una regeneración segura.
En tercer lugar, el entorno debe detectar comportamientos inaceptables. Sin pruebas, comprobaciones de políticas, controles de acceso y observabilidad en tiempo de ejecución, el equipo no puede distinguir la generación exitosa de un fallo plausible.
En cuarto lugar, alguien debe asumir la responsabilidad del resultado. Un agente no puede responder por una interrupción, una vulneración de la privacidad o un incidente de seguridad. La responsabilidad humana y organizativa sobrevive a cualquier cambio de autoría.
Por tanto, la lectura escéptica es importante. «Desechable» puede convertirse en una excusa conveniente para descuidar la calidad del diseño y la documentación. Los equipos pueden asumir que podrán regenerar un componente más adelante y descubrir después que su especificación real solo existía en el comportamiento de producción y en la memoria del personal.
El código puede ser barato de recrear mientras que el contexto sigue siendo costoso de recuperar.
El código fuente desechable puede dejar efectos duraderos en seguridad y datos
Eliminar el código fuente generado no revierte las acciones que dicho código realizó.
Pensemos en un desarrollador que pide a un agente crear una migración única de datos de clientes. El script lee un esquema antiguo, transforma los registros y los escribe en un nuevo servicio.
El equipo puede eliminar el script después de la migración. Los registros modificados permanecen. También los campos corrompidos, los identificadores filtrados, las entradas de auditoría incompletas o los permisos no deseados.
Un script de infraestructura generado crea el mismo problema. Puede aprovisionar un bucket de almacenamiento público, una cuenta de servicio con permisos amplios o una credencial de larga duración. Eliminar el archivo no elimina necesariamente el recurso.
Las aplicaciones internas temporales también tienden a volverse permanentes. Un equipo de ventas empieza a utilizar un panel generado. Operaciones depende de sus resultados. El desarrollador original pasa a otro proyecto.
Lo que comenzó como código de IA desechable ahora sustenta un proceso empresarial. Puede carecer de propietario, política de dependencias, plan de copias de seguridad, revisión de accesibilidad o procedimiento de incidentes.
Este riesgo aumenta cuando los agentes reciben permisos amplios. Un agente de programación que puede ejecutar comandos de shell, acceder a servicios de red, consultar bases de datos y publicar cambios tiene un efecto mucho mayor que una herramienta de autocompletado.
Las solicitudes de permisos ofrecen una protección limitada. Las personas se habitúan a las aprobaciones, especialmente cuando una herramienta genera muchas solicitudes. La defensa más sólida es una contención determinista.
Un agente debe recibir el acceso mínimo al sistema de archivos, la red, las credenciales y el despliegue necesarios para la tarea. Las acciones de alto riesgo deben realizarse en entornos aislados con registros claros y reglas de caducidad.
Los equipos también deben distinguir entre operaciones reversibles e irreversibles. Generar un archivo local suele ser reversible. Enviar un mensaje, eliminar datos de producción, rotar un secreto compartido o modificar una cuenta externa puede no serlo.
El sistema debe exigir pruebas más sólidas antes de permitir acciones irreversibles. Esas pruebas podrían incluir una ejecución en seco, aprobación humana, vista previa del cambio, confirmación de copia de seguridad o evaluación de políticas.
La revisión de código de IA debe examinar los efectos secundarios, no solo el estilo del código fuente. Los revisores deben preguntarse qué datos lee el programa, con qué sistemas se comunica, qué estado modifica y cómo puede revertirse la operación.
La procedencia también importa. Los equipos necesitan saber qué modelo o agente produjo un cambio, qué especificación recibió, qué herramientas invocó, qué pruebas se ejecutaron y quién aprobó el resultado.
Este registro no es decoración burocrática. Ayuda a los investigadores a reconstruir fallos cuando la implementación generada fue sustituida o eliminada posteriormente.
El riesgo de la cadena de suministro crea otro efecto duradero. Un agente puede seleccionar una dependencia por similitud de nombres o ejemplos obsoletos. Ese paquete puede introducir vulnerabilidades u obligaciones de licencia mucho después de que desaparezca el código inicial.
Los controles del repositorio pueden bloquear paquetes desconocidos, exigir lockfiles, analizar licencias y restringir las fuentes de instalación. Los agentes deben operar dentro de esos controles en lugar de eludirlos por conveniencia.
El objetivo no es conservar para siempre todo el código fuente desechable. Es conservar las pruebas necesarias para explicar y gobernar los efectos del código fuente.
Un programa temporal puede seguir siendo temporal cuando su entorno está aislado, sus entradas están controladas, sus salidas se validan y su vida útil se aplica. Sin esas condiciones, «temporal» describe una intención más que una propiedad.
Lo que los lectores de Google News deberían vigilar a continuación
El futuro de escribir código sin leerlo se decidirá por la economía de la verificación, no por demostraciones de generación de código.
La primera señal que hay que vigilar es si las organizaciones trasladan la revisión a etapas anteriores. Las especificaciones, los planes de prueba, los modelos de amenazas y las restricciones arquitectónicas deberían recibir una atención más formal antes de que los agentes comiencen la implementación.
Las pruebas de ese cambio reforzarían la tesis del código de un solo uso. Los equipos tratarían la intención como el artefacto duradero y la implementación como una expresión reemplazable de ella.
Si las pull requests siguen creciendo mientras las prácticas de revisión permanecen sin cambios, la tesis se debilita como modelo operativo. Describiría el volumen de código sin resolver el problema de comprensión resultante.
La segunda señal es si las métricas de entrega mejoran junto con la productividad individual. Las organizaciones deberían medir el tiempo de entrega, la tasa de fallos de cambios, el tiempo de recuperación, los defectos que llegan a producción y la carga operativa.
Más código generado no equivale al éxito. Más funcionalidades completadas con un comportamiento estable en producción sí lo hacen.
El trabajo de DORA sugiere que la IA puede aumentar el rendimiento al tiempo que incrementa la inestabilidad. Una mejora sostenida en ambas dimensiones demostraría que las pruebas, la ingeniería de plataformas y la gobernanza están alcanzando a la generación.
Una inestabilidad continua respaldaría la conclusión contraria. Significaría que las organizaciones producen implementaciones más rápido de lo que pueden absorberlas de forma segura.
La tercera señal es si los agentes de programación obtienen una contención más sólida y medible. Hay que observar el sandboxing predeterminado, las credenciales restringidas, las políticas legibles por máquina, los registros completos de herramientas y la aprobación obligatoria para acciones irreversibles.
Estos controles harían más seguro el código de IA desechable porque limitan su efecto incluso cuando los humanos no inspeccionan cada línea. También darían a las empresas una base creíble para delegar tareas más amplias.
Un aumento de filtraciones relacionadas con agentes, cambios no autorizados o aplicaciones internas abandonadas expondría la debilidad del modelo. Mostraría que la eliminación redujo la visibilidad sin reducir las consecuencias.
Los lectores también deberían evitar tratar todos los flujos de trabajo de programación con IA como una sola categoría. Una prueba unitaria generada, una migración de repositorio y un cambio autónomo en producción presentan riesgos distintos.
El nivel adecuado de supervisión depende de la sensibilidad de los datos, la reversibilidad, la criticidad del sistema y la confianza en la verificación. Los equipos necesitan categorías explícitas en lugar de un único proceso de aprobación universal.
Google News puso en primer plano una expresión provocadora, pero la expresión debería iniciar el análisis en lugar de terminarlo. El código puede escribirse sin leerse sin dejar de ser responsable. Puede ser reemplazable sin quedar libre de consecuencias.
El desafío práctico consiste en hacer que la intención, las restricciones, las pruebas, la procedencia y la evidencia operativa sean más duraderas que cualquier implementación concreta. Los equipos que logren ese equilibrio podrán beneficiarse de una generación más barata sin renunciar al control.
Los equipos que no puedan describir esos controles deberían detenerse antes de llamar desechable a su código. Deberían plantearse una pregunta más difícil: si ninguna persona lee completamente esta implementación, ¿qué sistema fiable detectará el error antes que los clientes?
