La revisión de Anthropic Claude Code sustituye la lectura humana rutinaria mientras la IA escribe el 90% del código
La revisión de Anthropic Claude Code ha entrado en un terreno desconocido porque Claude ya escribe aproximadamente el 90% del código del producto, según la empresa. Entre junio y septiembre de 2026, las pull requests fusionadas se duplicaron con creces. Sin embargo, la proporción que requirió una reversión habría caído más de un 40%.
Esa combinación es la verdadera historia. Anthropic no respondió a una explosión de código escrito por máquinas asignando a las personas más líneas para inspeccionar. Trasladó la mayor parte de la lectura rutinaria a otros agentes de Claude y reservó la aprobación humana para cambios con mayor riesgo.
No se trata simplemente de una versión más rápida de la revisión convencional. Cambia qué significa revisar, quién lo hace y dónde comienza la responsabilidad. Anthropic ahora considera la atención humana como un recurso escaso que debe seguir el riesgo, en lugar de cada línea individual.
El enfoque también llega con una limitación importante. Los resultados destacados son mediciones propias de Anthropic, sin datos brutos publicados ni auditoría independiente. Su proceso depende de una automatización extensa, infraestructura interna, lanzamientos escalonados y un acceso inusualmente amplio a sus propios modelos.
La competencia resultante no es Claude contra los programadores humanos. Es cobertura automatizada frente a inspección humana universal. Anthropic apuesta a que las comprobaciones por capas, las aprobaciones específicas y la reversibilidad barata pueden controlar más riesgo que la lectura línea por línea a velocidad de máquina.
Qué cambió en la revisión de Anthropic Claude Code
Anthropic trasladó la revisión de código de una única puerta humana a un sistema continuo de comprobaciones automatizadas, agentes revisores, aprobaciones específicas y reversión rápida.
La empresa describió el sistema en una publicación de ingeniería del 15 de octubre sobre la revisión de Claude Code. Los autores Addy Osmani, Morgan Westlee Lunt y Qing Wang plantearon el problema en torno al volumen de producción. Cuando los agentes generan cambios más rápido de lo que las personas pueden leerlos, una cola tradicional se convierte en un cuello de botella para la entrega.
Anthropic afirma que cada pull request recibe una revisión de Claude antes de que una persona la examine. El revisor lee el cambio propuesto en relación con el repositorio más amplio y con la intención declarada de la pull request. En el caso de correcciones de errores, intenta identificar la causa raíz en vez de comprobar solo el parche visible.
Varios agentes buscan luego posibles defectos en paralelo. Otro grupo vota sobre cada hallazgo, y el sistema publica un problema solo cuando suficientes revisores coinciden. Anthropic afirma que probó filtros que eliminan comentarios limitados al estilo, diagnósticos o limpieza opcional.
Los hallazgos restantes reciben etiquetas de gravedad. Los desarrolladores o agentes deben corregir cada hallazgo o cerrar su hilo con una razón. Una revisión de seguridad automatizada independiente también puede impedir una fusión mientras un problema siga sin resolverse.
Estas revisiones se sitúan junto a las salvaguardas convencionales. Las pull requests siguen enfrentándose a linting, comprobaciones de tipos, compilaciones y pruebas en las plataformas compatibles. Una cola de fusión vuelve a ejecutar las comprobaciones frente a la rama principal actual, reduciendo los fallos causados por cambios válidos de forma independiente que interactúan mal entre sí.
La revisión comienza antes de que exista una pull request. Claude ejecuta pruebas, compilaciones o comprobaciones visuales y muestra la evidencia resultante. Después, un subagente con contexto nuevo inspecciona el diff, lo que reduce la posibilidad de que el agente autor simplemente repita sus supuestos originales.
Las anteriores prácticas de programación de Anthropic recomendaban separar los contextos de autoría y verificación. El nuevo flujo de trabajo convierte esa recomendación en un sistema operativo para todo el equipo.
La aprobación humana depende del riesgo clasificado del cambio. El trabajo de bajo riesgo puede fusionarse una vez superadas las comprobaciones automatizadas y de seguridad. Los ejemplos incluyen documentación, cambios de texto, funciones internas y adiciones ocultas tras feature flags.
El trabajo ordinario de producto generalmente requiere una persona. Las áreas sensibles, como el almacenamiento en caché, los prompts de sistema y los mecanismos de actualización, también reciben atención humana. Los cambios de mayor riesgo requieren dos personas, mientras que determinadas rutas protegidas siempre activan una revisión manual.
El clasificador evalúa el cambio, no si lo escribió una persona o un agente. Un segundo clasificador aún puede exigir participación humana cuando el nivel original parece demasiado permisivo. La aprobación de un agente nunca ocupa una plaza reservada para una persona.
Esta distinción importa. Anthropic no ha eliminado la responsabilidad humana ni ha afirmado que la revisión por IA haga que el software esté libre de errores. Ha separado la detección rutinaria de defectos de las decisiones relacionadas con la arquitectura, la dirección de producto, los sistemas sensibles y el riesgo aceptable.
La persona que dio instrucciones a Claude sigue siendo responsable del resultado. Cada aprobación se aplica a un commit específico, por lo que cambios posteriores pueden invalidarla. En el modelo de Anthropic, la delegación cambia quién escribe y lee el código, pero no quién asume el resultado.
Las cifras hacen insostenible la revisión solo humana
Las métricas comunicadas por Anthropic sugieren que la producción de código ya ha superado cualquier proceso de revisión basado en la lectura humana universal.
La empresa afirma que las pull requests fusionadas en el repositorio de Claude Code se duplicaron con creces entre junio y septiembre de 2026. Durante el mismo período, la proporción que necesitó reversiones cayó más de un 40%.
Estas cifras describen una dirección, no el rendimiento completo. Anthropic no reveló el número absoluto de pull requests, la tasa inicial de reversiones, la tasa final de reversiones ni la variación estadística. Una caída relativa del 40% podría partir de una base alta o baja.
La cifra del 90% también exige una redacción cuidadosa. Anthropic afirma que Claude escribe aproximadamente el 90% del código de Claude Code. Eso no significa que el modelo elija de forma independiente las prioridades de producto, defina todos los requisitos o asuma la responsabilidad del despliegue.
Los ingenieros siguen dirigiendo las tareas, juzgando la evidencia, resolviendo compromisos de diseño y decidiendo si el trabajo debe existir. La autoría de la máquina mide la generación de código, mientras que la ingeniería de software abarca mucho más que producir líneas.
Incluso con esas salvedades, Anthropic afronta un problema real de escalado. Su monorepo independiente habría pasado de unas 2.500 modificaciones fusionadas al día en mayo a más de 30.000 en septiembre. La empresa creó un sistema interno de control de código fuente llamado Scion para manejar esa carga de trabajo.
Claude Code utiliza un repositorio separado, por lo que la cifra de 30.000 cambios no mide directamente al equipo del producto. Aun así, el relato de Anthropic sobre su rediseño del control de código fuente muestra la presión más amplia que rodea su infraestructura de desarrollo.
Las historias de Scion y Claude Code apuntan al mismo cuello de botella. Una vez que los agentes de programación pueden crear, probar y revisar cambios de forma continua, escribir código deja de controlar el rendimiento. Las colas de revisión, las compilaciones, los permisos, los sistemas de integración y los controles de lanzamiento se convierten en los factores limitantes.
La revisión de código tradicional presupone que llega un número manejable de cambios producidos por personas. Otra persona lee cada diff, solicita revisiones y aprueba la versión final. Ese modelo empieza a romperse cuando la producción crece más rápido que la capacidad de los revisores.
Añadir revisores no resuelve por completo el desajuste. Los ingenieros experimentados son escasos, y la revisión constante interrumpe el trabajo de diseño, la depuración y las decisiones de producto. Una organización puede aumentar el personal de revisión y aun así perder atención compartida a través de un flujo creciente de cambios.
Por ello, Anthropic mide más que el número de comentarios generados. Realiza seguimiento de las aprobaciones humanas por pull request, los comentarios humanos, el tiempo de espera, las reversiones y los incidentes. El objetivo declarado es reducir el tiempo de revisión humana sin trasladar ese tiempo a la recuperación en producción.
La empresa también informa de que su revisor comercial de IA elevó la proporción de pull requests internas que reciben comentarios sustanciales del 16% al 54%. La mayoría de los cambios de más de 1.000 líneas supuestamente atraen hallazgos, mientras que la mayoría de los cambios más pequeños vuelven limpios.
Ese resultado no establece por sí solo la precisión. Más comentarios pueden representar una mejor detección, más ruido o ambas cosas. Anthropic afirma que evalúa la calidad de los comentarios observando si los desarrolladores corrigen los hallazgos, los rechazan o identifican el comportamiento informado como intencional.
La señal más amplia es organizativa. Anthropic ya no considera que una persona lea cada línea modificada como la prueba definitoria de la revisión. Mide si el sistema combinado detecta problemas, dirige bien la atención y limita el daño en producción.
Ese cambio presiona a todas las organizaciones de ingeniería que despliegan agentes de programación. Si la producción de los agentes crece mientras la política de revisión se mantiene fija, las colas se expanden y desaparecen las ganancias esperadas de productividad. Los equipos deben restringir la generación o rediseñar cómo la validan.
La cobertura automatizada desafía la inspección humana universal
La competencia central enfrenta la amplia cobertura de las máquinas con la creencia de que todo cambio significativo merece una lectura humana directa.
La inspección humana universal ofrece una promesa intuitiva. Un ingeniero cualificado entiende el código, ve el cambio y acepta la responsabilidad antes de que se publique. Esa práctica puede difundir conocimiento al tiempo que detecta supuestos que las pruebas automatizadas pasan por alto.
Sin embargo, la promesa se debilita cuando la revisión se vuelve apresurada. Una persona ante una cola grande puede escanear en lugar de razonar, aprobar código de aspecto familiar o centrarse en el estilo en vez del comportamiento. Una firma humana no garantiza comprensión.
La alternativa de Anthropic utiliza varias capas especializadas. Un agente crea el cambio, otro lo revisa con contexto nuevo, varios agentes buscan errores y agentes separados evalúan cada hallazgo. La revisión de seguridad, la integración continua, las comprobaciones de fusión, el lanzamiento escalonado y la reversión cubren distintos modos de fallo.
Esto se parece a una defensa en profundidad. Ninguna capa individual necesita una cobertura perfecta porque las capas posteriores pueden detectar lo que las anteriores pasan por alto. La clasificación de riesgo dirige entonces el escaso criterio humano hacia los cambios con mayor impacto potencial.
El mecanismo también ofrece a Anthropic una cobertura de revisión más amplia. Las máquinas pueden inspeccionar cada pull request sin esperar el calendario de un colega. Pueden examinar el contexto del repositorio, aplicar convenciones documentadas y repetir las mismas comprobaciones en miles de cambios.
Las instrucciones almacenadas en CLAUDE.md describen el proyecto, sus convenciones y sus límites. Un REVIEW.md independiente indica al revisor cómo es un fallo en un repositorio concreto. Los propietarios del código pueden identificar rutas sensibles y excluir las irrelevantes.
Cuando el revisor señala repetidamente un error, el equipo puede trasladar la lección a etapas anteriores. Puede añadir una regla de linting, mejorar un archivo de instrucciones, modificar una habilidad o crear una nueva comprobación automatizada. La retroalimentación de la revisión se convierte entonces en infraestructura reutilizable.
Los fallos anteriores se convierten en casos de evaluación. Anthropic afirma que recopiló pull requests asociadas con incidentes, reversiones y correcciones posteriores. Los ingenieros verificaron los errores subyacentes, y el revisor ahora se ejecuta diariamente contra ese conjunto.
Esto supone una desviación significativa de la revisión como una reunión entre dos personas. El sistema intenta conservar las lecciones en comprobaciones ejecutables en vez de depender de la memoria individual. Cada incidente puede ampliar la cobertura futura de detección de la organización.
Sin embargo, la revisión humana sigue gestionando cuestiones que no pueden reducirse a la corrección local. Los ingenieros deciden si una función debe existir, si una abstracción establece un precedente perjudicial y si la evidencia respalda el despliegue.
También inspeccionan áreas sensibles, como la facturación, los mecanismos de actualización, la integración continua y los flujos de lanzamiento. Estos cambios pueden tener un amplio radio de impacto incluso cuando su código parece correcto a nivel local.
Por tanto, el proceso no declara que las máquinas sean mejores revisoras en todas las dimensiones. Asigna a las máquinas el trabajo de lectura que pueden realizar repetidamente, mientras asigna a las personas las decisiones relacionadas con el propósito, la arquitectura, la incertidumbre y la responsabilidad.
Esa división también transforma las habilidades de ingeniería. Los ingenieros deben especificar la intención, identificar restricciones, diseñar verificaciones, interpretar evidencias y reconocer cuándo un agente optimizó el objetivo equivocado. Leer código sigue siendo útil, pero ya no es la única vía para comprender.
El equipo Scion de Anthropic ofreció un ejemplo relacionado. Los ingenieros informaron que Claude a veces perseguía diseños ineficientes o excesivamente defensivos que se ajustaban a patrones locales. Las personas tuvieron que rechazar esas direcciones porque comprendían las compensaciones a nivel de sistema.
La expresión “humano en el circuito” puede ocultar esta función. Una persona que simplemente aprueba la salida de una máquina es una salvaguarda débil. Una persona que define límites, elige la evidencia y sabe cuándo detener la automatización aporta un control significativo.
Para otras organizaciones, la lección no es eliminar a los revisores. Es distinguir la inspección mecánica del juicio. La cobertura automatizada se vuelve valiosa cuando las personas conservan la autoridad sobre decisiones de grandes consecuencias y evidencias ambiguas.
Cómo las revisiones de Claude Code evitan bucles interminables de agentes
Anthropic descubrió que los autores de IA y los revisores de IA pueden crear trabajo ilimitado a menos que el proceso de revisión esté diseñado explícitamente para converger.
Más revisión no es automáticamente mejor. Anthropic describe una solicitud de extracción de Claude Code que pasó por más de 50 rondas de revisión y corrección durante la noche. El autor acabó deteniendo el bucle.
El revisor no estaba descubriendo un nuevo defecto crítico en cada pasada. Anthropic utilizó el historial de versiones para examinar los hallazgos repetidos y descubrió que aproximadamente el 59% se refería a código presente durante la primera revisión.
El agente seguía localizando problemas antiguos adicionales en vez de evaluar solo la corrección nueva. Cada comentario provocaba otra corrección, confirmación y revisión. El sistema permanecía activo sin avanzar eficientemente hacia un estado final aceptable.
Este fallo ilustra un riesgo distintivo de la revisión de código con IA. Una persona puede descartar una sugerencia de poco valor en segundos. Un agente autor tiende a actuar sobre ella, produciendo otro diff que da al agente revisor más material.
Anthropic respondió con controles de convergencia. Tras tres rondas, el revisor pide al autor que reconsidere el enfoque. Las pasadas posteriores se centran en el nuevo diff en lugar de buscar repetidamente en todo el cambio.
El revisor también informa de una clase completa de defectos relacionados de una sola vez. Eso permite al autor corregir cada caso en vez de recibir comentarios similares en rondas consecutivas. Los hallazgos publicados previamente no deberían volver a aparecer.
Anthropic afirma que estos cambios mejoraron su ciclo interno de revisión. La proporción de solicitudes de extracción aprobadas tras una ronda de revisión y corrección habría aumentado del 65% al 78%.
Las solicitudes de extracción que requerían cinco o más rondas habrían descendido del 8,9% al 1,5%. La media de revisiones antes de aprobarse bajó de 2,08 a 1,32. Estas métricas siguen siendo reportadas por la empresa, pero abordan un problema operativo que muchos flujos de trabajo con agentes pasan por alto.
La convergencia importa porque el trabajo automatizado no es gratuito solo por no tener salario. Cada ronda adicional consume capacidad del modelo, retrasa el cambio, crea más código y aumenta el material que las comprobaciones posteriores deben inspeccionar.
El mismo problema aparece cuando los revisores reaccionan de forma exagerada ante amenazas hipotéticas. Anthropic afirma que la revisión adversarial puede volverse miope, fomentando validaciones o complejidad excesivas. Un sistema optimizado para descubrir posibles fallos puede generar nuevos costes de mantenimiento.
La profundidad basada en riesgos ofrece un control. El servicio de Code Review de Anthropic, disponible de forma general, admite distintos niveles de revisión para repositorios rutinarios y críticos. La empresa afirma que la mayoría de las revisiones ahora terminan en seis a diez minutos.
Sin embargo, un revisor más rápido no resuelve la cuestión subyacente de gobernanza. Los equipos aún deben decidir qué hallazgos importan, qué rutas merecen una inspección más profunda y cuántos ciclos son aceptables.
Las instrucciones de revisión también pueden convertirse en una capa de políticas oculta. Si CLAUDE.md, REVIEW.md o las indicaciones de clasificación contienen supuestos débiles, los agentes pueden aplicarlos de forma consistente en todo el repositorio.
La coherencia ayuda solo cuando la regla es correcta. Los equipos necesitan propiedad, control de versiones, casos de evaluación y revisión para las instrucciones que guían a sus revisores. De lo contrario, la automatización puede escalar una política equivocada más rápido de lo que las personas lo advierten.
Aquí es donde el contexto compartido de ingeniería adquiere importancia. Las organizaciones que adoptan agentes necesitan registros duraderos de decisiones arquitectónicas, lecciones de incidentes y enfoques descartados. Una base de conocimiento de ingeniería con capacidad de búsqueda puede ayudar a preservar ese contexto más allá de un único hilo de revisión.
El proceso de Anthropic funciona porque trata al revisor como un sistema que necesita medición. Realiza seguimiento de la precisión, el ruido, las rondas, los incidentes y las respuestas de los desarrolladores. Instalar un revisor de IA sin esos bucles de retroalimentación copiaría la herramienta visible, pero perdería el modelo operativo.
Lo que los resultados de Anthropic aún no demuestran
Las afirmaciones más sólidas siguen siendo autoinformadas, y Anthropic no ha demostrado que sus resultados se transfieran a equipos con infraestructura, presupuestos o tolerancia al fallo distintos.
La primera incertidumbre se refiere a la medición. Anthropic informó que las solicitudes de extracción fusionadas se más que duplicaron y que la proporción de reversiones cayó más de un 40%. No publicó el conjunto de datos subyacente, las tasas absolutas ni la distribución de gravedad de los incidentes.
Una proporción decreciente de reversiones puede ser alentadora y aun así ocultar resultados importantes. Los equipos pueden corregir hacia adelante en vez de revertir, desactivar una bandera de funcionalidad o tolerar una regresión que nunca recibe esa etiqueta. Las reversiones son útiles, pero incompletas.
Las tasas de incidentes aportan otra salvaguarda, pero la publicación pública no ofrece una serie detallada de incidentes. Sin datos de gravedad y exposición, los observadores externos no pueden determinar si el proceso redujo el riesgo o cambió la forma en que se gestionaban los fallos.
La cifra del 90% de autoría conlleva una ambigüedad similar. No especifica si la medición cuenta líneas generadas, líneas aceptadas, confirmaciones u otra unidad. Tampoco revela cuánto prompting, edición e iteración humana precedieron al código final.
El entorno de Anthropic es inusualmente favorable para este método. La empresa controla los modelos, puede dedicar un cómputo sustancial a revisores paralelos y desarrolla infraestructura interna en torno a cargas de trabajo generadas por agentes.
Sus empleados también usan Claude Code internamente antes de los lanzamientos públicos. Las nuevas funciones pueden avanzar por un despliegue interno, un canal de últimas versiones y luego un canal estable. Las banderas de funcionalidad permiten al equipo desactivar comportamientos sin realizar un despliegue completo.
Los equipos que operan sistemas médicos, financieros, industriales o críticos para la seguridad pueden afrontar requisitos diferentes. Una reversión rápida no puede deshacer todas las consecuencias. Una migración de datos defectuosa, un cambio de autorización o una acción externa pueden producir daños irreversibles.
Anthropic reconoce que las fusiones defectuosas aún dependen de autores, ingenieros de guardia, telemetría y paneles para su detección. Todavía no cuenta con interruptores automáticos que aumenten los requisitos de aprobación cuando suben las reversiones o los incidentes.
Esa brecha importa porque la clasificación del riesgo puede quedar obsoleta. Un cambio etiquetado como de bajo riesgo puede interactuar con dependencias ocultas. Una serie de cambios individualmente seguros también puede producir un estado combinado peligroso.
La seguridad introduce otra preocupación. Anthropic utiliza revisión de seguridad automatizada, pero sus propios materiales de riesgo muestran por qué sigue siendo necesaria la supervisión humana. Su evaluación de sabotaje describe la monitorización de modelos como un control en evolución, no como una garantía completa.
La reacción de la comunidad ha planteado preguntas más amplias sobre el coste y la comprensión. Algunos desarrolladores sostienen que Anthropic puede mantener patrones de revisión que resultarían antieconómicos en otros lugares. Otros temen que menos personas leyendo diffs debiliten el conocimiento colectivo de la base de código.
Anthropic declara abiertamente que nadie en el equipo de Claude Code mantiene un modelo mental completo del producto. En su lugar, los ingenieros piden a Claude que explique el subsistema pertinente cuando lo necesitan.
Ese enfoque puede mantener las explicaciones actualizadas, pero crea una dependencia. Si la explicación generada omite una interacción, el ingeniero puede tomar una decisión usando un mapa incompleto. La misma familia de modelos también puede repetir supuestos integrados en el código que revisa.
La revisión entre modelos podría aportar diversidad adicional, pero no mejora automáticamente la precisión. Sistemas diferentes pueden compartir patrones de entrenamiento o fallar por motivos no relacionados. La propiedad importante es la evidencia independiente, no simplemente un nombre de modelo distinto.
Ninguna de estas cuestiones invalida los resultados informados por Anthropic. Limitan lo que esos resultados establecen. La empresa ha mostrado un proceso interno detallado con métricas direccionales alentadoras, no un sustituto universal de la revisión humana de código.
Tres señales pondrán a prueba si el modelo se sostiene
La próxima prueba será si Anthropic puede preservar la calidad a medida que se amplían las fusiones sin intervención humana, los productos de revisión llegan a otras empresas y los competidores adoptan controles distintos.
La primera señal es la propia política de aprobación de Anthropic. Su proceso actual permite que cambios seleccionados de bajo riesgo se fusionen sin un revisor humano independiente después de que superen las comprobaciones automatizadas.
Observe si ese límite se amplía a más código de producto. Si Anthropic añade los interruptores automáticos que sus ingenieros desean, la escalada automática podría hacer más creíble un despliegue más amplio. El aumento de incidentes o un regreso a aprobaciones más estrictas debilitarían el caso.
La segunda señal es la evidencia de organizaciones externas que utilizan revisión automatizada. Anthropic ha lanzado Code Review para clientes Team y Enterprise, creando una prueba más amplia en repositorios y culturas de ingeniería desconocidos.
Las métricas útiles no serán el número de comentarios ni de solicitudes de extracción revisadas. Los equipos deberían informar de hallazgos aceptados, defectos que se escaparon, falsos positivos, latencia de revisión, esfuerzo humano e incidentes de producción.
Resultados comparables fuera de Anthropic reforzarían la afirmación de que la revisión de IA en capas puede escalar. Un ruido elevado, un uso creciente de modelos o tasas de incidentes sin cambios sugerirían que el éxito de Anthropic depende de su entorno interno.
La tercera señal es la respuesta competitiva. OpenAI, GitHub, Google, Cursor y otros proveedores de agentes de programación afrontan el mismo desequilibrio entre el código generado y la capacidad de los revisores.
Sus decisiones revelarán si la revisión basada en riesgos se convierte en un patrón compartido. Los sistemas competidores pueden favorecer la revisión entre modelos, un sandboxing más sólido, la verificación formal, la evaluación específica del repositorio o una aprobación humana más persistente.
Los desarrolladores deberían resistirse a reducir este debate a si la IA puede encontrar errores. La cuestión práctica es si un sistema completo de revisión puede asignar atención, preservar la responsabilidad y recuperarse de forma segura cuando todas las capas pasan algo por alto.
Para los líderes de ingeniería, la acción inmediata es medir. Establezca una línea de base del tiempo de revisión, los defectos escapados, los falsos positivos, las tasas de reversión y la gravedad de los incidentes antes de cambiar la política de aprobación. Sin esa línea de base, fusionar más rápido puede parecer una mejora mientras desplaza los costes a otros lugares.
Los equipos también deberían separar los cambios reversibles de los irreversibles. La documentación, los ajustes de interfaz señalados y las herramientas internas no requieren el mismo proceso que la autenticación, la facturación, las migraciones o la infraestructura de lanzamiento.
La revisión de Anthropic Claude Code ofrece una respuesta concreta a un problema al que muchos equipos pronto se enfrentarán. Trata la revisión como un sistema de control por capas, no como la prueba de que una persona leyó cada línea.
Las cifras reportadas por la empresa hacen que valga la pena poner a prueba esa respuesta, no copiarla a ciegas. Si mañana sus agentes duplicaran la producción de código, ¿qué evidencia permitiría a sus revisores dejar de leerlo todo con seguridad hoy?
