Blog

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

El criterio es el bien de lujo tecnológico de la era IA

Una mujer profesional y un androide humanoide contemplan juntos una gran pintura abstracta en una sala de galería luminosa y minimalista.

Estaba escuchando un podcast sobre lujo. No sobre tecnología. Sobre hoteles, coches, relojes, perfumes y la psicología de lo deseable.

Y en algún momento César Val —experto en estrategia de lujo— soltó algo que me hizo parar el audio y rebobinar: el lujo no es precio. Es deseo. Y el deseo se construye sobre escasez, historia e identidad. Cosas que no se democratizan.

Yo llevaba semanas dándole vueltas a una pregunta completamente distinta: qué queda del valor profesional cuando la IA puede ejecutar lo que antes ejecutaban los expertos. Y de repente los dos cables se conectaron solos.

La IA convierte el conocimiento en commodity

Durante décadas, el conocimiento técnico era escaso. Sabías cosas que otros no sabían, y eso tenía precio.

La IA está cambiando esa ecuación. No porque los expertos hayan dejado de ser útiles, sino porque el umbral de competencia se ha democratizado. Cualquiera con una suscripción de 20 euros al mes puede generar análisis, código, estrategias o documentación que antes requerían años de formación.

Y cuando algo se democratiza, pasa lo que siempre pasa: el precio cae. La ejecución competente se convierte en commodity.

Si todos usamos el mismo Claude, el mismo Copilot, el mismo ChatGPT… ¿en qué te diferencias?

El mecanismo del lujo

César Val tiene una respuesta que no viene del mundo tecnológico, y quizás por eso es útil.

El lujo no compite en precio ni en funcionalidad. Compite en deseo. Y el deseo se construye con tres ingredientes: escasez, identidad e historia. Lo que no puede reproducirse en masa es lo que genera aspiración.

Cuando la producción industrial democratizó la ropa, la moda de lujo no murió. Se volvió más deseable precisamente porque era lo contrario de lo abundante.

Mismo mecanismo, diferente sector.

El criterio como bien escaso

Aquí está el cable que me faltaba conectar.

La IA inunda el mundo de output competente. Texto competente. Código competente. Análisis competente. Producido con los mismos modelos que usa todo el mundo.

Lo que la IA no democratiza es el gusto. La capacidad de juzgar qué es realmente bueno: qué pregunta vale la pena hacerle al modelo, qué respuesta merece descartarse, qué enfoque tiene sentido en este contexto y no en el siguiente.

Eso es el criterio. Y el criterio, en un mundo de output abundante, es escaso por definición.

Escaso. Difícil de imitar. Generador de deseo.

Es decir: es el bien de lujo tecnológico de la era IA.

Luxurizar o commoditizar

Esto tiene una implicación práctica incómoda.

Si tu valor profesional sigue descansando sobre «sé hacer X» —escribir, analizar, programar, diseñar—, estás compitiendo en el terreno donde la IA mejora más rápido. Ese es el camino de la commoditización: velocidad y precio, y en ambos el humano pierde.

El otro camino es el de César Val: construir algo que no puede reproducirse en masa. Una voz. Un punto de vista. Un criterio reconocible que genere confianza antes de que alguien empiece a leer.

Luxurizar el valor profesional no significa volverse elitista ni caro. Significa identificar qué parte de lo que haces no puede replicarse con un prompt bien escrito, y construir desde ahí.

Para mí, eso es la transversalidad: décadas conectando mundos que rara vez conviven bien —negocio, tecnología, seguridad, innovación— y el criterio acumulado para saber cuándo algo tiene sentido y cuándo no. No viene en ningún modelo. Y tampoco en ningún prompt.

Moraleja

Cuando la IA democratiza la ejecución, el valor se desplaza hacia arriba: hacia quien decide qué ejecutar y por qué. El criterio —saber qué es bueno, cuándo importa, por qué este enfoque y no el otro— es lo que queda cuando todo lo demás se automatiza. Y lo escaso, como siempre, es lo que genera deseo.

Me gustaría saber cómo lo ves tú. ¿Estás luxurizando tu valor profesional, o todavía compitiendo en el terreno donde la IA siempre gana?

Cuéntamelo en LinkedIn

Relacionados sugeridos

Publicado el

La coherencia que nadie enseña en ingeniería

Hombre joven con camiseta y vaqueros mirándose en un espejo; su reflejo le muestra vestido con camisa, chaqueta y pantalón chino.

Hace unos años di una ponencia en un evento organizado por RedHat, Intel y la empresa donde trabajaba. Hablé de OpenShift: contenedores, agilidad, el presente del desarrollo de aplicaciones. Salió bien. Fui a casa contento.

Unos días después le enseñé las fotos a mi madre. Echó un vistazo y dijo: «Muy bien, hijo. Pero eras el único que no llevaba traje.»

Lo primero que pensé fue que no habría llevado traje de todas formas. El evento giraba en torno a herramientas de agilidad. Aparecer con traje habría resultado contradictorio —casi cómico— con el propio mensaje. Eso lo tenía claro.

Pero el comentario no me salía de la cabeza. No iba sucio, ni roto, ni estrafalario. Tampoco llevaba algo que llamara la atención en sentido positivo. Mi ropa no restaba. Pero tampoco sumaba.

Desde entonces empecé a tomarme la ropa un poco más en serio. No como vanidad. Como coherencia. Años después, con la IA poniendo el sector patas arriba, esa misma lógica me ha vuelto a la cabeza con más fuerza. Te cuento por qué.

Esto no va de moda. Va de posicionamiento profesional. La ropa es solo el ejemplo más visible de un problema más amplio: la coherencia entre todas las señales que emites, y si esas señales están alineadas con el profesional que quieres ser. En un momento en el que la IA está redefiniendo qué perfiles tienen valor, esa coherencia ya no es opcional.

Lo que dices antes de abrir la boca

María Uranga, experta en asesoría de imagen, lo dice sin rodeos en el podcast de Adrià Solà Pastor: la mayor parte de una entrevista de trabajo ya está decidida antes de que el candidato abra la boca.

Tendemos a leer eso como «viste bien para las entrevistas». Pero si lo transponemos al mundo técnico, el dato es mucho más incómodo.

Tu LinkedIn es una primera impresión. Tu primera intervención en una reunión con cliente es una primera impresión. La forma en que escribes un correo con una propuesta técnica es una primera impresión. Y en todos esos casos, la percepción se forma antes de que el interlocutor procese el contenido real.

La pregunta correcta no es «¿llevo la camisa adecuada?». La pregunta es: ¿con qué intención me estoy presentando?

Vístete para el rol que quieres tener

La frase más memorable del episodio es esta:

«Te tienes que vestir como si ya lo fueras. Si voy a ser el director del departamento, me voy a vestir desde el primer día como si ya lo fuera.»

Sustituyamos «vestir» por «comunicar».

Si quieres que te vean como el profesional que conecta negocio y tecnología, tienes que comunicar como ese profesional desde el primer día: en tus conversaciones, en lo que publicas, en cómo introduces un problema técnico ante un directivo. No esperes a tener el título. La percepción precede al reconocimiento formal.

Este principio no es autoayuda: es la misma lógica que usamos cuando hacemos un PoC antes de tener el presupuesto aprobado. Demuestras el valor antes de que te lo pidan.

Sin coherencia, solo hay disfraz

El límite está claro en el podcast: la imagen falla cuando cae en el disfraz. Cuando hay una desconexión entre lo que proyectas, lo que sientes y lo que realmente eres.

Para un profesional técnico, el equivalente del disfraz es el perfil de LinkedIn lleno de buzzwords sin experiencia real detrás, o el consultor que habla de «transformación digital» en cada frase pero no puede explicar un caso concreto.

La autenticidad no es solo una virtud ética. Es una ventaja estratégica: lo que es real, se sostiene; lo que es disfraz, se cae en la primera pregunta incómoda.

Hay quien lleva esta lógica todavía más lejos. Juan, del canal Huéleme Mucho, lo explica con una imagen que se te queda: si eres Batman, el Caballero Oscuro, no puedes ir oliendo a Nenuco. No porque haya una norma escrita, sino porque en cuanto alguien lo detecta —aunque no lo procese conscientemente— algo no cuadra y eso le pone en alerta. La coherencia no es solo lo que dices o cómo te vistes. Es la suma de todas las señales que emites a la vez.

Si no lo defiendes, lo pierdes

Hay un momento del podcast que resuena especialmente. María explica que si llevas algo que no defiendes —aunque te quede bien— el primer comentario negativo que recibas te desestabiliza. Pero si lo defiendes de verdad, lo que recibes es refuerzo, no crítica.

El mecanismo funciona igual en el posicionamiento profesional.

Si tú mismo no tienes claro qué rol ocupas, qué valor diferencial aportas, cuál es tu área de autoridad… cualquier comentario que cuestione tu valía te afecta de forma desproporcionada. En cambio, cuando hay una narrativa propia consolidada, el ruido externo no encuentra grieta donde entrar.

«Tu imagen es perfecta cuando te defiendes tú mismo», dice. Sin necesidad de validación externa constante.

La estrategia de imagen que nadie enseña en ingeniería

Hay una frase que aparece varias veces en el episodio: «La imagen es dinámica.» No es un estado fijo que alcanzas una vez. Evoluciona con tus objetivos, tu contexto, el rol al que aspiras.

Lo mismo ocurre con el posicionamiento profesional en entornos técnicos.

No es un perfil de LinkedIn que actualizas cada tres años. Es una elección continua sobre cómo te presentas, con qué lenguaje explicas lo que haces, qué proyectos eliges visibilizar y cuáles te quedas para ti.

Nadie nos enseña esto en la ingeniería. Nos enseñan a resolver problemas técnicos. Pero no a comunicar que sabemos resolverlos antes de que nos den la oportunidad de demostrarlo.

El momento de hacer esta revisión es ahora

En el mundo técnico estamos en un momento de reconfiguración acelerada. Muchos perfiles que funcionaban bien hace tres años tienen que redefinir qué valor aportan y cómo comunicarlo. En ese contexto, el posicionamiento no es un lujo: es supervivencia profesional. Y el posicionamiento no empieza en el LinkedIn ni en el discurso. Empieza en cómo te presentas al mundo cada día.

Moraleja

La imagen —física o profesional— no es vanidad. Es el canal por el que el mundo recibe información sobre quién eres y a qué aspiras, antes de que tengas ocasión de demostrarlo.

Si quieres que te vean como un referente en tu área, empieza a comunicar como tal hoy. No cuando tengas el título, no cuando tengas el caso de éxito, no cuando te sientas «suficientemente preparado». La percepción no espera a que estés listo.

Y si no sabes exactamente cómo quieres que te vean, ese es el ejercicio más urgente que tienes pendiente.

¿Tienes claro cómo quieres que te vean —y estás enviando las señales correctas para que eso ocurra? No solo en lo que dices. En todo lo demás también.

Comparte tu reflexión 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.