https://orcid.org/0000-0003-3314-8768
Una mirada crítica a la ingeniería agéntica, sus límites matemáticos, la evidencia experimental y las oportunidades de investigación desde Puno, Perú.
Introducción
Durante décadas, quienes nos dedicamos a la ingeniería de sistemas hemos aprendido que desarrollar software implica identificar problemas, comprender requerimientos, diseñar arquitecturas, implementar algoritmos, verificar resultados y mantener sistemas que evolucionan con las necesidades de las organizaciones.
Este proceso ha cambiado con el tiempo: desde los modelos tradicionales de desarrollo hasta las metodologías ágiles, las arquitecturas distribuidas y la computación en la nube. Sin embargo, la aparición de la inteligencia artificial generativa y, en particular, de los agentes basados en grandes modelos de lenguaje, está introduciendo una transformación que merece un examen riguroso.
Ya no hablamos solamente de herramientas que completan líneas de código, sino de sistemas capaces de interpretar objetivos, organizar actividades, utilizar herramientas, generar programas, ejecutar pruebas y revisar resultados.
En este contexto, revisé el artículo de Zhenfeng Cao (2026), cuya primera versión se tituló The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm. Su tesis resulta provocadora: la ingeniería de software estaría llegando al final del paradigma que la sostuvo durante más de medio siglo. La segunda versión, titulada Agentic Software: How AI Agents Are Restructuring the Software Paradigm, emplea una formulación más moderada.
Mi posición es que la ingeniería de software no está desapareciendo: está atravesando una transformación estructural que exige ampliar sus fundamentos, sus métodos de evaluación y sus responsabilidades profesionales.
En este artículo distingo las afirmaciones de Cao, los resultados de otras investigaciones y mis propias propuestas conceptuales. Se trata de una revisión crítica y una agenda de investigación, no de un estudio experimental original.
1. Del software tradicional a los sistemas agénticos
La ingeniería de software tradicional se ha construido sobre la creación y evolución de reglas, estructuras de datos, algoritmos y componentes. Con los agentes de inteligencia artificial, parte de las decisiones operativas puede tomarse en tiempo de ejecución mediante un modelo que interpreta objetivos, consulta información, utiliza herramientas y adapta acciones.
Imaginemos una institución universitaria que necesita analizar factores asociados al rendimiento académico. En un enfoque convencional podríamos desarrollar módulos de extracción de datos, transformación, modelamiento estadístico y visualización. En un enfoque agéntico, uno o varios agentes podrían coordinar parte de esas tareas a partir de objetivos y restricciones definidos por especialistas.
Sin embargo, esta posibilidad no elimina la necesidad de requisitos, arquitectura, seguridad, calidad de datos ni validación estadística. Modifica la distribución de actividades entre humanos y sistemas computacionales. Los trabajos de Wang et al. (2025) y Yao et al. (2023) ayudan a comprender las funciones de percepción, memoria, acción y utilización de herramientas en esta transición.
2. ¿Realmente estamos ante el fin de la ingeniería de software?
La pregunta parece asumir que la esencia de nuestra profesión consiste en escribir código. Considero que esa premisa es incorrecta. La ingeniería de software incluye especificación, diseño, construcción, pruebas, mantenimiento, gestión del riesgo y aseguramiento de calidad.
La llegada de lenguajes de alto nivel, frameworks, servicios en la nube y herramientas de automatización no eliminó la disciplina. Elevó los niveles de abstracción y transformó las competencias profesionales. La aparición de agentes introduce un cambio más profundo, porque automatiza también determinadas decisiones del proceso.
Pero automatizar actividades no equivale a eliminar la necesidad de gobernarlas. Una universidad puede utilizar agentes para desarrollar un sistema de matrícula, aunque seguirá necesitando garantizar integridad de registros, privacidad, disponibilidad y cumplimiento normativo.
Por ello, resulta más defendible hablar de una ingeniería de software asistida, coordinada y parcialmente ejecutada por agentes que de su desaparición.
3. Evidencia experimental: avances, límites y desafíos
Benchmarks como SWE-bench han permitido medir la capacidad de los modelos para resolver incidencias reales de repositorios públicos (Jimenez et al., 2024). Sin embargo, una puntuación elevada no demuestra automáticamente capacidad de despliegue seguro o mantenimiento sostenido. Durante 2026 se publicaron cuestionamientos metodológicos a SWE-bench Verified, incluidos problemas de contaminación y de adecuación de las pruebas (OpenAI, 2026; Epoch AI, 2026).
Es necesario distinguir entre resolver una incidencia aislada, integrar una modificación y mantener un sistema durante múltiples iteraciones.
En EvoClaw, difundido posteriormente como SWE-Milestone, Deng et al. (2026) analizaron el comportamiento de modelos y marcos agénticos en secuencias de desarrollo. Los resultados expusieron dificultades para conservar el contexto, evitar la propagación de errores y prevenir regresiones. Estas cifras pertenecen a condiciones específicas del estudio; no deben interpretarse como tasas universales de rendimiento.
También se han comunicado mejoras notables de coordinación multiagente en experiencias empresariales, como las presentadas por Kumar y Ramagopal (2026). Sin embargo, los pilotos de proveedores requieren contrastación independiente antes de formular conclusiones generalizables.
Resolver correctamente una tarea no equivale a garantizar el funcionamiento de un sistema durante meses o años. La autonomía operativa no es sinónimo de confiabilidad sostenida.
4. Una corrección matemática necesaria
La primera versión de Cao plantea que la complejidad de las interacciones entre componentes sigue una expresión de la forma:
Pero el razonamiento que acompaña esa expresión considera las posibles relaciones entre pares de componentes. Si tenemos n componentes, el máximo número de pares no ordenados es:
Si cada par puede estar conectado o no, el número de grafos simples no dirigidos etiquetados posibles es:
Esta función no es asintóticamente equivalente a 2n. Además, contar configuraciones posibles de dependencias no es lo mismo que contar caminos de interacción, ni demuestra por sí solo que el coste real de desarrollar software tenga el mismo orden de crecimiento.
| Componentes (n) | 2n | 2n(n−1)/2 |
|---|---|---|
| 3 | 8 | 8 |
| 4 | 16 | 64 |
| 5 | 32 | 1.024 |
| 6 | 64 | 32.768 |
| 10 | 1.024 | 34.359.738.368 |
Para sostener rigurosamente una afirmación sobre costes exponenciales de mantenimiento sería necesario definir una función de esfuerzo, supuestos sobre dependencias y evidencia que conecte el modelo con observaciones reales. Tampoco es suficiente representar la capacidad humana como una constante y asumir que los modelos agénticos aumentarán su desempeño sin restricciones.
5. Mi propuesta: hacia una ingeniería agéntica verificable
Considero necesario avanzar hacia una ingeniería agéntica verificable: una línea de investigación que combine autonomía computacional, evaluación sistemática y gobernanza. El término se utiliza aquí como propuesta conceptual que requiere validación, no como una disciplina experimentalmente establecida.
Propongo representar un sistema agéntico de forma ampliada:
- L: modelo de lenguaje o motor de decisión.
- T: herramientas, APIs y servicios.
- M: memoria y recuperación de contexto.
- P: planificación y coordinación.
- V: verificación de resultados.
- G: gobernanza, seguridad y límites de actuación.
En términos de optimización, una política de actuación π podría evaluarse mediante la siguiente función objetivo conceptual:
Donde Q es calidad, C coste, R riesgo y λ y μ ponderaciones de las prioridades institucionales. Para una evaluación experimental deberán definirse escalas comparables, reglas de medición y restricciones explícitas.
La utilidad de este planteamiento consiste en evitar que la autonomía se mida solo por la cantidad de tareas completadas. Un sistema que produce resultados rápidos, pero inseguros o difíciles de mantener, puede no ser superior. La importancia de incorporar controles de riesgo también se encuentra en los enfoques de gestión propuestos por NIST (2024) e ISO/IEC 42001:2023.
6. ¿Cómo investigar científicamente la ingeniería agéntica?
Propongo comparar tres enfoques bajo tareas, repositorios y criterios de aceptación equivalentes:
- Desarrollo convencional: los ingenieros realizan análisis, diseño, implementación, pruebas y mantenimiento con herramientas tradicionales.
- Desarrollo asistido por IA: los ingenieros conservan la dirección principal y utilizan modelos generativos como apoyo.
- Desarrollo agéntico supervisado: los agentes ejecutan tareas con mecanismos de trazabilidad, verificación y autorización humana.
| Dimensión | Indicador verificable |
|---|---|
| Efectividad | Porcentaje de tareas aceptadas por pruebas independientes. |
| Productividad | Tiempo por tarea aceptada. |
| Calidad | Defectos por unidad funcional entregada. |
| Mantenibilidad | Regresiones y cambios correctivos en iteraciones sucesivas. |
| Coste | Coste total por tarea validada. |
| Seguridad | Incidentes o violaciones de restricciones por ejecución. |
| Autonomía | Proporción de tareas completadas sin intervención humana. |
| Confiabilidad | Éxito acumulado durante secuencias de cambios. |
Un estudio riguroso tendría que controlar dificultad, experiencia de los participantes, familia de modelos, infraestructura y criterios de evaluación; además, reportar variabilidad e intervalos de confianza.
Hipótesis propuesta: los sistemas agénticos supervisados pueden mejorar la productividad del desarrollo de software, pero el efecto dependerá de la complejidad de las tareas, los mecanismos de verificación y la preservación del contexto a lo largo del tiempo.
Esta hipótesis aún no constituye una conclusión experimental propia.
7. El desafío de las universidades
Como docente universitario considero que esta transformación obliga a revisar nuestras prácticas formativas. Los conocimientos de algoritmos, estructuras de datos, arquitectura, bases de datos, sistemas distribuidos y seguridad siguen siendo esenciales.
Un estudiante capaz de generar programas mediante un modelo, pero incapaz de explicar su complejidad, identificar fallos o verificar su corrección, no dispone de una formación suficiente en ingeniería.
Debemos enseñar a construir y auditar sistemas agénticos, sin reemplazar el pensamiento computacional por la dependencia de respuestas automáticas. En la Universidad Nacional del Altiplano y otras instituciones del país podemos impulsar laboratorios donde se comparen soluciones convencionales, asistidas y agénticas con protocolos reproducibles.
El objetivo debe ser formar profesionales que sepan decidir qué automatizar, cómo verificarlo y cuándo una decisión requiere necesariamente intervención humana.
8. Oportunidades de investigación aplicada desde Puno
Puno no debe limitarse a observar esta transformación. Podemos estudiar aplicaciones pertinentes para nuestras instituciones y sectores productivos:
- Educación: agentes de apoyo a la evaluación formativa y la gestión académica, con supervisión docente.
- Empresas: automatización de análisis comercial, procesos administrativos y reportes para pequeñas organizaciones.
- Gestión pública: revisión documental y seguimiento de procedimientos, sin reemplazar la responsabilidad de los funcionarios.
- Ambiente: coordinación de análisis geoespacial, imágenes satelitales y generación de reportes técnicos verificables.
Son oportunidades de investigación, no soluciones ya certificadas para operar sin supervisión. Precisamente por ello, requieren datos locales, restricciones claras y evaluación empírica. El reto consiste en producir conocimiento replicable y tecnología útil para nuestro contexto.
9. El modelo económico: del software como servicio al resultado como servicio
La propuesta de Agent as a Service (AaaS) desplaza la atención desde el acceso a funcionalidades hacia la entrega de resultados. Esto abre posibilidades de cobrar por incidencias resueltas, procesos completados o servicios efectivamente prestados.
Pero los resultados de negocio no siempre pueden atribuirse directamente a un agente: intervienen decisiones humanas, condiciones de mercado y factores externos. Además, existen costes de inferencia, herramientas, almacenamiento, validación, supervisión y recuperación de errores.
En consecuencia, cualquier comparación económica debería medir el beneficio neto, el coste total de propiedad y los riesgos asumidos, y no únicamente la velocidad aparente de ejecución.
10. Reflexión final: el ingeniero del futuro no debe renunciar a comprender
Después de examinar las propuestas de Cao y contrastarlas con las investigaciones recientes, considero que estamos ante una transformación profunda del desarrollo de software. Sin embargo, persiste una diferencia importante entre generar código, entregar una funcionalidad y mantener un sistema confiable durante años.
Esta distancia no se resolverá solamente con modelos más grandes o con mayor cantidad de agentes. Necesitamos arquitectura, verificación, gestión de memoria, seguridad, observabilidad, investigación experimental y responsabilidad profesional.
El ingeniero del futuro deberá formular problemas con precisión, diseñar sistemas, interpretar evidencia y responder por las decisiones técnicas. La rapidez de implementación será valiosa, pero no podrá sustituir la comprensión.
No estamos ante el fin de la ingeniería de software. Estamos ante el inicio de una etapa en la que producir código dejará de ser suficiente para demostrar competencia profesional.
La verdadera diferencia estará en quién comprende el problema, quién demuestra la calidad de la solución y quién asume la responsabilidad de su funcionamiento. Desde Puno, Perú, considero que debemos participar activamente en esta transformación mediante formación, investigación y desarrollo tecnológico con resultados verificables.
Referencias bibliográficas
- Autio, C., et al. (2024). Artificial intelligence risk management framework: Generative artificial intelligence profile (NIST AI 600-1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.600-1
- Cao, Z. (2026). The end of software engineering: How AI agents are fundamentally restructuring the software paradigm (versión 1). arXiv. https://arxiv.org/abs/2606.05608v1
- Cao, Z. (2026). Agentic software: How AI agents are restructuring the software paradigm (versión 2). arXiv. https://arxiv.org/abs/2606.05608v2
- Deng, G., et al. (2026). EvoClaw: Evaluating AI agents on continuous software evolution [Prepublicación, posteriormente difundida como SWE-Milestone]. arXiv. https://arxiv.org/abs/2603.13428
- Epoch AI. (2026). SWE-bench Verified: Benchmark review. https://epoch.ai/benchmarks/swe-bench-verified/review
- International Organization for Standardization & International Electrotechnical Commission. (2023). Information technology — Artificial intelligence — Management system (ISO/IEC 42001:2023). https://www.iso.org/standard/42001
- Jimenez, C. E., et al. (2024). SWE-bench: Can language models resolve real-world GitHub issues? International Conference on Learning Representations. https://openreview.net/forum?id=VTF8yNQM66
- Kumar, R., & Ramagopal, P. (2026). Agentic engineering: How swarms of AI agents are redefining software engineering. LangChain. Artículo de LangChain
- OpenAI. (2026). Why we no longer evaluate SWE-bench Verified. Artículo y auditoría
- Wang, Y., et al. (2025). Agents in software engineering: Survey, landscape, and vision. Automated Software Engineering, 32, artículo 70. https://doi.org/10.1007/s10515-025-00544-2
- Yao, S., et al. (2023). ReAct: Synergizing reasoning and acting in language models. International Conference on Learning Representations. https://arxiv.org/abs/2210.03629
Ver el perfil de Aldo Hernán Zanabria Gálvez