Mi apuesta sobre hacia dónde va la ingeniería de software. No es un análisis. Es una dirección.
Última actualización: Marzo 2026Llevo semanas intentando escribir este artículo. Lo he empezado tres veces y las tres lo he borrado porque sonaba a algo que ya había dicho.
Y tiene sentido. Llevo meses escribiendo sobre cómo la IA está cambiando la ingeniería de software. Sobre el código opaco que ya está en producción. Sobre las heurísticas que los seniors no saben explicar. Sobre por qué la verificación es el nuevo trabajo central. Sobre por qué esa verificación necesita infraestructura, no disciplina. Pero todo eso eran piezas sueltas. Diagnósticos. Soluciones concretas a problemas concretos.
Lo que no había escrito es lo que conecta todo eso. La pregunta de fondo: ¿hacia dónde va esta profesión? No mañana, no la semana que viene. Dentro de tres, cinco, diez años.
Esto es lo más cerca que tengo de una respuesta. No es un análisis. Es un manifiesto personal. Mi apuesta.
Lo conté brevemente en el artículo sobre verificación como infraestructura, pero quiero desarrollarlo porque fue el momento en el que algo hizo clic.
Un perfil no técnico de mi entorno usó IA para construir una herramienta funcional. No un prototipo. No una demo. Algo con tests, con una interfaz limpia, que hacía lo que tenía que hacer. Mi primera reacción fue asombro. La segunda fue un escalofrío: “¿y ahora qué?”
Porque ese software funcionaba. Pero yo no tenía forma de saber si debería llegar a producción sin aplicar un juicio que esa persona no tenía por qué tener. ¿Es consistente con las convenciones del proyecto? ¿Esa dependencia se comporta igual bajo carga real? ¿Encaja en el sistema más amplio?
El no-code llevaba años prometiendo esto. No lo consiguió porque te daba bloques limitados. La IA generativa lo está consiguiendo porque te da un colaborador que interpreta lo que quieres hacer. Y eso cambia todo.
No me voy a detener en argumentar si esto va a pasar o no. Ya lo hice. Va a pasar. Está pasando. La pregunta que me interesa ahora es otra: si aceptamos que cada vez más personas van a crear software sin formación técnica profunda, ¿qué construimos nosotros para que ese software sea software de verdad?
Cuando planteas esto en una conversación entre ingenieros, hay dos reacciones inmediatas.
La primera: “eso nunca va a funcionar, los no-técnicos no entienden los sistemas, van a crear un desastre.” Y tienen razón en parte. El software generado sin contexto puede ser un desastre. Pero la conclusión de “por lo tanto, que no lo hagan” es la misma que dijeron los que no querían que la gente usara frameworks, o plataformas cloud, o lenguajes de alto nivel. Cada vez que bajó la barrera de entrada, alguien dijo que era una mala idea. Y cada vez, la barrera bajó igualmente.
La segunda: “perfecto, entonces los ingenieros somos los guardianes de la calidad, los que revisamos y verificamos.” Y aquí es donde veo la trampa. Porque verificar es necesario (escribí una serie entera sobre ello), pero no es suficiente como visión de futuro. Verificar es reactivo. Alguien genera, tú compruebas. Estás detrás, no delante.
No quiero estar detrás.
Durante mucho tiempo usé la metáfora de la maratón para describir esta profesión. Nunca puedes parar de aprender, de actualizarte, de correr, porque si te detienes te quedas atrás. Y es verdad. Pero es una metáfora reactiva. Es supervivencia. Es responder a lo que viene.
Lo que propongo es otra postura: no corras la maratón, constrúyela. Diseña el siguiente tramo de carretera para que otros puedan recorrerlo. Ingenieros, no ingenieros, agentes, quien sea. Y cuando ese tramo esté estabilizado, sube un nivel y construye el siguiente.
¿Qué significa eso en concreto? Significa que el trabajo de ingeniería se mueve de escribir software a construir la infraestructura que permite a otros crear software de verdad. No solo verificar (eso es una pieza). Construir los sistemas, las plataformas, los guardarraíles, los contratos que hacen que el software generado por cualquiera sea operable, mantenible y coherente con su contexto.
Y alguien dirá: “eso es platform engineering, llevan años hablando de eso.” Sí y no. Platform engineering resuelve la parte de infraestructura técnica: pipelines, despliegues, entornos. Eso está bien, pero es solo una de las dimensiones. La que a mí me obsesiona es otra.
En mis últimos artículos he hablado de tres dimensiones de lo que hace que el software sea software de verdad: funcional (hace lo que debe), craft (está bien hecho), y contextual (encaja en este equipo, en esta empresa, en este momento).
Las dos primeras tienen caminos claros. La funcional se valida con tests. La de craft se fuerza con linters, templates, buenas plataformas. No es trivial, pero el problema está definido.
La contextual es la frontera. Y es donde creo que está el futuro de esta profesión.
Contexto es: este servicio tiene una dependencia que se degrada bajo carga y no aparece en ningún test. Contexto es: estamos migrando de esta arquitectura a esta otra, no inviertas aquí. Contexto es: el equipo que va a mantener esto tiene estas capacidades y no otras. Contexto es: este componente lo toca otro equipo y hay tensión sobre quién es el owner.
Hoy, todo eso vive en la cabeza de personas como yo. En conversaciones de pasillo. En la intuición de alguien que lleva años en el proyecto. Es conocimiento tácito, el que los seniors no saben explicar.
Mi apuesta es que el trabajo del ingeniero del futuro es convertir ese conocimiento tácito en infraestructura consumible. No solo por otros ingenieros (que es lo que ya hacemos con RFCs y principios de diseño), sino por agentes y por perfiles no técnicos que van a generar software sin tener ese contexto en la cabeza.
¿Es fácil? No. ¿Se puede hacer del todo? Te digo la verdad: no lo sé.
Y aquí es donde mi postura se separa de la mayoría de lo que leo.
La reacción natural ante la automatización es buscar el hueco que la máquina no pueda llenar. “La IA nunca podrá entender el contexto organizacional.” “La IA nunca podrá tener juicio.” Es reconfortante. También es una trampa.
No porque esté convencido de que la IA pueda hacer todo eso mañana. Sino porque buscar lo irremplazable es una postura defensiva. Es encontrar tu trinchera y quedarte ahí. Y las trincheras en tecnología tienen fecha de caducidad.
Mi propuesta es la contraria: en vez de buscar lo que la IA no puede hacer, ser quien construye la infraestructura que le permita hacerlo. Cada vez que consigues codificar una capa de juicio que antes era tácita (un principio de diseño, un contrato de verificación, un guardarraíl contextual), esa capa deja de depender de que alguien se acuerde. Se convierte en sistema. Y tú subes un nivel y atacas la siguiente capa de juicio que todavía no sabes cómo codificar.
Plumbline fue mi primer intento de hacer esto con la verificación. Pero la verificación es solo el principio. El contexto arquitectónico, el estratégico, el organizacional, todo eso necesita el mismo tratamiento: dejar de vivir en cabezas y empezar a vivir en infraestructura.
¿Tiene eso un techo? ¿Llegará un momento en el que hayamos abstraído tanto que ya no haga falta un ingeniero para construir la siguiente capa? Puede que sí. Puede que ese sea el final de la profesión tal como la conocemos. Sería deshonesto no reconocerlo.
Pero eso no cambia lo que toca hacer hoy.
Llevar contexto tácito a infraestructura explícita. Hacer que las decisiones que hoy viven en conversaciones de pasillo estén codificadas en sistemas que cualquiera pueda consumir. Construir los guardarraíles que permitan a más personas (y a más agentes) crear software que funcione, que esté bien hecho, y que encaje en su contexto.
No como una amenaza. Como la evolución natural de una profesión que siempre ha tratado de lo mismo: hacer accesible lo que antes era imposible.
Lo que cambia es para quién lo construyes. Antes, para otros ingenieros. Ahora, para cualquiera.
Esa es mi apuesta. Esa es la dirección en la que voy a invertir los próximos años. No sé hasta dónde llega. Pero sé que es la dirección correcta.
Y de eso no tengo ninguna duda.
¿Estás construyendo camino o corriéndolo?
No es una pregunta retórica. Me interesa de verdad saber cómo estás viendo esto desde tu equipo, desde tu empresa, desde tu posición. Porque creo que la respuesta va a ser muy diferente según el contexto de cada uno, y eso es precisamente lo que hace esto tan interesante.