El Senior Engineer está muerto. Larga vida al Experto Generalista

Hace unos meses tuvimos una caída en producción que afectaba a la preparación de pedidos en tiendas. El sistema de stock no actualizaba correctamente y los preparadores estaban trabajando con datos desactualizados. Cada minuto contaba (hablamos de tiendas físicas, gente real esperando producto en el lineal).

Teníamos a dos ingenieros disponibles para atacar el problema. Uno era un crack absoluto en el framework que usábamos. Conocía cada quirk, cada configuración, cada edge case de la herramienta. El otro no dominaba ese framework en particular, pero entendía cómo funcionaba el sistema de stock de punta a punta: la arquitectura de eventos, las dependencias con otros servicios, el modelo de consistencia, y (esto es clave) por qué el sistema estaba diseñado así para el negocio.

¿Quién crees que encontró el problema?

El segundo. En menos de una hora. Porque el problema no estaba en el framework. Estaba en una race condition entre dos servicios que el primero ni siquiera sabía que existían.

Esa experiencia me confirmó algo que llevo tiempo observando en los más de 100 ingenieros que he mentorizado: el ingeniero que solo sabe mucho de su stack tiene un techo. Y con la llegada de la IA, ese techo es cada vez más bajo.

El senior engineer atrapado en su burbuja

¿Te suena este perfil? Un ingeniero con años de experiencia, que domina su tecnología como nadie, que puede resolver cualquier problema técnico dentro de su dominio... pero que no sabe explicar por qué su sistema existe. Que no tiene ni idea de qué métricas de negocio mueve su código. Que cuando le preguntas "¿y esto qué impacto tiene?" te contesta con detalles de implementación.

Yo lo veo constantemente. Gestiono 7 equipos que dan servicio a más de 25.000 pedidos diarios y más de 1.600 tiendas. Y el patrón se repite: los ingenieros más valiosos no son los que más saben de una tecnología. Son los que entienden el contexto completo.

El problema con la profundidad técnica sin amplitud es que tiene rendimientos decrecientes. Pasar de "bueno" a "muy bueno" en un framework concreto requiere un esfuerzo enorme. Pasar de "muy bueno" a "experto mundial" requiere años. Y cuando llegas ahí... el framework puede haber cambiado, o directamente haber muerto.

Los datos lo confirman. Erik Bernhardsson analizó más de 26 proyectos open-source y calculó que la vida media del código es de 3.33 años. En frontend, Angular tiene una vida media de 0.32 años. Estás invirtiendo miles de horas en dominar algo que tiene la esperanza de vida de un yogur.

No digo que la profundidad técnica no importe. Claro que importa. Pero apostar todo tu valor profesional a ella es una estrategia cada vez más arriesgada.

Qué es un experto generalista (y qué no es)

Cuando digo "generalista", mucha gente piensa en el típico jack of all trades, master of none. El que sabe un poco de todo pero no domina nada. Ese perfil no es lo que propongo.

Un experto generalista es algo muy diferente. Es un ingeniero que tiene profundidad real (puede diseñar sistemas, debuggear problemas complejos, tomar decisiones arquitectónicas con criterio) pero que además entiende el terreno que rodea al código.

En mi experiencia, estos ingenieros comparten cuatro rasgos:

Entienden el "para qué" antes que el "cómo". Cuando les llega un requisito, su primera pregunta no es "¿qué framework uso?" sino "¿qué problema de negocio estamos resolviendo?". Esto les permite cuestionar soluciones, proponer alternativas, y a veces matar features antes de que se escriba una línea de código. Eso es influencia real.

Navegan la incertidumbre sin paralizarse. Pueden entrar en un sistema que no conocen, hacer las preguntas correctas, y en poco tiempo identificar los puntos de apalancamiento. No necesitan dominar la tecnología para entender la arquitectura. No necesitan conocer el negocio al detalle para identificar dónde está el riesgo.

Conectan puntos que otros no ven. Cuando gestionas 7 equipos, ves un patrón recurrente: los problemas más costosos casi nunca son de un solo equipo. Son problemas entre equipos, entre sistemas, entre dominios. El experto generalista los ve venir porque tiene visión periférica. El especialista puro no, porque solo mira su parte.

Comunican decisiones técnicas en lenguaje de negocio. Esta es quizá la habilidad más infravalorada. Un ingeniero que puede explicar a un Product Manager por qué una decisión técnica va a afectar al time-to-market o al coste operativo tiene un poder que ningún framework te da. Es lo que yo llamo pasar de "ejecutor de tickets" a "partner estratégico".

La IA como acelerador de esta evolución

La IA no ha creado la necesidad del experto generalista. Pero la ha acelerado brutalmente.

Piénsalo así: si la IA commoditiza la escritura de código (y los datos dicen que ya genera el 41% del código en muchas empresas) entonces el valor del ingeniero ya no está principalmente en escribir. Está en decidir qué escribir, por qué, y cómo encaja en el sistema.

Hay un concepto económico que explica esto muy bien: la Paradoja de Jevons. En 1865, cuando las máquinas de vapor se hicieron más eficientes, el consumo de carbón no bajó. Subió. Porque la eficiencia desbloqueó nuevos usos que antes no eran viables. Con la IA está pasando exactamente lo mismo. El coste de los tokens ha caído 10x, pero el uso ha subido 100x. Se genera más código que nunca. Y alguien tiene que entender todo ese código, validarlo, integrarlo, y asegurarse de que resuelve el problema correcto.

Ese "alguien" no es un prompt engineer. Es un ingeniero con criterio. Un experto generalista.

Lo vivo cada día. Cuando un equipo usa IA para generar código, los problemas que aparecen rara vez son de sintaxis. Son de contexto: el código no entiende la restricción de negocio, no respeta el contrato con otro servicio, no contempla el caso de fallo que solo conoces si entiendes la arquitectura. Los datos lo respaldan (el 48% del código generado por IA tiene riesgo alto de vulnerabilidades de seguridad). La IA genera el código, pero el criterio lo pones tú.

Como digo siempre: el código es un medio, no un fin. Y la IA ha hecho que esto sea más verdad que nunca.

Cómo se construye un experto generalista

No voy a darte una lista genérica de "aprende system design y lee Clean Code". Eso ya lo sabes. Lo que quiero compartir es lo que he visto que realmente funciona, después de mentorizar a más de 100 ingenieros y de vivirlo yo mismo gestionando sistemas a escala en retail.

Involúcrate en decisiones que no son "tuyas". La próxima vez que producto esté decidiendo el roadmap, pide estar en la conversación. No para opinar sobre prioridades de negocio, sino para aportar contexto técnico que cambie la decisión. Cuando lo haces un par de veces y tu input genera impacto, dejas de ser "el de implementación" y pasas a ser alguien a quien se consulta. Eso es influencia, no jerarquía.

Cuando resuelvas un problema técnico, pregúntate qué problema de negocio acabas de resolver. Suena simple. Casi nadie lo hace. "Optimicé la query de stock" no es lo mismo que "reduje el tiempo de preparación en tienda un 15%, lo que permite servir 200 pedidos más al día". El segundo habla el idioma de la gente que decide presupuestos y prioridades.

Aprende a leer sistemas, no solo código. La próxima vez que te asignen a un proyecto nuevo, antes de abrir el IDE, dibuja el sistema. ¿Qué servicios hablan entre sí? ¿Dónde está el estado? ¿Cuáles son los puntos de fallo? ¿Qué pasa si este componente cae? Este hábito te da superpoderes porque empiezas a ver problemas antes de que existan.

Busca los problemas entre equipos. Los bugs más caros, las caídas más gordas, los proyectos que se retrasan meses (casi siempre ocurren en las interfaces entre sistemas y entre equipos). Si te conviertes en la persona que entiende esas fronteras, tu valor se multiplica porque estás resolviendo problemas que nadie más puede ver.

El techo invisible

Vuelvo a la historia del principio. Aquel día en producción, con las tiendas afectadas y el reloj corriendo, no necesitábamos un experto en un framework. Necesitábamos a alguien que entendiera el sistema. El negocio. Las dependencias. El contexto.

Eso es un experto generalista. Y eso es exactamente lo que la IA no va a reemplazar. Porque la IA puede generar código, pero no puede entender por qué ese sistema existe, a quién sirve, y qué pasa cuando falla un viernes a las 20:00 con 1.600 tiendas abiertas.

El senior engineer clásico (el que apuesta todo a la profundidad técnica en un stack) tiene un techo invisible. Y ese techo baja un poco cada día que la IA mejora.

La buena noticia es que la transición a experto generalista no requiere empezar de cero. Requiere ampliar la mirada. Dejar de pensar solo en cómo implementar y empezar a pensar en por qué implementar, para quién, y qué impacto tiene.

El código es un medio, no un fin. Y los ingenieros que entiendan esto son los que van a liderar la próxima década.

---

Este artículo surge de una reflexión inspirada por el artículo de Milan Milanovic sobre fundamentals vs frameworks, donde toca el concepto de Expert Generalist. Quise ir más allá y aterrizarlo desde mi experiencia gestionando equipos y sistemas a escala.