La reescritura de código con IA de Cisco sitúa un objetivo del 98% tras tokens ilimitados
Según se informa, Cisco otorgó a un ingeniero de 27 años tokens de IA ilimitados para intentar reescribir el 98% de su código heredado en un plazo de 24 meses. La reescritura de código con IA de Cisco combina un objetivo inusualmente amplio con un pequeño equipo propuesto. Su relevancia depende de qué pretende cambiar Cisco y de cómo establecerá que los cambios funcionan.
Según Tom’s Hardware, que recoge información de Fortune, el presidente y director de producto Jeetu Patel respaldó al exfundador de startup Padmanabhan Krishnamurthy tras una conversación en San Francisco. El encargo supuestamente incluye un período inicial de prueba de cuatro semanas. Estos detalles describen un experimento y una ambición, más que resultados de modernización verificados de forma independiente.
La tensión central es la generación de código sin restricciones frente a una entrega de software responsable. Amazon ya ha descrito actualizaciones de aplicaciones asistidas por IA, lo que ofrece una comparación útil. La ambición atribuida a Cisco plantea una pregunta más amplia: ¿cuánta responsabilidad organizativa puede asumir un pequeño equipo de ingeniería cuando generar cambios resulta más fácil?
La reescritura de código con IA de Cisco comienza con un objetivo, no con una migración terminada
El encargo informado establece respaldo ejecutivo; no demuestra que Cisco haya modernizado su software.
El relato de Tom’s Hardware sobre el encargo de código heredado identifica a Krishnamurthy, conocido como Paddy, como el ingeniero detrás de la propuesta. Según se informa, propuso un equipo de dos personas. Patel brindó el respaldo, incluidos tokens sin restricciones, las unidades de texto que los modelos de IA procesan al recibir instrucciones y generar respuestas.
El informe afirma que Krishnamurthy trabajó anteriormente cinco niveles organizativos por debajo de Patel. Su relato presenta el proyecto como un cambio de responsabilidad tanto como de herramientas. Un exfundador recibiría margen para cuestionar supuestos de ingeniería establecidos.
Existe un historial de adquisición verificable de forma independiente detrás de esa conexión. El aviso de adquisición de EzDubs de Cisco indica que la transacción se cerró el 25 de noviembre de 2025. Cisco describió EzDubs como una empresa de software de IA especializada en traducción de voz en tiempo real. Su justificación declarada incluía ampliar el talento de ingeniería para colaboración.
Ese historial respalda la versión de una startup adquirida que se incorpora a Cisco. No valida de forma independiente la propuesta de reescritura ni su viabilidad. El anuncio de adquisición se refiere a capacidades de colaboración, no a un plan publicado para transformar el software heredado de Cisco.
La redacción del encargo informado también exige cautela. La refactorización implica cambiar la estructura interna del software manteniendo su comportamiento observable externamente. La reescritura puede implicar sustituir una implementación, introduciendo potencialmente decisiones de diseño y riesgos de compatibilidad distintos.
Estos términos pueden describir trabajos que se solapan, pero no son medidas intercambiables de progreso. Una limpieza interna automatizada difiere de forma sustancial de sustituir un componente del que dependen los clientes. Un programa de modernización debe identificar a qué categoría pertenece cada cambio.
La información pública no proporciona un inventario detallado que respalde la cifra del 98%. Tampoco explica si la finalización significa cambios generados, cambios aceptados, despliegue en producción o retirada de implementaciones antiguas. Sin esas definiciones, el porcentaje comunica mejor la ambición que el alcance operativo.
La misma cautela se aplica al calendario. La información publicada el 30 de octubre de 2026 no establece que el reloj del proyecto comenzara ese día. Los lectores deberían evitar calcular una fecha exacta de finalización únicamente a partir de la fecha de publicación.
Por tanto, el punto de partida útil es limitado. Según se informa, el presidente de Cisco autorizó un experimento de ingeniería agresivo con un objetivo destacado definido. Que ese experimento se convierta en un programa de modernización repetible sigue siendo una cuestión aparte.
Los tokens ilimitados desplazan la presión hacia la revisión y la responsabilidad
Eliminar un límite de generación cambia dónde se acumula el trabajo de ingeniería; no elimina el trabajo necesario para aceptar un cambio.
Los tokens de IA ilimitados parecen capacidad de ingeniería ilimitada porque el resultado visible es código. Sin embargo, un parche generado, un cambio propuesto en archivos fuente, todavía necesita una razón de ser. Alguien debe establecer qué cambia, por qué es seguro y quién lo mantendrá.
Consideremos una modernización hipotética de un componente de autenticación compartido. Una herramienta de IA podría sugerir código más claro, dependencias más recientes y pruebas adicionales. Esa propuesta aún necesitaría evaluarse frente a las reglas de permisos existentes y las configuraciones de clientes compatibles.
Este ejemplo es ilustrativo, no una descripción del proyecto de Cisco. Muestra por qué generar software plausible y aceptar la responsabilidad por el comportamiento desplegado son actividades distintas. Una redacción más rápida puede revelar una escasez de revisores en lugar de eliminar una escasez de programadores.
Los responsables de ingeniería enfrentan la presión inmediata. Si los cambios propuestos llegan más rápido de lo que los equipos pueden evaluarlos, la cola de revisión crece. Los responsables deben decidir entonces si reducen el alcance del trabajo, aumentan la capacidad de revisión o cambian cómo se adjuntan pruebas a cada propuesta.
Los especialistas en seguridad enfrentan un problema relacionado. Deben comprender si el proceso preserva los límites de acceso y trata adecuadamente la información sensible. Un parche que parece más limpio puede aun así cambiar supuestos que antes se aplicaban de forma indirecta.
Los responsables de producto deben distinguir las mejoras internas de los cambios que afectan a los clientes. Sustituir una dependencia, un componente de software externo, puede introducir comportamientos más allá de los archivos que una herramienta de IA edita directamente. Por ello, la aceptación depende del sistema circundante, no simplemente del atractivo de la sustitución.
El patrocinio ejecutivo importa porque estas responsabilidades cruzan líneas jerárquicas. Un pequeño equipo central puede desarrollar un enfoque, pero los equipos afectados siguen necesitando una forma de aprobar cambios. Una autoridad poco clara convertiría cada demostración exitosa en una negociación sobre quién acepta las consecuencias.
Esta es la relevancia organizativa de las ambiciones de reescritura de código con IA de Cisco. El experimento pone a prueba si un equipo pequeño puede crear un proceso en el que otros equipos confíen. Su resultado tendría que incluir evidencia reproducible, límites de cambio comprensibles y vías claras para gestionar fallos.
Los mantenedores establecidos siguen siendo fundamentales para ese proceso. A menudo saben por qué existe una implementación incómoda o qué requisito del cliente explica una rama inusual. Ese conocimiento es evidencia útil, incluso cuando sugiere que la implementación actual debería cambiar.
La documentación se convierte en parte de la cuestión sobre capacidad de ingeniería. Los equipos necesitan acceso a decisiones de diseño, historiales de incidentes y requisitos de compatibilidad antes de evaluar una sustitución propuesta. Una base de conocimiento de ingeniería con capacidad de búsqueda aborda ese problema de información junto con el flujo de trabajo de programación.
La presión resultante recae en ambos lados del experimento. El pequeño equipo debe hacer que su trabajo sea revisable, mientras que los equipos establecidos deben explicar concretamente sus objeciones. Ni la generación sin restricciones ni la experiencia institucional ofrecen una respuesta automática.
Las actualizaciones de aplicaciones de Amazon ofrecen una comparación más acotada
Una migración delimitada proporciona evidencia más clara que un porcentaje que cubre un patrimonio de software indefinido.
Amazon ofrece un precedente industrial para la modernización asistida por IA. En su anuncio de transformación de aplicaciones de diciembre de 2024, la empresa describió la actualización de aplicaciones internas a Java 17. Java es un lenguaje de programación y entorno de ejecución utilizado para software empresarial.
Amazon afirmó que el esfuerzo abarcó decenas de miles de aplicaciones de producción y ahorró más de 4.500 años-persona de trabajo de desarrolladores. Se trata de resultados comunicados por la empresa, no de una evaluación independiente. No obstante, describen una transformación más específica que una promesa general de reescribir código heredado.
Esa especificidad importa. Una actualización de versión ofrece un estado inicial y un estado objetivo identificables. Los revisores pueden examinar si una aplicación se compila, si el comportamiento esperado se mantiene intacto y si el nuevo entorno de ejecución satisface sus requisitos.
Una reescritura más amplia puede combinar muchos objetivos diferentes. Podría implicar simplificar la arquitectura, sustituir dependencias, mejorar la mantenibilidad o eliminar funcionalidades obsoletas. Cada objetivo requiere sus propios criterios de aceptación, incluso cuando las mismas herramientas de IA ayudan a producir los cambios.
El flujo de trabajo de actualización de Java de AWS también conserva un paso explícito de aceptación humana. Su documentación describe compilar el código original, realizar una transformación y pedir al desarrollador que verifique y acepte los resultados. Distingue los cambios de compatibilidad del lenguaje de las actualizaciones adicionales de dependencias.
Esta distinción es útil porque la modernización rara vez es una operación única. Una actualización exitosa del lenguaje no demuestra que todas las bibliotecas estén al día. Una compilación exitosa no demuestra que todos los flujos de trabajo de clientes funcionen correctamente.
Por tanto, el ejemplo de Amazon respalda una conclusión limitada: la transformación asistida por IA tiene aplicaciones empresariales concretas con límites descriptibles. No demuestra que el objetivo atribuido a Cisco sea alcanzable. Tampoco muestra que un equipo de implementación minúsculo pueda realizar de forma independiente todas las tareas de aceptación asociadas.
También hay una lección de medición. El tiempo estimado de desarrolladores ahorrado depende de un proceso alternativo supuesto. Esa estimación se vuelve más informativa cuando se acompaña de aplicaciones desplegadas, cambios aceptados y rendimiento operativo continuo.
El experimento de Cisco se beneficiaría de informes igualmente concretos. Una descripción de la carga de trabajo inicial revelaría si el equipo está probando una transformación repetible o explorando un rediseño más amplio. Ambos pueden ser valiosos, pero conllevan incertidumbres diferentes.
Para los compradores empresariales, esa distinción afecta a cómo interpretar las afirmaciones de los proveedores. Una demostración interna es evidencia sobre un proceso concreto en un entorno concreto. Una capacidad compatible para clientes exige compromisos adicionales respecto al mantenimiento, la documentación y la gestión de fallos.
La presión competitiva se refiere tanto a la evidencia como a la velocidad. Las empresas que hablan de modernización con IA necesitan explicar cada vez más qué se transformó y cómo funcionó la aceptación. Un porcentaje destacado y llamativo proporciona menos información útil que un resultado claramente delimitado.
La comparación también mantiene la historia de Cisco anclada a la realidad. Su relevancia procede de poner a prueba si un patrocinio ejecutivo agresivo puede ampliar el alcance de la ingeniería asistida por IA. La experiencia de Amazon aporta contexto sin resolver de antemano ese experimento.
La cifra del 98% necesita una definición antes de convertirse en una métrica útil
Un porcentaje de modernización solo adquiere significado cuando los lectores saben qué se contabiliza para completarlo.
Un porcentaje necesita un denominador: la cantidad total frente a la cual se mide el progreso. Para esta iniciativa, esa cantidad podría ser líneas de código fuente, repositorios, aplicaciones o componentes seleccionados. La información publicada no establece qué interpretación se aplica.
Estas opciones pueden producir imágenes muy distintas del progreso. Reformatear archivos puede afectar muchas líneas de código fuente sin cambiar la facilidad de mantenimiento. Sustituir un componente pequeño pero central puede requerir una validación exhaustiva y, aun así, afectar relativamente poco código.
La regla de finalización importa tanto como la métrica. Generar un cambio propuesto es un paso intermedio. Aceptarlo en el repositorio de código fuente es otro paso, mientras que desplegarlo y retirar la implementación anterior requiere trabajo adicional.
Esto no hace que la ambición del 98% sea inherentemente irrazonable. Hace que sea difícil de evaluar a partir de la descripción pública. Los lectores necesitan definiciones de alcance y aceptación antes de interpretarla como una previsión de ingeniería.
El lenguaje de la refactorización plantea otro desafío de medición. Preservar el comportamiento es fundamental en la refactorización, pero las pruebas existentes solo examinan el comportamiento que cubren. Una ejecución exitosa de las pruebas no puede establecer que todas las condiciones no probadas permanezcan sin cambios.
Esa brecha explica por qué la revisión y la observación operativa son importantes. Una regresión, una pérdida involuntaria de comportamiento existente, puede aparecer fuera de los escenarios representados en las pruebas automatizadas. La confianza surge de combinar evidencias, en lugar de tratar cualquier verificación individual como concluyente.
La investigación también advierte contra equiparar la sensación de rapidez con la productividad medida. El experimento de productividad de desarrolladores de METR examinó a 16 desarrolladores experimentados que completaron 246 tareas en proyectos de código abierto que conocían bien. Permitir el uso de herramientas de IA de principios de 2025 aumentó el tiempo de finalización en un 19%.
Sin embargo, los participantes creían que las herramientas les habían ayudado a terminar más rápido. El hallazgo ilustra por qué la conveniencia percibida y la velocidad de entrega medida requieren evaluaciones separadas. No predice los resultados de Cisco ni establece que las herramientas de IA posteriores tengan las mismas limitaciones.
Posteriormente, METR subrayó esa distinción. Su actualización sobre el diseño del experimento de febrero de 2026 describió las dificultades para interpretar mediciones más recientes porque habían cambiado la participación y la selección de tareas. Los investigadores consideraron plausible una mayor velocidad, aunque advirtieron que la evidencia disponible no permitía establecer con precisión la mejora.
En conjunto, estos hallazgos respaldan una medición cuidadosa, en lugar de un veredicto universal sobre la programación con IA. Las capacidades de las herramientas cambian, y distintas tareas exponen restricciones diferentes. Los resultados de mantenimiento de código abierto conocido no pueden trasladarse sin más a un programa de modernización de una gran empresa.
Para Cisco, la pregunta relevante es si mejora el proceso completo. Una generación más rápida tendría un valor limitado si la revisión y la corrección consumieran el tiempo ahorrado. A la inversa, un proceso fiable podría aportar valor incluso si deliberadamente dejara intacta una parte considerable del código.
Por tanto, una evaluación creíble distinguiría la actividad de los resultados. Los parches propuestos muestran actividad; las transformaciones aceptadas demuestran progreso tras la revisión. Un despliegue estable y una menor carga de mantenimiento ofrecen evidencias más sólidas de que el trabajo logró su propósito.
Los tokens ilimitados eliminan una posible restricción a la experimentación. No resuelven estas cuestiones de medición. El objetivo informado se vuelve más esclarecedor cuando Cisco explica cómo distinguirá una demostración impresionante de una mejora sostenida de ingeniería.
Un equipo pequeño sigue necesitando acceso al conocimiento institucional
La versión más sólida de este experimento combina libertad para rediseñar con acceso a las razones por las que el software existente se comporta como lo hace.
La historia de la dotación de personal invita a una interpretación generacional sencilla. Un fundador joven cuestiona supuestos que una gran organización ha aceptado. Ese encuadre refleja el cambio de oportunidad informado, pero no puede establecer qué juicios de ingeniería son correctos.
La juventud no produce automáticamente una arquitectura sólida, del mismo modo que la antigüedad no justifica automáticamente conservar una implementación. La distinción útil es si una propuesta resiste el examen. Un equipo pequeño necesita suficiente libertad para probar ideas y suficiente contexto para interpretar los resultados.
Los antecedentes de Krishnamurthy como fundador, según lo informado, son relevantes para esa cuestión organizativa. La experiencia en startups puede fomentar la atención al problema completo, en lugar de a una tarea asignada de forma limitada. Aun así, no sustituye la comprensión de los sistemas afectados por un cambio.
El conocimiento institucional puede explicar ineficiencias aparentes. Una secuencia de reintentos inusual podría adaptarse a una condición operativa concreta. Una comprobación redundante podría proteger una integración antigua. Estos son ejemplos hipotéticos, no características identificadas del software de Cisco.
Siempre que sea posible, estas explicaciones deberían convertirse en requisitos verificables. De lo contrario, la modernización depende de localizar a la persona que recuerda una decisión antigua. Capturar la razón permite que una nueva implementación preserve el comportamiento necesario mientras cuestiona el diseño original.
La obligación inversa también importa. Los equipos establecidos deberían distinguir los requisitos documentados de los hábitos que han perdurado sin examen. Una objeción se vuelve accionable cuando identifica una condición de fallo o un criterio de aceptación.
Aquí es donde el respaldo ejecutivo puede ayudar sin sustituir el juicio de ingeniería. El liderazgo puede autorizar el acceso, resolver disputas de propiedad y proteger tiempo para la evaluación. No puede establecer la corrección mediante entusiasmo ni hacer que una fecha límite sustituya a la evidencia.
Por tanto, la contribución más valiosa de un equipo pequeño podría ser un proceso repetible, en vez de una gran cantidad de código de sustitución. Ese proceso conectaría las transformaciones propuestas con requisitos pertinentes y una ruta clara de aprobación. Otros equipos podrían entonces evaluar trabajos similares sin reconstruir el procedimiento.
Esta posibilidad cambia cómo interpretar el nivel de personal propuesto. Un equipo compacto podría desarrollar métodos de transformación y coordinar su adopción. Eso difiere de afirmar que esas personas por sí solas pueden asumir toda responsabilidad de pruebas, seguridad, soporte y mantenimiento.
También limita lo que la historia dice sobre el empleo de nivel inicial. Otorgar responsabilidad inusual a un fundador adquirido no establece un patrón general de contratación. El caso ofrece evidencia sobre una decisión de gestión concreta, en lugar de un resultado del mercado laboral.
Para los desarrolladores, la implicación práctica se refiere al trabajo que rodea al código generado. Comprender requisitos, explicar compensaciones y establecer evidencias sigue siendo necesario cuando redactar se vuelve más fácil. Estas responsabilidades se hacen más visibles cuando un proyecto intenta cambios a través de límites organizativos.
Para los trabajadores del conocimiento en general, el paralelo es el acceso al contexto. Un sistema de IA puede producir una respuesta plausible sin captar la razón por la que una decisión anterior importaba. La automatización útil necesita una forma de recuperar esa razón y mostrar la incertidumbre.
Por tanto, el experimento de Cisco también es una prueba de aprendizaje organizativo. Sus perspectivas mejoran si un equipo pequeño puede convertir conocimiento disperso en evidencias de aceptación reutilizables. Se debilitan si el proyecto trata a los mantenedores experimentados únicamente como obstáculos para una producción más rápida.
Observe las evidencias del piloto, la aceptación en producción y la carga de mantenimiento
La próxima actualización útil explicaría qué superó la evaluación, quién lo aceptó y qué ocurrió después.
La reescritura de código con IA de Cisco será más fácil de evaluar mediante evidencias concretas en los próximos meses. El periodo de prueba de cuatro semanas informado proporciona a los lectores un punto de referencia a corto plazo. Sin embargo, la información no establece su fecha exacta de inicio ni promete una publicación pública.
La primera señal es una descripción del alcance y los resultados del piloto. Los lectores deberían buscar una carga de trabajo identificable, un objetivo de transformación declarado y criterios de aceptación. Esos detalles mostrarían si el equipo probó algo representativo de la ambición más amplia.
Una demostración exitosa reforzaría el caso si expusiera tanto los logros como las limitaciones. Por ejemplo, informar qué cambios requirieron corrección humana ayudaría a establecer las exigencias reales del proceso. Este es un estándar de evidencia, no una predicción sobre lo que Cisco divulgará.
Una demostración que muestre únicamente código recién generado aportaría un respaldo más débil. Demostraría producción sin explicar compatibilidad ni aceptación. La diferencia importa porque el objetivo a largo plazo consiste en modificar software existente, en lugar de producir un ejemplo independiente.
La segunda señal es la aceptación en un proceso de entrega de producción. Los lectores deberían buscar confirmación de que los equipos responsables aprobaron una transformación delimitada y la desplegaron. Un procedimiento de reversión, una forma definida de restaurar una versión anterior, aclararía aún más cómo gestiona el programa los fallos.
Esta señal reforzaría el caso de modernización porque conecta el experimento con responsabilidades operativas. Mostraría que los equipos afectados pueden evaluar el trabajo, en lugar de limitarse a admirarlo. La aprobación aún tendría que interpretarse dentro del alcance de ese despliegue.
Por el contrario, demostraciones repetidas sin despliegue dejarían sin resolver una cuestión central. El proceso podría generar propuestas útiles mientras tiene dificultades para satisfacer los requisitos de aceptación. Ese resultado identificaría una restricción de entrega, en vez de demostrar que toda transformación carece de valor.
La tercera señal es la carga de mantenimiento tras el despliegue. Los lectores deberían buscar evidencia sobre correcciones posteriores, demandas de soporte y si la implementación anterior puede retirarse. Estos resultados revelan si la modernización reduce trabajo o simplemente lo traslada a otra parte.
Un cambio que se mantenga estable y simplifique el mantenimiento futuro respaldaría la premisa del proyecto. Un cambio que requiera una intervención recurrente extensa la debilitaría. Ninguna conclusión debería basarse únicamente en la rapidez con la que apareció la primera sustitución.
Estas señales también proporcionan un marco mejor para los compradores empresariales que evalúan afirmaciones sobre modernización con IA. Pidan a los proveedores que separen los cambios propuestos de los cambios desplegados, y los cambios desplegados de las mejoras duraderas. Soliciten suficiente detalle para comprender qué cargas de trabajo produjeron el resultado informado.
Para los líderes de ingeniería, la acción inmediata es examinar un problema de mantenimiento delimitado en su propia organización. Establezcan el estándar de aceptación existente, identifiquen a las personas que entienden sus restricciones y midan el recorrido completo hasta el despliegue. Comparen el esfuerzo de revisión y corrección junto con la velocidad de generación. Registren los supuestos que limitarían repetir el resultado en otro contexto. La reescritura de código con IA de Cisco merece atención porque pone a prueba hasta dónde pueden extender la modernización del software el respaldo ejecutivo y la experimentación sin restricciones. Su importancia final dependerá de qué siga siendo fiable después de la emoción inicial. Cuando llegue la próxima actualización, planteen una pregunta concreta: ¿qué cambio aceptado facilitó el mantenimiento del software y qué evidencia respalda ese juicio?
