Spoiler: somos un recurso
Quiero abrir un melón curioso y me gustaría leer opiniones al respecto.
Una parte de mí escribe esto por desahogo. Otra, porque llevo un tiempo observando un patrón que me gustaría que no existiese, pero, spoiler: existe.
El título lo dice todo.
Somos un recurso.
Cuando empecé hace unos años en el mundo de la informática corporativa (la de laburar, vaya) tuve la fortuna y la desgracia de hacer mis prácticas en Lean Mind.
Recuerdo sentarme sin saber lo que era una kata y, de repente, estar buscando patrones en un String con una expresión regular.
Recuerdo que uno de mis compañeros se sentó a mi lado y empezamos el pair:
—¿Qué harías para sacar el texto entre [] de un String?
Era una kata con un problema sencillo y terminamos diseñando, discutiendo y pensando mil formas de resolverla.
Me divertí como nunca.
No simplemente programando, sino pensando realmente en las soluciones, planteando todos los casos que se nos ocurrían y discutiendo diferentes maneras de atacar un mismo problema.
Hasta ese momento tenía claro que me gustaba la informática.
Lo que no sabía era cuánto me gustaba programar.
Y esa fue la fortuna.
La desgracia tardé un poco más en entenderla.
Lean Mind fue mi primera referencia de cómo era trabajar en desarrollo. El problema de tener una buena primera referencia es que corres el riesgo de pensar que eso es lo normal.
Luego sales fuera.
Y descubres que afuera hace frío.
Tiempo después recordé algo que había escuchado en una charla de otro compañero de Lean Mind cuando todavía estudiaba: la importancia de tener malos jefes para aprender a apreciar a los buenos.
En aquel momento me pareció una reflexión interesante. Después de empezar a trabajar, la entendí bastante mejor.
Haber pasado por un sitio donde a la gente le importaba realmente lo que construía fue una gran fortuna. También significó salir al mercado esperando encontrar lo mismo en todas partes.
Y no siempre es así.
Fuera también encuentras gente muy quemada, esperando el día en que la echen para dejar de lidiar con micromanagement, tiempos imposibles y prioridades que cambian cada semana.
Después de pasar por diferentes proyectos y organizaciones empiezas a reconocer ciertos patrones.
Autonomía hasta que algo sale mal
Hay uno del mundo corporativo que me resulta especialmente curioso.
Cuando todo va bien, muchos equipos viven en el limbo. No se lidera, no se gestiona y hay decisiones que nadie termina de tomar. Aun así, el equipo tira, resuelve los problemas y consigue que las cosas sigan funcionando.
Mientras funcione, a eso lo llamamos autonomía.
Ownership.
Self-managed teams.
El problema es que autonomía no significa dejar a un equipo a su suerte.
Un equipo autónomo necesita contexto, prioridades claras y alguien que tome las decisiones que no le corresponden al propio equipo. Si nadie hace eso, no tienes autonomía. Tienes un grupo de personas intentando sacar adelante un proyecto mientras adivina qué espera la organización de ellas.
Pero mientras las cosas salen, nadie parece demasiado preocupado.
Hasta que llega una deadline y el proyecto no llega.
Entonces aparecen los líderes.
De repente necesitamos reuniones, explicaciones, visibilidad, seguimiento y métricas. Personas que hasta ayer confiaban plenamente en el equipo empiezan a preguntar cómo hemos podido llegar hasta aquí.
Y, por supuesto, aparece el micromanagement.
Lo curioso es que muchas veces conseguimos pasar de un extremo al otro sin detenernos nunca en el medio. Primero confundimos autonomía con no gestionar nada y, cuando eso deja de funcionar, intentamos solucionarlo controlando cada movimiento.
En medio tienes al equipo preguntándose en qué momento pasamos de «vosotros sois los expertos» a tener que explicar qué hicimos ayer, qué estamos haciendo hoy y por qué algo que lleva meses bloqueado sigue bloqueado :).
Y muchas veces se consigue que todo el mundo se sienta responsable excepto quienes tenían precisamente la responsabilidad de gestionar el proyecto.
Cuando había que dirigir, éramos autónomos. Cuando hay que buscar responsables, somos recursos.
Y aquí es donde empiezan a conectarse las dos ideas.
Siempre fuimos recursos
Los profesionales de IT llevamos años siendo un recurso escaso.
Creo que eso nos permitió olvidar durante un tiempo una realidad bastante sencilla:
Siempre fuimos un recurso.
Durante años, cambiar frecuentemente de trabajo ha tenido cierto estigma. Da igual que hayas entrado en un infierno: aguanta. ¿Qué va a pensar la siguiente empresa si has cambiado otra vez? ¿Cómo vas a explicar que hayas durado solo un año?
Como si abandonar un entorno que no te aporta nada —o que incluso empieza a afectar a tu vida fuera del trabajo— fuese una especie de traición profesional.
Mientras tanto, las empresas hacen lo que tiene sentido para ellas.
Y está bien.
Son empresas.
Si mañana una división deja de ser rentable, un proyecto desaparece o mantener una plantilla deja de tener sentido para el negocio, alguien hará números y tomará una decisión.
El problema quizá estaba en que nosotros pensábamos que la relación era otra.
Durante mucho tiempo fuimos un recurso caro, sí. Pero, sobre todo, éramos un recurso escaso.
Ahora seguimos siendo caros, pero empezamos a parecer menos escasos y, para algunas empresas, bastante más prescindibles.
Y sí: la IA llegó para quedarse.
¿Y ahora qué?
No sé a dónde llegará el mundo de la informática con esta revolución.
Al menos desde donde yo lo veo, el mercado está más cerrado y es más selectivo que hace unos años. No sé cuánto de eso podemos atribuir realmente a la IA, cuánto al contexto económico y cuánto a la corrección de un mercado que durante años contrató como si fuese a crecer para siempre.
Probablemente sea una mezcla de todo.
Y, ojo, no creo que exigir más cualificación sea necesariamente malo.
Todos los que llevamos algún tiempo trabajando hemos conocido líderes que no lideran, desarrolladores que no desarrollan y analistas que no analizan. También hemos conocido a gente muy buena sosteniendo proyectos enteros sin que casi nadie se dé cuenta.
Yo tampoco llevo tanto tiempo por aquí y ya he visto un poco de todo.
Lo que me interesa no es solo que el mercado exija más cualificación, sino qué vamos a considerar cualificación.
Porque escribir código nunca fue todo nuestro trabajo.
Y ahora lo es todavía menos.
Una IA puede generar una implementación en segundos. Puede escribir tests, explicarte un repositorio, encontrar errores, proponerte un refactor o montarte la base de una aplicación antes de que termines el café.
Eso es una realidad. Fingir que no está ocurriendo no va a hacer que desaparezca.
Pero una implementación no es necesariamente una solución.
Todavía hay que decidir qué construir, entender el problema y hablar con las personas que realmente lo tienen. Hay que saber qué compromisos estamos tomando, qué ocurrirá cuando algo falle y cuánto nos costará cambiar aquello dentro de dos años.
Hay que entender producción, los datos y el negocio.
Y, sobre todo, hay que saber cuándo no necesitamos montar Kafka para hacer un CRUD.
La IA puede ayudarte a escribir los diez servicios, sus abstracciones, los tests y los manifiestos de Kubernetes. El problema es que no siempre necesitas diez servicios, todas esas abstracciones ni un clúster de Kubernetes.
Generar código nunca había sido tan barato.
Tener criterio sigue siendo bastante caro.
Código o soluciones
Aquí creo que durante los próximos años veremos una diferencia cada vez más grande entre dos tipos de organizaciones.
Están las empresas que quieren producir código.
Y están las empresas que quieren construir soluciones.
Las primeras pueden descubrir que nunca había sido tan barato generar código. Le pides a una IA otra capa, otra abstracción u otros cinco servicios y los tienes en unos segundos.
Las segundas tienen un problema bastante más complicado.
Porque una solución mantenible no es simplemente código que compila. Tampoco es una arquitectura con muchos nombres interesantes en el diagrama.
Es entender el dominio, saber qué compromisos estás tomando y diseñar algo que pueda seguir funcionando cuando una dependencia se caiga, lleguen más usuarios de los esperados o la persona que escribió el código ya no esté en la empresa.
También es observabilidad, resiliencia y alta disponibilidad cuando el problema realmente las necesita.
Y es sencillez cuando no las necesita.
Porque no, un CRUD no tiene que tener Kafka.
Durante años hemos hablado de la deuda técnica como algo que pagaríamos «en el futuro». Ahora tengo curiosidad por ver qué ocurre cuando generar todavía más código cuesta segundos.
Hasta ahora, añadir complejidad tenía al menos cierta fricción. Había que escribirla, probarla y mantenerla. Esa fricción no impedía que construyéramos barbaridades, pero conseguía que alguien tuviera que invertir tiempo en ellas.
La IA reduce mucho ese coste inicial, pero no elimina el coste de entender el resultado, operarlo en producción o cambiarlo dentro de dos años.
Quizá algunas empresas descubran que la IA no ha eliminado su deuda técnica. Simplemente les ha permitido generarla a una velocidad que antes era imposible.
Y entonces llegará la factura.
No será solo la factura del proveedor de IA. Será la de mantener miles de líneas de código que nadie entiende del todo, producidas para resolver problemas que quizá no necesitaban tanto código.
Recursos menos escasos
Puede que dentro de unos años vuelva a leer esto y resulte que estaba completamente equivocado.
Quizá terminemos con sistemas de IA desarrollando de forma autónoma, desplegando y manteniendo producción alrededor del mundo mientras nosotros miramos desde casa.
En ese caso tocará licenciarse en IA.
Qué le vamos a hacer.
Mientras existan ordenadores, sospecho que encontraremos alguna manera de seguir rompiéndolos.
Pero, de momento, creo que seguimos exactamente donde estábamos.
Somos recursos.
Siempre lo fuimos.
La diferencia es que ahora quizá somos recursos menos escasos.
Eso no significa que todo el conocimiento haya dejado de importar. Puede significar justo lo contrario: cuando escribir código deja de ser la barrera, empieza a importar mucho más todo lo que había alrededor del código.
Entender por qué estamos construyendo algo.
Saber decir que no.
Elegir una solución sencilla aunque la compleja quede mejor en el diagrama.
Detectar que algo va a explotar antes de que explote.
Entender que un sistema no termina cuando hacemos merge.
Y preocuparse realmente por lo que estamos construyendo.
El problema es que ese criterio no se mide tan fácilmente como el número de tickets cerrados, las líneas generadas o la reducción de headcount que alguien puede poner en un Excel.
Y, como durante todos estos años, muchas veces serán los gerentes quienes decidan quién tiene ese conocimiento, quién aporta valor y quién es prescindible.
Veremos cuáles se preocupan por construir equipos y productos de calidad.
Cuáles entienden la IA como una herramienta para multiplicar las capacidades de esos equipos.
Y cuáles intentan surfear la ola reduciendo costes hasta descubrir que habían confundido generar código con construir software.
No sé quién terminará surfeándola perfectamente y quién se caerá por el camino. Tampoco sé si llegará un momento en el que la IA pueda hacerlo todo por nosotros.
De momento, mientras existan ordenadores, la informática sigue viva.
Y nosotros seguiremos construyendo.
Porque, spoiler:
somos un recurso.
Pero nunca todos los recursos fueron iguales.