Versvs

Ser maestro de almazara cuando todo es automatizable

Publicado en 2026.09.24 por Jose Alcántara / 0 comentarios

Cuentan quienes saben de aceite que el verdadero peligro de una almazara moderna no es que se rompa la gigantesca centrifugadora de acero inoxidable, sino que el maestro de almazara pierda el olfato. A fin de cuentas, embotellar aceite malo cuesta exactamente los mismos vatios que embotellar ambrosía. Sin un buen criterio que le ponga control, la automatización podría terminar optimizando las cosas equivocadas.

No es un tema que podamos bautizar como nuevo. Al contrario, es el tema estrella en estos tiempos de incertidumbre: ¿dónde centrar nuestros esfuerzos cuando la inteligencia artificial automatice mi trabajo diario? En tono existencialista, ¿de qué vamos a trabajar cuando la inteligencia artificial automatice nuestro trabajo actual?

Pero vamos a mantener la calma. El mediático apocalipsis de trabajo no parece estar avalado por datos (más bien al contrario, Economist incluso habla de un boom de trabajos nuevos) y de la revolución industrial aprendimos que la transición fue generacional, quienes ya eran artesanos tenían un saber hacer que siguió siendo valioso durante décadas, incluso cuando las nuevas generaciones entraron al mercado laboral con nuevos roles adaptados a las nuevas máquinas disponibles.

De esto hemos hablado ya en varias ocasiones (¿De verdad los LLM nos van a volver estúpidos?), pero creo que el análisis más detallado lo hice a puerta cerrada en una newsletter interna para mis compañeros de trabajo, de modo que voy a traerme aquí algunas de las ideas que escribí entonces, acerca de qué tipo de tareas tiene sentido automatizar y en qué tipo de tareas tiene sentido enfocarnos nosotros.

Para ello, vamos a evaluar las tareas desde dos puntos de vista, cada uno con un pequeño marco analítico de respaldo:

Sobre tareas propiamente dichas, ¿dónde tiene más sentido enfocarte si eres una persona?
Sobre productos (o funcionalidades de producto), ¿qué tiene sentido internalizar y qué delegar en LLMs?

Mapeando tareas en el doble eje que va de la automatización fácil a la validación difícil

Hace unos meses se publicó un artículo muy cuco en este aspecto: Some Simple Economics of AGI (Arxiv). Oh sí, AGI. Ahora todo es AGI, y cuando todo es AGI nada es AGI. Algo manoseado el término. Pero vamos a no derrapar y continuemos con el artículo.

En este paper Catalini, Hui, y Wu clasifican tareas atendiendo a 2 ejes sencillos: cómo de sencilla o difícil es una tarea de automatizar y cómo de sencilla o difícil es de validar.

Esos dos ejes permiten establecer cuatro cuadrantes en los que clasificar nuestras tareas:

Fácil de automatizar / Fácil de validar
Esta es terreno para la máquina, con seguridad. Aquí se encuentran muchos casos de uso exitosos, sobre todo en ingeniería. El desarrollo de software es un buen ejemplo: el software puede generarse rápidamente y validarse de forma fiable a bajo coste; o bien compila y cumple con los criterios de rendimiento, o no lo hace. No hay trampas ocultas.
Difícil de automatizar / Fácil de validar
Zona de artesanía. Muchas actividades físicas o especializadas se sitúan aquí. Siguen siendo difíciles de automatizar, pero relativamente fáciles de evaluar una vez completadas. Fontaneros, electricistas, albañiles. El tubo pierde agua o no lo pierde, fácil de ver.
Difícil de automatizar / Difícil de validar
Se trata de actividades profundamente humanas y de carácter tácito, en las que tanto la automatización como la validación representan un desafío. Los ámbitos político y religioso están en esta categoría. Aunque seguro que hay quien sugiere que para el tipo de perfil humano que entra en política, quizá mejor un algoritmo… No entro a juzgar. No parece que la IA vaya a permitir automatizar esos asuntos a corto plazo.
Fácil de automatizar / Difícil de validar
Este es el cuadrante de mayor riesgo, donde una fuga genera problemas que tardamos mucho en notar de modo que sus efectos son siempre graves. La automatización resulta tentadora por ser económica y rápida, pero la validación es lenta, costosa o tardía. La calidad de algunas decisiones solo se revela con el paso del tiempo (pensemos, por ejemplo, en las inversiones, que son casi siempre planes de ejecución medio, largo, o muy largo plazo). Cuando la validación se demora respecto a la ejecución, el riesgo se acumula en el tiempo. En tiempos de ejecución automática ese diferencial puede ser enorme. Y cuando explote será devastador.

Conceptos conocidos para quienes siguen mis artículos como el de brecha de supervisión están relacionados con algunas ideas de ese artículo. El foco en la definición y la validación también.

Pero vamos con el segundo marco: el de producto. La misma lógica que decide dónde has de poner tu esfuerzo como persona va a ayudarnos a entender dónde poner nuestro esfuerzo al pensar en términos de producto.

La escasa primavera de un producto atrapado entre la promesa del verano y el frío del invierno

Todo lo anterior describe qué tipo de tareas tiene más o menos sentido automatizar pero, ¿qué sucede si eres una empresa que quiere sobrevivir en el mercado con un humilde producto que resuelva un problema concreto? ¿En qué aspectos tiene sentido invertir esfuerzo para añadir valor diferencial y qué otros aspectos conviene directamente delegar?

Discrepo de quienes dicen que el software ha muerto. El software lleva décadas transformando nuestro mundo y ahora producirlo es más barato que nunca. ¿Muerto? Vamos a producir más software del que jamás habíamos soñado. Solo que va a ser diferente. La promesa del viejo software-como-servicio (SaaS) está en horas bajas. Va a haber muchísimo más software, pero adaptado a flujos y problemas concretos (personales o corporativos).

Así que hablemos de software como producto. Hay quien defiende que conviene programar esa capa que habla con el modelo, el harness. Prácticamente todas las startups de IA que vemos se dedican a eso de una forma u otra: un software que interroga modelos, incluso las que hacen cacharritos a los que das órdenes de voz están, en esencia, dándote un harness para hablar con un modelo.

El asunto es que esto va muy rápido y se mueven dos frentes a la vez. En este último año hemos visto cómo los modelos se liaban cuando se les llenaba la ventana de contexto, cómo aprendían a anotar lo que sabían que iban a necesitar más adelante para no perderlo al seguir rodando esa ventana, y luego empezaron a trocear proyectos largos que no cabían en su ventana. Todo esto estaba primero en los agentes (el harness) y luego en los modelos mismos. Anthropic ya contó en su blog como al mejorar los modelos, piezas completas del agente/harness dejaron de ser necesarias. Opus incorpora ahora lógica que inicialmente estaba en Claude. El modelo aprende del harness y este último se adelgaza, haciendo hueco para terraformar nuevas habilidades que, al tiempo, serán aprendidas por el modelo y traspasadas al mismo.

Así que ya no es solo el miedo a que OpenAI, o Anthropic, o Google, vean tu ingeniosa idea de producto y decidan incorporarla a su producto, con mil veces mejor distribución que el tuyo. Es que los propios LLM con los que tu producto interactúa la terminen aprendiendo y la hagan sin que el harness de los grandes vendors de IA la incorpore.

La situación recuerda a la de la Web 2.0 a principios de siglo, cuando el mayor objetivo era que te comprasen Google o Microsoft y tu mayor miedo era… que decidiesen implementar tu idea sin comprarte.

La prueba de PACO, o prueba de absorción

En estas encontré en un post en Hackernoon una taxonomía interesante para decidir qué parte de tu producto es core y te toca hacerlo y qué parte vas a delegar en otros. La pregunta que se hace es: ¿cómo identifico si merece la pena poner a mi equipo a programar una cierta funcionalidad? Para responderla usa otras dos preguntas:

¿Podría uno de los laboratorios en la frontera lanzar tu producto como funcionalidad base de su propio harness?
¿Podría un modelo aprender tu lógica de negocio y resolverla automáticamente volviéndote innecesario?

Si la respuesta a alguna de estas dos es positiva, es muy probable que no te merezca la pena invertir horas de ingeniería en ese aspecto concreto, porque antes o después te van a absorber o el LLM o alguno de los grandes laboratorios de IA con sus clientes de uso masivo.

Con esta habilidad tan norteamericana para los acrónimos, el artículo propone PACT (Proof, Authority, Context, Taste) para guiarnos. A mí al traducirlo me ha salido PACO porque taste lo he traducido como olfato, no solo por las risas sino porque frente a la solemnidad de Silicon Valley quizá viene bien una chispa de sentido común.

Básicamente, hay que huir de los mecanismos, cuyo acceso va a generalizarse y enfocarse en las reglas de juego que definen qué puede hacerse con los mecanismos.

Prueba. Validación funcional. Los agentes son indulgentes evaluándose a sí mismos y tienden a inflar su propia nota. A mayor volumen de trabajo generado, más cotiza la capacidad de auditarlo.
Autoridad. Gobernanza y accesos. Quién actúa, qué permisos tiene y hasta dónde entra la IA. La plataforma te da la infraestructura; el límite de actuación no se delega.
Contexto. La verdad interna del negocio. Tus procesos, fuentes y convenciones de código. Ningún modelo preentrenado conoce tu organización, así que esta memoria es cosa tuya.
Olfato. El listón de calidad. Sin control, los LLM convergen en lo genérico. Abandonar esa mediocridad exige forzar al modelo a ir por el camino que tú le trazas, programar tu propio estándar en el sistema que lo va a controlar.

Si la funcionalidad pasa la prueba de PACO y gestiona aspectos de la validación, la gobernanza, el contexto único del problema a resolver, o el criterio que ha de definir qué es bueno, entonces merece la pena meterla al backlog y programarla de forma nativa. Así que ya saben, si estaban pensando en hacer un microagente especializado en extraer información de charlas TED, no pasa la prueba de PACO, cualquier modelo lo hace ya sin más. Pero si piensan ayudar a los contables a cerrar el trimestre fiscal validando contra normativas específicas y usando contexto interno de empresas no disponible en otro sitio, quizá tenga sentido ayudarles a tener un harness o un software específico (al menos, por ahora).

La convergencia de ambos enfoques

Ambos marcos convergen en el criterio como valor clave, quizá lo único que sigue humanizando en este bucle. La validación difícil del primer marco y el olfato del segundo son la misma cosa vista desde dos ángulos: el criterio que decide si el aceite es bueno. Por ahora, ése sigue siendo nuestro lugar en el bucle. Parece que a nuestro maestro de almazara no va a ser fácil reemplazarlo.

Inteligencia artificial

Humanidad transitiva

Publicado en 2026.08.24 por Jose Alcántara / Comentarios desactivados

Trenes, barcos y aviones imitan a la naturaleza en lo que consiguen, pero no en el cómo. A la inteligencia artificial no le damos ese margen: buscamos en la máquina un reflejo nuestro.

Gafas, equipo de sonido, frigorífico. Nuestras casas son auténticas Wunderkammern que habrían hecho enloquecer a cualquier rey del siglo XVI.

Hace unos días me encontré con Ordinary Abundance. Un recordatorio breve, factual pero aún dotado de cierta remembranza lírica, de que muchas de las cosas que hoy damos por sentadas en nuestro día a día son pura genialidad que hace apenas unos siglos habraían maravillado a cualquiera.

No se trata de decir que el mundo sea perfecto, obviamente no lo es. Pero es maravillante, jugando a construir un participio activo. Maravillado es quien recibe el asombro; maravillante, lo que lo provoca. Un poco como estúpido y estupendo, que salen los dos del stupere latino y aluden a ese quedarse pasmado, diferenciándose únicamente según de qué lado del pasmo te toque estar.

El mundo no ha dejado de ser maravillante. Pero nosotros hemos dejado de estar maravillados.

Abundancia ordinaria, el agua que hemos dejado de ver

Sin ser el Edén, no obstante, vivimos en un mundo que hemos llenado de cotidianas maravillas: desde el frigorífico a las gafas o esa lámina que compraste en Orsay para llevarte a casa tu cuadro preferido. Tan inmersos en maravillas que a veces las olvidamos, como los pececillos de David Foster Wallace olvidaban qué era el agua, de tanto verla.

Igual con esta última frase os he perdido. Me regañarán mis queridos expertos en marketing por desviarles del hilo ahora que ya tenía su atención, pero tienen ustedes que oír This is Water, de David Foster Wallace. Es un texto precioso del que hablé en el blog en un par de ocasiones (y la de ocasiones en que me he contenido; hoy, no).

El espejo del guepardo y las maravillas que nunca son como las imaginamos

Parte del problema es que somos un poco cuadriculados acerca de cómo han de ser los inventos futuros. El meme invita a hablar de coches voladores. La realidad siempre es diferente. Es un poco lo que pides en AliExpress y lo que te llega, fenómeno que en pocos casos se cumple con más certidumbre que cuando el ser humano trata de imitar a la naturaleza.

Es ahí donde nos liamos. No comparamos el invento con lo que el invento hace, sino con lo que teníamos en la cabeza cuando lo imaginamos. El guepardo es el espejo con el que medimos al tren, y el tren siempre va a salir perdiendo en aquello que el guepardo hace bien.

El ser humano quería ser rápido como los guepardos e inventamos cosas para movernos rápido, pero los trenes y los coches no corren como un guepardo. También quisimos viajar por el agua como los peces y también lo conseguimos, pero barcos y submarinos no se desplazan como un pez. Y podemos volar, pero tampoco volamos como un pájaro.

Creación humana como imitación de la vida

Todas esas invenciones son a la vez superiores e inferiores a la alternativa original. Somos más rápidos, pero no cambiamos de dirección con la misma facilidad; volamos más lejos, pero necesitamos varios kilómetros solo para despegar y una mosca despega y aterriza en el capuchón de mi boli Bic. Por dejarlo en un par de ejemplos sencillos.

Con la inteligencia pasa igual, solo que el espejo lo llevamos puesto. Los humanos tendemos a vernos en el centro mismo del universo (y esto nos lleva de vuelta al default system que Wallace describe en el meollo más interesante de This is Water), de modo que consideramos que las cosas son naturales solo cuando cumplen nuestros criterios. Miramos la máquina buscando nuestro reflejo y, al no encontrarlo, concluimos que no hay humanidad ahí dentro. Somos un tanto chauvinistas, por así decirlo.

Movimiento 37, o la inteligencia que no supimos ver

En Maniac (del que hablamos hace unos días), Labatut relata el enfrentamiento entre AlphaGo y Lee Sedol (el duelo multipartida equivalente en go al Kasparov vs Deep Blue de ajedrez, mucho menos conocido en occidente pese a su grandísima relevancia). En marzo de 2016, durante la segunda partida del duelo, en el movimiento 37, la máquina coloca una piedra en un lugar inesperado del tablero, en un lugar donde ningún profesional habría jugado jamás. A los comentaristas les da la risa y asumen que es un error; tras todo el hype tras la primera victoria, la máquina no estaba a la altura del reto, game over.

AlphaGo vs Lee Sedol (Marzo 2016), Partida 2, Movimiento 37

O eso creyeron durante unos minutos. Fan Hui, campeón europeo y que ya había sido derrotado por AlphaGo unos meses antes, fue el primero que, casi en directo, opinó diferente: aquello de que no era un movimiento humano.

Sobra decir que AlphaGo ganó la partida y, a la postre, el duelo.

Ahí tienen ustedes el guepardo y el tren, versión go. Enfrentados a un razonamiento que no es superior ni inferior pero sí distinto nuestra primera reacción colectiva fue llamarlo equivocación. Cuando tu agente se pone a programar piensa diferente a como lo haces tú y, como no reconocemos esa forma de razonar, la miramos desde arriba. No será para tanto, no será verdadera inteligencia, concluimos.

Por intentar ser objetivo, conviene ver si logramos meter la cuchara a la contra. Nadie discute si un avión vuela, porque volar tiene una definición y el avión la cumple. Con inteligencia no tenemos una definición tan objetiva; algo que nos ponga de acuerdo y con lo que valorar sin ambigüedad si algo representa o no inteligencia.

Pero entonces la postura podría ser «no lo sé» en lugar de «no lo es». Y a eso se suma nuestra reticencia a darle el marchamo: cada vez que hemos tenido una definición clara, la hemos movido. Inteligencia es jugar bien al ajedrez, hasta que cayó el ajedrez y dejó de parecernos el único requisito. Ahí añadimos que había que jugar bien al go, hasta que también cayó el go. Traducir, escribir, ¿demostrar nuevos teoremas quizá? ¿Habrá que mover la portería de nuevo? Lean a Daniel Arjona sobre esto. La frontera de lo que cuenta como inteligencia lleva treinta años retrocediendo justo hasta donde la máquina todavía no llega, lo cual es una manera muy elaborada pero un poco sibilina de no perder nunca la discusión.

Humanidad transitiva, nuestra esencia extendida a nuestras creaciones

La vida es lo que pasa mientras estudias ciencias y lees a Tolkien. La mía, al menos. Vamos a meterlo todo en la batidora.

Sagan, profundamente ateo, escribió en Cosmos que somos una forma que tiene el cosmos de conocerse a sí mismo. Así, una inteligencia artificial no es inhumana porque es una vuelta al mismo mecanismo. El de la materia organizándose para entenderse, ahora a través de nosotros en lugar de directamente. Tolkien llegó a un sitio parecido desde el extremo opuesto. Profundamente católico, en On fairy tales llama subcreación a lo que hace el ser humano cuando construye mundos, y en Mythopoeia lo resume mejor de lo que voy a poder resumirlo yo: creamos según la ley con la que fuimos creados. Las proezas de los elfos en su obra eran subcreaciones de Ilúvatar, que les dio ese poder de crear, y nuestras máquinas son subcreaciones nuestras exactamente por el mismo mecanismo. Dos personajes brillantes con concepciones de la naturaleza totalmente opuestas que, en este punto, habrían estado relativamente de acuerdo.

Esto confiere a nuestras creaciones una suerte de humanidad transitiva: la propiedad de que aquello que hacemos siga siendo humano aunque ya no se nos parezca, porque viene de nosotros. El avión vendría a ser tan humano como la mano que lo dibujó y la mente que lo imaginó. Un modelo que juega al go no piensa como nosotros pero juega, y precisamente por eso es una de las cosas más humanas que hemos construido nunca. Es la parte de nosotros que sale a explorar el espacio de soluciones donde nuestra biología se desorienta y se pierde esperando al bibliotecario que le diga por qué pasillo empezar a buscar.

Lo cual, si me permiten aterrizarlo en el bucle, cambia la pregunta útil. «¿Es verdadera inteligencia?» no tiene respuesta y no le sirve a nadie el lunes por la mañana (aunque amenice sobremesas). La que sí sirve es «en qué problemas piensa mejor que nosotros», para saber dónde ubicarnos. Porque el lugar que queda para nosotros podría no estar donde la máquina es peor sino donde es distinta.

Y nos va a costar aceptar esa inteligencia distinta como inteligencia, igual que no aceptamos a los aviones como los pájaros y, sin embargo, vuelan.

Desarrollo de Software/Inteligencia artificial

Deja de mirar el código

Publicado en 2026.08.04 por Jose Alcántara / Comentarios desactivados

«Oh, ahora ya no necesito programadores, mira mi superaplicación vibecodeada disponible en…. localhost:3000».

El chiste está tan usado que ya da hasta vergüenza, pero se sigue viendo.Y, con todo, el pequeño atisbo de soberbia que suele acompañarlo no es lo peor. Lo peor es que yerra en el enfoque.

La intención de la broma es dejar caer, de forma más o menos velada, que no es para tanto. Que un programador sabe cosas que ese contable que se hace herramientas sencillas para casos de uso específicos necesita. Que es poco más o menos que irreemplazable. Lo dicho, que hay un poso de soberbia. «¿Cómo me va a pasar a mí, que soy ingeniero, lo mismo que a los cajeros del súper o a quienes blandían la manguera de la gasolinera?» Al palo. Quizá sea mejor ver qué pasó con los contables.

Podríamos parar aquí y dedicar el post a repetir de nuevo que los LLM son tan solo la nueva capa de abstracción sobre la que construimos; que ya no usamos software estático para hacer documentos sino software modelos y agentes para fabricar software personalizado en tiempo real. Pero not today, lo siento.

Hoy vamos a hablar directamente del trabajo de los programadores profesionales y de cómo vamos a tener que rediseñar la forma en que producimos software.

Me encanta VS Code. Uso Claude con su extensión ahí empotrado. También uso Antigravity en modo full IDE (al final es un fork, son casi idénticos). Hay algo de atavismo: me gusta ver el código, saber que si la IA comete un error podré bajar al barro y arreglarlo a mano tirando de oficio.

Algo que, por otra parte, cada vez pasa menos.

Alguna cosilla toco a mano, pero muy poco. En general los modelos más actuales implementan razonablemente bien los casos de uso cotidianos. Y si se les escapa algún detalle en sus múltiples pasadas de test… les paso la traza de error y el modelo caza el problema.

Ahora que todos somos expertos en La Odisea (y confieso que no he visto todavía la nueva película de Nolan pero ando liado con el libro), hay una escena en el Canto XIII donde Atenea, la de ojos de lechuza, se revela ante Odiseo en las playas de Ítaca. La diosa no aparece allí para sustituir la astucia del héroe, sino para ayudarle: anticipa los problemas y le ayuda a evitarlos. Odiseo no se pone a afilar lanzas en pleno combate; confía en el criterio sobrehumano de su aliada.

Nosotros estamos viviendo nuestro propio momento Homérico frente al editor de código.

Pero vamos más allá: ¿y si la afición por mirar el código y tocarlo a mano fuese una mala práctica?

Para la mayoría del software que hacemos, con modelos disponibles que poseen altísimas capacidades en materia de ciberseguridad (tanto en ataque como en defensa), que detectan defectos que llevaban años escondidos ante los ojos de los mejores programadores del mundo, ¿es sensato seguir editando líneas a mano?

Este debate se parece mucho al del coche autónomo. Escribíamos en 2018 al hilo de una noticia sobre la primera víctima de un coche autónomo que la última víctima no sería noticia:

Un día los coches autónomos provocarán menos accidentes que los hasta ahora convencionales; y no será noticia porque tendemos a pasar por alto cuando las cosas sencillamente funcionan.

Y retomábamos la idea en 2023 (Tendrás coche, pero no lo conducirás):

Si el software conduce estadísticamente mejor que las personas, ¿no sería precisamente lo más ético priorizar que sea la máquina la que conduzca el coche para minimizar las víctimas?

Con datos de 2025, los vehículos autónomos producen entre un 60% y un 80% menos accidentes que los humanos (CBC). Aún más a su favor si consideramos que los coches autónomos reportan por obligación legal todos los incidentes a la policía mientras los humanos resolvemos un 30% de los roces con un parte amistoso sin que quede registro policial formal. El algoritmo nos gana aquí también.

Hay un pasaje de Criptonomicón de Neal Stephenson (ya saben, una de mis debilidades literarias) que me viene a la cabeza. Un operario, incapaz de confiar del todo en las instrucciones que recibe, introduce su propio criterio al generar unas claves que deberían ser completamente aleatorias pero dejan de serlo debido precisamente a eso. El resultado es, precisamente por eso, menos seguro.

Es una buena metáfora de lo que empieza a ocurrirnos con el código: llega un momento en que nuestra intervención manual deja de ser una garantía de calidad y puede convertirse en una fuente de errores.

Volvamos al software: llegado el momento en que el software es capaz de encontrar defectos que tú no viste y evitarlos durante la implementación antes de que lleguen a producción, ¿es buena idea que metas tus zarpas en el código? No hay que tener miedo a dejar que la máquina haga el código.

Pasa el tiempo y actualizamos la definición de lo que consideramos buenas prácticas. Eso lo sabe cualquiera que lleve suficientes trienios picando piedra. Hoy sale una librería, mañana seguir usándola te hace quedar mal (jQuery, ¡qué la tierra te sea leve!).

Empresas como Google ya empujan a sus ingenieros a no tocar código fuente a mano. Y no lo hacen por fardar ni por token maxxing. Lo hacen porque dada la pendiente de aprendizaje y desarrollo de los LLMs, lo más inteligente que podemos hacer es delegar la producción de código y centrar el intelecto humano en otra parte del proceso. Nuestro lugar en el bucle es otro: la concepción y la validación (y en tareas cuya validación sea automatizable más en la primera que en la segunda).

Esto deja dos lecciones sobre la mesa.

La brecha de calidad. En breve el código hecho por máquina va a ser tan superior que tú versión manual va a verse tosca. Si no eres muy top programando, seguramente para ti esto ya sea verdad.
El cambio de herramientas. A usar una herramienta se aprende usándola. Si la forma de crear código y operar sistemas pasa por prompts, skills, e orquestación de agentes, cuanto antes adquieras soltura en ese diálogo, antes volverás a ser relevante.

¿Dónde es mejor el humano que el bot (al menos por ahora)? Entendiendo qué hay que hacer y decidiendo hacia dónde ha de ir el producto. Se nos da sensiblemente mejor el diseño de soluciones extremo a extremo y la visión holística, mientras que la IA tiende a ir a lo microlocal y termina parcheando de mala manera si no se la supervisa.

Y todo está bien. Magnus Larssen juega al ajedrez mejor que Kasparov gracias a la inteligencia artificial. Seguiremos haciendo software, nos lo vamos a pasar en grande siendo creativos y resolviendo problemas, pero no como antes. Vamos a hacerlo de otra forma. Non ti preoccupare.

[Imágenes: Jose Alcántara con ChatGPT.]

Empresa y organización/Inteligencia artificial

Tomas de decisión multicriterio para visibilizar las motivaciones ocultas

Publicado en 2026.07.27 por Jose Alcántara / Comentarios desactivados

«I changed by not changing at all», cantaba Eddie Vedder en una de las canciones acústicas más hermosas que se hayan escrito. Esa frase resume por qué encallan la mayoría de reorganizaciones corporativas: las empresas deciden cambiar algo basándose en subjetividad y sesgos, en lugar de aplicar un sistema racional que optimice la decisión.

Vamos a hablar de toma de decisiones multicriterio, aplicada a un caso concreto: reorientar una estructura de equipos hacia dominios de negocio.

De reorganización de equipos de software

“¿Cómo que la frontera de trabajo entre los equipos no está clara?” A mí, germanófilo empedernido, me gusta mucho responder con un jein (esa mezcla alemana de ja y nein, sí y no).

El tiempo pasa y tu producto evoluciona. Tus equipos se van desalineando del negocio por pura inercia del mercado y tu producto. Un día el desajuste es tal que alguien aparece con la idea feliz de reorganizar la casa. Y no es infrecuente que se proponga con cierta resignación. Vamos, que ese alguien preferiría, en el fondo, no tener que tocar nada.

Decisiones multicriterio en la vida real: produciendo software

La siguiente parte de esta nota es una descripción de pequeño framework para ayudar a valorar las alternativas de forma más o menos objetiva. Vamos con un ejemplo paso a paso.

1. Entender las alternativas

¿Qué opciones tenemos realmente?

A: Silos Funcionales. Cada departamento a lo suyo, paso de testigos (handoffs) y asignación de recursos por proyecto.
B: Orientación a Negocio / Value Streams. Equipos multidisciplinares, estables y autónomos, enfocados a un producto o flujo de valor.
C: Estructura Híbrida / Matricial. Equipos de proyecto temporales, con personas que siguen reportando a sus jefes funcionales.

En no pocos casos la opción A es el statu quo, la B es la que se declara en el PowerPoint, y la C es la que se acaba adoptando porque permite salvar la cara a (casi) todos los stakeholders, aunque deje sin tocar problemas de fondo.

2. Acordar criterios ponderados

En un escenario real descubrir estos criterios llevará un buen rato, idealmente de trabajo en equipo. Por no complicarnos, trabajemos con cuatro criterios sencillos:

Criterio	Peso
Time-to-Market / Foco en Negocio: «Queremos entregar valor rápido»	5
Calidad del Producto «Cero bugs en producción»	2
Eficiencia de Costes «Optimizar el presupuesto»	2
Control de Riesgos «Seguridad y procesos robustos»	1

Lo siguiente es ver qué puntuación merecen cada una de las alternativas en cada uno de estos ejes, ponderamos el resultado por el peso del mismo, y vemos cuál es la opción que sale triunfadora en base a este marco.

¿Qué cabe esperar? En muchos casos, puede que el resultado diga una cosa pero la realidad observada diga otra.

Aquí está la pregunta que estábamos esperando: si la matriz dice que B es la ganadora absoluta, ¿por qué seguimos operando en A o atascados en C?

Lo has vivido. Todos lo hemos vivido. Según McKinsey, cerca del 90% de las organizaciones experimenta con cambios estructurales o tecnológicos, pero apenas un 7% logra un despliegue con impacto real.

La disonancia cognitiva entre resolverlo en la pizarra e integrarlo en la cultura del día a día es salvaje. Cantaba Sabina “que no hay ser humano que le eche una mano a quien no se quiere dejar ayudar”. Ningún workshop puede arreglar un sistema que, en el fondo, no quiere ser arreglado.

La abstracción metodológica como eliminador de fricción

La genialidad de este marco reside en confrontar al grupo con tres verdades de forma que sean difíciles de soslayar:

Externaliza el pensamiento: Baja el debate de la cabeza (donde sesgos, política de pasillo y emociones distorsionan la realidad) a un plano lógico. Esto va de datos. No es nada personal.
Obliga a consensuar los criterios: El conflicto de base es que cada stakeholder tiene intereses distintos y prioriza cosas distintas. Acordar criterios y ponderarlos ayuda a alinear la importancia relativa de los diferentes factores.
Evita el autoengaño: Si la matriz dice una cosa pero pero la organización sigue queriendo hacer otra, aquí hay tomate. Hay criterios que no se pusieron sobre la mesa pero siguen pesando en la decisión final.

Y ahí empieza la diversión.

Haciendo aflorar los Criterios Ocultos

La hora de la verdad.

En un proceso puramente racional, la organización acordaría el plan para migrar a la opción que sumó más puntos y todos tan contentos. Pero, para sorpresa de nadie, eso no suele suceder..

Cuando las matemáticas dan una opción ganadora pero el cambio no llega y al final se paraliza, es porque se están ponderando criterios que nadie ha querido poner sobre la mesa. Javier Recuenco, acostumbrado a lidiar y evangelizar sobre la resolución de problemas de esta índole, diría que tu subconsciente ya había decidido comprar salmón y toda la conversación posterior sobre nutrición te sobraba bastante: ni dieta equilibrada, ni variedad, ni leches. SAL-MÓN. Es a lo que habías venido y es lo que vas a comprar. Y los números, que esperen.

Pero te estás haciendo trampas al solitario. Y lo sabes.

El verdadero valor de usar un framework de decisión multicriterio como el del ejemplo no es sacar una nota media intentando encontrar una solución que permita nadar y guardar la ropa, sino obligarte a un ejercicio de honestidad sacando a la luz los criterios implícitos que están condicionando la decisión pero de los que no se está hablando.

Algunos ejemplos:

Pérdida de control e influencia: Tras una reorganización hacia dominios de negocio, los jefes de áreas funcionales tienen un rol diferente. ¿Cuánto miedo hay a perder el feudo?
Garantía de utilización de recursos: El pánico funcional a que un programador esté “parado” un día porque el equipo de producto no lo necesita en ese sprint. Se sigue priorizando la eficiencia de recursos sobre la eficiencia de flujo (que por cierto es algo que impacta sobre el time-to-market, que era un criterio en la matriz que usamos más arriba), sobre esto hablé en su día cuando tratamos eficacia vs eficiencia.
Sensación de seguridad personal: En la estructura funcional, con múltiples áreas implicadas, la responsabilidad sobre un fracaso se diluye. En un equipo de producto, la responsabilidad es compartida e ineludible. El silo provee ciertos escondites y una dosis de paz mental.
Sobrecarga cognitiva de gestión: Cambiar a negocio implica cambiar gobernanza y habilitar nuevas líneas de comunicación, sacar a muchas personas de su zona de confort para que traten con personas con las que antes no necesitaban tratar.

El fin de la mascarada y el diseño correcto de incentivos

Poner sobre el papel tanto la conducta declarada como la naturaleza subyacente de la organización produce un efecto definitivo: presenta un autorretrato imposible de ignorar. Es el fin del cinismo. Ya nadie puede sostener que la empresa prefiere el time-to-market cuando es obvio que pondera el control.

Lo que la organización elige de verdad, no lo que dice elegir, está perfectamente calibrado para lo que a al management de la misma le importa.

Llegados a este punto, la misión es rediseñar los objetivos y mover la discusión al sitio correcto. El debate ya no puede seguir siendo metodológico; ahí ya no queda nada por discutir. Toca hablar de lo político y lo cultural.

Quizá sea más relevante repensar el variable a corto plazo (el famoso bonus) de esos managers para que cobrarlo dependa de tomar la decisión estructural correcta. O trabajar explícitamente en cómo gestionar el miedo al error si eliminamos los silos que les sirven de refugio, construyendo una cultura corporativa que premie de verdad el experimentar y aprender rápido.

Al final, como en aquella mujer de la canción de Pearl Jam que vio pasar la vida desde detrás de un mostrador, el mayor riesgo de las empresas es ver pasar los años cambiando cosas de sitio para seguir, en el fondo, exactamente en el mismo lugar.

[Imagenes. Jose Alcántara con Gemini.]

Política

La españita feliz y la melancolía de las pilas gastadas

Publicado en 2026.07.23 por Jose Alcántara / Comentarios desactivados

La españita feliz. A estas alturas, todos estamos más que familiarizados con la expresión y con el imaginario que evoca. Se recurre a ella con esa nostalgia amarga de tiempos pasados, cuando la sociedad española vivía en una suerte de optimismo despreocupado, empujada por un progreso que se sentía como una inercia inevitable. Unos sitúan este oasis en la última década del siglo pasado; otros prefieren ubicarlo ya en los primeros compases del nuevo milenio.

Cuando la expresión salta al terreno del meme, esa españita feliz se contrapone frontalmente al humor de la España actual. Un presente donde la sensación de progreso ha desaparecido: la convergencia con los vecinos ricos de Europa ha empezado a dar marcha atrás, media Centroeuropa nos adelanta en renta per cápita, los jóvenes se ven incapaces de emanciparse o formar una familia, y la sostenibilidad del Estado (con las pensiones a la cabeza) exhibe una lista casi interminable de achaques.

La excusa para hilvanar este texto la encontré hace poco durante una visita a Budapest. Allí me topé con que en Hungría denominan «los felices tiempos de paz» (boldog békeidők) al medio siglo que transcurre entre la consecución de una mayor autonomía dentro del Imperio Húngaro en 1867 y la disolución absoluta de dicho imperio en 1918, tras la Primera Guerra Mundial. La Hungría feliz, por buscarle el gemelo.

Lo que me pareció llamativo fue el paralelismo entre ambos memes históricos. Al final, la felicidad es eso que pasa entre que pedimos un deseo y se nos concede. Es exactamente como comprar lotería de Navidad en pleno mes de agosto: sabes perfectamente que no te va a tocar, pero durante esos meses te regalas el lujo de fantasear con ello.

Hagamos un poco de memoria comparada:

En Hungría: Tras el fiasco revolucionario de 1848, consiguen la anhelada autonomía en 1867, equiparando oficialmente Budapest a la altura de Viena. Todo va sobre ruedas hasta que en 1918, tras la Gran Guerra, el imperio salta por los aires, la separación es total y el periodo de los «tiempos felices» echa el cierre.
En España: Se aprueba la Constitución del 78, cimentando la segunda restauración borbónica, eso que hemos dado en llamar la Transición, y abriendo un ciclo de descentralización sin precedentes que, al menos al principio, se une a una expansión económica y social que hoy recordamos, con cierta ternura, como la españita feliz.

En ambos escenarios, el fin de la burbuja coincide sospechosamente con el momento en que empezamos a sufrir las consecuencias de haber obtenido, precisamente, lo que habíamos deseado. Deseos que, por cierto, eran alarmantemente parecidos en ambos casos (identitarismo y autonomía regional, descentralización del estado).

Es la diferencia de toda la vida entre pedir un regalo de Reyes con toda la ilusión del mundo, abrirlo el día seis por la mañana, y descubrir a las dos horas que se le han gastado las pilas.

Citas/Frases/Lecturas

El mundo tendría que salvarse a sí mismo

Publicado en 2026.07.14 por Jose Alcántara / Comentarios desactivados

Todo estaba a nuestra disposición. Lo novedoso aparecía como por arte de magia y caía en nuestras palmas como si fuese maná del cielo. Invenciones y descubrimientos, niveles de producción agrícola nunca antes vistos, artefactos de alta gama, artificios, juguetes, ropa de última moda, teatro, dulces, música, ¡cine! Vivíamos en el rapto constante de lo nuevo. Fue necesario adaptarnos para aprender a convivir con esa abundancia feroz. ¿Qué hicimos? Gozamos, jugamos y nos emborrachamos. Bailamos de una guerra a la siguiente. ¿Qué alternativa nos quedaba? Todos sabíamos que ese mundo perfecto que nuestros padres habían construido para nosotros se estaba acabando. Por eso nuestros juegos eran urgentes. Necesarios. Simplemente teníamos que divertirnos. No había nada más que hacer. Porque intuíamos lo que venía. No sé cómo, pero lo sabíamos. Todos lo sabíamos. Hombres y mujeres, ricos y pobres, judíos y goyim. Todos. Así que nos comportamos como niños, e hicimos lo que ellos hacen mejor que nadie: pretender que nada estaba sucediendo para poder seguir jugando. El mundo tendría que salvarse a sí mismo.

Benjamin Labatut, en Maniac.

Leí hace un tiempo Un verdor terrible de Labatut, y voy a usar unos días de asueto en darle un repaso a Maniac, que de momento ha empezado muy bien.

Desarrollo de Software/Empresa y organización/Inteligencia artificial

La wiki como repositorio de skills (o por qué tu agente de IA necesita leer tu Confluence)

Publicado en 2026.07.14 por Jose Alcántara / Comentarios desactivados

Una de las cosas que me obsesiona desde que tengo uso de razón profesional es la gestión del conocimiento. Es una de esas hebras invisibles que sostiene todo lo que he hecho: desde los tiempos analógicos en que estudiaba mi doctorado y me dedicaba a la investigación científica, hasta la gestión de equipos de desarrollo de software en la que ando metido a día de hoy.

Para mí, es casi una obligación moral. Si el objetivo es el progreso de la humanidad, el único camino transitable es ampliar el conocimiento del que disponemos para continuar avanzando.

Pero el conocimiento, si no está en su contexto, deviene fácilmente en ruido.

Siempre he pensado que un blog necesita una pedia que lo ordene. Un rincón donde ir destilando conceptos y acunándolos en su propio caldo de cultivo. Es ahí donde hace ya muchos años nació en mi web el concepto de tabletización, cuando Apple y Google redefinían cómo nos relacionábamos con la tecnología. Y es ahí donde, ahora que vivimos la gran transformación de los LLM, sigo añadiendo notas como la reciente sobre la brecha de supervisión.

Todo esto lo cuento para ilustrar que soy muy de comerme mi propia comida de perro. Defiendo la gestión del conocimiento porque creo en ella con fiereza.

El segundo cerebro y la consistencia personal

Hablemos de cómo aprovechar la actual generación de herramientas de IA para gestionar lo que sabemos. El terreno se divide en dos escenarios básicos: tu sistema personal y el que compartes con tu equipo. Semejantes en la superficie, distintos en el fondo.

Para uso personal hay que admitir que los setup tipo segundo cerebro son imbatibles.

La idea es sencilla: un sistema en el que acumulas notas, documentos y reflexiones en bruto, y sobre el que un LLM pasa el escáner constantemente para relacionar cada nuevo pensamiento con lo que ya existía. Es una combinación potente, pero tiene truco: requiere una consistencia de hierro a la hora de tomar notas.

Sin consistencia no hay completitud. Y es esa completitud de ideas, unida al larguísimo alcance neuronal de los LLM, la que permite que emerja la magia y descubras conexiones que ni sospechabas.

Lo probé un tiempo. Es potente, sí, pero también es un pequeño dolor de muelas: el software para tomar notas por un lado, el de sincronización por otro, la API del LLM por el suyo… La idea es potente y diría que hay un hueco en el mercado para un producto que integre todo esto de forma nativa y sin fricción.

De wikis para humanos a repositorios de skills para agentes

Seguro que en tu empresa tenéis una wiki. Llámale Confluence, Notion o como quieras. Y seguro que tenéis unas directrices de uso sobre las que no pienso opinar, porque cada grupo de trabajo es un universo con sus propias leyes físicas.

Pero déjame decirte algo: si sigues tratando ese sistema como una simple web interna para ser leída exclusivamente por ojos humanos, te estás quedando muy corto.

A día de hoy, debes asumir que el principal usuario de tu wiki a medio plazo no va a tener carné de identidad. Va a ser un agente de IA.

Piensa en modo skills.

Cualquier página de tu Confluence que describa un proceso debe ser tratada como una habilidad que facilite la automatización del trabajo de tu agente. Favorece el Markdown limpio sobre el formateado complejo con macros extrañas o PDFs adjuntos. Estructura la información pensando en una máquina.

Tratar tu documentación interna como un repositorio de skills compartido tiene dos ventajas fundamentales:

Automatización real y agéntica de procesos: Si tienes una página que detalla el welcome pack para los nuevos desarrolladores de tu equipo (entorno, repositorios, accesos OTP…), lo ideal es estructurarla como un recurso que un agente pueda consumir directamente para automatizar el setup completo de ese nuevo colega de forma autónoma.
Consistencia (o cómo reducir la varianza entre agentes): Uno de los grandes problemas del trabajo agéntico a día de hoy es que los agentes que usamos responden ante nosotros -sus carnihuesados amos-, pero no se comunican con los agentes de nuestros compañeros de equipo.

La consistencia entre los miembros de un equipo es, ahora mismo, prácticamente inexistente. Cada uno entrena a su bot como buenamente puede.

¿Y qué mejor contexto común que toda esa documentación que ya hemos construido para dar consistencia, en primer lugar, al trabajo humano? Concebir estos sistemas sabiendo que su primer consumidor será un agente es lo que te va a ayudar a marcar la diferencia.

Este consejo sirve para cualquiera, pero es una orden de búsqueda y captura para responsables de equipos. Tu gente ya está usando LLMs para casi todo. Incentivar un repositorio de skills compartido es la forma más sencilla de asegurar que la tarea salga como se espera, independientemente de quién se ponga a los mandos del agente.

[Imágenes: Jose Alcántara usando ChatGPT.]