¿Pueden los ingenieros construir sistemas de IA tan buenos que terminen sustituyendo por completo a los propios ingenieros? Y, si pueden, ¿por qué iban a querer hacerlo?
Piénsalo un momento. Somos nosotros quienes escribimos el código. Entendemos exactamente qué pueden y qué no pueden hacer estos sistemas. Sabemos qué partes de nuestro trabajo se automatizarán primero y cuáles quizá nunca lleguen a ser sustituibles. Así que, si estamos construyendo nuestro propio reemplazo, lo hacemos con plena conciencia de lo que estamos destruyendo.
Creo que sí lo haremos. No porque tengamos que hacerlo, sino porque queremos hacerlo.
Los comediantes dedican monólogos enteros a explicar por qué la comedia no significa nada. Los diseñadores de videojuegos crean juegos cuyo objetivo es volver innecesario al jugador. Quienes dirigen equipos construyen sistemas diseñados precisamente para eliminar su propia importancia.
Hay algo extrañamente atractivo en crear tu propia obsolescencia. Cuanto mejor se te da lo tuyo, más te atrae la idea de volverlo innecesario.
La semana pasada estaba depurando un código de automatización que había escrito, un sistema que evita tener que procesar datos a mano, algo que antes le costaba a nuestro equipo horas al día. Mientras lo corregía, me di cuenta de que estaba usando IA para ayudarme a escribir mejor código que sustituye trabajo humano de forma más eficiente.
Estoy usando IA para construir automatizaciones mejores que eliminan trabajo humano. Ahí se me hizo evidente la ironía: me estoy volviendo prescindible con herramientas diseñadas para volverme prescindible.
Este impulso autodestructivo aparece por todas partes. Los grandes creadores parecen sentirse atraídos por socavar su propia importancia y, de algún modo, eso vuelve su trabajo más valioso, no menos.
Cuando los comediantes diseccionan la comedia: el arte de la autoconciencia profesional
Recuerdo ver "Make Happy" de Bo Burnham y sentir que algo encajaba. Ahí estaba un comediante dedicando medio espectáculo a explicar por qué la comedia carecía de sentido.
En sus trabajos anteriores, a mitad del espectáculo, se acercaba a un foco y le decía al público cuánto había costado alquilar esa única luz. Luego calculaba cuántos niños en África podrían alimentarse con ese mismo dinero. Destruía la magia con toda naturalidad mientras seguía plantado dentro de ella.
Pero "Make Happy" fue distinto. Burnham pasó todo el espectáculo hablando de ser un comediante que nunca había hecho otra cosa. Todos sus chistes sobre la "vida real" eran inventados. Su única experiencia real consistía en hacer bromas sobre no tener experiencias reales.
El final fue brutal en su honestidad. Habló de cómo los comediantes parecen seguros de sí mismos sobre el escenario, pero en realidad no saben nada y no pueden hacer nada. Luego convirtió esa confesión en otro chiste. Hasta su vulnerabilidad estaba actuada.
Su canción "Art is Dead" captura esto a la perfección. Toda la canción gira en torno a la idea de que los artistas no son más que personas sedientas de atención que aprendieron a conseguir lo que quieren. Está cantando sobre lo irrelevante que es su propio arte mientras crea un arte que, en realidad, sí resulta significativo.
Me encantó. Pero, en el fondo, estaba viendo a un comediante defender que los comediantes no deberían existir. Burnham descubrió cómo usar la comedia para matar la comedia.
Esa autodestrucción acaba siendo hermosa. No está analizando la comedia desde fuera. Está usando la comedia para matar la comedia desde dentro y, aun así, eso crea algo mejor que el análisis o la comedia por separado.
Reconozco ese impulso. Mi código favorito me ahorra trabajo porque hace el trabajo por mí. Mis sistemas más logrados reducen la necesidad de más sistemas. Crear tu propia obsolescencia me resulta natural.
Construir sistemas que me despidan (y por qué me encanta)
Acabé dirigiendo equipos antes de lo que esperaba, casi por accidente, cuando algunos proyectos pequeños en los que andaba metido necesitaban más manos de las que yo solo podía aportar.
En cuanto tienes a otras personas trabajando contigo, enseguida te das cuenta de que la coordinación se convierte en un problema en sí mismo. No basta con sumar gente al proyecto y esperar que todo fluya bien.
Así que empecé a incorporar ayuda cuando los proyectos se me hicieron demasiado grandes para llevarlos yo solo. Y, sin importar en qué estuviera trabajando, seguía haciéndome la misma pregunta: si mañana cayera enfermo y no pudiera trabajar durante una semana, ¿se vendría todo abajo?
Me obsesioné con construir sistemas en los que yo pudiera desaparecer y nada se rompiera. Cada proceso que documenté, cada flujo de trabajo que puse en marcha, cada marco de decisión que diseñé: todo estaba pensado para que la empresa pudiera funcionar sin mí.
Un par de veces aquello me salió espectacularmente mal. Me apartaron de situaciones de las que no quería salir. Resulta que, cuando te vuelves reemplazable, a veces de verdad te reemplazan.
Pero la mayor parte del tiempo, este enfoque funcionó mejor de lo que esperaba. Cuanto mejor se me daba volverme innecesario, más necesario me volvía.
La mayoría de quienes dirigen equipos acaparan información y crean dependencias porque les aterra que los reemplacen. Se convierten en cuellos de botella. Hacer lo contrario funciona: trabajar activamente para dejar de serlo te vuelve valioso de una forma completamente distinta.
Ahora, cuando dirijo equipos, sigo la misma lógica de "despedirme a mí mismo". Todo lo que construyo está diseñado para que yo pudiera desaparecer mañana y el equipo siguiera funcionando sin sobresaltos. La buena gestión acaba haciendo prescindible a quien gestiona.
Diseñadores de juegos que convierten la optimización en una mecánica: el fenómeno Factorio
Hay toda una categoría de juegos, los simuladores de automatización, cuyo objetivo final es volverte innecesario.
Pensemos en el videojuego "Factorio". Empiezas extrayendo mineral con las manos y fabricando objetos básicos uno a uno. Pero el objetivo no es seguir haciendo eso para siempre. El objetivo es construir una fábrica que haga todo eso automáticamente mientras duermes.
He visto a amigos pasar tardes enteras, después del trabajo, montando cintas transportadoras y sistemas robóticos. Lo que ayer hacían a mano, hoy lo hacen las máquinas. Lo que la semana pasada exigía toda su atención, ahora funciona sin que tengan que intervenir en absoluto.
Esto resulta increíblemente satisfactorio. Literalmente estás avanzando hacia tu propia obsolescencia dentro del juego, y esa progresión, de ser esencial a volverte completamente innecesario, es el núcleo de la recompensa.
En Factorio, el éxito se mide por lo poco que el juego te necesita. Una fábrica perfectamente optimizada funciona durante horas sin intervención del jugador. Has construido algo tan eficiente que tu presencia se vuelve opcional.
Los diseñadores del juego crearon un sistema en el que el logro máximo es volver prescindible al jugador. Tomaron el concepto de automatización y lo convirtieron en entretenimiento. La gente llega a casa de trabajos en los que quizá ya se siente reemplazable y luego decide, por voluntad propia, jugar a un juego sobre sustituirse a sí misma.
Esto no es solo una mecánica de juego. Es la misma fuerza que empuja a los ingenieros a escribir código que escribe código, a quienes dirigen equipos a construir equipos que se sostienen solos y a los comediantes a crear chistes sobre la inutilidad de los chistes.
Los diseñadores entendieron algo fundamental. Sentimos una satisfacción profunda al crear sistemas que nos vuelven innecesarios. El código inteligente elimina la necesidad de más código. La automatización eficaz elimina la necesidad de trabajo manual. Los sistemas bien diseñados reducen la necesidad de sistemas adicionales. Factorio simplemente convirtió ese placer tan propio de la ingeniería en un videojuego.
Estamos programando nuestro propio reemplazo (y está funcionando)
Desde hace más de un año, escribo la mayor parte de mi código con comandos de voz apoyados en IA en Cursor IDE. Ayer construí una página de producto hablándole al ordenador durante unos veinte minutos en lugar de teclear.
Llevo ya un tiempo trabajando como CTO y construyendo sistemas.
En los últimos ocho meses he trabajado en varios sistemas de automatización:
- Un sistema que genera APIs CRUD básicas a partir de esquemas de base de datos: nos ahorra escribir el mismo código repetitivo una y otra vez
- Un extractor que lee documentación de APIs y escribe código de integración: funciona alrededor del 70% de las veces sin correcciones manuales
- Un experimento para generar aplicaciones móviles sencillas a partir de requisitos: todavía está bastante verde, pero sorprendentemente funciona
No son asistentes de IA que ayudan a programadores desde un chat. Son sistemas en los que los LLM escriben automáticamente la mayor parte del código, y los programadores revisan y corrigen lo que haga falta. Seguimos siendo esenciales, pero hemos pasado de escribir código a orquestar su generación.
No estoy observando cómo esto les ocurre a otros programadores. Estoy construyendo activamente estos sistemas yo mismo.
Reconozco el mismo patrón que describí con los comediantes y los diseñadores de juegos. Hay algo profundamente satisfactorio en lo bien que estos sistemas pueden sustituir trabajo manual.
Cuando la gente me pregunta si los programadores podrían terminar construyendo accidentalmente software que los reemplace, tengo clarísimo que sí lo haremos. No por accidente. A propósito. Por pura elegancia.
Hay algo perfectamente recursivo en que los ingenieros diseñemos nuestra propia obsolescencia. Construimos los sistemas que nos vuelven innecesarios. Entendemos exactamente lo que estamos haciendo y aun así seguimos haciéndolo porque la automatización es demasiado elegante como para resistirse.
No se me escapa la ironía. Estoy usando IA para escribir sistemas que reemplazan a programadores humanos y, al mismo tiempo, disfruto de verdad de lo limpio que resulta todo el proceso. Cada vez que elimino otro paso manual, cada vez que automatizo algo que antes requería criterio humano, siento la misma satisfacción que me da un algoritmo perfectamente optimizado.
Crear tu propio reemplazo es profundamente satisfactorio, sobre todo cuando lo haces bien.
No creo que esto ocurra de la noche a la mañana. Hay un enorme problema de última milla. Ajustar sistemas de IA para que manejen casos límite llevará más tiempo del que pensamos. Además, mejorar estos sistemas sigue recayendo en los ingenieros, al menos por ahora.
Pero la belleza de la automatización es lo bastante seductora como para que los ingenieros acepten fabricar su propia obsolescencia, incluso en contra de sus propios intereses.
Estamos construyendo nuestra propia obsolescencia porque es demasiado elegante como para no terminarla.
El patrón detrás del patrón
Bo Burnham usa la comedia para destruir la comedia. Yo construyo sistemas de gestión que vuelven prescindible a quien los dirige. Los diseñadores de juegos crean entretenimiento sobre volver innecesarios a los jugadores. Los ingenieros escriben código que reemplaza a los ingenieros.
Esto no es masoquismo ni suicidio profesional. Es algo más profundo.
Esta es mi teoría sobre lo que de verdad está pasando: no estamos construyendo IA para reemplazar a los ingenieros porque tengamos que hacerlo. Lo hacemos porque es el problema más interesante que hemos visto jamás.
Todos los ingenieros que conozco entraron en este campo porque les encanta resolver problemas. ¿Y cuál es el reto definitivo? Construir un sistema capaz de resolver problemas mejor que tú.
Es como Burnham usando la comedia para matar la comedia. Ves el problema y quieres resolverlo. ¿Puedes escribir código que escriba mejor código que tú?
Algunos ingenieros dicen que les preocupa que la IA les quite el trabajo. Pero mira lo que construyen de verdad en su tiempo libre. No están levantando defensas para proteger su puesto: están construyendo automatización.
Vamos a automatizar el trabajo de ingeniería porque el desafío es demasiado interesante como para ignorarlo. Y cuando funcione, estaremos orgullosos de ello.
