Categoría: Innovación & Tendencias

Casos reales y reflexiones sobre cómo aterrizar IA, IoT y otras tendencias en entornos regulados (utilities, AAPP). De la idea al piloto con foco en valor de negocio y seguridad.

Publicado el

Vibe coding: la mejor forma de aprender lo que no hay que hacer

Mujer sonriente sentada en el suelo de su salón con un portátil, del que brotan enredaderas y cables que invaden la habitación como una jungla descontrolada, con un pequeño timón de barco oculto entre las plantas y un androide entregándole otro cable más

Es domingo por la tarde. Mi blog, seamos honestos, es una mezcla rara: una tarjeta de presentación muy cara y un laboratorio donde hago mis pruebitas. Últimamente el laboratorio está muy entretenido: llevo semanas construyendo una bóveda de conocimiento personal que ingesta artículos, los clasifica, genera grafos que conectan ideas entre autores distintos. Lo que empezó siendo una evolución razonable —antes solo editaba posts, ahora quiero que también me ayude a encontrar temas y a aprender— se ha convertido en un jardín. Uno de esos de los que cuesta salir.

De «hazme un script» a «no sé qué he decidido»

El patrón es siempre el mismo. Le pides algo sencillo: que te automatice la ingesta de un artículo. Funciona, así que le pides la clasificación. También funciona, así que vas a por el grafo de conocimiento. Y de ahí a la diarización de hablantes en transcripciones de YouTube —algo que no había tocado en mi vida— escrito todo en scripts de Python, un lenguaje que tampoco he programado nunca.

Claude te va proponiendo cosas que, en principio, parecen razonables. Y como no le dedicas mucho rato —esto es un proyecto de fin de semana, no de trabajo—, tampoco piensas mucho las cosas. Dices «vale, perfecto» y sigues. Ese «vale, perfecto» repetido veinte veces es el problema: te da una sensación de control que no es real. No sabes si lo que acabas de aprobar tiene sentido. Solo sabes que suena bien.

La resaca del domingo con prisa

Y entonces empiezan a aparecer las grietas. No se da cuenta de que la transcripción de un vídeo ya existe en YouTube y no hace falta generarla de nuevo. Cuando transcribes en local, a veces alucina y el resultado es sutilmente incorrecto. Los scripts de Python se han ido llenando de funcionalidad añadida sobre la marcha hasta convertirse en un batiburrillo que ni tú entiendes.

Al final, aprovechando la vuelta del modelo Fable (que es más listo), le pedí que le echara un vistazo a todo aquello, porque tenía la sensación de que se estaba desmadrando. Y, efectivamente, estaba desmadrado: media docena de scripts pequeños que se podían fusionar en un par de ellos, y más cosas.

Lo curioso no es que la IA se equivocara. Es que, como yo tampoco sabía lo suficiente, no me di cuenta de lo que se le había pasado. Vas a la deriva convencido de que llevas el timón, y solo cuando ya no te acuerdas de por qué decidiste algo —y le tienes que pedir a la propia IA que te documente lo que has hecho para no perderte— te enteras de que no lo llevabas.

Lo único que de verdad me está funcionando

De todo lo que he ido probando, una cosa sí ha demostrado su valor: usar OpenSpec para dejar por escrito, antes de implementar, qué se va a hacer y por qué. Parece burocracia de fin de semana, pero no lo es: queda documentada la decisión, así que la propia IA es capaz luego de recordar por qué se tomó, en lugar de que tengas que reconstruirlo tú de memoria (que es justo lo que no funciona cuando decides veinte cosas seguidas sin pararte a pensarlas).

En el trabajo esto no es opcional: ahí sí hay que leer los diseños, prestar atención a lo que la IA propone, no dejarse llevar por la velocidad. En un proyecto personal de fin de semana, en cambio, puedo tirar para adelante y pagar el precio después.

Por eso recomiendo el vibe coding

Con todo el mundo diciendo que no hay que hacer vibe coding, yo lo recomiendo, con un poco de sorna. Una vez. En algo pequeño y sin consecuencias reales. Vas a aprender en un fin de semana lo que ningún curso te va a enseñar de verdad: que la IA, por muchas cosas plausibles que te proponga, no sabe lo que tú no sabes. Y que la sensación de control que te da es, precisamente, el riesgo.

Moraleja

El vibe coding no es peligroso porque la IA se equivoque de vez en cuando. Es peligroso porque tú, si no sabes lo suficiente, no te enteras de cuándo se equivoca. Hazlo una vez, en un proyecto sin nada que perder, y sabrás exactamente por qué no deberías volver a hacerlo así en algo que sí importa.

¿Te ha pasado alguna vez sentir que controlabas tu propio código —o tu propio proyecto— y en realidad ibas a la deriva? Cuéntamelo en LinkedIn.

Relacionados sugeridos

Publicado el

La IA y la vuelta a la época de Lotus 1-2-3 y dBASE III

Oficina corporativa de los años noventa con monitores CRT, archivadores metálicos y empleados con ropa de la época, junto a un androide moderno integrado como un compañero más.

Hay una época de la informática que recuerdo con cierta mezcla de nostalgia y prevención —no la viví profesionalmente, pero sí a través de mi padre y mis tíos—: cuando un departamento gestionaba sus cosas en dBASE III, otro lo hacía con Lotus 1-2-3, y el departamento de informática se dedicaba a su AS-400.

Esto me ha venido a la cabeza estos días. Esta semana me construí un script de transcripción local. No porque las alternativas del mercado sean malas, sino porque ninguna encajaba exactamente en mi flujo de trabajo.

Necesitaba algo que procesase el audio en local, a coste cero, con el ordenador que tengo. Lo mismo me está pasando con mi sistema de gestión de la bóveda de conocimiento. He probado Graphify, pero me tenía que adaptar a su forma de funcionar así que estoy montándome mi propia solución.

Hace unos meses escribí en Hábitos viejos con herramientas nuevas sobre cómo la reutilización fue durante décadas la respuesta racional a la escasez de recursos: construir algo a medida era caro, así que hacerlo genérico tenía sentido. Ese razonamiento ya no aplica de la misma manera.

No soy el único

Javier Garzás, consultor de transformación digital con más de 20 años en el sector, está hablando de que su equipo está haciendo desarrollos a medida con IA. Hay más gente en la misma dirección: personas que están cancelando suscripciones que antes pagaban sin cuestionarlas y construyendo sus propias alternativas adaptadas a su caso concreto.

En mi caso, que trabajo solo desde casa, esto no tiene ningún riesgo organizativo. Si mi script de transcripción solo me sirve a mí, ese es exactamente el objetivo. Puedo construir herramientas sin ninguna vocación de escala.

El problema llega cuando esto empieza a ocurrir dentro de una empresa.

La historia que ya vivimos (y estamos a punto de repetir)

Nadie planeó usar Lotus 1-2-3 y dBASE III así. Ocurrió porque construirse algo propio era lo más rápido y funcional en ese momento. El problema llegaba cuando parte de la gestión de la empresa estaba en la sombra: sin copias de seguridad, sin controles, sin que nadie del departamento de informática supiera que existía. Hoy lo llamaríamos Shadow IT.

Con la IA, estamos volviendo ahí. Pero a otra escala.

Antes, hacer tus propias soluciones requería cierto conocimiento técnico: instalar una aplicación SaaS no autorizada, registrarse en un servicio externo que IT no había aprobado. Ahora, cualquier empleado puede pedirle a Claude que le construya un script, una automatización o una integración que no pasa por ningún proceso de validación técnica. Cada uno con su solución. Nadie con visión de conjunto.

La gobernanza que viene

La respuesta obvia es prohibirlo. Pero ya sabemos cómo terminó esa historia con el BYOD, con el cloud o con WhatsApp en entornos corporativos: la gente sigue usando lo que le resulta más cómodo y productivo, solo que fuera del radar.

Lo que sí puede funcionar es una gobernanza que entienda la nueva realidad: construir software a medida ya no es una excepción técnica, sino una práctica habitual que se va a extender. El objetivo no es impedirlo, sino encauzarlo.

En la práctica, eso implica tres cosas: principios claros sobre dónde puede desplegarse código generado con IA; criterios para distinguir un script personal de una solución corporativa encubierta; y capacidad para detectar cuándo algo que empezó como una automatización individual se ha convertido en infraestructura crítica que solo entiende quien la construyó. Eso no es una prohibición. Es criterio aplicado a escala.

La gobernanza de la IA va a ser muy importante. Pero tendrá que ser flexible, porque imponer soluciones rígidas no tiene sentido cuando lo que se está viendo es que es muy barato y muy rápido construirte algo a medida.

Moraleja

La IA ha democratizado el traje a medida. Eso es una buena noticia para las personas con criterio suficiente para aprovecharlo. Para las organizaciones, es una nueva fuente de riesgo que todavía no está en la mayoría de los planes de gobernanza. La pregunta no es si tus empleados están construyendo soluciones propias con IA. Es si sabes cuáles son, dónde están y qué pasaría si mañana dejasen de funcionar.

Es la pregunta que pocas organizaciones se están haciendo todavía. ¿La tuya sí? Cuéntame en LinkedIn.

Relacionados sugeridos

Publicado el

Soberanía de IA: la mía cabe en un Mac Mini

Androide humanoide trabajando con un portátil en una mesa de madera, con una txapela vasca negra apoyada sobre la mesa.

He estado en el Open LLM Basque Day. Ponencias, debates, café con unas vistas excepcionales desde la planta 29 de la Torre Iberdrola. Y una palabra que aparecía en cada conversación: soberanía.

Soberanía tecnológica. Soberanía del dato. Modelos que no dependan de Washington ni de Pekín. En el mismo Bilbao, Elhuyar lleva décadas en tecnologías del lenguaje y ya tiene Llama-Eus. En HITZ, el centro de la EHU, adaptan modelos de Meta para euskera. En España, Alia es la infraestructura pública de IA del Gobierno: modelos abiertos en castellano y lenguas cooficiales —incluido el euskera—, entrenados en MareNostrum 5. En Suiza entrenan Apertus con 11.000 GPUs. El ecosistema está más cerca de lo que parece, y el debate es completamente legítimo.

Pero cuando volvía a casa, pensaba en mi versión de la soberanía. Que tiene bastantes menos GPUs.

De ChatGPT a Claude: lo que no he contado

Hace un año escribí sobre por qué volví a escribir en el blog y cómo un GPT personalizado con el corpus de mis posts me lo había puesto fácil. Lo que no he contado es todo lo que pasó después.

ChatGPT funciona bien para muchas cosas, pero hay un límite que me fue resultando incómodo: todo lo que le das vive en sus servidores. Tu corpus de textos, tus documentos, tus conversaciones. Eso no es soberanía. Es comodidad. Y no son lo mismo.

El salto a Claude no fue repentino. Fue gradual, y vino acompañado de un replanteamiento más profundo de cómo gestiono el conocimiento.

El experimento que no funcionó (y lo que aprendí de él)

En mayo escribí sobre el ruido que genera la IA cuando la usas sin criterio. Sin nombrarlo, hablaba de un sistema que se había puesto de moda: la idea de que un LLM puede actuar como mantenedor de una wiki personal, capturando todo lo que lees, generando resúmenes y cruzando referencias de forma automática.

La idea venía de Andrej Karpathy. Técnicamente sólida. Conceptualmente atractiva.

El problema fue la práctica: el sistema generaba tanto output —resúmenes, síntesis, notas automáticas— que acabé gestionando la IA en lugar de gestionar el conocimiento. Más ruido, no más señal. Lo quité.

Del experimento, sin embargo, me quedé con algo que sí tenía sentido: la búsqueda local.

La bóveda: manual, pero mía

Lo que monté en su lugar es más modesto y más deliberado.

Una bóveda en Obsidian donde archivo lo que leo —artículos, ponencias, transcripciones— con resúmenes generados por agentes de Claude. No es automatización ciega: cada activo pasa por un proceso que yo controlo. El LLM hace el trabajo tedioso de resumir y cruzar referencias; yo dirijo qué entra, qué se descarta y cómo se organiza.

La pieza clave que conservé del concepto original es QMD: un motor de búsqueda que funciona localmente, sin nube, sin API externa. Combina búsqueda por palabras clave y búsqueda semántica, y el índice vive en mi máquina. Cuando Claude Code necesita contexto para redactar un post o detectar conexiones entre ideas, consulta QMD. Sin enviar nada a ningún servidor externo, ni consumir tokens.

Eso es mi soberanía. No un modelo propio. No 11.000 GPUs. Un índice local en un Mac Mini.

Lo que ha cambiado en el flujo editorial

El resultado práctico es que el blog ya no funciona como antes.

Antes: una idea → un audio → ChatGPT → un post. Rápido, pero sin memoria. Cada artículo salía de la nada.

Ahora: una idea conecta con lo que he leído, con las ponencias que he procesado, con los autores que he archivado. Este mismo artículo sobre soberanía tiene contexto de la ponencia que escuché esta semana, cruzado con un documento que procesé hace mes y medio sobre gestión de conocimiento con LLMs. Sin buscar manualmente nada. La diferencia no es de velocidad, es de profundidad.

El sistema tiene memoria. Y esa memoria es local.

Sé que a escala de empresa esto suena a bricolaje. Y técnicamente lo es. A veces la mejor forma de entender un patrón es montarlo tú mismo a escala mínima. Pero el patrón es el mismo que se discutía en el Open LLM: quién controla los datos, quién puede consultarlos, quién decide qué se archiva.

Moraleja

La soberanía de IA no es solo un problema de estados y grandes organizaciones. Existe también a escala personal, y las implicaciones son parecidas: ¿dónde vive tu conocimiento? ¿Qué pierdes si cambias de proveedor?

Mi versión es modesta. Pero cuando pasé de ChatGPT a Claude, no perdí nada. Porque nada dependía de la nube.

A veces la soberanía no requiere 11.000 GPUs. Requiere criterio y un par de horas montando algo a mano.

¿Tienes algún sistema propio para gestionar lo que aprendes, o lo delegas todo a herramientas en la nube? Cuéntamelo en LinkedIn

Relacionados sugeridos

Publicado el

El médico ya sabe dónde derivarte. ¿Cuánta IA necesitas realmente?

Doctora frente a un ordenador con una interfaz médica en pantalla, seleccionando manualmente un centro de derivación de un desplegable de autocompletado.

Hace años estaba trabajando en una aplicación de sanidad. Teníamos que diseñar una pantalla para que el médico pudiera solicitar una radiografía, y uno de los campos era el centro al que derivar al paciente.

Como buenos informáticos —con ese impulso natural de automatizar todo lo que se mueve—, propusimos que el sistema rellenara ese campo automáticamente. Teníamos unas tablas con los centros disponibles, los criterios de derivación… parecía sencillo y eficiente.

El responsable funcional nos paró en seco.

«El médico ya sabe a qué centro tiene que ir el paciente», nos dijo. «Si automatizamos demasiado, se nos puede escapar alguna casuística que no controlamos, porque tampoco conocemos todas las posibilidades. Al final acabamos poniendo límites donde no deberían estar. Lo que tenemos que hacer es facilitarle la selección: favoritos, autocompletado. Nada más.»

Tenía razón. Y esa conversación lleva años rondándome la cabeza.

La IA es solo la siguiente capa

Lo que estamos viviendo con la inteligencia artificial es, en esencia, un salto más en el nivel de automatización. Un salto enorme, eso sí, pero con la misma trampa de siempre: la tentación de automatizarlo todo.

Y el riesgo ahora es mayor. Porque la IA no es determinista. No hace lo mismo dos veces de la misma manera. Puede alucinar —ese término tan gráfico del argot técnico, que describe cómo el modelo inventa algo con total convicción—, y eso añade una variable que las tablas de un sistema de sanidad nunca tenían.

Cuanto más se automatiza sin supervisión, más se amplía la superficie donde algo puede salir mal de una forma que no habíamos previsto.

Humano en el bucle, pero al mando

Hay una frase que se usa mucho últimamente: human in the loop. Suena bien. Ya escribí sobre quién es realmente ese humano y qué capacidad tiene de validar, porque a veces el control se convierte en decorado: el humano está ahí, pero sin entender lo que está supervisando.

Lo que yo hago va un paso más atrás: estar en el bucle, y al mando desde el principio.

No como espectador de lo que la IA decide, sino como quien dirige el proceso y delega tareas específicas —las más mecánicas, las más repetitivas— con plena conciencia de lo que está delegando y por qué.

He probado herramientas y flujos de trabajo con IA que prometían mucho, y he quitado los que no me convencían. No porque la tecnología fallara, sino porque no me daban esa sensación de control y al final era yo el que me tenía que adaptar a la herramienta.

El ritmo lo marcan las personas, no la tecnología

Hay un factor que a veces se pasa por alto en esta conversación: el rechazo.

Hay escepticismo hacia la IA, y no es irracional. Es la respuesta natural de quien ve una tecnología que cambia las reglas del juego y no sabe bien si está de su lado o en su contra.

Si automatizamos demasiado pronto —antes de que la gente haya podido interiorizar cómo funciona y qué controla—, lo único que conseguimos es alimentar ese escepticismo. La persona no entiende lo que pasa, no se fía, y acaba rechazando la herramienta.

La adopción real no la marcan las capacidades técnicas. La marcan las personas que tienen que usar esa tecnología cada día.

Cuando alguien entiende que la IA trabaja para él —que la controla, que puede corregirla, que no va a remolque de ella— el rechazo se convierte en curiosidad. Y la curiosidad, con el tiempo, en confianza.

Y entonces sí: se puede ir automatizando más. Gradualmente, con evidencias, con esa confianza ya construida.

Moraleja

El funcional de aquella pantalla de sanidad lo resumió sin saberlo: a veces la mejor automatización es la que no se hace. Lo más inteligente es facilitarle al humano que haga lo que ya sabe hacer, en lugar de intentar sustituirlo.

La IA permite cosas que antes eran impensables. Pero la velocidad a la que se adopta no la decide la tecnología: la decide la persona que tiene que usarla.

El objetivo no es que la IA haga más, sino que el humano haga mejor. Y para eso, el humano tiene que seguir llevando el volante.

¿En tu entorno habéis automatizado más de la cuenta y habéis tenido que dar marcha atrás? Cuéntamelo en LinkedIn

Relacionados sugeridos

Publicado el

Una camisa marrón, la IA y la relación que no te esperas

Hombre examinando una camisa de lino marrón en una tienda de ropa luminosa, con un smartphone sobre el mostrador en primer plano desenfocado.

A principio de temporada me pasé por la tienda donde suelo comprar las camisas. Tenían para el verano una colección de lino marrón. Marrón oscuro, terroso, muy de otoño.

Le comenté al dependiente: «A saber cómo eligen esto para verano.» Me pareció un color equivocado, pesado para la época. No lo compré.

Meses después, escuchando un podcast sobre imagen personal que no tenía nada de tecnológico, me encontré con la respuesta. Y resultó que tenía que ver con la inteligencia artificial y me voló la cabeza porque no era por lo que seguramente estés pensando ahora mismo.

El instituto que decide el color del año

Pantone es un sistema de codificación de colores. Si dices PANTONE 17-1230, cualquier diseñador del mundo sabe exactamente de qué marrón hablas. Es lo que tiene haber tenido que decorar mi casa, saber que es el Pantone.

Desde 1999, el Pantone Color Institute anuncia cada año el «color del año»: una elección que no es arbitraria, sino el resultado de meses de investigación sociológica. El objetivo no es dictar qué debería estar de moda, sino observar qué está sintiendo la sociedad y reflejarlo.

Para hacer esa lectura, Pantone trabaja con cazadores de tendencias (coolhunters): profesionales con formación en diseño, sociología, psicología y marketing que rastrean señales culturales en todo el mundo. No solo moda: arte, gastronomía, música, movimientos sociales, arquitectura. El color que eligen es, más que una predicción, un diagnóstico del estado de ánimo colectivo.

Y hay un detalle que explica bien mi camisa de principio de temporada: entre que Pantone anuncia el color y que ese color llega masivamente a las tiendas, pasa aproximadamente un año. La industria de la moda trabaja con ese adelanto. Lo que compras hoy fue decidido el año pasado.

Por qué el marrón tierra en 2025

El color del año 2025 fue Mocha Mousse (PANTONE 17-1230): un marrón suave y cálido con matices de chocolate y tierra húmeda. Y la justificación que dio Pantone fue exactamente la que describía el podcast: una búsqueda global de lo esencial, una reacción a la saturación visual y digital, un deseo de reconectar con lo natural y auténtico.

El hilo conductor es claro: a medida que la inteligencia artificial se ha instalado en el día a día, generando un aluvión de contenido, herramientas y cambios acelerados, algo en la sociedad ha respondido buscando lo contrario. Menos pantalla, más textura. Menos algoritmo, más tierra. Los colores vibrantes y sintéticos ceden ante la paleta orgánica.

Los cazadores de tendencias no predicen caprichos estéticos: observan tensiones sociales reales. Y una de las más claras de los últimos años es esta: la tecnología avanza tan deprisa que nos cansa, y esa fatiga se refleja incluso en los colores que queremos llevar.

2026: el blanco como pausa

La progresión continúa. El color del año 2026 es Cloud Dancer, un blanco roto muy suave. Es histórico: la primera vez desde que se instauró esta tradición en 1999 que Pantone elige un blanco puro.

Laurie Pressman, vicepresidenta del Pantone Color Institute, lo explicó así: «Buscamos un respiro, buscamos alivio; hay una desconexión emocional, una sobreestimulación visual. Solo queremos dar un paso atrás.»

Del marrón tierra al blanco. De volver a las raíces a hacer una pausa total. Son dos respuestas distintas a la misma presión acumulada, y forman una progresión que tiene mucho sentido visto en retrospectiva.

Lo que ya estamos viendo en el sector TI

Los cazadores de tendencias observan esa presión desde la moda. Pero la misma dinámica lleva tiempo operando en el mundo de la tecnología, y ahí no hace falta esperar al color del año para notarlo.

Las empresas de TI ya están notando lo que la IA mueve por dentro: procesos que se aceleran, perfiles profesionales que cambian, tareas que se redistribuyen. La pregunta sobre cuántos puestos de trabajo se verán afectados está sobre la mesa, aunque nadie tenga todavía una respuesta cerrada. Esperemos que la transición sea mejor de lo que algunos auguran.

Lo que sí es claro es que el impacto de la IA no se limita a los sectores donde la buscamos. Si está influyendo en el color de la ropa de verano, está influyendo en sitios que todavía no hemos pensado. Y como siempre con la tecnología, la clave es entender qué está cambiando antes de que el cambio te llegue de frente.

Yo acabé comprando una camisa blanca. Una marrón para el otoño si la sacan para la colección de otoño invierno cae fijo.

¿Tú has notado la IA en algún sitio donde no la esperabas? Me interesa saberlo. Te leo en LinkedIn.

Relacionados sugeridos

Publicado el

Hábitos viejos con herramientas nuevas: ¿sigue teniendo sentido hacer cosas genéricas?

Un hombre a punto de comprar un traje estándar se gira al ver que un sastre androide ofrece ropa a medida al mismo precio, en una sastrería luminosa y elegante.

Hace unas semanas estaba diseñando un pequeño sistema para automatizar una tarea repetitiva. A los cinco minutos ya estaba añadiendo parámetros para que sirviera «también en otros casos». Me detuve. ¿Para quién estaba haciendo eso?

Tengo un hábito que me ha servido durante décadas: cuando algo cuesta construirse, hazlo reutilizable. No sé exactamente cuándo lo interioricé, pero lleva tanto tiempo ahí que casi no lo veo. Últimamente he empezado a preguntarme si sigue siendo la respuesta correcta. O si simplemente lo estoy aplicando por inercia.

La lógica original era impecable. Si construir una solución a medida era caro, había que diseñarla de forma que sirviera para varios casos de uso. Plantillas parametrizables. Componentes configurables. Lógica condicional: «si el proyecto es de tipo A, haz esto; si es de tipo B, aquello». La reutilización era la respuesta racional a la escasez de recursos.

El problema de lo genérico

Cuando algo tiene que servir para muchos casos, inevitablemente se complica. Aparecen condiciones, excepciones, opciones que «depende». Y el resultado, aunque técnicamente reutilizable, traslada la complejidad al usuario: ahora eres tú quien tiene que interpretar qué aplica a tu situación y qué no.

Durante décadas ese coste fue aceptable porque la alternativa —construir algo completamente a medida— era cara, lenta o directamente inviable en el día a día.

Pero eso ha cambiado.

Mi flujo de publicación, como ejemplo

Tengo un sistema para gestionar el proceso de creación y publicación de entradas en mi blog. No es especialmente complejo, pero sí está completamente adaptado a cómo trabajo yo: tiene en cuenta mis temas habituales, artículos y vídeos que me han inspirado, mi tono de voz, los objetivos que persigo con cada publicación. Incluso el hecho de que no me preocupa especialmente el SEO —porque la mayor parte de mis lectores llegan a través de LinkedIn, no de buscadores— es algo que está integrado en cómo está construido ese flujo.

No tiene sentido para nadie más, y lo digo sin matices. No porque sea un sistema secreto, sino porque está construido sobre mi contenido, mis prioridades y mi forma de escribir. Intentar hacerlo genérico para que le sirviera a otra persona significaría añadir tantas capas de configuración y condiciones que dejaría de ser útil para cualquiera de los dos.

Y lo interesante es que construirlo a medida no fue especialmente costoso. Fue más rápido y más útil que buscar una solución estándar y adaptarla.

La IA invierte la ecuación

Ahí está el cambio que creo que no estamos terminando de asimilar: con las herramientas de inteligencia artificial actuales, generar algo ajustado a tu caso concreto ya no es caro.

Si tienes el criterio —si sabes lo que necesitas— puedes obtener una solución adaptada a tu contexto en mucho menos tiempo del que llevaría entender y configurar la versión genérica. La restricción que justificaba la genericidad ha desaparecido en muchos casos. El cuello de botella ya no es construir: es saber qué quieres construir.

Cuando los sistemas se diseñan para generar, no para ser genéricos

Lo veo también en cómo están diseñadas las herramientas que más uso. No están construidas para cubrirlo todo: están construidas para ayudarte a construir lo que tú necesitas. El Skill Creator de Claude Code es un buen ejemplo: en lugar de un sistema que contempla todos los casos de uso posibles, tienes algo que genera la solución específica para tu contexto. Llaman a esto meta-agentes —sistemas que crean otros sistemas—. El nombre es nuevo; la lógica, no: si generar algo adaptado ya no cuesta más que usar algo genérico, ¿por qué conformarse con lo genérico?

El hábito que merece revisarse

No estoy diciendo que la reutilización haya muerto. Hay contextos donde sigue siendo la estrategia correcta: cuando los requisitos son estables y compartidos, cuando el volumen justifica la inversión, cuando la solución estándar es suficientemente buena para el caso.

Lo que sí creo es que necesitamos cuestionar cuándo aplicamos ese hábito por inercia. Cuándo estamos construyendo algo genérico no porque sea lo más útil, sino porque es lo que siempre hemos hecho.

La IA no nos quita la necesidad de pensar. Al contrario: nos exige tener más claro qué queremos, porque sin ese criterio no se puede aprovechar la capacidad de generar soluciones adaptadas. Pero si tienes ese criterio, la genericidad como respuesta por defecto empieza a cuestionarse seriamente.

Cuando cambia la restricción, cambia la respuesta

Los hábitos que construimos a lo largo de años tienen una lógica detrás. La reutilización, la parametrización, las soluciones genéricas: todo eso nació de una restricción real.

Pero cuando cambia la restricción, merece la pena preguntar si la respuesta sigue siendo válida.

Yo llevo haciéndome esa pregunta con más frecuencia últimamente. No siempre la respuesta me gusta.

Relacionados sugeridos

¿Tienes algún hábito de este tipo —algo que construiste con toda la lógica del mundo y que ahora te preguntas si todavía tiene sentido? Me interesa leer tu perspectiva en LinkedIn.

Publicado el

Usas más IA pero ¿produces más valor?

na mujer y un androide concentrados miran con fastidio a otro androide caótico rodeado de pantallas y notificaciones

En los últimos meses es difícil salir de una reunión sin que alguien mencione la IA. Tu equipo la usa. Tú la usas. Probablemente tienes varias herramientas activas en este momento.

Pero si te pregunto cuántas de esas herramientas están generando valor real — no ahorro de tiempo aparente, no automatización de tareas que ya funcionaban — ¿qué me responderías?

El problema no es la IA. El problema es que nadie nos ha enseñado a decidir cuándo no usarla.

Cada herramienta que activas tiene un coste que va más allá de la suscripción mensual: consume atención, genera outputs que alguien tiene que revisar, y crea una dependencia que es difícil de cuestionar una vez instalada. A eso lo llamo ruido. Y el ruido tiene un precio que no aparece en ninguna factura.

El ruido más peligroso no es el que ves. Es el que parece útil.

Hace unos meses implementé un sistema que se había puesto de moda en redes y comunidades técnicas. La idea era atractiva: la IA como memoria activa, capturando contexto, generando resúmenes, manteniéndome al día sin esfuerzo. Cuando algo genera ese nivel de conversación, merece la pena probarlo.

El resultado fue el contrario de lo que esperaba.

El sistema funcionaba: técnicamente hacía lo que se suponía que tenía que hacer. Pero generaba tal volumen de contenido — resúmenes, síntesis, notas automáticas — que acabé dedicando más tiempo a gestionar ese output que a trabajar con la información real. Más ruido, no más señal.

Lo quité. Y volví a algo más manual, más quirúrgico: uso la IA para preguntas concretas, y Obsidian para gestionar el conocimiento. Menos automatización, más criterio.

Usar la IA con criterio significa hacerse una pregunta antes de activar cualquier herramienta: ¿qué problema concreto estoy resolviendo, y es este el mejor instrumento para resolverlo?

Parece obvio. Pero en la práctica, la presión del hype invierte el orden: primero adoptamos la herramienta, luego buscamos el problema que justifique su uso.

El criterio que me ha funcionado es simple: la IA aporta valor cuando reduce fricción en algo que ya hacía con esfuerzo. No cuando automatiza algo que funcionaba, no cuando genera contenido que nadie va a revisar, no cuando sustituye el juicio por la velocidad.

Como escribí hace unos días, el cuello de botella ya no es la ejecución sino la calidad de la idea que le das al modelo. Y para tener buenas ideas necesitas criterio, no más herramientas.

La herramienta correcta para cada trabajo no siempre es la más sofisticada. A veces es una nota, una conversación, o simplemente no hacer nada.

No te estoy pidiendo que uses menos IA. Te estoy pidiendo que te hagas una pregunta antes de usarla: ¿esto me aporta señal o me genera ruido?

Si la respuesta es ruido, tienes permiso para no usarlo. Aunque todo el mundo lo esté usando. Aunque alguien en LinkedIn diga que es imprescindible.

El criterio es la habilidad más escasa en este momento. Y curiosamente, es la que la IA no puede darte.

¿Cuál es la herramienta que más ruido te genera y que aún no te has atrevido a quitar? Cuéntamelo en LinkedIn.

Relacionados sugeridos

Publicado el

¿Qué haces cuando se te va la IA?

Dos androides recogen sus cosas en cajas de cartón mientras sus compañeros humanos los observan desde sus puestos de trabajo en una oficina moderna

He visto cómo en una semana se marchaba la fila entera de una mesa corrida. No uno, no dos: todos. Cuando pasa algo así, la organización lo nota. Hay un vacío, hay que redistribuir carga, hay que reclutar, hay que formar. Es duro, pero las empresas saben cómo gestionarlo. Tienen protocolos. Tienen planes. Llevan décadas aprendiendo a gestionar el riesgo de que una persona se vaya.

Lo que no han aprendido todavía es qué hacer cuando se les va la IA.

La IA como compañero de trabajo

Para entender el problema de la gobernanza de la inteligencia artificial, me resulta útil hacer un símil sencillo: tratarla como si fuese una persona.

Piénsalo así. Cada persona de tu equipo tiene ahora, o tendrá muy pronto, un asistente de IA. No una herramienta genérica que todos comparten, sino algo que les ayuda a ellos específicamente: a redactar, a analizar, a buscar, a resumir, a revisar. Una especie de compañero invisible que, de momento, no pide vacaciones ni se queja del café. Pero que tampoco negocia.

Si ese «compañero» fuese una persona de carne y hueso, ya sabrías qué hacer si un día te dice que se quiere ir. Tienes conversaciones, negocias condiciones, buscas sustituto, cubres temporalmente las tareas. Es un proceso conocido, con fricciones, pero manejable.

El problema es que la IA no funciona así.

El riesgo que nadie ha puesto en el plan de continuidad

Cuando el compañero de IA de todos tus empleados depende del mismo proveedor externo, el riesgo deja de ser individual para convertirse en sistémico.

Si ese proveedor decide subir sus precios un 40%, no te afecta a una persona: te afecta a todas a la vez. Si hay una restricción geopolítica — algo que, como hemos visto con los aranceles y las tensiones tecnológicas entre bloques, ya no es ciencia ficción — no pierdes un perfil: pierdes la capa de asistencia de toda tu organización de golpe. Y lo más importante: no puedes negociar. No hay una conversación que tengas. No hay palanca.

Con una persona, siempre hay margen de maniobra. Con un proveedor de IA al que dependes estructuralmente, muy poco.

En el congreso ApplAI de este año esto se mencionó de forma explícita: la dependencia de modelos en la nube crea un ciclo de vida que la empresa no controla. Cualquier cambio en ese entorno — técnico, comercial o regulatorio — puede afectar seriamente al funcionamiento de sistemas que ya están integrados en el día a día. Y el riesgo geopolítico está ahí: cualquier día de estos, un problema de aranceles en el mundo de la tecnología puede dejarte con un servicio al que no puedes acceder.

La pregunta que pocas empresas se han hecho

Todas las organizaciones tienen un plan de recuperación ante desastres para sus sistemas de IT. Tienen procedimientos para cuando cae el servidor, para cuando falla la base de datos, para cuando hay un incidente de ciberseguridad.

¿Tienen uno para cuando se quedan sin IA?

¿Cuántas personas de la organización dependen hoy de un único proveedor de IA? ¿Qué procesos críticos están apoyados en esa dependencia? ¿Cuánto tiempo tardarían en migrar a otro proveedor, o en operar sin esa capa de asistencia? ¿Se ha evaluado siquiera?

Estas son las preguntas que la gobernanza de la IA debería estar respondiendo. No como un ejercicio teórico, sino con la misma seriedad con la que se planifica la continuidad del negocio ante cualquier otro riesgo operativo.

Gobernanza no es un formulario de cumplimiento

Cuando se habla de gobernanza de la IA en muchas organizaciones, el debate se va rápidamente hacia la ética, la regulación o los comités de supervisión. Todo eso es necesario. Pero hay una dimensión más inmediata que a menudo queda fuera del foco: la gestión de la dependencia tecnológica.

Los directivos que han implantado IA en sus organizaciones con más criterio no la tratan como una herramienta más que se conecta y ya. La gobernanza para ellos significa tener claro el marco de control de riesgos desde el principio: qué decisiones se automatizan y cuáles requieren supervisión humana, qué datos salen de la organización y cuáles no, qué ocurre si el proveedor cambia las condiciones.

Eso no es burocracia. Es anticiparse.

Lo que aprendí viendo marcharse a una fila entera

Cuando una fila de compañeros se va en una semana, el impacto se nota. Pero la organización sobrevive porque el conocimiento, aunque distribuido y aunque costoso de recuperar, no desaparece del todo. Queda algo: los procesos documentados, la memoria institucional, los compañeros que se quedan.

Con la IA, si la dependencia está mal construida, no queda nada. O peor: queda un vacío donde antes había velocidad, y una organización que no sabe cómo operar sin ella porque nunca se lo planteó.

La buena noticia es que no es difícil de formular: ¿qué hacemos si mañana nos quedamos sin IA?

Las organizaciones que hayan pensado en esa respuesta antes de necesitarla son las que van a navegar los próximos años con más solidez. No las que adoptaron más rápido, sino las que adoptaron con criterio.

Eso es gobernanza. El resto es decoración.

Relacionados sugeridos

¿Tu organización tiene un plan de continuidad para la IA? Cuéntamelo en LinkedIn.

Publicado el

Antes del prompt, el ágora

Cinco participantes debaten en un ágora griega: cuatro personas con atuendo clásico y un androide con toga, integrado en el círculo como un igual.

Esta semana he estado en el congreso ApplAI 2026 y salí con una idea en la cabeza que no me ha abandonado. Javier del Ser, investigador de Tecnalia con una visión especialmente clara sobre IA y sociedad, cerró su ponencia con una recomendación que sonaba casi anacrónica: recuperar el concepto del ágora griega.

El ágora era la plaza pública donde los ciudadanos se reunían a debatir, a proponer ideas y a someterse al escrutinio de los demás. No para llegar a un acuerdo fácil, sino para que las ideas sobrevivieran al roce. Javi lo propuso como antídoto a la sobredependencia de la IA. Yo salí pensando en otra cosa: en que el ágora no es solo un freno al exceso, es la fuente de ventaja competitiva que se nos está pasando por alto.

Cualquiera puede pedir a la IA que desarrolle una idea

Y la IA lo hace bien. Muy bien. Le das un concepto a medio cocinar y te devuelve una estructura, argumentos, ejemplos y hasta un resumen ejecutivo. En minutos. Y gratis, o casi.

El problema es que eso lo puede hacer cualquiera. Tu competencia, tu colega del equipo de al lado, tu cliente. La barrera para desarrollar una idea ha desaparecido casi por completo.

Entonces, ¿dónde está ahora el diferencial?

El cuello de botella se ha desplazado

Si todos podemos pedirle a la IA que desarrolle nuestras ideas con la misma facilidad, lo que marca la diferencia ya no es quién ejecuta mejor. Es qué ideas le pedimos que desarrolle.

Y ahí es donde entra en juego algo que la IA no puede hacer por ti: trabajar la idea antes de lanzarla. Someterla a preguntas incómodas. Dejarla expuesta a alguien que no esté de acuerdo contigo. Escuchar a quien ve el problema desde otro ángulo.

Eso, en esencia, es el ágora.

Tus compañeros de trabajo como ventaja competitiva

He visto muchas veces cómo funciona esto en la práctica. Una persona llega con una idea, se sienta frente a la IA y en veinte minutos tiene un documento impecable. Otro, antes de abrir el ordenador, la comenta con dos compañeros, recibe objeciones, incorpora matices que no había considerado, y solo entonces se sienta a escribir el prompt.

El resultado no tiene nada que ver. No porque la IA del segundo sea mejor, sino porque la idea que le pasó era mejor.

Lo que antes era tiempo «perdido» debatiendo en la pizarra o en la máquina del café es, hoy, el trabajo de mayor valor que puedes hacer antes de abrir el modelo.

El riesgo de saltarse el ágora

Javier del Ser habló en ApplAI del peligro de la «caverna digital de Platón»: si delegamos cada vez más el pensamiento en la IA, y esa salida acaba siendo el entrenamiento de los modelos del futuro, terminamos todos consumiendo una representación empobrecida del mundo. Los humanos como sombras dentro de la caverna, por decirlo con su metáfora.

Pero hay una versión más inmediata y menos filosófica del mismo problema: si siempre vas directo al prompt sin haber debatido antes, las ideas que produces se parecen cada vez más a las de todos los demás que también van directo al prompt. La IA iguala la ejecución. El debate es lo que diferencia la entrada.

La nueva pregunta no es «¿cómo le pido esto a la IA?»

Es «¿con quién debería discutir esto antes?»

El ágora no tiene que ser una plaza griega ni una reunión formal. Puede ser una conversación de diez minutos, un mensaje en el grupo del equipo, una pregunta lanzada a alguien que sabes que va a ponerte a prueba. Lo que importa es el escrutinio previo. La incomodidad intelectual que afila la idea antes de que llegue al modelo.

Después de veinticinco años en proyectos tecnológicos, he aprendido que las mejores soluciones rara vez nacen del genio solitario. Nacen del roce. Y ahora que la IA se encarga de la ejecución, el roce es más valioso que nunca.

Relacionados sugeridos

💬 ¿Tienes ya tu ágora? ¿O vas directo al prompt? Lo comentamos en LinkedIn.

Publicado el

Cuando los agentes aceleran todo: qué le pasa a tu equipo técnico

Dos desarrolladores de diferentes géneros y etnias colaborando en una oficina moderna con múltiples pantallas de código y paneles de integración de IA, rodeados de plantas y arte abstracto.

Tradicionalmente, mantener una aplicación en versiones antiguas de sus frameworks y librerías era caro. Muy caro. Migrar de Java 8 a Java 17, o saltar de un framework viejo a uno moderno, requería tiempo, dinero y riesgo que muchas organizaciones preferían no asumir. Era más barato dejar el sistema tal cual estaba.

Así que pasaban los años. Y mientras el mundo avanzaba, tú seguías en tu aplicación. Eras muy productivo ahí: sabías dónde estaba todo, conocías sus rincones, sus peculiaridades. Era tu dominio.

La IA convierte la migración en algo viable

Ahora imagina que esos agentes de IA pueden migrar esas aplicaciones automáticamente. No solo a versiones más nuevas del mismo framework, sino incluso entre tecnologías. De Java a Go, de un ORM viejo a Hibernte moderno, de arquitectura monolítica a microservicios.

De repente, ese coste que justificaba «no tocar nada» desaparece.

Y con él desaparece también algo que nadie menciona: el lastre económico que permitía vivir de lo que ya sabías. Si migrar era caísimo, entonces seguías manteniendo la aplicación vieja, y tú seguías siendo el único que sabía cómo funcionaba. Eras productivo, eras necesario, y ese conocimiento era específico.

Pero si migrar se vuelve barato —casi gratis—, entonces la pregunta ya no es «¿modernizamos?» sino «¿por qué no?» Y la respuesta a eso recae en los equipos técnicos.

El ciclo de mantenimiento se acelera

Aquí es donde las cosas se ponen incómodas. Si antes podías vivir cinco, diez, quince años de una aplicación en versión antigua, ahora los ciclos se comprimen.

Ya no es «Java 8 hasta la jubilación». Ahora es «Java 8, luego Java 11, luego Java 17». Con cada salto viene no solo una nueva sintaxis: vienen nuevos patrones, nuevas herramientas, nuevas formas de estructurar el código.

Y eso significa que los técnicos ya no pueden permitirse el lujo de la especialización profunda en una única aplicación. Porque esa aplicación está en movimiento.

Dos fuerzas que se solapan

Hay un detalle que me preocupa más: los agentes y sistemas de IA que asisten este trabajo evolucionan más rápido que incluso las versiones de los lenguajes.

Si eres especialista en Java, ya tienes un reto: mantenerte al día con las nuevas versiones, los nuevos patrones, las nuevas librerías. Eso cuesta tiempo. Cuesta atención.

Pero ahora, encima, tienes agentes que cambian cada mes. Nuevas capacidades, nuevos «skills», nuevas formas de resolver problemas. Como he contado en otros posts, la velocidad con la que todo esto evoluciona es casi desorbitada.

¿Cómo se supone que una persona sigue siendo competente en Java moderno y en todos los agentes de IA que están emergiendo? No es una pregunta teórica: es lo que está pasando ahora mismo en los equipos.

La bifurcación que se aproxima

Esta tensión me lleva a una reflexión que seguramente veremos materializarse: la separación de los técnicos en dos perfiles.

De un lado, los que se especializan en el conocimiento técnico profundo: programación, arquitectura, patrones, frameworks. Gente que entiende Java moderno, que sigue el ritmo de las versiones, que domina el stack técnico.

Del otro, los que se especializan en sistemas de inteligencia artificial e integración: cómo estructurar agentes, cómo entrenarlos, cómo conectarlos con los sistemas existentes, cómo gestionar el conocimiento que alimenta la IA.

No es que uno sea mejor que el otro. Es que los ciclos de evolución son distintos, y las habilidades requeridas divergen. Hace años pasó algo similar: antes tenías al desarrollador del backend y al del frontend. Evolucionaban juntos, pero cada uno conocía su terreno. Ahora, pero en otra escala.

La implicación estructural

Esto no es un problema de productividad. Es un cambio en la forma de organizar los equipos.

Si antes tenías un equipo «Java» y todos evolucionaban juntos, ahora puede ser que tengas:

  • Un grupo que sigue siendo la punta de lanza técnica (Java moderno, arquitecturas de microservicios, etc.)
  • Otro grupo que lidia con la integración de agentes, el entrenamiento de sistemas, la arquitectura de prompts y skills

Y claro, estos dos grupos tienen que trabajar juntos. No puedes tener uno sin el otro. Pero sus presiones de actualización son distintas. Sus curvas de aprendizaje divergen.

Moraleja

La IA no solo hace el trabajo más rápido: hace que el coste de cambiar sea bajo suficiente para que cambiar sea inevitable. Y eso significa que el conocimiento que podía mantener a una persona productiva durante años ya no te basta. Porque el trabajo no está quieto, y los agentes que te ayudan a mantenerlo tampoco.

¿En tu equipo ya estáis viendo esta bifurcación? ¿O seguís esperando que una misma persona maneje Java moderno y la integración de agentes sin que se le vuelva la cabeza? Cuéntame en LinkedIn.

Relacionados sugeridos