Blog de Daniel Torres Burriel

Me gusta mucho empezar a escribir un post por el principio. Esto puede parecer una obviedad pero es que lo que me gusta es escribir el título del post al final. Básicamente porque yo sé cómo empiezo a escribir pero hay veces que el propio texto me lleva a otros territorios y entonces tengo que cambiar el título original, si es que he empezado por ahí.

En realidad hoy creo que no hace falta, porque tengo muy claro de lo que voy a escribir: quiero contar lo que ya estamos haciendo en mi empresa con inteligencia artificial. Parece sencillo, pero no lo es tanto, porque aquí se trata no de teorizar, sino de recopilar, sintetizar y compartir lo que ya estamos trabajando. Es decir, voy a hablar en pasado y en presente.

No vendemos IA, vendemos criterio sobre dónde y cómo aplicarla.

Podría terminar aquí el post porque la cita anterior resume perfectamente lo que quiero contar. Pero quiero entrar en detalles.

La IA no sustituye, redistribuye el trabajo

O lo que es lo mismo, mucha gente ha entrado directamente en la conversación del miedo a la inteligencia artificial, pero deberíamos hablar más bien de redistribución del trabajo. Las cosas las vamos a hacer de otra manera y quizá también haya cambio de roles y de personas.

Tenemos internamente un evento en marcha llamado “Los días de IA”, que es una iniciativa semanal donde cada miembro del equipo presenta ante toda la organización un caso real de aplicación de IA en su trabajo. Tenemos ya cuatro sesiones completadas: Mindful Journal, herramientas de research, Notebook LM aplicado a formación, y un agente de Codex. La quinta sesión la tenemos confirmada sobre optimización de tokens.

Hemos sistematizado la documentación de cada sesión en doce bloques canónicos, en markdown y Word con la plantilla corporativa, para que el conocimiento no se quede en la persona que lo presenta y se pueda reutilizar.

En el caso del agente de Codex, el sistema está desplegado y disponible para todo el equipo del repositorio, es decir, no es una herramienta individual. Lo hemos hecho así a propósito para evitar que distintas personas construyan agentes paralelos y dispersen recursos.

Cada rol del Estudio está redefiniendo cómo aplica la IA en su área: research, producto, formación, ingeniería y dirección. Las decisiones sobre qué herramienta usar y cómo integrarla en el flujo se toman desde cada disciplina, no desde una directriz vertical.

El criterio es el activo y se entrena con los años

Trabajamos los prompts iniciales fuera de la herramienta de construcción elegida, con el apoyo de un LLM aparte (Claude o Gemini) que ayude a dar exactitud al enunciado antes de empezar a ejecutar. Después lo refinamos dentro del constructor.

Aplicamos criterio de dirección de diseño desde el primer prompt, es decir: paleta, tipografía, modelo de interacción, gestión del error y tono. En el caso de Mindful Journal, instrucciones como “tono europeo, azules, sin remates” sustituyeron a la estética genérica que devuelve la herramienta por defecto.

Aproximadamente el 80% de las conversaciones de dirección con clientes, futuros clientes y partners pasan por un LLM antes de salir hacia afuera: para clarificar puntos, alinear estrategias y priorizar objetivos, tanto a nivel de contenido como de forma.

Distinguimos de manera explícita y transparente entre dos tipos de agente:

• Los que tienen reglas cerradas y resultado seguro (pueden lanzarse con un trigger automático).
• Los que operan sobre contexto sensible de cliente (necesitan supervisión humana en cada ejecución).

Esa distinción se documenta en el gobierno de decisiones del propio agente.

El coste de explorar se ha desplomado, y eso lo cambia todo

No nos quedamos cruzados de brazos ni nos lamentamos:

Tenemos un stack de construcción rápida activo y en producción: Replit, Lovable, Google AI Studio, v0, Mocha (hasta hoy, que han anunciado que lo cierran). Cada herramienta sirve a un objetivo determinado y concreto, y elegimos la adecuada según el tipo de salida que va a tener (web vs. app móvil, prototipo vs. producto desplegable).

Las herramientas de assessment (madurez ResearchOps, índice de madurez UX) están planteadas como fabulosos activos comerciales: entregan valor al usuario antes de la primera conversación y por detrás alimentan el CRM con leads cualificados por nivel de madurez.

El planteamiento de cada propuesta a cliente parte del marco “pieza pequeña y acotada como entrada”: un AI Readiness Assessment antes de proponer la suite completa. Lo hemos probado ya en 5 presentaciones a clientes corporativos.

La verificación es rápida pero obligatoria

Quien piense que esto es copiar y pegar o que las automatizaciones funcionan solas sin intervención humana, tiene un problema de comprensión.

Notebook LM opera siempre sobre fuentes cerradas que seleccionamos previamente: guías metodológicas, informes de años anteriores, materiales propios y webs específicas. Nunca con acceso libre a internet. Cada respuesta del sistema en Notebook LM tiene asociada una cita verificable al documento y párrafo de origen, accesible con un clic. La revisión la hacemos contra la fuente, no contra la intuición.

El agente de Codex está construido sobre un sistema de 7 archivos que estructura toda la operación: rol del agente, estándar de implementación, contrato de entradas y salidas válidas, checklist de acciones obligatorias, lógica de testing, ejemplos de referencia y gobierno de decisiones. El agente ajusta los tests en el mismo momento en que modifica el código, de manera que la verificación es inherente al proceso, no un paso posterior que pueda olvidarse. Si un test falla, falla antes de que la migración se considere completada.

Tenemos Atlas, el repositorio interno de insights de research, como fuente de verdad consultable para las herramientas de IA que trabajan sobre conocimiento del Estudio.

La accesibilidad la trabajamos desde el prompt

Las herramientas de assessment las hemos construido sobre WCAG 2.2 desde el primer prompt, con instrucciones explícitas sobre tabulación, area-labels para lectores de pantalla, contrastes y orden de foco. No lo hemos añadido después.

Trabajamos el responsive con atención específica a dispositivos móviles : ya que los constructores no resuelven los tres breakpoints a la vez, tenemos que indicar expresamente qué versión corregir y verificar el comportamiento en cada una.

Cuando hemos generado interfaces con vibe coding hemos aplicado contraste verificado WCAG AA desde el principio.

Ofrecemos el Módulo 2 del AI Experience Suite (AI Experience Audit) como servicio comercial específico para auditar la usabilidad de funcionalidades de IA ya integradas en producto de cliente. Varios de los clientes corporativos a los que hemos presentado el módulo han reconocido tener funcionalidades de IA en producción que sus usuarios ignoran.

Los prompts iniciales los trabajamos en inglés para incurrir en un menor consumo de tokens y en línea con estudios sobre la influencia del idioma en la precisión del modelo. Lo hace el equipo de research y también el equipo de ingeniería para el afinado del agente.

En resumen, os he dicho que este post habla en pasado y en presente. Habla de lo que hacemos y es algo que, mea culpa, no teníamos documentado y aquí está.

Llevo un mes trabajando, a ratos sueltos, en un proyecto personal que no tiene ambición comercial. Se llama Mindful Journal y vive en mindful-journal.app. Es una aplicación para escribir, para pensar, para reflexionar, para darse tiempo y para cuidarse. A veces también para darse unos cuantos latigazos cuando toca, que tampoco se trata de un ejercicio constante de complacencia con uno mismo.

La he construido probando el framework de Replit y he aprendido bastante por el camino.

Por qué un diario

Tampoco es una idea original. Llevar un diario es una práctica con siglos de recorrido y la literatura sobre sus efectos en el bienestar emocional es abundante. Lo que me interesaba era otra cosa: si el acto de escribir, de detenerse a pensar y de revisar lo escrito en perspectiva tiene valor, ¿por qué la mayoría de aplicaciones que existen para esto se plantean o como redes sociales encubiertas, o como herramientas de productividad disfrazadas de bienestar?

Quería algo distinto. Una herramienta que parte de una convicción sencilla y muy personal: escribir sobre uno mismo hace bien. Sin terapia, sin programa estructurado, sin método infalible. Solo un espacio privado, seguro y propio, donde volcar pensamientos, registrar emociones y, con el tiempo, empezar a ver patrones que quizá nunca habías notado.

Vivimos en una cultura que mide, optimiza y acelera. Que pide resultados rápidos y visibles. Qué lío todo. El bienestar emocional no funciona así. No hay una guía de pasos ni hay un resultado que alcanzar en una fecha concreta. Uno lo va descubriendo con el uso, con el lápiz, con el silencio cuando toca silencio.

Los principios que he intentado mantener

He trabajado con cuatro principios de fondo, no como mantras sino como criterios para decidir.

El primero, bienestar, no rendimiento. No hay puntuaciones que mejorar, ni hay metas que cumplir, y por supuesto no hay rachas que defender. Escribir ya es el acto en sí. Si una decisión de diseño no contribuye a que la persona se siente, escriba y luego pueda revisar lo escrito, sobra.

El segundo, privacidad radical. Las entradas son del usuario. Solo del usuario. Sin anuncios, sin análisis externos, sin entrenamiento de modelos a costa de lo que la persona ha decidido confiar a la aplicación. Y sin la posibilidad de compartir. Esto se traduce en cumplimiento estricto de GDPR, declaración de accesibilidad, política de privacidad, aviso legal y un DPO real, que soy yo mismo a través de Torresburriel Estudio. Si una aplicación pretende ser un espacio seguro para volcar lo emocional, lo mínimo es que el marco legal acompañe.

El tercero, sin fricción. Abre, escribe y cierra. La herramienta tiene que desaparecer para que lo que quede sea la persona y lo que ha escrito. He pensado  en esto al diseñar las prompts de escritura, que aparecen en el idioma elegido por el usuario, son rotativas y están redactadas para invitar, no para imponer. Y también al decidir que la página de resultados deje de ser scroll infinito a partir de los diez registros, porque en una aplicación que pretende reducir la ansiedad, el scroll infinito es enemigo declarado.

El cuarto, autenticación seria. He decidido que la entrada se hace mediante Google OAuth. Soy consciente de que esto deja fuera a quien no tiene o no quiere usar una cuenta de Google. Lo he sopesado. La alternativa habría sido construir un sistema de autenticación propio, con su recuperación de contraseñas, sus correos transaccionales y las incidencias de soporte. Un rollo que ahora mismo no he querido afrontar. Para un proyecto personal y para una aplicación cuyo valor reside en la confianza, he preferido apoyarme en un mecanismo robusto antes que improvisar uno inferior.

El agradecimiento como ancla

Hay una pieza que me parece central y que merece párrafo aparte: la nota de gratitud.

No la he metido como obligación, sino como invitación. La investigación en psicología positiva lleva décadas documentando el efecto del agradecimiento en el estado de ánimo, la resiliencia y la capacidad de atención plena. Y en una aplicación de escritura reflexiva, dejar fuera ese ángulo habría sido empobrecer mucho el producto.

Anotar aquello por lo que uno agradece, algo pequeño, algo cotidiano, no cambia la realidad. Pero hace algo mejor: entrena la mirada. Y una mirada entrenada en lo que sí hay, en lugar de en lo que falta, transforma poco a poco la experiencia de estar. La sección de análisis recoge los agradecimientos en perspectiva, porque revisarlos en bloque, semanas después de haberlos escrito, tiene un efecto distinto y complementario al de escribirlos en el momento.

Lo que ha pasado por el camino

He iterado sobre el producto en sesiones cortas, prácticamente todas a través de prompting con la herramienta. He pedido cosas concretas y he ido revisando lo que la herramienta entregaba. Hasta ahí todo normal. Hasta me he quedado sin tokens. El mundo moderno.

Algunas iteraciones han sido de fondo. Por ejemplo, el momento en el que decidí que la aplicación tuviera registro de usuarios y persistencia de datos por persona, en lugar del estado público inicial. O cuando trasladé el dominio personalizado y descubrí, tras hacer login, que los datos previos no estaban accesibles desde el nuevo dominio, lo que me obligó a entender bien cómo se gestiona la migración de bases de datos en este tipo de despliegues.

Otras iteraciones han sido de detalle pero para mi igual de relevantes:

• Que los prompts de escritura aparezcan en el idioma del usuario y no solo en inglés.
• Que el footer recoja con claridad el aviso legal, la declaración de accesibilidad, la política de privacidad y la información sobre el autor y el proyecto.
• Que el diseño visual tenga un sesgo más europeo, con predominio de azules y sans serif para lo que dirige la acción, en lugar de la convención cómoda de pasteles y tipografías redondeadas que tanto abunda en aplicaciones de bienestar.

Qué he aprendido construyéndola

He aprendido que el framework de Replit es razonablemente potente para llevar una idea a producto sin tener que ensamblar veinte herramientas distintas. También que sigue y seguirá habiendo decisiones que requieren criterio profesional y que ninguna herramienta toma por ti: qué arquitectura de información tiene sentido, qué piezas legales son obligatorias y cuáles convenientes, cuándo un módulo es funcionalidad y cuándo es ruido.

He vuelto a comprobar, una vez más, que vibe coding sin criterio es vibe coding sin destino. La herramienta acelera pero, de momento, no decide. La diferencia entre un producto digno y uno mediocre sigue estando en quién decide qué se construye, para quién y por qué.

Y he confirmado lo que ya intuía: que construir cosas pequeñas, con intención y para uno mismo, sigue siendo una de las formas más honestas de aprender. No hay informe de cliente, ni tablero de KPIs, ni revisión de stakeholders. Solo la pregunta, repetida cada vez que tomas una decisión, de si esto que estás haciendo merece la pena.

Mindful Journal no pretende estar terminado, no creo que lo esté. Es como el propio proceso de conocerse a uno mismo, está en construcción permanente. Se nutre de la experiencia de quienes lo usan, de lo que se echa en falta, de lo que sobra. Es una aplicación para parar. Construirla ha sido, paradójicamente, una forma de no parar de pensar.

Es viernes y me iba a poner a preparar un artículo para este mi blog personal, comentando una experiencia de generación de un sistema de diseño y codificación con inteligencia artificial de sus componentes a través del fichero DESIGN.md.

Pero es viernes por la tarde y en mi ha calado muy profundo aquella cosa de cuidarse uno mismo, de respetar el tiempo de descanso y de dejar descansar al cerebro. Es por eso que lo que voy a dejar aquí son un par de enlaces. Muy modesto todo, que nadie haga análisis sesudos porque mi objetivo aquí es simplemente divulgativo.

Pero es que hace semanas he venido trabajando en la creación de un sistema de diseño que me sirva como playground para actividades y pruebas posteriores. Lo he llamado Aragonia Design System, porque me apetece y porque me pone mucho dar visibilidad a todo lo que tiene que ver con Aragón. Quien me conocéis sabéis que soy aragonés, muy aragonés y mucho aragonés. Y hago gala de ello, siempre que tengo oportunidad.

Pero a lo que voy, que no me quiero desviar. Quien todavía tenga alguna duda acerca de el tremendo impacto de las herramientas de inteligencia artificial generativa en todo el ciclo de diseño centrado en el usuario, debería considerar su posición de manera urgente.

Todo esto que os cuento lo comparto después de haberlo compartido ya con mi equipo y después de haberlo implementado en la metodología de trabajo que seguimos para trabajar con clientes, siempre y cuando las circunstancias de contexto lo permitan. De esto último hablaré más adelante, porque tiene mucha chicha y seguramente hablaré en el blog de Estudio.

Por supuesto, todo el feedback será más que bien recibido.