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

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

Innovación a seis meses vista

Un androide en una reunión de oficina mira un reloj de bolsillo, sugiriendo que la IA acelera los tiempos.

Cuando trabajaba en Iberdrola como consultor de innovación al negocio, solía decir una frase muy simple: la innovación es Iberdrola dentro de tres o cinco años.

No era postureo. Era una forma práctica de justificar por qué merece la pena dedicar un poquito de recursos a hacer pequeñas pruebas de concepto: para eliminar dudas (o confirmar límites) sobre cosas que, si íbamos bien encaminados, en tres a cinco años serían parte del día a día.

Sigo pensando que esa definición es válida. Lo que ha cambiado —y mucho— es el reloj.

Mi definición de innovación (y por qué funcionaba)

En un contexto grande, la innovación no es solo “hacer cosas nuevas”. Es gestionar el riesgo y el aprendizaje.

Por eso las pruebas de concepto encajan tan bien: buscan despejar incertidumbre. Si lo tuviésemos todo claro, no sería innovación: sería un proyecto.

Con IA, el horizonte se ha comprimido

Con la inteligencia artificial he vivido una sensación nueva: la innovación ya no es a tres o cinco años. En estas cosas, muchas veces es a seis meses vista, y un año como máximo.

Lo he notado incluso en algo tan cotidiano como mantener mi web en WordPress: lo que hacía en verano, y cómo lo hacía, no se parece a lo que puedo hacer ahora en Navidades. La tecnología ha avanzado lo suficiente como para obligarte a revisar tu forma de trabajar.

Déjà vu: cuando Internet era “cada día algo nuevo”

Esto me recuerda mucho a cuando empezó todo el tema de Internet, con Java, los Servlets y los EJB.

Era una época muy dinámica: cada día salían cosas que pegaban un avance significativo sobre lo anterior. Estamos hablando de hace más de 25 años.

Hoy, en cambio, muchas tecnologías están más estables. Y, precisamente por eso, esta época de la IA me resulta tan familiar: vuelve esa sensación de revolución, de sorpresa constante y de adaptación continua.

Una época bonita… si la innovación te viene de serie

Si eres de los que llevan la innovación de serie —como yo, que siempre he tendido a probar, medir y ajustar antes de dar nada por sentado— esta etapa es preciosa: desafiante, sí, pero muy bonita.

Si tu planteamiento es más inmovilista, probablemente no estés tan contento. Pero es lo que toca, porque esto difícilmente se puede parar: la mejora de productividad que tienes es brutal.

Y, encima, cada nada salen cosas que te obligan a adaptarte para dar un salto de calidad y de productividad… otra vez.

Moraleja

Durante años, innovar era mirar a tres o cinco años. Con la IA, el horizonte se ha encogido y el ritmo se ha disparado.

No es solo “usar una herramienta”: es aceptar que tu forma de trabajar cambia más rápido. Y decidir cómo te adaptas.

¿A ti qué te está obligando a replantearte este ritmo? Te leo en LinkedIn.

Diseñado en la cabeza de Iñigo, made in ChatGPT.

Relacionados sugeridos

De GPTs a agentes y skills: del flujo del verano al de Navidad

En una oficina luminosa, una persona cambia el ‘empleado del mes’: el androide de verano acaba en la papelera y el androide navideño queda en el marco.

En verano conté en el blog que estaba usando ChatGPT y GPTs personalizados para automatizar tareas de edición: borradores, estructura, tono… y, sobre todo, para quitarme trabajo rutinario que me estaba robando tiempo. Lo conté en: El GPT de mi web me ha abierto los ojos (y no solo para escribir mejor).

Sigue siendo cierto: ese enfoque me descargó de un montón de “micro-tareas” que no aportan valor, y me dejó más energía para lo importante.

Pero en verano el flujo seguía teniendo una pega: mucha IA… y demasiado “pica y pala” con ficheros (esto me llevó a ordenar contexto y estructura: Del Prompt Engineer al Context Engineer: cómo la IA me obligó a reorganizar mi web (y mis esquemas mentales)). En Navidad he hecho el cambio que me faltaba: pasar de usar GPTs como herramienta a usar agentes y skills como parte del proceso.

Lo que funcionaba… y lo que no

El problema no era la calidad del texto que me devolvía la IA. El problema era el flujo.

Un GPT te puede generar un fichero, pero después lo tienes que guardar tú, moverlo a su sitio y subirlo a WordPress. Y cuando estás iterando (un ajuste de tono, un cambio de estructura, una idea nueva), esa fricción se acumula.

He intentado tirar por el camino de los MCP (Model Context Protocol) — lo comenté también en Y si el valor ya no está en las respuestas —, pero a día de hoy no lo tengo fino como para que me compense: no me termina de encajar en el flujo y seguía con demasiada gestión manual.

En vacaciones es cuando más “paz mental” tengo para mantenimiento: ordenar, limpiar, y dejar preparado el terreno para el resto del año.

Y este año he aprovechado para cambiar la forma de trabajo. Mantener la web, al final, es mucho de texto… pero también es muchísimo de manejar ficheros: Markdown, estructura de carpetas, persistencia del contexto, versiones.

Para mí, esto es innovación en pequeño: bajar fricción y riesgo hasta que el hábito sea sostenible.

Por qué me he pasado a Codex

He empezado a usar Codex, la herramienta de OpenAI, para el flujo del blog.

Lo interesante es que, aunque sea una herramienta pensada para desarrollo, en mi caso encaja porque mi “producto” también vive en un repositorio: contenido en Markdown, contexto, y un conjunto de automatizaciones alrededor.

De GPTs a agentes (y de prompts a trabajo reproducible)

Lo que he hecho ha sido coger los GPTs que tenía, con sus prompts, y meterlos en una carpeta dentro de Codex. Luego le he dado el contexto y le he pedido que los transforme en agentes y también en skills (dos estándares que están apareciendo para este tipo de flujos).

Y aquí ha llegado la sorpresa práctica: cuando algo no me ha funcionado, o no lo ha hecho como yo quería, le he pedido a la IA que me lo modifique… y lo ha modificado directamente.

Ya no es “te propongo un cambio y tú lo copias y lo pegas”: es iterar sobre el propio sistema de trabajo, con persistencia.

Lo que más me ha cambiado: los scripts dejan de ser “manuales”

Antes, para tareas concretas (por ejemplo, descargar artículos del blog y dárselos a la IA) tiraba de scripts en Python. Me los había generado la IA, sí, pero luego tenía que ejecutarlos yo a mano en el ordenador.

Ahora, con el enfoque de skills, esa automatización pasa a formar parte del flujo: se ejecuta desde dentro, con menos fricción y más continuidad.

Lo que me llevo (por ahora)

Partía con ventaja: ya tenía trabajo hecho (los GPTs, los prompts, y un estilo más o menos definido). Pero aun así, el salto en productividad es muy grande.

No porque el modelo “escriba mejor”, sino porque el flujo es más sencillo: menos pasos manuales, más persistencia, más capacidad de ajustar el sistema cuando se atasca.

Y otra cosa que me parece interesante es que este tipo de estándares se están empezando a soportar en más herramientas, como Claude y Cursor. Es un hilo que también conecta con: De Google a agentes: mi curva de aprendizaje con la IA.

En resumen: no va de “la herramienta ganadora”, sino de montar un sistema repetible que te quite pasos manuales.

Moraleja

La mejora de productividad no viene solo de pedirle cosas a un modelo: viene de integrarlo en un flujo que no te obligue a pelearte con ficheros y pasos manuales. Si la IA puede trabajar con tu contexto y tu estructura, iteras más rápido y con menos desgaste. Y eso, para mantener un blog, es la diferencia entre “lo haré cuando tenga tiempo” y “esto ya va solo”.

Relacionados sugeridos

¿Tú qué estás quitando (o manteniendo) de tu stack de IA? Te leo en LinkedIn.

Diseñado en la cabeza de Iñigo, made in ChatGPT.

La economía de las suscripciones llega a las herramientas de productividad con IA

Persona sorprendida ante una interfaz de chat de IA mientras varios androides con etiquetas de precio y una factura sugieren el coste acumulado de suscripciones.

Hay un patrón que ya conocemos de sobra: empiezas pagando una suscripción “pequeña”, luego otra, y otra… y, cuando te das cuenta, estás en modo Netflix/Amazon Prime/lo-que-toque, pero aplicado a herramientas de productividad.

Con la IA está pasando algo parecido, solo que el “contenido” no son series: es tu tiempo, tu foco y tu forma de trabajar.

Mi caso: escribir con voz y apoyarme en modelos

Para escribir las entradas del blog estoy usando una herramienta que graba y luego genera transcripción, y después paso ese texto por un modelo de IA para convertirlo en un borrador utilizable. En mi caso la herramienta es Plaud.

El motivo es simple: me automatiza partes pesadas del proceso. En vez de “ponerme a escribir” desde cero, hablo, lo vuelco a texto, y trabajo sobre un material que ya tiene estructura.

Y esto engancha con otra idea que llevo tiempo defendiendo: hablarle al modelo (en vez de teclear) suele ser más cómodo y flexible. Cuando dictas, no te frenas tanto “palabra a palabra”. Piensas en voz alta, y eso, para explorar ideas, es oro.

Tres variaciones del mismo concepto (y por qué se solapan)

En mi día a día he acabado viendo tres familias de herramientas que, en el fondo, hacen lo mismo con distinto envoltorio:

  1. Grabación de conversaciones y reuniones → se orientan a capturar audio “largo”, transcribir y ayudarte a generar un resumen o un borrador. Aquí encaja Plaud (por cómo lo uso).
  2. Interfaces tipo ChatGPT/Claude → puedes hablarle al modelo y trabajar en modo conversación, pero normalmente hay límites de minutos, cuotas o planes.
  3. Dictado como interfaz del sistema → herramientas como SuperWhisper que sustituyen el dictado del Mac por algo que no solo transcribe, sino que además puede “pasarlo por un modelo” con una instrucción. Por ejemplo: responder un email con la voz y pedir que lo reescriba en un tono formal.

Las tres familias tienen sentido. El problema llega cuando las usas todas: empiezas a pagar varias suscripciones para resolver tareas muy parecidas.

El detalle que cambia el cálculo: lo que ya viene incluido

En mi caso, por ejemplo:

  • La suscripción de ChatGPT sí la estoy pagando.
  • Con Plaud tengo 300 minutos al mes incluidos, que para mí suele ser suficiente, así que no necesito pagar un extra por uso.
  • SuperWhisper es algo que me atrae para el “día a día” (sustituir teclado por voz), pero si lo adoptas de verdad, es otra suscripción que se suma.

Y aquí aparece la pregunta práctica: ¿estoy pagando por complementariedad o por solape?

Una regla simple para no acabar pagando tres veces por lo mismo

Sin meterme en números (porque cada caso es un mundo), a mí me ayuda un criterio muy directo:

  • Si la herramienta me cambia el flujo (hace posible algo que antes no hacía) → tiene sentido pagar.
  • Si la herramienta solo optimiza un 10–20% algo que ya hago con otra → sospecha de solape.

En otras palabras: no se trata de “cuál es mejor”, sino de cuántas capas estoy comprando para el mismo trabajo: capturar voz → transcribir → transformar → ejecutar.

Y, sobre todo, intentar tratar la adopción de estas herramientas como lo que es: innovación como gestión del riesgo y del aprendizaje, no como coleccionismo de suscripciones.

Empresas vs. uso doméstico: la diferencia del retorno

Para una empresa, pagar varias herramientas puede ser viable si hay retorno: ahorro de tiempo, calidad de comunicación, menos fricción en tareas repetitivas, etc.

En cambio, a nivel doméstico (o de marca personal), llega un punto en el que es difícil sostenerlo: no puedes estar pagando 20 euros/dólares al mes por un montón de herramientas parecidas. Aunque cada una sea “barata”, el conjunto se convierte en una factura fija.

¿Convergencia o fatiga?

No tengo claro hacia dónde irá esto.

Por un lado, sería lógico que unas herramientas absorban funcionalidades de otras (y acabes con una única suscripción “completa”). Por otro, ahora mismo da la sensación de que estamos entrando de lleno en una economía de suscripciones de productividad con IA, donde el mercado premia el “paquete” más que la herramienta puntual.

Mi intención, al menos, es vigilar dos cosas:

  • Qué parte de mi proceso necesito de verdad (y cuál es capricho tecnológico).
  • Qué herramienta se queda como “base” y cuáles tienen que justificar su sitio sin duplicar a las demás.

Si tú también te estás montando tu stack de IA, quizá la mejor pregunta no sea “¿qué herramienta me falta?”, sino: ¿qué suscripción me sobra?

Relacionados sugeridos

De domótica a inteligencia: cuándo una Smart Home es realmente “smart”

Mujer sentada en un sofá conversando con un androide de ojos iluminados que pulsa el interruptor de un aplique de pared para encender la luz, al atardecer, en un salón moderno de Smart Home con plantas y una obra estilo Pollock.

Cuando empecé a domotizar mi casa, lo hice como informático: “automatizar todo para trabajar menos”. Instalé bombillas, interruptores y lo conecté todo a Home Assistant. Pero tras varias anécdotas (como pedirle al Apple Watch que encendiera la luz del baño y acabar poniendo una cadena de radio en medio de una reunión), descubrí que la verdadera inteligencia de una Smart Home va mucho más allá de comandos de voz o apps móviles.

¿Qué diferencia una casa domotizada de una casa inteligente?

  • Casa domotizada: requiere tu orden explícita. Cambias un interruptor por un botón en la app o por “Oye Siri…”.
  • Casa inteligente: actúa sin que se lo pidas; infiere estado y contexto para tomar decisiones autónomas.

La clave está en saber cuándo y cómo debe encender o apagar algo sin que tú levantes un dedo.

La farsa de los comandos de voz

Aunque en su día era lo “cool”, descubrí rápidamente sus límites:

  1. Latencia: hay un retraso desde que le das la orden con la voz hasta que se enciende la luz.
  2. Errores de interpretación: el Apple Watch interpretó “enciende baño” como “reproducir radio”.
  3. Dependencia de la infraestructura cloud: si falla Internet, no hay luz.

En cambio, una solución local basada en sensores y automatizaciones bien definidas funciona siempre.

Aprendizajes prácticos

  • Transparencia manual: conserva siempre la posibilidad de interruptores físicos; los invitados y tu familia lo agradecerán.
  • Simplicidad sobre complejidad: no todo debe automatizarse; prioriza las situaciones que realmente disfrutes tener libres de clics.
  • Resiliencia: contempla fallos (cortes de luz, pilas bajas en sensores) y diseña recuperaciones automáticas o notificaciones.

Tu casa, tu laboratorio de innovación

Las reglas que aplicas en tu hogar valen para cualquier proyecto tecnológico: evita el exceso de automatización, itera con datos reales y pon siempre al usuario (tú mismo) en el centro.

Moraleja

No se trata de llenar la casa de tecnología, sino de usar la justa. La verdadera comodidad está en que no notes que hay un sistema detrás, que la casa trabaje para ti no tú para la casa.


¿Y tú has convertido tu hogar en un sistema verdaderamente inteligente? Comparte tus retos y triunfos en los comentarios o en LinkedIn.

De momento el Diseñado en la cabeza de Iñigo, made in ChatGPT es solo para el web mi SmartHome sigue siendo diseñada y automatizada por mi.

Relacionados sugeridos

ChatGPT como copiloto: conclusiones de un experimento personal

Científico y androide colaborando en un laboratorio de alta tecnología

Hace meses decidí usar mi web como laboratorio para ChatGPT. Siempre ha sido una mezcla de tarjeta de presentación y laboratorio. Ahora, esa faceta laboratorio de inteligencia artificial ha tomado el mando.

¿Qué he aprendido trasteando con ChatGPT?

Después de darle bastante cera, hay cosas que tengo claras:

  1. Si sabes del tema, ChatGPT no es mejor que tú. Puede aportar puntualmente, pero a veces alucina. Eso sí, lo hace mucho más rápido.
  2. Si no sabes del tema, es oro. No será el mejor copywriter del mundo, pero escribe mejor que yo y en menos tiempo.
  3. Es un copiloto, no un piloto. Para temas sensibles (salud, decisiones críticas) necesita supervisión. Para otros, como optimizar un post, me sobra.
  4. Puede hacer mucho más de lo que creemos. Pero hay que darle contexto y cuidar el formato de entrada, si no, alucina.
  5. Conviene preguntarle cuando se va por las ramas. Suele explicar por qué y ajusta el tiro.

ChatGPT cambia la forma de trabajar

Lo veo claro: tenemos que adaptar nuestros procesos para incorporar a este “ayudante digital”. No es solo prompt engineering; es repensar cómo estructuramos la información para que saque su máximo potencial.

En mi caso, lo estoy usando para todo: desde posts de blog hasta elegir perfumes o renovar ropa. ¿El resultado? Me descarga de tareas repetitivas y me deja energía para lo creativo, justo donde quiero estar.

Moraleja

La IA no viene a sustituirte, viene a multiplicar lo que puedes hacer… siempre que sepas pilotar. Y si no, al menos deja que el copiloto te lleve un rato 😉.


💬 ¿Tú también estás probando IA en tu día a día? Cuéntamelo en LinkedIn y seguimos la conversación.

Ya sabes que esta entrada está Diseñada en la cabeza de Iñigo, made in ChatGPT

Cuando ChatGPT se volvió mi personal shopper… de perfumes

Hombre joven y androide eligiendo un perfume en una tienda moderna.

Como dice mi madre, soy el tío de los olores, lo reconozco. A unos les va el vino, a otros los quesos, a otros los coches deportivos, etc. A mí, lo que me pierde son los perfumes, te ayudan a cambiar el estado de ánimo. De nicho, además. De esos que cuestan un riñón y duran tres vidas, así que hay que elegirlos muy bien, que riñones solo tengo dos 😔.

El otro día, tras una jornada cancelada de recados, acabé deambulando por El Corte Inglés. Y claro, uno no entra a “mirar” perfumes. No pude hacer los recados, pero si salí con unas muestras nuevas en la mochila y una pregunta en la cabeza.

¿Y si le pido ayuda a la IA con esto?

Llegué a casa y saque a relucir mi faceta mas innovadora: abrí ChatGPT y le dicté toda mi colección de perfumes. Nada de teclear—eso ya lo he contado en otra entrada—porque hablarle al modelo es mucho más ágil.

Le solté nombres, marcas, impresiones… Y el modelo, que no tiene nariz pero sí contexto, empezó a ayudarme. No a recomendar a lo loco, sino a:

  • Identificar qué me gusta de verdad.
  • Ver qué carencias tengo (hola, perfumes cítricos de verano).
  • Comparar alternativas que había visto ese día.
  • Ahorrarme visitas a Fragantica buscando notas, familias y reseñas.

¿Esto va de perfumes o de productividad?

Las dos cosas. Porque al final no es tanto el perfume como el caso de uso. Lo que hice fue usar una IA generalista como un copiloto muy personalizado, no para sustituir mi gusto, sino para entenderlo y amplificarlo.

Y eso me hizo pensar: ¿cuánta gente está infrautilizando modelos como ChatGPT porque no les da contexto? ¿Cuántos están pidiéndole magia sin haberle contado antes su historia?

Este caso, aunque parezca frívolo, es una metáfora útil para equipos y profesionales que aún no ven el punto de incorporar IA a su flujo de trabajo. No hace falta que sepa programar: hace falta que sepa de ti.

No se trata de oler mejor, sino de decidir mejor

La IA no huele. Pero organiza. Te ayuda a pensar en voz alta, a tomar decisiones con más información y menos desgaste. Y eso, se llame perfume, arquitectura software o estrategia de innovación, al final es productividad.

 Moraleja

No hace falta tener un problema técnico para que la IA te aporte valor. Basta con tener una decisión entre manos… y darle contexto.


¿Y tú, a qué IA le has contado ya tus vicios? Cuéntamelo en LinkedIn 😉

Diseñado en la cabeza de Iñigo, made in ChatGPT, y personal Shopper a ver a donde nos acaba llevando esto…

¿Y si los bots no quieren leer lo mismo que tú?

Androide programando en dos pantallas de código mientras una ingeniera lo observa asombrada.

Últimamente me ha dado por experimentar con un GPT personalizado que me ayuda a repasar las entradas del blog. Y hace unos días, al pasarle una URL mía, me di cuenta de que el pobre se quedaba atascado. No por falta de inteligencia, sino porque el HTML venía tan cargadito de scripts, estilos y marcos que lo importante —el contenido— se perdía entre la maleza.

¿A quién estamos sirviendo nuestras webs?

Durante años, los arquitectos de software nos hemos centrado en optimizar la experiencia de usuario… humana. Pero resulta que los nuevos usuarios no llevan gafas ni ratón. Son bots. Inteligentes, veloces, insaciables.

Y esos bots, especialmente los que razonan, no hacen una búsqueda, leen un artículo y se van. No. Se lanzan a por toda la web, scrapings incluidos, con un ansia que dejaría a Google Reader en pañales.

Esto plantea una cuestión incómoda: ¿están nuestras webs preparadas para clientes no humanos?

El rendimiento no es lo único: la eficiencia cognitiva del bot

Un humano entra en Google, lee dos párrafos, decide si sigue. Pero un agente basado en IA se lo zampa todo, javascript inútil incluido, para intentar entender. Eso es un despilfarro brutal de ancho de banda, CPU y paciencia (la suya y la nuestra).

Lo he comprobado con mi agente. Si le paso una URL con mucho HTML decorativo, no solo tarda más: muchas veces no consigue extraer lo relevante porque se le cuela el menú, el pie de página y los avisos legales antes del contenido real. Cuando no directamente alguna herramienta anti bots corta parte del contenido.

¿Y si empezamos a pensar en ellos también?

Quizá haya llegado el momento de repensar cómo servimos información. No digo que reemplacemos el frontend, pero podríamos ofrecer rutas alternativas, más livianas, diseñadas explícitamente para estos nuevos consumidores digitales.

Imaginad algo así como un Model Context Protocol (MCP): una interfaz específica que exponga el contenido relevante, sin javascript, sin estilos, sin adornos. Puro conocimiento. Algo así como el «modo lectura» para bots. Quizás nuestros servidores nos lo agradezcan, o el financiero al ver el gasto de la nube de turno.

Moraleja: el próximo cliente puede que no tenga ojos

Estamos en plena transición hacia una web que ya no es solo para humanos. Y como arquitectos, innovadores o simplemente como quienes mantenemos el chiringuito online, toca hacerse preguntas nuevas.

¿Estamos enseñando bien nuestras cartas a estos nuevos jugadores? ¿O seguimos decorando el tablero para un público que ya no mira?


👉 Si esta reflexión te ha tocado una fibra o quieres compartir cómo lo estás resolviendo tú, te leo encantado en LinkedIn. ¡La conversación sigue allí!

De momento lo que si tengo claro es que está Diseñado en la cabeza de Iñigo made in ChatGPT, y que el topicazo de las gafas me ha hecho gracia y lo he dejado. Quien lo leerá ya no lo tengo tan claro 😉

El GPT de mi web me ha abierto los ojos (y no solo para escribir mejor)

profesional trabajando en varias pantallas

Hace un tiempo decidí probar a crearme un GPT personalizado para ayudarme con las tareas del blog: redactar borradores, categorizar, generar imágenes… lo típico. Pero lo que empezó como un “truco de productividad” ha acabado siendo una pequeña epifanía sobre cómo puede evolucionar nuestro trabajo en desarrollo de aplicaciones con la IA.

¿Para qué usamos (de verdad) la IA en las empresas TI?

Lo primero que se nos ocurre a los que estamos en tecnología es usar la IA para hacer lo mismo de siempre, pero más rápido y con más calidad: programar, escribir historias de usuario, documentar… Y sí, funciona. Nos hace más productivos y mejora los entregables.

Pero… seguimos haciendo las mismas aplicaciones. El valor añadido es interno, para nosotros como desarrolladores, no para el usuario final. Es una mejora, pero no es transformación.

IA dentro de las aplicaciones: que el usuario también gane

El segundo salto es dotar a nuestras aplicaciones de más inteligencia, para que las personas que las usan sean más eficientes o reciban respuestas más útiles. Un ejemplo real: mi propio GPT en WordPress no solo escribe textos, también aplica mi estilo, mi estructura de pensamiento y mis temas recurrentes.

Ese mismo patrón se puede aplicar en los portales, en los backoffices, en los CRM: que las aplicaciones aprendan cómo se expresan y trabajan sus usuarios, y les ayuden de forma contextual. Aquí sí estamos añadiendo valor al producto, no solo al proceso.

Y el paso siguiente… ¿para qué IA hacemos nuestras aplicaciones?

Este es el punto que más me interesa últimamente: crear servicios diseñados explícitamente para ser consumidos por inteligencias artificiales, no por humanos.

Porque si el consumidor de nuestros APIs va a ser un agente autónomo, tener un REST con documentación en Swagger igual ya no vale. Necesitamos nuevos protocolos de contexto como el Model Context Protocol (MCP) o repensar nuestros endpoints para exponer capacidades de negocio, no solo operaciones CRUD.

¿Nos consume una persona con interfaz gráfica o una IA que busca resolver una intención compleja? Eso lo cambia todo.

Moraleja

La IA no es solo una herramienta más en nuestra caja: es un nuevo interlocutor, tanto en el proceso como en el destino final de nuestras aplicaciones.



¿Y tú? ¿En qué punto estás con la IA en tu trabajo diario? Te leo en LinkedIn 😉

Diseñado en la cabeza de Iñigo, made in ChatGPT y también abre ojos