Según la última versión del SWEBOK, existen 18 Áreas de Conocimiento en Ingeniería de Software (KAs).
Aunque no todas están directamente relacionadas con el aspecto técnico de la ingeniería de software, el número de áreas técnicas no es inferior a 12. Analicémoslas:
- Requisitos de software: gestión de requisitos para definir el comportamiento y las restricciones de los sistemas de software.
- Arquitectura de software: estructuración de alto nivel de los sistemas de software y sus interacciones.
- Diseño de software: definición de componentes, interfaces y otras características necesarias para implementar una solución.
- Construcción de software: creación de software funcional.
- Pruebas de software: ejecución del software para asegurar que cumple con los requisitos especificados e identificar defectos.
- Operaciones de Ingeniería de Software: despliegue del software en su entorno operativo y provisión de servicios para mantenerlo en funcionamiento.
- Mantenimiento de software: modificación del software existente para corregir fallas, mejorar el rendimiento o adaptarlo a un entorno cambiante tras su entrega.
- Gestión de la configuración de software: gestiona los cambios en los artefactos de software.
- Calidad de software: asegura que un producto cumpla con los requisitos especificados y satisface las necesidades del cliente mediante prácticas de aseguramiento de la calidad.
- Seguridad de software: protección de los sistemas de información contra accesos no autorizados.
- Fundamentos de computación: conceptos esenciales para comprender contextos más amplios.
- Fundamentos matemáticos: principios que subyacen a los aspectos técnicos de las tareas de análisis y de verificación de modelos.
Quizás el número 12 sea un poco forzado y no aplique al trabajo diario de todos, pero, sin duda, está lo suficientemente cerca de lo que hacemos todos los días como para incluirlo aquí.
Gran información para trivias… pero ¿por qué es importante?
Bueno… no voy a dar rodeos, así que iré directo al punto:
¿Los ingenieros de software de todo el mundo están quejándose en Internet de que una de las 12 áreas de la ingeniería de software podría automatizarse por completo pronto?
¡Simplemente DEJEN DE LLORAR y SIGAN ADELANTE!
Es momento de sostener mi postura.
Vamos paso a paso. Para ello, analizaré el impacto de la IA en cada una de las 12 áreas de la ingeniería de software mencionadas. Daré una puntuación de “reemplazabilidad”, donde:
- 10/10 = el trabajo en esa área puede realizarse de principio a fin con herramientas de IA la mayor parte del tiempo, con mínima intervención humana (los humanos podrían “aprobar”, pero no toman muchas decisiones).
- 0/10 = la IA es principalmente una ayuda, pero los humanos siguen realizando el razonamiento central, los compromisos, la responsabilidad y la coordinación que hacen que el trabajo sea “real”.
1) Requisitos de Software - 4/10
La IA será muy útil para transformar notas desordenadas en artefactos claros: historias de usuario, criterios de aceptación, PRDs, casos de uso, listas de casos límite, incluso borradores de copy de UI y diagramas de flujo. Puede detectar inconsistencias (“dijiste X pero también Y”), proponer preguntas aclaratorias y mantener la trazabilidad entre documentos y tickets (básicamente actuando como un asistente incansable para el análisis de requisitos).
Pero el núcleo duro de los requisitos es la alineación humana bajo restricciones: stakeholders en conflicto, compromisos políticos, incentivos ocultos, la realidad presupuestaria y la decisión de qué significa “éxito” cuando nadie está completamente de acuerdo. Además, aquí viven silenciosamente la responsabilidad legal y la ética. La IA puede redactar, pero no puede hacerse cargo de las consecuencias de “hacemos esto” vs “no hacemos esto”, ni tiene acceso privilegiado al contexto real que las personas llevan en la cabeza (o eligen no compartirlo).
2) Arquitectura de Software - 3/10
La IA puede proponer arquitecturas rápidamente: “usar un enfoque event-driven”, “dividir en estos servicios”, “elegir Postgres + Redis”, “aquí hay un diagrama de referencia”, “aplicar CQRS”, etc. También es excelente enumerar trade-offs, listar posibles fallas, sugerir patrones de observabilidad y generar documentación que los humanos suelen no tener tiempo de escribir.
Pero la arquitectura trata menos de conocer patrones y más de elegir qué dolor vas a aceptar: latencia vs. consistencia, costo vs. redundancia, velocidad de entrega vs. corrección, autonomía vs. gobernanza. Esas decisiones dependen de la volatilidad del roadmap, la madurez del equipo, la capacidad operativa, las restricciones regulatorias y la tolerancia de la organización a las fallas. La IA sugiere; los humanos deciden y viven con las consecuencias meses después.
3) Diseño de Software - 6/10
El diseño está más cerca de la implementación que de la arquitectura, por lo que resulta más automatizable. La IA puede generar límites de módulos, modelos de clases, formas de API, esquemas de bases de datos, máquinas de estado, contratos de interfaz e incluso proponer refactorizaciones hacia abstracciones más limpias. Si le das restricciones claras (“necesitamos endpoints idempotentes”, “soportar modo offline”, “evitar breaking changes”), puede producir muy buenos primeros borradores.
Pero el diseño aún contiene muchos “requisitos silenciosos”: mantenibilidad, patrones de cambio futuro, ergonomía, cómo falla el sistema y la diferencia entre “técnicamente correcto” y “agradable de trabajar durante años”. La IA tiende a optimizar para la elegancia local y los patrones que ya ha visto; los humanos deben optimizar para el desorden evolutivo de este producto en particular.
4) Construcción de Software - 10/10 (mi punto de referencia)
Aquí estoy asumiendo la versión más fuerte de mi premisa (según la cual la IA “reemplaza” a los ingenieros en construcción). La generación de código, la refactorización, la traducción entre lenguajes, el scaffolding de servicios, la implementación de funcionalidades bien especificadas y la conexión de integraciones son tareas en las que los inputs y outputs pueden representarse como texto + tests + resultados de build. Ese es un terreno ideal para la IA.
Aun así, el matiz es importante: la construcción nunca consiste únicamente en escribir código. Incluye microdecisiones, interpretación de la ambigüedad y depuración en entornos reales. Pero si tuviera que elegir una sola área como “10”, sería construcción, porque es la más legible para la automatización y la más fácil de evaluar mecánicamente (¿compila?, ¿pasan los tests?, ¿pasa el lint?, ¿los benchmarks cumplen los objetivos?, etc.).
5) Pruebas de Software - 7/10
El testing es sorprendentemente automatizable porque gran parte sigue patrones: generar tests unitarios a partir de paths de código, fuzzear inputs, construir suites de regresión a partir de reportes de bugs, crear mocks, proponer casos límite y ejecutar grandes matrices de configuraciones. La IA también es buena leyendo fallos y proponiendo causas probables (“esto es un problema de timing inestable”, “mismatch de mock”, “edge case off-by-one”), lo que reduce el “tiempo humano por fallo”.
Pero hay dos cosas que resisten la automatización total. Primero, el problema del oráculo: saber cuál debería ser el comportamiento correcto cuando los requisitos son incompletos o contradictorios. Segundo, la priorización bajo riesgo: qué testear, qué no, dónde una falla es catastrófica y cuándo los tests en verde están dando falsa confianza. La IA puede generar montañas de tests; los humanos deben diseñar una estrategia que demuestre algo significativo en lugar de generar una ilusión reconfortante.
6) Operaciones - 7/10
Operaciones tiene mucha superficie automatizable: pipelines de despliegue, autorrecuperación ante fallas conocidas, detección de anomalías, resumen de logs y trazas, líneas de tiempo de incidentes, ejecución de runbooks, proyección de capacidad y análisis de “qué cambió” entre configuraciones y releases. La IA actuará cada vez más como un asistente SRE, siempre activo, que triajea y sugiere acciones rápidamente.
Pero en las operaciones es donde el costo de los errores es inmediato. Una recuperación automática mal ejecutada puede tirar la producción más rápido que cualquier humano. Además, los incidentes suelen involucrar combinaciones novedosas de fallas: caídas parciales, problemas de terceros, timeouts en cascada, estados corruptos y decisiones humanas bajo incertidumbre (“¿hacemos rollback?”, “¿desactivamos feature flags?”, “¿avisamos a legal/compliance?”).
7) Mantenimiento de software - 7/10
El mantenimiento es un gran objetivo para la IA porque está lleno de trabajo repetitivo y demandante de tiempo: actualizaciones de dependencias, migraciones de API, refactorizaciones hacia nuevos patrones, pago de deuda técnica obvia, porting de código legacy, actualización de documentación y corrección de bugs comunes en clases. La IA puede leer una codebase y proponer cambios incrementales y seguros más rápido que la mayoría de los humanos, especialmente cuando está guiada por pruebas y análisis estáticos.
Pero la parte difícil del mantenimiento no es cambiar el código, sino no romper el negocio mientras lo cambias. Los sistemas legacy codifican reglas de negocio que quizá no existan en ningún otro lugar, y el “comportamiento correcto” muchas veces está definido por años de rarezas en producción. El mantenimiento requiere un contexto profundo, la gestión de riesgos y una planificación cuidadosa del rollout. La IA puede hacer gran parte de las ediciones, pero los humanos todavía necesitan decidir qué es seguro, qué vale la pena y cuál es el radio de impacto.
8) Gestión de configuración de software - 8/10
SCM tiene un perfil de automatización fuerte: flujos de control de versiones, gestión de ramas, resolución de conflictos de merge (especialmente los conflictos mecánicos), etiquetado de releases, changelogs automatizados, pinning de dependencias, chequeos de paridad entre entornos, enforcement de CI/CD, policy-as-code y auditoría. Muchas actividades de SCM ya son procesos estructurados con reglas claras, perfectos para herramientas.
Las cosas difíciles de reemplazar son la gobernanza y la intención: qué cambios están permitidos,quién los aprueba, cómo se evalúa el riesgo y cómo se manejan las excepciones cuando la realidad no coincide con la política. Además, la “configuración” en sistemas modernos incluye secretos, infraestructura, feature flags y permisos (donde los errores son caros). La IA puede ejecutar y recomendar, pero los humanos conservarán la propiedad de la política, las aprobaciones y la responsabilidad.
9) Calidad de software - 5/10
La IA puede ayudar muchísimo con las prácticas de calidad: definir checklists, hacer cumplir estándares, detectar code smells, identificar inconsistencias entre la documentación y el comportamiento, sugerir métricas y revisar continuamente artefactos (PRs, diseños, tests) en busca de patrones comunes de falla. También puede elevar la base al volver barata y constante la “buena higiene”.
Pero la “calidad” es, en última instancia, un juicio de valor ligado a los usuarios y a los resultados de negocio, no solo al conteo de defectos. Los humanos deciden qué significa calidad aquí: objetivos de rendimiento, expectativas de accesibilidad, SLOs de confiabilidad, tolerancias de UX y en qué puntos el equipo está dispuesto a aceptar imperfecciones antes del lanzamiento. La calidad también es cultural: cómo los equipos manejan el feedback, cómo responden a bugs y cómo intercambian velocidad por corrección. La IA puede potenciar sistemas sólidos, pero no puede crear disciplina por sí sola.
10) Seguridad de software - 5/10
La IA será extremadamente útil en seguridad: escaneo de código, análisis de riesgos de dependencias, detección de configuraciones erróneas, sugerencias de código seguro, generación de políticas e incluso implementación de implementaciones por defecto más seguras para auth, uso de cifrado y validación de inputs. También puede ayudar con el threat modeling listando rutas plausibles de ataque y casos comunes de abuso.
Pero la seguridad sigue siendo adversarial y contextual. Los atacantes inventan nuevas cadenas y los defensores deben entender las restricciones del mundo real: usabilidad, workflows de negocio, requisitos de compliance y respuesta a incidentes. El trabajo más difícil es la priorización y las decisiones a nivel de arquitectura (“¿en qué confiamos?”, “¿qué aislamos?”, “¿cómo hacemos key management?”). La IA puede detectar una enorme cantidad de problemas, pero los humanos todavía necesitan definir la postura de seguridad y tomar decisiones de riesgo que tienen consecuencias legales y reputacionales.
11) Fundamentos de la informática - 3/10
Si tratamos esta área como “el conocimiento fundamental de CS que los ingenieros aplican”, la IA reducirá significativamente la necesidad de memorizar detalles. Puedes preguntarle por opciones de algoritmos, trade-offs de complejidad, modelos de concurrencia, estrategias de indexación de bases de datos, comportamientos de lenguajes/runtimes y errores típicos. Eso la hace parecer “reemplazable” en el sentido de que el acceso al conocimiento se vuelve comoditizado.
Pero los fundamentos tienen menos que ver con recitar hechos y más con pensar con claridad cuando las cosas salen mal: diagnosticar colapsos de performance, entender modos de falla distribuidos, elegir la estructura de datos adecuada bajo restricciones y detectar cuándo un sistema está violando un principio fundamental. La IA puede aconsejar, pero los humanos que entienden los fundamentos pueden juzgar si el consejo aplica, detectar errores sutiles y razonar bajo incertidumbre, especialmente cuando el entorno es novedoso o las restricciones no son obvias.
12) Fundamentos matemáticos - 3/10
La IA puede descargar muchísimo trabajo de cálculo matemático: derivar fórmulas, verificar la lógica, realizar razonamiento estadístico, asistir en demostraciones y explicar conceptos como la probabilidad, la teoría de grafos o la verificación formal. Para muchos ingenieros que solo usan matemáticas de vez en cuando, esto se sentirá como un superpoder: obtienes “matemática bajo demanda” sin tener que reaprender todo desde cero.
Pero cuando la matemática importa, importa porque estás construyendo algo en el que pequeños errores de razonamiento se convierten en grandes errores en el mundo real: modelos de riesgo, evaluación de ML, decisiones cercanas a la criptografía, argumentos de consistencia distribuida, scheduling/optimización o pruebas de corrección. En esos casos, los humanos todavía necesitan comprender los supuestos, validar el razonamiento e interpretar los resultados con responsabilidad. La IA puede acelerar el trabajo, pero no quieres vivir en un mundo en el que nadie del equipo pueda hacer un sanity check de las matemáticas.
Palabras de cierre
Nuestro trabajo está siendo mejorado. Si la automatización devora viva la construcción de software, eso no te vuelve obsoleto; hace que “escribir código” deje de ser un rasgo de personalidad. El mundo no se está quedando sin problemas de software; se está quedando sin personas capaces de definir el problema correcto, diseñar una solución sensata y mantenerla viva en producción sin convertir cada incidente en mitología.
La IA no está reemplazando a los ingenieros; está reemplazando excusas. Se acabó esconderse detrás de “no tuve tiempo de escribir tests”, “no podemos documentar esto”, “después lo limpiamos”, “seguridad lo revisará”, “ops se encargará”. Cuando redactar, hacer scaffolding, generar tests, mantener la higiene de configuración y hacer triage básico se vuelven baratos, la vara sube. La profesión pasa de “yo puedo construir” a “puedo ser alguien enquiénn se puede confiar”. Y la confianza se construye en las áreas más difíciles de automatizar: claridad de requisitos, trade-offs de arquitectura, estrategia de testing con sentido, postura de seguridad, criterio operativo y mantenimiento seguro.
La IA te compra tiempo y el tiempo no es un beneficio; es un mandato. Puedes usarlo para producir más funcionalidades más rápido (y entregar más basura más rápido), o puedes usarlo para hacer el trabajo que realmente hace que los sistemas tengan éxito: hacer mejores preguntas, matar malas ideas temprano, diseñar para el cambio, verificar el comportamiento en vez de esperar que salga bien, modelar modos de falla, reducir el radio de impacto de incidentes y hacer que la seguridad y la calidad sean reales en lugar de ceremoniales.
Así que sí: dejen de llorar y sigan adelante. Sigan adelante y dejen de medir su valor en líneas de código. Sigan adelante y dejen de pensar que “ingeniería” significa “implementación”. Sigan adelante con las partes del oficio que no se comprimen en el autocompletado: criterio, trade-offs, responsabilidad y buen gusto.
Deja que la IA haga el trabajo mecánico; tú haz el trabajo que tiene consecuencias.